Bug#1056633: src:gprconfig-kb: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: gprconfig-kb
Version: 23.0.0-3
Severity: serious
Control: close -1 23.0.0-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gprconfig-kb has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
doesn't pass its own autopkgtest on multiple architectures as some test 
dependencies aren't available there.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gprconfig-kb



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056628: udhcpc: file loss during upgrade due to Multi-Arch: same interacting with /usr-merge

[Michael Tokarev]

24.11.2023 02:27, Helmut Grohne:

Package: udhcpc
Version: 1:1.36.1-6~exp.1
Severity: normal
User: helm...@debian.org
Usertags: dep17p7

Hi Chris,

thanks for sitting down with me and doing this /usr-move. We aimed to be
careful and upload to experimental. Now dumat doesn't like your upload.
I'm trying to figure out why and whether this is an analyzer bug or a
real problem, so please do not move busybox to unstable for the time
bing.

What follows is details that you may skip entirely, but figured I better
write them down for my future self. So dumat figured that udhcpc is
Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
experimental package contains /usr/sbin/udhcpc. In theory, this could
result in a loss scenario, because you can install udhcpc for two
architecture in bookworm, ...


Helmut, udhcp is arch-all package.  You can't install two arch-all
packages at the same time..

I think we've been there before.  [/usr]/sbin/udhcpc is just a symlink
to [/usr]/bin/busybox.

/mjt

Bug#889722: conflict with apparmor < 2.11.1-4?

[Harald Dunkel]

nope

Thank you anyway
Harri

Bug#1056632: irssi: missing dependency on libwww-perl

[Dale Richards]

Package: irssi
Version: 1.4.3-2
Severity: normal
X-Debbugs-Cc: d...@dalerichards.net

Hi,

Although the irssi-scripts package is suggested by irssi, the irssi
manual still states that scripts should be installed using the included
scriptassist.pl script. Additionally, users may already be familiar with
installing irssi scripts this way, or they may want to install scripts
that are not yet packaged by irssi-scripts.

Currently, running "/run scriptassist" generates the following error:

06:58 -!- Irssi: Error in script scriptassist:
06:58 Can't locate LWP/UserAgent.pm in @INC (you may need to install the
  LWP::UserAgent module) (@INC contains: /home/debian/.irssi/scripts
  /usr/share/irssi/scripts /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0
  /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36
  /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.36
  /usr/share/perl/5.36 /usr/local/lib/site_perl) at
  /usr/share/irssi/scripts/scriptassist.pl line 24.
06:58 BEGIN failed--compilation aborted at
  /usr/share/irssi/scripts/scriptassist.pl line 24.

For this command to work as expected, the irssi package should depend on
libwww-perl. Otherwise, perhaps scriptassist.pl should be patched to
display a message directing users to the irssi-scripts package instead.



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

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

Versions of packages irssi depends on:
ii  libc6   2.36-9+deb12u3
ii  libglib2.0-02.74.6-2
ii  libperl5.36 5.36.0-7
ii  libssl3 3.0.11-1~deb12u2
ii  libtinfo6   6.4-4
ii  perl5.36.0-7
ii  perl-base [perlapi-5.36.0]  5.36.0-7

irssi recommends no packages.

Versions of packages irssi suggests:
pn  irssi-scripts  



Best regards,
Dale Richards

Bug#992180: [Debichem-devel] Bug#992180: MR with fix available Re: openmm FTBFS on amd64/arm64/ppc64el

[Andrius Merkys]

Hi Michael,

On 2023-11-23 19:25, Michael R. Crusoe wrote:
Hello, I opened the merge request below to add SIMDe to this package; I 
tested on the riscv64 porterbox where the build succeeded, included 
tests. Likewise on my personal amd64 laptop.


https://salsa.debian.org/debichem-team/openmm/-/merge_requests/1


Thanks a lot for helping porting openmm to more architectures! I have 
merged your PR and uploaded openmm.


It won't fix the FTBFS on armel / armhf; that's due to them being 
detected as arm64 and inappropriate NEON intrinsics being used


Thanks for spotting this, I will give it a look, although I understand 
very little about vectorization.


Best wishes,
Andrius

Bug#1056631: unbound: Please package 1.19.0 release for DNS64 improvements

[Daniel Gröber]

Source: unbound
Severity: wishlist
Tags: ipv6
X-Debbugs-Cc: d...@darkboxed.org, debian-i...@lists.debian.org

Hi Michael,

unbound 1.19.0 includes a small patch of mine aimed at allowing people
stuck behind IPv4-only ISPs to still deploy monostack-IPv6 (using v6
tunneling and NAT64) without getting hit by the downsides of tunneled
IPv6 internet access.

I'd appreciate it if you could package it :)

Thanks,
--Daniel

Bug#1040750: about loong64 linux and grub package merge

[zhangjialing]

 Dear maintianers

 For now , the lintian package has block the loong64 linux and grub 
package merge, shell we give a new lintian package . IF we  just  add 
the loong64 support patch for lintian so that the new lintian can work 
for loong64 and not influence for other things .


Thanks,

JiaLing Zhang

Bug#1056630: evince crashes with sigsegv

[Jörg Sommer]

Package: evince
Version: 45.0-1
Severity: normal
File: /usr/bin/evince

Hi,

yesterday, my evince crashed, and I thought it was related to full-screen
mode (F5) and updating the PDF file (with latex) at the same time. But I
can't reproduce the crash. I only have the backtrace, and maybe, it is
helpful and you can track down the bug.

```text
   PID: 197951 (evince)
   UID: 1000 (joerg)
   GID: 1000 (joerg)
Signal: 11 (SEGV)
 Timestamp: Thu 2023-11-23 18:59:49 CET (11h ago)
  Command Line: evince
Executable: /usr/bin/evince
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-rofi-197905.scope
  Unit: user@1000.service
 User Unit: app-gnome-rofi-197905.scope
 Slice: user-1000.slice
 Owner UID: 1000 (joerg)
   Boot ID: 3f9715ead70d409f9fb5ed3b9353d33c
Machine ID: 523cb54753234ed08c13ec497d0d3b64
  Hostname: zenbook
   Storage: 
/var/lib/systemd/coredump/core.evince.1000.3f9715ead70d409f9fb5ed3b9353d33c.197951.170076238900.zst
 (present)
  Size on Disk: 7.8M
   Message: Process 197951 (evince) of user 1000 dumped core.


warning: Can't open file /memfd:gdk-wayland (deleted) during file-backed 
mapping note processing

warning: Can't open file /memfd:wayland-cursor (deleted) during file-backed 
mapping note processing
[New LWP 197951]
[New LWP 197955]
[New LWP 197956]
[New LWP 197959]
[New LWP 197958]
[New LWP 197973]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `evince'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  g_type_check_instance (type_instance=type_instance@entry=0x5deb90d1f420) at 
../../../gobject/gtype.c:4292
Download failed: Das Argument ist ungültig.  Continuing without source file 
./debian/build/deb/../../../gobject/gtype.c.
4292../../../gobject/gtype.c: Unpassender IOCTL (I/O-Control) für das Gerät.
[Current thread is 1 (Thread 0x7d7c5e20af80 (LWP 197951))]
#0  g_type_check_instance (type_instance=type_instance@entry=0x5deb90d1f420) at 
../../../gobject/gtype.c:4292
node = 0x4800
#1  0x7d7c628a3a08 in g_signal_handlers_disconnect_matched 
(instance=instance@entry=0x5deb90d1f420, mask=mask@entry=(G_SIGNAL_MATCH_FUNC | 
G_SIGNAL_MATCH_DATA), signal_id=signal_id@entry=0, detail=detail@entry=0, 
closure=closure@entry=0x0, func=func@entry=0x7d7c62979ad0 , 
data=0x5deb96ee4f20) at ../../../gobject/gsignal.c:3085
_g_boolean_var_95 = 
n_handlers = 0
__func__ = "g_signal_handlers_disconnect_matched"
#2  0x7d7c6297a0d5 in ev_view_presentation_delete_job (job=0x5deb90d1f420, 
pview=0x5deb96ee4f20 [EvViewPresentation]) at 
../libview/ev-view-presentation.c:405
#3  ev_view_presentation_delete_job (job=0x5deb90d1f420, pview=0x5deb96ee4f20 
[EvViewPresentation]) at ../libview/ev-view-presentation.c:399
#4  ev_view_presentation_reset_jobs (pview=0x5deb96ee4f20 [EvViewPresentation]) 
at ../libview/ev-view-presentation.c:413
#5  0x7d7c6297a1e0 in ev_view_presentation_dispose (object=0x5deb96ee4f20 
[EvViewPresentation]) at ../libview/ev-view-presentation.c:972
pview = 0x5deb96ee4f20 [EvViewPresentation]
#6  0x7d7c6288e9c0 in g_object_unref (_object=0x5deb96ee4f20) at 
../../../gobject/gobject.c:3894
weak_locations = 
nqueue = 0x5deb91278c50
old_ref = 
__func__ = "g_object_unref"
object = 0x5deb96ee4f20 [EvViewPresentation]
__func__ = "g_object_unref"
#7  g_object_unref (_object=0x5deb96ee4f20) at ../../../gobject/gobject.c:3805
object = 0x5deb96ee4f20 [EvViewPresentation]
__func__ = "g_object_unref"
#8  0x5deb8fc9ca9f in ev_window_set_document (document=0x7d7c16c1ba40 
[PdfDocument], ev_window=0x5deb90fa8050 [EvWindow]) at ../shell/ev-window.c:1771
_pp = 0x5deb90fa7bb8
_ptr = 
current_page = 4
priv = 0x5deb90fa7b60
#9  ev_window_document_changed_cb (model=, pspec=, ev_window=0x5deb90fa8050 [EvWindow]) at ../shell/ev-window.c:5247
#14 0x7d7c628a4243 in  (instance=instance@entry=0x5deb90fa78f0, 
signal_id=, detail=) at 
../../../gobject/gsignal.c:3675
var_args = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 
0x7ffdec200d90, reg_save_area = 0x7ffdec200cd0}}
#10 0x7d7c62889540 in g_closure_invoke (closure=0x5deb91115280, 
return_value=0x0, n_param_values=2, param_values=0x7ffdec200a80, 
invocation_hint=0x7ffdec2009d0) at ../../../gobject/gclosure.c:832
marshal = 0x7d7c6288c6d0 
marshal_data = 0x0
in_marshal = 0
real_closure = 0x5deb91115260
__func__ = "g_closure_invoke"
#11 0x7d7c6289cafc in signal_emit_unlocked_R 
(node=node@entry=0x7ffdec200b50, detail=detail@entry=1341, 
instance=instance@entry=0x5deb90fa78f0, 
emission_return=emission_return@entry=0x0, 

Bug#1030895: qt6-webengine: Enable riscv64 support

[Bo YU]

Hi!

On Fri, Nov 24, 2023 at 1:33 AM Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi,
>
> On 21/11/23 06:06, Bo YU wrote:
> [snip]
> > Let's start here again, okay? :)
> >
> > I just refactor these patches, which should not affect building of
> > other architectures except riscv64.
>
> And still we have a 14k+ lines debdiff to apply. My apologies, this is a
> huge NACK. Get it supported by upstream first and then we can talk.

Okay, no problem, I understand the situation and thanks for your feedback here.

The good news is that there is making an update for Chromium upstream, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051998#72

If everything is okay and Chromium can accept these patches but qt6
upstream can pick the Chromium which has supported riscv64 will wait a
long time I think.

Thanks  again~

BR,
Bo
(BTW, if anyone need these qt6-webengine riscv64 package, please to
see here: http://www.riscv-dev.tech:63015/qt6-webengine/)

>
> --
> To unsubscribe, send mail to 1030895-unsubscr...@bugs.debian.org.

Bug#1051998: chromium: please to add support for riscv64

[Bo YU]

Hi!

On Wed, Nov 22, 2023 at 12:51 PM Daniel Richard G.  wrote:
>
> Hello Bo YU,
>
> On Sun, 2023 Nov 19 10:01-05:00, Bo YU wrote:
> >
> > I have rebased the patchset base on 119.0.6045.159-1, there is no code
> > changed but maybe small change will be happened on next version from
> > upstream's supporting for riscv64.
>
> Do you have links/references for the upstreaming of riscv64 support?
> I am interested to see the status of that in Chromium development.
>

I made a summary about support riscv64 from Chromium upstream based on 116, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051998#20

Sorry I promised that I will submit these patches to upstream but this
has not happened due to  being  busy with other works. Another reason
is that I known the support from upstream is alway in process and then
the original patchset come from opensuse then other distros picked
this as we did here so I am hesitant here it is suitable to submit
these valuable patchset from us.

But likely the Chromium developer has picked this now:
1. angle:
https://chromium-review.googlesource.com/c/angle/angle/+/5057086
2. base:
https://chromium-review.googlesource.com/c/chromium/src/+/5054184
3. sandbox:
https://chromium-review.googlesource.com/c/chromium/src/+/5056263
4. ffmpeg:
https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5054185

we have one dav1d to be left, but the developer told me he has did it.

> (Did Google accept all of the patches needed, or only a small
> part of them?)

I am not sure here so let's to see next step what happened.

BR,
Bo

Bug#1056592: debos: yaml: line X: did not find expected key

[Arnaud Rebillout]

Hello Christopher,

On 23/11/2023 23:45, Christopher Obbard wrote:

For me with debos 1.1.2-2, I seem to reproduce your issue:

   Running /debos --artifactdir debos-tests --template-var 'ospack:"debian"'
debos-tests/test-key.yaml using kvm backend
   2023/11/23 16:41:30 yaml: line 7: did not find expected key


Good to hear, I'm not alone!


But with a local checkout of debos upstream built with `go build`, your recipe
runs just fine (notice there are now no single-quotes around the --template-
var argument to the inner debos call):

   Running /debos --artifactdir debos-tests --template-var ospack:debdfsa
debos-tests/test-key.yaml using kvm backend
   2023/11/23 16:41:46  debootstrap 


I think this has something to do with the recent shell escaping patches.
Perhaps there is some go module which isn't up to date in Debian causing the
additional single quotation marks around the inner debos call ?


Indeed, the package golang-github-alessio-shellescape is not exactly at 
the last version in Debian, we have 1.4.1, upstream is at 1.4.2.


However, after updating it, and rebuilding the fakemachine package, and 
then rebuilding debos, I still have the same error.


After digging a bit more, I found that Sjoerd added a few commits to 
debos, just after release 1.1.2. Those commits are needed if fakemachine 
0.0.7 is used, and I can confirm that the issue is fixed by importing 
those commits. Cf: 
https://salsa.debian.org/go-team/packages/debos/-/merge_requests/5


Packaging sidenote: please push your pristine-tar branch (or disable it 
in debian/gbp.conf), at the moment "gbp buildpackage" fails because of that.


Thanks!

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Vincent Lefevre]

On 2023-11-24 02:07:15 +0100, Vincent Lefevre wrote:
> It seems that the cause of the issue is that at package installation,
> the current TEXINPUTS is taken into account. So it uses my own
> glyphtounicode.tex file (needed as a workaround to a Ghostscript
> bug) instead of the one from the package.

The issue disappears if I remove my glyphtounicode.tex file and
do "apt install --reinstall texlive-base".

Now /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
correctly appears in /var/lib/texmf/web2c/pdftex/pdflatex.log.

If I understand correctly, /var/lib/texmf/web2c/pdftex/pdflatex.fmt is
generated by fmtutil, but its man page does not say that $TEXINPUTS is
used.

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

Bug#1032369: O: harmony -- program and library for creating and managing Discord accounts

[Paul Wise]

On Sun, 2023-03-05 at 16:40 +0800, Paul Wise wrote:

> I intend to orphan the harmony package.
> 
> The package description is:
>  A program and library for performing various actions with
>  the Discord messaging service.

Patrick, since you recently adopted the Debian purple-discord package,
perhaps you would be interested in adopting the harmony package too?

https://bugs.debian.org/1032369

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1053062: mina: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/mina/-/merge_requests/5

Bug#1056629: haskell-simple-sendfile: FTBFS on hurd-i386: missing conduit & conduit-extra build-deps

[Samuel Thibault]

Source: haskell-simple-sendfile
Version: 0.2.32-1
Severity: important
Tags: patch

Hello,

As specified in simple-sendfile.cabal, the non-linux ports need
libghc-conduit-dev and libghc-conduit-extra-dev (see
https://buildd.debian.org/status/fetch.php?pkg=haskell-simple-sendfile=hurd-i386=0.2.32-1=1696815797=0
), as the attached patch fixes.

Samuel

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-24 02:14:44.327702173 +0100
+++ debian/control  2023-11-24 02:22:46.205868750 +0100
@@ -13,6 +13,12 @@
  ghc (>= 8),
  ghc-prof,
  libghc-network-dev (>= 3.1.4),
+ libghc-conduit-extra-dev (>= 1.0) [!linux-any],
+ libghc-conduit-extra-dev (<< 1.4) [!linux-any],
+ libghc-conduit-extra-prof [!linux-any],
+ libghc-conduit-dev (>= 1.0) [!linux-any],
+ libghc-conduit-dev (<< 1.4) [!linux-any],
+ libghc-conduit-prof [!linux-any],
  libghc-network-prof,
  libghc-resourcet-dev,
  libghc-resourcet-prof,

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Vincent Lefevre]

