Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build

[Jochen Sprickerhof]

Source: golang-github-pion-webrtc.v3
Version: 3.1.56-2
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

golang-github-pion-webrtc.v3 attempts network access during build.
This is forbidden by Policy 4.9:

  For packages in the main archive, required targets must not attempt
  network access, except, via the loopback interface, to services on the
  build host that have been started by the build.

This can be tested with the sbuild unshare backend:

=== NAME  TestDataChannelParamters_Go
util.go:41: Unexpected routines on test end:
goroutine 34 [select]:

github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).loop(0xc240a0, 
{0x9f4b80, 0xc3ec30})

/<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:139
 +0x12d
created by 
github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).BindRTCPWriter in 
goroutine 16

/<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:74
 +0x115

goroutine 35 [select]:

github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).loop(0xc0001303c0,
 {0x9f4b80, 0xc3ec30})

/<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:97
 +0x19c
created by 
github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).BindRTCPWriter in 
goroutine 16

/<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:86
 +0x115

goroutine 36 [select]:

github.com/pion/interceptor/pkg/report.(*SenderInterceptor).loop(0xc000130420, 
{0x9f4b80, 0xc3ec30})

/<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:98
 +0x19c
created by 
github.com/pion/interceptor/pkg/report.(*SenderInterceptor).BindRTCPWriter in 
goroutine 16

/<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:87
 +0x115

[...]

Cheers Jochen

Bug#1070409: golang-github-pion-ice.v2: accesses the internet during build

[Jochen Sprickerhof]

Source: golang-github-pion-ice.v2
Version: 2.3.1-1
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

golang-github-pion-ice.v2 attempts network access during build.
This is forbidden by Policy 4.9:

  For packages in the main archive, required targets must not attempt
  network access, except, via the loopback interface, to services on the
  build host that have been started by the build.

This can be tested with the sbuild unshare backend:

=== RUN   TestConnectionStateCallback
goroutine profile: total 16
2 @ 0x43f36e 0x40999f 0x4095d2 0x71a847 0x476061
#   0x71a846
github.com/pion/ice/v2.(*Agent).startOnConnectionStateChangeRoutine.func1+0x46  
/<>/_build/src/github.com/pion/ice/v2/agent.go:424

2 @ 0x43f36e 0x438057 0x470a85 0x4a1ec7 0x4a4f0a 0x4a4ef3 0x565516 0x5a2004 
0x5a568e 0x5a567c 0x5a8745 0x476061
#   0x470a84internal/poll.runtime_pollWait+0x84 
/usr/lib/go-1.22/src/runtime/netpoll.go:345
#   0x4a1ec6internal/poll.(*pollDesc).wait+0x26 
/usr/lib/go-1.22/src/internal/poll/fd_poll_runtime.go:84
#   0x4a4f09internal/poll.(*pollDesc).waitRead+0x129
/usr/lib/go-1.22/src/internal/poll/fd_poll_runtime.go:89
#   0x4a4ef2internal/poll.(*FD).RawRead+0x112   
/usr/lib/go-1.22/src/internal/poll/fd_unix.go:708
#   0x565515net.(*rawConn).Read+0x35
/usr/lib/go-1.22/src/net/rawconn.go:44
#   0x5a2003golang.org/x/net/internal/socket.(*Conn).recvMsg+0x143  
/<>/_build/src/golang.org/x/net/internal/socket/rawconn_msg.go:27
#   0x5a568dgolang.org/x/net/internal/socket.(*Conn).RecvMsg+0x4ad  
/<>/_build/src/golang.org/x/net/internal/socket/socket.go:247
#   0x5a567bgolang.org/x/net/ipv4.(*payloadHandler).ReadFrom+0x49b  
/<>/_build/src/golang.org/x/net/ipv4/payload_cmsg.go:31
#   0x5a8744github.com/pion/mdns.(*Conn).start+0xe4 
/<>/_build/src/github.com/pion/mdns/conn.go:295

2 @ 0x43f36e 0x4510c5 0x4ea5b8 0x476061
#   0x4ea5b7context.(*cancelCtx).propagateCancel.func2+0x97 
/usr/lib/go-1.22/src/context/context.go:510

2 @ 0x43f36e 0x4510c5 0x719098 0x476061
#   0x719097github.com/pion/ice/v2.(*Agent).taskLoop+0x137  
/<>/_build/src/github.com/pion/ice/v2/agent.go:230

2 @ 0x43f36e 0x4510c5 0x71a5c5 0x476061
#   0x71a5c4
github.com/pion/ice/v2.(*Agent).startOnConnectionStateChangeRoutine.func2+0xa4  
/<>/_build/src/github.com/pion/ice/v2/agent.go:433

2 @ 0x43f36e 0x4510c5 0x71b113 0x476061
#   0x71b112
github.com/pion/ice/v2.(*Agent).connectivityChecks+0x1b2
/<>/_build/src/github.com/pion/ice/v2/agent.go:550

1 @ 0x434a31 0x4706bd 0x531871 0x5316a5 0x52e4cb 0x7748bd 0x476061
#   0x4706bcruntime/pprof.runtime_goroutineProfileWithLabels+0x1c   
/usr/lib/go-1.22/src/runtime/mprof.go:1079
#   0x531870runtime/pprof.writeRuntimeProfile+0xb0  
/usr/lib/go-1.22/src/runtime/pprof/pprof.go:774
#   0x5316a4runtime/pprof.writeGoroutine+0x44   
/usr/lib/go-1.22/src/runtime/pprof/pprof.go:734
#   0x52e4caruntime/pprof.(*Profile).WriteTo+0x14a  
/usr/lib/go-1.22/src/runtime/pprof/pprof.go:369
#   0x7748bc
github.com/pion/ice/v2.TestConnectionStateCallback.TimeOut.func2+0x3c   
/<>/_build/src/github.com/pion/transport/test/util.go:21

1 @ 0x43f36e 0x40999f 0x4095b2 0x4faeeb 0x4fd037 0x4fa01b 0x4fcf25 0x4fb92b 
0x77c2ac 0x43ef1d 0x476061
#   0x4faeeatesting.(*T).Run+0x3aa  
/usr/lib/go-1.22/src/testing/testing.go:1750
#   0x4fd036testing.runTests.func1+0x36 
/usr/lib/go-1.22/src/testing/testing.go:2161
#   0x4fa01atesting.tRunner+0xfa
/usr/lib/go-1.22/src/testing/testing.go:1689
#   0x4fcf24testing.runTests+0x444  
/usr/lib/go-1.22/src/testing/testing.go:2159
#   0x4fb92atesting.(*M).Run+0x68a  
/usr/lib/go-1.22/src/testing/testing.go:2027
#   0x77c2abmain.main+0x16b _testmain.go:225
#   0x43ef1cruntime.main+0x29c  
/usr/lib/go-1.22/src/runtime/proc.go:271

1 @ 0x43f36e 0x4510c5 0x73a965 0x766c5b 0x766c32 0x746425 0x4fa01b 0x476061
#   0x73a964github.com/pion/ice/v2.(*Agent).connect+0x124   
/<>/_build/src/github.com/pion/ice/v2/transport.go:53
#   0x766c5agithub.com/pion/ice/v2.(*Agent).Dial+0xfa   
/<>/_build/src/github.com/pion/ice/v2/transport.go:15
#   0x766c31github.com/pion/ice/v2.connect+0xd1 
/<>/_build/src/github.com/pion/ice/v2/transport_test.go:219
#   0x746424

Bug#1028541: lvm2: LVM filters render servers unusable post bookworm upgrade

[Vasudev Kamath]

Package: lvm2
Version: 2.03.22-1+b1
Followup-For: Bug #1028541

Dear Maintainer,

We noticed this issue when we upgraded some our servers to use Bookworm. This
is actually rendering our system unusable as the LVM partitions are not getting
detected due to this issue. We have large number of servers and this is blocking
us from upgrading to Bookworm.

The fix is done by upstream can we please release updated LVM2 with fix for 
bookworm?
Backporting does not seem to be right thing to do as this is genuine bug and 
also since
its rendering systems unusable. 

Will this be considered for next point release of Bookworm?. If you need 
support in testing
I'm ready to provide that. 

Thanks and Regards,
Vasudev Kamath


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

Kernel: Linux 6.7.12-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 lvm2 depends on:
ii  dmeventd  2:1.02.196-1+b1
ii  dmsetup   2:1.02.196-1+b1
ii  libaio1t640.3.113-8
ii  libblkid1 2.40-8
ii  libc6 2.37-19
ii  libdevmapper-event1.02.1  2:1.02.196-1+b1
ii  libedit2  3.1-20230828-1+b1
ii  libselinux1   3.5-2+b2
ii  libsystemd0   255.5-1
ii  libudev1  255.5-1

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 suggests no packages.

-- no debconf information

Bug#1070408: ITP: python3-tabnet -- Attentive Interpretable Tabular Learning

[Yadd]

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

* Package name: python3-tabnet
  Version : 4.1.0
  Upstream Contact: DreamQuark 
* URL : https://github.com/dreamquark-ai/tabnet
* License : Expat
  Programming Lang: Python
  Description : Attentive Interpretable Tabular Learning

