Bug#994288: [Debichem-devel] Bug#994288: libinchi1: feature request, add InChI trust, reference executable

[Andrius Merkys]

X-Debbugs-CC: dleid...@debian.org

Hi Norwid,

On 2021-09-15 10:58, Norwid Behrnd wrote:
> to assign InChI and InChIKey to molecular structures described in a .sdf file,
> I suggest the addition of InChi  trust's reference implementation into the
> applications curated by debichem.  This would allow a local generation of 
> these
> descriptors without need to access a public third party web page (protection 
> of
> intellectual property) and independently of libraries like OpenBabel/RDKit 
> (and
> their implementation of InChI/InChIKey).

Am I right to assume you are requesting here for the 'inchi_main'
executable being included in Debian packages for inchi?

Best,
Andrius

Bug#994438: kubernetes-client: Please provide zsh completion for kubectl

[Florian Schlichting]

Package: kubernetes-client
Version: 1.20.5+really1.20.2-1
Severity: wishlist

It would be nice to have zsh completion for kubectl readily available
once kubernetes-client is installed, as is the case for bash completion.

Thanks for working on kubernetes in Debian!

Bug#994437: libortp: missing -lbctoolbox

[Frank Heckenbach]

Package: libortp-dev
Version: 1:4.4.13-2
Severity: normal
File: libortp

% cat a.c
#include 

