Bug#1016680: RM: gpaste -- RoQA; version 3.42.6-1 is cruft that didn't get autoremoved

2022-08-04 Thread Paul Wise
Package: ftp.debian.org
Severity: normal
Control: affects -1 + gpaste
X-Debbugs-CC: gpa...@packages.debian.org

Please remove version 3.42.6-1 of src:gpaste from Debian unstable.
It was superseded by 42.1-4 but dak didn't autocruft the old version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1016530:

2022-08-04 Thread Sam James
It looks like this might be 
https://gitlab.freedesktop.org/mesa/demos/-/issues/27 / 
https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/84.


signature.asc
Description: Message signed with OpenPGP


Bug#956012: debian-edu-config: use DuckDuckGo as Chromium's default search provider

2022-08-04 Thread Andres Salomon
Alright, got it - using the "recommended" subdirectory instead of 
"managed" does the trick. It'll be in the next release after 
104.0.5112.79-1.


On Wed, Aug 3, 2022 at 14:07, Andres Salomon  
wrote:
On Mon, 06 Apr 2020 06:30:53 + Mike Gabriel 
 wrote:

> Package: chromium
> Severity: wishlist
>
> Currently (during the bullseye release cycle), chromium uses Google 
as

> the default search provider.
>
> With the below snippet dropped into
> /etc/chromium/policies/managed/.json we could switch that 
to

> DuckDuckGo:
>
> {
> "DefaultSearchProviderEnabled":true,
> "DefaultSearchProviderName": "DuckDuckGo",
> 
"DefaultSearchProviderIconURL":"https://duckduckgo.com/favicon.ico;,

> "DefaultSearchProviderEncodings":["UTF-8"],
> 
"DefaultSearchProviderSearchURL":"https://duckduckgo.com/?q={searchTerms};,

>
> 
"DefaultSearchProviderSuggestURL":"https://duckduckgo.com/ac/?q={searchTerms}=list;,
> 
"DefaultSearchProviderNewTabURL":"https://duckduckgo.com/chrome_newtab;,

> }
>
> Maybe an option for Chromium in Debian?
>


Unfortunately, this recipe is for administrators that want to force a 
default search engine. There's no way to change the default search 
engine to something else through the UI, so this won't work for us. 
We just want to change the default search engine, and allow users to 
set it to something else (including back to Google, if that's their 
preference) in Settings -> Search Engine.




Bug#1016678: dose3: Overly sensitive to newlines in package control fields

2022-08-04 Thread Sven Mueller
Package: dose3
Version: 7.0.0-1
Tags: patch