python3-tabnet is a pyTorch implementation of Tabnet (TabNet: Attentive
Interpretable Tabular Learning, https://arxiv.org/pdf/1908.07442.pdf).
Please note that some different choices have been made overtime to improve
the library which can differ from the orginal paper.

This package is needed for jupyterlab. Will be maintained under
Debian Pan Maintainers Team umbrella.

Bug#965386: plasma-browser-integration: Please package Firefox extension

[Paul Wise]

On Mon, 20 Jul 2020 20:24:38 +0200 Michael Weghorn wrote:

> Note: The file 'dev_README.txt' in the sources describes how to build the
> extension, but this probably cannot be followed as is, since it involves
> installing packages via "npm" in the first step (which is not in line with
> Debian's packaging practices).

None of that is actually needed, since you just can symlink the
directory into the Firefox and Chromium extension directories:

   sudo cp -a extension/ /usr/share/webext/plasma
   sudo ln -s /usr/share/webext/plasma 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/$(jq -r 
.applications.gecko.id < extension/manifest.json)
   sudo ln -s /usr/share/webext/plasma /usr/share/chromium/extensions/plasma

I have tested that this works on Debian firefox/firefox-esr/chromium.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#926618: RFP: webext-plasma-integration

[Paul Wise]

On Mon, 6 Dec 2021 14:47:24 + Phil Morrell wrote:

> Would be nice to see this packaged, since the native part is already
> available, under the affects package name. Note, I'm not even using this
> under KDE, it works perfectly fine under XFCE.

As I mentioned in #965386, this is easy to add to the package:

   sudo cp -a extension/ /usr/share/webext/plasma
   sudo ln -s /usr/share/webext/plasma 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/$(jq -r 
.applications.gecko.id < extension/manifest.json)
   sudo ln -s /usr/share/webext/plasma /usr/share/chromium/extensions/plasma

I think this RFP should be closed in favour of #965386, which would
simply included the needed files in plasma-browser-integration itself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070407: mailman3-web: dpkg --configure mailman3-web fails

[Thomas Krichel]

Package: mailman3-web
Version: 0+20240312-1
Severity: important

Dear Maintainer,

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

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

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

I am dist-updating my Debian system. I get a failure for the installation
of Mailman3-web

root@tagol~# dpkg --configure mailman3-web
Setting up mailman3-web (0+20240312-1) ...
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 20
Errors were encountered while processing:
 mailman3-web


  I tried replacing the set -e with set -x in

/var/lib/dpkg/info# e mailman3-web.postinst

  Then I get

root@tagol/var/lib/dpkg/info# dpkg --configure mailman3-web
Setting up mailman3-web (0+20240312-1) ...
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mailman3-web.postinst 
configure 0+20200530-2.1
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 20
Errors were encountered while processing:
 mailman3-web

  Running

root@tagol/var/lib/dpkg/info# /usr/share/debconf/frontend 
/var/lib/dpkg/info/mailman3-web.postinst configure 0+20200530-2.1

  yields nothing

root@tagol/var/lib/dpkg/info# dpkg --configure mailman3-web |& tee 
log.dpkg.config.mailman3web.5
Setting up mailman3-web (0+20240312-1) ...
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mailman3-web.postinst 
configure 0+20200530-2.1
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 20
Errors were encountered while processing:
 mailman3-web

  Same thing.

root@tagol~# systemctl restart mailman3-web.service
root@tagol~#

  The web interface page loads

https://folks.email/mailman3/postorius/lists/bibnez.folks.email/

  but when I go to sign-in I get

Internal Server Error: /mailman3/accounts/login/

OfflineGenerationError at /accounts/login/
You have offline compression enabled but key
+"5dc9242d199e3c2224564016de526a9d8e46b5d332709d1fde99964e8821452c" is missing 
from offline
+manifest. You may need to run "python manage.py compress". Here is the 
original content:

  I go ahead and run

root@tagol/usr/share/mailman3-web# ./manage.py compress
Compressing... Error parsing template socialaccount/signup.html: 
socialaccount/base.html
done
Compressed 2 block(s) from 78 template(s) for 1 context(s).

  It turns out this issue was discussed on the mailing list

https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/MGY6JA6O7BWGR2KNKD3PQTMW7ZY7NHS3/

  I tried to downgrade

root@tagol~# dpkg -i mailman3-web_0+20200530-2.1_all.deb
dpkg: warning: downgrading mailman3-web from 0+20240312-1 to 0+20200530-2.1
(Reading database ... 121410 files and directories currently installed.)
Preparing to unpack mailman3-web_0+20200530-2.1_all.deb ...
Unpacking mailman3-web (0+20200530-2.1) over (0+20240312-1) ...
Setting up mailman3-web (0+20200530-2.1) ...
Installing new version of config file /etc/cron.d/mailman3-web ...
dpkg: error processing package mailman3-web (--install):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 20
Errors were encountered while processing:
 mailman3-web

  So I upgrade again

root@tagol/usr/share/mailman3-web# apt upgrade
The following packages were automatically installed and are no longer required:
  libabsl20220623 libaio1 linux-image-6.6.15-amd64 python3-editables 
python3-pyrsistent
Use 'apt autoremove' to remove them.

Upgrading:
  mailman3-web

Summary:
  Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 0
  1 not fully installed or removed.
  Download size: 25.9 kB
  Space needed: 2,048 B / 11.2 TB available

Continue? [Y/n] y
Get:1 http://mirror.hetzner.com/debian/packages testing/main amd64 mailman3-web 
all 0+20240312-1 [25.9 kB]
Fetched 25.9 kB in 0s (141 kB/s)
Preconfiguring packages ...
mailman3-web failed to preconfigure, with exit status 20
(Reading database ... 121410 files and directories currently installed.)
Preparing to unpack .../mailman3-web_0+20240312-1_all.deb ...
Unpacking mailman3-web (0+20240312-1) over (0+20200530-2.1) ...
Setting up mailman3-web (0+20240312-1) ...
Installing new version of config file /etc/cron.d/mailman3-web ...
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 20
Errors were encountered while processing:

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Package: qtbase5-dev
Version: 5.15.10+dfsg-7.2+b1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Control: found -1 5.15.2+dfsg-9
Control: found -1 5.7.1+dfsg-3+deb9u4
Control: affects -1 musescore
Control: affects -1 musescore3

I’ve received reports that PDFs generated by Mu͒seScore when
viewed in Atril (but not in Okular or mupdf!) have the top
of the treble clef cut off. I found that the same happens
for glyphs of the font I use for URLs and copyright notices
(attached), but only from Mu͒seScore, not from LibreOffice.

I first reported this to Atril both because I couldn’t find
anything wrong with the font metrics (or after fixing what
could have been, I tried multiple variants) upstream at
https://github.com/mate-desktop/atril/issues/610 where a
helpful soul found that there’s some clip path in the PDFs
which Atril honours that clips off the rendering but that
under that the glyphs are fully present.

Then I dug into the Mu͒seScore Studio source code, but could
not find anything suspicious, so I extracted an MWE from its
source code (under GPLv2 though I doubt the example below is
actually nōntrivial enough to be copyrightable) to generate
a PDF and, voilà, the top of the text is cut off in Atril but
not in mupdf.

I’m attaching the MWE (qex.pro + qex.cc) and the font file
(SIL OFL, currently the .otf is the source) so you can
reproduce this. It reproduces for me on stretch, bullseye and
sid, probably universally. (Make sure $DISPLAY is set. Put the
.otf into ~/.local/share/fonts/ to test.)

$ QT_SELECT=5 qmake qex.pro && make && ./qex
$ mupdf moo.pdf
$ atril moo.pdf

Please forward this bug upstream as suitable. Thanks in advance!
(I don’t have the means to test with upstream’s versions.)

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

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages qtbase5-dev depends on:
ii  libegl-dev 1.7.0-1+b1
ii  libgl-dev  1.7.0-1+b1
ii  libglu1-mesa-dev [libglu-dev]  9.0.2-1.1+b1
ii  libqt5concurrent5t64   5.15.10+dfsg-7.2+b1
ii  libqt5core5t64 5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64 5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64  5.15.10+dfsg-7.2+b1
ii  libqt5network5t64  5.15.10+dfsg-7.2+b1
ii  libqt5printsupport5t64 5.15.10+dfsg-7.2+b1
ii  libqt5sql5t64  5.15.10+dfsg-7.2+b1
ii  libqt5test5t64 5.15.10+dfsg-7.2+b1
ii  libqt5widgets5t64  5.15.10+dfsg-7.2+b1
ii  libqt5xml5t64  5.15.10+dfsg-7.2+b1
ii  libvulkan-dev  1.3.280.0-1
ii  libxext-dev2:1.3.4-1+b1
ii  qt5-qmake  5.15.10+dfsg-7.2+b1
ii  qtbase5-dev-tools  5.15.10+dfsg-7.2+b1
ii  qtchooser  66-2

Versions of packages qtbase5-dev recommends:
pn  libqt5opengl5-dev  

Versions of packages qtbase5-dev suggests:
pn  default-libmysqlclient-dev  
pn  firebird-dev
pn  libpq-dev   
pn  libsqlite3-dev  
pn  unixodbc-dev

-- no debconf information
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#define ensure(what) if (!(what)) errx(1, "%s", #what)

int main(int argc, char *argv[]) {
QGuiApplication MyApp(argc, argv);
QPdfWriter printerDev("moo.pdf");
QPainter p;
ensure(p.begin());
p.setRenderHint(QPainter::Antialiasing, true);
p.setRenderHint(QPainter::TextAntialiasing, true);

QPointF ofs(100, 1000);
QFont font("Inconsolatazi4varl_qu", 72);
p.setFont(font);
p.drawText(ofs, "foi Test 0'l");

p.end();
errx(0, "done");
}
CONFIG += debug
SOURCES += qex.cc
TARGET = qex


Inconsolatazi4varl_qu-Regular.otf
Description: application/vnd.ms-opentype

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Shmerl]

On Sat, 4 May 2024 21:10:10 +0300 Jussi Pakkanen  wrote:
> The script runs fine on x64_64 but fails on arm64 (and probably also
> x86, but I did not test it). This would imply something wonky going on
> in the toolchain. The question then becomes where this should be
> reported to.

May be for rustc? It's worth filing the bug if it's not clear what the
root cause is. If it's not really rustc, developers will point that out.

Regards,
Shmerl.

Bug#1069538: zeroc-ice: FTBFS on armel: Gradle / Java heap space

[Chris Knadle]

An NMU diff for the upload to fix this bug is attached.

Thanks to Vladimir Petko and Tony Mancill on the [debian-java] mailing 
list for the fix


https://lists.debian.org/debian-java/2024/05/msg1.html

--
Chris Knadle
chris.kna...@coredump.us
diff -Nru zeroc-ice-3.7.10/debian/changelog zeroc-ice-3.7.10/debian/changelog
--- zeroc-ice-3.7.10/debian/changelog	2024-04-10 10:48:17.0 -0400
+++ zeroc-ice-3.7.10/debian/changelog	2024-05-04 13:55:38.0 -0400
@@ -1,3 +1,15 @@
+zeroc-ice (3.7.10-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules:
+- Add GRADLE_OPTS=-Xmx512M to fix FTBFS on armel due to Java heap space
+  memory error
+  Thanks to Vladimir Petko  and
+  Tony Mancill  for the fix
+(Closes: #1069538)
+
+ -- Christopher Knadle   Sat, 04 May 2024 13:55:38 -0400
+
 zeroc-ice (3.7.10-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru zeroc-ice-3.7.10/debian/rules zeroc-ice-3.7.10/debian/rules
--- zeroc-ice-3.7.10/debian/rules	2024-04-10 10:25:18.0 -0400
+++ zeroc-ice-3.7.10/debian/rules	2024-05-04 13:55:38.0 -0400
@@ -19,7 +19,6 @@
 java_compat_level ?= 8
 
 export JAVA_HOME=/usr/lib/jvm/default-java/
-
 #
 # Use the system gradle unless it has been overridden by GRADLE
 # environment variable.
@@ -35,6 +34,10 @@
 			  -PiceBuilderClassPath=com.zeroc.gradle.ice-builder
 endif
 
+# GRADLE_OPTS memory setting to work around FTBFS on armel
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538
+export GRADLE_OPTS=-Xmx512M
+
 export GRADLEARGS	= --gradle-user-home $(CURDIR)/.gradle \
 			  --info \
 			  --console plain \

Bug#1069133:

[Forest]

Control: fixed -1 linux/6.7.12-1

Bug#1069133:

[Forest]

fixed -1 linux/6.7.12-1

Bug#1066213: slrn: FTBFS: misc.c:376:4: error: implicit declaration of function ‘VA_COPY’ [-Werror=implicit-function-declaration]

[Andreas Beckmann]

Followup-For: Bug #1066213
Control: tag -1 patch pending

Hi,

this was fixed and tagged in git a week ago, but so far no upload
happened.


Andreas

Bug#1061216: Please upgrade to llvm-toolchain-17

[Gregor Riepl]

As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -17.

This package depends on 14.


Not possible at this time. Trying to build openvdb 10.0.1 against LLVM 
17 results in the following error:


CMake Error at openvdb_ax/openvdb_ax/CMakeLists.txt:118 (message):
  OpenVDB AX does not currently support LLVM versions >= 15 due to opaque
  pointer changes in LLVM.  Found unsuitable LLVM version "17.0.6"

The release notes for openvdb 11.1.0[1] mention compatibility with LLVM 
15, but not later versions. There's nothing listed for 11.0.0, and a 
quick test shows that this hasn't changed:


CMake Error at openvdb_ax/openvdb_ax/CMakeLists.txt:118 (message):
  OpenVDB AX does not currently support LLVM versions >= 16 due to opaque
  pointer changes in LLVM.  Found unsuitable LLVM version "17.0.6"

Which LLVM versions are you planning to remove?
Would it be possible to keep at least LLVM 15 until upstream has 
upgraded their code base?


[1] 
https://www.openvdb.org/documentation/doxygen/changes.html#v10_1_0_changes

Bug#1048058: slrn: Fails to build source after successful build

[Andreas Beckmann]

Followup-For: Bug #1048058
Control: tag -1 patch

Attached patch cleans two more directories with files that are generated
during build, fixing building the package twice in a row.


Andreas
>From 996fe0699101d5f2683b6a329fad71fb72210094 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Sun, 5 May 2024 02:14:36 +0200
Subject: [PATCH] fix building twice in a row

Closes: #1048058
---
 debian/clean | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 debian/clean

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..a3c3220
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,2 @@
+po/debian/
+src/debian/
-- 
2.20.1

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Maytham Alsudany]

Hi,

Any progress on getting linenoise packaged? This is urgently needed to devendor
linenoise in the redict package (a new fork of redis).

If you've lost interest, I'm happy to take over this ITP.

Kind regards,
Maytham


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

Bug#1069077:

[Forest]

Control: found -1 6.7.12-1

Bug#1068510: bobcat: provide a separate bobcat-source package for bootstrapping icmake

[tony mancill]

On Sat, Apr 06, 2024 at 12:00:48PM -0700, tony mancill wrote:
> A separate bobcat-source binary package will enable icmake 12.x to be
> bootstrapped without having to vendor in a copy of the bobcat sources.

The upstream has decided to pursue a different strategy that removes any
direct coupling between icmake and bobcat.

This has been accomplished with icmake 12.01.00-1:
https://tracker.debian.org/news/1522903/accepted-icmake-120100-1-source-into-unstable/

Bug#1070405: darktable: Please drop unused Build-Depends: libsoup2.4-dev

[Jeremy Bícha]

Source: darktable
Version: 4.6.1-2

Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and
we would eventually like to remove libsoup2.4 from Debian.

Thank you,
Jeremy Bícha

Bug#1070404: srain: Please update to 1.7.0

[Jeremy Bícha]

Source: srain
Version: 1.7.0
Severity: wishlist

Please update srain to 1.7.0. One detail I am interested in is that it
switches from libsoup2.4 to libsoup3.

https://github.com/SrainApp/srain/releases

Thank you,
Jeremy Bícha

Bug#1070403: does not start because of an "OpenSSL version mismatch"

[Tommaso Colombo]

Package: openssh-client-ssh1
Version: 1:7.5p1-16
Severity: grave
X-Debbugs-Cc: acct.deb...@tmcl.it

Any attempt to use ssh1 fails with:

"OpenSSL version mismatch. Built against 30100050, you have 30200020"

It looks like the cause is an runtime check of the OpenSSL version, which
requires that major and minor version are the same as those OpenSSH was
compiled against. This was appropriate for OpenSSL 1, but not for OpenSSL 3,
for which only checking the major version is enough to guarantee binary
compatibility.

This was fixed upstream in recent OpenSSH versions [1]. Could you please
backport it to ssh1?

Thanks,
Tommaso

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=3548


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

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

Versions of packages openssh-client-ssh1 depends on:
ii  libc62.37-18
ii  libselinux1  3.5-2+b2
ii  libssl3t64   3.2.1-3
ii  zlib1g   1:1.3.dfsg-3.1

openssh-client-ssh1 recommends no packages.

openssh-client-ssh1 suggests no packages.

-- no debconf information

Bug#1070402: linux-image-6.7.12-amd64: bluetooth dualshock 4 playstation controller no longer shows as connected

[Forest]

Package: src:linux
Version: 6.7.12-1
Severity: normal
X-Debbugs-Cc: fores...@nom.one

Dear Maintainer,

After upgrading from kernel 6.7.9 to 6.7.12, my DualShock 4 game
controller no longer shows as connected in KDE Plasma.

Contrary to what the GUI says, the device's onboard light seems to
indicate that it is connected, and it works in games. However, since the
GUI believes otherwise, I no longer have an indictor showing the
device's presence, and I can no longer easily turn off the device.

Clicking the Connect button in the GUI yields a failure.

Journalctl shows this new message at device power-on:

  bluetoothd[1143]: Authorization request for non-connected device!?

With the previous (working) kernel, these messages appeared instead:

  kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
  kernel: Bluetooth: HIDP socket layer initialized

Reverting to kernel 6.7.9 fixes the problem.

I suspect this might be the upstream bug (and patch):
https://bugzilla.kernel.org/show_bug.cgi?id=218680

-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.12-amd64 
root=UUID=6643f6c4-094f-40ea-a653-dfe61fd6e05c ro net.ifnames=0 quiet 
cryptdevice=UUID=921508cc-880b-455b-a47f-1f3a6cac6d55:osroot 
root=/dev/mapper/osroot splash

** Not tainted

** Kernel log:
[9.691418] Bluetooth: HCI device and connection manager initialized
[9.691421] Bluetooth: HCI socket layer initialized
[9.691423] Bluetooth: L2CAP socket layer initialized
[9.691425] Bluetooth: SCO socket layer initialized
[9.691451] input: HDA Digital PCBeep as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input19
[9.691505] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input20
[9.691544] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input21
[9.691590] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input22
[9.691622] input: HD-Audio Generic Line Out Front as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input23
[9.691656] input: HD-Audio Generic Line Out Surround as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input24
[9.691728] input: HD-Audio Generic Line Out CLFE as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input25
[9.691808] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input26
[9.693320] mt7921e :0b:00.0: enabling device ( -> 0002)
[9.695294] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[9.697686] mt7921e :0b:00.0: ASIC revision: 79610010
[9.700377] usbcore: registered new interface driver btusb
[9.709624] bluetooth hci0: firmware: direct-loading firmware 
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
[9.709836] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 
20231109191416
[9.779822] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[9.779880] mt7921e :0b:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20231109190918a

[   10.035775] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   10.036227] mt7921e :0b:00.0: WM Firmware Version: 01, Build 
Time: 20231109190959
[   10.069916] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   10.359539] audit: type=1400 audit(1714845460.171:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" 
pid=1056 comm="apparmor_parser"
[   10.359791] audit: type=1400 audit(1714845460.171:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=1060 comm="apparmor_parser"
[   10.359856] audit: type=1400 audit(1714845460.171:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/libexec/ibus-engine-hangul" pid=1064 comm="apparmor_parser"
[   10.360012] audit: type=1400 audit(1714845460.171:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=1062 comm="apparmor_parser"
[   10.360044] audit: type=1400 audit(1714845460.171:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=1059 comm="apparmor_parser"
[   10.360106] audit: type=1400 audit(1714845460.171:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=1048 
comm="apparmor_parser"
[   10.360183] audit: type=1400 audit(1714845460.171:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=1063 

Bug#1068665: cfengine3: FTBFS on arm{el,hf}: 1 of 60 tests failed

[Andreas Beckmann]

Followup-For: Bug #1068665
Control: tag -1 pending

Hi,

in order to make progress with the t64 transition, I've uploaded
Emanuele's patch as a NMU to DELAYED/2. Please let me know if I should
delay it longer.


Andreas

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Vincent Danjean]

Le 04/05/2024 à 17:32, Jakub Wilk a écrit :

* Vincent Danjean , 2016-12-25 23:36:

++    { "exfat", "nosuid,nodev,user,quiet,nonempty", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},


This doesn't work for me.
In dmesg I see:

     exfat: Unknown parameter 'quiet'



I forgot this bug for a long time since I'm using exfat SDcard/USBkey with 
pmount when it is required. But looking at my package:
$ apt-cache policy pmount
pmount:
  Installé : 0.9.99-alpha-1.2
  Candidat : 0.9.99-alpha-1.2
 Table de version :
 *** 0.9.99-alpha-1.2 100
100 /var/lib/dpkg/status
 0.9.23-7.1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages

It is a local package. So I looked where I build my packages and found a git 
tree initially cloned from
git://git.debian.org/git/pmount/pmount-debian.git (of course, the site does not 
exist anymore).
I was using a new upstream version (0.9.99-alpha) whose packaging had been 
prepared by Vincent Fourmond
and I locally applied this patch on top of it:
$ git diff origin/master
diff --git a/debian/changelog b/debian/changelog
index 3e17503..4a5f7cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+pmount (0.9.99-alpha-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix options for exfat (remove unsupported 'quiet' option)
+
+ -- Vincent Danjean   Sun, 18 Jul 2021 11:52:26 +0200
+
+pmount (0.9.99-alpha-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * support exfat filesystem (via fuse) (Closes: #755434)
+
+ -- Vincent Danjean   Sun, 25 Dec 2016 23:18:39 +0100
+
 pmount (0.9.99-alpha-1) experimental; urgency=low

   * New upstream experimental release, bringing in a lot of new features:
diff --git a/debian/patches/02-exfat-support.diff 
b/debian/patches/02-exfat-support.diff
new file mode 100644
index 000..d73af98
--- /dev/null
+++ b/debian/patches/02-exfat-support.diff
@@ -0,0 +1,11 @@
+Add support for exfat
+--- a/src/fs.c
 b/src/fs.c
+@@ -23,6 +23,7 @@
+ { "iso9660", "nosuid,nodev,user", 1, NULL, ",iocharset=%s" },
+ { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077",
+   ",iocharset=%s",",fmask=%04o,dmask=%04o"},
++{ "exfat", "nosuid,nodev,user", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},
+ { "hfsplus", "nosuid,nodev,user", 1, NULL, 0 },
+ { "hfs", "nosuid,nodev,user", 1, "077", NULL,
+   ",file_umask=%04o,dir_umask=%04o"},
diff --git a/debian/patches/series b/debian/patches/series
index e706419..f1ac0f2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 01-man-plugdev.diff
+02-exfat-support.diff

Looking at the dates, I see that origin/master was done by Vincent Fourmond on 
2011-03-25
I created a (local) package with the patch in this bug report on 2016-12-25
and I updated it on 2021-07-18 by removing the "quiet" and "nonempty" options.

  Regards,
Vincent

PS: it seems that 0.9.99-alpha never enters unstable. The changelog is saying:

diff --git a/ChangeLog b/ChangeLog
index 1dd34dd..8dcca5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+0.9.99-alpha
+
+- EXPERIMENTAL RELEASE, use at your own risks !
+- introducing a new /etc/pmount.conf file in which potentially
+  security-weak operations can be allowed:
+  * running fsck
+  * mounting while not physically logged (that was the default)
+  * loopback device mounting
+- pulling in new Russian translation from Rosetta
+- now checking if root can open the device before attempting any
+  mount, to avoid very long hangs on "no medium found" and the like.
+- whitelisting the "firewire" bus as a hotplug bus.
+
+
+  As noticed above, this is an experimental release. Please use with
+  care: even if the parsing of configuration files should be safe, it
+  has not been extensively tried.
+
+
 0.9.23
 ---
 - fix a security hole (see CVE-2010-2192 for more

Bug#1070340: This is not only Bookworm problem, but also Buster and maybe others

[Сергей Сёмин]

Initially I wrote only about Bookworm. But it is not only Bookworm problem.
For example, I have also repeat steps from
https://docs.google.com/document/d/1zjM5MvfFYC317PEPY4_4WRi0hOdpM766FyqpvOmeE90/edit?usp=sharing
in the environment of vagrant image debian/buster64 v10.20231211.1
(available here:
https://app.vagrantup.com/debian/boxes/buster64/versions/10.20231211.1).
Result fully reproduced:

vagrant@buster:~/imagemagick-6.9.10.23+dfsg$  ./magick.sh identify
mvg:piechart.mvg
coders/mvg.c:180:33: runtime error: 5e+26 is outside the range of
representable values of type 'long unsigned int'
identify: must specify image size `piechart.mvg' @
error/mvg.c/ReadMVGImage/186.
vagrant@buster:~/imagemagick-6.9.10.23+dfsg$

I used sources of imagemagick with version 8:6.9.10.23+dfsg-2.1+deb10u7
mentioned here https://security-tracker.debian.org/tracker/CVE-2023-34151
as fixed.
So I think CVE-2023-34151 was not properly closed for mvg in all Debian
versions. At least I proved that it was not closed in Bookworm and Buster.
But highly likely it was not properly closed in all other versions.

Bug#1065309: transition: gnat (12 -> 13 + time_t64)

[Graham Inggs]

Hi Nicholas

On Sat, 4 May 2024 at 12:21, Nicolas Boulenguez  wrote:
> For some reason, some rebuilds succeeded without a +b1 version.

I think if the original uploads FTBFS then they would not have gained
a +b1 version.

> Their reverse dependencies is dep-waiting on the +b1 version.
> Please cancel three dep-wait restrictions.
>
> gb libgnatcoll-db_23.0.0-6   . armel powerpc . -o
> gb libgnatcoll-bindings_24.0.0-2 . armhf . -o

I binNMU'd libgnatcoll again on armhf, and libgnatcoll-bindings again
on armel, armhf, hppa and powerpc, this should get the +b1 versions
aligned and get libgnatcoll-db built.

Regards
Graham

Bug#1070400: ITP: lomiri-weather-app -- Weather App for Lomiri Operating Environment

[Mike Gabriel]

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

* Package name: lomiri-weather-app
  Version : 5.13.5
  Upstream Contact: Daniel Frost
* URL : 
https://gitlab.com/ubports/development/apps/lomiri-weather-app
* License : GPL-3
  Programming Lang: C++/QML
  Description : Weather App for Lomiri Operating Environment

 This app is a core app for Ubuntu Touch's shell Lomiri. Ubuntu Touch is
 a mobile OS developed by the UBports Foundation. Lomiri is its operating
 environment optimized for touch based human-machine interaction, but
 also supports convergence (i.e. switching between tablet/phone and
 desktop mode).
 .
 This package provides Lomiri's Weather App.
 .
 The package will be maintained by the Debian UBports Packaging Team.

Bug#1070354: addition: this refers to "cachevol" type volumes, not "cachepool"

[Alex Volkov]

Also, probably fixed by this commit upstream:

https://gitlab.com/lvmteam/lvm2/-/commit/a985d5c63dd15d1114dac3caccd7aae89a732c38


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

Bug#1070399: RM: pmix [armel armhf i386] -- RoQA; NBS; no arch-specific reverse dependencies

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: p...@packages.debian.org
Control: affects -1 src:pmix

Please remove pmix on 32-bit architectures. It is no longer built
there and its only reverse dependency, openmpi has already been
updated to only use pmix on 64-bit architectures.

This will allow several packages to migrate from Unstable to Testing
(it is one of the blockers for gst-plugins-bad1.0).

Thank you,
Jeremy Bícha

Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu

[Otto Kekäläinen]

control: forward -1 https://github.com/codership/galera/issues/659
control: forwarded -1 https://github.com/codership/galera/issues/659

Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu

[Otto Kekäläinen]

Forwarded: https://github.com/codership/galera/issues/659

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Santiago Vila]

found 1064486 0.16.3-1
tags 1064486 + ftbfs bookworm trixie sid
thanks

El 20/4/24 a las 14:12, Andreas Metzler escribió:

FWIW I also get testsuite errors on current sid on amd64
The following tests FAILED:
  83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
  90 - rnp_tests.test_ffi_security_profile (Failed)
 174 - rnp_tests.test_key_add_userid (Failed)
 254 - cli_tests-EncryptElgamal (Failed)


Hello. This is also happening in bookworm, I assume that for the same 
underlying reason,
so I'm adding the bookworm version.

I've put several build logs (both successful and failed, to compare) here:

https://people.debian.org/~sanvila/build-logs/bookworm/

Note that in those build logs I'm using different sbuild backends, but I believe
they are not the reason why now it fails while it did not before.
I suspect of openssl, but I have not made any test to confirm.

Thanks.

Bug#1070398: gvfs-daemons: gvfs-udisks2-volume-monitor sigsegv at start

[Tomka Gergely]

Package: gvfs-daemons
Version: 1.54.0-1+b1
Severity: important
X-Debbugs-Cc: tomkatudor+...@gmail.com

Dear Maintainer,

I noticed that since upgrading to Trixie at login and when opening any
file menu in any application there is a cca minute long pause. I went
through checking things to a similar issue on Ubuntu where the problem
was that gvfs-udisks2-volume-monitor was not running. I have seen that
it does not runs here, and tried to start it, with the below result:

$ /usr/libexec/gvfs-udisks2-volume-monitor
(process:7253): GLib-CRITICAL **: 21:08:48.024: g_utf8_collate_key: assertion 
'str_norm != NULL' failed
Segmentation fault

I installed the version from Bookworm, did not help.

Warm Regards,

tg

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

Kernel: Linux 6.8.9-1-liquorix-amd64 (SMP w/12 CPU threads; PREEMPT)
ozegmentálási hiba
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gvfs-daemons depends on:
ii  gvfs-common  1.54.0-1
ii  gvfs-libs1.54.0-1+b1
ii  libbluray2   1:1.3.4-1+b1
ii  libc62.37-19
ii  libglib2.0-0t64  2.78.4-7
ii  libgudev-1.0-0   238-5
ii  libsecret-1-00.21.4-1+b1
ii  libsystemd0  255.5-1
ii  libudisks2-0 2.10.1-5
ii  lsof 4.95.0-1.1
ii  udisks2  2.10.1-5

Versions of packages gvfs-daemons recommends:
ii  dbus  1.14.10-4+b1
ii  gvfs  1.54.0-1+b1

Versions of packages gvfs-daemons suggests:
ii  gvfs-backends  1.54.0-1+b1

-- debconf-show failed

Bug#1070397: pistache: Please disable network tests in bookworm as well

[Santiago Vila]

Package: src:pistache
Version: 0.0.5+ds-3
Severity: serious
Tags: bookworm ftbfs
Control: fixed -1 0.0.5+ds-4

Dear maintainer:

Please disable network tests in bookworm as well, as they have started to fail
even when network access is allowed during build:

[ RUN  ] net_test.address_creation
../tests/net_test.cc:110: Failure
Expected equality of these values:
  address15.host()
Which is: "93.184.215.14"
  "93.184.216.34"
[  FAILED  ] net_test.address_creation (1 ms)

The test apparently expects www.example.com to have 93.184.216.34
as its IP address, but now it's 93.184.215.14.

Thanks.

Bug#1070396: exim4: FTBFS on hurd-i386

[Svante Signell]

Source: exim4
Version: 4.97-8
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

exim4 FTBFS on hurd-i386, but built before. Latest successful build
was 4.94-19. Attached are two patches enabling a successful build:

- exim_monitor_em_hdr.h:
em_hdr.h includes macros.h but not exim.h, which defines PATH_MAX, but
that header file cannot cannot be included. Instead define PATH_MAX
directly in em_hdr.h to avoid the error occurring when macros.h is
included.

- src_tls-gnu.c.patch:
Define tls_{client,server}_creds_invalidate() for Hurd too by adding
#defined(__GNU__) to the condition. Functions gnutls_priority_deinit()
and gnutls_certificate_free_credentials() already defined in
libgnutls.so.30 (and libgnutls.a)

Thanks!


--- a/src/tls-gnu.c	2023-11-04 13:55:49.0 +0100
+++ b/src/tls-gnu.c	2024-05-04 17:02:04.0 +0200
@@ -1720,7 +1720,7 @@
 }
 
 
-#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT)
+#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT) || defined(__GNU__)
 /* Invalidate the creds cached, by dropping the current ones.
 Call when we notice one of the source files has changed. */
  
Index: exim4-4.97/exim_monitor/em_hdr.h
===
--- exim4-4.97.orig/exim_monitor/em_hdr.h
+++ exim4-4.97/exim_monitor/em_hdr.h
@@ -99,6 +99,10 @@ this interface so that this kind of klud
 typedef void * hctx;
 
 #include "local_scan.h"
+/* PATH_MAX is defined in exim.h but cannot be included here */
+#ifndef PATH_MAX
+#define PATH_MAX 1024
+#endif
 #include "macros.h"
 #include "structs.h"
 #include "blob.h"

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Dne 01.05.2024 (sre) ob 23:09 +0200 je Samo Pogačnik napisal(a):
> Hi Daniel,
> 
> After installing our current 'git-subrepo' deb i noticed, that bash-completion
> integration with git does not work. The git-subrepo's own bash completion
> works,
> after you've already typed the first two words 'git subrepo TAB TAB', but the
> initial recognition of the 'subrepo' sub-command to the 'git' command does not
> work.
> 
> It turns out, that current git (bash-completion) in sid does not recognize our
> 'git-subrepo' executables installed by default into the git-core directory.
> The
> git bash-completion support finds git sub-commands using the 'git --list-
> cmds=comma-separated-list-of-cmdgroups', which executes a specific search for
> each group. Unfortunately none of the searches brings up the 'subrepo' sub-
> command. I do not know what is needed for the 'git-subrepo' inside 'git-core'
> to
> be recognized there. However i noticed, that the --list-cmds group 'other'
> scans
> the /usr/bin/ directory, where our old friend 'git-debrebase' and friends
> already reside and are being successfully recognized by git. Thus i prepared a
> change (in my salsa repo: in 
> https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the
> target installation directory, which seems to work.
> 
> Could you please take a look, how that holds water in debian.
> 
> thanks, Samo

Unfortunately, lintian is not happy with my solution above (does not allow
subdirs in /usr/bin and however git-subrepo script searches its helper functions
in git-subrepo.d subdir in the location of main git-subrepo script).

I managed to prepare another solution, without changing upstream sources in a
way to move 'git-subrepo' executable scripts into /usr/libexec/git-subrepo and
by adding a symlink to main git-subrepo executable into /usr/bin. That way bash-
completion integration works as in the initial solution and lintian is also
happy.

I pushed (forced) the new solution over the previous one.

regards, Samo 

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

After installing our current 'git-subrepo' deb i noticed, that bash-completion
integration with git does not work. The git-subrepo's own bash completion works,
after you've already typed the first two words 'git subrepo TAB TAB', but the
initial recognition of the 'subrepo' sub-command to the 'git' command does not
work.

It turns out, that current git (bash-completion) in sid does not recognize our
'git-subrepo' executables installed by default into the git-core directory. The
git bash-completion support finds git sub-commands using the 'git --list-
cmds=comma-separated-list-of-cmdgroups', which executes a specific search for
each group. Unfortunately none of the searches brings up the 'subrepo' sub-
command. I do not know what is needed for the 'git-subrepo' inside 'git-core' to
be recognized there. However i noticed, that the --list-cmds group 'other' scans
the /usr/bin/ directory, where our old friend 'git-debrebase' and friends
already reside and are being successfully recognized by git. Thus i prepared a
change (in my salsa repo: in 
https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the
target installation directory, which seems to work.

Could you please take a look, how that holds water in debian.

thanks, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Dne 25.04.2024 (čet) ob 12:59 +0200 je Daniel Gröber napisal(a):
> On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote:
> > Ok, so i'll prepare merge request in salsa gitlab, after pushing my
> > change in my working branch?
> 
> So creating a MR is fine but it's not the whole story with gbp. With gbp
> you're always dealing with both a debian and an upstream branch so the MR
> model doesn't fit since it just deals with the one branch you point it
> at. That doesn't really hurt as long as you remember to push your upstream
> branch also since I won't be pressing that merge button on the web ui
> anyway.
> 
> Technically I can still just assume your upstream branch points to the
> upstream/* tag you push -- assuming you don't forget to push the upstream
> tag. Seriously this workflow has so many trap doors for DMs it's insane :)
> 
> Anyway. What I want to see is a nice linear series of sensible commits with
> your packaging changes and one merge to bring in the new upstream [history]
> on the debian branch, the conventional upstream/* tag and the corresponding
> upstream branch which should be fast-forward from the previous upstream
> history.
> 
> [history]: That's the one default gbp workflow tweak I insist on when it's
> possible i.e. when the need for dealing with tarballs doesn't get in the
> way. I want git-blame to work in packaging repos. It's increadibly valuable
> for debugging but squashing the upstream changes as import-orig defaults to
> looses most of that context.
> 
> So you should be doing something like this:
> 
> $ git remote add upstream https://github.com/ingydotnet/git-subrepo.git
> $ git fetch upstream
> $ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch
>   # changes and create the merge
> $ gbp dch
> 
> $ gbp buildpackage [...sbuild runes...]
> 
> $ git push --tags salsa debian/sid upstream
> 
> There's also `gbp push` to make the git-push easier but it only works after
> doing a `gbp tag` to create the debian/* tag. This is however inappropriate
> for you as DM to do as the convention is to have the debian tag correspond
> to what I upload not what you propose to me :)
> 
> On my side I'll do:
> 
> $ gbp pull samo
> 
> $ gbp buildpackage [...sbuild runes...]
> 
> $ gbp tag# creates the debian/* tag
> $ debrelease   # upload to ftp-master
> $ gbp push salsa
> 
> Hope that gives you something more actionable than my previous mails.
> 
Thanks for this explanation. I suppose we shall apply this workflow upon the
git-repo, that you are going to push into the debian/* namespace.

As i understand, we are going to push and pull our changes from the same
branches of the sam git-repo, however i got a bit confused by your 'gbp pull
samo' command which indicates another git-repo involved. If your initial command
should've been 'gbp pull salsa', then it is clear to me. 
   
> > > PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do
> like to keep Debian work public and that includes teaching new
> contributors, do you mind if I copy our conversation back to the BTS?
I do not mind at all.

--Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote:
> Ok, so i'll prepare merge request in salsa gitlab, after pushing my
> change in my working branch?

So creating a MR is fine but it's not the whole story with gbp. With gbp
you're always dealing with both a debian and an upstream branch so the MR
model doesn't fit since it just deals with the one branch you point it
at. That doesn't really hurt as long as you remember to push your upstream
branch also since I won't be pressing that merge button on the web ui
anyway.

Technically I can still just assume your upstream branch points to the
upstream/* tag you push -- assuming you don't forget to push the upstream
tag. Seriously this workflow has so many trap doors for DMs it's insane :)

Anyway. What I want to see is a nice linear series of sensible commits with
your packaging changes and one merge to bring in the new upstream [history]
on the debian branch, the conventional upstream/* tag and the corresponding
upstream branch which should be fast-forward from the previous upstream
history.

[history]: That's the one default gbp workflow tweak I insist on when it's
possible i.e. when the need for dealing with tarballs doesn't get in the
way. I want git-blame to work in packaging repos. It's increadibly valuable
for debugging but squashing the upstream changes as import-orig defaults to
looses most of that context.

So you should be doing something like this:

$ git remote add upstream https://github.com/ingydotnet/git-subrepo.git
$ git fetch upstream
$ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch
  # changes and create the merge
$ gbp dch

$ gbp buildpackage [...sbuild runes...]

$ git push --tags salsa debian/sid upstream

There's also `gbp push` to make the git-push easier but it only works after
doing a `gbp tag` to create the debian/* tag. This is however inappropriate
for you as DM to do as the convention is to have the debian tag correspond
to what I upload not what you propose to me :)

On my side I'll do:

$ gbp pull samo

$ gbp buildpackage [...sbuild runes...]

$ gbp tag# creates the debian/* tag
$ debrelease   # upload to ftp-master
$ gbp push salsa

Hope that gives you something more actionable than my previous mails.

> > Have you found any docs for this workflow?
> Not really, it was just an idea while reading about gbp and git-debrebase.

Right, that's what I figured but I wasn't sure :)

> > I've thought about it some more and perhaps we should for now use something
> > simpler (plain gbp) until you get the hang of it and/or the (unapplied)
> > patches actually get in the way.
>
> I agree, i just found my fork of your git-subrepo a nice small playground. As 
> an
> exercise i've converted it into a git-debrebase tree (via: man 7 
> git-debrebase:
> 'converting an existing package').

Playing with this stuff sure is important to figure out whats going on ;)

--Daniel

PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do
like to keep Debian work public and that includes teaching new
contributors, do you mind if I copy our conversation back to the BTS?


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

Dne 24.04.2024 (sre) ob 17:33 +0200 je Daniel Gröber napisal(a):
> I'll push the repo there and give you access, you just have to adjust the
> Vcs-* fields and get those changes to me in a way that I actually want to
> accept them ;P
> 
> FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but
> I'm still trying to hone your git collab maintanance skillz :)
> 
Ok, so i'll prepare merge request in salsa gitlab, after pushing my change in my
working branch?

> > idea was to reverse the gbp's view on its branches, where the debian/sid
> > is the continuous branch and the patch-queue branches are the
> > intermediate and temporary ones.
> 
> I have to admit I've never really considered this to be a possible
> workflow. Honestly I don't think it's a good idea to hold a loaded gun
> (gbp) the wrong way round ;)
> 
> Have you found any docs for this workflow?
Not really, it was just an idea while reading about gbp and git-debrebase.

> 
> > In this experiment i am trying to have the patch-queue branch the main
> > continuous branch, brought (by any git means) to the state, where one
> > could do 'gbp pq export' to a fresh debian/sid branch rooted before any
> > upstream commits grouped at the end of the patch-queue branch.
> 
> git-subrepo is a relatively simple upstream so I would really not deviate
> from established and documented workflows for it. I get you probably want
> to explore the possible git workflows in Debian and admittedly my idea to
> use git-debrebase is probably also severe overkill (and I'm also guilty of
> just wanting to play with it too ;).
> 
> I've thought about it some more and perhaps we should for now use something
> simpler (plain gbp) until you get the hang of it and/or the (unapplied)
> patches actually get in the way.
I agree, i just found my fork of your git-subrepo a nice small playground. As an
exercise i've converted it into a git-debrebase tree (via: man 7 git-debrebase:
'converting an existing package').

regards, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

Dne 12.04.2024 (pet) ob 16:02 +0200 je Daniel Gröber napisal(a):
> 
> +git-subrepo (0.4.6-1) unstable; urgency=medium
> +
> +  [ Daniel Gröber ]
> +  * Fix Vcs URLs, s/guest-dxld/dxld-guest/
> +  * Update changelog for 0.4.3-2 release
> 
> Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does
> usually filter those out.
> 
> +  * Add salsa-ci config
> +  * Revert "Update changelog for 0.4.3-2 release"
> 
> I would collapse such VCS artifacts too since the changelog is from the
> perspective of "what changed since the last version" in the end, not a blow
> by blow of the git changes we used to get there. It's a judgement call tho.
> 
> +
> +  [ Samo Pogačnik ]
> +  * Updated debian/control info
> 
> Needs to be a lot more specifict than that. In d/changelog you're talking
> to two main groups of readers: other Debian contibutors (i.e. me) and
> actual end users. Does this tell me what I need to know to figure out why
> you made that change? Not really.
> 
> Looking at the diff it should have even been two commits "d/control: Point
> Vcs at samo" and "d/control: Make myself Maintainer".
> 

Thanks for the review. I followed your suggestions above and recommited
d/control and
d/changelog.

> As for the Vcs change: I'd prefer if we put the git repo in the debian/*
> namespace on Salsa.
> 

Here i am not sure who can / how to do this?

> > I also made another git-subrepo_rebase project (
> > https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with
> > rebasing of debian branch onto each renewed upstream. I assume rebasing
> > workflow
> > shoud somehow avoid commiting patch series into main-working branch. I
> > understood git-debrebase figured that out, but ... (see below)
> 
> I have a hard time figuring out what is going on in your repos. Damn I
> already hate gbp from a review standpoint.
> 
> I'm not sure you've internalized this, with gbp you really don't want to do
> any manual git-pull/git-merge calls. Let it do it throught it's
> gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of
> me when I try to review the package.
> 

I feel i owe you more explanation of what i am trying to achieve here
(now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The idea was
to reverse the gbp's view on its branches, where the debian/sid is the
continuous
branch and the patch-queue branches are the intermediate and temporary ones. In
this experiment i am trying to have the patch-queue branch the main continuous
branch, brought (by any git means) to the state, where one could do 'gbp pq
export'
to a fresh debian/sid branch rooted before any upstream commits grouped at the
end of
the patch-queue branch.

So, when a new upstream version is to be integrated (after pulling the upstream
repo):
---
1. a copy of current patch-queue/debian/sid branch is to be made for future
reference and current debian/sid branch renamed (i.e. *debian/upstream_version).

2. rebasing main patch-queue branch onto upstream at its new release

3. squashing existing d/* commits of previous releases into a single commit

4. do any necessary work on d/* and upstream code to make things work in new
version

5. rebase/reorder commits after the squashed commit on patch-queue branch to
put any d/* commits in front of any upstream commits

6. create a new debian/sid branch from the latest d/* commit

7. on patch-queue branch run 'gbp pq export' to generate final changes (patches)
on new debian/sid
---

For each new debian release (same upstream), a similar procedure is needed:
---
1. a copy of current patch-queue/debian/sid branch is to be made for future
reference and current debian/sid branch renamed (i.e. *debian/debian_version).

2. do any necessary work on d/* and upstream code to make things work in new
debian release

3. rebase/reorder new commits on the patch-queue branch to put any d/* commits
in front of any upstream commits

4. create a new debian/sid branch from the latest d/* commit

5. on patch-queue branch run 'gbp pq export' to generate final changes on new 
debian/sid
---

The main problem i face is:
How to run test builds directly from patch queue branch to get equivalent
'snapshot' results as from the final debian/sid branch?
 
> > I watched video about git-debrebase and it seemed reasonable to me at first,
> > however they lost me when dgit and pushing to dgit repo got into play.
> 
> The history structure does get a bit confusing yeah. My main takeway:
> "patches applied" workflows exist *mind blown*. I hadn't seen that yet,
> exactly what I've been looking for since gbp-pq sucks and quilt is no
> better. I just want to use striaght up git damn it and that's what
> debrebase and dgit seems to let you do :)
> 

I somehow managed to avoid quilt until now so i can not really comment it, but
i agree that having a patched git branch is light years better than having a
series of patches acompanying the original code.

> 
> I'm actually tending to just 

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

Dne 18.03.2024 (pon) ob 13:55 +0100 je Daniel Gröber napisal(a):
> 
> A good place to start is https://wiki.debian.org/Packaging
> 
> If you prefer a talk format there's Lucas' (excellent) tutorial
> 
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
> I can't find a recording of it but the slides are pretty extensive.
> 
> In video format there is
> 
https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/
> but I can't vouch for that one.
> 
> We can also do a call to figure out where you're at and what info you need
> because the huge scope of the general packaging related documentation can
> be a bit overwhelming and confusing, even if what you need to know is like
> 5% of that.

Thanks for all your input, i'll try to setup the debian/build environment first
and go through the provided links. Which debian-specific tools do you find
essential in your workflow, so that i can focus on them while reading the docs?

regards, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a):
> Hi Samo,
> 
> wouldn't you know it I've become a DD before I got a response to the
> git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it
> just now.
> 
> Are you still interested in maintaining git-subrepo in Debian?
> 
> I'm trying to limit my personal packaging work to stuff I actually use on a
> regular basis and apparently subrepo is not that essential, but as a DD I
> can now sponsor any uploads and help you with figuring out the Debian
> workflow and such though.
> 
> My packaging from way back when is at
> https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably
> needs a once over to check for updates necessary changes tho.
> 
> Thanks,
> --Daniel

Hi Daniel,

please excuse me for my late response, but my situation from 2020/21 when we
proposed the git-subrepo ITP changed in a way that i am spending most of my free
time off-line. With this on mind i am not sure, if i am responsive enough for a
maintainers job (i might be off-line for a few weeks from time to time).

However, i am tempted to push this through and give git-subrepo more audience.
Unfortunately i am more experienced in embedded Linux (yocto / openembedded /
bitbake) than in debian packaging and my desktop is more or less Ubuntu.

If you think that may shortcomings aren't that much of a showstopper, feel free
to send me your procedures/commands to deal with your salsa/git-subrepo repo.

I would very much appreciate any guidance regarding debian packaging procedures
and needed packaging/testing environment.

And of course congratulations on becoming a DD!

best regards, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Mon, Apr 15, 2024 at 09:13:03PM +0200, Samo Pogačnik wrote:
> Thanks for the review. I followed your suggestions above and recommited
> d/control and
> d/changelog.
> 
> > As for the Vcs change: I'd prefer if we put the git repo in the debian/*
> > namespace on Salsa.
> > 
> 
> Here i am not sure who can / how to do this?

I'll push the repo there and give you access, you just have to adjust the
Vcs-* fields and get those changes to me in a way that I actually want to
accept them ;P

FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but
I'm still trying to hone your git collab maintanance skillz :)

> I feel i owe you more explanation of what i am trying to achieve here
> (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The
> idea was to reverse the gbp's view on its branches, where the debian/sid
> is the continuous branch and the patch-queue branches are the
> intermediate and temporary ones.

I have to admit I've never really considered this to be a possible
workflow. Honestly I don't think it's a good idea to hold a loaded gun
(gbp) the wrong way round ;)

Have you found any docs for this workflow?

> In this experiment i am trying to have the patch-queue branch the main
> continuous branch, brought (by any git means) to the state, where one
> could do 'gbp pq export' to a fresh debian/sid branch rooted before any
> upstream commits grouped at the end of the patch-queue branch.

git-subrepo is a relatively simple upstream so I would really not deviate
from established and documented workflows for it. I get you probably want
to explore the possible git workflows in Debian and admittedly my idea to
use git-debrebase is probably also severe overkill (and I'm also guilty of
just wanting to play with it too ;).

I've thought about it some more and perhaps we should for now use something
simpler (plain gbp) until you get the hang of it and/or the (unapplied)
patches actually get in the way.

> So, when a new upstream version is to be integrated (after pulling the
> upstream repo):

tl;dr honestly.

Look, we already have too many possible workflows for git maint. in Debian
adding a new one that doesn't have wide usage yet isn't going to help
unless it brings something new to the table. So how does this compare to
the other 50 workflows? :^)

> I feel/hope debrebase is doing something similar as my little experiment but
> with all the debian specific bells and whistles, i am currently not even aware
> of. I would say that, if dgit/debrebase provides a workflow without messing
> with patch-sets (and tarballs), then this is the tool...

There's no escaping tarballs in Debian :3

Except maybe with dgit but even then you need to think about calling
origtargz...

*chanting* In the tarball, part of the tarball, in the tarball, part of the
 tarball ...[ad nauseam]

https://youtu.be/SxGjdx1NXfg?feature=shared=49 and also:
https://www.youtube.com/watch?v=EM9kl6jY09A

--Daniel


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Mon, Apr 08, 2024 at 09:01:24PM +0200, Samo Pogačnik wrote:
> > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet:
> > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html
> > (note the navigation buttons in the top right)
>
> Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo
> according to gbp manual and now i am not sure if generated changelog is ok.

You can just edit the changelog `gbp dch` generates. I do find it fucks up
most of the time the way I use it and just edit it. I am starting to think
gbp is more trouble that it's worth now that I'm starting to look at some
of the other workflows...

+git-subrepo (0.4.6-1) unstable; urgency=medium
+
+  [ Daniel Gröber ]
+  * Fix Vcs URLs, s/guest-dxld/dxld-guest/
+  * Update changelog for 0.4.3-2 release

Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does
usually filter those out.

+  * Add salsa-ci config
+  * Revert "Update changelog for 0.4.3-2 release"

I would collapse such VCS artifacts too since the changelog is from the
perspective of "what changed since the last version" in the end, not a blow
by blow of the git changes we used to get there. It's a judgement call tho.

+
+  [ Samo Pogačnik ]
+  * Updated debian/control info

Needs to be a lot more specifict than that. In d/changelog you're talking
to two main groups of readers: other Debian contibutors (i.e. me) and
actual end users. Does this tell me what I need to know to figure out why
you made that change? Not really.

Looking at the diff it should have even been two commits "d/control: Point
Vcs at samo" and "d/control: Make myself Maintainer".

As for the Vcs change: I'd prefer if we put the git repo in the debian/*
namespace on Salsa.

+
+ -- Samo Pogačnik   Sun, 07 Apr 2024 19:31:14 +


> I also made another git-subrepo_rebase project (
> https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with
> rebasing of debian branch onto each renewed upstream. I assume rebasing 
> workflow
> shoud somehow avoid commiting patch series into main-working branch. I
> understood git-debrebase figured that out, but ... (see below)

I have a hard time figuring out what is going on in your repos. Damn I
already hate gbp from a review standpoint.

I'm not sure you've internalized this, with gbp you really don't want to do
any manual git-pull/git-merge calls. Let it do it throught it's
gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of
me when I try to review the package.

> > I wish we could use a rebase workflow with gbp but I haven't found a way to
> > do it yet. At least not with gbp import-ref as-is. We could work on a patch
> > for it I suppose ;)
> > 
> I think i am a bit too green for that

Maybe, maybe not. Only one way to find out.

> I watched video about git-debrebase and it seemed reasonable to me at first,
> however they lost me when dgit and pushing to dgit repo got into play.

The history structure does get a bit confusing yeah. My main takeway:
"patches applied" workflows exist *mind blown*. I hadn't seen that yet,
exactly what I've been looking for since gbp-pq sucks and quilt is no
better. I just want to use striaght up git damn it and that's what
debrebase and dgit seems to let you do :)


I'm actually tending to just jumping onto dgit. Should actually make things
easier for you once I figure out how it works. There's even nice docs for
the sponsorship workflow
https://manpages.debian.org/testing/dgit/dgit-sponsorship.7.en.html unlike
with gbp where upload sponsorship seems to just not have been considered in
it's design if my DM experience with it is any indication :D

Opinions?

--Daniel


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Sun, Mar 31, 2024 at 01:42:48PM +0200, Samo Pogačnik wrote:
> I prepared a new git-subrepo in salsa as a fork of your project (
> https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and 
> prepared
debby> a new 'debian/sid' branch. Would you be so kind to take a look at it and 
comment
> on what should be changed/fixed and how to proceed.

You removed the (Closes Bug#) ITP reference from d/changelog. It's policy
to close that but with the first upload, so you have to keep it.

Workflow wise I don't see why you needed to make a merge commit at
d0cc659. Can you explan what you were doing?

On Wed, Mar 27, 2024 at 07:27:31PM +0100, Samo Pogačnik wrote:
> Thank you for the valuable information. Currently i managed to reactivate my
> Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was
> also able to setup debian-sid chrooted environment on my old Ubuntu laptop up 
> to
> the point that i think i can successfully rebuild your current 'git-subrepo'
> project using the following commands after entering 'debian-sid' (schroot -c
> debian-sid):

> $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git

I don't use pristine-tar unless absolutely required (due to DFSG repacking
or some such), gbp defaults to using git-archive to generate tarballs so
just leave off the pristine-tar options.

Packaging repos usually declare whether they use pristine-tar in d/gbp.conf
so there should rarely be a need to fiddle with the options here.

> $ cd git-subrepo
> $ gbp buildpackage  --git-pristine-tar-commit

Don't use --git-pristine-tar-commit. Proper proceedure is to do that
explicitily using gbp import-org (if using that).

There's another option for importing upstream sources which I prefer (but
that is a bit of a PITA): `gbp import-ref` it is a pure git workflow
leaving the tarball hassle to gbp and that preserves upstream git history
and git-blame'ability.

Admittedly it's not very widely used in Debian ATM (which may change thanks
to the current xz kerfluffle) so docs may be lacking. Let me know if you
can't figure it out.

> I hope this is the correct procedure - i wasn't very confident seing 'sbuild'
> requireing another 'chroot' from within my original 'chroot', however it seems
> to be working now?

Seems ok, but building in "clean" chroots (using sbuild) is strongly
preferred for real testing.

sbuild calls schroot internally. You run it from your system like
normal. You just have to configure a tell it which base chroot to use and
that chroot needs special handling to be as close to the buildd ones as
feasible. Relevant chroot bootstrapping tools often have an
"sbuild"/"buildd" mode.

I tend to use sbuild-createchroot(8) from ubuntu-dev-tools for chroot
building, but debspawn is probably orders of magnitudes easier as far as
setup and maintainance of the environments is concerned.

> My plan now is to fork your git-subrepo project, fetch latest upstream changes
> and rebuild the latest version. Would that be ok to get to the point, when a 
> new
> ITP could have been issued?

You don't need a new ITP, it's still open and valid. If you want to be
proper you can change the "owner" field to yourself. Send an email to
cont...@bugs.debian.org, see
https://www.debian.org/Bugs/server-control. Good practice for interacting
with the BTS anyway.

> > https://github.com/lkhq/debspawn looks really neat and tidy but may be
> > untrodden ground. Could be workable if you feel up to trying it. I would
> > also be curios to know if it works well. See
> > https://github.com/lkhq/debspawn/issues/27 for some discussion between
> > ximion (the author) and josh (sbuild maintainer) how it compares against
> > sbuild.
> > 
> I might try debspawn on another 'non-debian' 'nixos-based' machine, but this 
> may
> not happen very quickly. As i understood, it only requires a systemd-based
> Linux.

I wouldn't trust it working outside of Debian. It's a Debian tool for and
by Debian people.

> > Aah, it's nice and warm in the jungle but simetimes you get lost between
> > all the vines~
>
> I get lost a lot. Three years ago even so that i created new docker-pbuilder-
> based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my
> head around debian ways. You can imagine that the project wasn't accepted very
> well on debian-devel:).

c.f. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence

While sometimes we may need to build to understand others need to see you
understand before they let you build on their land ;-)

--Daniel


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

wouldn't you know it I've become a DD before I got a response to the
git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it
just now.

Are you still interested in maintaining git-subrepo in Debian?

I'm trying to limit my personal packaging work to stuff I actually use on a
regular basis and apparently subrepo is not that essential, but as a DD I
can now sponsor any uploads and help you with figuring out the Debian
workflow and such though.

My packaging from way back when is at
https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably
needs a once over to check for updates necessary changes tho.

Thanks,
--Daniel

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Mon, Apr 01, 2024 at 07:54:09PM +0200, Samo Pogačnik wrote:
> > Workflow wise I don't see why you needed to make a merge commit at
> > d0cc659. Can you explan what you were doing?
>
> Well, after i updated the upstream branch, i wanted to preserve your
> original debian/sid branch, so i renamed it and merged it into the new
> debian/sid branch, based at the latest 0.4.6 release tag of the upstream
> branch.
> 
> Actually, this is the point, where i need to learn, how debian/sid branch
> is to be managed in a 'debianized' git repo through upstream updates?

Right, that's not how to do things in a git-buildpackage repo. See the
problem gbp is solving is that Debian source packages (.dsc) are composed
of two parts (tarballs) the upstream part (.orig.tar.*) and the debian part
(debian.tar.*). To represent this in git gbp has the concept of an upstream
branch and a debian branch.

When updating your gbp packaging repo to a new upstream version you have to
update the upstream branch pointer and merge that into the debian branch
separately. import-orig and import-ref will do this for you as it's a
hassle.

Honestly I really hate this part of gbp's design. Having two branches is
just such a hassle to manage and makes all the operations gbp performs
non-atomic and it has to support rollback of whatever it has already tried
to do in case anything (say a git-merge) fails down the line ... it's a
mess.

There are other git workflows in use in Debian, eg. dgit, but they're even
harder to get your head around, or at least I haven't managed to, so gbp it
is for now :/

Anyway gbp has reasonably good documentation, maybe you haven't seen it yet:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html
(note the navigation buttons in the top right)

> > I don't use pristine-tar unless absolutely required (due to DFSG repacking
> > or some such), gbp defaults to using git-archive to generate tarballs so
> > just leave off the pristine-tar options.
> > 
> > Packaging repos usually declare whether they use pristine-tar in d/gbp.conf
> > so there should rarely be a need to fiddle with the options here.
> > 
> I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to
> 'False' i can simply run 'gbp buildpackage'. Would you recommend setting
> 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo?

Oh I didn't even know gbp has a user config file. That seems
ill-concieved. Gah.

Yeah I would strongly reccomend not messing with the pristine-tar option in
the user-config. We could explicitly set it =False in d/gbp.conf but I'd
rather not as I don't think that's commonly done at all though I can find a
number of occurrences in my Debian packaging workdir.

> > There's another option for importing upstream sources which I prefer (but
> > that is a bit of a PITA): `gbp import-ref` it is a pure git workflow
> > leaving the tarball hassle to gbp and that preserves upstream git history
> > and git-blame'ability.
> > 
> > Admittedly it's not very widely used in Debian ATM (which may change thanks
> > to the current xz kerfluffle) so docs may be lacking. Let me know if you
> > can't figure it out.
> > 
> something new for me to digest:) Actually i preserved upstream history in
> my manual git-subrepo upstream branch update and lost your history in new
> debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer
> upstream could solve that as well...

I wish we could use a rebase workflow with gbp but I haven't found a way to
do it yet. At least not with gbp import-ref as-is. We could work on a patch
for it I suppose ;)

I just want to avoid using a custom script to import upstream sources if at
all possible. Debian already has too much fude factor in packaging.

> > sbuild calls schroot internally. You run it from your system like
> > normal. You just have to configure a tell it which base chroot to use and
> > that chroot needs special handling to be as close to the buildd ones as
> > feasible. Relevant chroot bootstrapping tools often have an
> > "sbuild"/"buildd" mode.
> > 
> > I tend to use sbuild-createchroot(8) from ubuntu-dev-tools
> > for chroot
> > building, but debspawn is probably orders of magnitudes easier as far as
> > setup and maintainance of the environments is concerned.
>
> Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild)
> to create chroot used by sbuild, however sbuild is not run from my old
> ubuntu host directly, but from 'schroot -c debian-sid' prepared
> previously (see:
> https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild)

I don't see why that would be necessary though? Ubuntu also uses sbuild,
the version in their archive should work just fine for our purposes as long
as you make it use a Debian chroot.

--Daniel


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

I prepared a new git-subrepo in salsa as a fork of your project (
https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and prepared
a new 'debian/sid' branch. Would you be so kind to take a look at it and comment
on what should be changed/fixed and how to proceed.

thanks, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

Dne 24.03.2024 (ned) ob 17:46 +0100 je Daniel Gröber napisal(a):
> For building I use debuild or git-buildpackage+sbuild depending on context.
> 
> I create chroots for sbuild with a wrapper script around
> sbuild-createchroot using btrfs-snapshots for efficiency.
> 
> To keep working on a package without having to reinstall the entire
> dependency tree (as sbuild does) every time I tweak sbuild's
> --anything-failed-commands or use schroot directly with a different chroot
> profile setup which has my homedir mounted.
> 
> I'm not sure all of that is the easiest setup these days. It certainly
> needs "gardening" to keep it updated and in-sync between both my laptop and
> workstation and I have been looking into alternatives.
> 
Thank you for the valuable information. Currently i managed to reactivate my
Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was
also able to setup debian-sid chrooted environment on my old Ubuntu laptop up to
the point that i think i can successfully rebuild your current 'git-subrepo'
project using the following commands after entering 'debian-sid' (schroot -c
debian-sid):
$ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git
$ cd git-subrepo
$ gbp buildpackage  --git-pristine-tar-commit
$ gbp buildpackage

I hope this is the correct procedure - i wasn't very confident seing 'sbuild'
requireing another 'chroot' from within my original 'chroot', however it seems
to be working now?

My plan now is to fork your git-subrepo project, fetch latest upstream changes
and rebuild the latest version. Would that be ok to get to the point, when a new
ITP could have been issued?

> https://github.com/lkhq/debspawn looks really neat and tidy but may be
> untrodden ground. Could be workable if you feel up to trying it. I would
> also be curios to know if it works well. See
> https://github.com/lkhq/debspawn/issues/27 for some discussion between
> ximion (the author) and josh (sbuild maintainer) how it compares against
> sbuild.
> 
I might try debspawn on another 'non-debian' 'nixos-based' machine, but this may
not happen very quickly. As i understood, it only requires a systemd-based
Linux.

> When trying to understand how the build tools work and fit together keep in
> mind that debuild (the traditional default) is nothing but a wrapper around
> dpkg-buildpackage (which has a more extensive manpage) and passess most
> options down as-is. git-buildpackage (by default) wraps debuild (or
> optionally sbuild if you tell it to). sbuild allows building in chroots and
> has a number of fancy options to make that easy.
> 
> Aah, it's nice and warm in the jungle but simetimes you get lost between
> all the vines~
> --Daniel
I get lost a lot. Three years ago even so that i created new docker-pbuilder-
based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my
head around debian ways. You can imagine that the project wasn't accepted very
well on debian-devel:).

thanks again, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Fri, Mar 15, 2024 at 06:42:54PM +0100, Samo Pogačnik wrote:
> Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a):
> > Are you still interested in maintaining git-subrepo in Debian?
>
> please excuse me for my late response, but my situation from 2020/21 when
> we proposed the git-subrepo ITP changed in a way that i am spending most
> of my free time off-line. With this on mind i am not sure, if i am
> responsive enough for a maintainers job (i might be off-line for a few
> weeks from time to time).

Given that git-subrepo doesn't have much upstream activity these days I
don't find that very concerning at all. In fact Debian development is
pretty well suited to an offline workflow -- if only because the tools we
use were designed so long ago that having no internet was still common ;)

Only thing I would recommend you get yourself is a setup where you can
send/read your email offline and without Debian stuff getting lost.

As long as you surface regularly and especially some time before it's
release'o'clock it doesn't matter much. Worst case I'm expected to deal
with any packages under my sponsorship umbrella so the responsibility
doesn't rest enrirely on you anyway.

Now you may wonder "why don't I just do it then" and I just find having
someone else on board that cares (more intensly) about a package helps make
the drudgery of maintanance more fun ;)

> However, i am tempted to push this through and give git-subrepo more
> audience.  Unfortunately i am more experienced in embedded Linux (yocto /
> openembedded / bitbake) than in debian packaging and my desktop is more
> or less Ubuntu.

Not a big deal either. The packaging should mostly be done IIRC and since
subrepo is just a simple shell script it's about the simplest thing to
package I can imagine, no need to worry there.

The main job(s) of a maintainer are responding to bugs, fixing or
forwarding them, communicating with upstream and reviewing new versions,
perhaps writing new docs if you can see users struggling. All of which are
more about humans than about computer obscurities.

As for the Ubuntu bit. There are tons of ways to get a Debian development
environment on your system, I don't know what the easiest one is for you
since that depends on what you're familiar with. Docker is certainly
possible and AFAIK the dockerhub images are maintained by DDs.

You just have to keep in mind to build/test with Debian unstable since
that's where the actual development happens. Depending on whether you want
git-subrepo to also be available for the current release (bookworm) we
could also publish to the backports repo but that does double the amount of
package building/testing work we have to do.

> If you think that may shortcomings

I don't think about people that way, what you call shortcomings I call
*untapped potential* ;)

> I would very much appreciate any guidance regarding debian packaging
> procedures and needed packaging/testing environment.

A good place to start is https://wiki.debian.org/Packaging

If you prefer a talk format there's Lucas' (excellent) tutorial
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
I can't find a recording of it but the slides are pretty extensive.

In video format there is
https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/
but I can't vouch for that one.

We can also do a call to figure out where you're at and what info you need
because the huge scope of the general packaging related documentation can
be a bit overwhelming and confusing, even if what you need to know is like
5% of that.

> And of course congratulations on becoming a DD!

Yey, now the real work begins ;)

--Daniel

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

just a quick update.

Dne 01.04.2024 (pon) ob 23:07 +0200 je Daniel Gröber napisal(a):
> 
> Anyway gbp has reasonably good documentation, maybe you haven't seen it yet:
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html
> (note the navigation buttons in the top right)
> 
Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo
according to gbp manual and now i am not sure if generated changelog is ok.
I also made another git-subrepo_rebase project (
https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with
rebasing of debian branch onto each renewed upstream. I assume rebasing workflow
shoud somehow avoid commiting patch series into main-working branch. I
understood git-debrebase figured that out, but ... (see below)

> > > 
> I wish we could use a rebase workflow with gbp but I haven't found a way to
> do it yet. At least not with gbp import-ref as-is. We could work on a patch
> for it I suppose ;)
> 
I think i am a bit too green for that, however i may provide some crazy idea:)

I watched video about git-debrebase and it seemed reasonable to me at first,
however they lost me when dgit and pushing to dgit repo got into play.

regards, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Samo Pogačnik]

Hi Daniel,

Dne 31.03.2024 (ned) ob 16:01 +0200 je Daniel Gröber napisal(a):
> 
> You removed the (Closes Bug#) ITP reference from d/changelog. It's policy
> to close that but with the first upload, so you have to keep it.
> 
Fixed (even salsa pipeline is happy:).

> Workflow wise I don't see why you needed to make a merge commit at
> d0cc659. Can you explan what you were doing?
> 
Well, after i updated the upstream branch, i wanted to preserve your original
debian/sid branch, so i renamed it and merged it into the new debian/sid branch,
based at the latest 0.4.6 release tag of the upstream branch.

Actually, this is the point, where i need to learn, how debian/sid branch is to
be managed in a 'debianized' git repo through upstream updates?

> I don't use pristine-tar unless absolutely required (due to DFSG repacking
> or some such), gbp defaults to using git-archive to generate tarballs so
> just leave off the pristine-tar options.
> 
> Packaging repos usually declare whether they use pristine-tar in d/gbp.conf
> so there should rarely be a need to fiddle with the options here.
> 
I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to
'False' i can simply run 'gbp buildpackage'. Would you recommend setting
'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo?

> There's another option for importing upstream sources which I prefer (but
> that is a bit of a PITA): `gbp import-ref` it is a pure git workflow
> leaving the tarball hassle to gbp and that preserves upstream git history
> and git-blame'ability.
> 
> Admittedly it's not very widely used in Debian ATM (which may change thanks
> to the current xz kerfluffle) so docs may be lacking. Let me know if you
> can't figure it out.
> 
something new for me to digest:) Actually i preserved upstream history in my
manual git-subrepo upstream branch update and lost your history in new
debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer upstream
could solve that as well...

> sbuild calls schroot internally. You run it from your system like
> normal. You just have to configure a tell it which base chroot to use and
> that chroot needs special handling to be as close to the buildd ones as
> feasible. Relevant chroot bootstrapping tools often have an
> "sbuild"/"buildd" mode.
> 
> I tend to use sbuild-createchroot(8) from ubuntu-dev-tools
> for chroot
> building, but debspawn is probably orders of magnitudes easier as far as
> setup and maintainance of the environments is concerned.
> 
Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild) to
create chroot used by sbuild, however sbuild is not run from my old ubuntu host
directly, but from 'schroot -c debian-sid' prepared previously (see: 
https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild)

> You don't need a new ITP, it's still open and valid. If you want to be
> proper you can change the "owner" field to yourself. Send an email to
> cont...@bugs.debian.org, see
> https://www.debian.org/Bugs/server-control. Good practice for interacting
> with the BTS anyway.
> 
noted and thanks for valuable insights.

best regards, Samo

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

Hi Samo,

On Tue, Mar 19, 2024 at 10:00:44PM +0100, Samo Pogačnik wrote:
> > We can also do a call to figure out where you're at and what info you need
> > because the huge scope of the general packaging related documentation can
> > be a bit overwhelming and confusing, even if what you need to know is like
> > 5% of that.
> 
> Thanks for all your input, i'll try to setup the debian/build environment 
> first
> and go through the provided links. Which debian-specific tools do you find
> essential in your workflow, so that i can focus on them while reading the 
> docs?

For building I use debuild or git-buildpackage+sbuild depending on context.

I create chroots for sbuild with a wrapper script around
sbuild-createchroot using btrfs-snapshots for efficiency.

To keep working on a package without having to reinstall the entire
dependency tree (as sbuild does) every time I tweak sbuild's
--anything-failed-commands or use schroot directly with a different chroot
profile setup which has my homedir mounted.

I'm not sure all of that is the easiest setup these days. It certainly
needs "gardening" to keep it updated and in-sync between both my laptop and
workstation and I have been looking into alternatives.

https://github.com/lkhq/debspawn looks really neat and tidy but may be
untrodden ground. Could be workable if you feel up to trying it. I would
also be curios to know if it works well. See
https://github.com/lkhq/debspawn/issues/27 for some discussion between
ximion (the author) and josh (sbuild maintainer) how it compares against
sbuild.

When trying to understand how the build tools work and fit together keep in
mind that debuild (the traditional default) is nothing but a wrapper around
dpkg-buildpackage (which has a more extensive manpage) and passess most
options down as-is. git-buildpackage (by default) wraps debuild (or
optionally sbuild if you tell it to). sbuild allows building in chroots and
has a number of fancy options to make that easy.

Aah, it's nice and warm in the jungle but simetimes you get lost between
all the vines~
--Daniel


signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

[Daniel Gröber]

On Mon, Apr 01, 2024 at 11:07:50PM +0200, Daniel Gröber wrote:
> I wish we could use a rebase workflow with gbp but I haven't found a way to
> do it yet. At least not with gbp import-ref as-is. We could work on a patch
> for it I suppose ;)

Looking at git-debrebase (https://www.youtube.com/watch?v=iov10lD7tcg)
now. Looks promising, hmm.

--Daniel


signature.asc
Description: PGP signature

Bug#1070395: tinyproxy: CVE-2023-40533 CVE-2023-49606

[Moritz Mühlenhoff]

Source: tinyproxy
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for tinyproxy.

CVE-2023-40533[0]:
| An uninitialized memory use vulnerability exists in Tinyproxy 1.11.1
| while parsing HTTP requests. In certain configurations, a specially
| crafted HTTP request can result in disclosure of data allocated on
| the heap, which could contain sensitive information. An attacker can
| make an unauthenticated HTTP request to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2023-1902

CVE-2023-49606[1]:
| A use-after-free vulnerability exists in the HTTP Connection Headers
| parsing in Tinyproxy 1.11.1 and Tinyproxy 1.10.0. A specially
| crafted HTTP header can trigger reuse of previously freed memory,
| which leads to memory corruption and could lead to remote code
| execution. An attacker needs to make an unauthenticated HTTP request
| to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2023-1889


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40533
https://www.cve.org/CVERecord?id=CVE-2023-40533
[1] https://security-tracker.debian.org/tracker/CVE-2023-49606
https://www.cve.org/CVERecord?id=CVE-2023-49606

Please adjust the affected versions in the BTS as needed.

Bug#1070394: libstb: CVE-2023-47212

[Moritz Mühlenhoff]

Source: libstb
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libstb.

CVE-2023-47212[0]:
| A heap-based buffer overflow vulnerability exists in the comment
| functionality of stb _vorbis.c v1.22. A specially crafted .ogg file
| can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2023-1846


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-47212
https://www.cve.org/CVERecord?id=CVE-2023-47212

Please adjust the affected versions in the BTS as needed.

Bug#1070392: exiv2: CVE-2024-24826 CVE-2024-25112

[Moritz Mühlenhoff]

Source: exiv2
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for exiv2.

The advisories are a little misleading, they mention it as
new in v0.28.0, but that only applies to the "main" branch,
where it was removed and later reintroduced.

The 0.27-maintenance branch _does_ include the Quicktime decoder

CVE-2024-24826[0]:
| Exiv2 is a command-line utility and C++ library for reading,
| writing, deleting, and modifying the metadata of image files. An
| out-of-bounds read was found in Exiv2 version v0.28.1. The
| vulnerable function, `QuickTimeVideo::NikonTagsDecoder`, was new in
| v0.28.0, so Exiv2 versions before v0.28 are _not_ affected. The out-
| of-bounds read is triggered when Exiv2 is used to read the metadata
| of a crafted video file. In most cases this out of bounds read will
| result in a crash. This bug is fixed in version v0.28.2. Users are
| advised to upgrade. There are no known workarounds for this
| vulnerability.

https://github.com/Exiv2/exiv2/security/advisories/GHSA-g9xm-7538-mq8w
https://github.com/Exiv2/exiv2/pull/2337

CVE-2024-25112[1]:
| Exiv2 is a command-line utility and C++ library for reading,
| writing, deleting, and modifying the metadata of image files. A
| denial-of-service was found in Exiv2 version v0.28.1: an unbounded
| recursion can cause Exiv2 to crash by exhausting the stack. The
| vulnerable function, `QuickTimeVideo::multipleEntriesDecoder`, was
| new in v0.28.0, so Exiv2 versions before v0.28 are _not_ affected.
| The denial-of-service is triggered when Exiv2 is used to read the
| metadata of a crafted video file. This bug is fixed in version
| v0.28.2. Users are advised to upgrade. There are no known
| workarounds for this vulnerability.

https://github.com/Exiv2/exiv2/security/advisories/GHSA-crmj-qh74-2r36
Fixed by: 
https://github.com/Exiv2/exiv2/commit/355afea485550e8214ac6b449fb210a7efb71365 
(v0.28.2)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-24826
https://www.cve.org/CVERecord?id=CVE-2024-24826
[1] https://security-tracker.debian.org/tracker/CVE-2024-25112
https://www.cve.org/CVERecord?id=CVE-2024-25112

Please adjust the affected versions in the BTS as needed.

Bug#1070393: gobgp: CVE-2023-46565

[Moritz Mühlenhoff]

Source: gobgp
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gobgp.

CVE-2023-46565[0]:
| Buffer Overflow vulnerability in osrg gobgp commit
| 419c50dfac578daa4d11256904d0dc182f1a9b22 allows a remote attacker to
| cause a denial of service via the handlingError function in
| pkg/server/fsm.go.

https://github.com/osrg/gobgp/issues/2725


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-46565
https://www.cve.org/CVERecord?id=CVE-2023-46565

Please adjust the affected versions in the BTS as needed.

Bug#1016957: remove kbd-chooser from the archive?

[Cyril Brulebois]

Paul Gevers  (2024-05-04):
> If you're sure it's not used, I can work around udd and have it at least
> removed from testing. I think a bug retitle (or separate bug) would have
> been better. The current bug isn't RC.

If it's certain that package isn't used/useful anymore, the correct thing
to do is to have it removed from the archive, via unstable, sync'd into
testing. I don't see what a removal from testing only would achieve, esp.
for trumped-up reasons.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Jussi Pakkanen]

On Sat, 4 May 2024 at 13:27, Jussi Pakkanen  wrote:

> Disabling tests is also not a great because it just hides the bug.
> Thus other packages that actually use this functionality are going to
> hit this eventually and file more bugs on Meson. That is a waste of
> everybody's time and energy.

I managed to replicate this bug without Meson. Attached is sample code
plus a build script that runs a few compilation commands in a shell
script.

The script runs fine on x64_64 but fails on arm64 (and probably also
x86, but I did not test it). This would imply something wonky going on
in the toolchain. The question then becomes where this should be
reported to.


rustcmixbug.tar.gz
Description: GNU Zip compressed data

Bug#1070391: wiki.debian.org: spelling error: This command backup all height key-slots

[Yngve Spjeld-Landro]

Package: wiki.debian.org
Severity: minor

Dear Maintainer,

on page https://wiki.debian.org/LVM it says "This command backup all height 
key-slots"


I'd like to suggest that the text is changed to: "This command backs up all 
eight key-slots"

Bug#1070390: opendmarc: CVE-2024-25768

[Moritz Mühlenhoff]

Source: opendmarc
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for opendmarc. It's unclear
whether this is actually a security issue, it doesn't appear to have
been reported upstream...

CVE-2024-25768[0]:
| OpenDMARC 1.4.2 contains a null pointer dereference vulnerability in
| /OpenDMARC/libopendmarc/opendmarc_policy.c.

https://github.com/LuMingYinDetect/OpenDMARC_defects/blob/main/OpenDMARC_detect_1.md


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-25768
https://www.cve.org/CVERecord?id=CVE-2024-25768

Please adjust the affected versions in the BTS as needed.

Bug#1070388: jupyterhub: CVE-2024-28233

[Moritz Mühlenhoff]

Source: jupyterhub
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for jupyterhub.

CVE-2024-28233[0]:
| JupyterHub is an open source multi-user server for Jupyter
| notebooks. By tricking a user into visiting a malicious subdomain,
| the attacker can achieve an XSS directly affecting the former's
| session. More precisely, in the context of JupyterHub, this XSS
| could achieve full access to JupyterHub API and user's single-user
| server. The affected configurations are single-origin JupyterHub
| deployments and JupyterHub deployments with user-controlled
| applications running on subdomains or peer subdomains of either the
| Hub or a single-user server. This vulnerability is fixed in 4.1.0.

https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-7r3h-4ph8-w38g
https://github.com/jupyterhub/jupyterhub/commit/e2798a088f5ad45340fe79cdf1386198e664f77f


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-28233
https://www.cve.org/CVERecord?id=CVE-2024-28233

Please adjust the affected versions in the BTS as needed.

Bug#1070387: gdcm: CVE-2024-25569 CVE-2024-22373 CVE-2024-22391

[Moritz Mühlenhoff]

Source: gdcm
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for gdcm.

These are fixed in 3.0.24:

CVE-2024-25569[0]:
| An out-of-bounds read vulnerability exists in the
| RAWCodec::DecodeBytes functionality of Mathieu Malaterre Grassroot
| DICOM 3.0.23. A specially crafted DICOM file can lead to an out-of-
| bounds read. An attacker can provide a malicious file to trigger
| this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2024-1944

CVE-2024-22373[1]:
| An out-of-bounds write vulnerability exists in the
| JPEG2000Codec::DecodeByStreamsCommon functionality of Mathieu
| Malaterre Grassroot DICOM 3.0.23. A specially crafted DICOM file can
| lead to a heap buffer overflow. An attacker can provide a malicious
| file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2024-1935

CVE-2024-22391[2]:
| A heap-based buffer overflow vulnerability exists in the
| LookupTable::SetLUT functionality of Mathieu Malaterre Grassroot
| DICOM 3.0.23. A specially crafted malformed file can lead to memory
| corruption. An attacker can provide a malicious file to trigger this
| vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2024-1924


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-25569
https://www.cve.org/CVERecord?id=CVE-2024-25569
[1] https://security-tracker.debian.org/tracker/CVE-2024-22373
https://www.cve.org/CVERecord?id=CVE-2024-22373
[2] https://security-tracker.debian.org/tracker/CVE-2024-22391
https://www.cve.org/CVERecord?id=CVE-2024-22391

Please adjust the affected versions in the BTS as needed.

Bug#1053995: Info received (ITP: fastfetch -- like neofetch, but much faster because written in C)

[Hiago De Franco]

Hello,

On Wed, Nov 15, 2023 at 02:12:00AM +, Li Carter wrote:
> Friendly ping
>

As discussed on 
https://github.com/fastfetch-cli/fastfetch/issues/533#issuecomment-2094282467
I will be taking this bug to work on it. 

> > 2023年10月16日 14:39，Debian Bug Tracking System  写道：
> > 
> > Thank you for the additional information you have supplied regarding
> > this Bug report.
> > 
> > This is an automatically generated reply to let you know your message
> > has been received.
> > 
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> > 
> > Your message has been sent to the package maintainer(s):
> > w...@debian.org
> > 
> > If you wish to submit further information on this problem, please
> > send it to 1053...@bugs.debian.org.
> > 
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> > 
> > -- 
> > 1053995: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053995
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
>

Regards,
Hiago.

Bug#1070386: ITP: pass-import - MediaWiki API client in Python

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner 

* Package name: remarkable
  Version : 1.87+git20240504.e8cc99d
  Upstream Author : Jamie McGowan 
* URL : https://github.com/roddhjav/pass-import
* License : BSD-2 GPL-2+ LGPL-2.1+ MIT
  Programming Lang: Python
  Package source  : https://salsa.debian.org/python-team/packages/remarkable
  Description: A free fully featured Markdown editor.

 Remarkable is a free fully featured Markdown editor. It has a syntax
 like Github flavoured Markdown. With it you can write Markdown and view
 the changes as you make them in the live preview window. You can export
 your files to a variety of formats. There are multiple styles available
 along with extensive configuration options so you can set it up exactly
 how you like.

Also on:

AUR: https://aur.archlinux.org/packages/remarkable
Gentoo: https://github.com/gentoo/gentoo/tree/824b749/app-editors/remarkable

Bug#1016957: remove kbd-chooser from the archive?

[Paul Gevers]

Hi

On 04-05-2024 3:36 p.m., Holger Wansing wrote:

I think Bastian's approach is, to remove kbd-chooser from the archive, since
it was stated (see below) that it's no longer in use.


It might be that udd assumes all packages that build a udeb are used.


d-i has switched away from it to console-setup 12 years ago with
https://salsa.debian.org/installer-team/debian-installer/-/commit/2575a669e91252a6253430020137154c995c9b38


I did check the d-i repository and there are still references to 
kbd-chooser, so I *assumed* it was still used.



Are there any ports maybe, that still use it somehow?
Or what about derivatives?
It's an udeb-only package, so the use in the installer is the only imaginable
scenario...
If you're sure it's not used, I can work around udd and have it at least 
removed from testing. I think a bug retitle (or separate bug) would have 
been better. The current bug isn't RC.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068583: libgav1: FTBFS on s390x: test failures

[Sebastian Ramacher]

On 2024-05-04 10:02:38 -0400, John David Anglin wrote:
> Adding architecture-is-little-endian to build dependency is not a good 
> solution as this blocks building glibc
> on big endian targets:
> https://buildd.debian.org/status/package.php?p=glibc=sid

libavif will also need to drop support for libgav1 on the other big
endian architectures.

Cheers
-- 
Sebastian Ramacher

Bug#1069693: network-manager-fortisslvpn: upgrading the stack from network-manager-fortisslvpn-gnome to ppp broke a current working VPN configuration

[Patrice Duroux]

Package: network-manager-fortisslvpn
Followup-For: Bug #1069693

Hi,

Issue #1070343 seems to be related to this issue.
But I did not find a way to modify the affected VPN config (GNOME) and add the
option (--pppd-accept-remote). Editing /etc/openfortivpn/config file has no
(global) effect in this case.

Regards,
Patrice


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

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

Versions of packages network-manager-fortisslvpn depends on:
ii  libc62.38-7
ii  libglib2.0-0t64  2.78.4-7
ii  libnm0   1.46.0-2
ii  network-manager  1.46.0-2
ii  openfortivpn 1.22.0-1
ii  ppp  2.5.0-1+2

network-manager-fortisslvpn recommends no packages.

network-manager-fortisslvpn suggests no packages.

-- no debconf information

Bug#1070385: obs-studio: Plugin fails to load libobs.so because it doesn't exist

[Thomas Blanc]

Package: obs-studio
Version: 30.1.2+dfsg-1
Severity: normal

Dear Maintainer,

I installed the following obs plugin in my home directory:
https://github.com/LiveSplit/obs-livesplit-one

Upon starting obs, the plugin did not load and the logs told me libobs.so was
not found

Typing $ dpkg -L libobs0t64 | grep libobs\\.so
allowed me to find the two following files:
/usr/lib/x86_64-linux-gnu/libobs.so.30
/usr/lib/x86_64-linux-gnu/libobs.so.0 (symlink to the previous)

Adding a symlink libobs.so in that directory fixed the issue, but I am worried
as I edited a directory I'm not sure I should according to Debian guidelines
(I'm not the most system-savy person)

Since others might have the same issue, I'm letting you know and hope my fix is
the right one

Thank you,

Thomas Blanc

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

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

Versions of packages obs-studio depends on:
ii  libavcodec60   7:6.1.1-4
ii  libavdevice60  7:6.1.1-4
ii  libavformat60  7:6.1.1-4
ii  libavutil587:6.1.1-4
ii  libc6  2.38-7
ii  libcurl3t64-gnutls 8.7.1-5
ii  libegl11.7.0-1+b1
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4
ii  libgcc-s1  14-20240429-1
ii  libglx01.7.0-1+b1
ii  libjansson42.14-2+b2
ii  libluajit-5.1-22.1.0+openresty20231117-2
ii  libmbedcrypto7t64  2.28.8-1
ii  libmbedtls14t642.28.8-1
ii  libmbedx509-1t64   2.28.8-1
ii  libobs0t64 30.1.2+dfsg-1
ii  libopengl0 1.7.0-1+b1
ii  libpci31:3.12.0-1
ii  libpulse0  16.1+dfsg1-5
ii  libpython3.11t64   3.11.9-1
ii  libqrcodegencpp1   1.8.0-1.2+b1
ii  libqt6core6t64 6.4.2+dfsg-21.1+b1
ii  libqt6gui6t64  6.4.2+dfsg-21.1+b1
ii  libqt6network6t64  6.4.2+dfsg-21.1+b1
ii  libqt6svg6 6.4.2-4+b2
ii  libqt6widgets6t64  6.4.2+dfsg-21.1+b1
ii  libqt6xml6t64  6.4.2+dfsg-21.1+b1
ii  librist4   0.2.10+dfsg-2
ii  libspeexdsp1   1.2.1-1+b1
ii  libsrt1.5-openssl  1.5.3-1+b2
ii  libstdc++6 14-20240429-1
ii  libswscale77:6.1.1-4
ii  libudev1   255.5-1
ii  libv4l-0t641.26.1-4+b1
ii  libva-drm2 2.20.0-2+b1
ii  libva2 2.20.0-2+b1
ii  libx11-6   2:1.8.7-1+b1
ii  libx264-1642:0.164.3108+git31e19f9-1
ii  libxcb-composite0  1.17.0-1
ii  libxcb-randr0  1.17.0-1
ii  libxcb-shm01.17.0-1
ii  libxcb-xfixes0 1.17.0-1
ii  libxcb-xinerama0   1.17.0-1
ii  libxcb11.17.0-1
ii  libxkbcommon0  1.6.0-1+b1
ii  python33.11.8-1
ii  python3.11 3.11.9-1
ii  qt6-image-formats-plugins  6.4.2-5+b1
ii  qt6-wayland6.4.2-5+b2

Versions of packages obs-studio recommends:
ii  obs-plugins  30.1.2+dfsg-1

Versions of packages obs-studio suggests:
ii  pkexec 124-2
ii  policykit-1124-2
pn  v4l2loopback-dkms  

-- no debconf information

Bug#1070384: llvm-toolchain-14: CVE-2024-31852

[Moritz Mühlenhoff]

Source: llvm-toolchain-14
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for llvm-toolchain-14.

CVE-2024-31852[0]:
| LLVM before 18.1.3 generates code in which the LR register can be
| overwritten without data being saved to the stack, and thus there
| can sometimes be an exploitable error in the flow of control. This
| affects the ARM backend and can be demonstrated with Clang. NOTE:
| the vendor perspective is "we don't have strong objections for a CVE
| to be created ... It does seem that the likelihood of this
| miscompile enabling an exploit remains very low, because the
| miscompile resulting in this JOP gadget is such that the function is
| most likely to crash on most valid inputs to the function. So, if
| this function is covered by any testing, the miscompile is most
| likely to be discovered before the binary is shipped to production."

https://github.com/llvm/llvm-project/issues/80287
https://bugs.chromium.org/p/llvm/issues/detail?id=69
https://github.com/llvmbot/llvm-project/commit/0e16af8e4cf3a66ad5d078d52744ae2776f9c4b2


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31852
https://www.cve.org/CVERecord?id=CVE-2024-31852

Please adjust the affected versions in the BTS as needed.

Bug#1070383: llvm-toolchain-15: CVE-2024-31852

[Moritz Mühlenhoff]

Source: llvm-toolchain-15
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for llvm-toolchain-15.

CVE-2024-31852[0]:
| LLVM before 18.1.3 generates code in which the LR register can be
| overwritten without data being saved to the stack, and thus there
| can sometimes be an exploitable error in the flow of control. This
| affects the ARM backend and can be demonstrated with Clang. NOTE:
| the vendor perspective is "we don't have strong objections for a CVE
| to be created ... It does seem that the likelihood of this
| miscompile enabling an exploit remains very low, because the
| miscompile resulting in this JOP gadget is such that the function is
| most likely to crash on most valid inputs to the function. So, if
| this function is covered by any testing, the miscompile is most
| likely to be discovered before the binary is shipped to production."

https://github.com/llvm/llvm-project/issues/80287
https://bugs.chromium.org/p/llvm/issues/detail?id=69
https://github.com/llvmbot/llvm-project/commit/0e16af8e4cf3a66ad5d078d52744ae2776f9c4b2


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31852
https://www.cve.org/CVERecord?id=CVE-2024-31852

Please adjust the affected versions in the BTS as needed.

Bug#1070343: openfortivpn: stopped working after today's upgrade in Debian testing

[Francesco Poli]

Control: severity -1 important
Control: retitle -1 please warn users about the option --pppd-accept-remote 
needed for ppp >= 2.5.0


On Sat, 04 May 2024 00:23:32 +0200 Francesco Poli (wintermute) wrote:

[...]
>   Peer refused to agree to his IP address
[...]

I tried to downgrade ppp to version 2.4.9-1+1.1+b1 and openfortivpn is
working again.

By searching the web, I found openfortigui issue [#194], which mentions
the new option --pppd-accept-remote that has to be used with
openfortvpn, when ppp version >= 2.5.0 ...

[#194]: 

I actually added

  pppd-accept-remote = true

to my /etc/openfortivpn/MYNETWORK and now openfortivpn works again
(with ppp/2.5.0-1+2).

I am therefore lowering the severity of this bug report.

I am not closing it, though, since I believe that such an important
behavior change (the need to add an option, if ppp version >= 2.5.0)
should really be communicated to the users of the openfortivpn Debian
package users.
Maybe a NEWS.Debian file in /usr/share/doc/openfortivpn could be added
to document this new need?
I really believe that users should be warned about this!




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


pgpZHMqUG_HMM.pgp
Description: PGP signature

Bug#1070382: llvm-toolchain-16: CVE-2024-31852

[Moritz Mühlenhoff]

Source: llvm-toolchain-16
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for llvm-toolchain-16.

CVE-2024-31852[0]:
| LLVM before 18.1.3 generates code in which the LR register can be
| overwritten without data being saved to the stack, and thus there
| can sometimes be an exploitable error in the flow of control. This
| affects the ARM backend and can be demonstrated with Clang. NOTE:
| the vendor perspective is "we don't have strong objections for a CVE
| to be created ... It does seem that the likelihood of this
| miscompile enabling an exploit remains very low, because the
| miscompile resulting in this JOP gadget is such that the function is
| most likely to crash on most valid inputs to the function. So, if
| this function is covered by any testing, the miscompile is most
| likely to be discovered before the binary is shipped to production."

https://github.com/llvm/llvm-project/issues/80287
https://bugs.chromium.org/p/llvm/issues/detail?id=69
https://github.com/llvmbot/llvm-project/commit/0e16af8e4cf3a66ad5d078d52744ae2776f9c4b2


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31852
https://www.cve.org/CVERecord?id=CVE-2024-31852

Please adjust the affected versions in the BTS as needed.

Bug#1070381: llvm-toolchain-17: CVE-2024-31852

[Moritz Mühlenhoff]

Source: llvm-toolchain-17
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for llvm-toolchain-17.

CVE-2024-31852[0]:
| LLVM before 18.1.3 generates code in which the LR register can be
| overwritten without data being saved to the stack, and thus there
| can sometimes be an exploitable error in the flow of control. This
| affects the ARM backend and can be demonstrated with Clang. NOTE:
| the vendor perspective is "we don't have strong objections for a CVE
| to be created ... It does seem that the likelihood of this
| miscompile enabling an exploit remains very low, because the
| miscompile resulting in this JOP gadget is such that the function is
| most likely to crash on most valid inputs to the function. So, if
| this function is covered by any testing, the miscompile is most
| likely to be discovered before the binary is shipped to production."

https://github.com/llvm/llvm-project/issues/80287
https://bugs.chromium.org/p/llvm/issues/detail?id=69
https://github.com/llvmbot/llvm-project/commit/0e16af8e4cf3a66ad5d078d52744ae2776f9c4b2


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31852
https://www.cve.org/CVERecord?id=CVE-2024-31852

Please adjust the affected versions in the BTS as needed.

Bug#1070380: llvm-toolchain-18: CVE-2024-31852

[Moritz Mühlenhoff]

Source: llvm-toolchain-18
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for llvm-toolchain-18.

CVE-2024-31852[0]:
| LLVM before 18.1.3 generates code in which the LR register can be
| overwritten without data being saved to the stack, and thus there
| can sometimes be an exploitable error in the flow of control. This
| affects the ARM backend and can be demonstrated with Clang. NOTE:
| the vendor perspective is "we don't have strong objections for a CVE
| to be created ... It does seem that the likelihood of this
| miscompile enabling an exploit remains very low, because the
| miscompile resulting in this JOP gadget is such that the function is
| most likely to crash on most valid inputs to the function. So, if
| this function is covered by any testing, the miscompile is most
| likely to be discovered before the binary is shipped to production."

https://github.com/llvm/llvm-project/issues/80287
https://bugs.chromium.org/p/llvm/issues/detail?id=69
https://github.com/llvmbot/llvm-project/commit/0e16af8e4cf3a66ad5d078d52744ae2776f9c4b2

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31852
https://www.cve.org/CVERecord?id=CVE-2024-31852

Please adjust the affected versions in the BTS as needed.

Bug#1070379: pytorch: CVE-2024-31580 CVE-2024-31583 CVE-2024-31584

[Moritz Mühlenhoff]

Source: pytorch
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for pytorch.

CVE-2024-31580[0]:
| PyTorch before v2.2.0 was discovered to contain a heap buffer
| overflow vulnerability in the component
| /runtime/vararg_functions.cpp. This vulnerability allows attackers
| to cause a Denial of Service (DoS) via a crafted input.

https://github.com/pytorch/pytorch/commit/b5c3a17c2c207ebefcb85043f0cf94be9b2fef81

CVE-2024-31583[1]:
| Pytorch before version v2.2.0 was discovered to contain a use-after-
| free vulnerability in torch/csrc/jit/mobile/interpreter.cpp.

https://github.com/pytorch/pytorch/commit/9c7071b0e324f9fb68ab881283d6b8d388a4bcd2

CVE-2024-31584[2]:
| Pytorch before v2.2.0 has an Out-of-bounds Read vulnerability via
| the component torch/csrc/jit/mobile/flatbuffer_loader.cpp.

https://github.com/pytorch/pytorch/commit/7c35874ad664e74c8e4252d67521f3986eadb0e6


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-31580
https://www.cve.org/CVERecord?id=CVE-2024-31580
[1] https://security-tracker.debian.org/tracker/CVE-2024-31583
https://www.cve.org/CVERecord?id=CVE-2024-31583
[2] https://security-tracker.debian.org/tracker/CVE-2024-31584
https://www.cve.org/CVERecord?id=CVE-2024-31584

Please adjust the affected versions in the BTS as needed.

Bug#1070378: docker.io: CVE-2024-32473

[Moritz Mühlenhoff]

Source: docker.io
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for docker.io.

CVE-2024-32473[0]:
| Moby is an open source container framework that is a key component
| of Docker Engine, Docker Desktop, and other distributions of
| container tooling or runtimes. In 26.0.0, IPv6 is not disabled on
| network interfaces, including those belonging to networks where
| `--ipv6=false`. An container with an `ipvlan` or `macvlan` interface
| will normally be configured to share an external network link with
| the host machine. Because of this direct access, (1) Containers may
| be able to communicate with other hosts on the local network over
| link-local IPv6 addresses, (2) if router advertisements are being
| broadcast over the local network, containers may get SLAAC-assigned
| addresses, and (3) the interface  will be a member of IPv6 multicast
| groups. This means interfaces in IPv4-only networks present an
| unexpectedly and unnecessarily increased attack surface. The issue
| is patched in 26.0.2. To completely disable IPv6 in a container, use
| `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create`
| or `docker run` command. Or, in the service configuration of a
| `compose` file.

https://github.com/moby/moby/security/advisories/GHSA-x84c-p2g9-rqv9
https://github.com/moby/moby/commit/841c4c8057bcf5317d6565875595a3f0c046e3fa

It's not super clear whether this is only fixed in 26.x and old releases
(such as the one in unstable) are not affected or, let's validate
and update the Security Tracker accordingly if not (ideally by identifying
the introducing commit)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-32473
https://www.cve.org/CVERecord?id=CVE-2024-32473

Please adjust the affected versions in the BTS as needed.

Bug#1070377: frr: CVE-2024-34088

[Moritz Mühlenhoff]

Source: frr
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for frr.

CVE-2024-34088[0]:
| In FRRouting (FRR) through 9.1, it is possible for the get_edge()
| function in ospf_te.c in the OSPF daemon to return a NULL pointer.
| In cases where calling functions do not handle the returned NULL
| value, the OSPF daemon crashes, leading to denial of service.

https://github.com/FRRouting/frr/pull/15674
Introduced by: 
https://github.com/FRRouting/frr/commit/f173deb35206a09e8dc22828cb08638e289b72a5
 (base_8.0)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34088
https://www.cve.org/CVERecord?id=CVE-2024-34088

Please adjust the affected versions in the BTS as needed.

Bug#1069377: scipy: FTBFS on arm64: make[1]: *** [debian/rules:161: execute_after_dh_auto_install] Error 1

[Drew Parsons]

Source: scipy
Followup-For: Bug #1069377
Control: tags -1 ftbfs

This is an odd error.  Looks as if the behaviour changed in respect to
which exception gets emitted.

There's a new release needing to get packaged. Likely it resolves the
issue.

Bug#1070376: uriparser: CVE-2024-34402 CVE-2024-34403

[Moritz Mühlenhoff]

Source: uriparser
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for uriparser.

CVE-2024-34402[0]:
| An issue was discovered in uriparser through 0.9.7.
| ComposeQueryEngine in UriQuery.c has an integer overflow via long
| keys or values, with a resultant buffer overflow.

https://github.com/uriparser/uriparser/pull/185
https://github.com/uriparser/uriparser/issues/183

CVE-2024-34403[1]:
| An issue was discovered in uriparser through 0.9.7.
| ComposeQueryMallocExMm in UriQuery.c has an integer overflow via a
| long string.

https://github.com/uriparser/uriparser/issues/183
https://github.com/uriparser/uriparser/pull/186


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34402
https://www.cve.org/CVERecord?id=CVE-2024-34402
[1] https://security-tracker.debian.org/tracker/CVE-2024-34403
https://www.cve.org/CVERecord?id=CVE-2024-34403

Please adjust the affected versions in the BTS as needed.

Bug#1070375: python-jose: CVE-2024-33663 CVE-2024-33664

[Moritz Mühlenhoff]

Source: python-jose
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for python-jose.

CVE-2024-33663[0]:
| python-jose through 3.3.0 has algorithm confusion with OpenSSH ECDSA
| keys and other key formats. This is similar to CVE-2022-29217.

https://github.com/mpdavis/python-jose/issues/346

CVE-2024-33664[1]:
| python-jose through 3.3.0 allows attackers to cause a denial of
| service (resource consumption) during a decode via a crafted JSON
| Web Encryption (JWE) token with a high compression ratio, aka a "JWT
| bomb." This is similar to CVE-2024-21319.

https://github.com/mpdavis/python-jose/issues/344
https://github.com/mpdavis/python-jose/pull/345


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-33663
https://www.cve.org/CVERecord?id=CVE-2024-33663
[1] https://security-tracker.debian.org/tracker/CVE-2024-33664
https://www.cve.org/CVERecord?id=CVE-2024-33664

Please adjust the affected versions in the BTS as needed.

Bug#1070373: quickjs: CVE-2024-33263

[Moritz Mühlenhoff]

Source: quickjs
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for quickjs.

CVE-2024-33263[0]:
| QuickJS commit 3b45d15 was discovered to contain an Assertion
| Failure via JS_FreeRuntime(JSRuntime *) at quickjs.c.

https://github.com/bellard/quickjs/issues/277


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-33263
https://www.cve.org/CVERecord?id=CVE-2024-33263

Please adjust the affected versions in the BTS as needed.

Bug#1070374: social-auth-app-django: CVE-2024-32879

[Moritz Mühlenhoff]

Source: social-auth-app-django
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for social-auth-app-django.

CVE-2024-32879[0]:
| Python Social Auth is a social authentication/registration
| mechanism. Prior to version 5.4.1, due to default case-insensitive
| collation in MySQL or MariaDB databases, third-party authentication
| user IDs are not case-sensitive and could cause different IDs to
| match. This issue has been addressed by a fix released in version
| 5.4.1. An immediate workaround would be to change collation of the
| affected field.

https://github.com/python-social-auth/social-app-django/security/advisories/GHSA-2gr8-3wc7-xhj3
https://github.com/python-social-auth/social-app-django/commit/31c3e0c7edb187004d8abbde7e9c4f7ef9098138
 (5.4.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-2024-32879
https://www.cve.org/CVERecord?id=CVE-2024-32879

Please adjust the affected versions in the BTS as needed.

Bug#1070372: tqdm: CVE-2024-34062

[Moritz Mühlenhoff]

Source: tqdm
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for tqdm.

CVE-2024-34062[0]:
| tqdm is an open source progress bar for Python and CLI. Any optional
| non-boolean CLI arguments (e.g. `--delim`, `--buf-size`,
| `--manpath`) are passed through python's `eval`, allowing arbitrary
| code execution. This issue is only locally exploitable and had been
| addressed in release version 4.66.3. All users are advised to
| upgrade. There are no known workarounds for this vulnerability.

https://github.com/tqdm/tqdm/security/advisories/GHSA-g7vv-2v7x-gj9p
Fixed by: 
https://github.com/tqdm/tqdm/commit/b53348c73080b4edeb30b4823d1fa0d8d2c06721 
(v4.66.3)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34062
https://www.cve.org/CVERecord?id=CVE-2024-34062

Please adjust the affected versions in the BTS as needed.

Bug#1070371: ofono: CVE-2023-4232 CVE-2023-4233 CVE-2023-4234 CVE-2023-4235

[Moritz Mühlenhoff]

Source: ofono
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for ofono.

It's not clear whether they were actually reported upstream or only
submitted to Red Hat Bugzilla:

CVE-2023-4232[0]:
| A flaw was found in ofono, an Open Source Telephony on Linux. A
| stack overflow bug is triggered within the decode_status_report()
| function during the SMS decoding. It is assumed that the attack
| scenario is accessible from a compromised modem, a malicious base
| station, or just SMS. There is a bound check for this memcpy length
| in decode_submit(), but it was forgotten in decode_status_report().

https://bugzilla.redhat.com/show_bug.cgi?id=2255394

CVE-2023-4233[1]:
| A flaw was found in ofono, an Open Source Telephony on Linux. A
| stack overflow bug is triggered within the
| sms_decode_address_field() function during the SMS PDU decoding. It
| is assumed that the attack scenario is accessible from a compromised
| modem, a malicious base station, or just SMS.

https://bugzilla.redhat.com/show_bug.cgi?id=2255396

CVE-2023-4234[2]:
| A flaw was found in ofono, an Open Source Telephony on Linux. A
| stack overflow bug is triggered within the decode_submit_report()
| function during the SMS decoding. It is assumed that the attack
| scenario is accessible from a compromised modem, a malicious base
| station, or just SMS. There is a bound check for this memcpy length
| in decode_submit(), but it was forgotten in decode_submit_report().

https://bugzilla.redhat.com/show_bug.cgi?id=2255399

CVE-2023-4235[3]:
| A flaw was found in ofono, an Open Source Telephony on Linux. A
| stack overflow bug is triggered within the decode_deliver_report()
| function during the SMS decoding. It is assumed that the attack
| scenario is accessible from a compromised modem, a malicious base
| station, or just SMS. There is a bound check for this memcpy length
| in decode_submit(), but it was forgotten in decode_deliver_report().

https://bugzilla.redhat.com/show_bug.cgi?id=2255402


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4232
https://www.cve.org/CVERecord?id=CVE-2023-4232
[1] https://security-tracker.debian.org/tracker/CVE-2023-4233
https://www.cve.org/CVERecord?id=CVE-2023-4233
[2] https://security-tracker.debian.org/tracker/CVE-2023-4234
https://www.cve.org/CVERecord?id=CVE-2023-4234
[3] https://security-tracker.debian.org/tracker/CVE-2023-4235
https://www.cve.org/CVERecord?id=CVE-2023-4235

Please adjust the affected versions in the BTS as needed.

Bug#1070370: dmitry: CVE-2017-7938 CVE-2020-14931 CVE-2024-31837

[Moritz Mühlenhoff]

Source: dmitry
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for dmitry.

CVE-2017-7938[0]:
| Stack-based buffer overflow in DMitry (Deepmagic Information
| Gathering Tool) version 1.3a (Unix) allows attackers to cause a
| denial of service (application crash) or possibly have unspecified
| other impact via a long argument. An example threat model is
| automated execution of DMitry with hostname strings found in local
| log files.

https://packetstormsecurity.com/files/142210/Dmitry-1.3a-Local-Stack-Buffer-Overflow.html
https://github.com/jaygreig86/dmitry/pull/12

CVE-2020-14931[1]:
| A stack-based buffer overflow in DMitry (Deepmagic Information
| Gathering Tool) 1.3a might allow remote WHOIS servers to execute
| arbitrary code via a long line in a response that is mishandled by
| nic_format_buff.

https://github.com/jaygreig86/dmitry/issues/4
https://github.com/jaygreig86/dmitry/pull/6
Fixed by: 
https://github.com/jaygreig86/dmitry/commit/da1fda491145719ae15dd36dd37a69bdbba0b192

CVE-2024-31837[2]:
| DMitry (Deepmagic Information Gathering Tool) 1.3a has a format-
| string vulnerability, with a threat model similar to CVE-2017-7938.

https://github.com/jaygreig86/dmitry/pull/12

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7938
https://www.cve.org/CVERecord?id=CVE-2017-7938
[1] https://security-tracker.debian.org/tracker/CVE-2020-14931
https://www.cve.org/CVERecord?id=CVE-2020-14931
[2] https://security-tracker.debian.org/tracker/CVE-2024-31837
https://www.cve.org/CVERecord?id=CVE-2024-31837

Please adjust the affected versions in the BTS as needed.

Bug#1070304: util-linux: Please build and provide the cal binary

[Jörg Behrmann]

On Sat, May 04, 2024 at 04:13:37PM +0200, Michael Meskes wrote:
> > The example was to show how people could achieve using ncal to get
> > cal, if the
> > ncal package would not ship a cal binary.
> 
> Sure, but the only reason for the cal binary as it is, is to have the
> original cal available. All new and extended features are in ncal and
> are explicitly deactivated when called as cal.
> 

That is valid reasoning or was at some point, but I want to argue that it might
be good to rethink it today, since Alpine [1], Arch [2], CentOS [3], Fedora [4],
Gentoo [5], Mageia [6], OpenMandriva [7], OpenSuse [8], RHEL [9], and Slackware
[10] ship the /usr/bin/cal binary from the util-linux package (or split version
of the package in case of Alpine or they don't disable it by default in the case
of Gentoo). This is true even for very BSD forward Linux distributions like
OpenMandriva.

My point is, that anybody not using Debian or a derivative will expect cal to be
the util-linux version.

> But it is supported in ncal. Again, think of cal as traditional-cal if
> that makes it easier.

I will continue to think of ncal as the weird column-order calendar. :)

In more seriousness, if the expectation is for people to use ncal and cal is
just a remnant, that should best be ignored, I'd prefer that difference to the
rest of the Linux distribution ecosystem be whittled away instead.

[1] 
https://alpine.pkgs.org/3.19/alpine-main-x86_64/util-linux-2.39.3-r0.apk.html
[2] 
https://archlinux.pkgs.org/rolling/archlinux-core-x86_64/util-linux-2.40-3-x86_64.pkg.tar.zst.html
[3] 
https://centos.pkgs.org/9-stream/centos-baseos-x86_64/util-linux-2.37.4-18.el9.x86_64.rpm.html
[4] 
https://fedora.pkgs.org/40/fedora-x86_64/util-linux-2.40-0.9.rc1.fc40.i686.rpm.html
[5] 
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/util-linux/util-linux-2.39.4.ebuild
[6] 
https://mageia.pkgs.org/cauldron/mageia-core-release-x86_64/util-linux-2.40-3.mga10.x86_64.rpm.html
[7] 
https://openmandriva.pkgs.org/rolling/openmandriva-main-release-aarch64/util-linux-2.39.4-1-omv2490.aarch64.rpm.html
[8] 
https://opensuse.pkgs.org/tumbleweed/opensuse-oss-x86_64/util-linux-2.39.3-4.2.x86_64.rpm.html
[9] by virtue of CentOS
[10] 
https://slackware.pkgs.org/current/slackware-x86_64/util-linux-2.40-x86_64-2.txz.html


signature.asc
Description: PGP signature

Bug#1067320: topal: FTBFS: debian/rules: debian_packaging.mk: No such file or directory

[Nicolas Boulenguez]

Source: topal
Followup-For: Bug #1067320
Control: tag -1 + patch

Hello.
Attachment 002 below fixes this bug.
Would you be OK with a non maintainer upload?

The other attachments are unrelated sugestions.
Would you be OK with a salsa.debian.org/debian/topal git repository?


PATH 1/10  updates the upstream part to version 82.


>From 31c2f14e91e2a01c75eb1309f17ea540ffb80571 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sat, 3 Dec 2022 18:56:23 +0100
Subject: [PATCH 02/10] Switch to dh-ada-library >= 8.2 for packaging.mk

---
 debian/control | 1 +
 debian/rules   | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index be7984d..53206e5 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
 Maintainer: Phil Brooke 
 Build-Depends:
  debhelper-compat (= 13),
+ dh-ada-library (>= 8.2),
  gnat (>= 11),
  libreadline-dev,
  texlive,
diff --git a/debian/rules b/debian/rules
index cdd07e4..d3e38d5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,8 +4,7 @@
 
 DEB_BUILD_MAINT_OPTIONS := hardening=+all
 include /usr/share/dpkg/buildflags.mk
-include /usr/share/dpkg/buildopts.mk
-include /usr/share/ada/debian_packaging.mk
+include /usr/share/ada/packaging.mk
 
 # Compile Ada and C with the same compiler.
 CC := gnatgcc
-- 
2.39.2


>From a9e088d51c8f95a9e7cd60bee7e31f9e167834ed Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sat, 3 Dec 2022 18:57:35 +0100
Subject: [PATCH 03/10] Set CC from gnat version without the deprecated gnatgcc
 symbolic link

gcc-$MAJOR is also specific to Debian, but not to Ada.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index d3e38d5..b29f0ea 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,7 @@ include /usr/share/dpkg/buildflags.mk
 include /usr/share/ada/packaging.mk
 
 # Compile Ada and C with the same compiler.
-CC := gnatgcc
+CC := gcc-$(DEB_GNAT_VERSION)
 
 # Upstream Makefile insists on rebuilding everything everytime.
 # SOURCE_DATE_EPOCH (set by debhelper) and the -m gnatmake option may
-- 
2.39.2


>From 6a3416662d4142d461f6c59bdaca4c3e495f59ff Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 20 Jul 2022 14:56:41 +0200
Subject: [PATCH 04/10] Drop full texlive from build dependencies

It was now redundant with more specific dependencies.
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 53206e5..5669b2f 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,6 @@ Build-Depends:
  dh-ada-library (>= 8.2),
  gnat (>= 11),
  libreadline-dev,
- texlive,
  texlive-latex-base,
  texlive-latex-extra,
  texlive-fonts-recommended,
-- 
2.39.2


>From 2946bec7938ae412ac7cf632a2f2982a6b79355d Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 20 Jul 2022 14:57:05 +0200
Subject: [PATCH 05/10] Sort build dependencies

Dpkg supports the extra comma exactly for this purpose.
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 5669b2f..00262aa 100644
--- a/debian/control
+++ b/debian/control
@@ -7,10 +7,10 @@ Build-Depends:
  dh-ada-library (>= 8.2),
  gnat (>= 11),
  libreadline-dev,
+ texlive-fonts-extra,
+ texlive-fonts-recommended,
  texlive-latex-base,
  texlive-latex-extra,
- texlive-fonts-recommended,
- texlive-fonts-extra
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://www.zircon.org.uk/topal/
-- 
2.39.2


>From acb27a97b77357e5a17617c778119151161468de Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sat, 3 Dec 2022 19:18:57 +0100
Subject: [PATCH 06/10] Remove some trailing whitespaces

---
 debian/changelog | 1 -
 debian/rules | 1 -
 2 files changed, 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 03c854b..ba63f7a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -290,4 +290,3 @@ topal (0.6.4-1) unstable; urgency=low
   * Initial Release (closes: #143319).
 
  -- Phil Brooke   Sun, 21 Apr 2002 14:29:05 +
-
diff --git a/debian/rules b/debian/rules
index b29f0ea..c8539a8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -37,4 +37,3 @@ override_dh_auto_install:
 .PHONY: override_dh_installchangelogs
 override_dh_installchangelogs:
dh_installchangelogs Changelog.html
-
-- 
2.39.2


>From 6934d431d7d4efde5a7a2e2095e879d6488a083d Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 27 Aug 2023 14:03:48 +0200
Subject: [PATCH 07/10] Bump Standards-Version

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 00262aa..abc38ee 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends:
  texlive-fonts-recommended,
  texlive-latex-base,
  texlive-latex-extra,
-Standards-Version: 4.6.1
+Standards-Version: 4.7.0
 Rules-Requires-Root: no
 Homepage: https://www.zircon.org.uk/topal/
 
-- 

Bug#1053128: smbclient: "smbtree -N" causes a segfault when "server min protocol = NT1"

[Bernhard Übelacker]

Hello,
I am not a samba maintainer, just trying to collect some more information.

As far as I see the crash happens
because "cli_credentials_get_password(creds)" in line 62
returns a null pointer, which gets forwarded to
the call to strlcpy without further check.

Kind regards,
Bernhard



(rr) reverse-finish
Run back to call of #0  strlcpy (dst=0x7fff875c0640 "", src=0x0, dsize=) at ./src/strlcpy.c:36
0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
61  len = strlcpy(
(rr) bt
#0  0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
#1  0x7f9851ec6510 in SMBC_call_auth_fn (ctx=ctx@entry=0x5574eb8ba610, 
context=context@entry=0x5574eb8b7900, server=server@entry=0x5574eb8c9fe0 "10.0.2.15", 
share=share@entry=0x7f9851ed46a4 "IPC$", pp_workgroup=pp_workgroup@entry=0x7fff875c09b8, 
pp_username=pp_username@entry=0x7fff875c09a0, pp_password=0x7fff875c09a8) at 
source3/libsmb/libsmb_server.c:171
...

(rr) list smbtree.c:42
37
38  static void get_auth_data_with_context_fn(
39  SMBCCTX *context,
40  const char *server,
41  const char *share,
42  char *domain,
43  int domain_len,
44  char *user,
45  int user_len,
46  char *password,
47  int password_len)
48  {
49  struct cli_credentials *creds = samba_cmdline_get_creds();
50  size_t len;
51
52  len = strlcpy(domain, cli_credentials_get_domain(creds), 
domain_len);
53  if ((int)len >= domain_len) {
54  return;
55  }
56  len = strlcpy(
57  user, cli_credentials_get_username(creds), user_len);
58  if ((int)len >= user_len) {
59  return;
60  }
61  len = strlcpy(
62  password, cli_credentials_get_password(creds), 
password_len);
63  if ((int)len >= password_len) {
64  /* pointless, but what can you do... */
65  return;
66  }

# 2024-05-04 Trixie/testing amd64 qemu VM

apt install systemd-coredump mc gdb rr samba smbclient smbclient-dbgsym 
libsmbclient0-dbgsym libbsd0-dbgsym
apt build-dep samba



mkdir /home/benutzer/source/samba/orig -p
cd/home/benutzer/source/samba/orig
apt source samba



mc -e /etc/samba/smb.conf
 [global]
+server min protocol = NT1
 

testparm -s
systemctl enable --now smb
systemctl enable --now nmb
systemctl restart smbd nmbd
# Maybe a minute waiting is needed or this message appears "main: This is 
utility doesn't work if netbios name resolution is not configured."
smbtree -N --option="client min protocol = NT1"






benutzer@debian:~$ rr record smbtree -N --option="client min protocol = NT1"
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/smbtree-0'.
===
INTERNAL ERROR: Signal 11: Speicherzugriffsfehler in smbtree () () pid 9884 
(4.19.6-Debian)
If you are running a recent Samba version, and if you think this problem is not 
yet fixed in the latest versions, please consider reporting this bug, see 
https://wiki.samba.org/index.php/Bug_Reporting
===
PANIC (pid 9884): Signal 11: Speicherzugriffsfehler in 4.19.6-Debian
BACKTRACE: 14 stack frames:
 #0 
/usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x32) 
[0x7f9851a105c2]
 #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0xd) 
[0x7f9851a1085d]
 #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x28f5) 
[0x7f9851a108f5]
 #3 /lib/x86_64-linux-gnu/libc.so.6(+0x3c510) [0x7f9851acd510]
 #4 /lib/x86_64-linux-gnu/libbsd.so.0(strlcpy+0x10) [0x7f9851c7f900]
 #5 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14510) [0x7f9851ec6510]
 #6 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14ab1) [0x7f9851ec6ab1]
 #7 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14bdb) [0x7f9851ec6bdb]
 #8 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x156e4) [0x7f9851ec76e4]
 #9 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0xd37f) [0x7f9851ebf37f]
 #10 smbtree(main+0x262) [0x5574e9c43692]
 #11 /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7f9851ab86ca]
 #12 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f9851ab8785]
 #13 smbtree(_start+0x21) [0x5574e9c43b21]
smb_panic(): calling panic action [/usr/share/samba/panic-action 9884]
smb_panic(): action returned status 0
Can not dump core: corepath not set up
benutzer@debian:~$


benutzer@debian:~$ rr replay --debugger-option=-q smbtree-0
Reading symbols from /usr/bin/smbtree...
(No debugging symbols found in 

Bug#1070299: Acknowledgement (gcc-14: Wrong vectorized code generated with -O3, ok without -O.)

[Håkan T Johansson]

This issue turned out to not be an gcc issue, but a badly declared 
flexible / 'zero-length array' at the end of the structure, which then 
relied on undefined behaviour.  The declared size (here [4]) was then 
apparently taken into account in the code generation.


I do not know of a way to diagnose this kind of use without warning for 
basically all kinds of arrays at the end of structures.  Though it would 
be nice, as it was not straightforward to find the issue.


Perhaps a note in the gcc-14 upgrade notes that the compiler now uses 
declared array sizes (more) to influence loop execution might be useful.


Except for that, this bug can be closed.

Bug#1034878: #1034878 meld gives python traceback if run as root

[Jeremy Bícha]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/meld/-/issues/846
Control: severity -1 minor

On Sat, May 4, 2024 at 8:42 AM  wrote:
> Bug #1034878 - meld gives python traceback if run as root is caused by the 
> call to Gtk.Settings.get_default() in settings.py at about line 56.

In general, GNOME developers and the Debian GNOME team don't want you
running apps as root/sudo. We do expect some things to be broken if
you try it anyway. However, you can try raising this issue directly
with the upstream meld developers who may be willing to apply a fix
for the issue. I notice that someone already reported a similar issue
today but maybe you can add a comment with your additional research.

https://gitlab.gnome.org/GNOME/meld/-/issues/846

Thank you,
Jeremy Bícha

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Jakub Wilk]

* Vincent Danjean , 2016-12-25 23:36:

++{ "exfat", "nosuid,nodev,user,quiet,nonempty", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},


This doesn't work for me.
In dmesg I see:

exfat: Unknown parameter 'quiet'

--
Jakub Wilk

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

Hi Matt,

Quoting Matt Taggart:
>  Package: riseup-vpn
>  Version: 0.21.11+ds1-5+b1
>  Severity: grave
>  
>  When attempting to run the bookworm riseup-vpn package, it fails to 
>  connect to riseup's servers and gives the following output:
>  
>  2024/05/01 18:21:23 Error fetching eip v3 
>  json:https://api.black.riseup.net/3/config/eip-service.json
>  
>  My understanding is that this is due to the package failing to be able 
>  to verify the current LetsEncrypt cert that host is using. More details at
>  
>  https://0xacab.org/leap/bitmask-vpn/-/issues/768
>  
>  (supposedly the current upstream snap has this fixed, but I haven't 
>  tried it)
>  
>  As this breaks what the package is supposed to do (at least when using 
>  riseup as provider, maybe there is a way to point it elsewhere?) I think 
>  this is grave. Also I think it might be a good candidate for being fixed 
>  in a stable release update.

If I am not mistaken, as per the said, issue, it is fixed in the commit
referenced here, right?


https://0xacab.org/leap/bitmask-vpn/-/commit/14cf64b10a97c29688f252a7d9d3481c8484aa1d

I tried this in my testing system and it seems I am able to connect to the VPN
with this patch applied. Can you confirm?

Consequently, I also did some work to cherry-pick this and prepare a stable-p-u
upload (not yet uploaded, will do after confirmation) and pushed my changes
at[1]. I have also compiled the `.deb` for stable and it is ready to be
consumed[2]. Do you think you could ask someone to check the same?

Other than that, I also tried to update the package in unstable to the latest
version to fixup this properly. I was able to build it, pushed my changes
here[3] and the `.deb` is available here[4]. Again, if you/someone else could
try this, it'd be great. It is working for me on my debian/testing system.

I would have attemped the update much sooner but unfortunately an update with
0xacab's gitlab broke my d/watch file and I did not notice a new version is out
there sooner.

I was thinking to go ahead with an upload, but there are a few things that I
would like to clarify before I do so (btw thanks to the maintainers for
committing a patch to use with qt6.4):

1. Why is the default provider set to "provider = bitmask" in
providers/vendor.conf? This leads to building the binary called bitmask-vpn
instead of riseup-vpn. Is there a thought of changing the binary name?

In current stage it points to just dummy APIs and hence I overrode it in d/rules
to build riseup-vpn instead.

2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
BSD-2-Clause, BSD-3-Clause and also GPL-3 for
vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so what
exactly is the exact license? Is it redistributable under all the three? (I
don't think so?)

[1]: 
https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
[2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
[3]: 
https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
[4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1003300: kxl: New upstream project and versions

[Alexandre Detiste]

The diff between old & new repos is very conservative;
only autohell files

Bug#1070334: libnet-frame-device-perl needs network access during build

[Étienne Mollier]

Control: tags -1 + patch

Étienne Mollier, on 2024-05-03:
> Has someone an idea of better approach?

Answering to myself, the test suite does not actually attempt to
access the Internet, but it does attempt to access the device on
the build machine that can route by default to 1.1.1.1.  This is
not because it is a Cloudflare DNS, but merely because it is the
first usable ipv4 available at hand.  Especially in chroot-mode
unshare, there are no device leading to Internet exposed, thus
no device able to route to 1.1.1.1 with the default object
instanciation routine.

It turns out that the class can be told to construct objects
that refer to the loopback interface by asking for routes to the
loopback network (127/8 in ipv4, ::1/64 in ipv6).  I prepared a
patch in this direction and consider uploading soon.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Allman Brothers Band - Statesboro Blues
Description: fix build failure when no network interfaces are available.
 On buildd systems using sbuild chroot mode unshare, the network interface
 leading to Internet is not exposed.  However the default construction method
 for instanciating Net::Frame::Devices relies on the existence of a network
 interface able to route to 1.1.1.1.  This change adjusts the test suite items
 failing when not such interfaces are available, by trying to refer to loopback
 interfaces instead.  Note this slightly changes the meaning of the
 t/04-new-default.t, as it does not test the default behavior anymore, but it
 tests the behavior with ipv6 targets instead.
 .
 This addresses a Debian infrastructure specific behavior, probably not much
 worth forwarding upstream.

Author: Étienne Mollier 
Bug-Debian: https://bugs.debian.org/1070334
Forwarded: not-needed
Last-Update: 2024-05-04
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- libnet-frame-device-perl.orig/t/05-new-target.t
+++ libnet-frame-device-perl/t/05-new-target.t
@@ -2,7 +2,7 @@
 BEGIN { plan(tests => 1) }
 
 use Net::Frame::Device;
-my $d = Net::Frame::Device->new(target => '2.2.2.2') or die("Device::new");
+my $d = Net::Frame::Device->new(target => '127.1.1.1') or die("Device::new");
 print $d->cgDumper if $d->can('cgDumper');
 
 ok(1);
--- libnet-frame-device-perl.orig/t/04-new-default.t
+++ libnet-frame-device-perl/t/04-new-default.t
@@ -2,7 +2,7 @@
 BEGIN { plan(tests => 1) }
 
 use Net::Frame::Device;
-my $d = Net::Frame::Device->new or die("Device::new");
+my $d = Net::Frame::Device->new(target6 => '::1') or die("Device::new");
 print $d->cgDumper if $d->can('cgDumper');
 
 ok(1);


signature.asc
Description: PGP signature

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Santiago Vila]

El 4/5/24 a las 16:48, ca...@allfreemail.net escribió:

Package: base-files
Version: 13.2
Followup-For: Bug #885414

Dear Maintainer,

I'd like to point out that the "fix" doesn't actually fix the reported
problem. Variables that must be quoted in order to have a well-defined
behavior are still not quoted, namely the "$i" is not quoted. See the
very first message in this thread for patch.


Using the regexp ^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$ ensures that
$i will never contain spaces or, in general, characters that
are interpreted by the shell in a special way. Therefore, unless
I'm missing anything, the behaviour with or without quotes
around $i would be the same.

Thanks.

Bug#1070369: sssd: CVE-2023-3758

[Salvatore Bonaccorso]

Source: sssd
Version: 2.9.4-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/SSSD/sssd/pull/7302
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sssd.

CVE-2023-3758[0]:
| A race condition flaw was found in sssd where the GPO policy is not
| consistently applied for authenticated users. This may lead to
| improper authorization issues, granting or denying access to
| resources inappropriately.


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-3758
https://www.cve.org/CVERecord?id=CVE-2023-3758
[1] https://github.com/SSSD/sssd/pull/7302
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2223762
[3] 
https://github.com/SSSD/sssd/commit/e1bfbc2493c4194988acc3b2413df3dde0735ae3 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070367: linux-image-6.7.12-amd64: No WiFi

[Kurt Meyer]

Package: src:linux
X-Debbugs-Cc: yahweh19...@hailmail.net
Version: 6.7.12-1
Severity: important

Dear Maintainer,

* What led up to the situation?

Booting with the linux-image-6.7.12-amd64 kernel results in Wi-Fi not working 
and Wi-Fi isn't even an option under network-manager. This issue also 
manifested when I attempted to boot using the linux-image-6.6.15-amd64 kernel, 
so the issue may have started with that kernel.

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

Wi-Fi works when I boot using the linux-image-amd-6.6.13-1 kernel. My computer 
has a Broadcom BCM4352 802.11ac dual band wireless network adapter chip.

-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.12-amd64 
root=UUID=2ce960a9-306e-407e-940e-88fb66c8e14e ro quiet

** Tainted: I (2048)
* workaround for bug in platform firmware applied

** Kernel log:
[   11.786668] Registered IR keymap rc-rc6-mce
[   11.808428] IR RC6 protocol handler initialized
[   11.838563] rc rc0: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0
[   11.838630] rc rc0: lirc_dev: driver ene_ir registered at minor = 0, raw IR 
receiver, no transmitter
[   11.838692] input: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0/input14
[   11.838828] rc rc0: nonsensical timing event of duration 0
[   11.838831] rc rc0: two consecutive events of type space
[   11.838840] ene_ir: driver has been successfully loaded
[   12.161547] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.202826] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[   12.202904] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[   12.202972] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input18
[   12.207177] intel_rapl_common: Found RAPL domain package
[   12.207181] intel_rapl_common: Found RAPL domain core
[   12.207182] intel_rapl_common: Found RAPL domain uncore
[   12.207183] intel_rapl_common: Found RAPL domain dram
[   12.239648] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.239654] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.239656] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   12.239658] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   12.239660] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   12.239661] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[   12.239662] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   12.247641] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input19
[   12.247785] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input20
[   12.556062] input: Advanced Silicon S.A CoolTouch(TM) System as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.1/3-1.7.1:1.0/0003:2149:230C.0001/input/input21
[   12.651379] mc: Linux media interface: v0.10
[   12.697557] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   12.722908] hid-multitouch 0003:2149:230C.0001: input,hidraw0: USB HID v1.10 
Device [Advanced Silicon S.A CoolTouch(TM) System] on 
usb-:00:1d.0-1.7.1/input0
[   12.723282] logitech-djreceiver 0003:046D:C52B.0005: hiddev2,hidraw2: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:1d.0-1.7.4/input2
[   12.851837] input: Logitech Wireless Device PID:4101 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input22
[   12.862814] input: Logitech Wireless Device PID:4101 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input23
[   12.863043] hid-generic 0003:046D:4101.0008: input,hidraw3: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4101] on usb-:00:1d.0-1.7.4/input2:1
[   12.863622] input: Logitech Wireless Device PID:4011 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input27
[   12.864099] input: Logitech Wireless Device PID:4011 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input28
[   12.865582] hid-generic 0003:046D:4011.0009: input,hidraw4: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4011] on usb-:00:1d.0-1.7.4/input2:2
[   13.045112] videodev: Linux video capture interface: v2.00
[   13.211441] usb 3-1.7.2: Found UVC 1.00 device Laptop_Integrated_Webcam_FHD 
(1bcf:2c33)
[   13.251154] usbcore: registered new interface driver uvcvideo
[