It seems that the cause of the issue is that at package installation,
the current TEXINPUTS is taken into account. So it uses my own
glyphtounicode.tex file (needed as a workaround to a Ghostscript
bug) instead of the one from the package.

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

Bug#1056373: musescore-general-soundfont: Uses dpkg --no-uniform-compression

[Guillem Jover]

On Wed, 2023-11-22 at 01:57:50 +, Thorsten Glaser wrote:
> Guillem Jover dixit:
> >the above (waiting for EOL, or the dpkg update, or compressing
> >everything with gzip) are not good options, I guess I could wait a
> >bit more until say dpkg 1.23.x? It's not urgent, it would just be
> >nice to get rid of them. :)
> 
> I understand the motivation, but on the other hand I’d rather like
> this to be a somewhat long-term thing.

Well, I see the patch I've got queued is from 2016, so this already
seems like long term. :) In any case:

> I don’t know the timelines, but 1.23.x would mean post-trixie, so
> anything in trixie-backports could still use it? That’s probably
> reasonable (and they get rarely updated anyway).

Yes, I think backports would be fine.

> To avoid a needless upload of the large packages, would you
> consider first making it a no-op that warns but does not fail the
> package build for the first release? Then with dpkg 1.24.0 I’d
> have to definitely upload all of them (otherwise they’d be rc-
> buggy) but if in the meantime any update arrives¹ I could do the
> switch already.

That's usually the way to obsolete these things yes, for reference
this is the patch I've got queued:

  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=pu/default-uniform-compression=c9cec0fcf43ab117ea746e6787ba3bbbd3ab7f72

So if that looks good, then I'll update

to include the schedule for this deprecation.

Thanks,
Guillem

Bug#1040062: dpkg-dev: Please drop pie-{compile,link}.spec

[Guillem Jover]

Hi!

On Tue, 2023-10-31 at 10:52:40 +0100, Guillem Jover wrote:
> I guess I could do it the other way, and given this is apparently
> causing issues as reported by Adrian, and as seen recently from
> the referenced bug report which might require patching a specific
> package to disable PIE there, I'm inclined to completely mask PIE
> in dpkg-buildflags for alpha and ia64 in around a couple of weeks,
> if I don't hear anything.

I've now queued locally a commit masking this for alpha and ia64 and
will be including it in dpkg 1.22.2, probably by the end of the weekend.
To the porters, please let me know if you'd prefer these not to be
masked.