dpkg, apt, grep-dctrl and other tools handle multi-line Depends,
Suggests, etc. fields just fine, even though policy only defines
Description as a multi-line field (and dpkg-gencontrol folds such
multiline fields in a source's debian/control into single line ones in
the resulting binary packages. However, since version 7.0.0, dose3's
debcheck falls over if a package has such a multiline headers.

See https://gitlab.com/irill/dose3/-/issues/17 and the associated pull-request.

The problem is surfaced by third party package build tools like bazel
(via pkg_deb, see https://github.com/bazelbuild/rules_pkg/issues/572).
I have also encountered this issue with third party packages that use
other build tools.

It would be nice to get this fixed in Debian, even if upstream is slow
on picking it up (the CI failure is solely because I didn't accept
some prompt before sending the PR).

Cheers,
Sven



Bug#1016677: ITP: golang-github-templexxx-cpu -- internal/cpu in Go ( add AVX512)

2022-08-04 Thread Nilesh Patra
Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-templexxx-cpu
  Version : 0.0.9-1
  Upstream Author : Temple3x
* URL : https://github.com/templexxx/cpu
* License : BSD-3-clause
  Programming Lang: Go
  Description : Provides CPU related information in Go
 internal/cpu(in Go standard lib) with these detections:
 .
 * AVX512
 * Cache Size
 * Invariant TSC
 .
 It also provides:
 .
 * False sharing range, see X86FalseSharingRange for X86 platform.
 * TSC frequency
 * Name
 * Family & Model



Bug#1016676: ITP: golang-github-templexxx-xorsimd -- XOR code engine in pure Go, more than 270GB/S per core

2022-08-04 Thread Nilesh Patra
Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-templexxx-xorsimd
  Version : 0.4.1-1
  Upstream Author : Temple3x
* URL : https://github.com/templexxx/xorsimd
* License : Expat
  Programming Lang: Go
  Description : XOR code engine in pure Go, more than 270GB/S per core
 Package xor implements a XOR code engine in pure Go.
 It can deliver more than 270GB/S per core. 



Bug#1016675: mke2fs: filesytem is corrupt if -D (direct io) is used (on an image file)

2022-08-04 Thread Alex King



Package: e2fsprogs
Version: 1.46.2-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Trying to create a filesystem on a file for loopback mounting


   * What exactly did you do that was ineffective
rm -f file
truncate file -s 1G
/sbin/mkfs.ext4 -D -E lazy_itable_init=0 -E lazy_journal_init=0 -i 12288 
-F -m1

file
sync # for good measure
/sbin/e2fsck -fn file


   * What was the outcome of this action?
Block bitmap differences:  +(32768--32896) +(98304--98432) +(163840--163968)
Fix? no

Free blocks count wrong for group #1 (32639, counted=32768).
Fix? no
...
Padding at end of inode bitmap is not set. Fix? no

Inode bitmap differences: Group 1 inode bitmap does not match checksum.
IGNORED.
Group 2 inode bitmap does not match checksum.
IGNORED.
...
file: ** WARNING: Filesystem still has errors **

file: 11/87424 files (0.0% non-contiguous), 14323/262144 blocks


   * What outcome did you expect instead?
I would have liked a filesystem that passes e2fsck without problems.
If I run the mkfs.ext4 command without -D, I don't see the problem.

I speculate that mkfs exits before IO is completed, and some writes
don't happen.  But I really don't know.  Else perhaps the kernel keeps
an outdated copy of the filesystem in cache, that is not updated or 
flushed when the direct writes happen.  I have not tested this on a

partition, I guess that is more likely to complete successfully.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.36.1-8+deb11u1
ii  libc62.31-13+deb11u3
ii  libcom-err2  1.46.2-2
ii  libext2fs2   1.46.2-2
ii  libss2   1.46.2-2
ii  libuuid1 2.36.1-8+deb11u1
ii  logsave  1.46.2-2

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.4-1

-- no debconf information

Thanks,
Alex



Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa

2022-08-04 Thread Axel Beckert
Hi Manuel,

Manuel A. Fernandez Montecelo wrote:
> > I know you're busy with RISC-V and other stuff, but please do me a
> > small favour and add me to the cwidget team on Salsa, probably via
> > https://salsa.debian.org/groups/cwidget-team/-/group_members
> 
> Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to
> spare in the last few years, and even there I'm lacking :-(

Oh. :-/

> I had seen this from pabs but will not have time at least until mid
> next week, so better if you do it and have permissions in general
> anyway, as you say.

Thanks for adding my to the cwidget team. I will do an cwidget upload
within the next few days and afterwards an aptitude upload.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1016636: puddletag: An error occurs while retriving metatags from Discogs.com

2022-08-04 Thread Sandro Tosi
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Searching for tags for any available album using Discogs.com release id.
>
>* What was the outcome of this action?
> Message reads: "An error occured: local variable '__reference_time' referenced
> before assignment".

can you run `puddletag` from a terminal window and report back the
full traceback printed there? even better, you can submit an issue
upstream at https://github.com/puddletag/puddletag/issues/new/choose
or thru the menu entry "Help > Report an issue" in puddletag.

please also be aware of
https://github.com/puddletag/puddletag/issues/725#issuecomment-1162469701

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



Bug#1016628: gcc-12: makes nodejs testsuite fail on mips64el/riscv64 only

2022-08-04 Thread YunQiang Su
Jérémy Lal  于2022年8月4日周四 18:39写道:
>
>
>
> Le jeu. 4 août 2022 à 12:36, Xi Ruoyao  a écrit :
>>
>> On Thu, 2022-08-04 at 18:18 +0800, YunQiang Su wrote:
>> > > Hi,
>> > >
>> > > If nodejs 18.6.0 is built using gcc-12, several tests fail,
>> > > but not when built using gcc-11 (all other things being equal).
>> > >
>> > > *Only* on mips64el and riscv64.
>> > >
>> > > In the logs, some new warnings show up, maybe that can help:
>> > > https://buildd.debian.org/status/fetch.php?pkg=nodejs=mips64el=18.6.0%2Bdfsg-4=1659454899=0
>> > >
>> > > in particular:
>> > > /usr/include/c++/12/bits/atomic_base.h:488:31: warning: ‘long
>> > > unsigned int __atomic_load_8(const volatile void*, int)’ writing 8
>> > > bytes into a region of size 0 overflows the destination [-Wstringop-
>> > > overflow=]
>> > >488 | return __atomic_load_n(&_M_i, int(__m));
>> > >
>> >
>> > @Xi Ruoyao Is this what you are working on?
>>
>> If we have evidence showing it's a GCC code generation bug, I'll try to
>> fix it.  I don't have any interest in node.js.
>

I mean is it about then zero legth var in C++?

>
> No evidence yet.
> Upstream nodejs says it might very well be a bug on their side.
> I'll reassign accordingly.
>
>



-- 
YunQiang Su



Bug#922545: [pkg-lxc-devel] Bug#922545: lxc: FTBFS on hppa -

2022-08-04 Thread Mathias Gibbens
Control: tags -1 +pending -moreinfo

Hi Tom,

On Mon, 1 Aug 2022 15:20:02 +0200 "Tom Turelinckx" 
wrote:
> Architecture-specific symbols files can be supplied by naming them
liblxc1.symbols., for example liblxc1.symbols.sparc64. The
attached liblxc1.symbols.sparc64 was created by copying liblxc1.symbols
and then applying the attached symbols.diff. I think the same file
could be used for liblxc1.symbols.alpha, liblxc1.symbols.m68k,
liblxc1.symbols.sh4 and liblxc1.symbols.sparc64. I have verified that
building lxc 4.0.11-1 against sid on sparc64 succeeds when the attached
liblxc1.symbols.sparc64 is included in the debian directory.
> 
> Another approach could be to lower DPKG_GENSYMBOLS_CHECK_LEVEL to 0
on architectures where libseccomp-dev is not available. This will still
log the symbol differences but without failing the build. This can be
achieved by applying the attached rules.diff against debian/rules. This
approach avoids having to maintain architecture-specific symbols files.
I have verified that building lxc 4.0.11-1 against sid on sparc64
succeeds with the attached rules.diff applied.
> 
> Both approaches are documented at [1].
> 
> Could you please consider adopting either one of these approaches?
Thanks!

  Thank you for providing those examples! I think the cleanest and most
easily maintained approach would be to modify d/rules to make a symbol
difference non-fatal for those architectures we know are missing
libseccomp. Having to maintain multiple different .symbol files for
specific architectures seems error prone to me, and since the only
difference should be the lack of libseccomp-related symbols, I think
that's OK.

  I have a commit staged locally, but don't want to push it up to
master without seeking input from others.

Mathias

> [1]:
https://manpages.debian.org/unstable/dpkg-dev/dpkg-gensymbols.1.en.html


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


Bug#1016672: bullseye-pu: package grub2/2.06-3~deb11u1

2022-08-04 Thread Steve McIntyre
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hey folks,

This is the current upstream version of grub2 (2.06), built for
bullseye as an upgrade path from 2.04-20. I know we normally don't
want to do this kind of thing, but I believe this is genuinely the
best way to keep on top of grub2 security issues.

Grub2 has had several sets of major security updates in the last couple
of years, particularly relevant in Secure Boot terms (BootHole et
al). Back before the bullseye release, Colin spent a *lot* of time
rebasing security fixes from GRUB 2.04 onto the 2.02 that we were
using in buster, and I know he was very worried about breaking some of
them and maybe introducing new holes. AFAICS it worked ok that time,
but...

We're now on to upstream 2.06 in unstable and bookworm, and that's
been the target for upstream hardening and patch work that's been
needed for the latest round of CVEs. There's also been a lot of code
scanning and static analysis done to find more issues before they
becoms CVE-worthy, and that's great!

There are some backported fixes to go into 2.04 and I've seen people
talking about 2.02 as well. *However*, I'm very worried that we don't
have the time and skills available to verify all the fixes against
three different upstream releases :-(.

The debdiff for the changes is way too large to include here. They're
obviously not minimal. If you really want to see it, look at [1].

I've tested locally on various machines using both UEFI and BIOS boot,
and all looks good here. The existing 2.06-3 package in bookworm that
I based on seems stable enough. The only real change I've made to that
(beyond usual backport noise) is to revert the change that disables
os-prober by default. I don't think that change is suitable for a
stable update.

[1] https://jack.einval.com/tmp/grub2_2.06-3~deb11u1.debdiff.gz


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

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



Bug#1016671: buster-pu: package grub2/2.06-3~deb10u1

2022-08-04 Thread Steve McIntyre
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hey folks,

This is the current upstream version of grub2 (2.06), built for buster
as an upgrade path from 2.02+dfsg1-20+deb10u4. I know we normally
don't want to do this kind of thing, but I believe this is genuinely
the best way to keep on top of grub2 security issues.

Grub2 has had several sets of major security updates in the last couple
of years, particularly relevant in Secure Boot terms (BootHole et
al). Back before the bullseye release, Colin spent a *lot* of time
rebasing security fixes from GRUB 2.04 onto the 2.02 that we were
using in buster, and I know he was very worried about breaking some of
them and maybe introducing new holes. AFAICS it worked ok that time,
but...

We're now on to upstream 2.06 in unstable and bookworm, and that's
been the target for upstream hardening and patch work that's been
needed for the latest round of CVEs. There's also been a lot of code
scanning and static analysis done to find more issues before they
becoms CVE-worthy, and that's great!

There are some backported fixes to go into 2.04 and I've seen people
talking about 2.02 as well. *However*, I'm very worried that we don't
have the time and skills available to verify all the fixes against
three different upstream releases :-(.

The debdiff for the changes is way too large to include here. They're
obviously not minimal. If you really want to see it, look at [1].

I've tested locally on various machines using both UEFI and BIOS boot,
and all looks good here. The existing 2.06-3 package in bookworm that
I based on seems stable enough. The only real change I've made to that
(beyond usual backport noise) is to revert the change that disables
os-prober by default. I don't think that change is suitable for a
stable update.

[1] https://jack.einval.com/tmp/grub2_2.06-3~deb10u1.debdiff.gz

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

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



Bug#1016523: meson >= 0.61

2022-08-04 Thread Mathias Gibbens
Control: tags -1 + pending

Hi Harri,

  Thanks for the report -- I've added a versioned dependency for meson
to d/control and it will be included in the next upload.

Mathias


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


Bug#1002956: Remote RCE in rabbitmq-server

2022-08-04 Thread Tim Abbott
On Wed, Aug 3, 2022 at 12:22 AM Thomas Goirand  wrote:

> Hi Tim,
>
> Please don't top-post, we don't do that in Debian, and also:
>

Apologies!

FYI, I'm sad too, but there's nothing I can do but pinging again the
> stable release team about this. You hear me well: the stable release
> team. Not the security team since they do not want to do a security
> announcement and an update through stable-security (so it shall be done
> through a point release, dealing with the stable release team).
>
> This means writing to 1002...@bugs.debian.org. That's the only email
> address that has influence on accepting the fixed version. Feel free to
> ping that email address until you get a reply. I agree that no reply
> since the 29th of Jan is sad...
>

I still don't understand why the determination was made to not do a
security announcement for this bug, given that it makes a Debian system
that installs this package vulnerable to remote RCE without manual
intervention.

But given that determination was made, perhaps the best way I can
contribute is by making sure this bug thread links to
https://blog.zulip.com/2022/01/25/zulip-server-4-9-security-release/#cve-2021-43799-remote-code-execution-vulnerability-involving-rabbitmq,
which has a bunch of public context about the impact of this bug, as well
as background explanation that may help release managers who don't know
much about Erlang/RabbitMQ.

-Tim Abbott


Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa

2022-08-04 Thread Manuel A. Fernandez Montecelo
Hi,

On Thu, 4 Aug 2022 at 18:03, Axel Beckert  wrote:
>
> Hi Manuel,
>
> TL;DR: Please grant me cwidget team membership on Salsa so we don't
> have to NMU it. Or just do an upload of cwidget with the patch from
> #1015925.
>
> I know you're busy with RISC-V and other stuff, but please do me a
> small favour and add me to the cwidget team on Salsa, probably via
> https://salsa.debian.org/groups/cwidget-team/-/group_members

Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to
spare in the last few years, and even there I'm lacking :-(

I had seen this from pabs but will not have time at least until mid
next week, so better if you do it and have permissions in general
anyway, as you say.

Thanks both of you, pabs and abe, for taking care!

-- 
Manuel A. Fernandez Montecelo 



Bug#1016670: libconfig-model-dpkg-perl: autopkgtest failures

2022-08-04 Thread gregor herrmann
Source: libconfig-model-dpkg-perl
Version: 2.162
Severity: serious
Justification: autopkgtest failures are serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libconfig-model-dpkg-perl fails its autopkgtests both on ci.d.n and
locally. (But not the tests during build.)

https://ci.debian.net/data/autopkgtest/unstable/amd64/libc/libconfig-model-dpkg-perl/24124550/log.gz
and copied from a local test:

…
ok 106 - test debhelper migration
In config class 'Dpkg::Control::Source', (location: control source Vcs-Browser) 
element 'Vcs-Browser' (level normal) has a configuration model error:
Compute argument 'pkgname', error with '- Source':
Configuration item 'control source Source' has a wrong value:
Undefined mandatory value.
value is computed from 'use Cwd; my $res = getcwd =~ 
m!/([a-z0-9][a-z0-9+.-]+)$! ? $1 : undef;
'

# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 106.
Dubious, test returned 255 (wstat 65280, 0xff00)
All 106 subtests passed

2022/08/04 22:40:52 write backend Dpkg Config::Model::Backend::Dpkg::write 
failed: In config class 'Dpkg', (location: changelog) element 'changelog' 
(level normal) has a configuration model error:
Compute argument 'pkg_name', error with '! control source Source':
Configuration item 'control source Source' has a wrong value:
Undefined mandatory value.
value is computed from 'use Cwd; my $res = getcwd =~ 
m!/([a-z0-9][a-z0-9+.-]+)$! ? $1 : undef;
'
…
2022/08/04 22:40:53 write backend Dpkg::Control 
Config::Model::Backend::Dpkg::Control::write failed: Configuration item 
'control source Source' has a wrong value:
Undefined mandatory value.
value is computed from 'use Cwd; my $res = getcwd =~ 
m!/([a-z0-9][a-z0-9+.-]+)$! ? $1 : undef;
'
Configuration item 'control source Source' has a wrong value:
Undefined mandatory value.
value is computed from 'use Cwd; my $res = getcwd =~ 
m!/([a-z0-9][a-z0-9+.-]+)$! ? $1 : undef;
'
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
Dubious, test returned 255 (wstat 65280, 0xff00)
All 1 subtests passed
…
Test Summary Report
- ---
t/dependency-check.t(Wstat: 65280 Tests: 106 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/dpkg.t(Wstat: 65280 Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output


Cheers,
gregor


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmLsTPZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZYGxAAinz/gSzn2nE8VI2sFIySHIp+S56WyiRKV23chG2dOQ3osq8WDQ9U5Oq1
inJd5xcOmKKmBcZ7weoC8IeLhCrIKPDzvp5/YzDPUkXSMehANBqzJi9baXbZjkUG
QTnRmoF4Os7+0PqU9Ji8bQtcWSAeW01SFYRGNWi2dmGAorPAewMSoQ2NF9G+a/4U
XtHjdQt2dJd0TFwdK1s/KeKHvE5sGqhLDBzoxb6R9nV7e5zMjDsNTxzG8vuv6qVz
qb0mviF+hKEZtKYloiotKY19sxh5ecqhx0GGuADl5jkTXB5Wv9nxSlU3f30oDqN+
Ynjyu78gLTnpWDPSpl58ShXCJRszUPhH3hc04yu3c/moxKn6L3oXkjZoKY/CBi2S
dDpFr/x+eXLDYhSFHsLROAm6mZ5CffnAfQYSKE8hQup5f4+9pnB4gxQbDewxsb+l
yjfewjTK6mZ3H9CMIX33d+Ai6LLrInr7vZNTIu8mf7YFaZC98mt8S/w/0g95s1/r
Ozl5vylt40oEEG4ZftwqW8+Wt1MJG5r2hS3klLzXD85DWiHKDfsT7EE+nEo7P8s7
6ChLhRv0nzYqG9NKwqpYnBxa1/q+ul0MNu5GXTHHUiB4FyxXbZ8jDQZtKwYrVpXp
AGoSG1+iChjCNSsPoR9KUxEN0VLH6udgKryRq5Nq+pVbyfEJn4Y=
=jaGK
-END PGP SIGNATURE-


Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread Bob Friesenhahn
Testing with ImageMagick 6.9.12-38 on an Illumos system shows the 
image the other way around with the bright pink cone laying on what 
might be a gray floor.  Due to the nature of the image, it is 
difficult to tell what the right way up is.


It appears that ImageMagick 6.9.10-23 and 6.9.12-38 do not display the 
same output!


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread Bob Friesenhahn

On Thu, 4 Aug 2022, Bob Friesenhahn wrote:


On Thu, 4 Aug 2022, László Böszörményi (GCS) wrote:


I see that a bit of code in 'tga.c' dealing with image orientation was
commented out because the compiler warned that it produced an invalid
result.  That was unfortunately not attended to.

Did you fix it with changeset 16721 [1]? I don't have time to compile
and check it ATM, but might package it tomorrow if it's a proper fix.


No it is not fixed yet.  I fixed a different bug, which caused some sample 
files to not be read at all.


While it would not surprise me all if there is an orientation bug in 
GraphicsMagick, for the provided case, the image shown by ImageMagick 
6.9.10-23 and GraphicsMagick is exactly the same.


The orientation which likely has issues is the exceedingly rare case 
where the row pixels may need to be written in reverse.


Can this issue be reproduced independently?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#990047: timeshift: Not possible to browse content of snapshot via the gui

2022-08-04 Thread Steve M
On Mon, 2022-08-01 at 22:26 +, Ludovic Poujol wrote:
> Steeve,
> 
> Good question. And, you're right, thanks !
> 
> I thought it was some kind of "internal browser" provided with 
> timeshift. But after looking more closely, it was actually trying to 
> start VSCode ! :s And it's the one that do not like to be run as
> root.
> 
> Not sure why or how it decided to use it instead of the Gnome file 
> browser. But apt remove of it "fixed" the issue.
> 
> I don't see any settings for that in the timeshift GUI. I'm not sure
> how 
> I can force it to use the default gnome file browser :(
> 
> 
> Thanks
> 
> --
> Ludovic Poujol

Ludovic,

Timeshift first uses xdg-open to call the default tool of your desktop
environment as it in turn calls gvfs-open, kde-open, exo-open, gnome-
open, etc. as appropriate. On my Debian desktop with KDE running xdg-
open and kde-open launche Dolphin, but on my Pop_OS laptop xdg_open is
not installed and there is no gvfs-open for some reason.

In the event that xdg_open fails, Timeshift tries in order to launch
nemo, nautilus, thunar, io.elementary.files, pantheon-files, marlin,
and dolphin lastly.

In your case it seems that maybe xdg-open is resulting in "code" being
called due to your Gnome settings. The command `xdg-mime query default
inode/directory` should report out what the default file browser is set
to. You can also look in ~/.config/mimeapps.list to see what it is set
to. I think you can just edit this file or run a command similar to
`xdg-mime default org.gnome.Nautilus.desktop inode/directory` to make a
change.

Please let me know how this works out as it may be worth asking
upstream for a more robust means of opening the default file manager.

Thanks
-Steve



Bug#1016624: RFS: psi-notify/1.3.0-1 -- Alert when your machine is becoming oversaturated

2022-08-04 Thread Paul Wise
On Thu, 2022-08-04 at 14:53 -0500, Michel Alexandre Salim wrote:

> Saw that from the notes you gave to the initial upload too. I checked
> libsystemd.pc and... there's nothing we can use there, unfortunately.

How about this?

pkg-config --variable systemd_user_unit_dir systemd

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1016668: kicad-packages3d - Unreachable maintainer

2022-08-04 Thread Bastian Blank
Source: kicad-packages3d
Version: 6.0.7-1
Severity: serious

Mails sent by the archive to the maintainer are rejected with the
following message:

| Action: failed
| Final-Recipient: rfc822;c.schoen...@t-online.de
| Status: 5.0.0
| Remote-MTA: dns; mx02.t-online.de
| Diagnostic-Code: smtp; 554 IP=194.177.211.212 - A problem occurred. (Ask your 
postmaster for help or to contact t...@rx.t-online.de to clarify.)

Bastian

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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



Bug#1016667: Should this package be removed?

2022-08-04 Thread Moritz Muehlenhoff
Source: caldav-tester
Version: 7.0+20190225-4
Severity: serious

Your package came up as a candidate for removal from Debian:
The plan is to remove Python 2 in Bookworm and there's no
porting activity towards Python 3.

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

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

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

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

Cheers,
Moritz



Bug#938645: telepathy-salut: Python2 removal in sid/bullseye

2022-08-04 Thread Moritz Mühlenhoff
severity 938645 serious
thanks

Am Fri, Aug 30, 2019 at 07:55:27AM + schrieb Matthias Klose:
> Package: src:telepathy-salut
> Version: 0.8.1-5.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

The plan is to remove Python 2 in bookworm, bumping severity to RC.

Cheers,
Moritz



Bug#1016666: RM: iotjs -- RoQA; unmaintained, open security issues, depends on Python 2

2022-08-04 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

See #1011124

Cheers,
Moritz



Bug#1016665: RM: gspiceui -- RoQA; Blocks removal of geda-gaf, unmaintained

2022-08-04 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove gspiceui. It blocks the removal of geda-gaf (#1008700) and
#967915 hasn't seen maintainer action since two years.

Cheers,
Moritz



Bug#1016664: RM: easyspice -- RoQA; depends on geda-gaf which is being removed

2022-08-04 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove easyspice. It blocks the removal of geda-gaf (#1008700) and
#967916 hasn't seen a reply in two years.

Cheers,
Moritz
   



Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-04 Thread Jurij Smakov
On Wed, Aug 3, 2022 at 5:37 PM Dima Kogan  wrote:

> Jurij Smakov  writes:
>
> > I tried launching notion under rr, and then this assertion does not
> > trigger, unfortunately.
>
> That's too bad. Thanks for trying it out.
>
> This issue is a race condition, and rr inherently limits the process to
> one core. Can you try "rr record --chaos"? This randomizes the thread
> switching, and is often effective and triggering these kinds of failures
> under rr.
>

Did not have much luck with --chaos either, the assertion does not trigger.

I was able to get a fully symbolized trace with gdb though, it can be found
here: http://wooyd.org/dbg/notion.backtrace.txt

Does this help? It would probably be useful to get backtraces for other
threads as well, but I was not able to quickly figure out how to get rid of
this warning:

"warning: Unable to find libthread_db matching inferior's thread library,
thread debugging will not be available."

which might be preventing me from accessing other threads' information.


-- 
Jurij Smakov | ju...@wooyd.org | Key ID: 43C30A7D


Bug#1016662: libpgjava: CVE-2022-31197: SQL Injection in ResultSet.refreshRow() with malicious column names

2022-08-04 Thread Salvatore Bonaccorso
Source: libpgjava
Version: 42.4.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libpgjava.

CVE-2022-31197[0]:
| PostgreSQL JDBC Driver (PgJDBC for short) allows Java programs to
| connect to a PostgreSQL database using standard, database independent
| Java code. The PGJDBC implementation of the
| `java.sql.ResultRow.refreshRow()` method is not performing escaping of
| column names so a malicious column name that contains a statement
| terminator, e.g. `;`, could lead to SQL injection. This could lead to
| executing additional SQL commands as the application's JDBC user. User
| applications that do not invoke the `ResultSet.refreshRow()` method
| are not impacted. User application that do invoke that method are
| impacted if the underlying database that they are querying via their
| JDBC application may be under the control of an attacker. The attack
| requires the attacker to trick the user into executing SQL against a
| table name who's column names would contain the malicious SQL and
| subsequently invoke the `refreshRow()` method on the ResultSet. Note
| that the application's JDBC user and the schema owner need not be the
| same. A JDBC application that executes as a privileged user querying
| database schemas owned by potentially malicious less-privileged users
| would be vulnerable. In that situation it may be possible for the
| malicious user to craft a schema that causes the application to
| execute commands as the privileged user. Patched versions will be
| released as `42.2.26` and `42.4.1`. Users are advised to upgrade.
| There are no known workarounds for this issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-31197
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31197
[1] 
https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-r38f-c4h4-hqq2https://github.com/pgjdbc/pgjdbc/commit/739e599d52ad80f8dcd6efedc6157859b1a9d637

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1002227: Move to templexxx-xorsimd? (Was: Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returne

2022-08-04 Thread Nilesh Patra

On 8/5/22 1:18 AM, Shengjing Zhu wrote:

On Fri, Aug 5, 2022 at 3:39 AM Nilesh Patra  wrote:


Hi,

On 8/5/22 12:42 AM, Shengjing Zhu wrote:

On Fri, Aug 5, 2022 at 3:09 AM Nilesh Patra  wrote:


Control: severity -1 important

I am uploading a new revision shortly disabling this
test so it allows revdeps to migrate atleast most which have nothing
to do with the failing function test in question.


If what you assert is correct


Checked this earlier.
Locally building revdeps with removed function seems to have no effect
on their build/autopkgtests.


why not just remove the broken
function and then close this bug?


I am not sure if it is worth doing so now, provided we should
switch to xorsimd. However I have pushed a patch to git repo removing that
function.
Please feel free to upload if you think otherwise.



I reviewed your patch, but it's wrong.

BytesSrc0 is used by
https://codesearch.debian.net/search?q=BytesSrc0+package%3A%5CQgolang-github-audriusbutkevicius-kcp-go%5CE=1


Hmmm, It didn't build this one locally, probably something wrong with my local
config then.


Though I think golang-github-audriusbutkevicius-kcp-go should be
removed from the archive instead.


This does not seem to have any rev-dep. And even the URL it points to no longer
exists.

https://github.com/AudriusButkevicius/kcp-go


But what you assert is wrong.


Yeah, my bad. Something wrong locally.

--
Best,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1016209: Disregard last message

2022-08-04 Thread Ignacio Vargas
Nevermind, it was a mistake on my part. Bug is indeed resolved in mangohud
0.6.8-1


Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread Bob Friesenhahn

On Thu, 4 Aug 2022, László Böszörményi (GCS) wrote:


I see that a bit of code in 'tga.c' dealing with image orientation was
commented out because the compiler warned that it produced an invalid
result.  That was unfortunately not attended to.

Did you fix it with changeset 16721 [1]? I don't have time to compile
and check it ATM, but might package it tomorrow if it's a proper fix.


No it is not fixed yet.  I fixed a different bug, which caused some 
sample files to not be read at all.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread GCS
Hi Bob,

On Thu, Aug 4, 2022 at 9:39 PM Bob Friesenhahn
 wrote:
> On Thu, 4 Aug 2022, Ivan Shmakov wrote:
> >   While graphicsmagick claims to support ‘Truevision Targa’
> >   format, its implementation is apparently slightly defective
> >   in that the images are read and written with their vertical
> >   axis reversed.  Consider, for instance, SHAPES.TGA from [1]:
> >   it’s shown with the gray (#9c9c9c) ‘floor’ at the bottom of
> >   the image by both LDPCXTGA.EXE and ImageMagick’s display(1),
> >   yet $ gm display SHAPES.TGA shows the floor at the /top/ of
> >   the image instead.
>
> I see that a bit of code in 'tga.c' dealing with image orientation was
> commented out because the compiler warned that it produced an invalid
> result.  That was unfortunately not attended to.
 Did you fix it with changeset 16721 [1]? I don't have time to compile
and check it ATM, but might package it tomorrow if it's a proper fix.

Thanks,
Laszlo/GCS
[1] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/2504f4ed1a52



Bug#1002227: Move to templexxx-xorsimd? (Was: Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returne

2022-08-04 Thread Shengjing Zhu
On Fri, Aug 5, 2022 at 3:39 AM Nilesh Patra  wrote:
>
> Hi,
>
> On 8/5/22 12:42 AM, Shengjing Zhu wrote:
> > On Fri, Aug 5, 2022 at 3:09 AM Nilesh Patra  wrote:
> >>
> >> Control: severity -1 important
> >>
> >> I am uploading a new revision shortly disabling this
> >> test so it allows revdeps to migrate atleast most which have nothing
> >> to do with the failing function test in question.
> >
> > If what you assert is correct
>
> Checked this earlier.
> Locally building revdeps with removed function seems to have no effect
> on their build/autopkgtests.
>
> > why not just remove the broken
> > function and then close this bug?
>
> I am not sure if it is worth doing so now, provided we should
> switch to xorsimd. However I have pushed a patch to git repo removing that
> function.
> Please feel free to upload if you think otherwise.
>

I reviewed your patch, but it's wrong.

BytesSrc0 is used by
https://codesearch.debian.net/search?q=BytesSrc0+package%3A%5CQgolang-github-audriusbutkevicius-kcp-go%5CE=1

Though I think golang-github-audriusbutkevicius-kcp-go should be
removed from the archive instead.

But what you assert is wrong.

-- 
Shengjing Zhu



Bug#1016661: cinnamon-desktop-environment: Please don't recommend empathy

2022-08-04 Thread Jeremy Bicha
Source: cinnamon-desktop-environment
Version: 5.2.2

empathy will not be included in the next Debian stable release. Please
drop it from your alternate recommends.

For more details, see https://bugs.debian.org/1016659

Thank you,
Jeremy Bicha



Bug#1016658: kalgebra: asserton failed on start

2022-08-04 Thread karogyoker
Package: kalgebra
Version: 4:20.12.1-1
Followup-For: Bug #1016658
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

I've tried the same in a VM on a Haswell CPU.
I removed chromium related packages and installed epiphany-web.
These steps don't interfere with kalgebra.
Even before and after these steps kalgebra was working correctly.
It might have to do something with SSE2 or SSE3 maybe?



Bug#1002227: Move to templexxx-xorsimd? (Was: Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returne

2022-08-04 Thread Nilesh Patra

Hi,

On 8/5/22 12:42 AM, Shengjing Zhu wrote:

On Fri, Aug 5, 2022 at 3:09 AM Nilesh Patra  wrote:


Control: severity -1 important

I am uploading a new revision shortly disabling this
test so it allows revdeps to migrate atleast most which have nothing
to do with the failing function test in question.


If what you assert is correct 


Checked this earlier.
Locally building revdeps with removed function seems to have no effect
on their build/autopkgtests.


why not just remove the broken
function and then close this bug?


I am not sure if it is worth doing so now, provided we should
switch to xorsimd. However I have pushed a patch to git repo removing that
function.
Please feel free to upload if you think otherwise.

--
Best,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread Bob Friesenhahn

On Thu, 4 Aug 2022, Ivan Shmakov wrote:


While graphicsmagick claims to support ‘Truevision Targa’
format, its implementation is apparently slightly defective
in that the images are read and written with their vertical
axis reversed.  Consider, for instance, SHAPES.TGA from [1]:
it’s shown with the gray (#9c9c9c) ‘floor’ at the bottom of
the image by both LDPCXTGA.EXE and ImageMagick’s display(1),
yet $ gm display SHAPES.TGA shows the floor at the /top/ of
the image instead.


I see that a bit of code in 'tga.c' dealing with image orientation was 
commented out because the compiler warned that it produced an invalid 
result.  That was unfortunately not attended to.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#1016394: column_family.cc:1494: rocksdb::ColumnFamilySet::~ColumnFamilySet(): Assertion `last_ref' failed.

2022-08-04 Thread GCS
Control: tags -1 +upstream -moreinfo
Control: forwarded -1 https://github.com/facebook/rocksdb/issues/10474

On Thu, Aug 4, 2022 at 9:46 AM Linas Vepstas  wrote:
> I just built-from-source & tested today's version of 
> https://github.com/facebook/rocksdb/ -- the problem persists.  It reports 
> that it is version 7.6.0
>
> I opened https://github.com/facebook/rocksdb/issues/10474 to report the 
> problem - its more-or-less a duplicate of this issue.
 Thanks for the feedback, I will try to follow that bug report and see
when upstream does fix it.

Regards,
Laszlo/GCS



Bug#1016659: empathy: depends on libsoup2.4

2022-08-04 Thread Jeremy Bicha
Source: empathy
Version: 3.25.90+really3.12.14-2
Severity: serious

An app can't link against both libsoup2.4 and libsoup3 simultaneously.
empathy depends on libsoup2.4 but it also depends on several libraries
that will be switching to libsoup3.

There is no longer an upstream for empathy. Empathy was archived more
than a year ago which means bug reports, translation updates, and even
bugfixes are no longer being accepted.

https://gitlab.gnome.org/GNOME/empathy

We will likely need to remove Empathy from Debian soon.

Thank you,
Jeremy Bicha



Bug#1002227: Move to templexxx-xorsimd? (Was: Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returne

2022-08-04 Thread Shengjing Zhu
On Fri, Aug 5, 2022 at 3:09 AM Nilesh Patra  wrote:
>
> Control: severity -1 important
>
> I am uploading a new revision shortly disabling this
> test so it allows revdeps to migrate atleast most which have nothing
> to do with the failing function test in question.

If what you assert is correct , why not just remove the broken
function and then close this bug?

-- 
Shengjing Zhu



Bug#1002227: Move to templexxx-xorsimd? (Was: Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returne

2022-08-04 Thread Nilesh Patra
Control: severity -1 important

I am uploading a new revision shortly disabling this
test so it allows revdeps to migrate atleast most which have nothing
to do with the failing function test in question.

Will go ahead with packaging xorsimd in next weeks (occupied with RL)
unless no-one beats me to it.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature


Bug#1016658: kalgebra: fails to start: assertion failed

2022-08-04 Thread karogyoker
Package: kalgebra
Version: 4:20.12.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

I use Debian Edu 11.4 Standard install for i386 on an Athlon XP.
When I try to start kalgebra from Terminal, this is what I get:

(kalgebra:3838): Gtk-CRITICAL **: 14:28:36.532: 
_gtk_css_ease_value_new_cubic_bezier: assertion 'x1 <= 1.0' failed

(kalgebra:3838): Gtk-CRITICAL **: 14:28:36.534: _gtk_css_array_value_new: 
assertion 'content != NULL' failed
**
Gtk:ERROR:../../../../gtk/gtkcssstylepropertyimpl.c:87:gtk_css_style_property_register:
 assertion failed: (initial_value != NULL)
Bail out! 
Gtk:ERROR:../../../../gtk/gtkcssstylepropertyimpl.c:87:gtk_css_style_property_register:
 assertion failed: (initial_value != NULL)
Aborted


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages kalgebra depends on:
ii  kalgebra-common  4:20.12.1-1
ii  kio  5.78.0-5
ii  libanalitza8 4:20.12.0-2
ii  libanalitzagui8  4:20.12.0-2
ii  libanalitzaplot8 4:20.12.0-2
ii  libanalitzawidgets8  4:20.12.0-2
ii  libc62.31-13+deb11u3
ii  libkf5configcore55.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5i18n5  5.78.0-2
ii  libkf5kiocore5   5.78.0-5
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libreadline8 8.1-1
ii  libstdc++6   10.2.1-6

kalgebra recommends no packages.

kalgebra suggests no packages.

-- no debconf information



Bug#1016261: givaro: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

2022-08-04 Thread Torrance, Douglas

On Fri, 29 Jul 2022 18:33:25 +0200 Lucas Nussbaum  wrote:

Source: givaro
Version: 4.2.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> Parsing file /<>/tests/test-recint_convert.C...
> Preprocessing /<>/tests/test-recint_exp.C...
> Parsing file /<>/tests/test-recint_exp.C...
> Preprocessing /<>/tests/test-recint_extra.C...
> Parsing file /<>/tests/test-recint_extra.C...
> Preprocessing /<>/tests/test-recint_rand.C...
> Parsing file /<>/tests/test-recint_rand.C...
> Preprocessing /<>/tests/test-regression.C...
> Parsing file /<>/tests/test-regression.C...
> Preprocessing /<>/tests/test-ringarith.C...
> Parsing file /<>/tests/test-ringarith.C...
> Preprocessing /<>/tests/test-rint_arith.C...
> Parsing file /<>/tests/test-rint_arith.C...
> Preprocessing /<>/tests/test-rmint_arith.C...
> Parsing file /<>/g
> E: Build killed with signal TERM after 150 minutes of inactivity


The full build log is available from:
http://qa-logs.debian.net/2022/07/28/givaro_4.2.0-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220728;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220728=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.



I think this is really a regression in Doxygen (version 1.9.4 was just uploaded
recently).  I've reported it at https://github.com/doxygen/doxygen/issues/9491.

An hacky fix is to remove the symlinks that are generated by the configure
script before building the documentation.  I'll upload a new package shortly.

Doug


signature.asc
Description: PGP signature


Bug#1004589: Part of a solution for #1004589

2022-08-04 Thread Ron Murray
Much of this is still a problem in the current version in testing
(0.17.2-1). The paths to the binaries in the gnunet.conf file seems to
have been fixed, but the other two problems remain.

Levin's solution to the user problem (by putting the real username in
the .service file still works, but gnunet still barfs on the logfile
problem. The solution to that is to put the logfile in /var/log/gnunet.
The current version of gnunet creates this directory, with correct
permissions (0755 gnunet:gnunet), but doesn't update /etc/gnunet.conf
to fit. With that file set up like this:

[path]
GNUNET_HOME = /var/lib/gnunet/
GNUNET_DATA_HOME = /var/lib/gnunet/data/
GNUNET_RUNTIME_DIR = /var/run/gnunet/

[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO
OPTIONS = -l /var/log/gnunet/gnunet.log

   gnunet starts up fine.

 .Ron Murray



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



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


Bug#1006728: RFP: gtkmm-4.0 -- GTK4 bindings for c++

2022-08-04 Thread Jeremy Bicha
This needs glibmm2.68, cairomm1.16, and pangomm2.48 to be packaged
first. Those are all new source packages intended for gtkmm 4. The
earlier source packages have a different ABI and are intended for
gtkmm3.

Thank you,
Jeremy Bicha



Bug#1016657: enable ipv6 and math options (and more?); harmonize README.*

2022-08-04 Thread Ivan Shmakov
Source: jimtcl
Version: 0.81+dfsg0-2
Severity: minor
Control: found -1 0.77+dfsg0-3

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

[Using Severity: minor chiefly due to the inclusion of the
README.* discrepancy in this report; feel free to clone and
address the issues separately.]

It’s customary for packages to be built for Debian with all
possible options enabled; or, alternatively, for there to be
separate ‘fully-featured’ and ‘low-footprint’ packages (such
as vim-nox vs. vim vs. vim-tiny; or exim4-daemon-heavy vs.
exim4-daemon-light; etc.)

Assuming there’d be no negative implications for Jim users
in Debian (such as openocd) in doing so, I request that ipv6
and math options are enabled for Debian Jim packages; which,
I presume, could be achieved by adding --ipv6 and --math to
the second dh_auto_configure invocation in debian/rules:

24  
25  override_dh_auto_configure: autosetup/jimsh0.c
26  dh_auto_configure --builddirectory=static/
27  dh_auto_configure -- --shared
28  

Currently both options are evidently disabled:

$ jimsh -e "socket -ipv6 stream.server  " 
ipv6 not supported
$ jimsh -e "expr { sin (1) } " 
syntax error in expression: " sin (1) "
$ 

It’d be nice to have UTF-8 support enabled as well (--utf8),
but I’m less certain that it won’t interfere with current Jim
users in Debian.

$ jimsh -e 'string length "\u2012" ' 
3
$ tclsh8.6 <(printf %s\\n 'puts [ string length "\u2012" ] ') 
1 
$ 

Overall, I’d think that /also/ having Jim packages built with
the --full configure option (which is to say, with support
for sqlite3, zlib and others) could come handy to some of us.
So far as I can tell, it’d involve making separate jimsh-full,
libjim-full and libjim-full-dev packages, which seems somewhat
unreasonable.

That, however, reminds me that there’s currently a discrepancy
between the README.* files installed by the package and the
features actually enabled at build time.  Namely, the jimsh
package includes the README.sqlite.gz and README.utf-8.gz
files, which correspond to features that are disabled and
unavailable to Debian jimsh package users.  Conversely, the
package /does not/ include README.namespaces, despite the
respective feature being enabled (by default.)  Hence I also
request that this discrepancy be rectified.

TIA.

-- 
FSF associate member #7257  http://am-1.org/~ivan/



Bug#1016652: cloud.debian.org: AWS Marketplace usage instructions need to be updated

2022-08-04 Thread Noah Meyerhans
Package: cloud.debian.org
Severity: normal
User: cloud.debian@packages.debian.org
Usertags: aws infrastructure

Per recent email from AWS, we need to update the usage instructions associated
with our AWS Marketplace AMI listings.  The requirements are documented at
https://docs.aws.amazon.com/marketplace/latest/userguide/ami-product-usage-instructions.html



Bug#1016656: colcrt(1) produces broken (off-by-one?) output

2022-08-04 Thread Ivan Shmakov
Package: bsdextrautils
Version: 2.38-4
Severity: minor
Control: found -1 2.36.1-8+deb11u1

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

The colcrt(1) version from bsdextrautils produces output
that does match neither the version from Debian Buster
(bsdmainutils) nor, say, the version from NetBSD.

Expected behavior (Buster, NetBSD 9; GNU Sed):

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt 
Hello
-
Hello
$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - 
Hello
Hello
$ 

Observed behavior:

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt 
H e l l o
 - - - - -
HHeeoo
$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - 
H e l l o
HHeeoo
$ 

As a workaround, $ ul -t dumb can be used in place of
$ colcrt -:

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" \
  | ul -t dumb 
Hello
Hello
$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/



Bug#1016655: bullseye-pu: package dbus-broker/26-1+deb11u2

2022-08-04 Thread Luca Boccassi
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-utopia-maintain...@lists.alioth.debian.org j...@inutil.org

Dear release team,

In accordance with the Security Team, we want to fix CVE-2022-31213 via
a p-u upload rather than a DSA.

https://security-tracker.debian.org/tracker/CVE-2022-31213

I have prepared the backports for the CVE fix, a memory leak fix, and
an assertion fix that were merged upstream in the latest release.

I have tested the new version in a bullseye nspawn container and found
no issue.

I have already done the upload as dbus-broker was approved for
bullseye-p-u already in the past. debdiff attached.

-- 
Kind regards,
Luca Boccassi
diff -Nru dbus-broker-26/debian/changelog dbus-broker-26/debian/changelog
--- dbus-broker-26/debian/changelog	2022-06-22 22:27:17.0 +0100
+++ dbus-broker-26/debian/changelog	2022-08-04 12:55:19.0 +0100
@@ -1,3 +1,11 @@
+dbus-broker (26-1+deb11u2) bullseye; urgency=medium
+
+  * Backport patch to fix assertion failure when disconnecting peer groups
+  * Backport patch to fix memory leak
+  * Backport patches to fix null pointer dereference (CVE-2022-31213)
+
+ -- Luca Boccassi   Thu, 04 Aug 2022 12:55:19 +0100
+
 dbus-broker (26-1+deb11u1) bullseye; urgency=medium
 
   * Backport strnspn-fix-buffer-overflow.patch to fix CVE-2022-31212
diff -Nru dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch
--- dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch	1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch	2022-08-04 12:55:19.0 +0100
@@ -0,0 +1,64 @@
+Author: David Rheinsberg 
+Origin: backport, https://github.com/c-util/c-stdaux/commit/7a8493bebc595f94ea57fa1cb6a765a66185aa95
+Description: add c_memcpy()
+ Alongside c_memset(), this adds c_memcpy() with the same trick of
+ allowing empty copies.
+--- a/subprojects/c-stdaux/src/c-stdaux.h
 b/subprojects/c-stdaux/src/c-stdaux.h
+@@ -488,6 +488,24 @@
+ return p;
+ }
+ 
++/**
++ * c_memcpy() - copy memory area
++ * @dst:pointer to target area
++ * @src:pointer to source area
++ * @n:  length of area to copy
++ *
++ * Copy the memory of size @n from @src to @dst, just as `memcpy(3)` does,
++ * except this function allows either to be NULL if @n is zero. In the latter
++ * case, the operation is a no-op.
++ *
++ * Return: @p is returned.
++ */
++static inline void *c_memcpy(void *dst, const void *src, size_t n) {
++if (n > 0)
++memcpy(dst, src, n);
++return dst;
++}
++
+ /*
+  * Common Destructors
+  *
+--- a/subprojects/c-stdaux/src/test-api.c
 b/subprojects/c-stdaux/src/test-api.c
+@@ -188,6 +188,7 @@
+ void *fns[] = {
+ (void *)c_errno,
+ (void *)c_memset,
++(void *)c_memcpy,
+ (void *)c_free,
+ (void *)c_close,
+ (void *)c_fclose,
+--- a/subprojects/c-stdaux/src/test-basic.c
 b/subprojects/c-stdaux/src/test-basic.c
+@@ -332,6 +332,19 @@
+ abort();
+ c_assert(p == NULL);
+ }
++
++/*
++ * Test c_memcpy() with a simple 8-byte copy.
++ */
++{
++uint64_t v1 = (uint64_t)-1, v2 = (uint64_t)0;
++
++c_assert(v1 == (uint64_t)-1);
++c_memcpy(, , sizeof(v1));
++c_assert(v1 == (uint64_t)0);
++
++c_memcpy(NULL, NULL, 0);
++}
+ }
+ 
+ /*
diff -Nru dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch
--- dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch	1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch	2022-08-04 12:55:19.0 +0100
@@ -0,0 +1,85 @@
+Author: David Rheinsberg 
+Origin: backport, https://github.com/c-util/c-stdaux/commit/1257244f886a4799a1ed739aa2c632e9eb033b8d
+Description: add c_memset()
+ The memset(3) function causes UB if its area pointer is NULL, even if
+ the area is 0-bytes in length. This is very unfortunate and requires
+ unnecessary guards in most callers. We really want to be able to call
+ memset(3) with NULL pointers on empty areas to avoid needless branching
+ and complexity.
+ .
+ Provide c_memset() which is exactly like memset(3) for non-NULL areas,
+ but a no-op for empty areas.
+--- a/subprojects/c-stdaux/src/c-stdaux.h
 b/subprojects/c-stdaux/src/c-stdaux.h
+@@ -470,6 +470,24 @@
+ return _c_likely_(errno > 0) ? errno : ENOTRECOVERABLE;
+ }
+ 
++/**
++ * c_memset() - fill memory region with constant byte
++ * @p:  pointer to memory region, if non-empty
++ * @c:  value to fill with
++ * @n:  size of the memory region in bytes
++ *
++ * This function works like `memset(3)` if 

Bug#1016654: apt-mark not mentioned in package description

2022-08-04 Thread michel
Package: apt
Version: 2.2.4
Severity: minor
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,



...title. 



Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

2022-08-04 Thread Ivan Shmakov
Package: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: minor
Control: found -1 1.4+really1.3.36+hg16481-2
Control: found -1 1.4+really1.3.35-1~deb10u2

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

While graphicsmagick claims to support ‘Truevision Targa’
format, its implementation is apparently slightly defective
in that the images are read and written with their vertical
axis reversed.  Consider, for instance, SHAPES.TGA from [1]:
it’s shown with the gray (#9c9c9c) ‘floor’ at the bottom of
the image by both LDPCXTGA.EXE and ImageMagick’s display(1),
yet $ gm display SHAPES.TGA shows the floor at the /top/ of
the image instead.

[1] http://archive.org/download/simtelnet_bu_mirror_2013_04
/simtelnet.bu.mirror.2013.04.zip/simtelnet%2Fmsdos%2Fgraphics
%2Fldpcxtga.zip (URI split for readability.)

The same applies to images produced with $ gm convert.

The obvious workaround is to use -flip, like:

$ gm display -flip SHAPES.TGA 
$ gm convert input.file -flip output.tga 

-- 
FSF associate member #7257  http://am-1.org/~ivan/



Bug#1004258: improvements to the bugfix

2022-08-04 Thread Wolfram Sang
Hi,

first of all, thank you for fixing this bug. I was also bitten by it
and I am happy that it was fixed already by a patch.

I'd like to suggest some improvements, though. First, I think the new
variable introduced should be 'gint' rather than 'int' to stay
consistent. Also, there were some white space issues with one of the new
lines. I add an updated patch here to this message. It is also a tad
shorter because of the ternary operator. Its usage is often a matter of
taste but I think it fits nicely here.

Thanks and looking forward to comments,

   Wolfram
From: Patrizio Tufarolo 
Date: Wed, 25 May 2022 08:11:36 +0200
Subject: fix_segfault_on_DNS_entries

Slightly edited by Wolfram Sang 
---
 src/modules/nm09.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/modules/nm09.c b/src/modules/nm09.c
index 2b3098b..02d0e20 100644
--- a/src/modules/nm09.c
+++ b/src/modules/nm09.c
@@ -529,7 +529,7 @@ static mmguiconn_t mmgui_module_connection_get_params(mmguicore_t mmguicore, con
 	GVariant *connconsec, *connipv4sec, *conntechsec;
 	GVariant *conndnsvar;
 	gchar *conntypestr, *connparamstr;
-	gint i, addrint;
+	gint i, addrint, n_dns_entries;
 	GVariant *addrvar;
 	gchar *techstr;
 	mmguiconn_t connection;
@@ -630,7 +630,8 @@ static mmguiconn_t mmgui_module_connection_get_params(mmguicore_t mmguicore, con
 	if (connipv4sec != NULL) {
 		/*DNS*/
 		conndnsvar = g_variant_lookup_value(connipv4sec, "dns", G_VARIANT_TYPE_ARRAY);
-		for (i = 0; i < g_variant_n_children(conndnsvar); i++) {
+		n_dns_entries = conndnsvar ? g_variant_n_children(conndnsvar) : 0;
+		for (i = 0; i < n_dns_entries; i++) {
 			addrvar = g_variant_get_child_value(conndnsvar, i);
 			addrint = ntohl(g_variant_get_uint32(addrvar));
 			if (connection->dns1 == NULL) {


signature.asc
Description: PGP signature


Bug#1016387: Traces

2022-08-04 Thread Dan Jacobson
OK, I found my trace!
But it was so tiny.
I had to zoom in to see it.
But I needed to use the slider, as CTRL++ doesn't work, only CTRL+-
does.
Also the man page should say one can start with a filename:
$ gpxviewer filename.gpx
which works, but should indeed then zoom in so the whole trace is noticeable.
OK, maybe with e.g., --zoom(-in)
Also
$ gpxviewer --help
Traceback (most recent call last):
  File "/usr/bin/gpxviewer", line 48, in ...
should instead mention some usage message.



Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

2022-08-04 Thread Eugene Losowski-Gallagher
Hi Chris,

Thank you for the prompt to test against sid.
I just tested and can confirm that it works.

Thank you so much for the help.

Eugene

On Thu, 4 Aug 2022 at 13:00, Chris Hofstaedtler  wrote:

> Hi Eugene,
>
> * Eugene Losowski-Gallagher 
> [220804 08:25]:
> > Ref: Bug#1011483
> (please keep the bug in To:)
>
> > Thank you for the comment on closing, and apologies for the delay in
> > writing.
> > I'll admit the description is poor (I submitted too early while trying to
> > report it- so didn't properly write the description to match the title).
> >
> > Questions on this closing:
> > 1) What is happening to the patch attached?
> > 2) I also wrote a patch for 1003366 - and both should resolve the issues
> on
> > OpenISCSI (just needs to be applied in order 1003366 first, then
> 1011483).
>
> > I have tested these and am using the "dev" build as installation media
> > until these get applied.
> >
> > Please advice how to proceed: New ticket for all components + patch,
> > patches applied (and both closed), etc?
>
> As far as I know, iscsi now works in the installer. I tried a sid
> installer from a few days ago and successfully installed a new VM.
>
> Is there anything left to do / something that does not work for you?
>
> Chris
>
>

-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923


Bug#1009806: Bug report - forced mount parameters

2022-08-04 Thread Chris Hofstaedtler
Control: severity -1 normal
Control: tags -1 + moreinfo

* Mcgiwer :
> I had discovered an very annoying and serious bug in the "mount" package:
> 
> While attempting to mount a hard disk while beeing logged in locally in 
> terminal (as root), the mount command forces following mount options:
> 
> "nosuid,nodev,noexec"
> 
> totally ignoring the ones I give.

I cannot reproduce this problem.

> It's at latest that good that it does not mount it as write-only (without 
> possibility to read from it).

I do not understand what you are saying here.

Chris



Bug#1016645: metaphlan2: package name and description can become confusing

2022-08-04 Thread Patrice Duroux
Too fast, great!
With many thanks,
Patrice

Le jeu. 4 août 2022 à 17:22, Andreas Tille  a écrit :
>
> Control: tags -1 pending
>
> Hi Patrice,
>
> Am Thu, Aug 04, 2022 at 04:12:39PM +0200 schrieb Patrice Duroux:
> > The current package version is already 3.0.14 and the package description is
> > citing 2.0 in two places but the following one may become strange by the
> > time, isn't it?
>
> Thanks for the hint which is perfectly right.  I've pushed a fix to Git
> as well as to the Debian new queue since a rename of a binary package
> has to go to new.  Thus there is no chance to predict when the renamed
> package will appear in the Debian package pool.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de



Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa

2022-08-04 Thread Axel Beckert
Hi Manuel,

TL;DR: Please grant me cwidget team membership on Salsa so we don't
have to NMU it. Or just do an upload of cwidget with the patch from
#1015925.

I know you're busy with RISC-V and other stuff, but please do me a
small favour and add me to the cwidget team on Salsa, probably via
https://salsa.debian.org/groups/cwidget-team/-/group_members

Background:

There are currently RC bugs in aptitude and cwidget which both cause
aptitude to FTBFS with GCC 12:

  https://bugs.debian.org/1015925
  https://bugs.debian.org/1012895

Both bug reports have patches by pabs (Cc'ed).

Without having the cwidget bugs (#1015925) fixed, I can't fix the
aptitude one (#1012895).

Currently you're the only "cwidget team" member on Salsa. I've
requested team membership there a few days ago, so I can do proper
"Team uploads" for cwidget, too. Otherwise pabs or me would have to
NMU cwidget. And I think having a second uploader for cwidget would be
good in the long run anyway, especially because aptitude is its only
library user.

Other options beside the NMU are (obviously) that you do a quick
upload of cwidget with pabs' patch from #1015925.

(Sent from my non-debian address to your non-debian address due to the
current GMail fuckup which causes tons of false positive mail
rejections by GMail, especially with mails forwarded by the BTS.)

Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5  /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: a...@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: a...@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/


signature.asc
Description: PGP signature


Bug#1016650: haskell-devscripts: Support internal libraries

2022-08-04 Thread Scott Talbert
Package: haskell-devscripts
Severity: important

haskell-devscripts does not currently support packages with internal
libraries (correctly).  Partial support was added to support GHC
registration with a directory of files instead of a single file, where
the first file in the directory was selected, but this unfortunately was
too naive and does not work in all cases.

Packages currently have to be patched to remove the internal libraries
(e.g., attoparsec), so ideally we should add proper support for internal
libraries to the tooling.



Bug#1016645: metaphlan2: package name and description can become confusing

2022-08-04 Thread Andreas Tille
Control: tags -1 pending

Hi Patrice,

Am Thu, Aug 04, 2022 at 04:12:39PM +0200 schrieb Patrice Duroux:
> The current package version is already 3.0.14 and the package description is
> citing 2.0 in two places but the following one may become strange by the
> time, isn't it?

Thanks for the hint which is perfectly right.  I've pushed a fix to Git
as well as to the Debian new queue since a rename of a binary package
has to go to new.  Thus there is no chance to predict when the renamed
package will appear in the Debian package pool.

Kind regards

 Andreas. 

-- 
http://fam-tille.de



Bug#1016649: haskell-devscripts: haddock recipe run on all architectures

2022-08-04 Thread Scott Talbert
Package: haskell-devscripts
Severity: important

The haddock recipe is being run on all arches, when it really only needs
to be run once on the -all arch.  This is not only wasteful, but it
causes problems for certain packages (e.g., haskell-gi-gtk) where the
documentation cannot be built on mips without running out of memory.  This is a
regression from the pre-Perl state.



Bug#1016648: hedgewars FTBFS with ffmpeg 5

2022-08-04 Thread Peter Green

Package: hedgewars
Version: 1.0.0-16
Severity: serious

Hedgewars failed to build on all architectures when binnmu'd (note: the binnmu 
sat
in BD-Uninstallable for a long time due to issues with haskell packages).


[ 41%] Linking Pascal executable ../bin/hwengine
cd /<>/obj-x86_64-linux-gnu/hedgewars && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/hwengine.dir/link.txt --verbose=1
/<>/obj-x86_64-linux-gnu/bin/ppas.sh
Linking /<>/obj-x86_64-linux-gnu/bin/hwengine
/usr/bin/ld.bfd: /<>/obj-x86_64-linux-gnu/bin//libavwrapper.so: 
undefined reference to `avcodec_encode_audio2'
/usr/bin/ld.bfd: /<>/obj-x86_64-linux-gnu/bin//libavwrapper.so: 
undefined reference to `avcodec_get_context_defaults3'
/usr/bin/ld.bfd: /<>/obj-x86_64-linux-gnu/bin//libavwrapper.so: 
undefined reference to `avcodec_encode_video2'
An error occurred while linking 
/<>/obj-x86_64-linux-gnu/bin/hwengine
make[3]: *** [hedgewars/CMakeFiles/hwengine.dir/build.make:165: bin/hwengine] 
Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:2688: hedgewars/CMakeFiles/hwengine.dir/all] 
Error 2
make[2]: *** Waiting for unfinished jobs




Bug#1016346: [Help] LaTeX error due to encoding issues (Was: Bug#1016346: pycorrfit: FTBFS: make[1]: *** [debian/rules:46: override_dh_auto_build] Error 1)

2022-08-04 Thread Andreas Tille
Control: tags -1 help

Hi,

Am Fri, Jul 29, 2022 at 08:41:23PM +0200 schrieb Lucas Nussbaum:
> > (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-0.def)
> > No file PyCorrFit_doc.toc.
> > ! Argument of ? has an extra }.
> >  
> > \par 
> > l.144 \newpage

I was able to reproduce this error with the small LaTeX file:


$ cat test.tex
\documentclass[]{scrartcl}
\usepackage[utf8x]{inputenc}
\usepackage{hyperref}
\begin{document}
Bla
\end{document}

$ pdflatex test.tex
...
(/usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./PyCorrFit_doc.aux) (/usr/share/texlive/texmf-dist/tex/latex/ucs/ucsencs.def)
(./PyCorrFit_doc.out) (./PyCorrFit_doc.out)
(/usr/share/texlive/texmf-dist/tex/latex/bookmark/bookmark.sty
(/usr/share/texlive/texmf-dist/tex/latex/bookmark/bkm-pdftex.def))
! Argument of � has an extra }.
 
\par 
l.6 \end{document}
  
? 
! Emergency stop.
 
\par 
l.6 \end{document}
  
!  ==> Fatal error occurred, no output PDF file produced!


If I subsitute  s/utf8x/utf8/  in line 2  the test file builds fine.
However, in the full LaTeX source fails later with:

...
See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...  
  
l.288 Name & \textbf{TIR (□x$\upsigma$/Exp.) 3D}


So if someone finds a clue how to build this file properly


\documentclass[]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{hyperref}
\begin{document}
Bla \textbf{TIR (□x$\upsigma$/Exp.) 3D}
\end{document}


the bug can be fixed.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Bug#1016647: Upgrade to new upstream release, currently 0.7.5

2022-08-04 Thread Frédéric Bonnard
Package: src:python-schema
Version: 0.6.7-4

--

Dear maintainer,
upstream python-schema introduced support for 'Literal' which the
package "organize" uses in its latest version and I'd like to update
"organize".
Would mind considering upgrading python-schema ?
Thanks a lot,
Regards,

F.


signature.asc
Description: PGP signature


Bug#1013273: [Pkg-rust-maintainers] Bug#1013273: linking problems on ppc64el

2022-08-04 Thread Frédéric Bonnard
> FWIW, if you want to test - there is an MR open for updating Debian's 
> rustc to 1.60 ;)

Awesome Fabian, that worked .. at least, on a current unstable schroot,
with squeekboard 1.18.0 (which failed just before in the very same schroot),
but with upgraded rustc .debs 1.60.0+dfsg1-1~exp1 .
Thanks,

F.


signature.asc
Description: PGP signature


Bug#1016646: bind9: /etc/bind/named.conf incorrectly refers to /usr/share/doc/bind9/README.Debian.gz

2022-08-04 Thread Quentin Armitage
Package: bind9
Version: 1:9.18.5-1
Severity: minor

Dear Maintainer,

   * What led up to the situation?
   I was configuring bind9 and read /etc/bind/named.conf which said to
   read /usr/share/doc/bind9/README.Debian.gz before configuring bind.
   That file does not exist, which confused me. I subsequently
   discovered that the file is /usr/share/doc/bind9/README.Debian (i.e.
   no .gz suffix).

   This is also an issue with bind9 9.16

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.18.5-1
ii  bind9-utils1:9.18.5-1
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  init-system-helpers1.60
ii  iproute2   5.10.0-4
ii  libc6  2.31-13+deb11u3
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.5.2-1
ii  libnghttp2-14  1.43.0-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libuv1 1.40.0-2
ii  libxml22.9.10+dfsg-6.7+deb11u2
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2+deb11u1

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.18.5-1
ii  resolvconf 1.87
pn  ufw

-- Configuration Files:
/etc/bind/named.conf changed [not included]
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/ufw/applications.d/bind9 [Errno 2] No such file or directory: 
'/etc/ufw/applications.d/bind9'

-- no debconf information



Bug#1014417: meson: test changes causes FTBFS

2022-08-04 Thread Jeremy Bicha
gjs 1.73 made changes so that it builds now with meson 0.63.

https://buildd.debian.org/status/package.php?p=gjs

Ubuntu cherry-picked some merge proposals that enabled gjs 1.72 to build too.

http://launchpadlibrarian.net/614996822/meson_0.63.0-1_0.63.0-1ubuntu3.diff.gz

Thank you,
Jeremy Bicha



Bug#1012691: Bug#1013157: nifti2dicom: vtk[6,7] removal

2022-08-04 Thread Andreas Tille
Control: tags -1 upstream
Control: forwarded -1 https://github.com/biolab-unige/nifti2dicom/issues/36



Bug#1016180: transition: gnome-desktop 43

2022-08-04 Thread Jeremy Bicha
Control: tags -1 -moreinfo

gnome-books has been removed from Testing so can be ignored. now.
budgie-control-center is fixed in experimental and will be uploaded to
Unstable promptly once the transition begins.
chatty has a merge proposal in Salsa. [1]
And I'll do a Nautilus upload once the transition begins.

The gnome-desktop library has a fairly strict dependency on
gnome-desktop3-data. This means that it won't be able to smoothly
migrate; everything needs to migrate at the same time.

This transition is basically complete in Ubuntu. We got stuck because
some packages depend on libx11 which is stuck in kinetic-proposed
because of an autopkgtest issue which isn't affecting Debian.

https://release.debian.org/transitions/html/auto-gnome-desktop.html

[1] https://salsa.debian.org/DebianOnMobile-team/chatty/-/merge_requests/25

Thank you,
Jeremy Bicha



Bug#1016645: metaphlan2: package name and description can become confusing

2022-08-04 Thread Patrice Duroux
Package: metaphlan2
Version: 3.0.14-1
Severity: wishlist

Dear Maintainer,

Version 2.0 is EOL since 2 years ago, cf.:
https://github.com/biobakery/MetaPhlAn2
(see also https://huttenhower.sph.harvard.edu/metaphlan2/ that indicates
to look for 3.0)
With 3.0 the official name seems to me MetaPhlAn (without any attached number):
https://github.com/biobakery/MetaPhlAn
with the homepage: http://segatalab.cibio.unitn.it/tools/metaphlan/index.html
(see also https://huttenhower.sph.harvard.edu/metaphlan)

The current package version is already 3.0.14 and the package description is
citing 2.0 in two places but the following one may become strange by the
time, isn't it?

 MetaPhlAn 2.0 relies on ~1M unique clade-specific marker genes (the
 marker information file can be found at
 usr/share/metaphlan2/utils/markers_info.txt.bz2) identified from
 ~17,000 reference genomes (~13,500 bacterial and archaeal, ~3,500 viral,
 and ~110 eukaryotic), allowing


In any case, many thanks for its maintenance.

Cheers,
Patrice

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 metaphlan2 depends on:
ii  bowtie2  2.4.5-1
ii  metaphlan2-data  2.6.0+ds-4
ii  python3  3.10.5-3
ii  python3-biom-format  2.1.12-1+b1
ii  python3-biopython1.79+dfsg-3+b1
ii  python3-dendropy 4.5.2-1
ii  python3-h5py-serial  3.7.0-2
ii  python3-msgpack  1.0.3-1+b1
ii  python3-numpy1:1.21.5-1+b1
ii  python3-pandas   1.3.5+dfsg-5
ii  python3-pysam0.17.0+ds-2+b2
ii  python3-requests 2.27.1+dfsg-1
ii  python3-scipy1.8.1-8

metaphlan2 recommends no packages.

metaphlan2 suggests no packages.

-- no debconf information



Bug#1016644: simple-cdd: Please allow to preseed the 'error' type

2022-08-04 Thread Arnaud Rebillout
On Thu, 04 Aug 2022 15:57:36 +0200 Arnaud Rebillout  
wrote:

>
> Note that the error message above seems to come from debconf, and I
> wonder if it can be solved by adding 'error' to the list of known types
> here: 
https://sources.debian.org/src/debconf/1.5.79/debconf-set-selections/#L154


No, it doesn't work, I just tried.

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer



Bug#1016644: simple-cdd: Please allow to preseed the 'error' type

2022-08-04 Thread Arnaud Rebillout
Package: debian-cdd
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Lately I tried to preseed a question of the type 'error', and it wasn't
really straightforward.

Such a question can be seen in the package encfs, at:
https://sources.debian.org/src/encfs/1.9.5-1/debian/encfs.templates

The template looks like that:

  Template: encfs/security-information
  Type: error
  _Description: Encfs security information
   According to a security audit by Taylor Hornby (Defuse Security), the current
   [...]

In effect, when the package encfs is installed by the Debian installer,
it displays an error message. It's not really a question, it's simply an
error message.

I tried to use preseeding to prevent the Debian installer from showing
this message. The tentative preseed line that I applied was:

  encfs encfs/security-information seen true

However, this leads to a build failure in live-build-config:

  $ ./build.sh --verbose --installer --variant netinst
  [...]
  2022-08-04 10:05:37,846 DEBUG Checking configuration...
  error: Cannot find a question for encfs/security-information
  2022-08-04 10:05:38,016 ERROR preseed file invalid:
<>/simple-cdd/profiles/default.preseed

Fortunately, there's a workaround! We have to apply this preseeding instead:

  encfs encfs/security-information boolean true
  encfs encfs/security-information seen true

It seems like the first line is enough to trick simple-cdd/debconf into
accepting the second line. This workaround has been use to build the
Kali Linux ISOs:
https://gitlab.com/kalilinux/build-scripts/live-build-config/-/commit/d9040785

Note that the error message above seems to come from debconf, and I
wonder if it can be solved by adding 'error' to the list of known types
here: https://sources.debian.org/src/debconf/1.5.79/debconf-set-selections/#L154

To finish this report, a few URLs showing that other people struggle
with this issue:
- https://bugs.launchpad.net/ubuntu/+source/encfs/+bug/1672827
- https://askubuntu.com/q/1401467/424636

Thanks,

Arnaud



Bug#1016047:

2022-08-04 Thread Timothy Pearson
The areas I'm specifically interested in helping with are the security updates 
and the ungoogled Chromium patchset -- I'm already maintaining the ungoogled 
patches on top of the ppc64el patches, and I'd like to get both of those in 
Debian proper.



Bug#1016643: ethflux: please add support for riscv64

2022-08-04 Thread Bo YU
Source: ethflux
Version: 1.0-3
Severity: wishlist
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear ethflux Maintainer,

The ethflux package can be built on my real riscv64 hardware,
so could you add support for riscv64 arch as a build target?
And I noticed that in 1.0-3 upload it was restricted archs to
release archs, so feel free to close or let me know it if this 
make non-sence, thanks.

The PR is here:
https://salsa.debian.org/go-team/packages/ethflux/-/merge_requests/2


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#1016604: transition: svt-av1

2022-08-04 Thread Dylan Aïssi
Le mer. 3 août 2022 à 23:11, Sebastian Ramacher  a écrit :
>
> On 2022-08-03 23:04:29 +0200, Dylan Aïssi wrote:
> > Please schedule a transition slot for svt-av1.
>
> Please go ahead
>

Uploaded, thanks!

Best,
Dylan



Bug#1008198: Add another Canon entry to the monochrome settings list

2022-08-04 Thread Th
On Thu, 24 Mar 2022 10:27:11 +0100 Thierry Huchard 
 wrote:

> Package:thunderbird
> Version:91.7.0esr
>
>
> I have a printing problem, Canon printers using the cnijfilter2 driver
> cannot print in black and white
> I reported it to Mozilla with a solution. It has been adopted and will
> be applied on version 100
> The problem is that the implementation of Portal for printing is faulty.
> The test proposed by emilio (Emilio Cobos Álvarez) works if Portal is
> not activated: "Can you confirm that going to about:config and setting
> print.cups.monochrome.extra_settings to CNGrayscale:True makes it behave
> as you expect? Thanks."
> Mozilla has removed its portal implementation, Gtk printing uses portal
> transparently: https://phabricator.services.mozilla.com/D139594
> I have disabled Portal in version 91.7 of firefox-esr and thunderbird, I
> attach the patch.
> Do you think that this patch can be integrated quickly in Thunderbird
> and Firefox-esr.

>

Fixed in thunderbird 102

> Thierry Huchard



Bug#1016640: gnome-terminal: Size resets to 80x24, when another window gets focus (only tested on gnome-shell)

2022-08-04 Thread Jeremy Bicha
Control: forwarded -1 https://gitlab.gnome.org/GNOME/vte/-/issues/2572

On Thu, Aug 4, 2022 at 7:33 AM Krassy Boykinov  wrote:
> Gnome-terminal resets its size to default after loosing focus - either by:
> (1) mouse or (2) by pressing CTRL + SHIFT + N to open a new instance.

Interesting bug report. Yes, this was triggered by today's vte
updates. I've reported the issue to GNOME.

Thank you,
Jeremy Bicha



Bug#1016413: pu bug for reference

2022-08-04 Thread Rene Engelhard

Hi,

Am 04.08.22 um 12:58 schrieb Rene Engelhard:
just for reference: a stable update for this is requested in 
http://bugs.debian.org/1016413



oops, should have been gone to #1016420 obviously (too hot...)


Regards,


Rene



Bug#1016420: pu bug for reference

2022-08-04 Thread Rene Engelhard
just for reference: a stable update for this is requested in 
http://bugs.debian.org/1016413




Bug#1016642: UI.py: SyntaxWarning: "is not" with a literal. Did you mean "!="?

2022-08-04 Thread Jaume Sabater
Package: pg-activity
Version: 1.6.2-1
Severity: normal

Dear Maintainer,

Upon installation of the pg-activity package on Debian 11 Bullseye, the
following error happens:

Fetched 335 kB in 0s (31.8 MB/s)
Selecting previously unselected package python3-psutil.
(Reading database ... 26732 files and directories currently installed.)
Preparing to unpack .../python3-psutil_5.8.0-1_amd64.deb ...
Unpacking python3-psutil (5.8.0-1) ...
Selecting previously unselected package python3-psycopg2.
Preparing to unpack .../python3-psycopg2_2.8.6-2_amd64.deb ...
Unpacking python3-psycopg2 (2.8.6-2) ...
Selecting previously unselected package pg-activity.
Preparing to unpack .../pg-activity_1.6.2-1_all.deb ...
Unpacking pg-activity (1.6.2-1) ...
Setting up python3-psutil (5.8.0-1) ...
Setting up python3-psycopg2 (2.8.6-2) ...
Setting up pg-activity (1.6.2-1) ...
/usr/lib/python3/dist-packages/pgactivity/UI.py:1659: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
  if val is not 0:
/usr/lib/python3/dist-packages/pgactivity/UI.py:1660: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
  if val['name'] is not 'Query':
/usr/lib/python3/dist-packages/pgactivity/UI.py:1678: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
  if val is not 0:
Processing triggers for man-db (2.9.4-2) ...

The application can be launched and seems to be working fine, though I have
not tested all the options it offers.

Moreover, I have found a very similar bug bug on the bleachbit package,
which may serve as reference:

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

I have not tried installing the version of pg-activity available on sid
because the dependencies has changed.

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

Kernel: Linux 5.15.39-2-pve (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pg-activity depends on:
ii  python3   3.9.2-3
ii  python3-psutil5.8.0-1
ii  python3-psycopg2  2.8.6-2

pg-activity recommends no packages.

pg-activity suggests no packages.

-- no debconf information

-- 
Jaume Sabater
"Ubi sapientas ibi libertas"


Bug#1016641: RM: software-copyright -- ROM; wrong source package name, replaced with new one

2022-08-04 Thread Dominique Dumont
Package: ftp.debian.org
Severity: normal

Hi

I've messed up when I created software-copyright source package. It
should have been libsoftware-copyright-perl.

libsoftware-copyright-perl source package is now in Debian unstable.
It's time to remove software-copyright source package.

Sorry for the blunder

All the best



Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

2022-08-04 Thread Eugene Losowski-Gallagher
Hi Chris,

Ref: Bug#1011483

Thank you for the comment on closing, and apologies for the delay in
writing.
I'll admit the description is poor (I submitted too early while trying to
report it- so didn't properly write the description to match the title).

Questions on this closing:
1) What is happening to the patch attached?
2) I also wrote a patch for 1003366 - and both should resolve the issues on
OpenISCSI (just needs to be applied in order 1003366 first, then 1011483).

I have tested these and am using the "dev" build as installation media
until these get applied.

Please advice how to proceed: New ticket for all components + patch,
patches applied (and both closed), etc?

Many thanks

Eugene


On Fri, 29 Jul 2022 at 21:27, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the open-iscsi package:
>
> #1011483: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set:
> /etc/iscsi/initiatorname.iscsi does not exist
>
> It has been closed by Chris Hofstaedtler .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Chris Hofstaedtler <
> z...@debian.org> by
> replying to this email.
>
>
> --
> 1011483: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011483
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Chris Hofstaedtler 
> To: 1011483-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 29 Jul 2022 22:22:17 +0200
> Subject: Re: #1011483 duplicate/related to #1003366
> I'll close this bug (doesnt have much info) in favor of #1003366.
>
>
> -- Forwarded message --
> From: Eugene 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 23 May 2022 22:02:09 +0100
> Subject: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set:
> /etc/iscsi/initiatorname.iscsi does not exist
> Package: open-iscsi
> Version: 2.1.3-5
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: eugene.losowskigallag...@googlemail.com
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 11.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages open-iscsi depends on:
> ii  debconf [debconf-2.0]  1.5.77
> ii  libc6  2.31-13+deb11u3
> ii  libisns0   0.100-3
> ii  libkmod2   28-1
> ii  libmount1  2.36.1-8+deb11u1
> ii  libopeniscsiusr2.1.3-5
> ii  libssl1.1  1.1.1n-0+deb11u2
> ii  libsystemd0247.3-7
> ii  udev   247.3-7
>
> open-iscsi recommends no packages.
>
> open-iscsi suggests no packages.
>
> -- debconf information excluded
>


-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923


Bug#1011483: closed by Chris Hofstaedtler (Re: #1011483 duplicate/related to #1003366)

2022-08-04 Thread Chris Hofstaedtler
Hi Eugene,

* Eugene Losowski-Gallagher  [220804 
08:25]:
> Ref: Bug#1011483
(please keep the bug in To:)

> Thank you for the comment on closing, and apologies for the delay in
> writing.
> I'll admit the description is poor (I submitted too early while trying to
> report it- so didn't properly write the description to match the title).
> 
> Questions on this closing:
> 1) What is happening to the patch attached?
> 2) I also wrote a patch for 1003366 - and both should resolve the issues on
> OpenISCSI (just needs to be applied in order 1003366 first, then 1011483).

> I have tested these and am using the "dev" build as installation media
> until these get applied.
> 
> Please advice how to proceed: New ticket for all components + patch,
> patches applied (and both closed), etc?

As far as I know, iscsi now works in the installer. I tried a sid
installer from a few days ago and successfully installed a new VM.

Is there anything left to do / something that does not work for you?

Chris



Bug#1016387: Traces

2022-08-04 Thread Jochen Sprickerhof

* Dan Jacobson  [2022-08-04 06:25]:

I had made the trace you see downloadable on
https://www.openstreetmap.org/user/jidanni/traces/4707960 .

I made it with https://wiki.openstreetmap.org/wiki/OSMTracker_(Android) .
Such traces only have trackpoints, no waypoints usually.

I was hoping to see something like the above URL.


I can see that just fine, see the attached image.

Cheers Jochen


signature.asc
Description: PGP signature


Bug#1016387: Traces

2022-08-04 Thread Dan Jacobson
I had made the trace you see downloadable on
https://www.openstreetmap.org/user/jidanni/traces/4707960 .

I made it with https://wiki.openstreetmap.org/wiki/OSMTracker_(Android) .
Such traces only have trackpoints, no waypoints usually.

I was hoping to see something like the above URL.



Bug#1016640: gnome-terminal: Size resets to 80x24, when another window gets focus (only tested on gnome-shell)

2022-08-04 Thread Krassy Boykinov

Package: gnome-terminal
Version: 3.44.1-1
Severity: important

Gnome-terminal resets its size to default after loosing focus - either by:
(1) mouse or (2) by pressing CTRL + SHIFT + N to open a new instance.

I have not tested other WM's besides gnome-shell

I suspect that it has to do with dependencies, that got updated as of today,
because before the update everything was fine.

APT log (depending packages):
2022-08-04 12:32:12 upgrade libvte-2.91-0:amd64 0.68.0-1+b1 0.69.90-2
2022-08-04 12:32:12 upgrade libvte-2.91-common:amd64 0.68.0-1+b1 0.69.90-2
2022-08-04 12:32:12 upgrade gir1.2-vte-2.91:amd64 0.68.0-1+b1 0.69.90-2
...
2022-08-04 12:32:20 upgrade libx11-data:all 2:1.8.1-1 2:1.8.1-2
2022-08-04 12:32:20 upgrade libx11-6:amd64 2:1.8.1-1 2:1.8.1-2
2022-08-04 12:32:20 upgrade libx11-xcb1:amd64 2:1.8.1-1 2:1.8.1-2


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-2
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.44.1-1
ii  gsettings-desktop-schemas 42.0-1
ii  libatk1.0-0   2.38.0-1
ii  libc6 2.33-8
ii  libdconf1 0.40.0-3
ii  libgcc-s1 12.1.0-7
ii  libglib2.0-0  2.72.3-1
ii  libgtk-3-03.24.34-1
ii  libpango-1.0-01.50.7+ds-1
ii  libstdc++612.1.0-7
ii  libuuid1  2.38-6
ii  libvte-2.91-0 0.69.90-2
ii  libx11-6  2:1.8.1-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.2-1
ii  nautilus-extension-gnome-terminal  3.44.1-1
ii  yelp   42.1-2

gnome-terminal suggests no packages.

-- no debconf information



Bug#1013667: virt-manager: FTBFS: tests failed

2022-08-04 Thread Fabio Fantoni
hi, I prepared an MR that fix this: 
https://salsa.debian.org/libvirt-team/virt-manager/-/merge_requests/15




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003165: scikit-learn testing migration

2022-08-04 Thread Andreas Tille
Hi again,

Am Fri, Jul 29, 2022 at 06:09:26AM +0200 schrieb Andreas Tille:
> I just like to repeat my point:  If the package is to slow on release
> architectures, that we will not manage to fix it, it is in the interest
> of our users to not support the problematic architectures in favour of
> providing it for the architetures where the package is used in practice.
> 
> I have perfectly understood that we will loose several packages on that
> architectures and that this is not a good step.  But having those
> packages not at all is eve worse.

Before we fall into another "do nothing" period:  I will upload
scikit-learn restricted to those architectures only which have all tests
passing and will ask ftpmaster for removal of the others.  If you think
this is a bad idea please give good reasons not to do so or even better
fix the package for the problematic architectures.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Bug#1005119: Package has been built - waiting for upload

2022-08-04 Thread Katharina Drexel
The package has been built and reviewed:
https://salsa.debian.org/php-team/pear/php-asm89-stack-cors/

It could be uploaded by whomever wants to.
-- 



Bug#1016639: Bug report: php-xdebug 3.0.2 - Deiban Bullseye 5.10.127-2

2022-08-04 Thread Tecnico
Package: php-xdebug
Version: 3.0.2
Debian Version: Bullseye
Uname -a: Linux cod-desa-nucleo 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2
(2022-07-23) x86_64 GNU/Linux

Hello,

When we use the xdebug extension in PHP it suddenly stop while it is
debugging. This were not happening before the last security updates.

$ php -v
PHP 7.4.30 (cli) (built: Jul  7 2022 15:51:43) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies
    with Xdebug v3.0.2, Copyright (c) 2002-2022, by Derick Rethans
    

We tried to install another version of the package php-xebug (v3.1.5)
using PECL and everything works well, even installing the xdebug at the
same version
of Debian pacakges, we still have the same issue.

This is a code you could try to reproduce the error while you're debugging:




Thank you.



Bug#1016633: pyhst2: FTBFS: redefinition of 'constexpr const _Tp std::integral_constant<_Tp, __v>::value'

2022-08-04 Thread Neil Williams
On Thu, 04 Aug 2022 11:11:37 +0200 Andreas Beckmann 
wrote:
> Source: pyhst2
> Version: 2020c-5

I have looked at the changes for 2022b upstream (sadly, there is no
suitable git tag but the commit I downloaded as a tar.gz was
701a8c1793598a5f4a5d9e0d2b2e0ae89e61). I get the same errors
reported when building that with unstable.

I note that the path reported is c++/10/ and there were issues with
nvidia-cuda-toolkit and g++-11 in other packages. gcc-defaults now
points at g++-12

See 1003037 in astra-toolbox
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003037#24


> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Hi,
> 
> pyhst2 recently started to FTBFS in sid (but not yet in testing):
> 
> /usr/include/c++/10/type_traits:71:52: error: redefinition of
> 'constexpr const _Tp std::integral_constant<_Tp, __v>::value' 71 |
> template |
>^ /usr/include/c++/10/type_traits:59:29: note:
> 'constexpr const _Tp value' previously declared here 59 |
> static constexpr _Tp value = __v; | ^
> 
> Andreas



-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpRRylC9yEZC.pgp
Description: OpenPGP digital signature


Bug#1016413: pu bug for reference

2022-08-04 Thread Rene Engelhard
just for reference: a stable update for this is requested in 
http://bugs.debian.org/1016413




Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

2022-08-04 Thread Mark Hindley
Ansgar,

On Wed, Aug 03, 2022 at 11:01:53AM +0200, Ansgar wrote:
> On Wed, 2022-08-03 at 09:27 +0100, Mark Hindley wrote:
> > On Wed, Aug 03, 2022 at 10:11:29AM +0200, Michael Biebl wrote:
> > > 
> > > No, that would be a bad idea since systemd already ships its own,
> > > preferred implementation.
> > 
> > Is there a difference between the built-in and standalone
> > implementation other than the packaging?
> 
> Yes, executable size for example.
> 
> A reasonable alternative to include container user needs better might
> be to require init systems to provide tmpfiles (i.e., depend on a
> implementation) and packages to not depend on it if they only use
> tmpfiles if required for service startup via the system service
> manager. (I'm not sure if tmpfiles are always used this way.)

This seems an interesting idea. I wonder if it could be handled in the init
metapackage from src:init-script-helpers?

Mark



Bug#1016638: dh-buildinfo: Please provide dh-sequence-buildinfo

2022-08-04 Thread Debian/GNU
Package: dh-buildinfo
Version: 0.11+nmu2
Severity: wishlist

Dear Maintainer,

recent versions of debhelper allow us to add "dh-seqeunce-*"
build-dependencies, which will both install the requried package and
enable dh-sequences (--with=...) in d/rules.

This makes maintaining simpler, as we don't have to specify the same
information ("i want to use sequence 'foo'") in two places (d/rules and
d/control).

AFAICT, all is required is to add a "Provides: dh-sequence-buildinfo"
stanza to dh-buildinfo's d/control.

>From then on, enabling buildinfo is as simple as adding a B-D on
"dh-sequence-buildinfo" in any consumer package.

fmgrads
IOhannes

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 dh-buildinfo depends on:
ii  build-essential  12.9
ii  debhelper13.8
ii  perl 5.34.0-5

dh-buildinfo recommends no packages.

dh-buildinfo suggests no packages.

-- no debconf information



Bug#1016628: gcc-12: makes nodejs testsuite fail on mips64el/riscv64 only

2022-08-04 Thread Jérémy Lal
Le jeu. 4 août 2022 à 12:36, Xi Ruoyao  a écrit :

> On Thu, 2022-08-04 at 18:18 +0800, YunQiang Su wrote:
> > > Hi,
> > >
> > > If nodejs 18.6.0 is built using gcc-12, several tests fail,
> > > but not when built using gcc-11 (all other things being equal).
> > >
> > > *Only* on mips64el and riscv64.
> > >
> > > In the logs, some new warnings show up, maybe that can help:
> > >
> https://buildd.debian.org/status/fetch.php?pkg=nodejs=mips64el=18.6.0%2Bdfsg-4=1659454899=0
> > >
> > > in particular:
> > > /usr/include/c++/12/bits/atomic_base.h:488:31: warning: ‘long
> > > unsigned int __atomic_load_8(const volatile void*, int)’ writing 8
> > > bytes into a region of size 0 overflows the destination [-Wstringop-
> > > overflow=]
> > >488 | return __atomic_load_n(&_M_i, int(__m));
> > >
> >
> > @Xi Ruoyao Is this what you are working on?
>
> If we have evidence showing it's a GCC code generation bug, I'll try to
> fix it.  I don't have any interest in node.js.


No evidence yet.
Upstream nodejs says it might very well be a bug on their side.
I'll reassign accordingly.


Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

2022-08-04 Thread Richard B. Kreckel
On Wed, 3 Aug 2022 11:33:13 -0700 Max Bell  wrote:
> Why isn't the bug being fixed? That is obviously the correct solution.
So far, they argue that it's correct and only exposed bugs in all those
other packages. Which may even be correct. But without a clear
perspective of getting those fixed anytime soon, it's best to work
around in Debian.

  -richy.
-- 
Richard B. Kreckel




Bug#1016637: evolution: spool+smtp account — E-mails are marked always as new

2022-08-04 Thread Adrian Immanuel Kiess
Package: evolution
Version: 3.44.3-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Upgrading evolution a year ago
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt-get dist-upgrade
   * What was the outcome of this action?
 New messages in a local spool+smtp account are always marked as new,
clicking them marks then as read for some seconds — afterwards the message is
marked as new again
   * What outcome did you expect instead?
 Ability to mark messages on the spool directory as read

in Debian/testing, Evolution is unable to write access the spool directory and
mark read messages as "read". Clicking a message marks this message as "read"
for some seconds, afterwards the message status returns to "new". I assume,
this is, because of Evolution can't write to the spool directory of mails.

My mail spool directory permissions are set to the Debian defaults, and
Sylpheed can access the spool directory for writing. Sylpheed works fine with
my settings and mail spool permissions.

Thank you very much for your kind attention.

With many greetings,

Adrian Kieß



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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 evolution depends on:
ii  dbus   1.14.0-2
ii  evolution-common   3.44.3-2
ii  evolution-data-server  3.44.3-2
ii  libc6  2.33-8
ii  libcamel-1.2-633.44.3-2
ii  libclutter-gtk-1.0-0   1.8.4-4+b1
ii  libecal-2.0-1  3.44.3-2
ii  libedataserver-1.2-26  3.44.3-2
ii  libevolution   3.44.3-2
ii  libglib2.0-0   2.72.3-1
ii  libgtk-3-0 3.24.34-1
ii  libical3   3.0.14-1+b1
ii  libnotify4 0.8.1-1
ii  libsoup2.4-1   2.74.2-3
ii  libxml22.9.14+dfsg-1+b1
ii  psmisc 23.5-3

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.44.3-2
ii  evolution-plugin-pstimport   3.44.3-2
ii  evolution-plugins3.44.3-2
ii  yelp 42.1-2

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.44.3-2
ii  gnupg   2.2.35-3
pn  network-manager 

-- debconf information:
  evolution/kill_processes:
  evolution/needs_shutdown:


Bug#1016628: gcc-12: makes nodejs testsuite fail on mips64el/riscv64 only

2022-08-04 Thread YunQiang Su
Jérémy Lal  于2022年8月4日周四 15:12写道:
>
> Package: gcc-12
> Version: 12.1.0-7
> Severity: important
> X-Debbugs-Cc: YunQiang Su 
> Control: forwarded -1 https://github.com/nodejs/node/issues/44126
>
> Hi,
>
> If nodejs 18.6.0 is built using gcc-12, several tests fail,
> but not when built using gcc-11 (all other things being equal).
>
> *Only* on mips64el and riscv64.
>
> In the logs, some new warnings show up, maybe that can help:
> https://buildd.debian.org/status/fetch.php?pkg=nodejs=mips64el=18.6.0%2Bdfsg-4=1659454899=0
>
> in particular:
> /usr/include/c++/12/bits/atomic_base.h:488:31: warning: ‘long unsigned int 
> __atomic_load_8(const volatile void*, int)’ writing 8 bytes into a region of 
> size 0 overflows the destination [-Wstringop-overflow=]
>   488 | return __atomic_load_n(&_M_i, int(__m));
>

@Xi Ruoyao Is this what you are working on?

> Jérémy
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 gcc-12 depends on:
> ii  binutils   2.38.90.20220713-2
> ii  cpp-12 12.1.0-7
> ii  gcc-12-base12.1.0-7
> ii  libc6  2.33-8
> ii  libcc1-0   12.1.0-7
> ii  libgcc-12-dev  12.1.0-7
> ii  libgcc-s1  12.1.0-7
> ii  libgmp10   2:6.2.1+dfsg1-1
> ii  libisl23   0.25-1
> ii  libmpc31.2.1-2
> ii  libmpfr6   4.1.0-3
> ii  libstdc++6 12.1.0-7
> ii  libzstd1   1.5.2+dfsg-1
> ii  zlib1g 1:1.2.11.dfsg-4
>
> Versions of packages gcc-12 recommends:
> ii  libc6-dev  2.33-8
>
> Versions of packages gcc-12 suggests:
> pn  gcc-12-doc   
> pn  gcc-12-locales   
> pn  gcc-12-multilib  
>
> -- no debconf information



-- 
YunQiang Su



Bug#1016636: puddletag: An error occurs while retriving metatags from Discogs.com

2022-08-04 Thread Bartek
Package: puddletag
Version: 2.2.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: poem...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Retrieving meta-tags from Discogs.com.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Searching for tags for any available album using Discogs.com release id.

   * What was the outcome of this action?
Message reads: "An error occured: local variable '__reference_time' referenced
before assignment".

   * What outcome did you expect instead?
Meta-tags for a specific album release.


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

Kernel: Linux 5.19.0-xanmod1-x64v2 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages puddletag depends on:
ii  libjs-sphinxdoc 4.5.0-4
ii  python3 3.10.5-3
ii  python3-acoustid1.2.2-1
ii  python3-audioread   2.1.9-2
ii  python3-certifi 2020.6.20-1
ii  python3-charset-normalizer  2.0.6-2
ii  python3-configobj   5.0.6-5
ii  python3-idna3.3-1
ii  python3-lxml4.9.1-1+b1
ii  python3-mutagen 1.45.1-3
ii  python3-pyparsing   3.0.7-2
ii  python3-pyqt5   5.15.7+dfsg-1
ii  python3-pyqt5.qtsvg 5.15.7+dfsg-1
ii  python3-pyqt5.sip   12.11.0-1+b1
ii  python3-requests2.27.1+dfsg-1
ii  python3-six 1.16.0-4
ii  python3-urllib3 1.26.9-1

Versions of packages puddletag recommends:
ii  libchromaprint-tools  1.5.1-2+b1
ii  python3-levenshtein   0.12.2-2+b2

Versions of packages puddletag suggests:
pn  quodlibet  

-- no debconf information



Bug#1016635: libconfig-model-dpkg-perl: Missing build profile nocil

2022-08-04 Thread Andreas Tille
Package: libconfig-model-dpkg-perl
Version: 2.162
Severity: normal

Hi,

please try

   apt source gdcm
   cd gdcm-3.0.13
   cme fix dpkg-control
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Connecting to api.ftp-master.debian.org to check 3 package versions. Please 
wait...
Got info from api.ftp-master.debian.org for 0 packages.
Warning in 'source Build-Depends:9': unnecessary greater-than versioned 
dependency: libcharls-dev (>= 2.0). Debian has oldoldoldstable -> 1.0-5; 
oldoldstable -> 1.1.0+dfsg-2; oldstable -> 2.0.0+dfsg-1; buster-backports -> 
2.2.0+dfsg-2~bpo10+2; stable -> 2.2.0+dfsg-2; bullseye-backports -> 
2.2.1+dfsg-1~bpo11+1; unstable -> 2.3.4-1; testing -> 2.3.4-1;
Offending value: 'libcharls-dev (>= 2.0)'
Connecting to api.ftp-master.debian.org to check libexpat-dev versions. Please 
wait...
got no info for libexpat-dev
Warning in 'source Build-Depends:10': package libexpat-dev is unknown. Check 
for typos if not a virtual package.
Offending value: 'libexpat-dev'
Connecting to api.ftp-master.debian.org to check libz-dev versions. Please 
wait...
got no info for libz-dev
Warning in 'source Build-Depends:20': package libz-dev is unknown. Check for 
typos if not a virtual package.
Offending value: 'libz-dev'
Connecting to api.ftp-master.debian.org to check java-virtual-machine versions. 
Please wait...
got no info for java-virtual-machine
Warning in 'binary:"libgdcm-java" Suggests:0': package java-virtual-machine is 
unknown. Check for typos if not a virtual package.
Offending value: 'java-virtual-machine'
Configuration item 'source Build-Depends:1' has a wrong value:
Unknown build profile name 'nocil>': 'Expected one of cross pkg stage1 
stage2 nobiarch nocheck nodoc nogolang nojava noperl nopython noudeb'


Accoring to

   https://wiki.debian.org/BuildProfileSpec

nocil is a valid profile and should not crash cme.

Kind regards and thanks for maintaining cme

   Andreas.



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 libconfig-model-dpkg-perl depends on:
ii  debhelper  13.8
ii  libapt-pkg-perl0.1.40+b1
ii  libarray-intspan-perl  2.004-2
ii  libconfig-model-backend-yaml-perl  2.134-1
ii  libconfig-model-perl   2.152-1
ii  libdata-compare-perl   1.27-2
ii  libexporter-lite-perl  0.09-1
ii  liblog-log4perl-perl   1.55-1
ii  libmouse-perl  2.5.10-1+b2
ii  libparse-debcontrol-perl   2.005-5
ii  libparse-recdescent-perl   1.967015+dfsg-3
ii  libsoftware-licensemoreutils-perl  1.009-1
ii  libsort-versions-perl  1.62-2
ii  libtext-autoformat-perl1.75-1
ii  libtext-levenshtein-damerau-perl   0.41-2
ii  libtoml-tiny-perl  0.15-1
ii  liburi-perl5.12-1
ii  libwww-perl6.67-1
ii  libyaml-libyaml-perl   0.83+ds-1+b1
ii  licensecheck   3.3.0-1
ii  lintian2.115.2
ii  perl [libmodule-corelist-perl] 5.34.0-5

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.375-1

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information


  1   2   >