Bug#1061139: apt: showsrc does not respect `-t'

[Tianyu Chen]

Package: apt
Version: 2.6.0-1deepin5
Severity: normal
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

I've noticed that `apt showsrc` doesn't seem to respect the -t=target_release 
option.
When running `apt -t nonexist showsrc somepackage`, it prints one, which
is not the expected behavior.

apt should either support the `target_release` option, or exit failure
without outputting an entry similar to `apt show`

E: Command line option 't' [from -t] is not understood in combination 
with the other options.

This bug may relate to #613664 and #776366.

Best regards,
Tianyu Chen @ deepin


-- System Information:
Distributor ID: Deepin
Description:Deepin 23
Release:23
Codename:   beige
Architecture: x86_64

Kernel: Linux 6.6.7-amd64-desktop-hwe (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.131-1deepin2
ii  base-passwd 3.6.3
ii  deepin-keyring  2024.01.16
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.0-1deepin5
ii  libc6   2.37-12deepin2
ii  libgcc-s1   13.2.0-3deepin
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-2deepin1
ii  libstdc++6  13.2.0-3deepin
ii  libsystemd0 254.5-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
ii  apt-doc 2.6.0-1deepin5
ii  aptitude0.8.13.1-5deepin
ii  dpkg-dev1.21.22deepin1
ii  gnupg   2.2.40-1.1
pn  powermgmt-base  
ii  synaptic0.91.3

-- no debconf information

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Sandro Tosi]

On Fri, Sep 1, 2023 at 4:33 PM Rob Leslie  wrote:
>
> Package: transmission-daemon
> Version: 3.00-2.1+b1
> Severity: important
> File: /usr/bin/transmission-daemon
>
> Dear Maintainer,
>
> Since upgrading to bookworm, transmission-daemon has appeared to be
> leaking memory, eventually invoking the kernel OOM killer.

unstable already has the 4.x release branch, so i think the best
course of action is for you to prepare a backport for that version, or
find someone to do that for you. the maintainer and upstream are
unable to help with 3.x

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

Bug#1061138: coreutils: CVE-2024-0684: heap overflow in split --line-bytes with very long lines

[Salvatore Bonaccorso]

Source: coreutils
Version: 9.4-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for coreutils.

CVE-2024-0684[0]:
| heap overflow in split --line-bytes with very long lines

Note, the severity is choosen as such to make sure the fix lands in
trixie, but is slight overrated. If you feel strong on it feel free to
downgrade.

The issue can be reproduced with:

{ printf '%131070s\n' ''; printf 'x\n'; printf '%131071s\n' ''; } > in
split -C 131072 ---io=131072 in

and only affects trixie and unstable version of split.

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-2024-0684
https://www.cve.org/CVERecord?id=CVE-2024-0684
[1] https://www.openwall.com/lists/oss-security/2024/01/18/2

Regards,
Salvatore

Bug#1058932: RFP: forgejo -- a self-hosted lightweight software forge

[Maytham Alsudany]

Hi Wim,

On Wed, 17 Jan 2024 14:58:55 + Wim Bertels  wrote:
> there is a comparison available on:
> https://forgejo.org/compare/

I'm aware that Gitea and Forgejo have their own pros and cons. I meant they both
share a lot of the same dependencies, and those dependencies aren't available in
Debian (yet).

You can see the dependency tree for Gitea at
https://salsa.debian.org/Maytha8/gitea-debian-packaging (white = not packaged).

Kind regards,
Maytham


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

Bug#1061137: Doesn't work on SheevaPlug

[Vagrant Cascadian]

Control: fixed 1061137 2023.04~rc2+dfsg-1

On 2024-01-19, Martin Michlmayr wrote:
> Guido Lehwalder and Markus Krebs reported off-list that u-boot in
> Debian stable is broken on SheevaPlug.
>
> Markus Krebs bisected the DENX source and reported:
>
>> last working commit: 3aa14d76182dbbaf9fed4deeaf362f083b9d2f5b
>>
>> next commit, which doesn't work on Sheevaplug:
>> 5387b093cb7914b3c0404da928fa4bafdffac291
>
> Vagrant Cascadian pointed out that this issue has been fixed in:
>
>   commit 9a13a76e6256c51d04f41139733dbb31755e8d30
>   Author: Stefan Roese 
>   Date:   Mon Jan 16 09:01:48 2023 +0100
>
>   timer: orion-timer: Fix problem in early_init_done()

This commit was included in v2023.04-rc1, marking 2023.04~rc2+dfsg-1 as
fixing the issue as it was the first fixed version uploaded to Debian.

For the record, the upstream version currently in sid/unstable and
trixie/testing (2024.01) has the issue fixed as well, as well as the
previous 2023.07 version.


> and prepared a test package:
>
>> I've pushed a work-in-progress branch to:
>>  
>> https://salsa.debian.org/debian/u-boot/-/tree/debian/bookworm-wip?ref_type=heads
>
> Guido Lehwalder tested a binary with this change and reported
> that it fixes the issue.
>
> So we need a stable update with this change.

Thanks everyone!

This is a pretty trivial fix, so including in the next bookworm/stable
point release should work!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1061137: Doesn't work on SheevaPlug

[Martin Michlmayr]

Package: u-boot
Version: 2023.01+dfsg-2
Severity: important

Guido Lehwalder and Markus Krebs reported off-list that u-boot in
Debian stable is broken on SheevaPlug.

Markus Krebs bisected the DENX source and reported:

> last working commit: 3aa14d76182dbbaf9fed4deeaf362f083b9d2f5b
>
> next commit, which doesn't work on Sheevaplug:
> 5387b093cb7914b3c0404da928fa4bafdffac291

Vagrant Cascadian pointed out that this issue has been fixed in:

  commit 9a13a76e6256c51d04f41139733dbb31755e8d30
  Author: Stefan Roese 
  Date:   Mon Jan 16 09:01:48 2023 +0100

  timer: orion-timer: Fix problem in early_init_done()

and prepared a test package:

> I've pushed a work-in-progress branch to:
>  
> https://salsa.debian.org/debian/u-boot/-/tree/debian/bookworm-wip?ref_type=heads

Guido Lehwalder tested a binary with this change and reported
that it fixes the issue.

So we need a stable update with this change.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1061136: RM: simulide [armel armhf riscv64 arm64 mips64el ppc64el s390x] -- ROM; ANAIS; upstream supporting amd64 and i386 only

[Milan Kupcevic]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:simulide

New release version is reducing supported architectures down to 
amd64 and i386 only.

Milan

Bug#1061135: mlton: Add support for loongarch64

[JiaLing Zhang]

Source: mlton
Severity: normal
Tags: patch ftbfs loong64
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
  Mlton is not support loongarch64 now , I port and bootstrap it in
loongarch64 . Please help to support mlton loongarch64 in debian. 

Thanks,
JiaLing Zhang
--- mlton-20210117+dfsg.orig/basis-library/mlton/platform.sig
+++ mlton-20210117+dfsg/basis-library/mlton/platform.sig
@@ -9,7 +9,7 @@ signature MLTON_PLATFORM =
sig
   structure Arch:
  sig
-datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | m68k |
+datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 | m68k |
  MIPS | MIPS64 | PowerPC | PowerPC64 | RISCV |
  RISCV64 | S390 | Sparc | X86
 
--- mlton-20210117+dfsg.orig/basis-library/mlton/platform.sml
+++ mlton-20210117+dfsg/basis-library/mlton/platform.sml
@@ -23,6 +23,7 @@ structure MLtonPlatform: MLTON_PLATFORM
 (ARM64, "ARM64"),
 (HPPA, "HPPA"),
 (IA64, "IA64"),
+(LoongArch64, "LoongArch64"),
 (m68k, "m68k"),
 (MIPS, "MIPS"),
 (MIPS64, "MIPS64"),
--- mlton-20210117+dfsg.orig/basis-library/primitive/prim-mlton.sml
+++ mlton-20210117+dfsg/basis-library/primitive/prim-mlton.sml
@@ -154,6 +154,7 @@ structure Platform =
  | ARM64
  | HPPA
  | IA64
+ | LoongArch64
  | m68k
  | MIPS
  | MIPS64
@@ -173,6 +174,7 @@ structure Platform =
 | "arm64" => ARM64
 | "hppa" => HPPA
 | "ia64" => IA64
+| "loongarch64" => LoongArch64
 | "m68k" => m68k
 | "mips" => MIPS
 | "mips64" => MIPS64
--- mlton-20210117+dfsg.orig/bin/platform
+++ mlton-20210117+dfsg/bin/platform
@@ -109,6 +109,9 @@ parisc*)
 ia64*)
 HOST_ARCH=ia64
 ;;
+loongarch64*)
+HOST_ARCH=loongarch64
+;;
 m68k*)
 HOST_ARCH=m68k
 ;;
--- mlton-20210117+dfsg.orig/lib/stubs/mlton-stubs/mlton.sml
+++ mlton-20210117+dfsg/lib/stubs/mlton-stubs/mlton.sml
@@ -159,7 +159,7 @@ structure MLton: MLTON =
 
 structure Arch =
struct
-  datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 |
+  datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 |
m68k | MIPS | MIPS64 | PowerPC | PowerPC64 | 
RISCV |
RISCV64 | S390 | Sparc | X86
 
@@ -169,6 +169,7 @@ structure MLton: MLTON =
  (ARM64, "ARM64"),
  (HPPA, "HPPA"),
  (IA64, "IA64"),
+ (LoongArch64,"LoongArch64"),
  (m68k, "m68k"),
  (MIPS, "MIPS"),
  (MIPS64, "MIPS64"),
--- mlton-20210117+dfsg.orig/lib/stubs/mlton-stubs/platform.sig
+++ mlton-20210117+dfsg/lib/stubs/mlton-stubs/platform.sig
@@ -9,7 +9,7 @@ signature MLTON_PLATFORM =
sig
   structure Arch:
  sig
-datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | m68k |
+datatype t = Alpha | AMD64 | ARM | ARM64 | HPPA | IA64 | 
LoongArch64 | m68k |
  MIPS | MIPS64 | PowerPC | PowerPC64 | RISCV | RISCV64 
|
  S390 | Sparc | X86
 