> If PIE (via specs files) appears to work on x32, and changing the
> defaults in gcc is too much to bother, I think leaving it as is looks
> fine by me. But if this is causing problems as well and the x32 porters
> (if there's any remaining :), want to mask it alongside the other ports,
> let me know and I can also flip the switch for that one.

If the porters would also like to see x32 masked, let me know and I
can also include it, otherwise I'll leave it as it is now.

Thanks,
Guillem

Bug#1055605: fstack-clash-protection hardening change breaks building packages with clang on arm64

[Guillem Jover]

Control: severity -1 wishlist

Hi!

On Wed, 2023-11-08 at 19:00:59 +0100, Hugo Melder wrote:
> Package: dpkg-dev
> Version: 1.22.0
> Severity: important

> The recent change (https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf)
> breaks building Debian packages with clang on arm64.

So in principle, the default compiler in Debian is gcc, and the
default flags up to now have been targeting that, plus the specific
gcc version that is the current default. So packages using clang have
had to amend those flags by themselves.

> LLVM does not have
> -fstack-clash-protection enabled on aarch64 (https://reviews.llvm.org/D96007).

Hmm that's unfortunate.

> The GNUstep Objective-C 2.0 toolchain depends on Clang as GCC does not
> have newer Objective-C features such as ARC, properties, and blocks.

Is that being used or packaged in Debian? (Just curious.)

> Fedora enables stack-clash-protection based on the toolchain
> (https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/blob/c0bad810b4b47086f58e7537e258333b14c92c45/f/rpmrc#_77),
> and omits the flag when the compiler is not gcc.
> 
> I would suggest either checking for the compiler (if possible), or
> disabling it for aarch64 until Clang has support for it as well.

Unfortunately I don't think there's a machine readable way to discern
between them, that might not involve either parsing stuff like
--version/--help or pre-processing or compiling a program, which
seem rather undesirable. This would probably need to be specified by
the caller somehow.

I've got some pending discussion in the works for a revamp of the
build flags handling, which includes also trying to cover multiple
toolchains, which would hopefully cover this case. But as it is, I'd
say as of now, packages that use something that is not the default
compiler at the expected version, are on their own.

> Right now, projects like Grand Central Dispatch (libdispatch) or
> other projects with -Werror turned on, refuse to build.

I tried to look for that in Debian and could not find it, do you have
a pointer? But in any case, while I think supporting other toolchains
would be ideal and worthwhile, building packages with blanket -Werror
has always seemed like a bad idea because it then can cause this sort
of thing (or other unexpected errors due to newly introduced warnings).

Thanks,
Guillem

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Vincent Lefevre]

On 2023-11-23 23:44:16 +0100, Hilmar Preuße wrote:
> Sorry, I'm failing to reproduce:
> 
> hille@sid:~$ pdflatex a
> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian)
> (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> (./a.tex
> LaTeX2e <2023-06-01> patch level 1
> L3 programming layer <2023-08-29>
> (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
> Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
> (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
> (/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
> (./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux) 
> ) xmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
> Output written on a.pdf (1 page, 36600 bytes).
> Transcript written on a.log.
> hille@sid:~$ pdftotext a.pdf
> hille@sid:~$ cat a.txt
> x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.
> 
> , which looks good, IMHO. Could you add \listfiles to the top of your
> document and post the logfile here?

zira:~> pdflatex a
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux)

 *File List*
 article.cls2023/05/17 v1.4n Standard LaTeX document class
  size10.clo2023/05/17 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def2023-04-19 L3 backend support: PDF output (pdfTeX)
 ***

 )
Output written on a.pdf (1 page, 34719 bytes).
Transcript written on a.log.
zira:~> pdftotext a.pdf
zira:~> cat a.txt
x0 ; ⊕ ;

; ⊗ ; ` ; OK.


Here's the log file:

This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) 
(preloaded format=pdflatex 2023.11.21)  24 NOV 2023 01:04
entering extended mode
 restricted \write18 enabled.
 %&-line parsing enabled.
**a
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2023/05/17 v1.4n Standard LaTeX file (size option)
)
\c@part=\count185
\c@section=\count186
\c@subsection=\count187
\c@subsubsection=\count188
\c@paragraph=\count189
\c@subparagraph=\count190
\c@figure=\count191
\c@table=\count192
\abovecaptionskip=\skip48
\belowcaptionskip=\skip49
\bibindent=\dimen140
)
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2023-04-19 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count193
\l__pdf_internal_box=\box51
)
(./a.aux)
\openout1 = `a.aux'.

LaTeX Font Info:Checking defaults for OML/cmm/m/it on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for OMS/cmsy/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for OT1/cmr/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for T1/cmr/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for TS1/cmr/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for OMX/cmex/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 4.
LaTeX Font Info:... okay on input line 4.
LaTeX Font Info:External font `cmex10' loaded for size
(Font)  <7> on input line 5.
LaTeX Font Info:External font `cmex10' loaded for size
(Font)  <5> on input line 5.
 [1

{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux)
 ***
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
 ***


 *File List*
 article.cls2023/05/17 v1.4n Standard LaTeX document class
  size10.clo2023/05/17 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def2023-04-19 L3 backend support: PDF output (pdfTeX)
 ***

 ) 
Here is how much of TeX's memory you used:
 428 strings out of 474928
 8156 string characters out of 5762151
 1917791 words of memory out of 500
 22058 multiletter control sequences out of 15000+60
 558069 words of font info for 36 fonts, out of 800 for 9000
 1141 hyphenation exceptions out of 8191
 35i,5n,50p,133b,100s stack positions out of 1i,1000n,2p,20b,20s

Output written on a.pdf (1 page, 34719 bytes).
PDF statistics:
 28 PDF objects out of 1000 (max. 8388607)
 

Bug#976805: Progress?

[Mo Zhou]

Anyone interested in imhex can take this ITP over.

I can co-maintain it, but now I'm really slow on this given that my 
bandwidth is spent on other packages.


On 11/23/23 17:20, Matthias Geiger wrote:

On 23.11.23 21:04, Matthias Geiger wrote:
I just saw that imhex embeds some libaries; do you need any help 
devendoring it ? 


Poking at the source:


lib/third_party:

capstone: in debian, libcapstone-dev
fmt: in debian, libfmt-dev
imgui: in debian, libimgui-dev
jthread: NOT in debian, source is at https://github.com/josuttis/jthread
llvm-demangle: mix of header files, probably can't be excluded
microtar: NOT in debian, a single header from here 
https://github.com/rxi/microtar

miniaudio: in debian, libminiaudio-dev
nativefiledialog: NOT in debian, source is at 
https://github.com/btzy/nativefiledialog-extended

nlohmann_json: in debian, nlohmann-json3-dev
xdgpp: NOT in debian, just a single header from here: 
https://sr.ht/~danyspin97/xdgpp/

yara: in debian, libyara-dev

lib/external:

libromfs: NOT in debian, source is at https://github.com/WerWolv/libromfs
libwolv: NOT in debian, source is at https://github.com/WerWolv/libwolv
pattern_language: NOT in debian, source is at 
https://github.com/WerWolv/PatternLanguage


So that's seven libraries to package from scratch. Certainly doable. I 
could be convinced to package those if someone is willing to 
co-maintain them.


best,

Bug#889722: conflict with apparmor < 2.11.1-4?

[Mathias Gibbens]

Control: tags -1 + moreinfo

  Given the age of this bug, I think it's become a moot point. Any
objections to closing it?

Mathias


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

Bug#1056627: cython3 has an undeclared file conflict

[Helmut Grohne]

Package: cython3
Version: 0.29.36-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + cython3-dbg

cython3 has an undeclared file conflict. This may result in an unpack
error from dpkg.

The files
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/FlowControl.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/FusedNode.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/Scanning.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Compiler/Visitor.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Plex/Actions.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Plex/Scanners.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Runtime/refnanny.cpython-311d-x86_64-linux-gnu.so
 * 
/usr/lib/python3/dist-packages/Cython/Tempita/_tempita.cpython-311d-x86_64-linux-gnu.so
are contained in the packages
 * cython3/0.29.36-2 as present in unstable
 * cython3-dbg
   * 0.29.32-2+b1 as present in bookworm
   * 0.29.36-1 as present in trixie

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1056628: udhcpc: file loss during upgrade due to Multi-Arch: same interacting with /usr-merge

[Helmut Grohne]

Package: udhcpc
Version: 1:1.36.1-6~exp.1
Severity: normal
User: helm...@debian.org
Usertags: dep17p7

Hi Chris,

thanks for sitting down with me and doing this /usr-move. We aimed to be
careful and upload to experimental. Now dumat doesn't like your upload.
I'm trying to figure out why and whether this is an analyzer bug or a
real problem, so please do not move busybox to unstable for the time
bing.

What follows is details that you may skip entirely, but figured I better
write them down for my future self. So dumat figured that udhcpc is
Multi-Arch: same in bookworm and /sbin/udhcpc is a shared file. Then the
experimental package contains /usr/sbin/udhcpc. In theory, this could
result in a loss scenario, because you can install udhcpc for two
architecture in bookworm, dpkg --unpack the experimental one for one
architecture and then dpkg --remove the other. While you can unpack
udhcpc for two architectures, configuring it does not work out, because
it depends on busybox, which happens to implied to be Multi-Arch: no and
apt would never consider a solution where you'd have to coinstall
udhcpc. Also udhcpc was changed to an Architecture: all package later
and that also makes the issue unreproducible. In theory, the detector
should have noticed that the experimental package is not coinstallable
with itself and therefore the alleged problem cannot be exercised.

I think the latter is an analyzer bug and should have prevented the
issue from being displayed. In the mean time, please avoid uploading
this to unstable. I'll either close this bug or upgrade it to rc once I
have a better understanding of what's going on.

Helmut

Bug#980791: Still outstanding - package abandoned?

[Daniel Fancsali]

This has been nagging me for years now - has the package been abandoned 
due to lack of resources?


I also think, this would resolve #774763, #784832 and #783228 too...

Bug#1056626: ttyplot: Please update to ttyplot 1.5.2

[Sebastian Pipping]

Package: ttyplot
Version: 1.4+77.g1a1693b-2
Severity: normal
X-Debbugs-Cc: sebast...@pipping.org

Hi!

ttyplot 1.5.2 has been released upstream by now and contains bugfixes of value
over version 1.4+77.g1a1693b-2.  Would be great to see these fixes in Debian as
well.  Thanks in advance!

Best, Sebastian


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

Kernel: Linux 6.1.0-13-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 ttyplot depends on:
ii  libc62.36-9+deb12u3
ii  libncurses6  6.4-4
ii  libtinfo66.4-4

ttyplot recommends no packages.

ttyplot suggests no packages.

-- no debconf information

Bug#887787: lxc: CentOS 7 amd64 container can't be stopped

[Mathias Gibbens]

Control: tags -1 + moreinfo

Hi Toni,

  Sorry that no one responded to this bug until now. Is this behavior
still happening on a bookworm or sid system? I've just spent some time
testing various containers, including a CentOS 7 one, and they are
properly shutting down, both internally (`shutdown` and `halt`) as well
as via `lxc-stop`.

On Fri, 19 Jan 2018 22:51:13 +0100 Toni Mueller 
wrote:
> Trying to 'lxc-stop -n centos' (name of the container) also does not
> work. [snip] It would be great if lxc could prevent a container
> misbehaving like that.

  `lxc-stop` does have the "--timeout" and "--kill" options which can
be used to force stop a container that doesn't gracefully shutdown.

Mathias


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

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Hilmar Preuße]

On 11/23/23 15:53, Vincent Lefevre wrote:

On 2023-11-23 15:44:17 +0100, Vincent Lefevre wrote:


Hi Vincent,


\documentclass{article}
\pagestyle{empty}
\begin{document}
$x'$ ; $\oplus$ ; $\ominus$ ; $\otimes$ ; $\ell$ ; OK.
\end{document}

I get the following:


x0 ; ⊕ ;

; ⊗ ; ` ; OK.


instead of


x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.



I forgot to say that these are the characters obtained with
pdftotext (the issue is not with the glyphs, but with the
textual part).



Sorry, I'm failing to reproduce:

hille@sid:~$ pdflatex a
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) 
(preloaded format=pdflatex)

 restricted \write18 enabled.
entering extended mode
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] 
(./a.aux) 
)
xmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
Output written on a.pdf (1 page, 36600 bytes).
Transcript written on a.log.
hille@sid:~$ pdftotext a.pdf
hille@sid:~$ cat a.txt
x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.

, which looks good, IMHO. Could you add \listfiles to the top of your 
document and post the logfile here?


Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056625: RM: xhtmlrenderer -- ROM; outdated, unused

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package is obsolete.

No other package is the archive is depending on this.

Bug#1056624: ifup: verbose flag seems to not list all commands ifup dows

[MichaIng]

Package: ifupdown
Version: 0.8.41

On Orange Pi Zero 3, when using ifup to configure the Ethernet adapter, 
after doing a (soft) reboot, the interface is not present anymore. With 
NetworkManager, this is not the case. It is a bug in the vendor kernel 
build/driver for sure, just triggered by something "ifup" does. To debug 
the issue, we run "ifup -v eth0" or "ifup -nv eth0" to print the actual 
iproute2 commands performed and get something like this:


---
ifup: configuring interface eth0=eth0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
/sbin/ip addr add 192.168.1.15/255.255.255.0 broadcast 192.168.1.255 
 dev eth0 label eth0

/sbin/ip link set dev eth0   up
 /sbin/ip route add default via 192.168.1.1  dev eth0 onlink
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
---

When we run those exact commands manually, the interface does not 
disappear on reboot. We tested this several times to rule out randomness 
and tested with/without DHCP/static IP/gateway, and it can be 
consistently replicated that the issue appears as fast as an IP address 
is assigned by "ifup", but not by any of the "ip" commands run 
"run-parts" (we removed all hooks to rule out issues with them as well), 
but by something "ifup" additionally does.


So my question is whether someone has an idea what "ifup" does on top of 
the commands printed by the "verbose" flag, which might bring the 
adapter into a stage, that is not reset correctly on a soft reboot, 
causing the driver to fail?


I hope I derived it correctly that there is no (external) ifupdown 
project/source code, but that this is a Debian internal implementation? 
Else, it would be great if you can give me a hint, so I can ask this at 
the right place.


For reference: https://github.com/orangepi-xunlong/linux-orangepi/issues/54

Best regards,

Micha

Bug#1056623: RM: unsafe-mock -- ROM; unused, outdate

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package was used by JRuby during the transition to JDK >8.
There is no use for this anymore.

Bug#1056622: RM: unsafe-fences -- ROM; unused, obsolete

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package was used by JRuby during the transition to JDK >8.
There is no use for this anymore.

Bug#976805: Progress?

[Matthias Geiger]

On 23.11.23 21:04, Matthias Geiger wrote:
I just saw that imhex embeds some libaries; do you need any help 
devendoring it ? 


Poking at the source:


lib/third_party:

capstone: in debian, libcapstone-dev
fmt: in debian, libfmt-dev
imgui: in debian, libimgui-dev
jthread: NOT in debian, source is at https://github.com/josuttis/jthread
llvm-demangle: mix of header files, probably can't be excluded
microtar: NOT in debian, a single header from here 
https://github.com/rxi/microtar

miniaudio: in debian, libminiaudio-dev
nativefiledialog: NOT in debian, source is at 
https://github.com/btzy/nativefiledialog-extended

nlohmann_json: in debian, nlohmann-json3-dev
xdgpp: NOT in debian, just a single header from here: 
https://sr.ht/~danyspin97/xdgpp/

yara: in debian, libyara-dev

lib/external:

libromfs: NOT in debian, source is at https://github.com/WerWolv/libromfs
libwolv: NOT in debian, source is at https://github.com/WerWolv/libwolv
pattern_language: NOT in debian, source is at 
https://github.com/WerWolv/PatternLanguage


So that's seven libraries to package from scratch. Certainly doable. I 
could be convinced to package those if someone is willing to co-maintain 
them.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056621: reportbug: http://www.crbug.com

[debian user]

Package: reportbug
Version: 12.0.0
Severity: serious
Justification: Please do not redirect bugs to third party sites

Dear Maintainer,

pkg chromium is redirecting bugs through reportbug to http://www.crbug.com
$ apt policy chromium
chromium:
  Installed: 119.0.6045.159-1~deb12u1

I do not appreciate this.

thanks,
bw

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/user/.reportbugrc:
reportbug_version "7.1.7"
mode standard
ui text
email "bwtn...@yahoo.com"
no-cc
smtphost reportbug.debian.org

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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 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 reportbug depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.82
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u2
ii  file   1:5.44-3
ii  gnupg  2.2.40-1.1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#1056620: chromium: EVIL

[debian user]

Package: chromium
Version: 119.0.6045.159-1~deb12u1
Severity: wishlist

Dear Maintainer,

This app is evil.  Eevry 'upgrade' is worse, especially for webmail access.

Users might consider tossing this browser, as a longtime debian user I 
am concerneced I might quickly toss gmail and chromium in the garbage.

I won't try to explain how they are mining personal ino, it's so daMN OBVIOUS.
http://www.crbug.com

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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/8 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 chromium depends on:
ii  chromium-common119.0.6045.159-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u4
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.2+deb12u1
ii  libwebpdemux2  1.2.4-0.2+deb12u1
ii  libwebpmux31.2.4-0.2+deb12u1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backen  5.27.5-2
d]
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.36-9+deb12u3
ii  libjsoncpp25  1.9.5-4
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxnvctrl0   525.85.05-3~deb12u1
ii  x11-utils 7.7+5
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
pn  chromium-sandbox
ii  fonts-liberation

Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: soplex
  Version : 6.0.3
  Upstream Author : Zuse Institute Berlin (ZIB)
* URL : https://github.com/scipopt/soplex
* License : Apache-2, LGPL-2.1+, BSD-3-clause
  Programming Lang: C, C++
  Description : sequential object-oriented simplex solver

This package is part of the SCIP Optimization Suite. SoPlex is an optimization
package for solving linear programming problems (LPs) based on an advanced
implementation of the primal and dual revised simplex algorithm. It provides
special support for the exact solution of LPs with rational input data.

The package will be team-maintained under the umbrella of the
Debian Math Team 
at https://salsa.debian.org/math-team/soplex


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVfzOsACgkQ+C8H+466
LVnexAwAv47byYfXLrXInUiK/H2iFsLMynDDe6RB4eE/kQ0UJmJ769+ZEIU2PPF0
LyHp7SwlJykCrIgmfFI6RFkfpG0Nxk/V3ZmA6jtYr0qEif19062ykIEfkhueCvPY
cr7jLBkYTRWpqOA4Ot9d4dc/ZDzmsWHkKmxD5TbRkppgevxnXsbvbOtPtWeGlOgc
G4FKW3O+YyyXE14vc2hrwsQILO7zmTzDBnlZa4HYCCn+CNhhzfkIXACafM8nXERg
J+MIpJ+e+VQQXwVhIbP1T4XNS20ARyWLBaKkyDRIsa1ieyK95ajZyL7W/v9yRspp
vdoFfCWXVqeqr7rg1qFHYB7cbXY0D+W3zOHzEZgm2DHZc6+Ifc6LsLrvGwrmETKT
L8iBRiOwA+UUu9ENPV20pn3jUYl/SR975wFjZzwezEbJcQ+KCFiYZmPAWQYEoyWC
lI8b7rsw2NO/PBGInJH4vPxUefbhp1MGGIrDQBsUnvaSQHqABj9KZThB+wJzrC0L
NfYRW/iB
=h/nn
-END PGP SIGNATURE-

Bug#986638: lxc: CentOS 7 Container can't be started properly

[Mathias Gibbens]

Control: retitle -1 lxc: CentOS 7 containers require cgroup v1 controller
Control: tags -1 + confirmed wontfix

Hi Michael,

  Sorry that no one responded to this bug until now. The issue you are
seeing is caused by the version of systemd in CentOS 7 expecting a
cgroup v1 controller to be available, which isn't the case in recent
versions of Debian. (Not sure exactly when, maybe starting with the
bullseye release?) As a workaround, you can add
"systemd.unified_cgroup_hierarchy=0" to your host kernel boot
parameters which will switch systemd's cgroup setup from unified to
hybrid. After rebooting, I was able to successfully start a working
CentOS 7 container on my sid machine.

  There's nothing that lxc itself can do about this, so tagging with
wontfix but keeping the bug open for anyone else who might encounter
this issue in the future.

Mathias


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

Bug#1056618: libenet7: missing IPv6 support

[Adrian Friedli]

Package: libenet7
Version: 1.3.17+ds-2
Severity: normal
Tags: ipv6
X-Debbugs-Cc: a...@koalatux.ch

Hi there,

Many games in Debian rely on ENet for networking. Unfortunately ENet
does not support IPv6.

Cheers,
Adi

Bug#1056617: RM: yecht -- ROM; outdated, unused

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

JRuby stopped depending on yecht years ago.
There are no dependencies on this package in the archive.

Bug#1056580: lowering priority

[Matthias Klose]

Control: severity -1 important

lowering priority, technically it's not a regression (new package).

Bug#1056616: firefox: Firefox tab freeze when using BigBlueButton

[Florence Birée]

Package: firefox
Version: 120.0-1
Severity: important
X-Debbugs-Cc: flore...@biree.name

Dear Maintainer,

Since the last update of Firefox in Sid, when I try to use Firefox with
BigBlueButton to do a distant meeting (with microphone and webcam),
the BigBlueButton tab start using 100% of one cpu, and in a minute or
two, freeze. Other tab or the main firefox interface still works well.

I try to run firefox with --safe-mode, and the problem is still there.

The same BigBlueButton instance works very well with the firefox version
just before, and still works well in chromium.

Other websites doesn't have this problem (I quickly tried a jitsi meet
instance with also microphone and webcam, seems to works...)

Thanks for your work to maintain firefox in debian!

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.14
ii  fontconfig   2.14.2-6
ii  libasound2   1.2.10-1
ii  libatk1.0-0  2.50.0-1
ii  libc62.37-12
ii  libcairo-gobject21.18.0-1
ii  libcairo21.18.0-1
ii  libdbus-1-3  1.14.10-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.1-4
ii  libgtk-3-0   3.24.38-6
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.94-1
ii  libpango-1.0-0   1.51.0+ds-3
ii  libstdc++6   13.2.0-6
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  procps   2:4.0.4-2
ii  zlib1g   1:1.3.dfsg-3

Versions of packages firefox recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec60  7:6.1-4

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5
pn  pulseaudio 

-- no debconf information

Bug#1056615: capnproto: CVE-2023-48230: WebSocket message can cause crash

[Salvatore Bonaccorso]

Source: capnproto
Version: 1.0.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for capnproto.

CVE-2023-48230[0]:
| Cap'n Proto is a data interchange format and capability-based RPC
| system. In versions 1.0 and 1.0.1, when using the KJ HTTP library
| with WebSocket compression enabled, a buffer underrun can be caused
| by a remote peer. The underrun always writes a constant value that
| is not attacker-controlled, likely resulting in a crash, enabling a
| remote denial-of-service attack. Most Cap'n Proto and KJ users are
| unlikely to have this functionality enabled and so unlikely to be
| affected. Maintainers suspect only the Cloudflare Workers Runtime is
| affected.  If KJ HTTP is used with WebSocket compression enabled, a
| malicious peer may be able to cause a buffer underrun on a heap-
| allocated buffer. KJ HTTP is an optional library bundled with Cap'n
| Proto, but is not directly used by Cap'n Proto. WebSocket
| compression is disabled by default. It must be enabled via a setting
| passed to the KJ HTTP library via `HttpClientSettings` or
| `HttpServerSettings`. The bytes written out-of-bounds are always a
| specific constant 4-byte string `{ 0x00, 0x00, 0xFF, 0xFF }`.
| Because this string is not controlled by the attacker, maintainers
| believe it is unlikely that remote code execution is possible.
| However, it cannot be ruled out. This functionality first appeared
| in Cap'n Proto 1.0. Previous versions are not affected.  This issue
| is fixed in Cap'n Proto 1.0.1.1.


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-2023-48230
https://www.cve.org/CVERecord?id=CVE-2023-48230
[1] 
https://github.com/capnproto/capnproto/security/advisories/GHSA-r89h-f468-62w3
[2] 
https://github.com/capnproto/capnproto/commit/5d5d734b0350c6f2e36c3155753e6a19fbfeda9a

Regards,
Salvatore

Bug#1056614: RM: tweepy -- ROM; broken, obsolete, associated service doesn't exist anymore

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

This package and all Twitter related packages should be removed from the 
archive.

Twitter API access is broken, so there is no point keeping this in the archive.

Bug#1056595: dgit: must not override dpkg include lists

[Ian Jackson]

Johannes Schauer Marin Rodrigues writes ("Re: Bug#1056595: dgit: must not 
override dpkg include lists"):
> this bug was triggered by julian trying to work on my package sbuild
> in ubuntu.  I usually upload all my packages with "dgit --quilt=gbp
> push-source" and hence the problem julian faces was created.

I'm still not sure what the precise problem is.  Is it that the .dsc
in the Debian archive contains a .gitignore ?

> I'd also have no problem with resolving this particular situation by
> adding an appropriate debian/source/options to sbuild for the next
> upload. Then the same thing would happen independent of whether the
> person building sbuild uses dgit or not.

I think probably that would help.  IIRC there are some strange
interactions between dpkg command line options and d/s/options.
(I can't remember the details offhand.)

dgit does look in d/s/options but mostly to check that there's nothing
there that would make dpkg-source do something that dgit doesn't want.

Maybe some of our documentation (eg, dgit-maint-native(7)) should
recommend creating d/s/options, and maybe dgit ought to check that?

> But would that be future proof as in: will dgit maybe adjust these options in
> the future and if yes, is there something dgit could do to inform me that my
> debian/source/options might be incomplete?

dgit's default behaviour in this area hasn't changed for a very long
time.  It always wants to upload precisely your git tree, and
therefore it must pass dpkg-source options that make it able to
generate such a source package.

I think the only thing that might change is that #908747 might get
fixed, but that also seems unlikely and wouldn't invalidate your
d/s/options anyway.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1056613: twitterwatch: Please remove this package

[MigueL Landaeta]

Package: twitterwatch
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Versions of packages twitterwatch depends on:
ii  python3 3.9.2-3
pn  python3-tweepy  

twitterwatch recommends no packages.

twitterwatch suggests no packages.

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting Ilias Tsitsimpis (2023-11-23 21:10:36)
> On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote:
> > On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:
> > > Quoting John MacFarlane (2023-11-16 19:25:17)
> > > > Removing lua support would be most unfortunate!  If you need help from 
> > > > upstream in getting things to work, let me know.
> > > 
> > > I agree: Pandoc with its core scripting language disabled is a severely
> > > crippled Pandoc.
> > 
> > Understood, but I am not really sure how to move forward, since Pandoc
> > doesn't fully support the latest Stackage LTS. I can help with
> > packaging/upgrade libraries if you can provide the right set of
> > libraries we need.
> 
> I uploaded the following packages:
> 
> * haskell-hslua-cli_v1.3.0-1,
> * haskell-hslua-module-doclayout_v1.1.0-1
> * haskell-hslua-module-zip_v1.1.0-1
> 
> I believe the next step is to update pandoc to 3.0.1, so we can then
> package pandoc-lua-engine, pandoc-server and eventually pandoc-cli.
> 
> Jonas, how can I help move this forward? Pandoc is the last blocker to
> finish the Haskell transition.

I think this will be the best way forward:

Haskell team introduces new source package haskell-pandoc.

When available, I can build package pandoc depending on it.

I really don't like breaking upstream project pandoc into two Debian
source packages like that, but I don't have the energy at the moment to
try fix dh-haskell (which I suspect will be similar work as I am doing
to dh-cargo currently).


 - 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#1056612: retweet: Please remove this package

[MigueL Landaeta]

Package: retweet
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Bug#1056611: db2twitter: Please remove this package

[MigueL Landaeta]

Package: db2twitter
Severity: important

Hi,

I intend to remove tweepy package from the archive since
Twitter service doesn't exist anymore and its API access
is also gone from quite some time, I believe.

Can you remove this package from the archive?

I don't think there is any use left for any Twitter related package
in Debian at this point.


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

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

Versions of packages db2twitter depends on:
ii  python3 3.9.2-3
pn  python3-pil 
pn  python3-sqlalchemy  
pn  python3-tweepy  

db2twitter recommends no packages.

db2twitter suggests no packages.

Bug#1056610: RM: truffle-dsl-processor -- ROM; unused, outdated

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

It should be removed together with truffle.
See https://bugs.debian.org/1056609.

Bug#1056609: RM: truffle -- ROM; unused, outdated

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

This package was never really used for anything,
it was also never updated and as result the current
version in the archive is really outdated.

In its current state, it makes more sense to remove it,
until someone really has a real use and can provide an updated
version.

Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"

[Mihael Pranjić]

I can confirm the packages in testing are working (1.3.8.a+dfsg-1).

Thank you!

Regards
Mihael

Bug#1056608: timeshift: Timeshift cant restore RSYNC snapshots if your system installed on BTRFS with wrong subvolume

[James Morgan]

Package: timeshift
Version: 22.11.2-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: truescore149...@gmail.com

Dear Maintainer,

User cant make BTRFS snapshots without "@" subvolume (debian uses "@rootfs"),
but user can make RSYNC snapshot. The problem is that when you try to restore
that snapshot, you have alert about wrong BTRFS subvolumes, but RSYNC doesnt
need BTRFS subvolumes.

Steps to reproduce :
* Install Debian on BTRFS
* Create a RSYNC (not BTRFS) snapshot
* Try to restore that snapshot

Upstream doesnt have that problem, but I decided to report it because it can
greatly damage the system due to the illusion of security. The user creates a
snapshot thinking that this will save him from serious system errors and
ultimately will not be able to recover.

Thank you for your attention,


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 timeshift depends on:
ii  cron [cron-daemon]   3.0pl1-162
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libvte-2.91-00.70.6-2~deb12u1
ii  libxapp1 2.4.2-3
ii  psmisc   23.6-1
ii  rsync3.2.7-1

timeshift recommends no packages.

timeshift suggests no packages.

-- no debconf information

Bug#947334: lxc-checkpoint needs the criu package

[Mathias Gibbens]

Control: tags -1 + pending

  I think it's reasonable to Suggest criu in the bin:lxc package. If
anyone has a strong opinion that it should rather be a Recommends,
please let me know.

Mathias


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

Bug#1056607: RM: modulator -- ROM; unused, obsolete

[MigueL Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.

There is no use for this package and should be removed from the archive.

Bug#1056576: u-boot: Consider building apple/asahi variant

[Andreas Henriksson]

On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote:
> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote:
> > On 2023-11-23, Andreas Henriksson wrote:
> > > I'm opening this bug report to discuss the potential of building another
> > > u-boot variant in a new binary package from src:u-boot for "Apple
> > > Silicon" machines.
> > 
> > Thanks! I am guessing this class of hardware may represent a much larger
> > community than many other boards already supported in u-boot.

Potentially, although most users interested in running Linux on their
Apple Silicon probably will go with the distro choice that Asahi Linux
project heavily promotes (currently Fedora Asahi Remix).
We also have a long way to go before debian can offer a complete
end-user ready alternative (without third party packages). At the moment
Glanzmann provides a usable installer and his own apt repository which
works as a stop-gap solution for people who want to run "debian", while
we get proper debian in shape. I'm hopefully we'll be able to somehow
provide a smooth upgrade from glanzmann installs to plain debian at
some point in the future.

> > 
> > 
> > > # The overall picture of booting Linux on apple silicon
> > >
> > > A normal users boot procedure would look something like:
> > > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI)
> > > -> generic distro EFI boot managers (grub, systemd-boot, etc)
> > >
> > >
> > > m1n1 stage1 is installed by the Asahi Linux installer.
> > > m1n1 stage2 + u-boot + dtbs are bundled together and installed
> > > as boot.bin on the EFI partition.
> > 
> > From u-boot 2023.10 doc/board/apple/m1.rst:
> > 
> > $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho
> > 
> > So, this suggests to me one has to pick exactly which .dtb to use which
> > is presumably device-specific? Or is there some other process?

I'd like to point out that src:u-boot is only expected to provide
u-boot-nodtb.bin

Creating the macho variant and installing it in the ESP will be done by
`update-m1n1`.
The asahi-fwextract + asahi-scripts packages contains all the
integration glue for kernel, initramfs and bootloader updates.
(Possibly they should also grow triggers for both m1n1 and
u-boot-nodtb.bin to automatically launch update-m1n1.)

Thus which dtbs will be used isn't really a concern from the
src:u-boot maintainer side. However if you want to think about
theoretical license compliance, a possibility would indeed be
to use the dtbs coming out of u-boot project (although in reality
those dtbs are probably the most outdated ones, and atleast at the
moment you'd probably want to use something more up to date for better
hardware support which likely means the dtbs from the asahi kernel
fork).

> > 
> > I am guessing we would not be able to provide all the possible
> > "u-boot.macho" permutations out of the box (unless it is a very small
> > number of variants), but can probably ship all the relevent components
> > as long as they are in debian main. If the .dtb files come from
> > somewhere other than debian main, we would probably have to build it as
> > a contrib package.
> 
> Not really, including multiple dtbs is possible.  In fact the original
> Asahi distribution based on Arch and Asahi Fedora both do that (and use
> the dtbs provided by the kernel package).
> 
> See: https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1#L20
> 
> > 
> > 
> > > m1n1 stage2 is already in debian, see:
> > > https://tracker.debian.org/m1n1
> > 
> > Great!
> > 
> > 
> > > I've looked over the 43 patches and here's my *perception*
> > > of the current status:
> > >
> > > The current upstream apple_m1_defconfig should be usable
> > > for booting (from internal storage) on M1 machines.
> > >
> > > The M2 can possibly boot, but keyboard driver is not yet
> > > upstream - so no interaction with u-boot possible.
> > 
> > Ok, so worst case, there is at least one supported working platform even
> > without patches?
> 
> Indeed, plus some with partial support.
> 
> > 
> > 
> > > Some of the patches updates devicetree files (dts) which are
> > > completely apple-specific and should not have any chance to affect
> > > anything else, but these are also completely unused so does not
> > > neccessarily need to be included.
> > > The asahi tools to update the EFI boot.bin that combines m1n1,
> > > u-boot and dtbs uses the dtbs from the installed kernel, see:
> > > https://tracker.debian.org/asahi-fwextract
> > > https://tracker.debian.org/asahi-scripts
> > 
> > Here is the crux of the question ... can it use the .dtb files from
> > debian main or does it need .dtb files from some sources outside of
> > debian?
> > 
> 
> That really depends on which kernel you are going to use as both
> are developed in tandem.  Since we don't have a working kernel in
> the debian archive most people will use a 3rd party build including
> more up-to-date dtbs.
> I think this will really start to matter once we are nearing a 

Bug#1056595: dgit: must not override dpkg include lists

[Johannes Schauer Marin Rodrigues]

Hi,

On Thu, 23 Nov 2023 19:52:13 +0100 Julian Andres Klode  wrote:
> > I consider dpkg-source's behaviour, of excluding .gitignore by default,
> > to be wrong:
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
> > (You may recall that report, since you commented on it.)
> I see, I consider dpkg's behavior to be the correct one, and if you
> want to override it, do it in debian/source/options, not by passing
> arguments to dpkg.

this bug was triggered by julian trying to work on my package sbuild in ubuntu.
I usually upload all my packages with "dgit --quilt=gbp push-source" and hence
the problem julian faces was created.

I'd also have no problem with resolving this particular situation by adding an
appropriate debian/source/options to sbuild for the next upload. Then the same
thing would happen independent of whether the person building sbuild uses dgit
or not.

But would that be future proof as in: will dgit maybe adjust these options in
the future and if yes, is there something dgit could do to inform me that my
debian/source/options might be incomplete?

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote:
> On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:
> > Quoting John MacFarlane (2023-11-16 19:25:17)
> > > Removing lua support would be most unfortunate!  If you need help from 
> > > upstream in getting things to work, let me know.
> > 
> > I agree: Pandoc with its core scripting language disabled is a severely
> > crippled Pandoc.
> 
> Understood, but I am not really sure how to move forward, since Pandoc
> doesn't fully support the latest Stackage LTS. I can help with
> packaging/upgrade libraries if you can provide the right set of
> libraries we need.

I uploaded the following packages:

* haskell-hslua-cli_v1.3.0-1,
* haskell-hslua-module-doclayout_v1.1.0-1
* haskell-hslua-module-zip_v1.1.0-1

I believe the next step is to update pandoc to 3.0.1, so we can then
package pandoc-lua-engine, pandoc-server and eventually pandoc-cli.

Jonas, how can I help move this forward? Pandoc is the last blocker to
finish the Haskell transition.

-- 
Ilias

Bug#1056606: debian-security-support: mark tor as end-of-life for Debian bullseye

[Salvatore Bonaccorso]

Source: debian-security-support
Version: 1:13+2023.09.27
Severity: normal
X-Debbugs-Cc: car...@debian.org

As announced in DSA 5562-1 security support for 'tor' in bullseye has
been discontinued and people encouraged to upgrade to bookworm to
continue recieving support.

https://lists.debian.org/debian-security-announce/2023/msg00258.html

Regards,
Salvatore

Bug#1053881: tracker-miners: CVE-2023-5557

[Salvatore Bonaccorso]

Hi Jeremy,

On Wed, Nov 22, 2023 at 10:21:47AM -0500, Jeremy Bícha wrote:
> On Fri, Oct 13, 2023 at 9:27 AM Moritz Mühlenhoff  wrote:
> > Source: tracker-miners
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerability was published for tracker-miners.
> >
> > CVE-2023-5557[0]:
> > | A flaw was found in the tracker-miners package. A weakness in the
> > | sandbox allows a maliciously-crafted file to execute code outside
> > | the sandbox if the tracker-extract process has first been
> > | compromised by a separate vulnerability.
> 
> Moritz,
> 
> The architecture build issues were fixed in upstream's 3.4.6 release.
> Do you want to do a bookworm security update for this issue?
> 
> The sandbox in tracker-miners 2.x is significantly different and since
> no upstream patches were provided for it, I do not plan to work on
> fixing this for older Debian releases.

The issue itself is no-dsa for tracker-miners but can you (at per
above at least for bookworm) fix the issue with the upcoming point
releases?

Regards,
Salvatore

Bug#1056549: grantlee5: Is there intention to port the lib to Qt6 ?

[Filippo Rusconi]

On Thu, Nov 23, 2023 at 11:24:39AM +0100, Sune Stolborg Vuorela wrote:

On Thursday, November 23, 2023 10:52:56 AM CET Filippo Rusconi wrote:

include(KDEInstallDirs)
include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE)
include(KDECMakeSettings)
include(KDEGitCommitHooks)


KDEInstallDirs is basicalyl just GNUInstallDirs slightly improved and extended
KDEFrameworkCompilerSettings is just shared setup of c++ standards and default
warnings
KDECMakeSettings is setting a series of cmake policies and such
KDECommitHooks is just setting up git to commit reject certain changes

All of these are are part of extra-cmake-modules and is in general well tested
for cross platform functionality and it makes writing modern c++ and cmake
code simpler and easier.
In general, other than an extra line in your build scripts, shouldn't make
much of a difference.


That seems convincing, I'll test that and when I'm done I'll close the bug.

Thank you!

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Researcher at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#976805: Progress?

[Matthias Geiger]

On 23.11.23 20:51, Matthias Geiger wrote:

On Sun, 31 Jul 2022 22:14:33 -0700 "M. Zhou"  wrote:
> https://salsa.debian.org/pkg-security-team/imhex
> I forgot the current status. In my fuzzy memory there
> are some new dependencies to be packaged.
>
> On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote:
> > Hi. Is this coming along? What needs to happen to get this into the
> > repos? Do you need help?
> >
> > Thanks!
>
>
>

Hi,

any update on this ?

This would be great to have in debian.

best,

I just saw that imhex embeds some libaries; do you need any help 
devendoring it ?


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056120: mariadb-server: debian-start uses obsolate hardcoded /etc/mysql/debian.cnf

[Otto Kekäläinen]

Severity: wishlist
Version 1:10.11.5-3

You are correct in that there are still calls to
'--defaults-file=/etc/mysql/debian.cnf' in the package scripts and
that they have been deprecated.

They are obsolete on new installs. However on old installs that
upgraded from MariaDB 10.x they are still needed. We likely have to
wait for several years before removing those, and additionally there
needs to be scripts that delete/rename the all the legacy
/etc/mysql/debian.cnf files before that.

Bug#976805: Progress?

[Matthias Geiger]

On Sun, 31 Jul 2022 22:14:33 -0700 "M. Zhou"  wrote:
> https://salsa.debian.org/pkg-security-team/imhex
> I forgot the current status. In my fuzzy memory there
> are some new dependencies to be packaged.
>
> On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote:
> > Hi. Is this coming along? What needs to happen to get this into the
> > repos? Do you need help?
> >
> > Thanks!
>
>
>

Hi,

any update on this ?

This would be great to have in debian.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056605: ITP: licenserecon -- Reconcile licenses from debian/copyright against license-check

[Peter Blackman]

Package: wnpp
Severity: wishlist
Owner: Peter 
X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com

* Package name    : licenserecon
  Version : 1.0
  Upstream Contact: Peter Blackman 
* URL : https://salsa.debian.org/PeterB/licenserecon
* License : BSD-2-clause
  Programming Lang: Pascal
  Description : Reconcile debian/copyright licenses against licensecheck 
output

Uses licensecheck to determine file licences and,
 if not 'UNKNOWN', checks them against Dep5 debian/copyright.

Is intended as a partial replacement for license-reconcile (removed in 2019).
I use this package for checking debian/copyright in other packages I maintain.
Will need a sponsor.


From the man page;
===

   lrc

DESCRIPTION
   Lrc parses a valid DEP-5 copyright file and notes the licenses of files in the source tree. Licensecheck is then 
run, and

   the results compared. Differences between licenses in debian/copyright 
and the output of licensecheck are reported.

   It  should  be  run  in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The 
source tree
   should be clean, otherwise results will be contaminated by spurious  reports  on  the  build's  generated  
files.  It  is

   advisable to run lintian first to ensure correct syntax of 
debian/copyright.

   The  results  are indicative only, and not a substitute for manual checking. It is intended to report obvious 
errors. The
   design intends to minimise false positives as much as is practical. However, false positives will occur if  the  
spelling
   of  the  license  short-string  is not identical between the file and debian/copyright. This is quite likely 
with complex

   licensing such as 'and'/'or' constructs and specific exceptions.

   Only files with a copyright header are checked. False negatives may occur  if  licensecheck  cannot  determine  
a file's
   license.  Files  named  copyright, copying, readme etc. are not checked as they often specify the licenses of 
other files

   rather than their own.

EXIT CODES
   0: No differences found
   1: Failure to run (no debian/copyright etc)
   3: License differences found

SAMPLE OUTPUT
   Sample output invoking lrc.

    SUCCESS:
   Parsing Source Tree 
   Running licensecheck 

   No differences found

    DIFFERENCES:
   Parsing Source Tree 
   Running licensecheck 

   d/copyright | licensecheck

   LGPL-2.1+   | GPL-2+   test/src/config/chan.c
   GPL-2+  | public-domain share/lua/int/dummy.lua
   GPL-2+  | LGPL-2.1+ modules/access/sr_common.h

AUTHOR
   Peter Blackman 

SEE ALSO
   licensecheck (1)

2023-11-21 1 lrc(1)
 Manual page lrc(1) line 7/56 (END) (press h for help or q to quit)

Bug#1056604: libcpp-httplib-dev: wrong version number in pkgconfig file

[David James]

Package: libcpp-httplib-dev
Version: 0.14.1+ds-1
Severity: important
X-Debbugs-Cc: davidjamescastor...@proton.me

Dear Maintainer,

If this package is based on upstream v0.14.1 (as the package version 
suggests), then cpp-httplib.pc has the wrong version number (0.14.0). This
prevents it from being linked against by projects expecting that version e.g.
https://github.com/citra-emu/citra


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

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

Versions of packages libcpp-httplib-dev depends on:
ii  libbrotli-dev   1.0.9-2+b6
ii  libcpp-httplib0.14  0.14.1+ds-1
ii  libssl-dev  3.0.11-1
ii  zlib1g-dev  1:1.2.13.dfsg-3

libcpp-httplib-dev recommends no packages.

libcpp-httplib-dev suggests no packages.

-- no debconf information

Bug#1056603: netbase: please add coap(s) to /etc/services

[Adrian Friedli]

Package: netbase
Version: 6.4
Severity: wishlist
X-Debbugs-Cc: a...@koalatux.ch

Dear maintainer,

The Constrained Application Protocol (CoAP) as specified in RFC 7252 is
an emerging protocol used in many IoT applications. In Debian there are
at least two CoAP implementations: libcoap3 and aiocoap. The former is a
C library and the latter is a Python module, while both of them provide
simple command line clients.

IANA assigned the port 5683 to unencrypted CoAP using TCP and UDP and it
assigned the port 5684 to (D)TLS-secured CoAP.

Please add something like the following to /etc/services:

coap5683/tcp  # Constrained Application 
Protocol
coap5683/udp  # Constrained Application 
Protocol
coaps   5684/tcp  # Constrained Application 
Protocol over TLS
coaps   5684/udp  # Constrained Application 
Protocol over DTLS


Cheers,
Adi

Bug#1056576: u-boot: Consider building apple/asahi variant

[Tobias Heider]

On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote:
> On 2023-11-23, Andreas Henriksson wrote:
> > I'm opening this bug report to discuss the potential of building another
> > u-boot variant in a new binary package from src:u-boot for "Apple
> > Silicon" machines.
> 
> Thanks! I am guessing this class of hardware may represent a much larger
> community than many other boards already supported in u-boot.
> 
> 
> > # The overall picture of booting Linux on apple silicon
> >
> > A normal users boot procedure would look something like:
> > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI)
> > -> generic distro EFI boot managers (grub, systemd-boot, etc)
> >
> >
> > m1n1 stage1 is installed by the Asahi Linux installer.
> > m1n1 stage2 + u-boot + dtbs are bundled together and installed
> > as boot.bin on the EFI partition.
> 
> From u-boot 2023.10 doc/board/apple/m1.rst:
> 
> $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho
> 
> So, this suggests to me one has to pick exactly which .dtb to use which
> is presumably device-specific? Or is there some other process?
> 
> I am guessing we would not be able to provide all the possible
> "u-boot.macho" permutations out of the box (unless it is a very small
> number of variants), but can probably ship all the relevent components
> as long as they are in debian main. If the .dtb files come from
> somewhere other than debian main, we would probably have to build it as
> a contrib package.

Not really, including multiple dtbs is possible.  In fact the original
Asahi distribution based on Arch and Asahi Fedora both do that (and use
the dtbs provided by the kernel package).

See: https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1#L20

> 
> 
> > m1n1 stage2 is already in debian, see:
> > https://tracker.debian.org/m1n1
> 
> Great!
> 
> 
> > I've looked over the 43 patches and here's my *perception*
> > of the current status:
> >
> > The current upstream apple_m1_defconfig should be usable
> > for booting (from internal storage) on M1 machines.
> >
> > The M2 can possibly boot, but keyboard driver is not yet
> > upstream - so no interaction with u-boot possible.
> 
> Ok, so worst case, there is at least one supported working platform even
> without patches?

Indeed, plus some with partial support.

> 
> 
> > Some of the patches updates devicetree files (dts) which are
> > completely apple-specific and should not have any chance to affect
> > anything else, but these are also completely unused so does not
> > neccessarily need to be included.
> > The asahi tools to update the EFI boot.bin that combines m1n1,
> > u-boot and dtbs uses the dtbs from the installed kernel, see:
> > https://tracker.debian.org/asahi-fwextract
> > https://tracker.debian.org/asahi-scripts
> 
> Here is the crux of the question ... can it use the .dtb files from
> debian main or does it need .dtb files from some sources outside of
> debian?
> 

That really depends on which kernel you are going to use as both
are developed in tandem.  Since we don't have a working kernel in
the debian archive most people will use a 3rd party build including
more up-to-date dtbs.
I think this will really start to matter once we are nearing a release.

> 
> > # considerations
> >
> > 1/ are we willing to add another binary package to src:u-boot
> >building apple_m1_defconfig?
> 
> I think that makes sense.
> 
> 
> > 2/ should we name the binary package u-boot-apple or -asahi?
> >The existing third-party packages of the asahi fork calls
> >theirs u-boot-asahi.
> 
> I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the
> sunxi community port of allwinner hardware), but with src:u-boot-asashi
> already in NEW, that makes it a more confusing situation.

We can drop the one in new. There is no need to have both.

> 
> 
> > 3/ do we include patches?
> > 3.1/ No patches. If this is the desired path I can volunteer
> >  to test that it boots on my M1 machine. Other machines
> >  should probably be considered unsupported for now,
> >  even though they might have limited usefulness.
> > 3.2/ Minimal set of patches. We identify what we consider
> >  crutial only patches and recruit volunteers to test.
> >  M2 keyboard? USB? etc...
> > 3.3/ All asahi patches. We consider it simpler to just sync all patches
> >  with the asahi fork (even though some are even unused, like the
> >  devicetree patches). We trust the Asahi Linux project in their
> >  quest to upstream all their work and that they will rebase on newer
> >  releases and make our job easy.
> 
> I am inclined towards starting with no patches or a minimal set of
> patches. The asashi folks do seem to generally do a good job of
> upstreaming, so support should improve over time.
> 
> I have been working on getting 2023.10 into unstable, and before too
> long 2024.01~rc variants should land in experimental, presumably with
> more upstreamed patches.

Bug#1056602: RM: rust-boxfnonce -- ROM; Unmaintained upstream, no more rdeps

[James McCoy]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-boxfno...@packages.debian.org
Control: affects -1 + src:rust-boxfnonce

Please remove rust-boxfnonce.  It's unmaintained upstream, as described
in #104.  There are no more reverse dependencies.

Cheers

Bug#1056601: No module named

[Daniel Leidert]

Package: ansible
Version: 7.7.0+dfsg-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When trying to use the community.general.ssh_config module, I receive:

An exception occurred during task execution. To see the full traceback, use
- -vvv. The error was: ModuleNotFoundError: No module named 'paramiko' fatal:
[localhost]: FAILED! => {"changed": false, "msg": "Failed to import the
required Python library (PARAMIKO) on [hostname]'s Python /usr/bin/python3.
Please read the module documentation and install it in the appropriate
location. If the required library is installed, but Ansible is using the wrong
Python interpreter, please consult the documentation on
ansible_python_interpreter"}

Regards, Daniel


- -- 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')
Architecture: amd64 (x86_64)

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

Versions of packages ansible depends on:
ii  ansible-core   2.14.11-2
ii  openssh-client 1:9.4p1-1
ii  python33.11.4-5+b1
ii  python3-distutils  3.11.5-1
ii  python3-dnspython  2.4.2-1
ii  python3-httplib2   0.20.4-3
ii  python3-jinja2 3.1.2-1
ii  python3-netaddr0.8.0-2
ii  python3-yaml   6.0.1-1

Versions of packages ansible recommends:
ii  python3-argcomplete   3.1.4-1
ii  python3-cryptography  38.0.4-4
ii  python3-jmespath  1.0.1-1
ii  python3-kerberos  1.1.14-3.1+b7
ii  python3-libcloud  3.4.1-5
ii  python3-selinux   3.5-1
ii  python3-winrm 0.4.3-1
ii  python3-xmltodict 0.13.0-1

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.09-1+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmVfoxMACgkQS80FZ8KW
0F05SA//efTf36NuG0AAA/KlctZC9MsqhtNHUtlN8lxqeRrMJ4gEqOJtHimwt+3n
iE4ofPaFwU/fYWjKpmDbLoiu7WQ8AlDlgz1Xy3c4xue/KjGi6e5RvUBq70uEOuIq
qErnRFc5yiSRtOEGLeEGpfGsHw0UZrahpGVO9p1DMIWCwbLRaRcohbe1ok7Mlo6f
ynkK00Npvs8cumobsDolbyT7ofZo47NPZFAH3WugGLNsvcuHeCjLsxmpRzDq5UzS
XeaFUEIwRS5rTX6a3e+iKj/HBlIo5Oleorus0Ehyprkgbo9tyMqZEOY/+Cdexhud
VSt3bA/8fprfdOvl0JAftNTM71XwdlppwioO6NLpfQBiYtVzTZ2w3461QbSKzTHs
0rSUFgGYMzEzas54Bvra9ygCyk5hxc6IJVkwC+jX8q3ME07bej3G1PjX78z72RQY
PWCPU92/Oa7shAEwn+Xtd/MMNZEU5wCALql6WGdaVgq9NhT3CYtQNOCwf2M1z27L
SfAoVXVXKGTve8spwZxhI6QGMpD1431IarWVRsFNr3qolk/YgseWWmz27T3rdxQA
Gi97MnqvMPSL48Q7GMzavzZ1u9nqdS+4gmPigtDOjNEi3eh8k3473TXctzJpqi5K
TUSNCCNA74BbblacuNlBdMIyJrNF226ubnM3zwoakpOu2E007So=
=bCRB
-END PGP SIGNATURE-

Bug#1056595: dgit: must not override dpkg include lists

[Julian Andres Klode]

On Thu, Nov 23, 2023 at 05:57:42PM +, Ian Jackson wrote:
> Severity: -1 normal
> 
> Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg 
> include lists"):
> > dgit overrides the include lists for dpkg, causing packages to include
> > additional .gitignore and similar files which dpkg-source -b will
> > exclude.
> 
> Yes.
> 
> This is necessary (1) so that the git trees correspond precisely to
> the .dscs (which is the invariant of the dgit git view), and
> (2) to comply with our promise to provide people with the source code.
> 
> I consider dpkg-source's behaviour, of excluding .gitignore by default,
> to be wrong:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
> (You may recall that report, since you commented on it.)


I see, I consider dpkg's behavior to be the correct one, and if you
want to override it, do it in debian/source/options, not by passing
arguments to dpkg.

> 
> > This creates a significant hurdle to the NMU process and downstream
> > distribution maintainers who have to figure out how to reduce the
> > delta again, because in both cases, unrelated changes should not
> > be present in the diff between the two uploads.
> 
> I'm afraid I don't understand your scenario precisely.  I'm
> sympathetic to the goal of removing hurdles for NMUers and downstream
> maintainers.
> 
> > Like I had to spend about 20 minutes or so today trying to figure out
> > how to actually get that sorted out for a native package (I was trying
> > -i all the time when I should have passed -I), in turn I discovered
> > some other process issues but that's beside the point :D
> 
> Were you trying to use dgit to make an NMU?  If so what git branch
> did you start with?  What options did you give to dgit?


No, I have no intention to ever use dgit. I believe its design is
directly opposed to what I consider the right workflow.

In my case it was not actually an NMU but I was building a prepared
merge downstream in Ubuntu which removed files that were present
in the Debian upload, but it's the same issue NMUers in Debian
face.

If I start with the .dsc, have no intention of ever touching dgit,
I need to manually figure out why files go missing vs the previous
upload and how to make them not disappear.

Like for both NMUs, and downstream work, what we care about is not
"oh rebuild is cleaning out some garbage in the tarball" (normally
we are happy about that), but about maintaining the smallest possible
change to the base version.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1056576: u-boot: Consider building apple/asahi variant

[Vagrant Cascadian]

On 2023-11-23, Andreas Henriksson wrote:
> I'm opening this bug report to discuss the potential of building another
> u-boot variant in a new binary package from src:u-boot for "Apple
> Silicon" machines.

Thanks! I am guessing this class of hardware may represent a much larger
community than many other boards already supported in u-boot.


> # The overall picture of booting Linux on apple silicon
>
> A normal users boot procedure would look something like:
> Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI)
> -> generic distro EFI boot managers (grub, systemd-boot, etc)
>
>
> m1n1 stage1 is installed by the Asahi Linux installer.
> m1n1 stage2 + u-boot + dtbs are bundled together and installed
> as boot.bin on the EFI partition.

From u-boot 2023.10 doc/board/apple/m1.rst:

$ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho

So, this suggests to me one has to pick exactly which .dtb to use which
is presumably device-specific? Or is there some other process?

I am guessing we would not be able to provide all the possible
"u-boot.macho" permutations out of the box (unless it is a very small
number of variants), but can probably ship all the relevent components
as long as they are in debian main. If the .dtb files come from
somewhere other than debian main, we would probably have to build it as
a contrib package.


> m1n1 stage2 is already in debian, see:
> https://tracker.debian.org/m1n1

Great!


> I've looked over the 43 patches and here's my *perception*
> of the current status:
>
> The current upstream apple_m1_defconfig should be usable
> for booting (from internal storage) on M1 machines.
>
> The M2 can possibly boot, but keyboard driver is not yet
> upstream - so no interaction with u-boot possible.

Ok, so worst case, there is at least one supported working platform even
without patches?


> Some of the patches updates devicetree files (dts) which are
> completely apple-specific and should not have any chance to affect
> anything else, but these are also completely unused so does not
> neccessarily need to be included.
> The asahi tools to update the EFI boot.bin that combines m1n1,
> u-boot and dtbs uses the dtbs from the installed kernel, see:
> https://tracker.debian.org/asahi-fwextract
> https://tracker.debian.org/asahi-scripts

Here is the crux of the question ... can it use the .dtb files from
debian main or does it need .dtb files from some sources outside of
debian?


> # considerations
>
> 1/ are we willing to add another binary package to src:u-boot
>building apple_m1_defconfig?

I think that makes sense.


> 2/ should we name the binary package u-boot-apple or -asahi?
>The existing third-party packages of the asahi fork calls
>theirs u-boot-asahi.

I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the
sunxi community port of allwinner hardware), but with src:u-boot-asashi
already in NEW, that makes it a more confusing situation.


> 3/ do we include patches?
> 3.1/ No patches. If this is the desired path I can volunteer
>  to test that it boots on my M1 machine. Other machines
>  should probably be considered unsupported for now,
>  even though they might have limited usefulness.
> 3.2/ Minimal set of patches. We identify what we consider
>  crutial only patches and recruit volunteers to test.
>  M2 keyboard? USB? etc...
> 3.3/ All asahi patches. We consider it simpler to just sync all patches
>  with the asahi fork (even though some are even unused, like the
>  devicetree patches). We trust the Asahi Linux project in their
>  quest to upstream all their work and that they will rebase on newer
>  releases and make our job easy.

I am inclined towards starting with no patches or a minimal set of
patches. The asashi folks do seem to generally do a good job of
upstreaming, so support should improve over time.

I have been working on getting 2023.10 into unstable, and before too
long 2024.01~rc variants should land in experimental, presumably with
more upstreamed patches.


> Debian has a bananas-team that can take responsibility for testing
> and maintaining software, see:
> https://wiki.debian.org/Teams/Bananas

Glad to know!


> Also worth noting is that the asahi fork of u-boot has been uploaded
> and currently sitting in NEW as src:u-boot-asahi.
> https://ftp-master.debian.org/new.html
> As mentioned already on the ITP, I think it's excessive to duplicate all
> of u-boot over 43 patches (and hopefully shrinking):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471

Yes, it does seem a shame to duplicate all of u-boot, although it really
depends on how the upstreaming progress goes.

I can personally tell you reviewing the copyright and licesning
information for a project with 2+ files is... arduous. And it would
be somewhat ridiculous to do that twice.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1056600: Please update adcli to 0.9.2

[Mauricio Oliveira]

package: src:adcli
version: 0.9.1-2
severity: wishlist

Hi Laurent,

If at all possible, could you please update adcli to 0.9.2? (tagged on
Sep 28, 2023)

Thanks,

-- 
Mauricio Faria de Oliveira

Bug#1056599: node-proxy-agents: FTBFS with internet disabled

[Gianfranco Costamagna]

Source: node-proxy-agents
Version: 0~2023071921-1
Severity: serious


Hello, looks like the package tries to do calls to internet during build.
+ jest --testTimeout 5 --env node --moduleDirectories node_modules 
--testRegex test/dnsDomainIs.test.ts test/dnsDomainLevels.test.ts 
test/dnsResolve.test.ts test/isInNet.test.ts test/isPlainHostName.test.ts 
test/isResolvable.test.ts test/localHostOrDomainIs.test.ts 
test/shExpMatch.test.ts test/timeRange.test.ts
PASS test/shExpMatch.test.ts
PASS test/timeRange.test.ts
PASS test/localHostOrDomainIs.test.ts
(node:8627) [DEP0118] DeprecationWarning: The provided hostname "null" is not a 
valid hostname, and is supported in the dns module solely for compatibility.
(Use `node --trace-deprecation ...` to show where the warning was created)
PASS test/isInNet.test.ts
FAIL test/dnsResolve.test.ts
  ● dnsResolve(host) › should return `true` for "www.netscape.com"

assert(received)

Expected value to be equal to:
  true
Received:
  false

  12 |  const res = await dnsResolve(input);
  13 |  if (expected) {
> 14 |   assert(typeof res === 'string');
 |^
  15 |  expect(isIP(res)).toEqual(4);
  16 |  } else {
  17 |  expect(res).toBeNull();

  at test/dnsResolve.test.ts:14:11

PASS test/dnsDomainIs.test.ts
FAIL test/isResolvable.test.ts
  ● isResolvable(host) › should return `true` for "www.netscape.com"

expect(received).toEqual(expected) // deep equality

Expected: true
Received: false

   9 |  async ({ input, expected }) => {
  10 |  const res = await isResolvable(input);
> 11 |   expect(res).toEqual(expected);
 |  ^
  12 |  }
  13 |  );
  14 | });

  at test/isResolvable.test.ts:11:16

PASS test/isPlainHostName.test.ts
PASS test/dnsDomainLevels.test.ts

Test Suites: 2 failed, 7 passed, 9 total
Tests:   2 failed, 37 passed, 39 total
Snapshots:   0 total
Time:4.549 s
Ran all test suites.
dh_auto_test: error: cd ./packages/pac-resolver && sh -ex 
../../debian/nodejs/packages/pac-resolver/test returned exit code 1
make: *** [debian/rules:10: binary] Error 25


Gianfranco


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode

[Nicholas D Steeves]

Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] 
[Team] -- Emacs major mode for editing scala source code

Xiyue Deng  writes:

[snip]
>[ Xiyue Deng ]
>* Sync to latest upstream head (5d7cf21).

Have you asked upstream to tag a release?

>* Override clean rules in d/rules to fix building. (Closes:
>#1052917)

I believe you already know that

override_dh_auto_clean:
   /bin/true

is an incorrect approach.

>* Modernize d/watch using special substitute strings.

Ok, but why?

>* Add more metadata in d/upstream/metadata.

https://github.com/hvesalai/emacs-scala-mode/commits/master

is a git history log, not a changelog nor release notes.

>* Update year and Upstream-Contact and add myself in d/copyright.

Why did you add yourself?
https://en.wikipedia.org/wiki/Threshold_of_originality

I'm happy to support your claim, but you'll need to work for it in more
than a "sweat of the brow"/mechanical sense.

>* Use xz compression in d/gbp.conf.

Why is this useful when it has been the default since gbp 0.9.15?


Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1056348: FTBFS: tests fail in clean environment

[Nicolas Mora]

Le 2023-11-23 à 11 h 20, Steve McIntyre a écrit :


AFAICS in a non-interactive environment, USER isn't required to be set
but LOGNAME is; see

   https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Alternatively, the tets should probably be calling get(e)uid and
getpwent() rather than relying on the environment here.



Indeed, I also had the same conclusion using other documentation.

But then, if LOGNAME is mandatory, I suppose it would be better to use 
$LOGNAME alone instead of the condition.


(I'm not refusing your patch, I just try to see if there's a better and 
cleaner way to fix it)


I'll open a bug upstream to get their feedback on this

/Nicolas

Bug#1056598: librust-trust-dns-resolver-dev: impossible to build with feature dns-over-https-rustls

[Jonas Smedegaard]

Package: librust-trust-dns-resolver-dev
Version: 0.22.0-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Building with feature "dns-over-https-rustls" fails like this:

error[E0433]: failed to resolve: use of undeclared crate or module 
`rustls_native_certs`
  --> 
/build/sccache-0.7.3/debian/cargo_registry/trust-dns-resolver-0.22.0/src/tls/dns_over_rustls.rs:31:21
   |
31 | for cert in rustls_native_certs::load_native_certs().expect("could 
not load platform certs") {
   | ^^^ use of undeclared crate or module 
`rustls_native_certs`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `trust-dns-resolver` due to previous error

The package contains patch use-native-certs.patch which changes feature
"dns-over-rustls" to stop trigger feature (and implicit package
dependency) "webpki-roots".

When not simply removing that, but instead triggering feature/crate
"rustls-native-certs", the build succeeds.

Please adjust the patch accordingly.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVfmZsACgkQLHwxRsGg
ASEazhAArEahifiW09+ZyjgV4Zn7FOJLS0hgatbKv724mtszJ5W2SMm6BqzO4aM5
mNmAvU6WaA5BTzDu5resNt8P6BQ+9gAnE6qeiFyvIJz8g7CdYVeXXxnXR0Gw9Uqt
UYGBCKzKgC0tzgXsT/259hKswWL0myTY/KM9y+JPdnEf0ycLLj/utRn4XqLMcYQz
CCjU+g8lsIgjCYi3lz+QAV9+A45f8NJrz+kYkg5l3dLNLLunKYiV+uCq2YwtL4s2
nR/Zxoj3uodY06axhX3LRyEXWQGDZzy2RMmo5RXhUkKHaUHCLFrW/S2PeuX3w5pK
hg/Bt26JsEk1smRvi4Kw2RaNBio7BgONfv+5if9qM5m83Q/ifOQiJcDEY5kItnAN
T/RsE/1rYPl1Rm8YxBxp59NVJqZJXZl8rMgJZUV7whG+0MWeLIr4AbpXyNC/B/Jk
u7JtbTOHP1fBTekMcCWorcUMLIGaiEoNfGbyz0zaEx2GFL8mm3mUPZeM8OmNFVIz
/ROv0Gs4TxQ/99+EN9JiBJBzrMpOsYFBxWy/ZMJ0MRE9uPRhcC24QrIF3Akb32LB
4qNBYGcsybaaSDv140BOMPMPa+HDr9yc4CTW4AdiN5JhE02n4Ll+aDPKuGnxGf6T
Rq+1nDUuLybt0Sa1dJ2JrGN6EWdckJPzx+rvnRUiQPGzoH4jHTg=
=HRXm
-END PGP SIGNATURE-

Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators

[Otto Kekäläinen]

> > One more clarifying question:
> >
> > > > Thus a third thing the README could advise on is how Debian Developers 
> > > > and
> > > > Debian sysadmins are advised to build CI systems and test upgrade paths 
> > > > for
> > > > the next 10 years as what worked in the past 10 years does not apply 
> > > > as-is
> > > > anymore.
> > > People using CI systems will get an updated debootstrap in the next
> > > point release and everything will be fine.
> >
> > Do you refer above to the next Bookworm point update (scheduled on Dec
> > 9th according to https://release.debian.org/) or do you mean in
> > general that all CI upgrades tests will start working after the next
> > point release of both Bookworm and Bullseye and Buster?
> >
> > I am currently struggling to grasp how I should get for example
> > MariaDB 10.5 / Buster to MariaDB 10.11 / Bookworm testing running
> > again as usrmerge 38 removed the workaround the CI was relying on.
> > Example of current CI run:
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/4945062.
> > Are you saying that a point release of Buster is going to do something
> > that CI systems can continue to operate?
>
> Just create the chroot for the CI with --merged-usr and all will be
> fine. Debootstrap in Buster is not going to be updated to do it
> automatically, only in Bookworm/Bullseye.

Thanks Luca for clarification. So seems we need to get bookworm
removed from 
https://github.com/debuerreotype/debuerreotype/blob/60b625d1ce31bd81525bb67fc3a33f9686bc3433/examples/debian.sh#L183
so that the 'debuerreotype' will run debootstrap for both bookworm and
bullseye with '--usr-merged'. Once that is done, we need to wait for
to the code in 
https://github.com/debuerreotype/docker-debian-artifacts/tree/dist-amd64
to run to generate new images of official Debian Docker images at
https://hub.docker.com/_/debian.

This will fix upgrade testing from Bullseye to Bookworm if I
understood correctly.

Later the same needs to be done for other Debian derivatives as well
(see 
https://github.com/search?q=repo%3Adebuerreotype%2Fdebuerreotype%20merged-usr=code).
For that to be done somebody first needs to research what version of
each derivative adopted usrmerge version 38, and for Ubuntu and others
that carry patches we need to have researched and documented if those
patches are material and change the distro release versions when
usrmerge is forced or workaround (of usrmerge 38) is removed.

And the usrmerge README should definitely be extended to be very clear
about that globally everyone who administers Debian systems and have
any kind of CI system to test upgrades no longer can do it for Buster
to Bookworm tests. While Debian policy always has stated that jumping
releases is not possible, it has in practice been possible and now
with usrmerge 38 that expectation has a hard reset.

Bug#1056595: dgit: must not override dpkg include lists

[Ian Jackson]

Severity: -1 normal

Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg include 
lists"):
> dgit overrides the include lists for dpkg, causing packages to include
> additional .gitignore and similar files which dpkg-source -b will
> exclude.

Yes.

This is necessary (1) so that the git trees correspond precisely to
the .dscs (which is the invariant of the dgit git view), and
(2) to comply with our promise to provide people with the source code.

I consider dpkg-source's behaviour, of excluding .gitignore by default,
to be wrong:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
(You may recall that report, since you commented on it.)

> This creates a significant hurdle to the NMU process and downstream
> distribution maintainers who have to figure out how to reduce the
> delta again, because in both cases, unrelated changes should not
> be present in the diff between the two uploads.

I'm afraid I don't understand your scenario precisely.  I'm
sympathetic to the goal of removing hurdles for NMUers and downstream
maintainers.

> Like I had to spend about 20 minutes or so today trying to figure out
> how to actually get that sorted out for a native package (I was trying
> -i all the time when I should have passed -I), in turn I discovered
> some other process issues but that's beside the point :D

Were you trying to use dgit to make an NMU?  If so what git branch
did you start with?  What options did you give to dgit?

Or, are you the maintainer?  In which case, I'd like to know more
about what went wrong.  Did some NMUer using dgit make an upload that
is causing you trouble?

As background:

I generally recommend that someone doing an NMU which they intend to
upload with dgit, also obtain their baseline package with dgit.  Eg,
see
  https://manpages.debian.org/bookworm/dgit/dgit-nmu-simple.7.en.html
I recommend that users should *not* use the semi-official Debian git
sources because they're not suitable for non-Debian-experts:
  https://diziet.dreamwidth.org/9556.html

Of course if - like you do - you know what you're doing, then you can
start from (eg) a salsa branch.  But then I'm afraid that this problem
with .gitignore may be just another one of the strange Debian things
that you have to know.

Even so, I'm open to ideas of ways to make this wrinkle less annoying.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1056597: ffmpeg: drawtext filter missing from ffmpeg binaries

[Slim Joe]

Package: ffmpeg
Version: 7:6.1-4
Severity: normal

Dear Maintainer,

The FFmpeg binaries (i.e. ffplay and ffmpeg) no longer
provides the drawtext filter, useful for embedding text (such
as subtitles and time codes) into a video.

Here's a simple test command using a legally available video.

$ ffplay -i 
https://static.fsf.org/nosvn/videos/escape-to-freedom/videos/escape-to-freedom-720p.webm
 -vf "drawtext=x=20:y=20:fontsize=24:fontcolor=gold:text='%{localtime \: %T 
%Z%n(%F)}'"

The relevant portion of stderr from this command is this:

[AVFilterGraph @ 0x7f6ae4003e40] No such filter: 'drawtext'
[AVFilterGraph @ 0x7f6ae4003e40] Error processing filtergraph: Filter not found

A shallow search for a similar bug turns up the following link
from the ArchLinux bug tracker ("drawtext filter not available",
dated "Wednesday, 22 November 2023, 15:17 GMT"):

https://bugs.archlinux.org/task/80327

The recommended solution is to recompile FFmpeg with the
"--enable-libharfbuzz" option. There is a libharfbuzz-dev
package in Debian, so this should not be a problem (assuming
the ArchLinux bug report is correct).

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

Versions of packages ffmpeg depends on:
ii  libavcodec607:6.1-3
ii  libavdevice60   7:6.1-3
ii  libavfilter97:6.1-3
ii  libavformat60   7:6.1-3
ii  libavutil58 7:6.1-3
ii  libc6   2.37-12
ii  libpostproc57   7:6.1-3
ii  libsdl2-2.0-0   2.28.5+dfsg-2
ii  libswresample4  7:6.1-3
ii  libswscale7 7:6.1-3

Bug#1056596: lintian could check if source is NMUable / doesn't cause delta due to non-standard dpkg source options

[Julian Andres Klode]

Package: lintian
Severity: wishlist
X-Debbugs-Cc: j...@debian.org

In Bug##1056595 I outlined how dgit overrides dpkg filters
and files like .gitignore appear in tarballs, meaning that
if you download the .dsc and try to NMU it, your NMU suddenly
misses a lot of files.

lintian should check that dpkg-source -x && dpkg-source -b
does not

* add additional files
* remove files
* modify files

Arguably it may be reasonable to parse the Perl bindings
in dpkg to get the ignore list and just check that we don't
ship any ignored files.

Likewise it can ensure that other options like compression of
the tarball matches the dpkg options for that package,
i.e. archive defaults or debian/source/options.

Maybe this is better solved in something like piuparts,
I don't know.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1049995: openssh: catalan translation [INTL:ca]

[Colin Watson]

On Fri, Aug 18, 2023 at 04:37:50AM +0200, Pablo Huguet wrote:
> I did the catalan translation of it, and I will add the translation is 
> included
> thanks for reading!

Hi,

Thanks for the translation!  However, it contains syntax errors:

  $ msgmerge -U debian/po/ca.po debian/po/templates.pot
  debian/po/ca.po:41:59: syntax error
  debian/po/ca.po:57:27: syntax error
  msgmerge: found 2 fatal errors

Could you please fix these?

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

Bug#1056595: dgit: must not override dpkg include lists

[Julian Andres Klode]

Package: dgit
Severity: important
X-Debbugs-Cc: j...@debian.org

dgit overrides the include lists for dpkg, causing packages to include
additional .gitignore and similar files which dpkg-source -b will
exclude.

This creates a significant hurdle to the NMU process and downstream
distribution maintainers who have to figure out how to reduce the
delta again, because in both cases, unrelated changes should not
be present in the diff between the two uploads.

Like I had to spend about 20 minutes or so today trying to figure out
how to actually get that sorted out for a native package (I was trying
-i all the time when I should have passed -I), in turn I discovered
some other process issues but that's beside the point :D

-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (500, 'mantic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-10-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 dgit depends on:
ii  apt2.7.6
ii  ca-certificates20230311ubuntu1
ii  coreutils  9.1-1ubuntu2
ii  curl   8.4.0-2ubuntu1
ii  devscripts 2.23.6build1
ii  dpkg-dev   1.22.1ubuntu2
ii  dput   1.1.3ubuntu3
ii  git [git-core] 1:2.40.1-1ubuntu1
ii  git-buildpackage   0.9.32
ii  libdpkg-perl   1.22.1ubuntu2
ii  libjson-perl   4.1-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-6
ii  libtext-csv-perl   2.03-1
ii  libtext-glob-perl  0.11-3
ii  libtext-iconv-perl 1.7-8
pn  libwww-curl-perl   
ii  perl [libdigest-sha-perl]  5.36.0-9ubuntu1

Versions of packages dgit recommends:
ii  distro-info-data 0.59
ii  liburi-perl  5.21-1
ii  openssh-client [ssh-client]  1:9.4p1-1ubuntu1

Versions of packages dgit suggests:
ii  cowbuilder  0.89
ii  pbuilder0.231build1
ii  sbuild  0.85.2ubuntu1

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1030895: qt6-webengine: Enable riscv64 support

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On 21/11/23 06:06, Bo YU wrote:
[snip]

Let's start here again, okay? :)

I just refactor these patches, which should not affect building of 
other architectures except riscv64.


And still we have a 14k+ lines debdiff to apply. My apologies, this is a 
huge NACK. Get it supported by upstream first and then we can talk.

Bug#1056321: elogind conflicts with same version libelogind

[Low Salt Popcorn]

Wouldn't it be better, or at least more elegant, to turn
libelogind0 into a dummy transitional package that pulls in
libsystemd0? Here's the result of trying to install elogind
using the apt front end.

$ sudo apt install -t testing elogind
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apt : Depends: libapt-pkg6.0 (>= 2.7.6) but it is not going to be 
installed

 elogind : Depends: dbus (>= 1.9.14)
   Conflicts: libelogind0 but 246.10-1debian1 is to be installed
   Recommends: polkitd
# [etc]

I must note that the aptitude frontend is able to install
elogind using the default solution No. 1.

$ sudo aptitude install -t testing elogind
# [etc]
 Install the following packages:
1) libsystemd0 [254.5-1 (testing)]

Accept this solution? [Y/n/q/?]

On the other hand, an "apt full-upgrade" will automatically
remove elogind and replace it with systemd, which is NOT what
a user that's installed elogind would want. (An "apt upgrade"
will abort with an "unmet dependencies" conflict.)

Bug#992180: MR with fix available Re: openmm FTBFS on amd64/arm64/ppc64el

[Michael R. Crusoe]

On Sun, 15 Aug 2021 12:11:53 +0300 Adrian Bunk  wrote:
> Source: openmm
> Version: 7.5.1+dfsg-1
> Severity: important
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=openmm=sid
>
> ...
> 
/<>/openmmapi/include/openmm/internal/vectorize_sse.h:38:10: 
fatal error: smmintrin.h: No such file or directory

> 38 | #include 
> | ^
> compilation terminated.
> make[4]: *** 
[platforms/cpu/sharedTarget/CMakeFiles/OpenMMCPU.dir/build.make:98: 
platforms/cpu/sharedTarget/CMakeFiles/OpenMMCPU.dir/__/src/CpuCustomGBForce.cpp.o] 
Error 1

>
>
> Nice to have would be a vectorize_generic.h (or using simde),
> not sure whether upstream would be interested in doing that.

Hello, I opened the merge request below to add SIMDe to this package; I 
tested on the riscv64 porterbox where the build succeeded, included 
tests. Likewise on my personal amd64 laptop.


https://salsa.debian.org/debichem-team/openmm/-/merge_requests/1

It won't fix the FTBFS on armel / armhf; that's due to them being 
detected as arm64 and inappropriate NEON intrinsics being used



--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056576: u-boot: Consider building apple/asahi variant

[Tobias Heider]

On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote:
> Source: u-boot
> Version: 2023.07+dfsg-1
> Severity: wishlist
> X-Debbugs-CC: Tobias Heider , Andreas Henriksson 
> 
> 
> Dear Maintainer,
> 
> I'm opening this bug report to discuss the potential of building another
> u-boot variant in a new binary package from src:u-boot for "Apple
> Silicon" machines.
> 
> The Asahi Linux project has been working on bringing Linux to the newer
> ARM based line of laptops and stationary (mac mini) by Apple, a.k.a.
> M1, M2 and just released generation M3.
> 
> 
> # The overall picture of booting Linux on apple silicon
> 
> A normal users boot procedure would look something like:
> Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI)
> -> generic distro EFI boot managers (grub, systemd-boot, etc)
> 
> 
> m1n1 stage1 is installed by the Asahi Linux installer.
> m1n1 stage2 + u-boot + dtbs are bundled together and installed
> as boot.bin on the EFI partition.
> 
> Apple/macOS does not make use of EFI. The purpose of u-boot is to
> provide the EFI environment to allow "generic distro boot".
> 
> m1n1 stage2 is already in debian, see:
> https://tracker.debian.org/m1n1
> 
> 
> # Upstream status
> 
> The Asahi Linux project has already upstreamed most of their work
> so simply building `apple_m1_defconfig` is already possible.
> However they also maintain their own fork of it at:
> https://github.com/AsahiLinux/u-boot/tree/asahi-releng
> This fork currently contains 43 additional patches
> (some already upstreamed, some posted for review, some
> simply defconfig changes, some dts updates, etc).
> 
> I've looked over the 43 patches and here's my *perception*
> of the current status:
> 
> The current upstream apple_m1_defconfig should be usable
> for booting (from internal storage) on M1 machines.
> 
> The M2 can possibly boot, but keyboard driver is not yet
> upstream - so no interaction with u-boot possible.
> 
> M3 is not yet supported at all by Asahi Linux (the usual notice of
> expect atleast 6 months before this happens has been announced).
> 
> 
> Notable here is that Apple iBoot does not support USB booting,
> so booting from external media will have to be happening with
> the help of U-Boot. Unfortunately U-Boot USB support has a number of
> as I understand it generic bugs that pretty much prevents real-world
> usage, eg. not support >2TB usb drives, etc.
> Patches to fix these problems has been posted for review (with mostly
> positive feedback):
> https://lists.denx.de/pipermail/u-boot/2023-October/535517.html
> https://lists.denx.de/pipermail/u-boot/2023-October/535529.html
> https://lists.denx.de/pipermail/u-boot/2023-October/535534.html
> https://lists.denx.de/pipermail/u-boot/2023-October/535535.html
> 
> This is the bulk of the code changes outside apple specific files
> in the current 43 patch series living in asahi fork of u-boot.
> 
> There was previously also an attempt to upstream the Apple Type-C PHY
> dummy driver:
> https://lists.denx.de/pipermail/u-boot/2023-July/522961.html
> 
> 
> Some of the patches updates devicetree files (dts) which are
> completely apple-specific and should not have any chance to affect
> anything else, but these are also completely unused so does not
> neccessarily need to be included.
> The asahi tools to update the EFI boot.bin that combines m1n1,
> u-boot and dtbs uses the dtbs from the installed kernel, see:
> https://tracker.debian.org/asahi-fwextract
> https://tracker.debian.org/asahi-scripts
> 
> 
> 
> 
> # considerations
> 
> 1/ are we willing to add another binary package to src:u-boot
>building apple_m1_defconfig?
> 
> 2/ should we name the binary package u-boot-apple or -asahi?
>The existing third-party packages of the asahi fork calls
>theirs u-boot-asahi.
> 
> 3/ do we include patches?
> 3.1/ No patches. If this is the desired path I can volunteer
>  to test that it boots on my M1 machine. Other machines
>  should probably be considered unsupported for now,
>  even though they might have limited usefulness.
> 3.2/ Minimal set of patches. We identify what we consider
>  crutial only patches and recruit volunteers to test.
>  M2 keyboard? USB? etc...
> 3.3/ All asahi patches. We consider it simpler to just sync all patches
>  with the asahi fork (even though some are even unused, like the
>  devicetree patches). We trust the Asahi Linux project in their
>  quest to upstream all their work and that they will rebase on newer
>  releases and make our job easy.

Thank you for the detailed write-up!

I think you are right, a new binary package based on the existing u-boot
is certainly preferable over having a separate source package.
It also looks like there is progress in getting the changes merged upstream.

My preferred choices would be 1/ yes, 2/ u-boot-asahi and 3.2/ because keyboard
support in u-boot actually is important to boot usb disks if you break your
system and that patch shouldn't be 

Bug#1056594: mat2: test failure

[gregor herrmann]

Source: mat2
Version: 0.13.4-2
Severity: serious
Tags: upstream patch ftbfs
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Currently mat2's test suite fails, maybe due to newer libimage-exiftool-perl
releases. This can be seen on ci.debian.net, but the same failures
occur during the build tests, so the package FTBFS.

I've locally added upstream commit
https://0xacab.org/jvoisin/mat2/-/commit/bbd5b2817c9d64013e2f5ed670aca8d4738bb484
as a quilt patch, and the tests pass both during build and
autopkgtest.


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmVfhfFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbGDw/+IvB5zN2PAQj7XFfbyVvqdjr3JIp7krnucMzO+qBemoFW2BdVptGFawgD
XrEn2nj5XtKmG3EKLnqKjevLLeAcgFILEviUa0U1tM+/2pJkHiFC7J3eK5x8ug+9
JRjLVEh3WpG3vdBbvsOQ52B7xurqahfU9ReqR8Awnd/dQUXYycWgei/CUC320KRS
bfuRPcbsR+ibwspLD+3iw8oezikr/WCzXyYjffASJYQDyp7D+LOpHGVfHfFYAVt0
xJby75cKpq0AcMC2Rgg8JYYK0GJ/RJ4a8jptXohl8hcEA8w6htYxUiedA0eaikS3
9t9o2/7yZObpd3TYmpuoGRz00cpQ3bEYATZlYALs1umoCp9WsOjJ8by8tnHKZxUa
7jOfdRhTRF0rkwZ07LoneMFg966HaDTAQeN0TMHKLYvShY7hyVFNf+1AD02qqP8x
+guJ2YQw7U5mu4aEJtNvUXv1Pqh8Hl9hbiQNn23yL8IoCvfDzZUAqaEzRmLYjVt2
Ujoj6LHZgOZsBprIEBMch86MgyL65CeCzJr6JZ8wZmb/b//rPcVAv/VElTs+GfzS
Ka8qQygGzvulrIsA2t0loJG7QtwRcZk6ckaCq/2IVvgDpFf4UCIOGnAt2qtt0+Ak
Xy9Wb0YgnrY0v7BeTMZ+XU5LzWHqWLmj1d3PDvmy+sp9elbUgRU=
=mYNd
-END PGP SIGNATURE-

Bug#864824: claws-mail: If i have 2 mailbox, Claws-Mail always put my sent messages in the first one.

[Paul]

On Thu, 23 Nov 2023 14:58:08 +0100
Marco Moock  wrote: 

> This is something that looks like a general bug in Claws (if it still
> occurs in current Claws version) and should be discussed in
> us...@lists.claws-mail.org mailing list or reported in the bugtracker:
> https://www.thewildbeast.co.uk/claws-mail/bugzilla/index.cgi

This is looking like user-error to me.

with regards

Paul

Bug#1056593: transmission-remote-gtk: upstrean LOCALEDIR envvar bug avoids loading locale file

[Sylvain CANOINE]

Package: transmission-remote-gtk
Version: 1.5.1-1
Severity: normal
Tags: l10n upstream
X-Debbugs-Cc: cano...@9online.fr

Dear Maintainer,

The current version has a bug which prevents loading the appropriate
locale file, so transmission-remote-gtk isn't translated for 
non-english-speaking users.

Upstream fixed this bug in the 1.6.0 version with the following commit :
https://github.com/transmission-remote-gtk/transmission-remote-gtk/commit/af7d3d78388da19b691d8773adaa0d5cd7c1b456

Please consider adding this commit to the current package.



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

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

Versions of packages transmission-remote-gtk depends on:
ii  libc62.36-9+deb12u3
ii  libcurl4 7.88.1-10+deb12u4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgeoip11.6.12-10
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libproxy1v5  0.4.18-1.2

transmission-remote-gtk recommends no packages.

transmission-remote-gtk suggests no packages.

Bug#1056592: debos: yaml: line X: did not find expected key

[Christopher Obbard]

Hi Arnaud,

On Thu, 2023-11-23 at 23:23 +0700, Arnaud Rebillout wrote:
> Package: debos
> Version: 1.1.2-2
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Hi Christopher,
> 
> Here's a surprising bug report. The version of debos currently in Debian
> unstable is a bit broken, in an odd way.
> 
> Consider the following recipe:
> 
> ```
> $ cat main.yaml
> {{ $ospack := or .ospack "debian" }}
> architecture: amd64
> actions:
>   - action: debootstrap
>     suite: sid
>   - action: pack
>     file: {{ $ospack }}.tar.gz
> ```
> 
> If I run with `-t ospack:debian` it fails:
> 
> ```
> $ debos --print-recipe -t ospack:debian main.yaml
> 2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:05:27
> architecture: amd64
> actions:
>   - action: debootstrap
>     suite: sid
>   - action: pack
>     file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos --template-var
> 'ospack:"debian"' /home/user/debos/main.yaml using kvm backend
> 2023/11/23 16:05:31 yaml: line 6: did not find expected key
> ```


For me with debos 1.1.2-2, I seem to reproduce your issue:

  Running /debos --artifactdir debos-tests --template-var 'ospack:"debian"'
debos-tests/test-key.yaml using kvm backend
  2023/11/23 16:41:30 yaml: line 7: did not find expected key



But with a local checkout of debos upstream built with `go build`, your recipe
runs just fine (notice there are now no single-quotes around the --template-
var argument to the inner debos call):

  Running /debos --artifactdir debos-tests --template-var ospack:debdfsa
debos-tests/test-key.yaml using kvm backend
  2023/11/23 16:41:46  debootstrap 


I think this has something to do with the recent shell escaping patches.
Perhaps there is some go module which isn't up to date in Debian causing the
additional single quotation marks around the inner debos call ?





> However if I run without `-t`, it succeeds:
> 
> ```
> $ debos --print-recipe main.yaml
> 2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:10:55
> architecture: amd64
> actions:
>   - action: debootstrap
>     suite: sid
>   - action: pack
>     file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml
> using kvm backend
> 2023/11/23 16:10:59  debootstrap 
> 2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
> 2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
> [...]
> ```
> 
> Another surprise: this is a regression introduced by package 1.1.2-2. If
> I downgrade to version 1.1.2-1, everything works fine.
> 
> ```
> sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
> ```
> 
> I compared the Built-Using fields between both packages:
> 
> ```
> -golang-1.21 (= 1.21.1-1)
> +golang-1.21 (= 1.21.4-1)
> +golang-github-alessio-shellescape (= 1.4.1-3)
>  golang-github-cespare-xxhash (= 2.1.1-2)
>  golang-github-docker-go-units (= 0.4.0-4)
> -golang-github-go-debos-fakemachine (= 0.0.6-1)
> +golang-github-go-debos-fakemachine (= 0.0.7-1)
>  golang-github-google-uuid (= 1.3.0-1)
> -golang-github-klauspost-compress (= 1.15.12+ds1-3)
> +golang-github-klauspost-compress (= 1.17.2+ds1-1)
>  golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
>  golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
>  golang-github-ulikunitz-xz (= 0.5.6-2)
>  golang-go-flags (= 1.4.0-6)
> -golang-golang-x-sys (= 0.9.0-1)
> +golang-golang-x-sys (= 0.13.0-1)
>  golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
>  golang-yaml.v2 (= 2.4.0-4)
> ```
> 
> I suppose the regression was introduced by one of the dependencies that
> changed. I have no idea how to troubleshot that... Tomorrow I'll try to
> rebuild a package to see if that magically fixes it.
> 
> Can you try to reproduce this issue on your side, just to confirm?
> 
> Thanks in advance,
> 
> Arnaud
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-4-amd64 (SMP w/8 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 debos depends on:
> ii  busybox    1:1.36.1-4
> ii  debootstrap    1.0.133
> ii  libc6  2.37-12
> ii  libglib2.0-0   2.78.1-4
> ii  libostree-1-1  2023.7-3
> ii  qemu-system-x86    1:8.1.2+ds-1
> ii  qemu-user-static   1:8.1.2+ds-1
> ii  systemd-container  255~rc2-1
> 
> Versions of packages debos recommends:
> ii  bmap-tools 3.7-1
> ii  bzip2  1.0.8-5+b1
> ii  dosfstools 4.2-1
> ii  e2fsprogs  1.47.0-2+b1
> ii  fdisk  2.39.2-6
> ii  linux-image-amd64  6.5.10-1
> ii  mount  2.39.2-6
> ii  ovmf   2023.05-2
> ii  parted 3.6-3
> ii  systemd-resolved   

Bug#1056592: debos: yaml: line X: did not find expected key

[Arnaud Rebillout]

Package: debos
Version: 1.1.2-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Hi Christopher,

Here's a surprising bug report. The version of debos currently in Debian
unstable is a bit broken, in an odd way.

Consider the following recipe:

```
$ cat main.yaml
{{ $ospack := or .ospack "debian" }}
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: {{ $ospack }}.tar.gz
```

If I run with `-t ospack:debian` it fails:

```
$ debos --print-recipe -t ospack:debian main.yaml
2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:05:27
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos --template-var 'ospack:"debian"' 
/home/user/debos/main.yaml using kvm backend
2023/11/23 16:05:31 yaml: line 6: did not find expected key
```

However if I run without `-t`, it succeeds:

```
$ debos --print-recipe main.yaml
2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
2023/11/23 23:10:55
architecture: amd64
actions:
  - action: debootstrap
suite: sid
  - action: pack
file: debian.tar.gz
Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml using 
kvm backend
2023/11/23 16:10:59  debootstrap 
2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
[...]
```

Another surprise: this is a regression introduced by package 1.1.2-2. If
I downgrade to version 1.1.2-1, everything works fine.

```
sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
```

I compared the Built-Using fields between both packages:

```
-golang-1.21 (= 1.21.1-1)
+golang-1.21 (= 1.21.4-1)
+golang-github-alessio-shellescape (= 1.4.1-3)
 golang-github-cespare-xxhash (= 2.1.1-2)
 golang-github-docker-go-units (= 0.4.0-4)
-golang-github-go-debos-fakemachine (= 0.0.6-1)
+golang-github-go-debos-fakemachine (= 0.0.7-1)
 golang-github-google-uuid (= 1.3.0-1)
-golang-github-klauspost-compress (= 1.15.12+ds1-3)
+golang-github-klauspost-compress (= 1.17.2+ds1-1)
 golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
 golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
 golang-github-ulikunitz-xz (= 0.5.6-2)
 golang-go-flags (= 1.4.0-6)
-golang-golang-x-sys (= 0.9.0-1)
+golang-golang-x-sys (= 0.13.0-1)
 golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
 golang-yaml.v2 (= 2.4.0-4)
```

I suppose the regression was introduced by one of the dependencies that
changed. I have no idea how to troubleshot that... Tomorrow I'll try to
rebuild a package to see if that magically fixes it.

Can you try to reproduce this issue on your side, just to confirm?

Thanks in advance,

Arnaud


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 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 debos depends on:
ii  busybox1:1.36.1-4
ii  debootstrap1.0.133
ii  libc6  2.37-12
ii  libglib2.0-0   2.78.1-4
ii  libostree-1-1  2023.7-3
ii  qemu-system-x861:8.1.2+ds-1
ii  qemu-user-static   1:8.1.2+ds-1
ii  systemd-container  255~rc2-1

Versions of packages debos recommends:
ii  bmap-tools 3.7-1
ii  bzip2  1.0.8-5+b1
ii  dosfstools 4.2-1
ii  e2fsprogs  1.47.0-2+b1
ii  fdisk  2.39.2-6
ii  linux-image-amd64  6.5.10-1
ii  mount  2.39.2-6
ii  ovmf   2023.05-2
ii  parted 3.6-3
ii  systemd-resolved   255~rc2-1
ii  udev   255~rc2-1
ii  xz-utils   5.4.4-0.1
ii  zip3.0-13

Versions of packages debos suggests:
pn  libslirp-helper  
pn  user-mode-linux  

-- no debconf information

Bug#1056348: FTBFS: tests fail in clean environment

[Steve McIntyre]

On Thu, Nov 23, 2023 at 10:46:34AM -0500, Nicolas Mora wrote:
>Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit :
>> 
>> Ah, apologies - that version is bogus, it's just the version on the
>> bullseye machine I ran reportbug from.
>> 
>> The tests are failing on current unstable source.
>> 
>
>OK, makes more sense then.
>
>Nevertheless I'm wondering about the seriousness of the bug, I can't
>reproduce on my environment and all the buildd environments where libssh2 is
>built don't have the problem.

AFAICS in a non-interactive environment, USER isn't required to be set
but LOGNAME is; see

  https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Alternatively, the tets should probably be calling get(e)uid and
getpwent() rather than relying on the environment here.

>Could your issue be fixed by running something like this?
>USER=$LOGNAME dpkg-buiildpackage
>
>I'm just wondering if the patch is worth applying it to fix a less probable
>case.

The tests failed in a CI system we use at work, so I needed to fix it
there. The patch just adds fallback here, and makes things more robust.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#1027263: #1027263 pending, fixed in git

[Christoph Goehre]

tags 1027263 pending
thanks

Fixed with 
https://salsa.debian.org/debian/mini-dinstall/-/commit/ad12a309987683f89d7e6ac70defbc38b9d44c81

Bug#1056591: acedb FTBFS against glibc 2.38

[Olivier Gayot]

Package: acedb
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

Trying to build with glibc 2.38 fails with the following error:

 ../wh/utils.h:34:7: error: conflicting types for ‘strcasestr’; have ‘char 
*(char *, char *)’
34 | char *strcasestr (char *str1, char *str2);
   | ^~
 In file included from ../wh/mystdlib.h:227,
  from ../wh/regular.h:51,
  from utils.c:37:
 /usr/include/string.h:380:14: note: previous declaration of ‘strcasestr’ with 
type ‘char *(const char *, const char *)’

Before glibc 2.38, the strcasestr function was only made available when
building with _GNU_SOURCE. Starting with glibc 2.38, the function is
available by default.

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

  * Fix build against glibc 2.38 (LP: #2044385)


Thanks for considering the patch.


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

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch 
acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch
--- acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch1970-01-01 
01:00:00.0 +0100
+++ acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch2023-11-23 
16:07:13.0 +0100
@@ -0,0 +1,47 @@
+Description: Fix build against glibc 2.38
+ In previous glibc versions, strcasestr would only be available if building
+ with _GNU_SOURCE.
+ Starting with glibc 2.38, strcasestr is now available by default.
+ Ensure that acedb does not redefine the function if we're building with a 
modern glibc.
+Author: Olivier Gayot 
+Bug: 
+Bug-Ubuntu: https://launchpad.net/bugs/2044385
+Forwarded: no
+Last-Update: 2023-11-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: acedb-4.9.39+dfsg.02/w1/utils.c
+===
+--- acedb-4.9.39+dfsg.02.orig/w1/utils.c   2005-10-04 15:15:00.0 
+0200
 acedb-4.9.39+dfsg.02/w1/utils.c2023-11-23 16:48:20.118800952 +0100
+@@ -774,7 +774,7 @@
+ //
+ /* case-insensitive version of strstr */
+ 
+-#ifndef DARWIN
++#ifndef HAS_STRCASESTR
+ char *strcasestr(char *str1, char *str2)
+ {
+   g_strup(str1);
+Index: acedb-4.9.39+dfsg.02/wh/utils.h
+===
+--- acedb-4.9.39+dfsg.02.orig/wh/utils.h   2023-11-23 16:19:02.454527757 
+0100
 acedb-4.9.39+dfsg.02/wh/utils.h2023-11-23 16:47:40.099066905 +0100
+@@ -29,7 +29,16 @@
+  *---
+  */
+ 
+-#ifndef DARWIN
++/* Ensure that features.h or an equivalent is included. */ 
++#include 
++
++#if defined(DARWIN) || defined(_GNU_SOURCE)
++# define HAS_STRCASESTR
++#elif __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 38
++# define HAS_STRCASESTR
++#endif
++
++#ifndef HAS_STRCASESTR
+ /* case-insensitive version of strstr */
+ char *strcasestr  (char *str1, char *str2);
+ #endif
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/series 
acedb-4.9.39+dfsg.02/debian/patches/series
--- acedb-4.9.39+dfsg.02/debian/patches/series  2023-08-15 16:23:13.0 
+0200
+++ acedb-4.9.39+dfsg.02/debian/patches/series  2023-11-23 16:07:13.0 
+0100
@@ -13,3 +13,4 @@
 glibc2.32.patch
 # drop_gtk2.patch
 just_build_efetch.patch
+glibc-2.38.patch

Bug#1056590: dh_movetousr: consider updating symlink targets

[Colin Watson]

Package: debhelper
Version: 13.11.4
Severity: normal
X-Debbugs-Cc: Helmut Grohne 
Owner: Helmut Grohne 

I tried adding "Build-Depends: dh-sequence-movetousr" to parted.  The
build was apparently successful, but lintian warned me:

  W: libparted-fs-resize0: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libparted-fs-resize.so 
[usr/lib/x86_64-linux-gnu/libparted-fs-resize.so.0.0.5]
  W: libparted2: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libparted.so 
[usr/lib/x86_64-linux-gnu/libparted.so.2.0.5]

This is because libparted-dev has a
/usr/lib/x86_64-linux-gnu/libparted.so ->
/lib/x86_64-linux-gnu/libparted.so.2 symlink (and similar for
libparted-fs-resize.so), but libparted2 now ships
/usr/lib/x86_64-linux-gnu/libparted.so.2 instead.

Technically this is fine since the /lib -> /usr/lib symlink is now
mandatory, but lintian apparently doesn't know that, and I think it's
rather confusing.  We ought to either change lintian to not warn about
this, or change dh_movetousr to fix up the symlinks; either way,
developers shouldn't see a warning here.

Talking to Helmut at the mini-Debconf in Cambridge, we went back and
forth a bit but his gut feeling appeared to be that it would make sense
to at least experiment with having dh_movetousr update symlink targets,
so I'm filing this bug as a reminder.

Thanks,

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

Bug#1056348: FTBFS: tests fail in clean environment

[Nicolas Mora]

Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit :


Ah, apologies - that version is bogus, it's just the version on the
bullseye machine I ran reportbug from.

The tests are failing on current unstable source.



OK, makes more sense then.

Nevertheless I'm wondering about the seriousness of the bug, I can't 
reproduce on my environment and all the buildd environments where 
libssh2 is built don't have the problem.


Could your issue be fixed by running something like this?
USER=$LOGNAME dpkg-buiildpackage

I'm just wondering if the patch is worth applying it to fix a less 
probable case.


/Nicolas

Bug#1056588: ftp.kaist.ac.kr(ftp.kr.d.o): Not listed in public mirror list

[Adam D. Barratt]

Hi,

On Thu, 2023-11-23 at 23:57 +0900, 신도윤 wrote:
> Hello, this is ftp.kaist.ac.kr (known as ftp.kr.debian.org) manager.
> 
> I checked that we are not listed in the public mirror list.
> (https://www.debian.org/mirror/list)
> But, we are already listed in the mirror-master list.
> (
> https://mirror-master.debian.org/status/mirror-info/ftp.kaist.ac.kr.ht
> ml)

That's due to the mirror's current score on the status system (your
later link) being 28. The public list is generated based on those
mirrors with a score of at least 50.

There isn't enough history on the web side at least to see why the
score had dropped lower, but it is currently increasing, so it should
make its way back on to the public list "soon".

Regards,

Adam

Bug#1056589: python3-spidev: i got no spidev devices unter /dev/

[mooppi79]

Package: python3-spidev
Version: 3.6-1+b1
Severity: normal

Dear Maintainer,

I got no SPI - Device under /dev/ 

root@raspi2:/dev# ls -hl 
insgesamt 0
crw--- 1 root root 10, 134 20. Sep 14:15 apm_bios
crw-r--r-- 1 root root 10, 235 20. Sep 14:15 autofs
drwxr-xr-x 2 root root 260 20. Sep 14:15 block
crw--- 1 root root 10, 234 20. Sep 14:15 btrfs-control
drwxr-xr-x 3 root root  60  1. Jan 1970  bus
crw-rw 1 root video   239,   0 20. Sep 14:15 cec0
drwxr-xr-x 2 root root2,7K 22. Nov 18:59 char
crw--w 1 root tty   5,   1 22. Nov 18:59 console
crw--- 1 root root 10, 203 20. Sep 14:15 cuse
drwxr-xr-x 8 root root 160  1. Jan 1970  disk
drwxr-xr-x 3 root root 100 20. Sep 14:15 dri
crw-rw 1 root video29,   0 20. Sep 14:15 fb0
lrwxrwxrwx 1 root root  13  1. Jan 1970  fd -> /proc/self/fd
crw-rw-rw- 1 root root  1,   7 20. Sep 14:15 full
crw-rw-rw- 1 root root 10, 229 20. Sep 14:15 fuse
crw--- 1 root root254,   0 20. Sep 14:15 gpiochip0
crw--- 1 root root 10, 183 20. Sep 14:15 hwrng
crw-rw 1 root i2c  89,   0 20. Sep 14:15 i2c-0
crw-rw 1 root i2c  89,   1 20. Sep 14:15 i2c-1
crw-rw 1 root i2c  89,   2 20. Sep 14:15 i2c-2
lrwxrwxrwx 1 root root  12 20. Sep 14:15 initctl -> /run/initctl
drwxr-xr-x 3 root root 100 20. Sep 14:15 input
crw-r--r-- 1 root root  1,  11 20. Sep 14:15 kmsg
lrwxrwxrwx 1 root root  28 20. Sep 14:15 log -> /run/systemd/journal/
dev-log
brw-rw 1 root disk  7,   0 20. Sep 14:15 loop0
...
crw-rw 1 root disk 10, 237 20. Sep 14:15 loop-control
drwxr-xr-x 2 root root  60 20. Sep 14:15 mapper
crw-r- 1 root kmem  1,   1 20. Sep 14:15 mem
brw-rw 1 root disk179,   0 20. Sep 14:15 mmcblk0
brw-rw 1 root disk179,   1 20. Sep 14:15 mmcblk0p1
brw-rw 1 root disk179,   2 20. Sep 14:15 mmcblk0p2
drwxrwxrwt 2 root root  40  1. Jan 1970  mqueue
drwxr-xr-x 2 root root  60 20. Sep 14:15 net
crw-rw-rw- 1 root root  1,   3 20. Sep 14:15 null
crw-r- 1 root kmem  1,   4 20. Sep 14:15 port
crw--- 1 root root108,   0 20. Sep 14:15 ppp
crw--- 1 root root 10,   1 20. Sep 14:15 psaux
crw-rw-rw- 1 root tty   5,   2 23. Nov 16:00 ptmx
drwxr-xr-x 2 root root   0  1. Jan 1970  pts
crw-rw-rw- 1 root root  1,   8 20. Sep 14:15 random
crw--- 1 root root 10, 242 20. Sep 14:15 rfkill
drwxrwxrwt 2 root root  40 20. Sep 14:15 shm
crw--- 1 root root 10, 231 20. Sep 14:15 snapshot
drwxr-xr-x 3 root root 180 20. Sep 14:15 snd
lrwxrwxrwx 1 root root  15  1. Jan 1970  stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root  15  1. Jan 1970  stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root  15  1. Jan 1970  stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty   5,   0 20. Sep 14:15 tty
...
crw-rw 1 root dialout 204,  64 22. Nov 18:59 ttyAMA0
crw-rw 1 root dialout   4,  64 20. Sep 14:15 ttyS0
crw-rw 1 root dialout   4,  65 20. Sep 14:15 ttyS1
crw-rw 1 root dialout   4,  66 20. Sep 14:15 ttyS2
crw-rw 1 root dialout   4,  67 20. Sep 14:15 ttyS3
crw-rw 1 root dialout   4,  68 20. Sep 14:15 ttyS4
crw--- 1 root root 10, 239 20. Sep 14:15 uhid
crw--- 1 root root 10, 223 20. Sep 14:15 uinput
crw-rw-rw- 1 root root  1,   9 20. Sep 14:15 urandom
crw--- 1 root root 10, 126 20. Sep 14:15 userfaultfd
crw--- 1 root root 10, 125 20. Sep 14:15 vchiq
crw-rw 1 root tty   7,   0 20. Sep 14:15 vcs
...
crw--- 1 root root 10, 127 20. Sep 14:15 vga_arbiter
crw-rw 1 root kvm  10, 238 20. Sep 14:15 vhost-net
crw-rw 1 root kvm  10, 241 20. Sep 14:15 vhost-vsock
crw--- 1 root root 10, 130 20. Sep 14:15 watchdog
crw--- 1 root root249,   0 20. Sep 14:15 watchdog0
crw-rw-rw- 1 root root  1,   5 20. Sep 14:15 zero
root@raspi2:/dev# 



i have insert the Modules under 

etc/modules-load.d/modules.conf
spi-bcm2835
spi-bcm2835aux
spi-spidev
i2c-dev
i2c-bcm2835


the modul list under /lib/modules/6.1.0-13-armmp/kernel/drivers/spi

insgesamt 528K
-rw-r--r-- 1 root root  27K 29. Sep 06:15 spi-aspeed-smc.ko
-rw-r--r-- 1 root root  15K 29. Sep 06:15 spi-bcm2835aux.ko
-rw-r--r-- 1 root root  25K 29. Sep 06:15 spi-bcm2835.ko
-rw-r--r-- 1 root root 9,4K 29. Sep 06:15 spi-butterfly.ko
-rw-r--r-- 1 root root  30K 29. Sep 06:15 spi-cadence-quadspi.ko
-rw-r--r-- 1 root root  34K 29. Sep 06:15 spi-imx.ko
-rw-r--r-- 1 root root 9,0K 29. Sep 06:15 spi-lm70llp.ko
-rw-r--r-- 1 root root  17K 29. Sep 06:15 spi-meson-spicc.ko
-rw-r--r-- 1 root root  13K 29. Sep 06:15 spi-meson-spifc.ko
-rw-r--r-- 1 root root  27K 29. Sep 06:15 spi-omap2-mcspi.ko
-rw-r--r-- 1 root root  17K 29. Sep 06:15 spi-orion.ko
-rw-r--r-- 1 root root  37K 29. Sep 06:15 spi-pl022.ko
-rw-r--r-- 1 root root  12K 29. Sep 06:15 spi-pxa2xx-pci.ko
-rw-r--r-- 1 root root  33K 29. Sep 06:15 

Bug#1056062: coq: FTBFS in sid (dune update?)

[julien . puydt]

Hi,

Le mercredi 22 novembre 2023 à 18:48 +0100, Gianfranco Costamagna a
écrit :
> control: tags -1 patch
> 
> Hello, not sure why and how, but this upstream commit
> fbe9e28b667e795a5ceb41bd7784bd2ea7ab10bf
> 
> https://launchpadlibrarian.net/699029680/coq_8.17.0+dfsg-1build4_8.17.0+dfsg-1ubuntu1.diff.gz
> 
> Subject: [PATCH] make-library-index: use mktemp, general cleanup
> 
> This fixes the "sed: can't read tmp" error on my machine, not that I
> understand why it happened.
> 
> Looks fixing the issue
> 

Good: that means the problem will be fixed when I'll be able to upload
8.18.0+dfsg-1 to unstable.

control: fixed -1 8.18.0+dfsg-1

Thanks!

J.Puydt

Bug#1056588: ftp.kaist.ac.kr(ftp.kr.d.o): Not listed in public mirror list

[신도윤]

Package: mirrors
Severity: wishlist

User: mirr...@packages.debian.org
Usertags: mirror-list

Hello, this is ftp.kaist.ac.kr (known as ftp.kr.debian.org) manager.

I checked that we are not listed in the public mirror list.
(https://www.debian.org/mirror/list)
But, we are already listed in the mirror-master list.
(https://mirror-master.debian.org/status/mirror-info/ftp.kaist.ac.kr.html)

So, can we get listed both 2 domains (or if only 1 tier, then ftp.kr.d.o)
on the public mirror list?

Regards,

Roul