int main ()
{
  ortp_init ();
  ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c  `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol 
'bctbx_set_log_level_mask'
/usr/bin/ld: /lib/x86_64-linux-gnu/libbctoolbox.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
% gcc a.c  `pkg-config --cflags --libs ortp` -lbctoolbox
% ./a.out

So I think "-lbctoolbox" should be added to ortp.pc,
probably via "Requires:".

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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libortp-dev:amd64 depends on:
ii  libbctoolbox-dev  4.4.13-2
ii  libortp15 1:4.4.13-2

libortp-dev:amd64 recommends no packages.

libortp-dev:amd64 suggests no packages.

-- no debconf information

Bug#994436: librsvg2-bin: error reporting

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal

% cat bogus.svg

% rm -f bogus.pdf
% rsvg-convert -f pdf -o bogus.pdf bogus.svg
Error reading SVG:XML parse error: error code=201 (3) in (null):1:71: Namespace 
prefix xlink for href on use is not defined


% ls -la bogus.*
-rw--- 1 frank frank  0 16. Sep 05:07 bogus.pdf
-rw--- 1 frank frank 79 16. Sep 05:06 bogus.svg
%

The error itself is correct AFAIK, but the location is given with
"(null)" instead of the correct filename.

Afterwards, an empty output file is left which can be problematic
e.g. when run from a makefile. Of course, it can be worked around
with something like '|| { rm -f "$@"; false; }', but that really
shouldn't be necessery.

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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#994435: nsca-client: send_nsca client not working on bullseye

[Richard Landster]

Package: nsca-client
Version: 2.10.0-1
Severity: important

Dear Maintainer,

The send-nsca client in bullseye is not working for me.

Here is the command I use:

echo -n 'shared-web-test;my-api-cert;2;CRITICAL - certificate expired' | 
/usr/sbin/send_nsca -d ';' -H nagios01.example.com -to 5

On BUSTER this command returns:

1 data packet(s) sent to host successfully.

Furthermore, the passive alert shows up on the nagios server.

However, on BULLSEYE the above command returns:

0 data packet(s) sent to host successfully.

Doing a tcpdump on the Nagios server nagios01.example.com I do see network
traffic when running the command on the BULLSEYE host, but the alert does
not register.

The nagios01.example.com server is running Nagios 4.4.6.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages nsca-client depends on:
ii  libc6   2.31-13
ii  libmcrypt4  2.5.8-3.4+b1

nsca-client recommends no packages.

nsca-client suggests no packages.

-- no debconf information

Bug#994223: [Pkg-javascript-devel] Bug#994223: lintian-brush crashes with multiple sources

[Yadd]

Control: severity -1 grave
Control: retitle -1 lintian-brush unusable

Le 14/09/2021 à 08:23, Yadd a écrit :
> Package: lintian-brush
> Version: 0.111
> Severity: important
> X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org
> 
> Hi,
> 
> when launching lintian-brush on a multiple-sources packages, it crashes:
> 
>   Traceback (most recent call last):
>   File "/usr/bin/lintian-brush", line 33, in 
> sys.exit(load_entry_point('lintian-brush==0.111', 'console_scripts', 
> 'lintian-brush')())
>   File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", line 328, 
> in main
> overall_result = run_lintian_fixers(
>   File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 1165, 
> in run_lintian_fixers
> check_clean_tree(local_tree, basis_tree, subpath)
>   File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 778, 
> in check_clean_tree
> changes = local_tree.iter_changes(
>   File "/usr/lib/python3/dist-packages/breezy/tree.py", line 269, in 
> iter_changes
> return intertree.iter_changes(include_unchanged, specific_files, pb,
>   File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 971, in 
> iter_changes
> changes, target_extras = self._iter_git_changes(
>   File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1622, in 
> _iter_git_changes
> return changes_between_git_tree_and_working_copy(
>   File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1643, in 
> changes_between_git_tree_and_working_copy
> for path, index_entry in target._recurse_index_entries():
>   File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1266, in 
> _recurse_index_entries
> (ctime, mtime, dev, ino, mode, uid, gid, size, sha,
>   ValueError: too many values to unpack (expected 10)

lintian-brush crashes always using last version in a testing dist

Bug#994434: mypy: new upstream version (0.910) available

[Daniel Kahn Gillmor]

Package: mypy
Version: 0.812-1
Severity: wishlist

Dear Maintainer,

back in June, mypy upstream released 0.910:

https://mypy-lang.blogspot.com/2021/06/mypy-0910-released.html

note that this includes a switch to modular typeshed, as referenced here:


https://mypy-lang.blogspot.com/2021/05/the-upcoming-switch-to-modular-typeshed.html

it'd be great to have the most recent mypy available in debian.

thanks for maintaining mypy!

   --dkg

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

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

Versions of packages mypy depends on:
ii  python3   3.9.2-3
ii  python3-mypy  0.812-1

mypy recommends no packages.

Versions of packages mypy suggests:
ii  mypy-doc  0.812-1

-- no debconf information

Bug#964221: googletest: meson support

[Steven Robbins]

> > It's a reasonable request.  Where in the filesystem would you like to see 
these 
> > three files?
> 
> The wrap is pretty specific in that googletest and googlemock have to be
> subdirectories. So effectively the wrap is unzipped today at the
> /usr/src/googletest level - which seems very reasonable to me as it
> mimics the existing CMakeLists.txt layout as well.

You may have noticed its almost a year later and I did not address this bug.  
:-(

I just packaged new googletest 1.11.0.  I did look for a meson wrap but was 
not successful.  The wrap files for 1.10 are pretty simple and I thought about 
just blindly using them -- but I don't want to be guessing.  Do you have a 
suggestion on how to test this meson-wrapped gtest?

-Steve


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

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Sandro Tosi]

> I've moved the package under the games-team [1]. I was going to give you
> access to it but I can't find a Salsa account for you. If you don't have an
> account yet, you can easily create one [2] and let me know your username.
> I'll then give you access to the repository and you can make all of your
> changes. Once you're happy with it, I'll review and upload. Let me know if
> you have any questions!

what's the hold up with the upload? it's been moved to the games team
more than a year ago, it's under that team maintenance, so please
proceed asap with an upload to fix this RC bug

Bug#994085: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#994085: fixed in wireplumber 0.4.2-5)

[duck]

Quack,

It works great, thank you.

\_o<

--
Marc Dequènes

Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Steven Robbins]

On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote:

> Control: tags 994419 + ftbfs

I thought this tag was for the case that the package fails to build from 
source. ??  https://www.debian.org/Bugs/Developer


> I just noticed that this bug not only breaks autopkgtest 

What autopkgtest?  I don't think googletest has one.

> but also causes fastcdr to FTBFS.

I can't reproduce this.  I used "apt source fastcdr" to get the 1.0.21-2 
sources and they built fine.

Can you provide explicit instructions on reproducing the issue, please?

Best,
-Steve

Bug#993832: synfig FTBFS with mlt 7

[peter green]

Tags 993832 +patch
thanks

I found a fix in the upstream git repo and was able to apply it to the Debian
package and build sucessfully in raspbian bookworm-staging. A debdiff is
available at 
https://debdiffs.raspbian.org/main/s/synfig/synfig_1.4.0+dfsg-2+rpi1.debdiff
no intent to NMU in Debian.

Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Steven Robbins]

On Wednesday, September 15, 2021 2:25:49 P.M. CDT Timo Röhling wrote:
> Package: libgtest-dev
> Version: 1.10.0.20201025-1.1

I've discovered that upstream has released 1.11 -- which I'll package up.  

> the GTestTargets.cmake that is shipped in libgtest-dev also exports
> the GTest::gmock and GTest::gmock_main targets. However, the
> corresponding libraries libgmock.a and libgmock_main.a are shipped
> in libgmock-dev. This causes a fatal error and prevents successful
> CMake configuration in dependent projects.

Do you have a minimal reproduction by any chance?  I'd like to test out 1.11 
-- just in case it fixes the problem.

Thanks,
-Steve

Bug#994426: octave-sparsersb: flaky autopkgtest on ci.d.n armhf worker

[Michele Martone]

On 20210915@22:12, Paul Gevers wrote:
> Source: octave-sparsersb
> Version: 1.0.8-3
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: flaky timesout
> 
> Dear maintainer(s),
> 
> I looked at the results of the autopkgtest of you package on armhf
> because with a recent upload of glibc the autopkgtest of
> octave-sparsersb fails in testing. In august 2021, we replaced the host
> we were using for armhf testing for a new one. Since then, the
> autopkgtest has been failing most of the times, due to it timing out. We
> should get this fixed. Do you have any ideas what could be the root
> cause of this?
> 
> Ironically, the passing tests (since the new host) report a segfault
> and: Summary: 0 tests, 0 passed, 0 known failures, 0 skipped
> 
> Don't hesitate to contact us at debian...@lists.debian.org if you need
> help debugging this issue.
> 
> Paul
> 
> https://ci.debian.net/packages/o/octave-sparsersb/testing/armhf/
> 
> https://ci.debian.net/data/autopkgtest/testing/armhf/o/octave-sparsersb/14991286/log.gz
> 
> * test
>  a=sparsersb(sprand(100,100,0.4));
>  nrhs=1;
>  maxr=1;
>  tmax=1;
>  tn=2;
>  sf=1;
>  o=sparsersb(a,"autotune","n",nrhs,maxr,tmax,tn,sf);
>  assert(o==a)
> librsb error:The requested feature (e.g.:blocking) is not available
> because it was opted out or not configured at built time.
> librsb error:The requested feature (e.g.:blocking) is not available
> because it was opted out or not configured at built time.
> ! test failed
> index (_,0,_): subscripts must be either integers 1 to (2^31)-1 or logicals
> ...

Dear Paul,

The problem seems librsb-sided.

Assuming librsb fails at detecting cache memory size, maybe can you
first export e.g.
  RSB_USER_SET_MEM_HIERARCHY_INFO="L2:4/64/512K,L1:8/64/32K" 
and see if this avoids that?
Same with 
  OMP_NUM_THREADS=1
explicitly?

Maybe you send me outputs of  `rsbench -C` and `rsbench -I` ?

If I had a guest account to such an armhf machine it would be a bit
easier.

Cheers,
Michele

Bug#994433: ncurses-term: Is it necessary to take over terminfo entries (jfbterm, kon2...)?

[Steven Shiau]

Package: ncurses-term
Version: 6.2+20210905-1
Severity: normal

Dear Maintainer,

In ncurses-term 6.2+20210905-1, the terminfo entries from the deceased
Debian packages
jfbterm, kon2, libiterm1 and tn5250 were taken over. However, is it
really necessary?
Because this will cause conflict if we want to install the package
jfbterm, for example.
Although jfbterm is not maintained by Debian anymore, but it's still
available:
https://src.fedoraproject.org/rpms/jfbterm/
We can easily package it and install it on Debian.
However, with ncurses-term 6.2+20210905-1, it conflicts with
the original jfbterm in the file "/usr/share/terminfo/j/jfbterm".
If there is no jfbterm on the Debian system, then we do not need the
terminfo /usr/share/terminfo/j/jfbterm.
However, when we need it, and install it, this existing
/usr/share/terminfo/j/jfbterm from
ncurses-term 6.2+20210905-1 will make the install fail.
Therefore, it seems to be more reasonable to remove those terminfo files?
My 2 cents.

Steven

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

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

Versions of packages ncurses-term depends on:
ii  ncurses-base  6.2+20210905-1

ncurses-term recommends no packages.

ncurses-term suggests no packages.

-- no debconf information

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#994432: qa.debian.org: please show watch file errors

[Adam Borowski]

Package: qa.debian.org
Severity: wishlist


Hi!
If the watch file fails to return any versions (usu. due to changes on
the remote server), the result is shown as "-", same as if there was
no watch file.

This is an error that should be at least pointed out to the maintainer;
the PTS (tracker.debian.org) even labels it a "high" priority problem.

Thus, what about a nice red "ERROR" instead?

Bug#994420: RFS: opendnssec/1:2.1.10-1 -- dependency package to install full OpenDNSSEC suite

[Mat]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendnssec
   Version : 1:2.1.10-1
 * URL : https://www.opendnssec.org/
 * License : OLD-BSD, BSD-IBM-ISC, BSD-2-clause, GPL-2
 * Vcs : https://salsa.debian.org/debian/opendnssec
   Section : admin

It builds those binary packages:

  opendnssec-common - common configuration files for OpenDNSSEC suite
  opendnssec - dependency package to install full OpenDNSSEC suite
  opendnssec-doc - documentation for OpenDNSSEC suite
  opendnssec-enforcer - tool to prepare DNSSEC keys (common package)
  opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (MySQL
  backend)
  opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3
  backend)
  opendnssec-signer - daemon to sign DNS zone files periodically
  libhsm-bin - library for interfacing PKCS#11 Hardware Security
  Modules

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

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

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/o/opendnssec/opendnssec_2.1.10-1.dsc

Changes since the last upload:

 opendnssec (1:2.1.10-1) unstable; urgency=medium
 .
   * New upstream version 2.1.10
   * control: bump policy to 4.6.0, no code change
   * lintian-overrides: remove obsolete overrides

Regards,


-- 
Mat 


signature.asc
Description: Digital signature

Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Steven Robbins]

On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote:

> > Please add Depends: libgmock-dev to libgtest-dev.
> 
> I just noticed that this bug not only breaks autopkgtest but also
> causes fastcdr to FTBFS.
> 
> In case you're wondering, apparently this bug has been exposed by
> the changes in the new CMake version that has hit unstable, so this
> will possibly affect more packages.

Intriguing.  Note that gtest is intended as the base layer (gmock is built on 
top of gtest), so it would be a loss to have libgtest-dev pull in gmock.  
Hopefully there's an alternative fix.

-Steve


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

Bug#994259: [Debian-med-packaging] Bug#994259: resfinder: autopkgtest regression on armhf and i386: db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1

[Étienne Mollier]

Hi Paul,

Paul Gevers, on 2021-09-15:
> On 15-09-2021 18:51, Étienne Mollier wrote:
> > I intend to adjust the d/tests/control Architecture field of
> > resfinder to match the (pending upload) list of architectures
> > supported by kma.  Would this be sufficient to bring back
> > resfinder to testing, or is there some knob to twiddle on CI end
> > to make sure the absence of test is not a regression anymore?
> 
> If resfinder depends on kma, then britney (the Release Team migration
> software) *should* do the right thing. But it probably has a bug in this
> area. So either you add the Architecture field and be done with it (for
> now) or we override it on the Release Team side of things until britney
> is fixed.

Thanks for your explanation!

I prepare uploads to unstable, so architecture specifications in
kma and resfinder match the reality of the field (in d/control
and d/tests/control respectively).  Besides, it should make the
current situation a wee bit clearer for human beings, such as
future self.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#994431: Some debugging information

[Daniel Leidert]

Hi,

I did some debugging. The cause seems to be in parse_href() in
/usr/share/perl5/Devscripts/Uscan/http.pm.

This code (else part) adds the dot:

> if ($self->versionless) {
> 
> # exception, otherwise $mangled_version = 1
> $mangled_version = '';
> } else {
> $mangled_version = join(".",
> map { $_ if defined($_) }
>   ref $match eq 'ARRAY' ? @$match : $href =~ m&^$_pattern$&);
> }
> 

And this is due to me using a parenthesis within the parenthesis:

([0-9]+(-hf[0-9]*)?)

I now changed that to

([0-9]+(?:-hf[0-9]*)?)

and this seems to work.

I might have caught a corner case here. I mean the second match is empty and
shouldn't be added. But if that is intentional, please feel free to close this
report.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Bernhard Übelacker]

Hello Florence, dear Maintainer,

  
  Stack trace of thread 113079:

  #0  0x7f858b12ae71 raise 
(libc.so.6 + 0x3ce71)
  #1  0x7f858b114536 abort 
(libc.so.6 + 0x26536)
  #2  0x7f858b16c2b8 n/a 
(libc.so.6 + 0x7e2b8)
  #3  0x7f858b1fad42 
__fortify_fail (libc.so.6 + 0x10cd42)
  #4  0x7f858b1fad20 
__stack_chk_fail (libc.so.6 + 0x10cd20)
  #5  0x7f857c763146 
get_size (libsane-hpaio.so.1 + 0x14146)
  #6  0x n/a 
(n/a + 0x0)



Thanks for the fast response.
From looking at this stack trace I assume a stack variable in
function "get_size" gets overwritten. At the end of this function
the stack check gets triggered.

From looking at [1] I _think_ the issue might be with the
variable "char buffer[7]".
It looks like this buffer gets some hexadecimal size
information written to from a http connection.

Therefore my hypothesis is that either this "size" exceeds what
is with these 7 places possible (would be 268 MB ?),
or some unexpected input is read from the connection and
therefore the loop is not left before the buffer is overrun.

One easy thing might be to test if the resolution could be
changed to some lower value in the hope to get this "size" to
a lower value, does the scan then succeed ?

Kind regards,
Bernhard



[1] 
https://sources.debian.org/src/hplip/3.21.6+dfsg0-1/scan/sane/bb_ledm.c/#L1086
1084
1085int get_size(struct ledm_session* ps)
1086{
1087  struct bb_ledm_session *pbb = ps->bb_session;
1088  char buffer[7];
1089  int i=0, tmo=50, len;
1090
1091  if(ps->currentResolution >= 1200) tmo *= 5;
1092
1093  while(1)
1094  {
1095if(http_read_size(pbb->http_handle, buffer+i, 1, tmo, ) == 
2) return 0;
1096if( i && *(buffer+i) == '\n' && *(buffer+i-1) == '\r') break;
1097i++;
1098  }
1099  *(buffer+i+1)='\0';
1100  return strtol(buffer, NULL, 16);
1101}
1102

[2] https://sources.debian.org/src/hplip/3.21.6+dfsg0-1/scan/sane/http.c/#L513

# Bullseye/stable amd64 qemu VM 2021-09-15


echo "set enable-bracketed-paste off" >> /etc/inputrc; bash


apt update
apt dist-upgrade

apt install mc gdb simple-scan hplip
apt install simple-scan-dbgsym libsane-hpaio-dbgsym
apt build-dep libsane-hpaio



mkdir /home/benutzer/source/libsane-hpaio/orig -p
cd/home/benutzer/source/libsane-hpaio/orig
apt source libsane-hpaio
cd






benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/simple-scan
Reading symbols from /usr/bin/simple-scan...
Reading symbols from 
/usr/lib/debug/.build-id/31/8e835860dafff5fa45c03cb758e8cae5a11fa0.debug...
(gdb) tb main
Temporary breakpoint 1 at 0xe160: file src/simple-scan.p/simple-scan.c, line 
2434.
(gdb) run
Starting program: /usr/bin/simple-scan 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe618) at 
src/simple-scan.p/simple-scan.c:2434
2434src/simple-scan.p/simple-scan.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1",0x102)
$1 = (void *) 0x555da300
(gdb) b get_size
Breakpoint 2 at 0x73618080: file scan/sane/bb_ledm.c, line 1086.
(gdb) disassemble get_size,get_size+200
Dump of assembler code from 0x73618080 to 0x73618148:
   0x73618080 : push   %r15
   0x73618082 : push   %r14
   0x73618084 : push   %r13
   0x73618086 : push   %r12
   0x73618088 : mov$0x32,%r12d
   0x7361808e :push   %rbp
   0x7361808f :push   %rbx
   0x73618090 :sub$0x28,%rsp
   0x73618094 :mov0x89b0(%rdi),%r15
   0x7361809b :mov%fs:0x28,%rax
   0x736180a4 :mov%rax,0x18(%rsp)
   0x736180a9 :xor%eax,%eax
   0x736180ab :lea0x11(%rsp),%r13
   0x736180b0 :mov$0xfa,%eax
   0x736180b5 :cmpl   $0x4b0,0x744(%rdi)
   0x736180bf :cmovge %eax,%r12d
   0x736180c3 :mov%r13,%rbx
   0x736180c6 :lea0xc(%rsp),%r14
   0x736180cb :xor%ebp,%ebp
   0x736180cd :jmp0x736180d8 
   0x736180cf :nop
   0x736180d0 :add$0x1,%rbp
   0x736180d4 :add$0x1,%rbx
   0x736180d8 :mov0x1f0(%r15),%rdi
   0x736180df :mov%r14,%r8
   

Bug#994412: Not easy to remove dummy package cleanly

[David Bremner]

Control: tag -1 moreinfo

積丹尼 Dan Jacobson  writes:

> Package: debian-el
> Version: 37.10
>
> When I try to remove this dummy package, aptitude says
> The following packages will be REMOVED:
>   debian-el{p}  elpa-debian-el{pu} (D: debian-el)
>
> But other dummy packages don't trigger this in aptitude.

I couldn't duplicate this with aptitude or with apt. Can you give a
recipe for reproducing the problem in a clean system?

d

Bug#994430: codeblocks debugging windows

[sfl]

Debugging windows have the expected behavior when codeblocks is running on
X.org.

Steven

Bug#994431: uscan: Weird version result

[Daniel Leidert]

Package: devscripts
Version: 2.21.4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have a problem. I get a weird version number from uscan. This number should
be impossible based on the regex I use. A regex tester also doesn't lead to
this result. I'm thinking that there might be some issue in uscan.

This is the watch file:

version=4
opts=uversionmangle=s%-(hf\d+?)%+$1% \
 http://www.travis-analyzer.de/downl.php 
files/@PACKAGE@-src-([0-9]+(-hf[0-9]*)?)@ARCHIVE_EXT@


This is the result:

$filepattern = 
files/travis-src-([0-9]+(-hf[0-9]*)?)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz))
 found
$newfile = http://www.travis-analyzer.de/files/travis-src-210521.tar.gz
$newversion  = 210521.
$lastversion = 200504+hf2

Where is the dot coming from in the new version? I get this dot with and
without @ARCHIVE_EXT@. But the version regex shouldn't catch any dots?!

Regards, Daniel


- -- Package-specific info:

- --- /etc/devscripts.conf ---
Empty.

- --- ~/.devscripts ---
DEBSIGN_KEYID='BEED4DED5544A4C03E283DC74BCD0567C296D05D'
DEBUILD_LINTIAN='yes'
DEBUILD_LINTIAN_OPTS="-i -I -E --pedantic"
DEBCHANGE_RELEASE_HEURISTIC='changelog'
BTS_SMTP_HOST='smtps://mail.wgdd.de'

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.9
ii  fakeroot  1.26-1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.32-3
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-2
ii  libwww-perl   6.53-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-5
ii  python3   3.9.2-3
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.9
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.07.26
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.0
ii  libdpkg-perl1.20.9
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.08-1
ii  licensecheck3.2.11-1
ii  lintian 2.106.1
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.2.1
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.20-3
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21-1+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
ii  adequate 0.15.6
ii  at   3.1.23-1.1
ii  autopkgtest  5.16
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.5.1
pn  devscripts-el
ii  diffoscope   183
ii  disorderfs   0.5.11-1
pn  dose-extra   
pn  duck 
ii  faketime 0.9.8-9
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
ii  libnet-smtps-perl0.10-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.13-1
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:8.4p1-6
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
ii  quilt  

Bug#994430: codeblocks: Debugging windows no longer movable on screen.

[Steven Lochner]

Package: codeblocks
Version: 20.03-3
Severity: normal
X-Debbugs-Cc: sfl1...@gmail.com

Dear Maintainer,

Replicate: Open any of the debugging windows, open the "watches" window for
example. The "watches" window appears near the upper left corner. Click on the
title bar and drag to another screen location.

Expected behavior: window can be moved to another screen location.
Observed behavior: window cannot be moved. Note: Debugging windows in
codeblocks 20.03 in Debian 10 do not have this problem.

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

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

Versions of packages codeblocks depends on:
ii  codeblocks-common 20.03-3
ii  libastyle33.1-2+b1
ii  libc6 2.31-13
ii  libcodeblocks020.03-3
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libstdc++610.2.1-6
ii  libtinyxml2.6.2v5 2.6.2-4
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2

Versions of packages codeblocks recommends:
ii  g++4:10.2.1-1
ii  gcc4:10.2.1-1
ii  gdb10.1-1.7
ii  xterm  366-1

Versions of packages codeblocks suggests:
ii  codeblocks-contrib  20.03-3
pn  libwxgtk3.0-dev 

Bug#830138: pssh: please split psshutil and provide a python3 package

[Hilmar Preuße]

Am 15.09.2021 um 20:36 teilte Sandro Tosi mit:

On Wed, Sep 15, 2021 at 2:35 PM Hilmar Preuße  wrote:

Am 06.07.2016 um 13:45 teilte Sandro Tosi mit:


Hi Sandro,


pssh provides both a python module and a program in the same binary
package. Please split the python module in a separate package and
provide a python3 version of it.


The pssh has been ported to python3 in the meantime. Which part of the
package should be spilt into a new package? The part below
"/usr/lib/python3/dist-packages/psshlib/" ?


yes, that's what a python module is



It is 
https://salsa.debian.org/python-team/packages/pssh/-/commit/69802257d294d47a5910594f6d995dfb82438f17


Let me know if I missed anything.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#950366: fswatch: diff for NMU version 1.14.0+repack-13.1

[Boyuan Yang]

Control: tags -1 +pending +patch

Dear maintainer,

I've prepared an NMU for fswatch (versioned as 1.14.0+repack-13.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru fswatch-1.14.0+repack/debian/changelog fswatch-
1.14.0+repack/debian/changelog
--- fswatch-1.14.0+repack/debian/changelog  2019-10-26 10:38:15.0
-0400
+++ fswatch-1.14.0+repack/debian/changelog  2021-09-15 17:44:32.0
-0400
@@ -1,3 +1,15 @@
+fswatch (1.14.0+repack-13.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/rules: Correctly use DEB_HOST_MULTIARCH for libdir.
+(Closes: #950366)
+  * debian/patches/0001-autoconf2.70-compat.patch: Add upstream
+patch to fix FTBFS with autoconf 2.70+. (Closes: #978813)
+  * debian/gbp.conf: Drop custom compression format. This causes
+errors during building. Implicitly use default format instead.
+
+ -- Boyuan Yang   Wed, 15 Sep 2021 17:44:32 -0400
+
 fswatch (1.14.0+repack-13) unstable; urgency=medium
 
   * Made libfswatch a private library (Closes: #939382)
diff -Nru fswatch-1.14.0+repack/debian/gbp.conf fswatch-
1.14.0+repack/debian/gbp.conf
--- fswatch-1.14.0+repack/debian/gbp.conf   2019-10-26 10:36:05.0
-0400
+++ fswatch-1.14.0+repack/debian/gbp.conf   2021-09-15 17:44:29.0
-0400
@@ -2,5 +2,3 @@
 debian-branch = debian/sid
 upstream-branch = upstream/latest
 pristine-tar = True
-compression = gz
-
diff -Nru fswatch-1.14.0+repack/debian/patches/0001-autoconf2.70-compat.patch
fswatch-1.14.0+repack/debian/patches/0001-autoconf2.70-compat.patch
--- fswatch-1.14.0+repack/debian/patches/0001-autoconf2.70-compat.patch 1969-
12-31 19:00:00.0 -0500
+++ fswatch-1.14.0+repack/debian/patches/0001-autoconf2.70-compat.patch 2021-
09-15 17:40:41.0 -0400
@@ -0,0 +1,22 @@
+From: Boyuan Yang 
+Date: Wed, 15 Sep 2021 17:40:05 -0400
+Subject: autoconf2.70 compat
+
+Applied-Upstream:
https://github.com/emcrisostomo/fswatch/commit/c662b50ad25db990cc44b3fb03a7194ea81d6304
+Bug-Debian: https://bugs.debian.org/978813
+---
+ configure.ac | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 74af94d..7c87e07 100644
+--- a/configure.ac
 b/configure.ac
+@@ -34,7 +34,6 @@ AC_CONFIG_FILES([fswatch/Makefile fswatch/src/Makefile
fswatch/doc/Makefile])
+ AC_CONFIG_FILES([po/Makefile.in])
+ AC_CONFIG_FILES([man/fswatch.7])
+ AC_CONFIG_MACRO_DIRS([m4])
+-AC_CONFIG_MACRO_DIR([m4])
+ 
+ # Compute the canonical target-system type variables
+ AC_CANONICAL_TARGET
diff -Nru fswatch-1.14.0+repack/debian/patches/series fswatch-
1.14.0+repack/debian/patches/series
--- fswatch-1.14.0+repack/debian/patches/series 1969-12-31 19:00:00.0
-0500
+++ fswatch-1.14.0+repack/debian/patches/series 2021-09-15 17:40:41.0
-0400
@@ -0,0 +1 @@
+0001-autoconf2.70-compat.patch
diff -Nru fswatch-1.14.0+repack/debian/rules fswatch-
1.14.0+repack/debian/rules
--- fswatch-1.14.0+repack/debian/rules  2019-10-26 10:36:05.0 -0400
+++ fswatch-1.14.0+repack/debian/rules  2021-09-15 17:37:31.0 -0400
@@ -13,7 +13,7 @@
 override_dh_auto_configure:
dh_auto_configure -- \
--enable-static=no \
-   --libdir=/usr/lib/$(DEB_HOST_GNU_TYPE)/libfswatch
+   --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/libfswatch
 
 override_dh_install:
find debian -type d -name doc | xargs rm -rvDear maintainer,

I've prepared an NMU for fswatch (versioned as 1.14.0+repack-13.1) and
uploaded it to DELAYED/XX. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru fswatch-1.14.0+repack/debian/changelog fswatch-
1.14.0+repack/debian/changelog
--- fswatch-1.14.0+repack/debian/changelog  2019-10-26 10:38:15.0
-0400
+++ fswatch-1.14.0+repack/debian/changelog  2021-09-15 17:44:32.0
-0400
@@ -1,3 +1,15 @@
+fswatch (1.14.0+repack-13.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/rules: Correctly use DEB_HOST_MULTIARCH for libdir.
+(Closes: #950366)
+  * debian/patches/0001-autoconf2.70-compat.patch: Add upstream
+patch to fix FTBFS with autoconf 2.70+. (Closes: #978813)
+  * debian/gbp.conf: Drop custom compression format. This causes
+errors during building. Implicitly use default format instead.
+
+ -- Boyuan Yang   Wed, 15 Sep 2021 17:44:32 -0400
+
 fswatch (1.14.0+repack-13) unstable; urgency=medium
 
   * Made libfswatch a private library (Closes: #939382)
diff -Nru fswatch-1.14.0+repack/debian/gbp.conf fswatch-
1.14.0+repack/debian/gbp.conf
--- fswatch-1.14.0+repack/debian/gbp.conf   2019-10-26 10:36:05.0
-0400
+++ fswatch-1.14.0+repack/debian/gbp.conf   2021-09-15 17:44:29.0
-0400
@@ -2,5 +2,3 @@
 debian-branch = debian/sid
 upstream-branch = upstream/latest
 pristine-tar = True
-compression = gz
-
diff -Nru fswatch-1.14.0+repack/debian/patches/0001-autoconf2.70-compat.patch

Bug#963890: libopencv-contrib4.2: circular dependency with libopencv-superres4.2

[Nobuhiro Iwamatsu]

Version: 4.5.3+dfsg-1

Hi,

This issue has been fixed in 4.5.3+dfsg-1.

$ apt-cache show libopencv-superres4.5 | grep -e "^Version:" -e "^Depends:"
Version: 4.5.3+dfsg-1+b1
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libopencv-contrib4.5 (>= 
4.5.3+dfsg), libopencv-core4.
5 (>= 4.5.3+dfsg), libopencv-imgproc4.5 (>= 4.5.3+dfsg), libopencv-video4.5 (>= 
4.5.3+dfsg), libopen
cv-videoio4.5 (>= 4.5.3+dfsg), libstdc++6 (>= 5.2)

$ apt-cache show libopencv-contrib4.5 | grep -e "^Version:" -e "^Depends:"
Version: 4.5.3+dfsg-1+b1
Depends: libc6 (>= 2.29), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 4.0), 
libharfbuzz0b (>= 0.9.9), lib
hdf5-103-1, libopencv-calib3d4.5 (>= 4.5.3+dfsg), libopencv-core4.5 (>= 
4.5.3+dfsg), libopencv-dnn4.
5 (>= 4.5.3+dfsg), libopencv-features2d4.5 (>= 4.5.3+dfsg), libopencv-flann4.5 
(>= 4.5.3+dfsg), libo
pencv-highgui4.5 (>= 4.5.3+dfsg), libopencv-imgcodecs4.5 (>= 4.5.3+dfsg), 
libopencv-imgproc4.5 (>= 4
.5.3+dfsg), libopencv-ml4.5 (>= 4.5.3+dfsg), libopencv-objdetect4.5 (>= 
4.5.3+dfsg), libopencv-video
4.5 (>= 4.5.3+dfsg), libstdc++6 (>= 9), libtesseract4

Best regards,
  Nobuhiro

On Sun, 28 Jun 2020 17:47:49 +0200 Bill Allombert  wrote:
> Package: libopencv-contrib4.2
> Version: 4.2.0+dfsg-6+b1
> Severity: important
> 
> Hello Debian Science Team,
> 
> There is a circular dependency between libopencv-contrib4.2 and 
> libopencv-superres4.2:
> 
> libopencv-contrib4.2  :Depends: libopencv-superres4.2 (= 4.2.0+dfsg-6+b1)
> libopencv-superres4.2 :Depends: libopencv-contrib4.2 (>= 4.2.0+dfsg)
> 
> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 
> 

Bug#994422: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c /usr/share/cmake-3.16/Modules/CMakeCXXCompilerABI.cpp

[Eriberto Mota]

Complementing, my local build jail uses  /usr/bin/c++, but Salsa uses
/usr/lib/ccache/c++. Consequently, my current rule in debian/rules is:

@echo 'blhc: ignore-line-regexp: /usr/(bin|lib)/(ccache/)?c\+\+ -dM -E
-c /usr/share/cmake-[0-9.]+/Modules/CMakeCXXCompilerABI.cpp .*'

Regards,

Eriberto

Bug#994429: gimp: missing SANE option under File > Create menu

[Eric Cooper]

Package: gimp
Version: 2.10.26-1
Severity: normal

I have both xsane and xsane-common installed, but there is no longer
an option to use SANE under the Create menu.

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.26-1
ii  graphviz 2.42.2-5
ii  libaa1   1.4p5-50
ii  libbabl-0.1-01:0.1.88-1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s111.2.0-4
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libgegl-0.4-01:0.4.32-1
ii  libgexiv2-2  0.12.1-1
ii  libgimp2.0   2.10.26-1
ii  libglib2.0-0 2.68.4-1
ii  libgs9   9.53.3~dfsg-7+b1
ii  libgtk2.0-0  2.24.33-2
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b2.7.4-1
ii  libheif1 1.12.0-2+b1
ii  libilmbase25 2.5.7-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.12~rc1-2
ii  liblzma5 5.2.5-2
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.48.9+ds1-2
ii  libpangocairo-1.0-0  1.48.9+ds1-2
ii  libpangoft2-1.0-01.48.9+ds1-2
ii  libpng16-16  1.6.37-3
ii  libpoppler-glib8 20.09.0-3.1
ii  librsvg2-2   2.50.3+dfsg-1
ii  libstdc++6   11.2.0-4
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2.1
ii  libwebpdemux20.6.1-2.1
ii  libwebpmux3  0.6.1-2.1
ii  libwmf0.2-7  0.2.8.4-17+b1
ii  libx11-6 2:1.7.2-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages gimp recommends:
ii  ghostscript  9.53.3~dfsg-7+b1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gvfs-backends 
ii  libasound21.2.5.1-1

-- no debconf information

Bug#994392: blender: Color management settings missing

[Matteo F. Vescovi]

Hi Mikko!

On 2021-09-15 at 15:24 (+03), Mikko Rasa wrote:
> Blender 2.93.4 is missing most options in color management settings.
> I only have "sRGB" for display device, "Standard" for view transform,
> "None" for look and "sRGB" and "Linear" for sequencer.
> A build downloaded from blender.org shows all of the options, so it
> seems Debian's build is incorrectly configured somehow.

Digging in the build logs[1] you'll find something like:

= = = = >8 = = = =
-- Could NOT find OpenColorIO: Found unsuitable version "1.1.1", but
-- required is at least "2.0.0"
-- (found /usr/lib/libOpenColorIO.so;/usr/lib/x86_64-linux-gnu/libexpat.so)
-- OpenColorIO not found
= = = = >8 = = = =

OpenColorIO is still at 1.1.1 in Debian, in fact. And OCIO library is 
responsible for color management in Blender, as you can see at [2].

Now, even if I've tried to spend some time on packaging the 2.x.y version
actually I'm still failing badly due to external requests (that is, more
libraries or tools not packaged in Debian yet) for the package to build.

Hope this helps to understand the problem.

Cheers.

mfv


[1] 
https://buildd.debian.org/status/fetch.php?pkg=blender=amd64=2.93.4%2Bdfsg-1=1630968330=0
[2] https://docs.blender.org/manual/en/latest/render/color_management.html
-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#994428: mirror submission for mirrors.sonic.net

[Sonic.net]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.sonic.net
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 ppc64el s390x
Archive-http: /debian/
Maintainer: Sonic.net 
Country: US United States
Location: Santa Rosa, CA
Sponsor: Sonic. https://www.sonic.com/




Trace Url: http://mirrors.sonic.net/debian/project/trace/
Trace Url: http://mirrors.sonic.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sonic.net/debian/project/trace/mirrors.sonic.net

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Florence Birée]

Hi Bernhard,

Here is the stack trace (scanning with simple-scan):

sept. 15 18:55:47 lyra systemd[1]: Created slice Slice /system/systemd-coredump.
sept. 15 18:55:47 lyra systemd[1]: Started Process Core Dump (PID 113128/UID 0).
sept. 15 18:55:48 lyra systemd-coredump[113129]: [] Process 113052 
(simple-scan) of user 1000 dumped core.
 
 Stack trace of thread 113079:
 #0  0x7f858b12ae71 raise 
(libc.so.6 + 0x3ce71)
 #1  0x7f858b114536 abort 
(libc.so.6 + 0x26536)
 #2  0x7f858b16c2b8 n/a 
(libc.so.6 + 0x7e2b8)
 #3  0x7f858b1fad42 
__fortify_fail (libc.so.6 + 0x10cd42)
 #4  0x7f858b1fad20 
__stack_chk_fail (libc.so.6 + 0x10cd20)
 #5  0x7f857c763146 
get_size (libsane-hpaio.so.1 + 0x14146)
 #6  0x n/a 
(n/a + 0x0)
sept. 15 18:55:48 lyra systemd[1]: systemd-coredump@0-113128-0.service:
Succeeded.

I hope it will be useful!

Cheers,
Florence

Le Mon, 13 Sep 2021 18:11:40 +0200,
Bernhard Übelacker  a écrit :

> Hello Florence,
> there might be still something that could be done
> to retrieve some more information (if you have still
> the versions installed that show the issue).
> 
> The easiest first thing might be to install the package
> systemd-coredump, if possible.
> 
> Then open in another terminal 'journalctl -f'.
> 
> And reproduce one of the "stack smashings".
> 
> Then in the other terminal a "Stack trace" should appear - this
> should point out the library and maybe function where the issue is.
> 
> Kind regards,
> Bernhard



-- 
Florence Birée (elle)
06 52 92 15 32

En ces temps d'état policier, ne les laissons pas lire nos mails,
chiffrons-les ! https://emailselfdefense.fsf.org/fr/index.html


pgpjGcr7JVD1M.pgp
Description: Signature digitale OpenPGP

Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade

[Colin Watson]

On Fri, Sep 10, 2021 at 09:59:44PM +0200, Aurelien Jarno wrote:
> On 2021-09-10 20:39, Colin Watson wrote:
> > On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote:
> > > I gave a try with debconf-show instead. I have attached a totally
> > > untested patch to check that we agree on the way to do it.
> > 
> > I think you forgot to attach the patch?
> 
> Dooh. Please find a new version attached.

The general idea of this looks good to me.  I've left some detailed
review comments below, and IMO we should test it against my reproducer
(especially since this preinst patch needs to end up in bullseye).

> > I managed to reproduce the reported bug by taking Neil's full package
> > list, mangling it to roughly make sense on buster, installing all of
> > that, and then doing "apt upgrade && apt full-upgrade" (my own habit is
> > just to do "apt full-upgrade", but in this case the initial "apt
> > upgrade" is crucial).  I'm now trying to more or less bisect the package
> > list to find something rather more minimal; this is a slow process, but
> > no roadblocks so far, and I'll let you know when I have something.
> 
> Thanks a lot for your help.

OK, it took much longer than I expected because I wasn't able to do it
by just bisecting the package list, but here's a reproducer.  I ran this
in a fresh container produced by "lxc launch images:debian/buster"; I
expect other container tools can be made to exhibit this too, though it
may be sensitive to exactly which packages are in the base image.

  # apt update && apt -y install gimp libc6-dev postgresql whiptail
  # cat >/etc/apt/sources.list  diff --git a/debian/debhelper.in/libc.preinst 
> b/debian/debhelper.in/libc.preinst
> index d679db4f..e7808a44 100644
> --- a/debian/debhelper.in/libc.preinst
> +++ b/debian/debhelper.in/libc.preinst
> @@ -21,23 +21,22 @@ kfreebsd_compare_versions () {
>  
>  if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
>  then
> -# Load debconf module if available and usable
> +# Check if the debconf module is available and usable

I'd suggest initializing "USE_DEBCONF=" here to avoid potential
weirdness in case somebody happens to have that variable set in their
environment for some reason.

>  if [ -f /usr/share/debconf/confmodule ]; then
>  # cdebconf has a working fallback mechanism in case dialog
>  # is not usable, so do not try to do anything smart here
>  if [ "$DEBCONF_USE_CDEBCONF" ] ; then
> -. /usr/share/debconf/confmodule
>  USE_DEBCONF=1
>  # debconf requires perl
>  elif perl -e "" 2>/dev/null ; then
> -. /usr/share/debconf/confmodule
>  # Check that the selected frontend will work
>  if [ -n "$DEBIAN_FRONTEND" ] ; then
>  frontend="$DEBIAN_FRONTEND"
>  else
> -db_version 2.0
> -db_get debconf/frontend || RET="Dialog"
> -frontend="$RET"
> +# Query the frontend without first sourcing the confmodule 
> to avoid
> +# loosing control of the tty. This snipped must not be 
> copied blindly.

s/loosing/losing/, and s/snipped/snippet/.

> +frontend="$(echo 'GET debconf/frontend' | 
> debconf-communicate | sed '/^0 /!d;s/^0 //')"
> +frontend="${frontend:-Dialog}"
>  fi
>  frontend=`echo $frontend | tr '[:upper:]' '[:lower:]'`
>  case "$frontend" in
> @@ -61,6 +60,11 @@ then
>  fi
>  fi
>  
> +# Load debconf module if available and usable
> +if [ "$USE_DEBCONF" ]

This needs a "; then".

Thanks,

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

Bug#994259: [Debian-med-packaging] Bug#994259: resfinder: autopkgtest regression on armhf and i386: db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1

[Étienne Mollier]

Hi Paul,

Paul Gevers, on 2021-09-14:
> With a recent upload of resfinder the autopkgtest of resfinder fails in
> testing on armhf and i386 when that autopkgtest is run with the binary
> packages of resfinder from unstable. It passes when run with only
> packages from testing.

True, newer versions of resfinder are now using kma as a back
end, but it is not supported by upstream on 32bit architectures.
Actually the program insists to run on 64-bit, causing the error
in resfinder autopkgtest:

$ uname -m
i686
$ kma -h
Need a 64-bit system.
$ echo $?
1

A couple of removal requests are filed for 32-bit architectures
at the moment [1, 2], so packages depending on kma are not
available anymore on 32-bit platforms.  However, resfinder is
Architecture: all, so a removal request did not seem to make
much sense.

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

I intend to adjust the d/tests/control Architecture field of
resfinder to match the (pending upload) list of architectures
supported by kma.  Would this be sufficient to bring back
resfinder to testing, or is there some knob to twiddle on CI end
to make sure the absence of test is not a regression anymore?

Thank you for your ping!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#984066: irony-mode: ftbfs with GCC-11

[Nicholas D Steeves]

Control: tags + upstream fixed-upstream pending

Fixed upstream with a trivial one line fix:
  
https://github.com/Sarcasm/irony-mode/commit/ec6dce7ee16ffaa9a735204534aa4aa074d14487

Build log attached.


irony-mode_1.5.0-1~exp1_amd64.build.xz
Description: proof of ftbfs resolution with GCC-11

As uploads to bookworm are now open, I plan to upload directly to
unstable, minus the explicit GCC-11 dependency.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#994414: lintian(1) says --fails-on defaults to `error`, but looks like it's `none`

[Felix Lechner]

Hi Paride,

On Wed, Sep 15, 2021 at 11:36 AM Paride Legovini  wrote:
>
> It looks like there's a mismatch between the lintian manpage and the
> actual behavior.

Yeah, the current behavior is what I would like to see, but Lintian's
new approach to the exit status generated some controversy in the
past. At this point, I would simply like to change the documentation.
Would that work for you? What is your use case, please? Thank you!

Kind regards
Felix Lechner

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ole Tange]

On Mon, Sep 13, 2021 at 5:06 AM Sam Hartman  wrote:
:
> This seems clearly within the power Debian grants individual maintainers
> to either keep the citation notice or to remove it.

I hope my stance is clear:

I want to have an income from developing free software. The citation
notice indirectly gives me that. If you want to take away this without
paying me in a different way, I can only see that as an active hostile
action: You are threatening my livelihood.

Having GNU Parallel moved to non-free or not being distributed by
Debian at all is preferable to having my livelihood attacked.

Remember: I am not the enemy - I am the reason you have something to
package in the first place; so please don't behave like a dick - even
if what you intend to do might technically be legal.

I will be happy to work with anyone who understands this stance and
who wants to work to find a solution that everyone can accept. And
given I just want the citation notice shown to people who write
scientific articles, I really think we can find such a solution.


/Ole

Bug#994418: ocfs2-tools: failing autopkgtest on one of ci.d.n amd64 workers

[Valentin Vidic]

On Wed, Sep 15, 2021 at 09:24:08PM +0200, Paul Gevers wrote:
> I looked at the results of the autopkgtest of you package on amd64
> because with a recent upload of glibc the autopkgtest of ocfs2-tools
> fails in testing. It seems to me that the failures are related to the
> worker that the test runs on. ci-worker13 fails, while the other workers
> are OK. We recently changed the setup of ci-worker13, to have /tmp/ of
> the host on tmpfs as that speeds up testing considerably is a lot of
> cases. I copied some of the output at the bottom of this report, but I'm
> not 100% sure that the /tmp there (the one inside the lxc testbed) *is*
> on tmpfs.
> 
> Don't hesitate to contact us at debian...@lists.debian.org if you need
> help debugging this issue.
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocfs2-tools/15277216/log.gz
> 
> 
> autopkgtest [19:14:22]: test basic: [---
> 
> === disk ===
> 200+0 records in
> 200+0 records out
> 209715200 bytes (210 MB, 200 MiB) copied, 0.109005 s, 1.9 GB/s
> 
> === mkfs ===
> mkfs.ocfs2 1.8.6
> mkfs.ocfs2: Could not open device
> /tmp/autopkgtest-lxc.8neywhcx/downtmp/autopkgtest_tmp/disk: Invalid argument
> autopkgtest [19:14:23]: test basic: ---]

Yes, tmpfs seems to be the problem since it doesn't support O_DIRECT that
is being requested here:

static void
open_device(State *s)
{
s->fd = open64(s->device_name, O_RDWR | O_DIRECT);

if (s->fd == -1) {
com_err(s->progname, 0,
"Could not open device %s: %s",
s->device_name, strerror (errno));
exit(1);
}
}

-- 
Valentin

Bug#978831: patch gyoto for autoconf 2.70

[Étienne Mollier]

Control: tag -1 patch

Hi Thibaut,

Since version 2.70, autoreconf has become somewhat more picky
about the macro expansions, and they seem to need a bit more
protection.  I adjusted some parts of the configure.ac until it
fixed the configure process, in the patch in attachment.  (Maybe
not all changes of the patch are required, but it works as is.)

In hope this helps,
Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.
--- gyoto-1.4.4.orig/configure.ac
+++ gyoto-1.4.4/configure.ac
@@ -159,14 +159,14 @@
 	[],
 	[with_virtualenv=no])
 AS_IF([test "x$with_virtualenv" != xno],
-	AC_CHECK_PROGS([VIRTUALENV], [virtualenv virtualenv3 virtualenv2], [no])
-	AS_IF([test "x$VIRTUALENV" = xno],
+	[AC_CHECK_PROGS([VIRTUALENV], [virtualenv virtualenv3 virtualenv2], [no])]
+	[AS_IF([test "x$VIRTUALENV" = xno],
 	[AC_MSG_FAILURE(
-		[--with-virtualenv given but virtualenv could not be found])]),
-	AC_SUBST([VIRTUALENV], [no]))
+		[--with-virtualenv given but virtualenv could not be found])])],
+	[AC_SUBST([VIRTUALENV], [no])])
 AC_ARG_VAR([VIRTUALENV_FLAGS], [flags to pass to the virtualenv command])
 
-AX_PKG_SWIG(2.0)
+AX_PKG_SWIG([2.0])
 
 # DONE WITH PYTHON STUFF
 
@@ -184,7 +184,7 @@
 AS_IF([test "x$HAVE_CXX11" != "x1" && test "x$enable_c__11" = "xyes"],
   [AC_MSG_ERROR([C++11 requested but not found])])
 
-AC_ARG_WITH(mpi, [AS_HELP_STRING([--with-mpi],
+AC_ARG_WITH([mpi], [AS_HELP_STRING([--with-mpi],
 [compile with MPI (parallelization) support. If none is found,
 MPI is not used. Default: auto])
 ],,[with_mpi=auto])


signature.asc
Description: PGP signature

Bug#994426: octave-sparsersb: flaky autopkgtest on ci.d.n armhf worker

[Paul Gevers]

Source: octave-sparsersb
Version: 1.0.8-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: flaky timesout

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on armhf
because with a recent upload of glibc the autopkgtest of
octave-sparsersb fails in testing. In august 2021, we replaced the host
we were using for armhf testing for a new one. Since then, the
autopkgtest has been failing most of the times, due to it timing out. We
should get this fixed. Do you have any ideas what could be the root
cause of this?

Ironically, the passing tests (since the new host) report a segfault
and: Summary: 0 tests, 0 passed, 0 known failures, 0 skipped

Don't hesitate to contact us at debian...@lists.debian.org if you need
help debugging this issue.

Paul

https://ci.debian.net/packages/o/octave-sparsersb/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/armhf/o/octave-sparsersb/14991286/log.gz

* test
 a=sparsersb(sprand(100,100,0.4));
 nrhs=1;
 maxr=1;
 tmax=1;
 tn=2;
 sf=1;
 o=sparsersb(a,"autotune","n",nrhs,maxr,tmax,tn,sf);
 assert(o==a)
librsb error:The requested feature (e.g.:blocking) is not available
because it was opted out or not configured at built time.
librsb error:The requested feature (e.g.:blocking) is not available
because it was opted out or not configured at built time.
! test failed
index (_,0,_): subscripts must be either integers 1 to (2^31)-1 or logicals
* test
 a=sparsersb(sprand(100,100,0.4));
 nrhs=20;
 maxr=1;
 tmax=1;
 tn=1;
 o=sparsersb(a,"autotune","t",nrhs,maxr,tmax,tn);
 assert(o==a)
librsb error:The requested feature (e.g.:blocking) is not available
because it was opted out or not configured at built time.
librsb error:The requested feature (e.g.:blocking) is not available
because it was opted out or not configured at built time.
autopkgtest [20:58:07]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.h8cplcuw/downtmp/build.roH/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.h8cplcuw/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.h8cplcuw/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=160; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; touch
/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-stdout
/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-stderr; bash -ec
'DH_OCTAVE_TEST_ENV="xvfb-run -a" /usr/bin/dh_octave_check
--use-installed-package' 2> >(tee -a
/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-stderr >&2) > >(tee -a
/tmp/autopkgtest-lxc.h8cplcuw/downtmp/command1-stdout);" (kind: test)
autopkgtest [20:58:08]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994427: ITP: obs-text-slideshow -- plugin for OBS Studio to present texts in videos

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, jbwon...@gmail.com

* Package name: obs-text-slideshow
  Version : 1.5.1
  Upstream Author : Joshua Wong 
* URL : 
https://obsproject.com/forum/resources/obs-text-slideshow.1303/
* License : GPL-2+
  Programming Lang: C++
  Description : plugin for OBS Studio to present texts in videos

 OBS plugin inspired by the built-in image slideshow, except for text sources
 instead. Useful for displaying song lyrics, captions, translations, etc.
 .
 Is possible to insert any text in plugin settings or load a content from a
 single or from multiple text files. The transition modes for texts are cut,
 fade, swipe and slide. Is also possible to choice a font and its style. There
 are other settings.
 .
 This plugin is compatible with OBS 27 or higher.

Bug#994425: golang-github-sevlyar-go-daemon: FTBFS with Go 1.17

[William 'jawn-smith' Wilson]

Package: golang-github-sevlyar-go-daemon
Version: 0.1.5-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

The architecture darwin/386 is no longer supported in Go,
which causes a failure in the test suite of this package.
An upstream commit already exists that removes darwin/386
from the test case. This patch pulls in that change.

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

Successfully build with Go 1.17

  * Cherry pick upstream patch to remove darwin/386 architecture
and resolve FTBFS with Go 1.17 (LP: #1943761)


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-34-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-sevlyar-go-daemon-0.1.5/debian/patches/0001-cherry-pick-upstream-change-for-go-1.17.patch
 
golang-github-sevlyar-go-daemon-0.1.5/debian/patches/0001-cherry-pick-upstream-change-for-go-1.17.patch
--- 
golang-github-sevlyar-go-daemon-0.1.5/debian/patches/0001-cherry-pick-upstream-change-for-go-1.17.patch
 1969-12-31 18:00:00.0 -0600
+++ 
golang-github-sevlyar-go-daemon-0.1.5/debian/patches/0001-cherry-pick-upstream-change-for-go-1.17.patch
 2021-09-15 14:56:46.0 -0500
@@ -0,0 +1,21 @@
+Description: Fix FTBFS with Go 1.17
+ As of Go 1.15, the architecture darwin/386 was deprecated, and
+ it has been fully removed in Go 1.17. This was causing a failure
+ in a build-time test of this package. For more information, see
+ https://github.com/golang/go/issues/37610
+Origin: upstream, 
https://github.com/sevlyar/go-daemon/commit/4575a85b8ba1ffd626da3ac85b9143300d6437eb
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-sevlyar-go-daemon/+bug/1943761
+Applied-Upstream: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-sevlyar-go-daemon/+bug/1943761
+Last-Update: 2021-09-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/compilation_test.go
 b/compilation_test.go
+@@ -18,7 +18,6 @@
+   }
+ 
+   pairs := []string{
+-  "darwin/386",
+   "darwin/amd64",
+   "dragonfly/amd64",
+   "freebsd/386",
diff -Nru golang-github-sevlyar-go-daemon-0.1.5/debian/patches/series 
golang-github-sevlyar-go-daemon-0.1.5/debian/patches/series
--- golang-github-sevlyar-go-daemon-0.1.5/debian/patches/series 1969-12-31 
18:00:00.0 -0600
+++ golang-github-sevlyar-go-daemon-0.1.5/debian/patches/series 2021-09-15 
14:47:27.0 -0500
@@ -0,0 +1 @@
+0001-cherry-pick-upstream-change-for-go-1.17.patch

Bug#994424: spice-vdagent FTBFS: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations]

[Helmut Grohne]

Source: spice-vdagent
Version: 0.20.0-2
Severity: serious
Tags: ftbfs

spice-vdagent fails to build from source in unstable. A non-parallel
build ends as follows:

| gcc -DHAVE_CONFIG_H -I. -I./src   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/libdrm  -I/usr/include/spice-1 -pthread 
-I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
-I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/x86_64-linux-gnu -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -I./src -DUDSCS_NO_SERVER  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Werror -Wp,-D_FORTIFY_SOURCE=2 
-fno-strict-aliasing -fstack-protector --param=ssp-buffer-size=4 -c -o 
src/vdagent/spice_vdagent-x11-randr.o `test -f 'src/vdagent/x11-randr.c' || 
echo './'`src/vdagent/x11-randr.c
| src/vdagent/x11-randr.c: In function ‘vdagent_x11_set_monitor_config’:
| src/vdagent/x11-randr.c:1007:21: error: ‘g_memdup’ is deprecated: Use 
'g_memdup2' instead [-Werror=deprecated-declarations]
|  1007 | g_memdup(mon_config, 
config_size(mon_config->num_of_monitors));
|   | ^~~~
| In file included from /usr/include/glib-2.0/glib.h:82,
|  from src/vdagent/x11-randr.c:25:
| /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
|   257 | gpointer  g_memdup (gconstpointer mem,
|   |   ^~~~
| cc1: all warnings being treated as errors
| make[1]: *** [Makefile:1184: src/vdagent/spice_vdagent-x11-randr.o] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:18: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#994423: pytorch-vision: FTBFS on armhf: Illegal instruction

[Sebastian Ramacher]

Source: pytorch-vision
Version: 0.8.2-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| I: pybuild base:232: python3.9 setup.py clean 
| Illegal instruction
| E: pybuild pybuild:353: clean: plugin distutils failed with: exit code=132: 
python3.9 setup.py clean 
| dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned exit 
code 13
| make: *** [debian/rules:6: clean] Error 25

https://buildd.debian.org/status/fetch.php?pkg=pytorch-vision=armhf=0.8.2-1%2Bb1=1631302732=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Timo Röhling]

Control: severity 994419 serious
Control: affects 994419 + src:fastcdr
Control: tags 994419 + ftbfs

Hi, 


On Wed, 15 Sep 2021 21:25:49 +0200 Timo =?utf-8?Q?R=C3=B6hling?= 
 wrote:

the GTestTargets.cmake that is shipped in libgtest-dev also exports
the GTest::gmock and GTest::gmock_main targets. However, the
corresponding libraries libgmock.a and libgmock_main.a are shipped
in libgmock-dev. This causes a fatal error and prevents successful
CMake configuration in dependent projects.

Please add Depends: libgmock-dev to libgtest-dev.

I just noticed that this bug not only breaks autopkgtest but also
causes fastcdr to FTBFS.

In case you're wondering, apparently this bug has been exposed by
the changes in the new CMake version that has hit unstable, so this
will possibly affect more packages.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#994421: cdebootstrap: failing autopkgtest on one of ci.d.n amd64 workers

[Paul Gevers]

Oops, forgot the log

On 15-09-2021 21:42, Paul Gevers wrote:
> I looked at the results of the autopkgtest of you package on amd64
> because with a recent upload of glibc the autopkgtest of cdebootstrap
> fails in testing. It seems to me that the failures are related to the
> worker that the test runs on. ci-worker13 fails, while the other workers
> are OK. We recently changed the setup of ci-worker13, to have /tmp/ of
> the host on tmpfs as that speeds up testing considerably is a lot of
> cases. I copied some of the output at the bottom of this report, but I'm
> not 100% sure that the /tmp there (the one inside the lxc testbed) *is*
> on tmpfs.

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cdebootstrap/15277269/log.gz

autopkgtest [19:32:51]: test sid-build: [---
E: Target disallows device special files
autopkgtest [19:32:51]: test sid-build: ---]

It was pointed out to me on IRC that this is probably caused by mounting
tmp with nodev. If it's save to do so, I'll update our hosts and check
again. In that case, sorry for the noise.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994422: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c /usr/share/cmake-3.16/Modules/CMakeCXXCompilerABI.cpp

[Joao Eriberto Mota Filho]

Package: blhc
Version: 0.12-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: si...@ruderich.org

Hi Simon,

The line shown in the subject is being produced from blhc over CMake 3.16 and
later versions. See an example below, from obs-advanced-scene-switcher
(currently only in Salsa and New Queue):

CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c
/usr/share/cmake-3.18/Modules/CMakeCXXCompilerABI.cpp -DASIO_STANDALONE
-DHAVE_OBSCONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB
-DREPLAYBUFFER_SUPPORTED -DVCAM_SUPPORTED -Dadvanced_scene_switcher_EXPORTS
-I/builds/debian/obs-advanced-scene-switcher/debian/output/source_dir/obj-x86_64-linux-gnu
-I/builds/debian/obs-advanced-scene-switcher/debian/output/source_dir
-I/builds/debian/obs-advanced-scene-switcher/debian/output/source_dir/deps/asio/asio/include
-I/builds/debian/obs-advanced-scene-switcher/debian/output/source_dir/deps/websocketpp
-I/usr/include/obs -I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu
-I/usr/include -I/usr/include/c++/10 -I/usr/include/x86_64-linux-gnu/c++/10
-I/usr/include/c++/10/backward -I/usr/lib/gcc/x86_64-linux-gnu/10/include
-I/usr/local/include

I found an explanation about this line here[1] (CMake Project). A summary:

 "From that Salsa job (link in the original report) you can see that what blhc
 (the hardening-tool-enforcement-thing) is complaining about, are the four calls
 to the compiler like /usr/lib/ccache/c++ -dM -E -c
 /usr/share/cmake-3.16/Modules/CMakeCXXCompilerABI.cpp .

 These are obviously false positives, since it's CMake checking compiler flags
 and the resulting objects never end up in any artefacts from the build.
 Because CPPFLAGS aren't inserted in there, the calls are flagged, and the tool
 complains."

[1] https://gitlab.kitware.com/cmake/cmake/-/issues/20631#note_746828

Really, I tested a final binary with hardening-check command and I can see:

# hardening-check obs-text-slideshow.so
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: unknown, no -fstack-clash-protection instructions found
 Control flow integrity: no, not found!

I am getting the same message from blhc in some packages (in my packages
packetsender, obs-advanced-scene-switch and obs-text-slideshow). What you think
about to add the following line as an exclusion in blhc?

 /usr/lib/ccache/c++ -dM -E -c 
/usr/share/cmake-.*/Modules/CMakeCXXCompilerABI.cpp .

Now I will use an exclusion via debian/rules.

Thanks!

Regards,

Eriberto

Bug#994417: libvte-2.91-0: underscore character from DejaVu Sans Mono is invisible on last line

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/340

On Wed, 15 Sep 2021 at 15:12:41 -0400, Eric Cooper wrote:
> Underscore characters in the bottom line of a terminal window using
> libvte are not shown when the font is DejaVu Sans Mono (at least for
> 10, 11, and 12 point size).  Both xfce4-terminal and
> gnome-terminal exhibit this.

This might be https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/340?

smcv

Bug#994421: cdebootstrap: failing autopkgtest on one of ci.d.n amd64 workers

[Paul Gevers]

Source: cdebootstrap
Version: 0.7.8
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on amd64
because with a recent upload of glibc the autopkgtest of cdebootstrap
fails in testing. It seems to me that the failures are related to the
worker that the test runs on. ci-worker13 fails, while the other workers
are OK. We recently changed the setup of ci-worker13, to have /tmp/ of
the host on tmpfs as that speeds up testing considerably is a lot of
cases. I copied some of the output at the bottom of this report, but I'm
not 100% sure that the /tmp there (the one inside the lxc testbed) *is*
on tmpfs.

Don't hesitate to contact us at debian...@lists.debian.org if you need
help debugging this issue.

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Bug#994419: libgtest-dev: missing dependency on libgmock-dev

[Timo Röhling]

Package: libgtest-dev
Version: 1.10.0.20201025-1.1
Severity: important
Tag: patch

Dear maintainer,

the GTestTargets.cmake that is shipped in libgtest-dev also exports
the GTest::gmock and GTest::gmock_main targets. However, the
corresponding libraries libgmock.a and libgmock_main.a are shipped
in libgmock-dev. This causes a fatal error and prevents successful
CMake configuration in dependent projects.

Please add Depends: libgmock-dev to libgtest-dev.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#994418: ocfs2-tools: failing autopkgtest on one of ci.d.n amd64 workers

[Paul Gevers]

Source: ocfs2-tools
Version: 1.8.6-6
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on amd64
because with a recent upload of glibc the autopkgtest of ocfs2-tools
fails in testing. It seems to me that the failures are related to the
worker that the test runs on. ci-worker13 fails, while the other workers
are OK. We recently changed the setup of ci-worker13, to have /tmp/ of
the host on tmpfs as that speeds up testing considerably is a lot of
cases. I copied some of the output at the bottom of this report, but I'm
not 100% sure that the /tmp there (the one inside the lxc testbed) *is*
on tmpfs.

Don't hesitate to contact us at debian...@lists.debian.org if you need
help debugging this issue.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocfs2-tools/15277216/log.gz


autopkgtest [19:14:22]: test basic: [---

=== disk ===
200+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 0.109005 s, 1.9 GB/s

=== mkfs ===
mkfs.ocfs2 1.8.6
mkfs.ocfs2: Could not open device
/tmp/autopkgtest-lxc.8neywhcx/downtmp/autopkgtest_tmp/disk: Invalid argument
autopkgtest [19:14:23]: test basic: ---]




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992698: meld dies with "Trace/breakpoint trap"

[Bálint Réczey]

Control: tags -1 unreproducible

Ok, thanks for letting me know.

Cheers,
Balint

Harald Dunkel  ezt írta (időpont: 2021. szept. 15.,
Sze, 20:49):
>
>
> Sorry, I cannot reproduce this anymore. The auto.misc.ucf-old has been 
> deleted.
>
>
> Regards
> Harri

Bug#993843: [BUG] With --disable-dynamic-nss, not all functions calls are protected

[Bart Schaefer]

On Wed, Sep 15, 2021 at 7:32 AM Axel Beckert  wrote:
>
> But copying zsh-static on a system with a different libc6 version
> still segfaults, so this patch might be necessary but not sufficient.
>
> Last line is:
>
>   zsh-static: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: 
> Assertion `sym != NULL' failed.

Based on the strace, my guess would be that getrlimit() is what's
attempting to link to the dynamic library.  This is based on the
success of the uname() call and on what does NOT appear in the
subsequent trace output.  If getrlimit() does have this effect, it's
possible that getrusage() will as well.

Bug#994417: libvte-2.91-0: underscore character from DejaVu Sans Mono is invisible on last line

[Eric Cooper]

Package: libvte-2.91-0
Version: 0.64.2-2
Severity: normal

Underscore characters in the bottom line of a terminal window using
libvte are not shown when the font is DejaVu Sans Mono (at least for
10, 11, and 12 point size).  Both xfce4-terminal and
gnome-terminal exhibit this.

Downgrading to version 0.62.3-1 of libvte and libvte-common fixes the
problem.

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

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

Versions of packages libvte-2.91-0 depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libfribidi0  1.0.8-2
ii  libgcc-s111.2.0-4
ii  libglib2.0-0 2.68.4-1
ii  libgnutls30  3.7.2-2
ii  libgtk-3-0   3.24.30-3
ii  libicu67 67.1-7
ii  libpango-1.0-0   1.48.9+ds1-2
ii  libpangocairo-1.0-0  1.48.9+ds1-2
ii  libpcre2-8-0 10.36-2
ii  libstdc++6   11.2.0-4
ii  libsystemd0  247.9-1
ii  libvte-2.91-common   0.64.2-2
ii  zlib1g   1:1.2.11.dfsg-2

libvte-2.91-0 recommends no packages.

libvte-2.91-0 suggests no packages.

-- no debconf information

Bug#994416: transition: urdfdom

[Jose Luis Rivero]

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

Dear Release Team:

I'm the maintainer of console-bridge package, upstream has released 1.0
version some weeks ago. We have 1.0.1+dfsg2-2 in experimental, it builds
in all arches: 

https://buildd.debian.org/status/package.php?p=console-bridge=experimental

I have run ratt in the Open Robotics buildfarm and dependencies looks
fine: https://build.osrfoundation.org/job/debian-ratt-builder/86/

"""
2021/09/15 14:11:16 Loading changes file 
"console-bridge_1.0.1+dfsg2-2_amd64.changes"
2021/09/15 14:11:16  - 3 binary packages: libconsole-bridge-dev 
libconsole-bridge1.0 libconsole-bridge1.0-dbgsym
2021/09/15 14:11:16 Corresponding .debs (will be injected when building):
2021/09/15 14:11:16 libconsole-bridge-dev_1.0.1+dfsg2-2_amd64.deb
2021/09/15 14:11:16 libconsole-bridge1.0-dbgsym_1.0.1+dfsg2-2_amd64.deb
2021/09/15 14:11:16 libconsole-bridge1.0_1.0.1+dfsg2-2_amd64.deb
2021/09/15 14:11:16 Setting -dist=sid (from .changes file)
2021/09/15 14:11:18 Loading sources index 
"/var/lib/apt/lists/ftp.us.debian.org_debian_dists_sid_main_source_Sources.lz4"
2021/09/15 14:11:19 Setting -sbuild_dist=unstable (from .changes file)
2021/09/15 14:11:19 Building package 1 of 10: ros-dynamic-reconfigure
2021/09/15 14:15:57 Building package 2 of 10: ros-geometry
2021/09/15 14:20:45 Building package 3 of 10: ros-rosconsole-bridge
2021/09/15 14:24:26 Building package 4 of 10: ros-roscpp-core
2021/09/15 14:27:48 Building package 5 of 10: urdfdom
2021/09/15 14:30:09 Building package 6 of 10: ros-bond-core
2021/09/15 14:34:10 Building package 7 of 10: ros-class-loader
2021/09/15 14:37:56 Building package 8 of 10: ros-geometry2
2021/09/15 14:42:58 Building package 9 of 10: ros-ros-comm
2021/09/15 14:50:07 Building package 10 of 10: ros-actionlib
2021/09/15 14:58:21 Build results:
2021/09/15 14:58:21 PASSED: ros-roscpp-core
2021/09/15 14:58:21 PASSED: urdfdom
2021/09/15 14:58:21 PASSED: ros-class-loader
2021/09/15 14:58:21 PASSED: ros-geometry2
2021/09/15 14:58:21 PASSED: ros-ros-comm
2021/09/15 14:58:21 PASSED: ros-actionlib
2021/09/15 14:58:21 PASSED: ros-geometry
2021/09/15 14:58:21 PASSED: ros-rosconsole-bridge
2021/09/15 14:58:21 PASSED: ros-bond-core
2021/09/15 14:58:21 PASSED: ros-dynamic-reconfigure
"""

Ben file:

title = "urdfdom";
is_affected = .depends ~ "libconsole-bridge0.4" | .depends ~ 
"libconsole-bridge1.0";
is_good = .depends ~ "libconsole-bridge1.0";
is_bad = .depends ~ "libconsole-bridge0.4";

Thanks!

Bug#992698: meld dies with "Trace/breakpoint trap"

[Harald Dunkel]

Sorry, I cannot reproduce this anymore. The auto.misc.ucf-old has been deleted.


Regards
Harri

Bug#994402: binutils-source: Re-enable building of ARC cross-binutils

[Alexey Brodkin]

Package: binutils-source
Version: 2.37-6
Severity: normal
Tags: patch

Dear Maintainer,

W/o newer dpkg we cannot correctly build cross-Binutils for ARC
as target architecture won't be recognized. And so we disabled it
with [1]. And once new dpkg gets uploaded we're ready to re-enable this one
with a patch below.

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

-Alexey

--->8---
--- a/debian/rules
+++ b/debian/rules
@@ -116,14 +116,11 @@
 install_binary = install -m 755 -s --strip-program="$(STRIP)"
 
 NATIVE_ARCHS ?= amd64 i386 arm64 armhf armel ppc64el s390x
-NATIVE_ARCHS += alpha hppa ia64 m68k powerpc ppc64 \
+NATIVE_ARCHS += alpha arc hppa ia64 m68k powerpc ppc64 \
riscv64 sh4 sparc64 x32
 NATIVE_ARCHS += hurd-i386 kfreebsd-amd64 kfreebsd-i386
 #NATIVE_ARCHS += nios2 or1k s390 sparc
 
-# Once dpkg with ARC support is uploaded, add "arc" as well
-#NATIVE_ARCHS += arc
-
 # don't generate the control file entries for native packages which are never
 # built. Only valid for Ubuntu. The autopkg testers get confused otherwise
 ifneq ($(distribution)-$(CROSS_ARCHS),Ubuntu-)
@@ -140,12 +137,10 @@
 # DEB_HOST_ARCH is filtered-out later anyway, do not test here.
 CROSS_ARCHS ?= amd64 i386 x32 \
s390x ppc64el arm64 armhf armel \
-   alpha hppa m68k \
+   alpha arc hppa m68k \
powerpc ppc64 sh4 sparc64 \
ia64 riscv64 \
kfreebsd-amd64 kfreebsd-i386 hurd-i386
-# Once dpkg with ARC support is uploaded, add "arc" as well
-#  arc
   else ifeq ($(DEB_HOST_ARCH),arm64)
 CROSS_ARCHS ?= amd64 armel armhf i386 ppc64el riscv64 s390x x32
   else ifeq ($(DEB_HOST_ARCH),ppc64)
--->8---


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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages binutils-source depends on:
ii  make4.2.1-1.2
ii  python3 3.8.2-0ubuntu2
ii  texinfo 6.7.0.dfsg.2-5
ii  zlib1g-dev  1:1.2.11.dfsg-2ubuntu1.2

binutils-source recommends no packages.

binutils-source suggests no packages.

Bug#830138: pssh: please split psshutil and provide a python3 package

[Hilmar Preuße]

Am 06.07.2016 um 13:45 teilte Sandro Tosi mit:

Hi,


pssh provides both a python module and a program in the same binary
package. Please split the python module in a separate package and
provide a python3 version of it.

The pssh has been ported to python3 in the meantime. Which part of the 
package should be spilt into a new package? The part below 
"/usr/lib/python3/dist-packages/psshlib/" ?


hille@debian-amd64-sid:~$ dpkg -L pssh
/.
/usr
/usr/bin
/usr/bin/parallel-nuke
/usr/bin/parallel-rsync
/usr/bin/parallel-scp
/usr/bin/parallel-slurp
/usr/bin/parallel-ssh
/usr/lib
/usr/lib/pssh
/usr/lib/pssh/pssh-askpass
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/pssh-2.3.1.egg-info
/usr/lib/python3/dist-packages/psshlib
/usr/lib/python3/dist-packages/psshlib/__init__.py
/usr/lib/python3/dist-packages/psshlib/askpass_client.py
/usr/lib/python3/dist-packages/psshlib/askpass_server.py
/usr/lib/python3/dist-packages/psshlib/cli.py
/usr/lib/python3/dist-packages/psshlib/color.py
/usr/lib/python3/dist-packages/psshlib/manager.py
/usr/lib/python3/dist-packages/psshlib/psshutil.py
/usr/lib/python3/dist-packages/psshlib/task.py
/usr/lib/python3/dist-packages/psshlib/version.py
/usr/share
/usr/share/doc
/usr/share/doc/pssh
/usr/share/doc/pssh/README.Debian
/usr/share/doc/pssh/changelog.Debian.gz
/usr/share/doc/pssh/changelog.gz
/usr/share/doc/pssh/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/parallel-nuke.1.gz
/usr/share/man/man1/parallel-rsync.1.gz
/usr/share/man/man1/parallel-scp.1.gz
/usr/share/man/man1/parallel-slurp.1.gz
/usr/share/man/man1/parallel-ssh.1.gz

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#830138: pssh: please split psshutil and provide a python3 package

[Sandro Tosi]

On Wed, Sep 15, 2021 at 2:35 PM Hilmar Preuße  wrote:
>
> Am 06.07.2016 um 13:45 teilte Sandro Tosi mit:
>
> Hi,
>
> > pssh provides both a python module and a program in the same binary
> > package. Please split the python module in a separate package and
> > provide a python3 version of it.
> >
> The pssh has been ported to python3 in the meantime. Which part of the
> package should be spilt into a new package? The part below
> "/usr/lib/python3/dist-packages/psshlib/" ?

yes, that's what a python module is

>
> hille@debian-amd64-sid:~$ dpkg -L pssh
> /.
> /usr
> /usr/bin
> /usr/bin/parallel-nuke
> /usr/bin/parallel-rsync
> /usr/bin/parallel-scp
> /usr/bin/parallel-slurp
> /usr/bin/parallel-ssh
> /usr/lib
> /usr/lib/pssh
> /usr/lib/pssh/pssh-askpass
> /usr/lib/python3
> /usr/lib/python3/dist-packages
> /usr/lib/python3/dist-packages/pssh-2.3.1.egg-info
> /usr/lib/python3/dist-packages/psshlib
> /usr/lib/python3/dist-packages/psshlib/__init__.py
> /usr/lib/python3/dist-packages/psshlib/askpass_client.py
> /usr/lib/python3/dist-packages/psshlib/askpass_server.py
> /usr/lib/python3/dist-packages/psshlib/cli.py
> /usr/lib/python3/dist-packages/psshlib/color.py
> /usr/lib/python3/dist-packages/psshlib/manager.py
> /usr/lib/python3/dist-packages/psshlib/psshutil.py
> /usr/lib/python3/dist-packages/psshlib/task.py
> /usr/lib/python3/dist-packages/psshlib/version.py
> /usr/share
> /usr/share/doc
> /usr/share/doc/pssh
> /usr/share/doc/pssh/README.Debian
> /usr/share/doc/pssh/changelog.Debian.gz
> /usr/share/doc/pssh/changelog.gz
> /usr/share/doc/pssh/copyright
> /usr/share/man
> /usr/share/man/man1
> /usr/share/man/man1/parallel-nuke.1.gz
> /usr/share/man/man1/parallel-rsync.1.gz
> /usr/share/man/man1/parallel-scp.1.gz
> /usr/share/man/man1/parallel-slurp.1.gz
> /usr/share/man/man1/parallel-ssh.1.gz
>
> Hilmar
> --
> sigfault
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#994414: lintian(1) says --fails-on defaults to `error`, but looks like it's `none`

[Paride Legovini]

Package: lintian
Version: 2.106.1
Severity: normal
X-Debbugs-Cc: par...@debian.org

Hi,

It looks like there's a mismatch between the lintian manpage and the
actual behavior. The manpage says that for --fail-on "The default is
error." However lintian doesn't actually exit with $? != 0 on errors
(E tags) unless `--fail-on error` is explicitly specified.

Paride

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

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

Versions of packages lintian depends on:
ii  binutils2.37-5
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.26-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.12-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.611-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-5
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.37-5
ii  libtext-template-perl  1.60-1

-- no debconf information

Bug#994413: textql: FTBFS with Go 1.17

[William 'jawn-smith' Wilson]

Package: textql
Version: 2.0.3-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

Package textql currently FTBFS with Go 1.17. This is caused by
a failing build-time test due to a minor change in Go's temp
file name creation.

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

Successfully build this package with Go 1.17.

  * Fix build-time test that fails with Go 1.17 (LP: #1943749)


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-34-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru textql-2.0.3/debian/control textql-2.0.3/debian/control
--- textql-2.0.3/debian/control 2020-09-09 18:21:08.0 -0500
+++ textql-2.0.3/debian/control 2021-09-15 12:37:52.0 -0500
@@ -1,8 +1,7 @@
 Source: textql
 Section: devel
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Go Packaging Team 

+Maintainer: Debian Go Packaging Team 

 Uploaders: ChangZhuo Chen (陳昌倬) 
 Build-Depends: debhelper (>= 10),
dh-golang,
diff -Nru textql-2.0.3/debian/patches/0001-fix-csv-test-with-go-1.17.patch 
textql-2.0.3/debian/patches/0001-fix-csv-test-with-go-1.17.patch
--- textql-2.0.3/debian/patches/0001-fix-csv-test-with-go-1.17.patch
1969-12-31 18:00:00.0 -0600
+++ textql-2.0.3/debian/patches/0001-fix-csv-test-with-go-1.17.patch
2021-09-15 12:37:52.0 -0500
@@ -0,0 +1,22 @@
+Description: Fix test that is failing with Go 1.17
+ Due to a change in Go 1.17, the file name in the test case
+ TestCSVInputHasAName no longer has the "./" in it, causing
+ it to fail. Stripping that substring from it fixes the test.
+Author: William 'jawn-smith' Wilson 
+Bug: https://github.com/dinedal/textql/issues/135
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/textql/+bug/1943749
+Forwarded: https://github.com/dinedal/textql/pull/136
+Last-Update: 2021-09-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/inputs/csv_test.go
 b/inputs/csv_test.go
+@@ -134,7 +134,7 @@
+   }
+ 
+   input, _ := NewCSVInput(opts)
+-  expected := fp.Name()
++  expected := strings.ReplaceAll(fp.Name(), "./", "")
+ 
+   if !reflect.DeepEqual(input.Name(), expected) {
+   t.Errorf("Name() = %v, want %v", input.Name(), expected)
diff -Nru textql-2.0.3/debian/patches/series textql-2.0.3/debian/patches/series
--- textql-2.0.3/debian/patches/series  1969-12-31 18:00:00.0 -0600
+++ textql-2.0.3/debian/patches/series  2021-09-15 12:37:28.0 -0500
@@ -0,0 +1 @@
+0001-fix-csv-test-with-go-1.17.patch

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Witold Baryluk]

Package: glx-diversions
Followup-For: Bug #993338
X-Debbugs-Cc: witold.bary...@gmail.com

I noticed that removing the non-free and/or contrib from the suites
available during live-build process in my scripts, causes nvidia drivers
to not be installed, and bug no longer reproducible.

So indeed it is likely glx-diversions or the nvidia specific one.

Regards,
Witold

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Sebastian Ramacher]