--- mlton-20210117+dfsg.orig/mlton/main/main.fun
+++ mlton-20210117+dfsg/mlton/main/main.fun
@@ -199,6 +199,7 @@ fun defaultAlignIs8 () =
| ARM64 => true
| HPPA => true
| IA64 => true
+   | LoongArch64 => true
| MIPS => true
| MIPS64 => true
| RISCV64 => true
--- mlton-20210117+dfsg.orig/runtime/cenv.h
+++ mlton-20210117+dfsg/runtime/cenv.h
@@ -99,6 +99,8 @@ COMPILE_TIME_ASSERT(sizeof_double__is_ei
 #include "platform/hppa.h"
 #elif (defined (__ia64__))
 #include "platform/ia64.h"
+#elif (defined (__loongarch64))
+#include "platform/loongarch64.h"
 #elif (defined (__m68k__))
 #include "platform/m68k.h"
 #elif (defined (__mips64))
--- /dev/null
+++ mlton-20210117+dfsg/runtime/gdtoa/arith.h
@@ -0,0 +1,6 @@
+#define IEEE_8087
+#define Arith_Kind_ASL 1
+#define Long int
+#define Intcast (int)(long)
+#define Double_Align
+#define X64_bit_pointers
--- /dev/null
+++ mlton-20210117+dfsg/runtime/gdtoa/gd_qnan.h
@@ -0,0 +1,3 @@
+#define f_QNAN 0x7fc0
+#define d_QNAN0 0x7ff8
+#define d_QNAN1 0x0
--- mlton-20210117+dfsg.orig/runtime/platform/linux.c
+++ mlton-20210117+dfsg/runtime/platform/linux.c
@@ -28,6 +28,9 @@ static void catcher (__attribute__ ((unu
 #elif (defined(__ia64__))
 ucontext_t* ucp = (ucontext_t*)context;
 GC_handleSigProf ((code_pointer) ucp->_u._mc.sc_ip);
+#elif (defined(__loongarch64))
+ucontext_t* ucp = (ucontext_t*)context;
+GC_handleSigProf ((code_pointer) ucp->uc_mcontext.__pc);

Bug#1055812: nmu: sqlcipher_4.5.5-3

[Boyuan Yang]

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

On Sat, 11 Nov 2023 23:36:28 +0100 Sebastian Ramacher 
wrote:
> user release.debian@packages.debian.org
> usertags 1055812 = transition
> retitle 1055812 transition: sqlcipher
> forwarded 1055812
https://release.debian.org/transitions/html/auto-sqlcipher.html
> tags 1055812 confirmed
> thanks
> 
> On 2023-11-11 23:19:03 +0100, Petter Reinholdtsen wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > X-Debbugs-Cc: sqlcip...@packages.debian.org
> > Control: affects -1 + src:sqlcipher
> > 
> > nmu sqlcipher_4.5.5-3 . ANY . unstable . -m "Rebuild with newer
sqlcipher."
> > 
> > The SONAME of the shared library changed from libsqlcipher0 to
libsqlcipher1.
> > This is related to
> > https://release.debian.org/transitions/html/auto-sqlcipher.html >.
> 
> In this case, please select transition in reportbug to get the correct
> meta data. Fixing.

I see that this everything about this transition is now completed. Shall
we close this bug?

Thanks,
Boyuan Yang


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

Bug#1057860: Will do release + upload this weekend

[Jelmer Vernooij]

We'll just need to do an upstrema release and an upload for this, the
change is already in upstream bzr.

I'll do this over the weekend; if I fail to do a release for some
reason then I'll ship the patch in Debian.

Jelmer

Bug#1061104: xtl-dev is not installed with libxsimd-dev transparently (missing Depends:)

[Kentaro HAYASHI]

FYI:

I've created MR.

  debian: require xtl-dev with runtime
  https://salsa.debian.org/science-team/xsimd/-/merge_requests/4


Regards,

Bug#1061133: libsoup3: Build profiles don't actually work

[Simon McVittie]

On Fri, 19 Jan 2024 at 01:17:36 +0100, John Paul Adrian Glaubitz wrote:
> I was just trying to bootstrap libsoup3 for sh4 using build profiles.
> 
> Unfortunately, that doesn't work since it seems that specifying multiple
> build profiles for a build dependency means that the build dependency is
> removed only if all of the specified profiles are activated.

It can work either way. You can either write

dep  

or
dep 

and they mean different things. I seem to have a blind spot for this
and can never remember which way round they are without looking it up,
but one of them means "require dep if (!nocheck) && (!noinsttest)"
and the other means "require dep if (!nocheck) || (!noinsttest)".
Each of them makes sense for some packages and some build profiles.

> Thus, in order to strip "libapache2-mod-php" from the build dependencies,
> one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the
> libapache2-mod-php build dependency is still pulled in.

That sounds familiar, I think maybe I added that (in libsoup2.4, before
the packaging was forked for libsoup3).

If it's written this way round, it's probably because the build system
will refuse to enable the test suite (either to be run at build-time
or to be installed for later use by autopkgtest) if it doesn't detect
libapache2-mod-php? A lot of GNOME and GNOME-adjacent packages use the
same test executables for build-time and as-installed testing, so it does
often make sense to require a build-dependency if
(!nocheck) || (!noinsttest) - even if you are not going to run build-time
tests, in the absence of noinsttest the package still needs to compile
them, in order to populate the -tests package for later use.

If that's the case, then yes, to bootstrap it you will have to disable
both of those profiles, not just nocheck, and that's probably not a
bug. glib2.0 and dbus have a circular dependency on each other that
works like this, because each wants to use the other in its test suite,
and the way to disable it is to use both build profiles.

> This, however, means that that the "nocheck" profile has to be there to
> boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the
> build fail since this build dependency is mandatory.

*That* sounds like the real bug here. In what way does it fail?

>From a quick look at libsoup3, it seems like it might only need
GNUTLS for part of the test suite, and therefore needs to pass
-Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding
-Dauto_features=enabled) whenever both of these profiles are disabled?

debian/rules in dbus has an example of altering configure options if
both build-time and as-installed tests are disabled, if that helps.

smcv

Bug#1034903: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin navi10_mes.bin for module amdgpu

[Diederik de Haas]

On Friday, 23 June 2023 18:33:44 CET Alex Deucher wrote:
> On Wed, Jun 21, 2023 at 11:38 AM Ben Hutchings  wrote:
> > On Thu, 27 Apr 2023 15:43:28 +0800 xiao sheng wen(
> >  wrote:
> > > Package: firmware-amd-graphics
> > > Version: 20230310-1~exp1
> > > 
> > >  When I upgrade to kernel 5.10.0-22-arm64, there are following error
> > > 
> > >  infos:
> > > W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin
> > > for module amdgpu W: Possible missing firmware
> > > /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu> 
> > [...]
> 
> Those could be dropped.  They are not really used by the driver.  They
> are for a feature which was not ultimately productized on those parts.

Does this mean that *this* bug can be closed?
Further discussions are about different firmware files, but not the ones
this bug was about.

> > More recently amdgpu added:
> > 
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes_2.bin");
> > MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
> > 
> > and these are also missing from linux-firmware.git.
> > 
> > Is this firmware intended to be available to the public?
> 
> Yes, those will be available soon.

From current master WHENCE file:
File: amdgpu/gc_11_0_3_me.bin
File: amdgpu/gc_11_0_3_mec.bin
File: amdgpu/gc_11_0_3_mes1.bin
File: amdgpu/gc_11_0_3_mes_2.bin

So 2 out of 3 are now available, but not the `*_mes.bin` file.

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

Bug#1055080: fixed in obfuscate 0.0.9-3

[gregor herrmann]

On Thu, 18 Jan 2024 16:34:14 +, Debian FTP Masters wrote:

>  obfuscate (0.0.9-3) unstable; urgency=medium
>  .
>* Added manpage (Closes: #1055080)

Thanks for fixing this bug, and sorry for not following up on the
initial conversation.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1060320: dpkg-buildpackage: PERL_UNICODE variable causes bad encoding in output

[Guillem Jover]

Hi!

On Tue, 2024-01-09 at 15:39:33 +0100, Peter Krefting wrote:
> Package: dpkg-dev
> Version: 1.21.22
> Severity: wishlist
> Tags: l10n

> With PERL5OPTS=-Mutf8 and PERL_UNICODE=SDL set in environment [1], output from
> dpkg-buildpackage (and others) is garbled ("double" UTF-8 encoding):
> 
>   $ dpkg-buildpackage --version
>   Debian dpkg-buildpackage version 1.21.22.
> 
>   Detta program är fri programvara. Se GNU General Public License version 2
>   eller senare för kopieringsvillkor. Det finns INGEN garanti.
> 
> Unsetting PERL5OPTS fixes it:
> 
>   $ bash -c "unset PERL_UNICODE; dpkg-buildpackage --version"
>   Debian dpkg-buildpackage version 1.21.22.
> 
>   Detta program är fri programvara. Se GNU General Public License version 2
>   eller senare för kopieringsvillkor. Det finns INGEN garanti.

Right, dpkg does not currently set its streams to be UTF-8. But I
agree it probably should.

> [1] As per https://stackoverflow.com/a/6163129

Ah, yes, that page is great, I've had it in my bookmarks for a long
time. :D

In any case I started looking into this the other day, and the first
blocker is that adding «use open qw(:encoding(UTF-8) :std);» is not
enough as the gettext code needs to be switched to its Object Oriented
methods which handle encoding according to the locale automatically,
otherwise we also get doubly encoded output. I've got some of this in
a branch but…

…my concern is whether just with those two things will be enough, or
if we'll get botched input/output, like we did in around 2008, when a
similar change in spirit was done for dpkg-genchanges, dpkg-gencontrol
and dpkg-source. So I'll need to check all this thoroughly, and add
new test cases, etc.

Thanks,
Guillem

Bug#1061133: libsoup3: Build profiles don't actually work

[John Paul Adrian Glaubitz]

Source: libsoup3
Version: 3.4.4-2
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org

Hello,

I was just trying to bootstrap libsoup3 for sh4 using build profiles.

Unfortunately, that doesn't work since it seems that specifying multiple
build profiles for a build dependency means that the build dependency is
removed only if all of the specified profiles are activated.

Thus, in order to strip "libapache2-mod-php" from the build dependencies,
one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the
libapache2-mod-php build dependency is still pulled in.

This, however, means that that the "nocheck" profile has to be there to
boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the
build fail since this build dependency is mandatory.

Not sure if it's actually a bug in apt which handles multiple profiles
per build dependency other than one would expect.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1061131: Acknowledgement (Package does not purge quite well, but maybe could.)

[Rui Damas]

I just went to check about the libvirt-qemu group removal warning...
grep libvirt-qemu /etc/group ... o.O?... and there is not such
group... seams it got removed anyway, so why the warning?...

On 1/19/24, Debian Bug Tracking System  wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1061131:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061131.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Libvirt Maintainers
> 
>
> If you wish to submit further information on this problem, please
> send it to 1061...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1061131: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061131
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Thu, 2024-01-18 at 23:14:49 +, Aidan wrote:
> On Thu, Jan 18, 2024 at 6:30 PM David Kalnischkies wrote:
> > On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> > > I am looking for a sponsor for my package "dpkg-buildenv":
> >
> > Similar to my recent "veto" of apt-verify in #1059267, which was
> > subsequently ignored and pushed into the archive anyhow, I would
> > like to call into question the naming of the package/application…
> >
> > There are various "dpkg-build*" tools already that grabbing 'env' feels
> > wrong (I would confuse it probably with 'flag' on a bad day), especially
> > if that isn't at least discussed with dpkg maintainers (I at least see
> > no mention of it on the list) and given that this is something that
> > "just" works with Docker.

Just by chance I had seen the mail on the mentors list, but thanks for
the heads-up, because I tend to look there very sporadically!

My reaction was pretty similar TBH. There's enough confusion with
things like dpkg-reconfigure and dpkg-preconfigure and other packages
that have also grabbed from the dpkg-* namespace, which I'd like to
reduce. In this case, it would remove the possibility to use such name
in the future, creates confusion, and it looks like a layer violation,
because it's setting up apt, containers and stuff which should be
sitting on top and not below dpkg.

> > As explained in the other bug, there is no veto and as you can see its
> > easy to completely ignore me (and anyone else) but I wanted to say it
> > anyhow, so that nobody is surprised later on.

> Thanks for taking a look David.
> For the name I choose "dpkg'' because it stands for "debian package" and
> dpkg-buildenv is intrinsically related to debian packaging.
> However I understand the usage of dpkg may imply the package has been
> officially created and maintained by the dpkg developers.

Yes, see above. I also appreciate naming is hard, :) but all other
similar implementations could have claimed the same about using dpkg-*,
and I think josch questions are also relevant, even though I also
understand that even among all other options, none might seem
completely suitable to you. But…

> If the package's name was the last blocking issue preventing adoption in
> Debian then I would spend the time to rename it.

…regardless of whether this is or not the last blocking issue, I'd
still very much appreciate if you could rename the project and tool
upstream. :)

Thanks,
Guillem

Bug#1061131: Package does not purge quite well, but maybe could.

[Rui Damas]

Package: libvirt-daemon-system
Version: 9.0.0-4

I installed this package by mistake, by installing virt-manager with
recommends... so i purged virt-manager (and dependencies) to then
reinstall it.

... and noticed the following warnings:

Purging configuration files for libvirt-daemon-system (9.0.0-4) ...
userdel: group libvirt-qemu not removed because it is not the primary
group of user libvirt-qemu.
dpkg: warning: while removing libvirt-daemon-system, directory
'/var/lib/libvirt/qemu' not empty so not removed

O.o ... think that there is no need for the '/var/lib/libvirt/qemu'
not empty, since it only contains another empty directory inside:
/var/lib/libvirt/qemu/checkpoint/

As for the group libvirt-qemu complain, i have no idea about it

ps: similar happens to libvirt-daemon-config-nwfilter, for which i
will also fill a bug report.

Bug#1061132: Package does not purge quite well, but maybe could.

[Rui Damas]

Package: libvirt-daemon-config-nwfilter
Version: 9.0.0-4

I installed this package by mistake, by installing virt-manager with
recommends... so i purged virt-manager (and dependencies) to then
reinstall it.

... and noticed the following warning:

Purging configuration files for libvirt-daemon-config-nwfilter (9.0.0-4) ...
dpkg: warning: while removing libvirt-daemon-config-nwfilter,
directory '/etc/libvirt' not empty so not removed

O.o ... think that there is no need for the '/etc/libvirt' not empty,
since it only contains another empty directory inside:
/etc/libvirt/secrets/

ps: similar happens to libvirt-daemon-system, for which i will also
fill a bug report.

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Guillem Jover]

Hi!

On Wed, 2024-01-03 at 15:04:01 -0700, Sam Hartman wrote:
> > "Guillem" == Guillem Jover  writes:
> Guillem> At least the dpkg behavior seems entirely
> Guillem> correct to me and required for safe upgrades (
> 
> Can you help me understand the sentence above?
> Where is the case where this behavior is needed for safe upgrades?
> (I am asking out of curiosity; I'm guessing it's some corner case with
> essential packages, but I would like to understand.)

I should probably have qualified that statement, where safe upgrades
is restricted to the specific scenarios at hand. In any case, I don't
think this is specific to essential packages, this seems more general.
But of course the effects of not supporting such safe upgrades for
essential packages would be potentially more severe (although an
essential package can never be a conflictor as dpkg would refuse to
remove it).

In essence this involves a cyclic restriction where a set of packages
are stating they cannot be unpacked at the same time, but later
versions might be. There are several subcases for this depending on
the strength of the dependencies from each side, whether these are
versioned, and also whether the package manager front-end or the user
decides whether to fully evict a conflictor or wants to upgrade to a
latest version that can co-exist.

What the current behavior permits is to safely intertwine an unpack,
a conflictors files transfer and its removal in the same step, so that
the front-end or the user does not need to apply --force-* options to
forcibly remove the conflictor while breaking the dependency system
for an undetermined amount of time, to be able to proceed with such
upgrade.

I don't see any other way around this kind of upgrade that does not
break the dependency system besides the current behavior (if someone
does, I'm happy to hear it). Of course there's always the option to
prohibit those kinds of relationships, which means the behavior never
is brought up, and there's no need either to be concerned about whether
it needs to be supported or not. But that seems overly restrictive,
because once or if you need to express that kind of relationship, then
that path would be closed.


All this being said, when Helmut brought this up, I noticed that dpkg
is expecting to be hand held by giving to it the proper order for these
operations (as front-ends do), or it will either fail to upgrade
depending on the scenario, or unnecessarily use the conflictor eviction
behavior, which are not ideal (but do not break the dependency system).
I've got some test cases (Conflicts vs Breaks, Conflicts vs Conflicts),
which I should expand to add addition restrictions in the form of
Depends and Pre-Depends, unversioned relationships and similar, after
which I'll look into improving the way dpkg schedules its processing
queue in these cases so that it is a bit smarter about them and does
not fail so easily or uses this behavior unnecessarily when there's a
path forward at hand. But this seems besides the point of the conflictor
eviction behavior.

Thanks,
Guillem

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timelineg

[Steve Langasek]

On Wed, Jan 17, 2024 at 09:33:12PM -0800, Steve Langasek wrote:
> And my proposal for checking that set, since we're only talking about
> runtime library packages, is to check whether any of the contents of these
> packages in bookworm match ^/lib - as a runtime library package NOT matching
> this pattern, but matching a pattern for one of the other aliased
> directories, would be something ...  special.

Binary packages in bookworm shipping libs in /lib* (i.e. /lib, /lib32,
/lib64):

$ ssh -C coccia.debian.org zcat \
/srv/mirrors/debian/dists/bookworm/'*'/Contents-armhf.gz \
| awk -F/ '/^lib.*\.so/ { print $NF }' | sort -u | wc -l
222
$

Binary packages in experimental that are to be renamed:


$ for pkg in $(cat reports/lfs-and-depends-time_t reports/runtime-libs); do \
sed -n -e"s/Package: \($pkg\)$/\1/p" \
/var/lib/apt/lists/*experimental*Packages; \
  done | sort -u | wc -l
130
$

$ join -j1 usrmerge-libs experimental-libs 
libpam0g
$



I'll follow up on that.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli]

On Thu, 18 Jan 2024 07:56:08 -0500 James McCoy wrote:

[...]
> The latest upload has already fixed this.  It should migrate to testing
> as part of the ongoing Perl transition.

Thanks a lot for your very prompt reply!
I'll wait for the Perl transition to be completed and then I'll see.

Bye!

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


pgpinQ_uCDSbK.pgp
Description: PGP signature

Bug#1061130: sssd-common: not using alternatives for idmap-plugin

[Vincent Danjean]

Package: sssd-common
Version: 2.8.2-4
Severity: normal

  Hi,

  sssd-common provides /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so
that needs to be manually symlinked from /etc/cifs-utils/idmap-plugin
if we want to use it.
  However, cifs-utils provides /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
that it installs as /etc/cifs-utils/idmap-plugin with the
Debian alternative system:
# update-alternatives --list idmap-plugin
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
# update-alternatives --display idmap-plugin
idmap-plugin - auto mode
  link best version is /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
  link currently points to /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
  link idmap-plugin is /etc/cifs-utils/idmap-plugin
  slave idmap-plugin.8.gz is /usr/share/man/man8/idmap-plugin.8.gz
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - priority 40
  slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz


  As sssd-common does not use the alternative system,
each times cifs-utils is upgraded (security, ...),
the /etc/cifs-utils/idmap-plugin is recreated to
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
(via /etc/alternatives/idmap-plugin).

  So sssd-common should also use the alternative system,
probably with a priority below 40 (so that cifs-utils
version would still be the defaut as currently),
but allowing an admin sys to permanently change this.

  Regards,
Vincent


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

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

Versions of packages sssd-common depends on:
ii  adduser  3.137
ii  libc-ares2   1.25.0-1
ii  libc62.37-13
ii  libdbus-1-3  1.14.10-4
ii  libdhash10.6.2-2+b1
ii  libglib2.0-0 2.78.3-1
ii  libgssapi-krb5-2 1.20.1-5
ii  libini-config5   0.6.2-2+b1
ii  libkeyutils1 1.6.3-2+b2
ii  libkrb5-31.20.1-5
pn  libldap-2.4-2
ii  libldap-2.5-02.5.13+dfsg-5+b2
ii  libldb2  2:2.8.0+samba4.19.4+dfsg-2
ii  libnfsidmap1 [libnfsidmap2]  1:2.6.4-3
ii  libnl-3-200  3.7.0-0.2+b1
ii  libnl-route-3-2003.7.0-0.2+b1
pn  libnss-sss   
ii  libp11-kit0  0.25.3-4
pn  libpam-sss   
ii  libpam0g 1.5.2-9.1+b1
ii  libpcre2-8-0 10.42-4
ii  libpcre3 2:8.39-15
ii  libpopt0 1.19+dfsg-1
ii  libref-array10.6.2-2+b1
ii  libselinux1  3.5-1+b2
pn  libsemanage1 
ii  libsemanage2 3.5-1+b2
ii  libssl1.11.1.1w-0+deb11u1
ii  libssl3  3.1.4-2
pn  libsss-certmap0  
pn  libsss-idmap0
pn  libsss-nss-idmap0
ii  libsystemd0  255.2-4
ii  libtalloc2   2.4.1-2
ii  libtdb1  1.4.9-2
ii  libtevent0   0.15.0-1
pn  libunistring2
ii  libunistring51.1-2
ii  python3  3.11.6-1
pn  python3-sss  

Versions of packages sssd-common recommends:
ii  bind9-dnsutils  1:9.19.19-1
ii  bind9-host  1:9.19.19-1
pn  libnss-sss  
pn  libpam-sss  

Versions of packages sssd-common suggests:
ii  apparmor 3.0.12-1+b2
pn  libsss-sudo  
pn  sssd-tools   

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Aidan]

On Thu, Jan 18, 2024 at 6:30 PM David Kalnischkies 
wrote:

> Hi,
>
> On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> > I am looking for a sponsor for my package "dpkg-buildenv":
>
> Similar to my recent "veto" of apt-verify in #1059267, which was
> subsequently ignored and pushed into the archive anyhow, I would
> like to call into question the naming of the package/application…
>
> There are various "dpkg-build*" tools already that grabbing 'env' feels
> wrong (I would confuse it probably with 'flag' on a bad day), especially
> if that isn't at least discussed with dpkg maintainers (I at least see
> no mention of it on the list) and given that this is something that
> "just" works with Docker.
>
>
> As explained in the other bug, there is no veto and as you can see its
> easy to completely ignore me (and anyone else) but I wanted to say it
> anyhow, so that nobody is surprised later on.
>
>
> Best regards
>
> David Kalnischkies
>


Thanks for taking a look David.
For the name I choose "dpkg'' because it stands for "debian package" and
dpkg-buildenv is intrinsically related to debian packaging.
However I understand the usage of dpkg may imply the package has been
officially created and maintained by the dpkg developers.

If the package's name was the last blocking issue preventing adoption in
Debian then I would spend the time to rename it.

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Aidan]

On Thu, Jan 18, 2024 at 9:04 PM Johannes Schauer Marin Rodrigues <
jo...@debian.org> wrote:

> Hi Aidan,
>
> On Thu, 18 Jan 2024 16:52:26 +0100 Andrey Rakhmatullin 
> wrote:
> > I see you added this tool to the list of similar tools on the wiki so you
> > at least know about that list. So how is your tool better than other
> tools
> > on that list, or at least than the ones packaged in Debian?
> > Please also note that if you followed the procedure outlined at
> > https://mentors.debian.net/intro-maintainers/ and filed an ITP bug
> before
> > doing the packaging this discussion would happen there, not on the RFS
> bug.
>
>
Unlike other tools, dpkg-buildenv provides a complete dockerfile (
https://github.com/aidan-gallagher/dpkg-buildenv/blob/main/dpkg-buildenv/Dockerfile)
which describes the environment setup.
This makes it easy to integrate with other tools such as Jenkins (
https://github.com/aidan-gallagher/dpkg-buildenv/blob/main/dpkg-buildenv/Documentation/using-with-jenkins.md)
and VSCode (
https://github.com/aidan-gallagher/dpkg-buildenv/blob/main/dpkg-buildenv/Documentation/using-with-vscode.md
).

By integrating the Dockerfile with your Continuous Integration System
(Jenkins), it means the Jenkin's & developer's environment is guaranteed to
be the exact same.
I've written about the benefits of that here:
https://aidangallagher.co.uk/articles/continuous-integration-pipeline/.
The ability to run the Jenkins workload within a container is the reason I
started the work.


> I'm the current maintainer of sbuild. You found the wiki page and you saw
> that
> there already exist 10 different implementations of utilities that build
> Debian
> packages inside a docker container. You still decided to add an eleventh
> implementation so I guess my plea here will not amount to much but anyways
> here
> goes my sales pitch:
>
> If you want your code to be in Debian, please consider reviewing the patch
> attached to this bug report:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867176
>
> I'm not a docker user, so I cannot verify whether this is indeed doing the
> right thing but you are, so it should be easy for you to take it, test it
> and
> finalize it.
>
> I'm afraid contributing to an existing tool is not as sexy as supplying one
> that is 100% written by you but I can guarantee you that if you can clean
> up
> that patch, I will apply it to sbuild and your code will be in Debian
> proper.
>
> Maybe, hopefully we can make sbuilder and/or pbuilder work with docker
> instead
> of having eleven competing implementations doing the same thing?
>
> Thanks!
>
> cheers, josch


Thank you for taking the time to reply.
I shall have a look at sbuild and that patch however I am not familiar with
Perl and I imagine the sbuild implementation will be relatively more
complicated than dpkg-buildenv.

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[Alexandru Mihail]

On a later thought, this also works:
git diff debian/mini-httpd.postinst
diff --git a/debian/mini-httpd.postinst b/debian/mini-httpd.postinst
index 372bbe0..4a469d1 100644
--- a/debian/mini-httpd.postinst
+++ b/debian/mini-httpd.postinst
@@ -2,8 +2,10 @@
 set -e
 
 if [ ! -r /var/www/html/index.html ]; then
-mkdir -p /var/www/html
-cp /usr/share/doc/mini-httpd/examples/index.html
/var/www/html/index.html
+if [ -r /usr/share/doc/mini-httpd/examples/index.html ]; then
+mkdir -p /var/www/html
+cp /usr/share/doc/mini-httpd/examples/index.html
/var/www/html/index.html
+fi
 fi
 
 #DEBHELPER#


I tested it successfully on Debian Testing slim.
However, it will take me some time to add this to the next release and,
moreover, for that to make its way from sid -> testing. If urgent
action is required, use a local workaround; if not, wait for my upload
:)

Regards,
Alexandru Mihail


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

Bug#967256: apwal: depends on deprecated GTK 2

[Yavor Doganov]

Control: tags -1 + patch

Please find attached a patch.
(You might want to remove the last line from debian/rules to create a
dbgsym package.)
Description: Port to GTK 3.
Bug-Debian: https://bugs.debian.org/967256
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2024-01-19
---

--- apwal-0.4.5.orig/src/Makefile
+++ apwal-0.4.5/src/Makefile
@@ -7,11 +7,11 @@
 INSTALL ?= install
 
 ifdef APWAL_DEBUG
-CFLAGS += -g -Wall -Werror `$(PKG_CONFIG) --cflags gtk+-2.0 gthread-2.0 
libxml-2.0` -DGTK_DISABLE_DEPRECATED -DAPWAL_DEBUG $(CPPFLAGS)
-LDFLAGS += `$(PKG_CONFIG) --libs gtk+-2.0 gthread-2.0 libxml-2.0`
+CFLAGS +=  -DAPWAL_DEBUG $(CPPFLAGS) -g -Wall -Werror `$(PKG_CONFIG) --cflags 
gtk+-3.0 gthread-2.0 libxml-2.0`
+LDFLAGS += `$(PKG_CONFIG) --libs gtk+-3.0 gthread-2.0 libxml-2.0`
 else
-CFLAGS += -O2 `$(PKG_CONFIG) --cflags gtk+-2.0 gthread-2.0 libxml-2.0` 
$(CPPFLAGS)
-LDFLAGS += -O2 `$(PKG_CONFIG) --libs gtk+-2.0 gthread-2.0 libxml-2.0`
+CFLAGS += $(CPPFLAGS) -O2 `$(PKG_CONFIG) --cflags gtk+-3.0 gthread-2.0 
libxml-2.0`
+LDFLAGS += -O2 `$(PKG_CONFIG) --libs gtk+-3.0 gthread-2.0 libxml-2.0`
 endif
 
 OBJS=main.o app.o launcher.o editor.o property.o \
@@ -34,7 +34,6 @@
 all: apwal
 apwal: $(OBJS)
$(CC) -o $@ $^ $(LDFLAGS)
-   $(STRIP) $@
 endif
 
 install: all
@@ -42,14 +41,14 @@
$(INSTALL) apwal $(DESTDIR)/usr/bin
 
 .c.o: $(INCS)
-   $(CC) -c $< -o $*.o $(CFLAGS)
+   $(CC) $(CFLAGS) -c $< -o $*.o
 
 xmlrc.o: xmlrc.c $(INCS)
-   $(CC) -c $< -o $*.o $(CFLAGS)
+   $(CC) $(CFLAGS) -c $< -o $*.o
 about.o: about.c $(INCS) ../Makefile.inc
-   $(CC) -c $< -o $*.o $(CFLAGS) -DAPWAL_VERSION=\"$(VERS)\"
+   $(CC) -DAPWAL_VERSION=\"$(VERS)\" $(CFLAGS) -c $< -o $*.o
 
-gtkstuff.o: pixbufinline.inc
+gtkstuff.o: pixbufinline.inc gresource.c
 xmlrc.o: xmlrcinline.inc
 
 $(OBJS): $(INCS)
@@ -88,6 +87,18 @@
echo   "sizeof(pixbufinline_t));" >> $@; \
echo "" >> $@;
 
+gresource.c: ../pixmaps/*.png
+   @echo "generating $@..."
+   @echo "" >> $*.xml
+   @echo "" >> $*.xml
+   @echo "" >> $*.xml
+   @for f in ../pixmaps/*.png; do \
+ echo "$$f" >> $*.xml; \
+   done;
+   @echo "" >> $*.xml
+   @echo "" >> $*.xml
+   @glib-compile-resources --generate-source $*.xml
+
 tags: $(INCS) $(OBJS:.o=.c)
ctags -R
 
@@ -102,5 +113,5 @@

 
 clean:
-   -rm -f $(OBJS) apwal pixbufinline.inc xmlrcinline.inc tags
+   -rm -f $(OBJS) apwal pixbufinline.inc gresource.* xmlrcinline.inc tags
 
--- apwal-0.4.5.orig/src/apwalapp.h
+++ apwal-0.4.5/src/apwalapp.h
@@ -49,9 +49,6 @@
   GtkWidget   *w2_btn_cancel;
   GtkWidget   *w2_btn_ok;
 
-  
-  GtkTooltips  *tips;
-
   struct apwal_pref_t *apwal_pref;
   struct editor_t *editor;
   struct property_t   *prop;
--- apwal-0.4.5.orig/src/launcher.h
+++ apwal-0.4.5/src/launcher.h
@@ -35,7 +35,6 @@
   GtkWidget *event_box;
   GtkWidget *image;
   GdkPixbuf *pixbuf;
-  GdkBitmap *bitmap_mask;
 
   gint   x;
   gint   y;
--- apwal-0.4.5.orig/src/launcher.c
+++ apwal-0.4.5/src/launcher.c
@@ -29,6 +29,7 @@
 {
   launcher_t  *l;
   app_list_t *apps;
+  GdkRectangle geom;
 
   l = (launcher_t *)malloc(sizeof(launcher_t));
   g_assert(l != NULL);
@@ -51,7 +52,6 @@
 
   l->image = NULL;
   l->pixbuf = NULL;
-  l->bitmap_mask = NULL;
 
   l->x = 0;
   l->y = 0;
@@ -60,8 +60,10 @@
 
   l->editor_started = FALSE;
 
-  l->xwidth = gdk_screen_width();
-  l->xheight = gdk_screen_height();
+  gdk_monitor_get_geometry(gdk_display_get_primary_monitor
+   (gdk_display_get_default()), );
+  l->xwidth = geom.width;
+  l->xheight = geom.height;
 
   l->timeout_activated = 0;
   l->apps = NULL;
@@ -75,6 +77,10 @@
 void launcher_load_apps(launcher_t *l, app_list_t *apps)
 {
   app_t *app;
+  cairo_surface_t *surf;
+  cairo_region_t *region;
+  GdkWindow *win;
+  GdkSeat *seat;
   GdkPixbuf *pixbuf;
   GdkModifierType state;// mouse state
   gint x_min, y_min;
@@ -93,7 +99,6 @@
 
   l->pixbuf = NULL;
   l->image = NULL;
-  l->bitmap_mask = NULL;
 
   l->apps = apps;
   if (!apps)
@@ -107,7 +112,11 @@
  app_list_delta_x(l->apps), app_list_delta_y(l->apps),
  x_min, y_min); 
   // get the current position of the mouse cursor
-  gdk_window_get_pointer (l->window->window, >x, >y, );
+  gtk_widget_realize(l->window);
+  seat = gdk_display_get_default_seat(gdk_display_get_default());
+  win = gtk_widget_get_window(l->window);
+  gdk_window_get_device_position(win, gdk_seat_get_pointer(seat),
+ >x, >y, );
   // check if the position is correct
   l->x = l->x + (x_min * ICON_WIDTH);
   if (l->x < 0)
@@ -149,15 +158,19 @@
 app = app_list_next(l->apps);
   }
 
-  gdk_pixbuf_render_pixmap_and_mask(l->pixbuf,
-NULL/*pixmap_return*/,
->bitmap_mask/*mask_return*/,
-

Bug#1061129: baresip-gtk: GTK interface not working

[Martina Ferrari]

Package: baresip-gtk
Version: 1.0.0-4+b7
Severity: important
X-Debbugs-Cc: t...@debian.org

Hi,

The baresip-gtk package seems to be completely unusable. There is no menu entry
for it, executing the `baresip` command just starts the CLI, and I cannot load
the gtk module manually either.

$ baresip -m gtk
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:  IPv4=wlp0s20f3|10.x.x.x
pre-loading modules: 1
dl: mod: ./gtk (./gtk: cannot open shared object file: No such file or 
directory)
module gtk: No such file or directory
could not pre-load module 'gtk' (No such file or directory)

$ baresip -m /usr/lib/baresip/modules/gtk.so
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:  IPv4=wlp0s20f3|10.x.x.x
pre-loading modules: 1
dl: mod: .//usr/lib/baresip/modules/gtk.so (.//usr/lib/baresip/modules/gtk.so: 
cannot open shared object file: No such file or directory)
module /usr/lib/baresip/modules/gtk.so: No such file or directory
could not pre-load module '/usr/lib/baresip/modules/gtk.so' (No such file or 
directory)

$ cd /
$ baresip -m /usr/lib/baresip/modules/gtk.so
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:  IPv4=wlp0s20f3|10.x.x.x
pre-loading modules: 1
aufilt: gtk_vumeter
gtk: message_init failed (Invalid argument)
module /usr/lib/baresip/modules/gtk.so: Invalid argument
could not pre-load module '/usr/lib/baresip/modules/gtk.so' (Invalid argument)



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 baresip-gtk depends on:
ii  baresip-core  1.0.0-4+b7
ii  libc6 2.37-13
ii  libglib2.0-0  2.78.3-1
ii  libgtk2.0-0   2.24.33-2

baresip-gtk recommends no packages.

baresip-gtk suggests no packages.

-- no debconf information

Bug#1061123: suitesparse breaks octave autopkgtest: it hangs

[Sébastien Villemot]

Control: reassign -1 libsuitesparse-dev 1:7.4.0+dfsg-1
Control: forcemerge 1061049 -1

Le jeudi 18 janvier 2024 à 19:48 +0100, Paul Gevers a écrit :
> Source: suitesparse, octave
> Control: found -1 suitesparse/1:7.5.1+dfsg-1
> Control: found -1 octave/8.4.0-1
> Severity: serious
> Tags: sid trixie
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of suitesparse the autopkgtest of octave fails in 
> testing when that autopkgtest is run with the binary packages of 
> suitesparse from unstable. It passes when run with only packages from 
> testing. In tabular form:
> 
> passfail
> suitesparsefrom testing1:7.5.1+dfsg-1
> octave from testing8.4.0-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Normally the 
> test only takes a couple of minutes, now it times out after 2:47 hours. 
> I'm notifying you already as this is currently also impacting the perl 
> transition via texinfo.
> 
> Currently this regression is blocking the migration of suitesparse to 
> testing [1]. Due to the nature of this issue, I filed this bug report 
> against both packages. Can you please investigate the situation and 
> reassign the bug to the right package?

Thanks. This is due to a ABI break in suitesparse. We’re currently
discussing the best fix with upstream.

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



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

Bug#1061128: RM: commando -- RoQA; dead upstream; orphaned; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:commando
Control: block 1061113 by -1
Control: tags 1061113 - moreinfo

Please remove the package commando. Last upstream action was 9.5 years ago.
The package is orphaned and has a very low popcon, so it should be unused.

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Arno Lehmann]

Hello,

Am 18.01.2024 um 22:12 schrieb Salvatore Bonaccorso:

Hi,

On Sat, Jan 13, 2024 at 04:39:51PM +0100, Arno Lehmann wrote:

Hi Salvatore,

Am 13.01.2024 um 13:47 schrieb Salvatore Bonaccorso:


Just to be clear, can you confirm this is or is not a regression from
a previous running 6.1.y kernel?


On this hardware, the network issues appeared right from the start.

First time I encountered it was with the Debian installation sime time last
year, and that's where my research led me to turn off PCIe power management.

Actually I don't even know which was the first kernel version I had on this
host, but it's been on Bookworm for all its lifetime.


This "feels" like its probably not really a regression, thus the
similarity (though not the identical case as the referenced thread).

What about newer kernels? Do 6.6.11-1 or 6.7-1~exp1 taken from
unstable (resp. experimental) show the same problem?

If yes, then it might be an idea to bring it upstream.


Well, tricky... at this stage, we're guessing what will tell us more -- 
newer kernel or an older one. And then we'll need to wait for while to 
see what happens.


Well, tomorrow morning I'll be on site and can then install another 
kernel and reboot.


Cheers,

Arno


--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Salvatore Bonaccorso]

Hi,

On Sat, Jan 13, 2024 at 04:39:51PM +0100, Arno Lehmann wrote:
> Hi Salvatore,
> 
> Am 13.01.2024 um 13:47 schrieb Salvatore Bonaccorso:
> 
> > Just to be clear, can you confirm this is or is not a regression from
> > a previous running 6.1.y kernel?
> 
> On this hardware, the network issues appeared right from the start.
> 
> First time I encountered it was with the Debian installation sime time last
> year, and that's where my research led me to turn off PCIe power management.
> 
> Actually I don't even know which was the first kernel version I had on this
> host, but it's been on Bookworm for all its lifetime.

This "feels" like its probably not really a regression, thus the
similarity (though not the identical case as the referenced thread).

What about newer kernels? Do 6.6.11-1 or 6.7-1~exp1 taken from
unstable (resp. experimental) show the same problem?

If yes, then it might be an idea to bring it upstream.

Regards,
Salvatore

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Johannes Schauer Marin Rodrigues]

Hi Aidan,

On Thu, 18 Jan 2024 16:52:26 +0100 Andrey Rakhmatullin  wrote:
> I see you added this tool to the list of similar tools on the wiki so you
> at least know about that list. So how is your tool better than other tools
> on that list, or at least than the ones packaged in Debian? 
> Please also note that if you followed the procedure outlined at
> https://mentors.debian.net/intro-maintainers/ and filed an ITP bug before
> doing the packaging this discussion would happen there, not on the RFS bug.

I'm the current maintainer of sbuild. You found the wiki page and you saw that
there already exist 10 different implementations of utilities that build Debian
packages inside a docker container. You still decided to add an eleventh
implementation so I guess my plea here will not amount to much but anyways here
goes my sales pitch:

If you want your code to be in Debian, please consider reviewing the patch
attached to this bug report:

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

I'm not a docker user, so I cannot verify whether this is indeed doing the
right thing but you are, so it should be easy for you to take it, test it and
finalize it.

I'm afraid contributing to an existing tool is not as sexy as supplying one
that is 100% written by you but I can guarantee you that if you can clean up
that patch, I will apply it to sbuild and your code will be in Debian proper.

Maybe, hopefully we can make sbuilder and/or pbuilder work with docker instead
of having eleven competing implementations doing the same thing?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[Alexandru Mihail]