On 2021-09-14 09:12:34 +0100, Simon McVittie wrote:
> On Sun, 12 Sep 2021 at 20:17:36 +0100, Simon McVittie wrote:
> > According to
> > https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
> > it might be necessary to remove
> > gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
> > testing if #993061 cannot be fixed soon. The other packages with an upper
> > limit have already been uploaded to unstable and will hopefully transition
> > reasonably smoothly.
> 
> Looking at the migration excuses for gnome-shell, I think we will need
> something more like this:
> 
> remove gnome-shell-extension-dashtodock/69-1
> remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8
> remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1

Removal hints added

> 
> I'm not sure why the first two would block migration since they don't have
> an upper limit on their version numbers, but those extensions haven't been
> ported to gnome-shell 40, so they aren't going to work in practice anyway.
> 
> Unfortunately this transition has got caught behind glibc, so will likely
> take a while to migrate. This seems to be a bug in glibc's mipsel symbols
> file (I'll open a bug for that).

Thanks. The latest upload of glibc looks like it would soon be able to
migrate and fixed the symbols file. If there are new regressions that
prevent migration of some of the ongoing transtions, I will look at some
additional binNMUs

Cheers

> 
> smcv
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994412: Not easy to remove dummy package cleanly

[積丹尼 Dan Jacobson]

Package: debian-el
Version: 37.10

When I try to remove this dummy package, aptitude says
The following packages will be REMOVED:
  debian-el{p}  elpa-debian-el{pu} (D: debian-el)

But other dummy packages don't trigger this in aptitude.

Bug#994411: error: ‘DRM_IOCTL_I915_GEM_MMAP_OFFSET’ undeclared

[Marin Damian]

Package: libdrm-dev
Version: 2.4.104-1

When I'm using 'DRM_IOCTL_I915_GEM_MMAP_OFFSET' literal in a C program, I get 
an error message: 'DRM_IOCTL_I915_GEM_MMAP_OFFSET' undeclared.
Here is a transcript:

root@debian:~# gcc -xc -S -o - - << EOF
#include 
#include 
int main(void) {
  int code = 0;
  switch (code) {
  case DRM_IOCTL_I915_GEM_MMAP:
  case DRM_IOCTL_I915_GEM_MMAP_GTT:
  case DRM_IOCTL_I915_GEM_MMAP_OFFSET:
break;
  }
  return 0;
}
EOF
.file   ""
: In function ‘main’:
:8:8: error: ‘DRM_IOCTL_I915_GEM_MMAP_OFFSET’ undeclared (first use in 
this function); did you mean ‘DRM_IOCTL_I915_GEM_MMAP_GTT’?
:8:8: note: each undeclared identifier is reported only once for each 
function it appears in
root@debian:~#

I suggest that 'i915_drm.h' uapi header file be corrected.

I am using Debian GNU/Linux 11.0, kernel 5.10.46-4 and libc6 2.31.

Bug#994259: [Debian-med-packaging] Bug#994259: resfinder: autopkgtest regression on armhf and i386: db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1

[Paul Gevers]

Hi,

On 15-09-2021 18:51, Étienne Mollier wrote:
> I intend to adjust the d/tests/control Architecture field of
> resfinder to match the (pending upload) list of architectures
> supported by kma.  Would this be sufficient to bring back
> resfinder to testing, or is there some knob to twiddle on CI end
> to make sure the absence of test is not a regression anymore?

If resfinder depends on kma, then britney (the Release Team migration
software) *should* do the right thing. But it probably has a bug in this
area. So either you add the Architecture field and be done with it (for
now) or we override it on the Release Team side of things until britney
is fixed.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994409: +1 (Re: task-laptop: please recommend automatic apt proxying)

[Holger Levsen]

On Wed, Sep 15, 2021 at 10:29:51AM -0700, Russ Allbery wrote:
> The safe default for Debian in any standard installation mode, which I
> believe includes tasks, is to talk explicitly to Debian infrastructure.
> If people would like to improve local performance, they should automate
> the configuration of the machines that they control, with the permission
> and understanding of the people who are using those machines.

that.


-- 
cheers,
Holger

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

All data, over time, approaches deleted, or public. (@quinnnorton)


signature.asc
Description: PGP signature

Bug#994409: task-laptop: please recommend automatic apt proxying

[Russ Allbery]

Phil Morrell  writes:

> Package: task-laptop
> Version: 3.53
> Severity: wishlist

> I'm not sure on the difference between auto-apt-proxy and
> squid-deb-proxy-client. Avahi is already pulled in by task-laptop.

Please do not do this.  I do not want to have to reason about the security
impact of someone who controls local DNS taking over my apt sources.  I
understand that people believe that this is harmless because of apt
signature checking, but it still opens more attack paths and routes to
exercise other possible vulnerabilities.

The safe default for Debian in any standard installation mode, which I
believe includes tasks, is to talk explicitly to Debian infrastructure.
If people would like to improve local performance, they should automate
the configuration of the machines that they control, with the permission
and understanding of the people who are using those machines.

We should not enable people who control the local network but not the
Debian system to dynamically change security-relevant configuration of
that system, which I believe includes apt sources, without explicit
permission.

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

Bug#994410: screenkey: missing python3-gi-cairo dependency

[Marco Lucidi]

Package: screenkey
Version: 1:1.4-2
Severity: normal

dear Maintainer,

I recently installed screenkey and when using it, the following errors appeared
on stdout:

$ screenkey
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 341, 
in on_configure
self.input_shape_combine_region(cairo.Region(cairo.RectangleInt(0, 0, 
0, 0)))
KeyError: 'could not find foreign type Region'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
TypeError: Couldn't find foreign struct converter for 'cairo.Context'

typed keys were still showing up on screen, but the black background was 
missing.

with a quick google search I learned that I needed to install python3-gi-cairo
to make the errors go away (e.g. https://stackoverflow.com/questions/42279510)
and indeed the issue was fixed after I manually installed python3-gi-cairo.

I think python3-gi-cairo should be a required dependency of screenkey to make
it work properly (it's already listed on screenkey homepage's "readme"
https://www.thregr.org/~wavexx/software/screenkey#from-source).

thank you

marco

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

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

Versions of packages screenkey depends on:
ii  fonts-font-awesome   5.0.10+really4.7.0~dfsg-4.1
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  gir1.2-gtk-3.0   3.24.24-4
ii  libx11-6 2:1.7.2-1
ii  python3  3.9.2-3
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-2
ii  slop 7.5-1+b1

screenkey recommends no packages.

screenkey suggests no packages.

-- no debconf information

Bug#994409: task-laptop: please recommend automatic apt proxying

[Phil Morrell]

Package: task-laptop
Version: 3.53
Severity: wishlist

I'm not sure on the difference between auto-apt-proxy and
squid-deb-proxy-client. Avahi is already pulled in by task-laptop.


On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote:
> > Why not simply automate setting it at install time using preseed? I'm
> > honestly not sure who the target audience for auto-apt-proxy is
> 
> Laptops of end-user systems are the target, but also developers. When
> people gather at a place (conference, hackspace, private meetup, etc.)
> downloading of .debs should just work quickly by default. Many such
> sites could easily provide a local cache and a number even do. BSPs tend
> to have a blackboard with information including the local mirror to use.
> Seriously, how many people change their mirror when they go to a BSP? If
> we installed auto-apt-proxy by default, much of the local caching would
> just work.



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldstable'), (100, 'buster-fasttrack'), (100, 'buster-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages task-laptop depends on:
ii  anacron  2.3-28
ii  tasksel  3.53

Versions of packages task-laptop recommends:
ii  avahi-autoipd   0.7-4+deb10u1
ii  bluetooth   5.50-1.2~deb10u2
ii  iw  5.0.1-1
ii  powertop2.8-1+b2
ii  wireless-tools  30~pre9-13
ii  wpasupplicant   2:2.7+git20190128+0c1e29f-6+deb10u3

task-laptop suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#385069: diremtpy or "exists"?

[マダンテ]

On Thu, 7 Sep 2006 20:43:26 -0400 Joey Hess  wrote:
> I think that by generalising beyond dirempty to include exists, you're
> getting closer to a generic unix tool.
>
> I worry though that the tool might be test(1). These seem like fairly
> good candidates to add to test, especially dirempty.
>
> --
> see shy jo

Bug#385069: moreutils: Please add "dirempty" command

[マダンテ]

On Mon, 28 Aug 2006 22:31:35 +0200 Erich Schubert  wrote:
> Package: moreutils
> Version: 0.16
> Severity: wishlist
>
> Hi,
> Testing a directory to be empty in bash is hackish, see
>
http://wooledge.org/mywiki/BashFaq#head-6ec77504553115e8518271d0d319e27148634f19
>
> The cleanest way probably is
> if [ -z "$(ls -A "$dir")" ]; then
> fi
>
> Maybe we should add a small utility which does test this in a sane way.
>
> if dirempty "$dir"; then
> fi
>
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/dash
> Kernel: Linux 2.6.17.7
> Locale: LANG=de_DE.UTF-8@euro, LC_CTYPE=de_DE.UTF-8@euro (charmap=UTF-8)
>
> Versions of packages moreutils depends on:
> ii  libc62.3.6.ds1-4 GNU C Library: Shared
libraries
> ii  perl 5.8.8-6.1   Larry Wall's Practical
Extraction
>
> moreutils recommends no packages.
>
> -- no debconf information
>
>

Bug#385069: diremtpy or "exists"?

[マダンテ]

On Fri, 08 Sep 2006 03:20:02 +0200 Erich Schubert  wrote:
> Hi Joey,
> > Hmm, and dirempty is just ! exists foo/* && ! exists foo/.* , right?
>
> Maybe "exists -d foo" would be nicer for this.
> In many applications, "exists 'foo/*'" would do the job okay enough (if
> you don't plan to rm the directory)
>
> best regards,
> Erich Schubert
> --
>  erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_
> To be trusted is a greater complement than to be loved.   //\
>  Man kann sich auch in Gesellschaft anderer einsam fühlen. Weizsäcker V_/_
>
>
>

Bug#385069: diremtpy or "exists"?

[マダンテ]

On Fri, 08 Sep 2006 03:59:51 +0200 Erich Schubert  wrote:
> Hi,
> > I worry though that the tool might be test(1). These seem like fairly
> > good candidates to add to test, especially dirempty.
>
> Definitely test should have had this functionality.
> However people will expect test to behave the same on all systems, so
> I'm not sure adding some non-POSIX extensions to test is a good idea.
> People will write scripts and use test, and then it won't work on other
> systems. If it's another utility, then it will be much more obvious that
> the tool might not exist on other systems.
> Furthermore some shells (busybox?) might be using a built-in test, and
> that wouldn't have this functionality then.
>
> best regards,
> Erich Schubert
> --
>  erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_
>  A man doesn't know what he knows until he knows what he doesn't know. //\
>   Man kann sich auch in Gesellschaft anderer einsam fühlen. Weizsäcker
V_/_
>
>
>

Bug#385069: diremtpy or "exists"?

[マダンテ]

On Thu, 7 Sep 2006 20:45:27 -0400 Joey Hess  wrote:
> Erich Schubert wrote:
> > A minute ago I didn't need "dirempty", but "exists 'foo/*.bar'"
> > test -e "foo" works fine if you have the filename. If you have wildcards
> > it gets a bit more complicated. IMHO it would be good to have a
> > convenience command for this instead of using some shell magic with test
> > and ls.
>
> Hmm, and dirempty is just ! exists foo/* && ! exists foo/.* , right?
>
> --
> see shy jo

Bug#385069:

[マダンテ]

Bug#385069: diremtpy or "exists"?

[マダンテ]

On Sat, 02 Sep 2006 03:55:33 +0200 Erich Schubert  wrote:
> Hi,
> A minute ago I didn't need "dirempty", but "exists 'foo/*.bar'"
> test -e "foo" works fine if you have the filename. If you have wildcards
> it gets a bit more complicated. IMHO it would be good to have a
> convenience command for this instead of using some shell magic with test
> and ls.
>
> best regards,
> Erich Schubert
> --
>  erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_
>  Reality continues to ruin my life --- Calvin  //\
> Wende Dein Gesicht der Sonne zu, dann fallen die Schatten hinter Dich.
V_/_
>
>
>

Bug#992527: [Pkg-javascript-devel] Bug#992527: node-srs: FTBFS with GDAL 3.3.1

[Yadd]

Le 15/09/2021 à 16:10, Sebastiaan Couwenberg a écrit :
> Since this only exists as part of the node-carto dependency chain,
> removing this package along with node-millstone and node-carto is
> probably a better idea than spending time fixing this issue.
> 
> Kind Regards,
> 
> Bas

Hi JS Team,

OK to remove node-srs, node-miilstone and node-carto ?

Bug#927379: Debian Bug Report Tracking System

[Vásárhelyi József]

Dear Paul,

We solved the problem.

I do not know exactly the exact solution, because My collegue Daniel 
did, but the essencei is this:


The synaptic has a directory where store some data. We deleted all the 
content and problem was solved.



Best regards,

Jozsef

2021. 08. 23. 14:52 keltezéssel, Paul Gevers írta:


Paul

<>

Bug#994182: headset functionality broken after recent update

[debian-bugs]

> Hi,
>
> I'm not sure what to do about this issue.

Well, to me it seems pulseaudio 15 should not not be promoted to testing 
until this is sorted out -- given the current boom in video conferencing 
due to working from home, a suddenly broken headset will cause a lot of 
trouble. (Thankfully, I did not have to work this week so I could spend 
three days figuring out what's wrong, couldn't afford this in a work week.)


AFAIU the issue is caused by a change in the btusb kernel driver and 
thus affects most bluetooth devices connected via USB, fixed only in 5.13.
So either the fix needs to be back-ported to the current kernel or 
pulseaudio needs to include the workaround outlined in the linked report.
At the very, very least users should be warned about a potential 
breakage and how to work around that.



Positive side effect: ofono seems not to be necessary anymore.

This is the new feature :)


It's the silver lining in a deluge ... ;)

Bug#994408: cdimage.debian.org: Buster non-free firmware image fails to detect wifi

[Olaf Zaplinski]

Package: cdimage.debian.org
Severity: important
Tags: d-i

Dear Maintainer,

1. in contrast to Linux Mint, the non-free iso does not detect my (popular) 
Realtek 8822CE wifi
2. non-free ISO is not available on german mirrors, so do not point us in that 
direction. I had to use the main server for downloading.

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Simon McVittie]

On Wed, 15 Sep 2021 at 11:34:33 -0400, Zack Weinberg wrote:
> For the various files with a "canonical" location
> either in /usr or in /, either specified by some standard or by
> convention, and regularly referred to by absolute pathname, all
> software should continue to refer to those files by their "canonical"
> name

There are two sorts of hard-coding that are common for absolute paths,
which we should not conflate.

I think you might be primarily talking about the situation where source
code refers to an executable by its hard-coded absolute path? (As in
"#!" of a script that is installed unmodified, as opposed to being
generated from a template.)

The situation I was talking about is where a build system auto-detects
the "correct" location for some tool, such as sed or perl, and writes
that detected location into an installed file - for example reading a
template that starts with #!@PERL@ and outputting an executable script
that starts with #!/usr/bin/perl, or similar. When this happens in a
binary package system like .deb, we need to make sure that the location
that will be detected on the build system is correct for all systems
where the .deb could get installed, even if the /usr-merge status of
the build system and the installed system are different (and we need to
continue to do this as long as both merged-/usr and non-merged-/usr are
supported). Upstreams that do this auto-detection are often trying to
help the use-case of portability of a single set of source code between
OSs, but unfortunately the auto-detection is sometimes unhelpful when a
single binary package is expected to support being installed on multiple
dissimilar but equally-supported OS configurations.

In both of these cases, during the transitional period that ends when
merged-/usr becomes required, package maintainers need to make sure
(by patching the source code, or configuring the build system, or
whatever other method is most suitable) that the package they maintain
will continue to work on non-merged-/usr Debian systems. There is no
requirement that Debian packages are portable to non-Debian systems,
however.

> The most common class of such files is
> those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
> not /bin/perl, etc.  I would ideally like this to be spelled out in
> Policy, as an explicit list of files that MUST be referred to without
> /usr, all others to be referred to with /usr.

A comprehensive list of executables whose paths in /{s,}bin can/should
be hard-coded seems at first glance as though it would be too large to
be particularly useful: on my x86_64 system, `apt-file search` tells
me it can see 245 files in /bin and 549 in /sbin. I'm confident that
many (most?) of those cannot be relied on to be in /bin,/sbin in all
non-Debian OSs.

As a 90% solution, it might be worthwhile to have a non-comprehensive
list of common interpreters and their canonical paths, but I think
Lintian is better-placed than Policy to do that, and it already has a list.

> As an upstream contributor to several pieces of software included in
> Debian, and as someone with an interest in ensuring that software
> developed on Linux is not *accidentally* unportable to other OSes
> under the 'Unix' umbrella, I'd like to stick an oar in

Sorry, I think portability to other Unixes is outside Debian's scope. One
of the advantages of merged /usr is that this is no longer something we
have to argue with each upstream that does not use (our idea of) the
canonical paths for everything, because both /bin and /usr/bin paths
will work.

With upstream hat on, I think this is going to be a losing battle in
general, because outside a few narrow areas that are fixed by Unix
folk history (mainly /bin/sh and /usr/bin/env), there is no portable
canonical path. For example, I regularly see merge requests to various
upstream projects saying that #!/bin/bash is not sufficiently portable
and they need to use #!/usr/bin/env bash on some OS - but in Debian,
we often prefer #!/bin/bash, to avoid packaged scripts being broken by
a locally-installed and potentially incompatible /usr/local/bin/bash.

smcv

Bug#994407: Binaries with same name

[ThePPK]

Package: needrestart
Version: 3.5-4

Needrestart while run once of scripts on 
/etc/needrestart/hook.d/30-pacman, execute pacman binary (which is Arch 
Linux package manager). In Debian we have a game with this same 
executable file name, 'pacman' and needrestart create process of pacman 
what run game window.
It's possible to force change name of pacman game or block running 
script while pacman (package manager) isn't installed in /sbin/, /bin/, 
/usr/bin/ or /usr/sbin/?

Bug#993210: mate-session-manager: mate-settings-daemon crashed

[Bernhard Übelacker]

Dear Maintainer, hello Mihai,
I tried to reconstruct the source line information of the top frames,
how they should look like if the packages
libgtk-3-0-dbgsym libglib2.0-0-dbgsym would have been installed.


#0  0x7fec909d1ce1 in __libc_signal_restore_set at 
../sysdeps/unix/sysv/linux/internal-signals.h:86
#1  0x7fec909bb537 in __GI_abort at abort.c:79
#2  0x7fec90b99dcc in g_assertion_message at ../../../glib/gtestutils.c:2937
#3  0x7fec90bf72fb in g_assertion_message_expr at 
../../../glib/gtestutils.c:2963
#4  0x7fec91288c36 in gtk_widget_get_frame_clock at 
../../../../gtk/gtkwidget.c:5871
#5  0x7fec9129748a in gtk_widget_realize at ../../../../gtk/gtkwidget.c:5541
#6  0x7fec91297668 in gtk_widget_map at ../../../../gtk/gtkwidget.c:5045
...

https://sources.debian.org/src/gtk+3.0/3.24.24-4/gtk/gtkwidget.c/#L5871


Kind regards,
Bernhard

Bug#994119: vdirsyncer: Random cannot import name 'metasync' with python3.9

[Benedikt Tuchen]

Hallo again,

On Sun, Sep 12, 2021 at 10:29:35AM +0200, Benedikt Tuchen wrote:
> I've made an update to Debian 11 and after the update I tried to use
> "vdirsyncer metasync" with my old configuration. While trying I got
> the following error message:
> 
> 
> error: Unknown error occurred: cannot import name 'metasync' from
> partially initialized module 'vdirsyncer.metasync' (most likely due
> to a circular import)
> (/usr/lib/python3/dist-packages/vdirsyncer/metasync.py)
> 
> 
> Every time I execute the command the result which tasks fail is
> different.

I've tested vdirsyncer on another device with Debian Bullseye and I
get the same error as on my main machine.

So it seems like this isn't only a personal issue.

Regards,
Benedikt


signature.asc
Description: PGP signature

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> Package: tech-ctte Severity: normal

Simon> As discussed in our last meeting, I think we should issue
Simon> more specific advice about merged-/usr, and in particular
Simon> about what #978636 means for maintainers right now.

I wasn't at this meeting, but as someone who has followed the merged
/usr discussions reasonably closely, I'd like to second the idea of
giving this advice.


I think we had a very productive discussion on debian-devel.
I think with a round or two more we could confirm project consensus on
some of the areas where you propose to give advice.

Honestly, though, I think  that having the TC give a decision in this
instance will be more effective and will take up less time overall.

I think the advice you propose to give is consistent with project
consensus where there is a consensus.  I think there are a couple of
areas, like gradual migration of paths where there is no rough consensus.  In
particular, I think Neils is not the only one who is uncomfortable
assuming that dpkg changes will eventually come along to better support
aliasing.
In those areas, advice is needed, and the TC is a body that can give
that advice.
The advice you are proposing to give seems technically sound to me.

So, thanks very much for your hard work on this issue!


signature.asc
Description: PGP signature

Bug#994182: headset functionality broken after recent update

[Felipe Sateler]

Hi,

I'm not sure what to do about this issue.

On Wed, Sep 15, 2021 at 10:57 AM debian-bugs  wrote:

> Back to pulseaudio and following
>
>  > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1247
>
> first answer by Igor Kovalenko
>

This suggest the problem is a kernel problem, but is uncovered by the new
HFP profile in pulse.


> I edited
>
> /etc/pulse/default.pa
>
> to match
>
> load-module module-bluetooth-discover enable_native_hfp_hf=false
>
> and with that parameter (enable_native_hfp_hf=false) things are back to
> normal.
> Couldn't find out what the equivalent setting for pipewire would be,
> that's why I went back to pulse.
>
> Positive side effect: ofono seems not to be necessary anymore.
>


This is the new feature :)

-- 

Saludos,
Felipe Sateler

Bug#975713: libcxxopts-dev: cxxopts should be architecture independent

[Boyuan Yang]

On Wed, 25 Nov 2020 10:37:23 -0500 Boyuan Yang  wrote:
> Control: severity -1 wishlist
> Control: tags -1 + help
> 
> 在 2020-11-25星期三的 13:22 +，Abhishek Dasgupta写道：
> > Package: libcxxopts-dev
> > Severity: normal
> > 
> > Hi,
> > 
> > cxxopts being a header-only library should be an -all package.
> 
> Unfortunately cxxopts comes with CMake config snippets, which will
> hardcode architecture detection strings, making it not cross-
> platformed. Dropping CMake scripts is not an option. See
> /usr/lib/cmake/cxxopts/cxxopts-config.cmake .
> 
> If you have any idea about how to solve this problem, please let me
> know.

A possible solution can be found at
https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#command:write_basic_package_version_file
, as well as https://github.com/jarro2783/cxxopts/pull/298/files .

Thanks,
Boyuan Yang


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

Bug#994406: ITP: node-mdn-browser-compat-data -- Compatibility data for Web technologies

[Yadd]

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

* Package name: node-mdn-browser-compat-data
  Version : 4.0.3
  Upstream Author : MDN Web Docs
* URL : https://github.com/mdn/browser-compat-data
* License : CC0-1.0
  Programming Lang: JavaScript
  Description : Compatibility data for Web technologies

@mdn/browser-compat-data contains browser compatibility data that
describes which platforms (where "platforms" are usually, but not always,
web browsers) support particular Web APIs.
.
This data can be used in documentation, to build compatibility tables
listing browser support for APIs.

This package is needed to upgrade node-y18n. It will be maintained under
JS Team umbrella

Bug#992339: Confirm

[Vincent Van Houtte]

Hi,

Glad I found this bug report, as I'm witnessing the same error messages 
in my journal after a clean install of Debian Bullseye (although not 
from a live iso - I used a netinstall iso in which I have incorporated a 
preseed file and non-free firmware).


I did only check the journal after installing my configuration via 
Ansible, so I cannot exclude that my configuration caused the error 
messages. One reason to believe that it was already present before my 
configuration is that the same configuration did not complain in Debian 
Buster (but neither pipewire nor xdg-desktop-portal were installed on 
those systems AFAIK).


I haven't been able to find anything relevant, except for this bug 
report. Happy to perform a few tests or provide more information.


--
Vincent Van Houtte

Bug#924664: ejabberd: node migration broken

[Anton Ivanov]

OK.

I will retest when I upgrade to current stable which should happen in the next 
few days.

A.

On 15/09/2021 15:38, Badlop wrote:


On Fri, 15 Mar 2019 at 17:42, Anton Ivanov
 wrote:

All files exist, retried several times with files both in /tmp/ and in
/var/lib/jabberd/ no difference in either case. It failes with "Table
config" message.

I tried this old report, using a recent ejabberd, and it works
correctly. Maybe the problem was related to some old bug?

For testing I set your hosts in /etc/hosts and the erlang node names
in ejabberdctl.cfg, to obtain a scenario similar to yours.

Some output, in case it gives some clue:

❯ ejabberdctl mnesia-change-nodename ejabberd@smaug
ejabb...@jabber.kot-begemot.co.uk /tmp/e/ejabberd.backup
/tmp/e/ejabberd.restore

  * Checking table: 'roster'
+ Checking key: 'ram_copies'
+ Checking key: 'disc_copies'
+ Checking key: 'disc_only_copies'
  - Replacing nodename: 'ejabberd@smaug' with:
''ejabb...@jabber.kot-begemot.co.uk''

...

  * Checking table: 'push_session'
+ Checking key: 'ram_copies'
+ Checking key: 'disc_copies'
+ Checking key: 'disc_only_copies'
  - Replacing nodename: 'ejabberd@smaug' with:
''ejabb...@jabber.kot-begemot.co.uk''
switched

❯ ls -la
total 124
-rw-r--r--  1 badlop badlop 22950 de set.  15 16:17 ejabberd.backup
-rw-r--r--  1 badlop badlop 23748 de set.  15 16:19 ejabberd.restore

❯ ejabberdctl registered_users localhost

❯ ejabberdctl restore /tmp/e/ejabberd.restore

❯ ejabberdctl registered_users localhost
admin
user1


By the way, a quick and dirty alternative is to not bother changing
the mnesia backup nodename, instead tell the new erlang node to use
the old node name (using ejabberdctl.cfg ERLANG_NODE)


--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Vincent Lefevre]

Package: libgmp10
Version: 2:6.2.1+dfsg-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

mpz_inp_raw segfaults (SEGV_MAPERR) on large sizes. I suspect that
this is due to an integer overflow in mpz/inp_raw.c:

  abs_xsize = BITS_TO_LIMBS (abs_csize*8);

See discussion
  https://gmplib.org/list-archives/gmp-bugs/2021-September/005077.html

and my comment
  https://gmplib.org/list-archives/gmp-bugs/2021-September/005086.html

I have not checked, but abs_xsize would be smaller than expected,
thus

  xp = MPZ_NEWALLOC (x, abs_xsize);

would allocate less than expected, thus I suppose that

  cp = (char *) (xp + abs_xsize) - abs_csize;

points to a location that is *before* the buffer.

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

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

Versions of packages libgmp10:i386 depends on:
ii  libc6  2.32-2

libgmp10:i386 recommends no packages.

libgmp10:i386 suggests no packages.

-- no debconf information

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

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Zack Weinberg]

As a Debian user I'm pleased to see the ctte taking proactive steps to
ensure that the merged-/usr transition will still allow smooth
upgrades from Debian 11 to 12 and 12 to 13.

As an upstream contributor to several pieces of software included in
Debian, and as someone with an interest in ensuring that software
developed on Linux is not *accidentally* unportable to other OSes
under the 'Unix' umbrella, I'd like to stick an oar in regarding:

On Wed, 15 Sep 2021 at 12:39:53 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> > - §(Building packages): I almost wrote an extra paragraph about
> >   how this class of bugs becomes a non-issue when merged-/usr is
> >   the only supported layout - but actually it doesn't! If we
> >   consider building packages while having /usr/local/bin/sed to be
> >   a supported thing you can do, then we need to ensure that
> >   /usr/local/bin/sed doesn't get hard-coded into the resulting
> >   package, and the steps you take to make that happen are the same
> >   as the steps you take to fix this class of bugs.
>
> I think that class of bugs probably does become non-RC when the
> merged-/usr transition is complete, though.

After the transition is complete, /usr/local is not the only possible
source of problems.  For the various files with a "canonical" location
either in /usr or in /, either specified by some standard or by
convention, and regularly referred to by absolute pathname, all
software should continue to refer to those files by their "canonical"
name, so that it remains portable to Unixes that have not and may
never undergo a /usr merge.  The most common class of such files is
those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
not /bin/perl, etc.  I would ideally like this to be spelled out in
Policy, as an explicit list of files that MUST be referred to without
/usr, all others to be referred to with /usr.

[I agree that from Debian's perspective it makes sense for these bugs
to be RC until the transition is complete, and non-RC afterward.]

zw

Bug#994404: ITP: python-types-typed-ast -- Typing stubs for typed-ast

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: python-types-typed-ast -- Typing stubs for typed-ast
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: python-types-typed-ast
  Version : 1.4.4
  Upstream Author : 
* URL : https://github.com/python/typeshed
* License : Apache-2.0
  Programming Lang: Python
  Description : Typing stubs for typed-ast
 This is a PEP 561 type stub package for the typed-ast package. It can be used 
by
 type-checking tools like mypy, PyCharm, pytype etc. to check code that uses
 typed-ast. The source for this package can be found at
 https://github.com/python/typeshed/tree/master/stubs/typed-ast.
 All fixes for types and metadata should be contributed there.
 .
 See https://github.com/python/typeshed/blob/master/README.md for more details.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-types-typed-ast

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Phil Morrell]

Thanks to Adrian and pabs for their corrections on documenting security
support, and there wasn't too much objection to the summary, more to the
sad state of affairs that leads to it and a bit of clarification.

I believe all the major points have cc'd 907051, so would like to
encourage someone more familiar with policy process than I am to draft
an amendment. There should be enough written there now to expand the
section accordingly with more recommendations, and possibly file
wishlist bugs for maintainers to document their reasons in the source.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907051


signature.asc
Description: PGP signature

Bug#994403: ITP: python-types-toml -- Typing stubs for toml

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: python-types-toml -- Typing stubs for toml
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: python-types-toml
  Version : 0.1.5
  Upstream Author : 
* URL : https://github.com/python/typeshed
* License : Apache-2.0
  Programming Lang: Python
  Description : Typing stubs for toml
 This is a PEP 561 type stub package for the toml package. It can be used by
 type-checking tools like mypy, PyCharm, pytype etc. to check code that uses
 toml. The source for this package can be found at
 https://github.com/python/typeshed/tree/master/stubs/toml.
 All fixes for types and metadata should be contributed there.
 . 
 See https://github.com/python/typeshed/blob/master/README.md for more details.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-toml-types

Bug#985912: eapol_test does not work with IPv6 because CONFIG_IPV6 is not enabled

[Christopher Schenk]

Hi,

we are also facing this problem and would love to see this config option 
set.


Best regards,

Christopher Schenk

Bug#994396: [Pkg-swan-devel] Bug#994396: strongswan: Please enable TPM2 via --enable-tss-tss2

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2021-09-15 at 15:53 +0200, Paride Legovini wrote:
> The Debian strongswan package doesn't currently have any TPM support,
> even if d/rules calls ./configure --enable-tpm, as actually enabling TPM
> requires a TSS (Tpm Software Stack) implementation. To enable TPM2 we
> need TSS2, which is enabled via --enable-tss-tss2 (which requires an
> additional build-dep: libtss2-dev).
> 
> Please consider adding those to the strongswan packaging.
> 
> Note: this still doesn't enable TPM1.2, for which --enable-tss-trousers
> is required. My suggestion is to avoid enabling it, and strongswan
> upstream Tobias Brunner agrees, see the discussion in the Ubuntu bug
> I linked.

Hi Paride,

thanks for the bug report and merge request. As said on that MR, it makes
sense to me since we already enable the TPM plugin, I'm just a bit confused
that it's an empty shell by default.

I'm not especially a huge fan of the remote attestation parts (the various
bits are really complex), but just having access to private keys sealed in the
TPM does look interesting to me.

I've set the flag to merge the request if the CI pipeline suceeds. Thanks!

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFCAX4ACgkQ3rYcyPpX
RFvyTggAxDgvoJNgK1aLrB/1FNQ8eYPcMKPt0l8deyfxRtFjSlrwMW8UOBJlnqkd
LuAeUd5tNLlvPIHCHazmSR8cyTIUDDcXc6+tzieuYrcetx6F9Ji8yUiz/AhhU1xY
UMmRXjl0MnYpuSASagw2txBlycNmCAB8NauBh5c34lp4Z9thzc7mtMw+scYuJBWD
4m2ZTQ6aX8PPvGQoYTt60IosqBWu9pDZAWF4DPBc/zbx0X45+Vn5bgkX2juZfTgv
33B0XylYbKKJde/WSLvb9x2XwkOLws0DpG18a+GUL5LfwRARx++8SyCxjOK8wJg8
+39lBvAcFMyrYBQYN+NMEPcJy4QIPw==
=IkBR
-END PGP SIGNATURE-

Bug#924664: ejabberd: node migration broken

[Badlop]

On Fri, 15 Mar 2019 at 17:42, Anton Ivanov
 wrote:
> All files exist, retried several times with files both in /tmp/ and in
> /var/lib/jabberd/ no difference in either case. It failes with "Table
> config" message.

I tried this old report, using a recent ejabberd, and it works
correctly. Maybe the problem was related to some old bug?

For testing I set your hosts in /etc/hosts and the erlang node names
in ejabberdctl.cfg, to obtain a scenario similar to yours.

Some output, in case it gives some clue:

❯ ejabberdctl mnesia-change-nodename ejabberd@smaug
ejabb...@jabber.kot-begemot.co.uk /tmp/e/ejabberd.backup
/tmp/e/ejabberd.restore

 * Checking table: 'roster'
   + Checking key: 'ram_copies'
   + Checking key: 'disc_copies'
   + Checking key: 'disc_only_copies'
 - Replacing nodename: 'ejabberd@smaug' with:
''ejabb...@jabber.kot-begemot.co.uk''

...

 * Checking table: 'push_session'
   + Checking key: 'ram_copies'
   + Checking key: 'disc_copies'
   + Checking key: 'disc_only_copies'
 - Replacing nodename: 'ejabberd@smaug' with:
''ejabb...@jabber.kot-begemot.co.uk''
switched

❯ ls -la
total 124
-rw-r--r--  1 badlop badlop 22950 de set.  15 16:17 ejabberd.backup
-rw-r--r--  1 badlop badlop 23748 de set.  15 16:19 ejabberd.restore

❯ ejabberdctl registered_users localhost

❯ ejabberdctl restore /tmp/e/ejabberd.restore

❯ ejabberdctl registered_users localhost
admin
user1


By the way, a quick and dirty alternative is to not bother changing
the mnesia backup nodename, instead tell the new erlang node to use
the old node name (using ejabberdctl.cfg ERLANG_NODE)