Hi again,
I've finally cracked the code !
I finally found out what the difference is, regarding package installs,
between the official and slim images.
Mainly, the existence of this file, which overrides dpkg official
logic:
/etc/dpkg/dpkg.cfg.d/docker
You can check this yourself !
This file is NOT present in the non-slim images (checked on sid and
sid-slim just to be sure as well).
The file does a bunch of wild stuff, mainly telling dpkg (apt backend)
to exclude a bunch of folders and files (through wildcards) from dpkg
installs and configures (mainly /usr/share/doc, locale).
This seems logical for a slimmed down image, but may lead to
inconsistent results. Out of pure curiosity I tried installing some
other random packages I use and, sure enough, one of them failed in a
similar way (failed to cp to /usr/share/doc//examples/config.txt). It was mc or an apache plugin I think.

Anyway, adding this last line with mini-httpd:
root@ef77c06126ea:/etc/dpkg/dpkg.cfg.d# tail -n 1
/etc/dpkg/dpkg.cfg.d/docker
path-include /usr/share/doc/mini-httpd/examples/*

seems to fix it (works as expected).
I see the maintainer of this image did a similar workaround for other
stuff around such as this line:
path-include /usr/share/doc/kde/HTML/C/*

Thus, I propose the easiest fix of adding this to your yaml config file
(I don't have much experience with docker). I still want to ship this
file in the official manner which other packages use, so I'm reluctant
to propose a workaround which is only applicable here. I'm working on
patching some existing C problems which affect all users, currently.
However, if you or anyone else proposes a fix which does not affect
normal operation in the debian:testing docker && plain install use
cases and does not break lintian rules, I'm more than happy to
incorporate it in mini-httpd:1.30-7.

If you find the workaround satisfactory and you need to use the slim
image, please close this bug via bugs.debian.org; if not I'm open to
suggestions and patch proposals.

Thank you for improving the quality of Debian packages !

Alexandru Mihail
mini-httpd maintainer

On Thu, 2024-01-18 at 17:35 +0100, lor...@freenet.de wrote:
> On Thu 2024-01-18 17:17, Alexandru Mihail wrote:
> > Can you replicate the problem by running apt purge mini-httpd &&
> > apt >install mini-httpd ? (docker)
> 
> # docker run -ti --rm debian:testing-slim bash -c "apt-get update &&
> apt-get purge mini-httpd && apt-get install -y mini-httpd
> [...]
> Package 'mini-httpd' is not installed, so not removed
> [...]
> Setting up mini-httpd (1.30-6) ...
> cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No
> such file or directory
> dpkg: error processing package mini-httpd (--configure):
>  installed mini-httpd package post-installation script subprocess
> returned error exit status 1
> Setting up libgdbm6:amd64 (1.23-5) ...
> Setting up libaprutil1:amd64 (1.6.3-1+b1) ...
> Setting up apache2-utils (2.4.58-1+b1) ...
> Processing triggers for libc-bin (2.37-13) ...
> Errors were encountered while processing:
>  mini-httpd
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> > Can you replicate in a non-docker environment (testing or sid) if
> > you have access to one ?
> 
> no, but I can use another base image
> 
> # docker run -ti --rm debian:testing bash -c "apt-get update && apt-
> get install -y mini-httpd"
> 
> this works. The error seems only to happen on debian:testing-slim but
> not on debian:testing



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

Bug#1061094: mmdebstrap vs. apt -o DPkg::Inhibit-Shutdown

[David Kalnischkies]

tl;dr: Fine by me, just some explaining comments for the record.

On Thu, Jan 18, 2024 at 12:54:45PM +1100, Trent W. Buck wrote:
> This MIGHT affect someone else doing "apt -o Dir=⋯" to do custom installs, but
> everything I can think of offhand is a wrapper around debootstrap, except for
> https://github.com/openSUSE/obs-build/blob/master/obs-docker-support#L118

This one sets different sources.list files, doesn't change Dir and is
hence still effected by the inhibit… except that this probably runs
somewhere in docker, so likely without dbus, systemd and what not.


> Everything I can find seems to set e.g. Dir::Etc rather than Dir itself.
> 
> https://codesearch.debian.net/search?q=apt.*-o.*Dir%5B%5E%3A%5D
> https://github.com/search?q=%2Fapt.*-o.*Dir%2F=code  (requires 
> Microsoft account, requires javascript)

Just for the record: To find more users you would need to look for
RootDir as well, which was used heavily before Dir. Looking for scripts
setting these options on the command line is probably not catching a lot
of users as command line parsing happens pretty late – after config
files are read – so setting {Root,}Dir is usually done in a config file
given via the APT_CONFIG environment variable.

Case in point: Our very own test cases do something akin to chrootless
mode of mmdebstrap with APT_CONFIG and Dir … and now I wonder how often
those tests inhibit and release the block on shutdown. I guess I never
tried to shutdown while running our tests. ☺

Also, as this is libapt, this isn't apt specific, could potentially be
used via apt-get, aptitude, python-apt, libapt-perl, synaptics, your run
of the mile software center, … its just increasingly unlikely.

A usecase I could imagine is someone trying to recover his main system
from a live CD. If your main system is sufficiently broken that
chrooting into it doesn't really work you could operate on it from the
outside similar to mmdebstrap (after all, the to be bootstrapped system
is sufficiently broken… given it doesn't really exist yet).


Anyway, this is a relatively new safeguard (60cc44d160 – April 2019)
nobody should really hard-depend on: Having it inhibited for too many
or for too few by default isn't that big of a problem and if someone
cares either way they can always set the option explicitly.

Given it is mainly supposed to avoid accidents for users who don't
interact with apt directly Dir == "/" is probably the closest we can
be to a sensible default value for the inhibition here if we ignore
that ideally the front ends would do the inhibition instead of our
low-level library, but that ship sailed…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1061048: RFS: RPGMod/1.3 ITP -- heyo!

[David Kalnischkies]

On Tue, Jan 16, 2024 at 07:42:09PM -0300, peq42 wrote:
> I am looking for a sponsor for my package "RPGMod":

Package names are lowercase.

No idea about the package or what it even is, but it looks a bit and
mentions games, so the Debian Games Team might be a good place to
find people/sponsors who know the field and can give hints:
https://wiki.debian.org/Games/Team


> * URL : http://peq42.com

I suppose: https://peq42.com/projects/rpgmod/


> * Vcs : https://peq42.com/downloads/RPGmod%20-%20Linux.deb

"Vcs" means "Version control system", while optional its strongly
recommend to use one (also for your upstream development). Look it
up on your preferred search engine; it might change your life.


> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x https://peq42.com/downloads/RPGmod%20-%20Linux.deb

Usually, you upload a source package that builds one (or more) binary
packages (= the deb files).

Your deb uses zst as compressor, so I guess you built it on a semi
recent Ubuntu release (older versions might have problems with it,
Debian releases even more – read-only support exists rather recentish).
You don't need to know what the first part of that sentence means to be
a good packager (but feel free to look it up if you are interested), but
packages for Debian should be built in the Debian release they are
targeting (for a new package, that would usually be 'unstable') – you
can use virtual machines, chroots and what not for that and use e.g.
tools like sbuild.

Your package installs (most) things in /opt – that isn't suitable for
packages targeted at the Debian archive. I also note that your package
claims to have no dependencies whatsever, which I find somewhat hard to
believe even if it is technically possible.


> additional comments:
> I'm sorry if this e-mail is not exactly perfect or if anything is missing,
> this is my first time packaging and submiting a package to the debian store.
> I setup the package using my personal e-mail(gabrielpm2...@gmail.com) and
> real name(Gabriel), but for the sake of lowering spam I get there, if
> possible, utilize this one(admi...@peq42.com) in the store

You can give any mail you like in the packaging… personally I am using
my @debian.org address in the packages and my personal mail for
communication on this and other lists, reply to bugreports and so on.
Others do the reverse. None of it will help lower spam though as nobody
and nothing can avoid an (un)healthy dosage of spam.


Note that Debian doesn't have a "store". We have repository(s) which
can mean the same thing and actually pre-dates stores, but usually
involves a different mind set: (Personal opinion follows) We don't
"sell" individual packages as products, but an entire catalog of
70.000+ packages that work (and play) well together.


As said, I haven't looked too closely at the package, but even so
I think you will need to invest a lot more work into making it fit for
the Debian archive… or in other words: lots of documentation to read,
policies to follow and friends to make on and off list(s).


Good luck & Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1061120: rust-ahash-0.7 autopkgtest failure

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2024-01-18 20:50:38)
> Quoting Peter Green (2024-01-18 19:29:59)
> > The autopkgtests for rust-ahash-0.7 are failing, this is blocking the
> > migration of rust-ahash-0.7 to testing which is in turn blocking the
> > migration of at least one rc bug fix to testing.
> > 
> > There are two issues, the first is that the autopkgtests are trying
> > to test a "runtime-rng" feature, but no such feature exists. My guess
> > is that there was some confusion between versions of ahash. I removed
> > the tests and the corresponding provides.
> > 
> > The second issue is more subtle. The "atomic-polyfill" feature
> > enables the dependency on the atomic-polyfill crate. However the
> > dependency on the atomic-polyfill crate is disabled on linux
> > (among many other targets). Disabling of a dependency on a target
> > overrides enabling the dependency in a feature. However the code
> > is not aware of this. The result is that building on Linux with
> > the atomic-polyfill feature enabled fails.
> 
> Thanks for the valuable input.
> 
> I am not convinced about the assessment related to and need for
> disabling runtime-rng, however, and it also seems that you applied not
> one but several measures for the atomic-polyfill issue - I will try do a
> more minimal fix for the atomic-polyfill issue to see if that is
> adequate.

Ahh, now I see the runtime-rng failure.  Seems to not be a confusion but
a hidden feature dynamically added to the publicly advertised ones, and
unexpected by the bench resolver to be explicitly declared.

Perhaps that's what you meant as well, or perhaps I am rambling - in any
case, I end at the same solution as you proposed.  Again, thanks a lot!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1061126: mysql-8.0: Security fixes from January 2024 CPU

[Salvatore Bonaccorso]

Source: mysql-8.0
Version: 8.0.35-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

See
https://www.oracle.com/security-alerts/cpujan2024.html#AppendixMSQL
for a list of CVEs affecting src:mysql-8.0.

Regards,
Salvatore

Bug#1061120: rust-ahash-0.7 autopkgtest failure

[Jonas Smedegaard]

Quoting Peter Green (2024-01-18 19:29:59)
> The autopkgtests for rust-ahash-0.7 are failing, this is blocking the
> migration of rust-ahash-0.7 to testing which is in turn blocking the
> migration of at least one rc bug fix to testing.
> 
> There are two issues, the first is that the autopkgtests are trying
> to test a "runtime-rng" feature, but no such feature exists. My guess
> is that there was some confusion between versions of ahash. I removed
> the tests and the corresponding provides.
> 
> The second issue is more subtle. The "atomic-polyfill" feature
> enables the dependency on the atomic-polyfill crate. However the
> dependency on the atomic-polyfill crate is disabled on linux
> (among many other targets). Disabling of a dependency on a target
> overrides enabling the dependency in a feature. However the code
> is not aware of this. The result is that building on Linux with
> the atomic-polyfill feature enabled fails.

Thanks for the valuable input.

I am not convinced about the assessment related to and need for
disabling runtime-rng, however, and it also seems that you applied not
one but several measures for the atomic-polyfill issue - I will try do a
more minimal fix for the atomic-polyfill issue to see if that is
adequate.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Hi Reinhard,

Instead of packaging golang-github-cyberphone-json-canonicalization I
uploaded a NMU for golang-webpki-org-jsoncanonicalizer to make it
provide the name that rekor expects, thereby closing this ITP bug with
this NMU upload.  See debdiff below.

What do you think about moving this package into the go-team umbrella?
I can help maintain it if you agree.

Before I understood that golang-webpki-org-jsoncanonicalizer was in
unstable (there was no ITP bug!  I though it was never uploaded) I did
some work to clean up this packaging, on my 'jas-upstream' and
'jas-debian/sid' branches in URL below.  That work is unfinished, but if
you agree, I can move this into the go-team umbrella and make an
experimental upload with updated packaging for testing.

https://salsa.debian.org/jas/golang-webpki-org-jsoncanonicalizer/-/tree/jas-debian/sid

/Simon

diff -Nru golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog
--- golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
2023-11-13 02:47:06.0 +0100
+++ golang-webpki-org-jsoncanonicalizer-0.20210204/debian/changelog 
2024-01-18 19:52:58.0 +0100
@@ -1,3 +1,10 @@
+golang-webpki-org-jsoncanonicalizer (0.20210204-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add link for name used by rekor.  Closes: #1060820.
+
+ -- Simon Josefsson   Thu, 18 Jan 2024 19:52:58 +0100
+
 golang-webpki-org-jsoncanonicalizer (0.20210204-1) unstable; urgency=medium
 
   * Initial release.
diff -Nru golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 
golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links
--- golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 1970-01-01 
01:00:00.0 +0100
+++ golang-webpki-org-jsoncanonicalizer-0.20210204/debian/links 2024-01-18 
19:52:58.0 +0100
@@ -0,0 +1 @@
+usr/share/gocode/src/webpki.org/jsoncanonicalizer 
usr/share/gocode/src/github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer


signature.asc
Description: PGP signature

Bug#1061125: rustc: Please disable profiler builtin on sparc64

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.70.0+dfsg1-5
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

The recently enabled profiler builtin is currently not supported on sparc64
and therefore leads to rustc failing to build from source [1]:

error: could not find native static library `/usr/lib/llvm-16/lib/clang/16/lib/\
 linux/libclang_rt.profile-sparc64.a`, perhaps an -L flag is missing?

We need to fix the profiler in LLVM upstream on sparc64 first before we can
enable it in Debian.

Could you disable the profiler builtin for sparc64 again?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=rustc=sparc64=1.70.0%2Bdfsg1-5=1705412917=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1061124: lmms-vst-server:i386 plug-in not compatible with lmms:amd64

[Joe]

Package: lmms-vst-server
Version: 1.2.2+dfsg1-6
Severity: important
X-Debbugs-Cc: shanny...@yahoo.fr

Dear Maintainer,
loading and running VST is an important part of a music software, unfortunately
it seems impossible on the 64-bit version of LMMS due to architecture
incompatibility between the software and the plug-in provided by the package
lmms-vst-server, which just wouldn't show up in LLMS.

An incompatibility I wasn't initially aware off and online search only had
everyone recommending to use the appimage version.

Uninstalling the amd64 version and installing the i386 allowed both LMMS and
the VeSTige plug-in to work properly. I don't think most amd64 users people
think of that.

Until a amd64 compatible plug-in is released you might want to add a note to
lmms-vst-server's package description that it isn't compatible with lmms:amd64
and VST support is only available for lmms:i386 .

Best regards. -Joe


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/12 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lmms-vst-server depends on:
ii  libc6 2.36-9+deb12u3
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5x11extras5  5.15.8-2
ii  libqt5xml55.15.8+dfsg-11
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxcb1   1.15-1
ii  wine [wine]   8.0~repack-4
ii  wine328.0~repack-4

Versions of packages lmms-vst-server recommends:
ii  lmms  1.2.2+dfsg1-6

lmms-vst-server suggests no packages.

-- no debconf information

Bug#1041786: codeblocks: randomly crashes when writing c++ code

[Andreas B. Mundt]

Package: codeblocks
Followup-For: Bug #1041786
X-Debbugs-Cc: a...@debian.org
Control: tags -1 upstream

Hi,

we have the same problem, CB crashing much too often …

I found an upstream bug report with a recipe provoking crashes, and
indeed I was able to crash the program in gdb.  I prepared Debian packages
with latest upstream source applied and recompiled on bookworm to make
sure the bug is not already fixed.

You can find coredump and some more detail at the upstream report at:
 https://sourceforge.net/p/codeblocks/tickets/1152/#d644

Best regards,

  Andi

Bug#1004901: ncurses-bin: issues with the infocmp(1) man page and databases

[Sven Joachim]

On 2022-02-03 11:10 +0100, Vincent Lefevre wrote:

> Package: ncurses-bin
> Version: 6.3-2
> Severity: minor
>
> In the infocmp(1) man page:
>
>Changing Databases [-A directory] [-B directory]
>Like  other  ncurses  utilities, infocmp looks for the terminal
>descriptions in several places.  You can use the  TERMINFO  and
>TERMINFO_DIRS environment variables to override the compiled-in
>default list of places to search (see curses(3X) for details).
>
> The curses(3X) man page does not exist. It is curses(3ncurses).

This particular problem has been fixed in version 6.3+20220423-1,
probably as a consequence of the following change in the 20211225
patchlevel:

,
| + improve markup, e.g., for external manpage links in the manpages
|   (prompted by report by Helge Kreutzmann).
`

As of version 6.4+20240113-1 there are no longer any '3X' references in
any of the manpages, and I have also added an autopkgtest to ensure that
they do not come back.

> Moreover,
>
>   FILES
>/etc/terminfo   Compiled terminal description database.
>
> It is empty in my case. It appears that infocmp looks at other places,
> such as /lib/terminfo (most cases) and "$HOME/.terminfo".

Yes.  There are several places in the manpages where /etc/terminfo is
referred to as the system terminfo database, but it is really just the
place where tic(1) writes to by default, whereas the terminfo entries
provided by the distribution usually live under /usr/share/terminfo.
Someone™ should improve that, because it basically affects every Linux
distro out there.

> Instead of giving a directory that is not used in practice, give a
> reference to the curses(3ncurses) man page?

That would probably not be too helpful, because that manpage is likely
not present.  The "Fetching Compiled Descriptions" section in
terminfo(5) is probably the most accurate reference.

Cheers,
   Sven

Bug#1061123: suitesparse breaks octave autopkgtest: it hangs

[Paul Gevers]

Source: suitesparse, octave
Control: found -1 suitesparse/1:7.5.1+dfsg-1
Control: found -1 octave/8.4.0-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of suitesparse the autopkgtest of octave fails in 
testing when that autopkgtest is run with the binary packages of 
suitesparse from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
suitesparsefrom testing1:7.5.1+dfsg-1
octave from testing8.4.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Normally the 
test only takes a couple of minutes, now it times out after 2:47 hours. 
I'm notifying you already as this is currently also impacting the perl 
transition via texinfo.


Currently this regression is blocking the migration of suitesparse to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=suitesparse

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave/41870107/log.gz

 94s  94s Integrated test scripts:
 94s  94s   liboctave/array/Array-base.cc-tst 
.. pass   21/21   94s 
liboctave/array/CMatrix.cc-tst . pass 
11/11   94s   liboctave/array/CSparse.cc-tst 
. pass   10/10   94s 
liboctave/array/Sparse.cc-tst .. pass 
107/107  94s   liboctave/array/dMatrix.cc-tst 
. pass   10/10   94s 
liboctave/array/dSparse.cc-tst . pass 
12/12   94s   liboctave/array/fCMatrix.cc-tst 
 pass   11/11   94s 
liboctave/array/fMatrix.cc-tst . pass 
8/894s   liboctave/array/idx-vector.cc-tst 
.. pass2/294s 
liboctave/util/oct-inttypes.cc-tst . pass 
28/28   94s   libinterp/corefcn/Cell.cc-tst 
.. pass5/594s 
libinterp/corefcn/__contourc__.cc-tst .. pass 
1/194s   libinterp/corefcn/__dsearchn__.cc-tst 
.. pass1/194s 
libinterp/corefcn/__eigs__.cc-tst .. pass 
1/194s   libinterp/corefcn/__ichol__.cc-tst 
. pass1/194s 
libinterp/corefcn/__ilu__.cc-tst ... pass 
1/195s   libinterp/corefcn/__isprimelarge__.cc-tst 
.. pass   10/10   95s 
libinterp/corefcn/__lin_interpn__.cc-tst ... pass 
1/195s   libinterp/corefcn/__magick_read__.cc-tst 
... pass4/495s 
libinterp/corefcn/__pchip_deriv__.cc-tst ... pass 
4/495s   libinterp/corefcn/__qp__.cc-tst 
 pass1/195s 
libinterp/corefcn/amd.cc-tst ... pass 
4/495s   libinterp/corefcn/besselj.cc-tst 
... pass  200/200  96s 
libinterp/corefcn/bitfcns.cc-tst ... pass 
60/60  100s   libinterp/corefcn/bsxfun.cc-tst 
 pass   82/82  100s 
libinterp/corefcn/call-stack.cc-tst  pass 
3/3   102s   libinterp/corefcn/cellfun.cc-tst 
... pass  134/134 102s 
libinterp/corefcn/chol.cc-tst 
..malloc(): invalid size (unsorted)
10094s fatal: caught signal autopkgtest [06:55:22]: ERROR: timed out on 
command "su -s /bin/bash debci -c set -e; exec 
/tmp/autopkgtest-lxc.gixhwtgb/downtmp/wrapper.sh 
--artifacts=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-artifacts 
--chdir=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/build.byz/src 
--env=DEB_BUILD_OPTIONS=parallel=64 --env=DEBIAN_FRONTEND=noninteractive 
--env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS 
--unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE 
--unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT 
--unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME 
--unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE 
--unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid 
--source-profile 
--stderr=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-stderr 
--stdout=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/upstream-testsuite-stdout 
--tmp=/tmp/autopkgtest-lxc.gixhwtgb/downtmp/autopkgtest_tmp 

Bug#1061122: openarena on wayland unplayable, too dark to see

[J Sloan]

Package: openarena
Version: 0.8.8+dfsg-7+b1
Severity: important
Tags: upstream

Dear Maintainer,


   * What led up to the situation? Attempting to launch openarena on Debian sid 
(trixie)
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I tried to increase the brightness using the game controls
   * What was the outcome of this action? no change
   * What outcome did you expect instead? I expected the brightness to increase


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

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

Versions of packages openarena depends on:
ii  ioquake3  1.36+u20231123.972635e+dfsg-1
ii  libc6 2.37-13
ii  openarena-081-maps0.8.5split-14
ii  openarena-081-misc0.8.5split-14
ii  openarena-081-players 0.8.5split-14
ii  openarena-081-players-mature  0.8.5split-14
ii  openarena-081-textures0.8.5split-14
ii  openarena-085-data0.8.5split-15
ii  openarena-088-data0.8.8-13
ii  openarena-data0.8.5split-15

Versions of packages openarena recommends:
ii  openarena-oacmp1  3-8

openarena suggests no packages.

Versions of packages ioquake3 depends on:
ii  ioquake3-server  1.36+u20231123.972635e+dfsg-1
ii  libc62.37-13
ii  libcurl3-gnutls  8.5.0-2
ii  libgl1   1.7.0-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libopenal1   1:1.23.1-4
ii  libopus0 1.4-1
ii  libopusfile0 0.12-4
ii  libsdl2-2.0-02.28.5+dfsg-3
ii  libvorbisfile3   1.3.7-1
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages ioquake3 recommends:
ii  kdialog4:22.12.3-1
ii  x11-utils  7.7+6

-- no debconf information

Bug#1061121: di-utils-terminfo: should include xterm-256color terminfo entry

[Sven Joachim]

Package: di-utils-terminfo
Version: 1.148
Control: block 887649 by -1

Please include the xterm-256color in di-utils-terminfo.  AFAICS this is
a prerequisite for fixing #887649, because vte2.91 sets the TERM
environment variable to xterm-256color by default[1,2], while the old
vte package sets TERM=xterm.

In case anyone has unrealistically high hopes: I can send a patch for
the current bug, but do not volunteer to fix #887649.

Cheers,
   Sven


1. https://bugzilla.gnome.org/show_bug.cgi?id=740641
2. 
https://sources.debian.org/src/vte2.91/0.74.2-1/src/vtedefines.hh/?hl=144#L144

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[David Kalnischkies]

Hi,

On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> I am looking for a sponsor for my package "dpkg-buildenv":

Similar to my recent "veto" of apt-verify in #1059267, which was
subsequently ignored and pushed into the archive anyhow, I would
like to call into question the naming of the package/application…

There are various "dpkg-build*" tools already that grabbing 'env' feels
wrong (I would confuse it probably with 'flag' on a bad day), especially
if that isn't at least discussed with dpkg maintainers (I at least see
no mention of it on the list) and given that this is something that
"just" works with Docker.


As explained in the other bug, there is no veto and as you can see its
easy to completely ignore me (and anyone else) but I wanted to say it
anyhow, so that nobody is surprised later on.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1060973: python-pbcore: FTBFS

[Étienne Mollier]

Control: tags -1 + unreproducible moreinfo

Hi Lucas,

I got information from Andreas Tille that the build failure is
not reproducible in his environment.  Actually I did give it a
go myself, and the build went through for me as well.  The build
log is available on the people's server[1].  Actually, looking
closely, I'm not sure why the build works in normal times: the
build environment does not look to embed python3-pip packages in
both cases, so in my case, pip may not be called in the first
place.

[1]: 
https://people.debian.org/~emollier/logs/python-pbcore/python-pbcore_amd64-2024-01-18T18:13:24Z.build.xz

Thanks for your quality assessment work, this is very useful to
catch issues!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-on air: Flying Colors - Peaceful Harbor (Live)


signature.asc
Description: PGP signature

Bug#1061120: rust-ahash-0.7 autopkgtest failure

[Peter Green]

Package: rust-ahash-0.7
Version: 0.7.7-1
Severity: serious

The autopkgtests for rust-ahash-0.7 are failing, this is blocking the
migration of rust-ahash-0.7 to testing which is in turn blocking the
migration of at least one rc bug fix to testing.

There are two issues, the first is that the autopkgtests are trying
to test a "runtime-rng" feature, but no such feature exists. My guess
is that there was some confusion between versions of ahash. I removed
the tests and the corresponding provides.

The second issue is more subtle. The "atomic-polyfill" feature
enables the dependency on the atomic-polyfill crate. However the
dependency on the atomic-polyfill crate is disabled on linux
(among many other targets). Disabling of a dependency on a target
overrides enabling the dependency in a feature. However the code
is not aware of this. The result is that building on Linux with
the atomic-polyfill feature enabled fails.

I see three possible routes for dealing with this.

1. Add target guards to the imports in the code, matching those
   in Cargo.toml
2. Remove the target restrictions from the atomic-polyfill dependency
3. Simply accept that the atomic-polyfill feature is broken on linux
   and stop testing it (this would also mean not having an "all features"
   test.

My patch implements the first option but I don't have a strong
preference for any of them.
diff -Nru rust-ahash-0.7-0.7.7/debian/changelog 
rust-ahash-0.7-0.7.7/debian/changelog
--- rust-ahash-0.7-0.7.7/debian/changelog   2023-12-30 10:22:55.0 
+
+++ rust-ahash-0.7-0.7.7/debian/changelog   2024-01-18 17:11:34.0 
+
@@ -1,3 +1,13 @@
+rust-ahash-0.7 (0.7.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtests
++ Remove provides and autopkgtests for feature runtime-rng which does not
+  exist.
++ Only import atomic-polyfill on platforms where the dependency is enabled
+
+ -- Peter Michael Green   Thu, 18 Jan 2024 17:11:34 +
+
 rust-ahash-0.7 (0.7.7-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-ahash-0.7-0.7.7/debian/control 
rust-ahash-0.7-0.7.7/debian/control
--- rust-ahash-0.7-0.7.7/debian/control 2023-12-30 10:18:50.0 +
+++ rust-ahash-0.7-0.7.7/debian/control 2024-01-18 17:11:27.0 +
@@ -40,7 +40,6 @@
  librust-ahash-0.7+atomic-polyfill-dev (= ${binary:Version}),
  librust-ahash-0.7+compile-time-rng-dev (= ${binary:Version}),
  librust-ahash-0.7+default-dev (= ${binary:Version}),
- librust-ahash-0.7+runtime-rng-dev (= ${binary:Version}),
  librust-ahash-0.7+serde-dev (= ${binary:Version}),
  librust-ahash-0.7+std-dev (= ${binary:Version}),
  librust-ahash-0.7.7-dev (= ${binary:Version}),
diff -Nru rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch 
rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch
--- rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch  
1970-01-01 00:00:00.0 +
+++ rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch  
2024-01-18 17:11:34.0 +
@@ -0,0 +1,23 @@
+Description: limit atomic-polyfill import architectures
+ The atomic-polyfill dependency is target limited, but the import
+ is not. This leads to import errors when building with the
+ atomic-polyfill feature enabled (or building with --all-features).
+
+ This patch makes the imports reflect the dependency
+Author: Peter Michael Green 
+Last-Update: 2024-01-18
+
+--- rust-ahash-0.7-0.7.7.orig/src/random_state.rs
 rust-ahash-0.7-0.7.7/src/random_state.rs
+@@ -29,9 +29,9 @@ extern crate alloc;
+ #[cfg(feature = "std")]
+ extern crate std as alloc;
+ 
+-#[cfg(feature = "atomic-polyfill")]
++#[cfg(all(feature = "atomic-polyfill",not(any(target_os = "linux", target_os 
= "android", target_os = "windows", target_os = "macos", target_os = "ios", 
target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", target_os = 
"dragonfly", target_os = "solaris", target_os = "illumos", target_os = 
"fuchsia", target_os = "redox", target_os = "cloudabi", target_os = "haiku", 
target_os = "vxworks", target_os = "emscripten", target_os = "wasi"]
+ use atomic_polyfill as atomic;
+-#[cfg(not(feature = "atomic-polyfill"))]
++#[cfg(not(all(feature = "atomic-polyfill",not(any(target_os = "linux", 
target_os = "android", target_os = "windows", target_os = "macos", target_os = 
"ios", target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", 
target_os = "dragonfly", target_os = "solaris", target_os = "illumos", 
target_os = "fuchsia", target_os = "redox", target_os = "cloudabi", target_os = 
"haiku", target_os = "vxworks", target_os = "emscripten", target_os = 
"wasi")]
+ use core::sync::atomic;
+ 
+ use alloc::boxed::Box;
diff -Nru rust-ahash-0.7-0.7.7/debian/patches/series 
rust-ahash-0.7-0.7.7/debian/patches/series
--- rust-ahash-0.7-0.7.7/debian/patches/series  2023-12-30 09:53:32.0 
+
+++ rust-ahash-0.7-0.7.7/debian/patches/series  2024-01-18 17:11:34.0 

Bug#1061119: RFP: prometheus-script-exporter -- Prometheus exporter to execute scripts and collect metrics from the output or the exit status

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-go-maintain...@lists.alioth.debian.org

* Package name: prometheus-script-exporter
  Version : 2.17.0
  Upstream Contact: https://github.com/ricoberger
* URL : https://github.com/ricoberger/script_exporter
* License : MIT
  Programming Lang: Golang
  Description : Prometheus exporter to execute scripts and collect metrics 
from the output or the exit status

The script_exporter is a Prometheus exporter to execute scripts and
collect metrics from the output or the exit status. The scripts to be
executed are defined via a configuration file. In the configuration
file several scripts can be specified. The script which should be
executed is indicated by a parameter in the scrap configuration. The
output of the script is captured and is provided for Prometheus. Even
if the script does not produce any output, the exit status and the
duration of the execution are provided.



I often use the node exporter textfile collector to do this kind of
thing:

exporter | sponge /var/lib/prometheus/node_exporter/exporter.prom

... but i often have issues where i don't quite know *when* to run the
script. It would be nice to run the script when prometheus scrapes...

I don't have time to package this right now.

Bug#1061118: debram: The debram binary is missing from the package.

[John Pace]

Package: debram
Version: 2.3.0
Severity: important
X-Debbugs-Cc: gostr...@gmail.com

Dear Maintainer,

It appears that the binary for the debram package was omitted when the package
was built. I haven't pulled and built the source package yet, but regardless
of that fact, the official debian packages are missing the binary.

*** 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: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages debram depends on:
ii  debram-data  2.3.0

debram recommends no packages.

Versions of packages debram suggests:
ii  debtags  2.1.5

-- no debconf information

Bug#1060326: reverse dependencies

[Thorsten Alteholz]

On 17.01.24 23:52, IOhannes m zmölnig (Debian/GNU) wrote:


what is required from my side?
do i need to contact the maintainers of these packages to coordinate?


someone needs to file the RM-bugs (please one bug for each package). It 
would be best if the maintainer is involved in this or at least knows 
about it.


  Thorsten

Bug#1061102: librust-tikv-jemallocator-dev: fails to compile provided code

[Jonas Smedegaard]

Control: reassign -1 librust-tikv-jemalloc-sys-dev 
Control: retitle -1 librust-tikv-jemalloc-sys-dev: fails to compile without 
xsltproc

Quoting Jonas Smedegaard (2024-01-18 12:32:26)
> Attempts at building Rust project biome (bug#1051238) fails during build
> of the tikv-jemallocator crate

Build succeeds when adding a build-dependency on xsltproc.

This seems most appropriately declared at librust-tikv-jemalloc-sys-dev
- reassigning accordingly.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1061114: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Andreas,

there is a reverse dependency that needs to be taken care of:


Checking reverse dependencies...
# Broken Depends:
qcumber: qcumber


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1061113: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Alexandre,

there is a reverse dependency that needs to be taken care of:

Checking reverse dependencies...
# Broken Build-Depends:
commando: python3-fswrap

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1060453: reverse dependencie

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Anton,

there are reverse dependencies that need to be taken care of:


Checking reverse dependencies...
# Broken Depends:
ceph: ceph-common
  ceph-mgr
  ceph-mon
  ceph-osd
  librados-dev
  librados2
  librgw2
  radosgw
dogecoin: dogecoin
graph-tool: python3-graph-tool [ppc64el]
i2pd: i2pd [armel]
lomiri-thumbnailer: lomiri-thumbnailer-service [riscv64]
openems: libnf2ff0 [amd64 arm64 i386 mips64el ppc64el riscv64 s390x]
 libopenems0 [amd64 arm64 i386 mips64el ppc64el riscv64 s390x]
slic3r: slic3r [i386]
slic3r-prusa: prusa-slicer [s390x]
srslte: srsenb [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
srsepc [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
srsue [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
swift-im: libswiften-dev
  libswiften0
vg: vg [amd64 mips64el]
vowpal-wabbit: libvw0 [amd64 i386]
xrt: libxrt-utils [amd64]
 libxrt1 [amd64 arm64]

# Broken Build-Depends:
brewtarget: libboost1.74-dev
dmrgpp: libboost1.74-dev


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1058645: Do you need help with this package?

[Martin Quinson]

Hello,

I'm wondering whether you need some help with the packaging of Hare. Is your
current state available somewhere?

Thanks,
Mt


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

Bug#1061117: linux-image-6.1.0-17-arm64: please enable support for lx2160a serdes runtime configuration

[Josua Mayer]

Package: src:linux
Version: 6.1.69-1
Severity: important
X-Debbugs-Cc: jo...@solid-run.com

Dear Maintainer,

Please enable support for lx2160a serdes configuration driver in arm64 flavour:
CONFIG_PHY_FSL_LYNX_28G

This driver is essential for supporting the SFP+ connectors on
SolidRun Honeycomb Workstation. Since mainline added references
to SerDes via "phys" properties in v5.18, Debian can not probe
the netdev's, breaking all 10Gbps NICs.

Ideally this will be enabled for current stable release, too.

Sincerely
Josua Mayer

-- Package-specific info:
** Version:
Linux version 6.1.0-17-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 
6.1.69-1 (2023-12-30)

** Command line:
 arm-smmu.disable-bypass=0 console=ttyAMA0,38400n8 quiet

** Not tainted

** Kernel log:
[4.330447] alg: No test for authenc(hmac(md5),cbc(aes)) 
(authenc-hmac-md5-cbc-aes-caam-qi2)
[4.330532] alg: No test for echainiv(authenc(hmac(md5),cbc(aes))) 
(echainiv-authenc-hmac-md5-cbc-aes-caam-qi2)
[4.334627] audit: type=1400 audit(1705595241.215:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=525 
comm="apparmor_parser"
[4.335982] audit: type=1400 audit(1705595241.215:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=526 
comm="apparmor_parser"
[4.335991] audit: type=1400 audit(1705595241.215:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=526 comm="apparmor_parser"
[4.336012] alg: No test for echainiv(authenc(hmac(sha1),cbc(aes))) 
(echainiv-authenc-hmac-sha1-cbc-aes-caam-qi2)
[4.336100] alg: No test for authenc(hmac(sha224),cbc(aes)) 
(authenc-hmac-sha224-cbc-aes-caam-qi2)
[4.336178] alg: No test for echainiv(authenc(hmac(sha224),cbc(aes))) 
(echainiv-authenc-hmac-sha224-cbc-aes-caam-qi2)
[4.339390] alg: No test for echainiv(authenc(hmac(sha256),cbc(aes))) 
(echainiv-authenc-hmac-sha256-cbc-aes-caam-qi2)
[4.339495] alg: No test for authenc(hmac(sha384),cbc(aes)) 
(authenc-hmac-sha384-cbc-aes-caam-qi2)
[4.339619] alg: No test for echainiv(authenc(hmac(sha384),cbc(aes))) 
(echainiv-authenc-hmac-sha384-cbc-aes-caam-qi2)
[4.340663] audit: type=1400 audit(1705595241.219:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=528 
comm="apparmor_parser"
[4.340674] audit: type=1400 audit(1705595241.219:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=528 
comm="apparmor_parser"
[4.340680] audit: type=1400 audit(1705595241.219:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=528 
comm="apparmor_parser"
[4.342833] alg: No test for echainiv(authenc(hmac(sha512),cbc(aes))) 
(echainiv-authenc-hmac-sha512-cbc-aes-caam-qi2)
[4.342951] alg: No test for authenc(hmac(md5),cbc(des3_ede)) 
(authenc-hmac-md5-cbc-des3_ede-caam-qi2)
[4.343067] alg: No test for echainiv(authenc(hmac(md5),cbc(des3_ede))) 
(echainiv-authenc-hmac-md5-cbc-des3_ede-caam-qi2)
[4.343743] alg: No test for echainiv(authenc(hmac(sha1),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha1-cbc-des3_ede-caam-qi2)
[4.344850] alg: No test for echainiv(authenc(hmac(sha224),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha224-cbc-des3_ede-caam-qi2)
[4.345868] alg: No test for echainiv(authenc(hmac(sha256),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha256-cbc-des3_ede-caam-qi2)
[4.346863] alg: No test for echainiv(authenc(hmac(sha384),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha384-cbc-des3_ede-caam-qi2)
[4.347587] alg: No test for echainiv(authenc(hmac(sha512),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha512-cbc-des3_ede-caam-qi2)
[4.347693] alg: No test for authenc(hmac(md5),cbc(des)) 
(authenc-hmac-md5-cbc-des-caam-qi2)
[4.347810] alg: No test for echainiv(authenc(hmac(md5),cbc(des))) 
(echainiv-authenc-hmac-md5-cbc-des-caam-qi2)
[4.348851] alg: No test for echainiv(authenc(hmac(sha1),cbc(des))) 
(echainiv-authenc-hmac-sha1-cbc-des-caam-qi2)
[4.349882] alg: No test for echainiv(authenc(hmac(sha224),cbc(des))) 
(echainiv-authenc-hmac-sha224-cbc-des-caam-qi2)
[4.350874] alg: No test for echainiv(authenc(hmac(sha256),cbc(des))) 
(echainiv-authenc-hmac-sha256-cbc-des-caam-qi2)
[4.351895] alg: No test for echainiv(authenc(hmac(sha384),cbc(des))) 
(echainiv-authenc-hmac-sha384-cbc-des-caam-qi2)
[4.352897] alg: No test for echainiv(authenc(hmac(sha512),cbc(des))) 
(echainiv-authenc-hmac-sha512-cbc-des-caam-qi2)
[4.353008] alg: No test for authenc(hmac(md5),rfc3686(ctr(aes))) 
(authenc-hmac-md5-rfc3686-ctr-aes-caam-qi2)
[4.353112] alg: No test for seqiv(authenc(hmac(md5),rfc3686(ctr(aes 
(seqiv-authenc-hmac-md5-rfc3686-ctr-aes-caam-qi2)
[4.353323] alg: No test for seqiv(authenc(hmac(sha1),rfc3686(ctr(aes 

Bug#1061116: linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon

[Josua Mayer]

Package: src:linux
Version: 6.1.69-1
Severity: normal
X-Debbugs-Cc: jo...@solid-run.com

Dear Maintainer,

Please enable "PCIE_LAYERSCAPE_GEN4" for arm64 flavour,
in addition to already enabled "PCIE_LAYERSCAPE".

LX2160 SoC early silicon revisions have a pci-e generation 4 controller.
It requires a different driver from newer gen-3 silicon.

This affects the SolidRun Honeycomb Workstation which
is otherwise fully supported in Debian.
Ideally the config option wll be enabled for debian stable, too.

-- Package-specific info:
** Version:
Linux version 6.1.0-17-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 
6.1.69-1 (2023-12-30)

** Command line:
 arm-smmu.disable-bypass=0 console=ttyAMA0,38400n8 quiet

** Not tainted

** Kernel log:
[4.330447] alg: No test for authenc(hmac(md5),cbc(aes)) 
(authenc-hmac-md5-cbc-aes-caam-qi2)
[4.330532] alg: No test for echainiv(authenc(hmac(md5),cbc(aes))) 
(echainiv-authenc-hmac-md5-cbc-aes-caam-qi2)
[4.334627] audit: type=1400 audit(1705595241.215:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=525 
comm="apparmor_parser"
[4.335982] audit: type=1400 audit(1705595241.215:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=526 
comm="apparmor_parser"
[4.335991] audit: type=1400 audit(1705595241.215:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=526 comm="apparmor_parser"
[4.336012] alg: No test for echainiv(authenc(hmac(sha1),cbc(aes))) 
(echainiv-authenc-hmac-sha1-cbc-aes-caam-qi2)
[4.336100] alg: No test for authenc(hmac(sha224),cbc(aes)) 
(authenc-hmac-sha224-cbc-aes-caam-qi2)
[4.336178] alg: No test for echainiv(authenc(hmac(sha224),cbc(aes))) 
(echainiv-authenc-hmac-sha224-cbc-aes-caam-qi2)
[4.339390] alg: No test for echainiv(authenc(hmac(sha256),cbc(aes))) 
(echainiv-authenc-hmac-sha256-cbc-aes-caam-qi2)
[4.339495] alg: No test for authenc(hmac(sha384),cbc(aes)) 
(authenc-hmac-sha384-cbc-aes-caam-qi2)
[4.339619] alg: No test for echainiv(authenc(hmac(sha384),cbc(aes))) 
(echainiv-authenc-hmac-sha384-cbc-aes-caam-qi2)
[4.340663] audit: type=1400 audit(1705595241.219:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=528 
comm="apparmor_parser"
[4.340674] audit: type=1400 audit(1705595241.219:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=528 
comm="apparmor_parser"
[4.340680] audit: type=1400 audit(1705595241.219:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=528 
comm="apparmor_parser"
[4.342833] alg: No test for echainiv(authenc(hmac(sha512),cbc(aes))) 
(echainiv-authenc-hmac-sha512-cbc-aes-caam-qi2)
[4.342951] alg: No test for authenc(hmac(md5),cbc(des3_ede)) 
(authenc-hmac-md5-cbc-des3_ede-caam-qi2)
[4.343067] alg: No test for echainiv(authenc(hmac(md5),cbc(des3_ede))) 
(echainiv-authenc-hmac-md5-cbc-des3_ede-caam-qi2)
[4.343743] alg: No test for echainiv(authenc(hmac(sha1),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha1-cbc-des3_ede-caam-qi2)
[4.344850] alg: No test for echainiv(authenc(hmac(sha224),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha224-cbc-des3_ede-caam-qi2)
[4.345868] alg: No test for echainiv(authenc(hmac(sha256),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha256-cbc-des3_ede-caam-qi2)
[4.346863] alg: No test for echainiv(authenc(hmac(sha384),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha384-cbc-des3_ede-caam-qi2)
[4.347587] alg: No test for echainiv(authenc(hmac(sha512),cbc(des3_ede))) 
(echainiv-authenc-hmac-sha512-cbc-des3_ede-caam-qi2)
[4.347693] alg: No test for authenc(hmac(md5),cbc(des)) 
(authenc-hmac-md5-cbc-des-caam-qi2)
[4.347810] alg: No test for echainiv(authenc(hmac(md5),cbc(des))) 
(echainiv-authenc-hmac-md5-cbc-des-caam-qi2)
[4.348851] alg: No test for echainiv(authenc(hmac(sha1),cbc(des))) 
(echainiv-authenc-hmac-sha1-cbc-des-caam-qi2)
[4.349882] alg: No test for echainiv(authenc(hmac(sha224),cbc(des))) 
(echainiv-authenc-hmac-sha224-cbc-des-caam-qi2)
[4.350874] alg: No test for echainiv(authenc(hmac(sha256),cbc(des))) 
(echainiv-authenc-hmac-sha256-cbc-des-caam-qi2)
[4.351895] alg: No test for echainiv(authenc(hmac(sha384),cbc(des))) 
(echainiv-authenc-hmac-sha384-cbc-des-caam-qi2)
[4.352897] alg: No test for echainiv(authenc(hmac(sha512),cbc(des))) 
(echainiv-authenc-hmac-sha512-cbc-des-caam-qi2)
[4.353008] alg: No test for authenc(hmac(md5),rfc3686(ctr(aes))) 
(authenc-hmac-md5-rfc3686-ctr-aes-caam-qi2)
[4.353112] alg: No test for seqiv(authenc(hmac(md5),rfc3686(ctr(aes 
(seqiv-authenc-hmac-md5-rfc3686-ctr-aes-caam-qi2)
[4.353323] alg: No test for seqiv(authenc(hmac(sha1),rfc3686(ctr(aes 
(seqiv-authenc-hmac-sha1-rfc3686-ctr-aes-caam-qi2)
[4.353425] alg: 

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[lortas]

On Thu 2024-01-18 17:17, Alexandru Mihail wrote:
>Can you replicate the problem by running apt purge mini-httpd && apt >install 
>mini-httpd ? (docker)

# docker run -ti --rm debian:testing-slim bash -c "apt-get update && apt-get 
purge mini-httpd && apt-get install -y mini-httpd
[...]
Package 'mini-httpd' is not installed, so not removed
[...]
Setting up mini-httpd (1.30-6) ...
cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file 
or directory
dpkg: error processing package mini-httpd (--configure):
 installed mini-httpd package post-installation script subprocess returned 
error exit status 1
Setting up libgdbm6:amd64 (1.23-5) ...
Setting up libaprutil1:amd64 (1.6.3-1+b1) ...
Setting up apache2-utils (2.4.58-1+b1) ...
Processing triggers for libc-bin (2.37-13) ...
Errors were encountered while processing:
 mini-httpd
E: Sub-process /usr/bin/dpkg returned an error code (1)


>Can you replicate in a non-docker environment (testing or sid) if you have 
>access to one ?

no, but I can use another base image

# docker run -ti --rm debian:testing bash -c "apt-get update && apt-get install 
-y mini-httpd"

this works. The error seems only to happen on debian:testing-slim but not on 
debian:testing

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[lortas]

On Thu 2024-01-18 17:17, Alexandru Mihail wrote:
>Hello, I cannot replicate the failing cp on 2 Debian virtual machines, one 
>tracking testing and one sid. I don't have much experience with docker, I will 
>try your command in the sid VM. Docker fails to run hello world on my personal 
>Ubuntu machine for some odd reason.

This works:
# docker run -ti --rm debian:testing-slim bash -c "mkdir -p 
/usr/share/doc/mini-httpd/examples && touch 
/usr/share/doc/mini-httpd/examples/index.html && apt-get update && apt-get 
install -y mini-httpd"

This fails:
# docker run -ti --rm debian:testing-slim bash -c "apt-get update && apt-get 
install -y mini-httpd"

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Andrey Rakhmatullin]

I see you added this tool to the list of similar tools on the wiki so you
at least know about that list. So how is your tool better than other tools
on that list, or at least than the ones packaged in Debian? 
Please also note that if you followed the procedure outlined at
https://mentors.debian.net/intro-maintainers/ and filed an ITP bug before
doing the packaging this discussion would happen there, not on the RFS
bug.

Bug#988477: Also observing #988477

[Elliott Mitchell]

tags 988477 - moreinfo
found 988477 4.17.2+76-ge1f9cb16e2-1~deb12u1
affects 988477 src:linux
severity 988477 critical
quit

I am also observing #988477 occur.  This machine has a AMD Zen 4
processor.  The first observation was when motherboard/processor was
swapped out, the older motherboard/processor was several generations old.

The pattern which is emerging is Linux MD RAID1 plus recent AMD processor
which has full IOMMU functionality.  The older machine was believed to
have an IOMMU, but the BIOS wasn't creating appropriate ACPI tables
(IVRS) and thus Xen was unable to utilize it.

This seems to be occuring with a small percentage of write operations.
Subsequent read operations appear to be fine.

I am not convinced this is a Xen bug.  I suspect this is instead a bug
in the Linux MD subsystem.  In particular if the DMA interface was
designed assuming only a single device would ever access any page, but
the MD RAID1 driver is reusing the same page for both devices.

IOMMU page release could be handled by marking the page unused in a
device data structure and later removed by sweeping a table.  In such
case if the MD-RAID1 driver was to redirect the page to another device
between these two steps, the entry for a subsequent device could be wiped
out when trying to invalidate an entry for a prior device.


Anyway, I'm also observing bug #988477.  This could also be a kernel bug.
So far no crashes/confirmed data loss have occured, but sweeping the
mirror does turn up small numbers of inconsistencies.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1061115: ksh93u+m: please configure a static CHILD_MAX value at build-time

[James Addison]

Source: ksh93u+m
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness

Dear Maintainer,

I'm an occasional volunteer with the Reproducible Builds[1] project, and
noticed recently that the ksh93u+m Debian package failed build reproducibility
testing[2] on amd64.

The autoconfiguration script[3] probes the build host for the user process
limit CHILD_MAX[4] - and the resulting value is compiled-into the /bin/ksh93
binary.  This means that the binary package varies (is non-reproducible) on
build hosts that have different process limits configured.


Some additional notes / context to help figuring out a suitable value:

  * The CHILD_MAX setting is a limit to the number of (sub)processes that a
user is allowed to run simultaneously.

  * The compiled-in ksh93 CHILD_MAX value is only read if the _runtime_ system
getconf call[5] returns a zero/negative value (unlimited?).

  * A zero or negative CHILD_MAX value seems unacceptable because it could
result in an inifinite loop[6] in the jobs.c code.

  * The default value[7] of 1024 was introduced in the AT source
some time between Y2007 and Y2011 - it may still be an acceptable value.

  * At the time of writing, the most recent Debian amd64 binary package for
source version ksh93u+m/1.0.7-1 has a compiled-in CHILD_MAX of 31626.

Regards,
James

[1] - https://www.reproducible-builds.org

[2] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/ksh93u+m.html

[3] - 
https://sources.debian.org/src/ksh93u%2Bm/1.0.7-1/src/lib/libast/comp/conf.sh/

[4] - 
https://sources.debian.org/src/ksh93u%2Bm/1.0.7-1/src/lib/libast/comp/conf.tab/#L67
  Note: this file's header explains each character in the line's "CDLMUX".

[5] - 
https://sources.debian.org/src/ksh93u%2Bm/1.0.7-1/src/cmd/ksh93/sh/init.c/#L1274

[6] - 
https://sources.debian.org/src/ksh93u%2Bm/1.0.7-1/src/cmd/ksh93/sh/jobs.c/#L1832-L1833

[7] - 
https://sources.debian.org/src/ksh93u%2Bm/1.0.7-1/src/cmd/ksh93/sh/init.c/#L153-L155

Bug#1061114: RM: r-bioc-savr -- ROM; Orphaned upstream, removed by Bioconductor

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: r-bioc-s...@packages.debian.org, 1060...@bugs.debian.org, 
debia...@lists.debian.org
Control: affects -1 + src:r-bioc-savr

Hi,

r-bioc-savr is removed from Bioconductor[1] probably due to no response
to Github issues about failures[2] since more than one year.  So it does
not make any sense to support this package in Debian any more.

Please remove the package from the Debian archive.

Kind regards and thank you for your work as ftpmaster
 Andreas.


[1] https://bioconductor.org/about/removed-packages/
[2] https://github.com/bcalder/savR/issues/12

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[Alexandru Mihail]

Hello, I cannot replicate the failing cp on 2 Debian virtual machines,
one tracking testing and one sid. I don't have much experience with
docker, I will try your command in the sid VM. Docker fails to run
hello world on my personal Ubuntu machine for some odd reason.

On Wed, 2024-01-17 at 10:51 +, lortas wrote:

> Package: mini-httpd
> Version: 1.30-6
> Severity: important
> 
> Dear Maintainer,
> 
> 
> # docker run -ti --rm debian:testing-slim bash -c "apt-get update &&
> apt-get install -y mini-httpd"
> [...]
> Setting up libexpat1:amd64 (2.5.0-2+b2) ...
> Setting up libssl3:amd64 (3.1.4-2) ...
> Setting up libapr1:amd64 (1.7.2-3+b2) ...
> Setting up mini-httpd (1.30-6) ...
> cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No
> such file or directory
> dpkg: error processing package mini-httpd (--configure):
>  installed mini-httpd package post-installation script subprocess
> returned error exit status 1
> Setting up libgdbm6:amd64 (1.23-5) ...
> Setting up libaprutil1:amd64 (1.6.3-1+b1) ...
> Setting up apache2-utils (2.4.58-1+b1) ...
> Processing triggers for libc-bin (2.37-13) ...
> Errors were encountered while processing:
>  mini-httpd
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 

Can you replicate the problem by running apt purge mini-httpd && apt
install mini-httpd ? (docker)
Can you replicate in a non-docker environment (testing or sid) if you
have access to one ?

Regards,
Alexandru Mihail
mini-httpd maintainer



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

Bug#1061113: RM: python-fswrap -- ROM dead upstream, lowpopcon, RC buggy, orphaned

[Alexandre Detiste]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-fsw...@packages.debian.org, Yogeswaran Umasankar

Control: affects -1 + src:python-fswrap

Hi Yogeswaran,

I greatly appreciate your recent work,
but I don't think you or I or anybody
should waste more time on this package.

Thus I ask it's removal.

Greetings,

Alexandre


- dead upstream since 2014
  https://github.com/hyde/fswrap

- low popcon
  https://qa.debian.org/popcon.php?package=python-fswrap

- no user left in Debian
   (I cannot check build-dependencies here but I'm confident...)
$ apt rdepends python3-fswrap
python3-fswrap
Reverse Depends:

- only exists in Debian & derivatives:
 https://repology.org/project/python:fswrap/packages


Greetings,



> Could you please provide me feedback for 'python-fswrap',
> and consider sponsoring it?

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

> Control: retitle 928542 ITA: python-fswrap -- unified object oriented 
> interface to file system objects
> Owner: Yogeswaran Umasankar 
> Hi,
> I would like to adopt this package, and maintain it under Debian Python Team.
> Cheers!

Bug#1061112: src:rust-cargo-auditable: unsatisfied build dependency in testing: librust-object-0.31+write-dev

[Paul Gevers]

Source: rust-cargo-auditable
Version: 0.6.1-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency (or actually, the right version if I understand the 
rust ecosystem well enough). Obviously your build dependencies shouldn't 
be removed from testing, but unfortunately there are multiple scenarios

where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? I note that this package already has a newer version in unstable, 
but that fails to migrate to testing because it's coupled to another 
Build-Depends that isn't ready to migrate. Regularly, if the build 
dependency is available in unstable, helping the maintainer of your 
Build-Depends to enable migration to testing is a great way to solve the 
issue. If your build dependency is gone from unstable and testing, 
you'll have to fix the build process in some other way.


Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059503: RFS: blanket/0.6.0-1 [RFP] -- listen to relaxing sounds

[Danial Behzadi]

Thanks for your recommendations.
There is new upload in mentors and the salsa is updated too:

* Package name : blanket
  Version  : 0.6.0+dfsg-1
  Upstream contact : Rafael Mardojai CM 
* URL  : 
* License  : Public-Domain, CC-BY-1.0, CC-BY-4.0, GPL-3+, 
CC-BY-SA-3.0, CC0-1.0, CC-BY-3.0

* Vcs  : 
  Section  : utils

The source builds the following binary packages:

 blanket - Listen to relaxing sounds

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


 

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


 dget -x 



Changes for the initial release:

blanket (0.6.0+dfsg-1) unstable; urgency=medium
.
  * Initial packaging. (Closes: #1053209)

Regards,
--
 Danial Behzadi

در سه‌شنبه, ژانویه 2 2024 at ۱۴:۱۵:۵۹ -05:00:00, 
Jeremy Bícha  نوشته بود:

Thank you very much for working on this package. Here are some
recommended improvements:

According to the links in SOUNDS_LICENSING.md :

1. city is CC-BY-3.0

2. white noise is CC-BY-3.0

3. pink noise links to the Spanish wikipedia page. But here's the
English version:

which says that the file is licensed as CC-BY-3.0 or
GFDL-1.2-no-invariants-or-later
It technically also allows the option of earlier CC-BY licenses but I
think we may be able to ignore that in our debian/copyright

4. debian/copyright is easier to review if the files are in 
alphabetical order.


5. Also, you can use the one line license name for the files and then
only include the longer license text once in a separate paragraph to
reduce the length of debian/copyright and improve its readability.
This is mentioned in
 
and

there are many examples in existing Debian packages.

6. data/com.rafaelmardojai.Blanket.metainfo.xml* is licensed CC-BY-1.0

7. blanket/mpris.py has several copyright holders that should be
mentioned in debian/copyright

8. I believe you need to add python3-gi to the Depends list so that
Python gobject-introspection works.

9. I suggest adding this to the end of the package description:

 .
 Blanket is a GNOME Circle app.

Thank you,
Jeremy Bícha

Bug#1060897: standalone is permitted, when the local web server is in use

[Georges Khaznadar]

On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog  wrote:
> [...] reported here and that you can see here:
> https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html

when I browse this URL with the debugger's console active, I see that:

The resource from 
“https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was 
blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: 
nosniff).

Probably, it the webserver is configured to serve normalize.css as MIME
type "text/css", the issue might be fixed.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1036968: included in 6.6.9-1

[Hans-Christoph Steiner]

For the record, the module was included starting in 6.6.9-1:

$ grep -i CS35L41 /boot/config-6.6.9-amd64
CONFIG_SND_HDA_SCODEC_CS35L41=m
CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_LIB=m
CONFIG_SND_SOC_CS35L41=m
CONFIG_SND_SOC_CS35L41_SPI=m
CONFIG_SND_SOC_CS35L41_I2C=m

Bug#1036968: fixed

[Hans-Christoph Steiner]

Control: fixed 1036968 6.6.9-1
Control: fixed 1036968 6.6.11-1

With 6.6.11-1, the headphone jack insert detection is now working when running 
on bookworm.

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Aidan]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dpkg-buildenv":

 * Package name : dpkg-buildenv
   Version  : 1.0.0
   Upstream contact : Aidan Gallagher (aidg...@gmail.com)
 * URL  : https://github.com/aidan-gallagher/dpkg-buildenv
 * License  : LGPL-2.0+
 * Vcs  : https://github.com/aidan-gallagher/dpkg-buildenv.git
   Section  : misc

The source builds the following binary packages:

  dpkg-buildenv - Builds debian packages in a docker container.

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

  https://mentors.debian.net/package/dpkg-buildenv/

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dpkg-buildenv/dpkg-buildenv_1.0.0.dsc

Changes for the initial release:

 dpkg-buildenv (1.0.0) unstable; urgency=low
 .
   * Initial Release.

Kind Regards,
Aidan

Bug#956479: Document upstream replacement

[Kyle Robbertze]

control: retitle -1 ITP: ocaml-posix -- OCaml bindings to the various POSIX APIs

Upstream has replaced this library with the ocaml-posix library

URL: https://github.com/savonet/ocaml-posix

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1061079: RFS pidgin-skype

[Patrick ZAJDA]

Hello,

I fixed some lintian info and migrated debug symbols to new standard, 
they are now in pidgin-skybe-common-dbgsym instead of pidgin-skype-dbg


Best regards,
--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061110: xorg-server: Regression from fixes for CVE-2024-21886

[Salvatore Bonaccorso]

Source: xorg-server
Version: 2:21.1.11-1
Severity: important
Tags: upstream
X-Debbugs-Cc: car...@debian.org, jcris...@debian.org, a...@debian.org, 
t...@security.debian.org

While preparing the update for xorg-server for bookworm an autopkgtest
regression in uqm was seen. The same is shown with the 2:21.1.11-1
upload to unstable:

https://ci.debian.net/packages/u/uqm/testing/amd64/41866714/

Julien Cristau was able to reproduce the leak independly from uqm:

Xvfb :10 & sleep 2; DISPLAY=:10 xdpyinfo >/dev/null

resulting in

1 XSELINUXs still allocated at reset
SCREEN: 0 objects of 304 bytes = 0 total bytes 0 private allocs
DEVICE: 0 objects of 88 bytes = 0 total bytes 0 private allocs
CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 0 objects of 16 bytes = 0 total bytes 0 private allocs
GC: 0 objects of 16 bytes = 0 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSORs still allocated at reset
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSOR_BITSs still allocated at reset
TOTAL: 0 objects, 0 bytes, 0 allocs

As per upstream commit bisection it seems that the first bad commit is
https://gitlab.freedesktop.org/xorg/xserver/-/commit/26769aa71fcbe0a8403b7fb13b7c9010cc07c3a8
which is related for the CVE-2024-21886 fix.

Regards,
Salvatore

Bug#1035397: Consider maintainership transfer to d-i-d team

[Gürkan Myczko]

Hi Mario

systemctl susped refuses to work when the suspend.target is linked to 
/dev/null


Unfortunately I can't review the quirkdb files if they are still right 
or not.
But from the age they probably are irrelevant when they have not been 
removed since

13 years, counting.

Best,
Alex

Bug#1061109: prosody-modules: enable modules mod_cloud_notify_extensions (_i.e._ mod_cloud_notify_encrypted, mod_cloud_notify_priority_tag and mod_cloud_notify_filters)

[Luca Capello]

Package: prosody-modules
Version: 0.0~hg20230223.556bf57d6417+dfsg-1~bpo11+1
Severity: wishlist
Usertags: pca-communication

Hi there,

to fully support "XEP-0357: Push Notifications", `mod_cloud_notify`
(cf. ) is not enough, as explained in
its README:

  

Manually downloading in `/usr/local/lib/prosody/modules/` the 4 Lua
files below...

  `mod_cloud_notify_extensions`
  `mod_cloud_notify_encrypted`
  `mod_cloud_notify_priority_tag`
  `mod_cloud_notify_filters`

...and activating `mod_cloud_notify_extensions` was enough to get "push
notifications" in Siskin:

  

NB, I have been testing this on a production system (and different
iPhones) since 2023-08-05!

Thx, bye,
Gismo / Luca

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

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

Versions of packages prosody-modules depends on:
ii  prosody  0.12.3-1~bpo11+1

Versions of packages prosody-modules recommends:
pn  lua-ldap  

prosody-modules suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1061108: llvmlite: FTBFS depends on llvm-14

[zhangdandan]

Source: llvmlite
Version: 0.41.1-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

When I compiled llvmlite 0.41.1-1 which depends llvm-14, and the code is 
forced to depend on llvm-14.
The pool-loong64 repository in Debian-ports only has llvm-toolchain-16 
and llvm-toolchain-17.


I download llvmlite 0.39.1, and modify the the llvm version in 
d/control, d/rules.

Build llvmlite 0.39.1 with llvm-13 (form my local repository).
The result is that the llvm version that llvmlite 0.39.1 depends on is 
modified to llvm-13 and the compilation is normal.


But llvmlite 0.41.1-1 is forced to depend on llvm-14.
Could the llvmlite source code be considered compatible with newer llvm 
versions, such as llvm-16 or the lastest llvm version?


thanks,
Dandan Zhang

Bug#1058122: python-griddataformats: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Drew Parsons]

Source: python-griddataformats
Followup-For: Bug #1058122

THanks for the patch, Yogeswaran.

Upstream has fixed it in their latest release however.

Bug#1061105: [DKIM] Bug#1061105: netcdf-bin nccopy compression error in bookworm

[Andre Castro Gonçalves de Oliveira de Castro]

Hi Bas,
It might be an issue with the dataset, but I see this error consistent 
across  the netCDFs that we are creating in my research center, when 
using netcdf-bin on bookworm. And I do not see any issue with the netCDF 
itself. Whihc makes me suspect that the issue might be with the version 
on netcdf-bin in bookworm


Cheers,
Andre

On 1/18/24 13:49, Sebastiaan Couwenberg wrote:
> Control: tags -1 upstream moreinfo
>
> On 1/18/24 12:55, Andre Castro Gonçalves de Oliveira de Castro wrote:
>> When I attempt to compress a NetCDF file with nccopy in Bookworm, an HDF 
>> error is returned and an empty NetCDF is produced
>> If the same command + file are invoked by netcdf-bin:1:4.7.4-1 (Bullseye), 
>> the compression is successful and the compressed NetCDF includes all the 
>> data.
>>
>> Example: (.nc file in attachment)
>>
>> nccopy -d9 20240117_KNMI_Cabauw-CABAUW_PAR001.nc 
>> 20240117_KNMI_Cabauw-CABAUW_PAR001.comp.nc
>>
>> output:
>>
>> NetCDF: HDF error
>> Location: file ; line 1617
>>
>> I am using a RaspberryPi4  Debian GNU/Linux 12 (bookworm), kernel 
>> 6.1.0-rpi4-rpi-v8,
> Might be an issue with the dataset.
>
> netcdf-bin (1:4.9.2-3) on unstable:
>
>$ nccopy -d9 20240117_KNMI_Cabauw-CABAUW_PAR001.nc
> 20240117_KNMI_Cabauw-CABAUW_PAR001.comp.nc
>NetCDF: Filter error: bad id or parameters or duplicate filter
>Location: file ?; fcn ? line 1152
>
> Kind Regards,
>
> Bas
>

Bug#1060897: standalone is permitted, when the local web server is in use

[Raphael Hertzog]

Hi Georges,

On Thu, 18 Jan 2024, Georges Khaznadar wrote:
> Would you like to enable documents generated with furo to be usable even
> when accessed under a file:// scheme?

Yes, but I'd also like them to work when hosted on a random non-Debian 
webserver.
My use case is documentation generated out of git and hosted on Gitlab
pages.

This is how I manage https://freexian-team.pages.debian.net/debusine/ and
it works well, but when I tried to move that to furo I encountered the
issues that I reported here and that you can see here:
https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html

> (1) I made an ITP for furo and packaged it for Debian, primarily because
> I am maintaining the package sympy, and that once upon a time, it began
> build-depending on furo.

I assumed it was needed as a dependency and not your primary interest,
thanks for packaging it anyway! It's actually a nice theme.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#903553: secure-delete: srm -r: fails to rename dir before truncating it.

[Georges Khaznadar]

Hello Manolo,

I am the new maintainer of the package secure-delete for a few months,
and this bu report is more than 3 years old.

Please can you tell me what srm prints when called with the -v switch?
(verbose mode).

By the way, can you also provide me a tarball of a minimal filesystem
which would trigger the bug you reported?

Thank you in advance.

Best regards,   Georges.

On Wed, 11 Jul 2018 12:00:18 +0200 =?utf-8?q?Manolo_D=C3=ADaz?= 
 wrote:
> Package: secure-delete
> Version: 3.1-6
> Severity: normal
> 
> 
> Dear Maintainer,
> 
> After running 'srm -r directory' the following warning is shown:
>   Warning: Couldn't find a free filename for directory!
> 
> Tested with ext4 and tmpfs filesystems only.
> 
> Best Regards,
> Manolo Díaz   
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.17.5 (SMP w/2 CPU cores)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
> LANGUAGE=es_ES.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages secure-delete depends on:
> ii  libc6  2.27-3
> 
> secure-delete recommends no packages.
> 
> secure-delete suggests no packages.
> 
> -- no debconf information

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1061107: vapigen: Make it possible to cross-compile libraries with Vala bindings

[Simon McVittie]

Package: valac
Version: 0.56.14-1
Severity: wishlist
X-Debbugs-Cc: debian-cr...@lists.debian.org

Now that we can cross-compile GObject-Introspection data, many GNOME
packages that could not not previously be cross-compiled become available
for cross-compiling. However, some of the libraries we would like to be
able to cross-compile (for example ibus and libportal) have Vala bindings,
generated from the library's own GIR XML via the vapigen tool.

At the moment, during a cross-build, vapigen will generally be a
host-architecture binary which cannot always be run on the build
architecture, causing builds to fail.

Ideally, during a cross-build, we would like to run a build-architecture
vapigen binary, but configure it (perhaps via command-line options or
environment variables) so that it will find host-architecture GIR XML
in /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0. The search paths need to
be architecture-specific in order to find GLib-2.0.gir without having
libgirepository1.0-dev installed, because libgirepository1.0-dev
is not cross-compile-friendly. I don't think there are any other
architecture-dependent paths involved, but the Vala maintainers would
know what this tool does better than I do.

As a proof-of-concept, I was able to work around this in libportal by
generating some local wrappers and overrides; but ideally this would
be something that could be done centrally, with most of the work in the
vala package.

I'll follow up with more concrete suggestions, but I wanted to open the
bug with a relatively solution-neutral problem statement rather than
jumping directly to a solution.

This is related to #1060904, but perhaps more of a downstream issue;
some solutions to it would benefit from #1060904, but that isn't a
mandatory dependency.

Thanks,
smcv

Bug#1061105: [DKIM] Bug#1061105: netcdf-bin nccopy compression error in bookworm

[Sebastiaan Couwenberg]

Control: tags -1 upstream moreinfo

On 1/18/24 12:55, Andre Castro Gonçalves de Oliveira de Castro wrote:

When I attempt to compress a NetCDF file with nccopy in Bookworm, an HDF error 
is returned and an empty NetCDF is produced
If the same command + file are invoked by netcdf-bin:1:4.7.4-1 (Bullseye), the 
compression is successful and the compressed NetCDF includes all the data.

Example: (.nc file in attachment)

nccopy -d9 20240117_KNMI_Cabauw-CABAUW_PAR001.nc 
20240117_KNMI_Cabauw-CABAUW_PAR001.comp.nc

output:

NetCDF: HDF error
Location: file ; line 1617

I am using a RaspberryPi4  Debian GNU/Linux 12 (bookworm), kernel 
6.1.0-rpi4-rpi-v8,


Might be an issue with the dataset.

netcdf-bin (1:4.9.2-3) on unstable:

 $ nccopy -d9 20240117_KNMI_Cabauw-CABAUW_PAR001.nc 
20240117_KNMI_Cabauw-CABAUW_PAR001.comp.nc

 NetCDF: Filter error: bad id or parameters or duplicate filter
 Location: file ?; fcn ? line 1152

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1061106: greenbone-security-assistant: FTBFS: Module not found: Error: styled-components tried to access react-is

[Andreas Beckmann]

Source: greenbone-security-assistant
Version: 22.9.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

greenbone-security-assistant recently started to FTBFS:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/greenbone-security-assistant-22.9.1'
dh_auto_build
yarnpkg
➤ YN: · Yarn 4.0.2
➤ YN: ┌ Resolution step
➤ YN0085: │ + @babel/cli@npm:7.23.4, @babel/core@npm:7.23.2, 
@babel/runtime@npm:7.23.8, @greenbone/ui-components@npm:2021.1.2, 
@sentry/react@npm:7.93.0, and 1537 more.
➤ YN: └ Completed in 28s 517ms
➤ YN: ┌ Post-resolution validation
➤ YN0002: │ gsa@workspace:. doesn't provide @testing-library/dom (pac90a), 
requested by @testing-library/user-event.
➤ YN0002: │ gsa@workspace:. doesn't provide eslint (paeac0), requested by 
eslint-config-prettier.
➤ YN0002: │ gsa@workspace:. doesn't provide webpack (p57dc5), requested by 
babel-loader.
➤ YN0086: │ Some peer dependencies are incorrectly met; run yarn explain 
peer-requirements  for details, where  is the six-letter p-prefixed 
code.
➤ YN: └ Completed
➤ YN: ┌ Fetch step
➤ YN0013: │ 1541 packages were added to the project (+ 232.09 MiB).
➤ YN: └ Completed in 16s 399ms
➤ YN: ┌ Link step
➤ YN: │ ESM support for PnP uses the experimental loader API and is 
therefore experimental
➤ YN0007: │ core-js@npm:3.35.0 must be built because it never has been before 
or the last one failed
➤ YN0007: │ core-js-pure@npm:3.35.0 must be built because it never has been 
before or the last one failed
➤ YN: └ Completed in 5s 423ms
➤ YN: · Done with warnings in 50s 952ms
yarnpkg build
Creating an optimized production build...
Failed to compile.

Module not found: Error: styled-components tried to access react-is (a peer 
dependency) but it isn't provided by its ancestors; this makes the require call 
ambiguous and unsound.
Required package: react-is
Required by: 
styled-components@virtual:aeec793562dc054156d7617eeac4faec6a48bcb8abd65b0c5eca097fbdaab5ab191a1518058c854b6434a26c3b23f297953db6ee0f294b8518a22ec995f2afae#npm:5.3.11
 (via 
/build/greenbone-security-assistant-22.9.1/.yarn/__virtual__/styled-components-virtual-f168d3a81a/1/debian/home/.yarn/berry/cache/styled-components-npm-5.3.11-d45616b9af-10c0.zip/node_modules/styled-components/dist/)

Ancestor breaking the chain: 
@greenbone/ui-components@virtual:6e2d2fdcc82b05e346bcb4964f7afce4b86db2780b5e70c3a01083f0ab0e9d9251f378bdd1e6fb2b74deb15e01fe6e14d0858724d02a8d9cbcc579c95cd07fcc#npm:2021.1.2
Ancestor breaking the chain: 
babel-plugin-styled-components@virtual:f168d3a81a1e91b693c08108d1009a02a75f6090dbf4772ac40165fab801be2bfee125de351515632b0b703695a00a076f7d92e70f7ac26d50383a3e693539ff#npm:2.1.4


make[1]: *** [debian/rules:15: override_dh_auto_build] Error 1


Andreas


greenbone-security-assistant_22.9.1-1.log.gz
Description: application/gzip

Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Mathieu Malaterre]

Control: severity -1 important

On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca  wrote:
[...]
> For this reason I would
> suggest to disable stackclash on the armel build of dcmtk (just like you
> did in experimental) to make sure the package builds properly again, but
> keep #1060104 open at a lower severity so that we don't lose track of
> this.

Done ! Thanks

Bug#998024: rsass as alternative

[Alexandre Rossi]

Hi,

rsass can appropriately compile sass files which is convenient for Debian
packaging.

Thanks,

Alex

Bug#1061076: kbtin: FTBFS with stack-clash-protection on armhf due to valgrind segfault

[Adam Borowski]

On Wed, Jan 17, 2024 at 04:29:10PM +0100, Emanuele Rocca wrote:
> Source: kbtin
> Severity: serious
> Usertags: 32bit-stackclash

> kbtin currently fails to build from source on armhf. The failure is due
> to an incompatibility between valgrind and stack-clash-protection on
> 32bit arm reported upstream at:
> https://bugs.kde.org/show_bug.cgi?id=479699

Thanks for the report (and fix).  I've applied it in git.  However... during
testing, while the package now builds fine on armhf (and armel amd64 ...),
I see it makes valgrind crash on arm64 with:

Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92
valgrind: m_debuginfo/readdwarf.c:2822 (copy_convert_CfiExpr_tree): Assertion 
'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

and likewise this doesn't appear to be a problem with kbtin itself -- it's
just a regular C program that does nothing weird.

While these bugs are unrelated (other than both being failures due to
valgrind not liking new toolchains), it makes no sense to upload the fix
right now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄

Bug#550236: Patch ineffective

[Georges Khaznadar]

Hello,

I am the new maintainer for secure-delete, and this bug report is 8
years old.

Please, can you tell me what is the output of srm with the -v switch
enabled (so in verbose mode), when it fails with 'Too many open files'?

And by the way, can you send me a tarball with some minimal example able
to trigger this bug?

Thank you in advance,   Georges.

On Wed, 25 Jun 2014 11:40:37 +0200 Martin Erik Werner 
 wrote:
> The patch does not appear to solve this issue, which is still present in 
> version
> 3.1-5.
> 
> -- 
> Martin Erik Werner 
> 
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1061104: xtl-dev is not installed with libxsimd-dev transparently (missing Depends:)

[Kentaro HAYASHI]

Package: libxsimd-dev
Version: 10.0.0-3
Severity: important
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,


* What led up to the situation?

  libxsimd-dev requires xtl-dev with Build-Depends: but it should be
  Depends: so it does not require xtl-dev:

  $ apt depends libxsimd-dev
  libxsimd-dev
  Breaks: libxtensor-dev (<< 0.24~)
  Breaks: python3-pythran (<< 0.11~)
  Suggests: libxsimd-doc

  Thus, when installing via apt install -y libxsimd-dev, it does not
  install xtl-dev:

  $ apt install -y  libxsimd-dev
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Suggested packages:
libxsimd-doc
  The following NEW packages will be installed:
libxsimd-dev
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 101 kB of archives.
  After this operation, 1161 kB of additional disk space will be used.
  Get:1 http://deb.debian.org/debian sid/main amd64 libxsimd-dev amd64
  10.0.0-3 [101 kB]
  Fetched 101 kB in 0s (2438 kB/s)
  debconf: delaying package configuration, since apt-utils is not
  installed Selecting previously unselected package libxsimd-dev:amd64.
  (Reading database ... 5230 files and directories currently installed.)
  Preparing to unpack .../libxsimd-dev_10.0.0-3_amd64.deb ...
  Unpacking libxsimd-dev:amd64 (10.0.0-3) ...
  Setting up libxsimd-dev:amd64 (10.0.0-3) ...

  NOTE: find_dependency(xtl) in
  /usr/lib/x86_64-linux-gnu/cmake/xsimd/xsimdConfig.cmake can't find
  xtl correctly if xtl-dev was not installed.

  There is a same bug with libxsimd-dev (8.1.0-7 on bookworm)

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

  Specify xtl-dev in Depends: field.

  diff -ur xsimd-10.0.0.orig xsimd-10.0.0
  diff -ur xsimd-10.0.0.orig/debian/control xsimd-10.0.0/debian/control
  --- xsimd-10.0.0.orig/debian/control2023-09-25 17:40:07.0
  +0900 +++ xsimd-10.0.0/debian/control 2024-01-18 20:48:05.400870085
  +0900 @@ -20,7 +20,9 @@
   Architecture: any
   Multi-Arch: same
   Section: libdevel
  -Depends: ${misc:Depends}
  +Depends: 
  + xtl-dev,
  + ${misc:Depends}
   Suggests: libxsimd-doc 
   Breaks: libxtensor-dev (<< 0.24~),
   python3-pythran (<< 0.11~)
   

 * What was the outcome of this action?

   xtl-dev can be installable transparently with sudo apt install -y
   libxsimd-dev.

 * What outcome did you expect instead?

   N/A

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

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

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

Bug#1061103: locale charset not respected

[Zefram]

Package: unicode
Version: 2.8-1.1
Severity: normal

unicode(1) documents that, by default, it produces output in the charset
nominated by the user's locale.  (This is in the documentation of the "-i"
option, which can be used to specify an output charset; it specifically
says that with a "properly set up locale" the option should not be
needed.)  In fact it does not reliably respect the environmental locale;
whether it uses it depends partly on which environment variables are being
used to specify it and partly on which locale is specified.  (I'm not
clear on what the logic actually is.)  If it doesn't use the locale then,
empirically, it outputs in UTF-8, which is not a safe default.

If no locale-relevant environment variables are set, meaning that the
environmental locale is C, then unicode(1) doesn't respect the locale,
and outputs in UTF-8:

$ env - locale charmap
ANSI_X3.4-1968
$ env - unicode --brief -x 2603 | od -tx1
000 e2 98 83 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d
020 41 4e 0a
023

If the C locale is explicitly set in the LANG environment variable,
then unicode(1) doesn't respect the locale, and outputs in UTF-8:

$ env - LANG=C locale charmap
ANSI_X3.4-1968
$ env - LANG=C unicode --brief -x 2603 | od -tx1
000 e2 98 83 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d
020 41 4e 0a
023

But if a Latin-1 locale is set in the LANG environment variable, then
unicode(1) does respect it:

$ env - LANG=de_DE.iso88591 locale charmap
ISO-8859-1
$ env - LANG=de_DE.iso88591 unicode --brief -x 2603 | od -tx1
000 3f 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d 41 4e
020 0a
021

Specifying the charset aspect of a locale using the LC_CTYPE environment
variable produces the same locale-dependent results as using LANG:

$ env - LC_CTYPE=C locale charmap
ANSI_X3.4-1968
$ env - LC_CTYPE=C unicode --brief -x 2603 | od -tx1
000 e2 98 83 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d
020 41 4e 0a
023
$ env - LC_CTYPE=de_DE.iso88591 locale charmap
ISO-8859-1
$ env - LC_CTYPE=de_DE.iso88591 unicode --brief -x 2603 | od -tx1
000 3f 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d 41 4e
020 0a
021

If a locale is specified using the LC_ALL environment variable, however,
then it seems to always be respected:

$ env - LC_ALL=C locale charmap
ANSI_X3.4-1968
$ env - LC_ALL=C unicode --brief -x 2603 | od -tx1
000 3f 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d 41 4e
020 0a
021
$ env - LC_ALL=de_DE.iso88591 locale charmap
ISO-8859-1
$ env - LC_ALL=de_DE.iso88591 unicode --brief -x 2603 | od -tx1
000 3f 20 55 2b 32 36 30 33 20 53 4e 4f 57 4d 41 4e
020 0a
021

The impact of this bug is that for many reasonable setups, with locale
correctly described in the environment and matching actual output
device capabilities, unicode(1) generates output containing spurious
control characters that not only don't display what was intended but
also sometimes screw up the display of other parts of the output.
I'm specifically seeing that result with a Latin-1 terminal emulator
and the C locale.

-zefram

Bug#1061102: librust-tikv-jemallocator-dev: fails to compile provided code

[Jonas Smedegaard]

Package: librust-tikv-jemallocator-dev
Version: 0.5.4-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Attempts at building Rust project biome (bug#1051238) fails during build
of the tikv-jemallocator crate, like this:

 Running 
`/build/biome-1.5.2/target/release/build/tikv-jemalloc-sys-b3e7f090619a01f2/build-script-build`
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
dh-cargo:deb-built-using=jemalloc_pic=0=/build/biome-1.5.2/debian/cargo_registry/tikv-jemalloc-sys-0.5.4
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] TARGET=x86_64-unknown-linux-gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] HOST=x86_64-unknown-linux-gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] NUM_JOBS=2
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
OUT_DIR="/build/biome-1.5.2/target/x86_64-unknown-linux-gnu/release/build/tikv-jemalloc-sys-2de43a13417834c8/out"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
BUILD_DIR="/build/biome-1.5.2/target/x86_64-unknown-linux-gnu/release/build/tikv-jemalloc-sys-2de43a13417834c8/out/build"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
SRC_DIR="/usr/share/cargo/registry/tikv-jemalloc-sys-0.5.4"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] cargo:rustc-cfg=prefixed
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_OVERRIDE
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] OPT_LEVEL = Some("3")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] TARGET = 
Some("x86_64-unknown-linux-gnu")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] HOST = Some("x86_64-unknown-linux-gnu")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=CC_x86_64-unknown-linux-gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CC_x86_64-unknown-linux-gnu = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=CC_x86_64_unknown_linux_gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CC_x86_64_unknown_linux_gnu = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] cargo:rerun-if-env-changed=HOST_CC
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] HOST_CC = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] cargo:rerun-if-env-changed=CC
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CC = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CRATE_CC_NO_DEFAULTS = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] DEBUG = Some("false")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CARGO_CFG_TARGET_FEATURE = 
Some("fxsr,sse,sse2")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=CFLAGS_x86_64-unknown-linux-gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CFLAGS_x86_64-unknown-linux-gnu = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=CFLAGS_x86_64_unknown_linux_gnu
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CFLAGS_x86_64_unknown_linux_gnu = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] cargo:rerun-if-env-changed=HOST_CFLAGS
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] HOST_CFLAGS = None
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] cargo:rerun-if-env-changed=CFLAGS
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CFLAGS = Some("-g -O2 
-ffile-prefix-map=/build/biome-1.5.2=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection")
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CC="cc"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] CFLAGS="-O3 -ffunction-sections 
-fdata-sections -fPIC -m64 -g -O2 -ffile-prefix-map=/build/biome-1.5.2=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] JEMALLOC_REPO_DIR="jemalloc"
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_MALLOC_CONF
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_PAGE
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_HUGEPAGE
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_QUANTUM
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] 
cargo:rerun-if-env-changed=JEMALLOC_SYS_WITH_LG_VADDR
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] --with-jemalloc-prefix=_rjem_
[tikv-jemalloc-sys 0.5.4+5.3.0-patched] running: cd 
"/build/biome-1.5.2/target/x86_64-unknown-linux-gnu/release/build/tikv-jemalloc-sys-2de43a13417834c8/out/build"
 && CC="cc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -m64 -g -O2 
-ffile-prefix-map=/build/biome-1.5.2=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection" 
CPPFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -m64 -g -O2 
-ffile-prefix-map=/build/biome-1.5.2=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection" 
LDFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -m64 -g -O2 
-ffile-prefix-map=/build/biome-1.5.2=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection" "sh" 

Bug#849837: /usr/bin/sfill: malloc assertion failure

[Georges Khaznadar]

Dear Rob,

I am the new maintainer of the package secure-delete for a few months.

Your bugreport is now eight years old. Unfortunately, it misses some
information: please can you tell me which are the filesystems on which
sfill repeatably fails? or send me a minimal example, like a tarball to
show how sfill's failure could be triggered?

By the way: have you got similar failures with filesystems which you are
using today?

Thank you in advance for your response.

Best regards,   Georges.

Rob Leslie a écrit :
> Package: secure-delete
> Version: 3.1-5
> Severity: important
> File: /usr/bin/sfill
> 
> Dear Maintainer,
> 
> I have some filesystems on which sfill repeatably fails with:
> 
> % sfill -fllz $dir
> sfill: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char 
> *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, 
> fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned 
> long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * 
> (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size 
> & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> 
> After this failure, the root directory of the filesystem is littered with
> numerous empty files.
> 
> 
> -- System Information:
> Debian Release: 7.11
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: i386 (x86_64)
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages secure-delete depends on:
> ii  libc6  2.13-38+deb7u11
> 
> secure-delete recommends no packages.
> 
> secure-delete suggests no packages.
> 
> -- no debconf information
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1061099: MR on Salsa

[Gard Spreemann]

Control:
tags 1061099 patch

A fix is available as MR 1 on Salsa:
https://salsa.debian.org/yangfl-guest/imgui/-/merge_requests/1


 Best,
 Gard


signature.asc
Description: PGP signature

Bug#1061101: Rebuild bindata.go using go-bindata

[Simon Josefsson]

Package: golang-github-common-nighthawk-go-figure
Severity: wishlist

Hi.  I noticed that the source code file bindata.go in this package was
generated using go-bindata from the files in fonts/.  This bug is to
request that this file is re-generated from source code during the build
of the Debian package.  I have verified manually that it is possible to
re-generate the file resulting in only minor differences (see below).

Before fixing this, I think we need to understand one thing better.  I
am worried that if we would use the output below, the differences in the
resulting source code would result in a build that is not bit-by-bit
binary identical to what the rest of the Go eco-system would see, which
may be a problem.  How can we make go-bindata generate exactly the same
bindata.go as upstream ships?  Of course, we could easily run go-bindata
and then add a sed expression to modify the resulting source code, so it
will match upstream's.  But that is a bit ugly.

Alternatively, we could enhance go-bindata to generating code without
mode/modTime (under some parameter) -- since I think this approach play
well with reproducible builds -- and then convince
golang-github-common-nighthawk-go-figure upstream to re-generate their
file using that.  Then we would be able to reproduce the upstream source
identically and still rebuild the sources we use for building this
Debian package.

Thoughts?

/Simon

jas@kaka:~/dpkg/golang-github-common-nighthawk-go-figure$ go-bindata -pkg 
figure -modtime 1529341546 fonts/
jas@kaka:~/dpkg/golang-github-common-nighthawk-go-figure$ git diff -w
diff --git a/bindata.go b/bindata.go
index f85d3bb..6b7c86d 100644
--- a/bindata.go
+++ b/bindata.go
@@ -1231,7 +1231,7 @@ func fontsEliteFlf() (*asset, error) {
return nil, err
}
 
-   info := bindataFileInfo{name: "fonts/elite.flf", size: 5005, mode: 
os.FileMode(420), modTime: time.Unix(1559099119, 0)}
+   info := bindataFileInfo{name: "fonts/elite.flf", size: 5005, mode: 
os.FileMode(436), modTime: time.Unix(1529341546, 0)}
a := {bytes: bytes, info: info}
return a, nil
 }
@@ -3438,7 +3438,6 @@ type bintree struct {
Func func() (*asset, error)
Children map[string]*bintree
 }
-
 var _bintree = {nil, map[string]*bintree{
"fonts": {nil, map[string]*bintree{
"3-d.flf": {fonts3DFlf, map[string]*bintree{}},
@@ -3639,3 +3638,4 @@ func _filePath(dir, name string) string {
cannonicalName := strings.Replace(name, "\\", "/", -1)
return filepath.Join(append([]string{dir}, 
strings.Split(cannonicalName, "/")...)...)
 }
+
jas@kaka:~/dpkg/golang-github-common-nighthawk-go-figure$ 


signature.asc
Description: PGP signature

Bug#1061100: imgui: Please tag git commits that correspond to versions in the archive

[Gard Spreemann]

Source: imgui
X-Debbugs-Cc: g...@nonempty.org
Version: 1.86+ds-1
Severity: minor

ImGui is currently available in the following distributions and versions:

* bullseye: 1.81+ds-1
* bookworm: 1.86+ds-1
* trixie: 1.89.6+ds-1
* sid: 1.89.6+ds-1

Of these, only the bullseye version is properly tagged in the git
repository shared on Salsa. Please tag the git commit corresponding
every version uploaded to the Debian archives to make the life of
other DDs easier. (In my case, the lack of tags was a great annoyance
when investigating #1061099)


 Best,
 Gard


signature.asc
Description: PGP signature

Bug#1040603: Bug#1042027: transmission 4.0.5-1

[Alexandre Rossi]

Hi,

> > A fixed version is awaiting sponsorship at:
> >
> > https://mentors.debian.net/package/transmission/
> 
> please push this packaging effort to a personal (but publicly
> accessible) git repo on salsa, so that i can cherry pick the changes i
> like, thanks

Here:


https://salsa.debian.org/niol/transmission/-/tree/master-candidate?ref_type=heads

Thanks,

Alex