Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-24 Thread Vladimir Petko
Hi,

The CMake checks if the function is present in the runtime library
(whether strlcpy() compiles), but the declaration in string.h itself
is guarded by __USE_MISC define.
On armhf in Ubuntu toolchain has -Werror=implicit-function-declaration
flag that causes the build failure.

Best Regards,
 Vladimir.

On Mon, 25 Mar 2024 at 18:27, Sebastiaan Couwenberg  wrote:
>
> Control: tags -1 upstream moreinfo
>
> On 3/25/24 3:39 AM, Vladimir Petko wrote:
> > In Ubuntu, the attached patch was applied to achieve the following:
> >* d/rules: define -D_BSD_SOURCE to ensure that strlcpy/strlcat functions
> >  are declared (LP: #2058864).
>
> That seems wrong.
>
> CMakeLists.txt checks for the existence of the function and uses its own
> implementation from mapstring.cpp if not found:
>
>   check_function_exists("strlcat"  HAVE_STRLCAT)
>   check_function_exists("strlcpy"  HAVE_STRLCPY)
>
> The functions are detected as shown in the buildlog:
>
>   -- Looking for strlcat
>   -- Looking for strlcat - found
>   -- Looking for strlcpy
>   -- Looking for strlcpy - found
>
> Why does this only happen on armhf?
>
> Kind Regards,
>
> Bas
>
> --
>   GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>



Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-24 Thread Sebastiaan Couwenberg

Control: tags -1 upstream moreinfo

On 3/25/24 3:39 AM, Vladimir Petko wrote:

In Ubuntu, the attached patch was applied to achieve the following:
   * d/rules: define -D_BSD_SOURCE to ensure that strlcpy/strlcat functions
 are declared (LP: #2058864).


That seems wrong.

CMakeLists.txt checks for the existence of the function and uses its own 
implementation from mapstring.cpp if not found:


 check_function_exists("strlcat"  HAVE_STRLCAT)
 check_function_exists("strlcpy"  HAVE_STRLCPY)

The functions are detected as shown in the buildlog:

 -- Looking for strlcat
 -- Looking for strlcat - found
 -- Looking for strlcpy
 -- Looking for strlcpy - found

Why does this only happen on armhf?

Kind Regards,

Bas

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



Bug#1067630: fixed in emacs 1:29.3+1-1

2024-03-24 Thread Max Nikulin

On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 
in Debian stable?




Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken

2024-03-24 Thread Norbert Preining
Hi Manny,

thanks for the detailed and long report, but I fear that none of the
issues are related to Debian nor TeX Live itself either.

On Sun, 24 Mar 2024, Manny wrote:
> There is a Debian-specific bug in the manual located here:
> 
>   /usr/share/doc/texlive-doc/latex/pdfcomment/pdfcomment.pdf
> 
> Page 7 links to example.pdf here:
> 
>   http://mirror.ctan.org/macros/latex/contrib/pdfcomment/doc/example.pdf

This is what the source document does. We don't rewrite all the source
documents, nor do we compile all the pdfs, neither does TeX Live.
Thus, this is an issue that can only be fixed by upupstream.

> Apart from that minor issue, there’s a bigger problem upstream. The
> “font” option is somewhat broken. Use of the font option produces

Again, this is a problem of the original package, nothing we here at
Debian nor I over at TeX Live can deal with.

> Poppler is apparently dropping the ball on fonts, even the so-called

I wouldn't be surprised, Poppler in Debian has an nearly infinite
history of breaking APIs as well as everything else. There is a reason
we on the TeX Live side use an embedded libpoppler, since anything else
is a guarantee for breakage.

> It’s worth noting that the Debian Social Contract (DSC) and Debian
> Free Software Guidelines (DFSG) condemn discrimination. Blind people
> cannot likely get passed all those CAPTCHAs to reach the upstream bug
> tracker. One might say the upstream bug tracker is not Debian’s
> problem. OTOH, the texlive package (understandably) steers people to
> file bugs upstream because this beast has the complexity of an OS in
> itself. But at the same time there’s an infrastructural problem when
> people are being directed into those shitty upstream walled gardens
> particularly when thy are discriminatory. I don’t have the answer --
> just laying out the problem.

Sorry to hear that, but again, this is out of our reach. We cannot save
the world and all software developers.
As said, at Debian we cannot do anything to fix this.
At TeX Live, we cannot do either.

Best regards

Norbert

--
PREINING Norbert  https://www.preining.info
arXiv / Cornell University   +   IFMGA Guide   +   TU Wien  +  TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"

2024-03-24 Thread Max Nikulin

Control: found -1 1:28.2+1-15

On Sun, 24 Mar 2024 16:53:55 -0300 David Bremner wrote:

** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode.
This is for security reasons, to avoid evaluating malicious Lisp code.


Emacs-28 in Debian 12 bookworm requires the fix as well.

Source: org-mode
versions 9.5 and 9.6 till 9.6.23 are affected as well.


** LaTeX preview is now by default disabled for email attachments.
To get back previous insecure behavior, set the variable
'org--latex-preview-when-risky' to a non-nil value.


This one is rather old, so almost certainly even Emacs-26 is affected.
On the other hand its severity is not so high and only users having 
latex packages installed are affected.


See also
Ihor Radchenko to emacs-orgmode… [ANN] Emergency bugfix release: Org 
mode 9.6.23. Sun, 24 Mar 2024 17:16:50 +. 
https://list.orgmode.org/871q7zbldp.fsf@localhost



The fix for LaTeX evaluation requires Emacs 29.3 and will not work for
the earlier Emacs versions. If upgrading Emacs is not viable, as a
workaround, you can set `org-preview-latex-default-process' to 'verbatim
- this will disable LaTeX previews and avoid the vulnerability.




Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-24 Thread Vladimir Petko
Package: mapserver
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

The package failed to build in Ubuntu noble on armhf:
--
/<>/mapshape.c: In function ‘msShapefileOpenHandle’:
/<>/mapshape.c:1755:3: error: implicit declaration of function
‘strlcpy’; did you mean ‘strncpy’? [-Werror=implicit-function-declaration]
 1755 | strlcpy(shpfile->source, filename, sizeof(shpfile->source));
  | ^~~
  | strncpy
/<>/mapshape.c: In function ‘msShapefileOpen’:
/<>/mapshape.c:1841:3: error: implicit declaration of function
‘strlcat’; did you mean ‘strncat’? [-Werror=implicit-function-declaration]
 1841 | strlcat(dbfFilename, ".dbf", bufferSize);
  | ^~~
  | strncat
--
See the build log[1]

strlcpy/strlcat function prototype is enabled in string.h when __USE_MISC macro
is defined.
strlcpy/strlcat functions belong to a set of functions declared on BSD
systems[2]


In Ubuntu, the attached patch was applied to achieve the following:
  * d/rules: define -D_BSD_SOURCE to ensure that strlcpy/strlcat functions
are declared (LP: #2058864).


Thanks for considering the patch.

[1] https://launchpadlibrarian.net/720858988/buildlog_ubuntu-noble-
armhf.mapserver_8.0.1-4build3_BUILDING.txt.gz
[2] https://linux.die.net/man/3/strlcat


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

Kernel: Linux 6.5.0-25-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mapserver-8.0.1/debian/rules mapserver-8.0.1/debian/rules
--- mapserver-8.0.1/debian/rules2024-03-16 20:08:52.0 +1300
+++ mapserver-8.0.1/debian/rules2024-03-25 15:19:52.0 +1300
@@ -17,7 +17,7 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
+CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) -D_BSD_SOURCE
 CFLAGS   := $(shell dpkg-buildflags --get CFLAGS)
 LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
 


Bug#1041228: policykit-1: Polkit fails if more than one rule is defined in /usr/local/share/polkit-1

2024-03-24 Thread Stepan Novotny

Hello, the bug is no longer present on Debian Trixie.
The same code which triggered it on Bookworm, works fine on Trixie.
I no longer have Bookworm so I am no longer able to replicate the problem.

Stepan



Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies

2024-03-24 Thread Otto Kekäläinen
Thanks Wouter for reporting this and Michael for submitting a merge
request for a potential fix!

The libcrypto.so.3 is from the OpenSSL package. In your upgrade case
it seems to be switching from
libssl3 [i386] to libssl3t64 [i386]. Your MariaDB packages are amd64.
This makes me wonder what is actually going on.

Were you able to recover? Can you now run manually 'systemctl --system
daemon-reload'?

This is the line dpkg was most likely running:
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.postinst#L289



Bug#1067650: davmail: O365Interactive fails with "superclass access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame"

2024-03-24 Thread Louis-Philippe Véronneau

Package: davmail
Version: 6.2.1.3496-1
Severity: important

Dear maintainers,

It seems something recently broke davmail's "O365Interactive" mode in Debian. 
When I try to use it (it's the only mode I can use since $work has mandatory 2FA), the 
login window is never shown and I get the following stacktrace:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: superclass 
access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame$2 (in 
unnamed module @0x112d0a71) cannot access class sun.net.www.protocol.https.Handler (in 
module java.base) because module java.base does not export sun.net.www.protocol.https to 
unnamed module @0x112d0a71
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at 
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
at 
davmail.exchange.auth.O365InteractiveAuthenticator.lambda$authenticate$0(O365InteractiveAuthenticator.java:150)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at 
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at 
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


Bug#1067649: Verification page is not accessible from the homepage

2024-03-24 Thread Tassia Camoes Araujo
Package: www.debian.org
Severity: important
X-Debbugs-CC: debian...@lists.debian.org

Dear www and CD teams,

When the Download link in our homepage was changed to start the iso
download right away, the old download page [1] became inaccessible (at
least not easily-accessible), making it very hard to find the
verification page [2]. I could only find it clicking on "other
downloads", then "Download mirrors", and scrolling up until the top of
the page, where a menu appears on the right, containing the link to the
verify page (I guess many of our users would totally miss it!).

My suggestion would be to replace the line "other downloads" with 2
separate links side-by-side: 

"verify authenticity" | "check all download options"

And incorporate the content of the old download page into those 2
targets, the verify and "Getting Debian" page [3] (current target of
other downloads).

[1] https://www.debian.org/download
[2] https://www.debian.org/CD/verify
[3] https://www.debian.org/distrib/

Cheers,

Tassia.



Bug#1066983: monopd: Fails to start monopd.service

2024-03-24 Thread Markus Koschany

Sylvain Rochet wrote:
> Actually, the main problem is /lib/systemd/system/monopd.socket which 
> set Accept=yes while monopd needs Accept=no (which is the default value).

I wonder if monopd needs a systemd socket file at all and if we should disable
the service after the installation. We have been using this setting since the
introduction of systemd. If monopd runs with Accept=no then we also don't need
a service template file. At some point I also noticed the same warning as
Shriram

"monopd.socket is a disabled or a static unit not running, not starting it." 
and then followed [1] and added the required template file.

I have been running monopd for the past decade and I also suspect the daemon is
affected by some bugs which might be remotely exploitable. Since users usually
don't need the monopd server anyway, if they want to play a game, they should
make a conscious decision to start it if they want to use it locally. For a
simple internet game, the daemon is not required.

[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html


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


Bug#1067648: freeciv-client-qt: segfault upon connect to a server in ___pthread_mutex_lock

2024-03-24 Thread Jeffrey Cliff
Package: freeciv-client-qt
Version: 3.1.0+ds-1+b2
Severity: important

Dear Maintainer,

what should happen

when you hit 'connect' to server for online play, it should either
connect, or fail to connect: but not segfault & crash.

game is kinda unusable if that's where it crashes.

what happens:

segfault in

#0  ___pthread_mutex_lock (mutex=0x8) at ./nptl/pthread_mutex_lock.c:80
#1  0x7f55768aea89 in __mtx_lock (mutex=) at
../sysdeps/pthread/mtx_lock.c:25
#2  0x56116e34c360 in ?? ()
#3  0x7f55fbbe in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#4  0x7f55778f49cb in
QItemSelectionModel::selectionChanged(QItemSelection const&,
QItemSelection const&)
() from /lib/x86_64-linux-gnu/libQt6Core.so.6
#5  0x7f55778f16b2 in
QItemSelectionModel::emitSelectionChanged(QItemSelection const&,
QItemSelection const&) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#6  0x7f55778f232e in QItemSelectionModel::select(QItemSelection
const&, QFlags) () from
/lib/x86_64-linux-gnu/libQt6Core.so.6
#7  0x7f55772664ba in QTableView::setSelection(QRect const&,
QFlags)
() from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#8  0x7f557720c08d in QAbstractItemView::mousePressEvent(QMouseEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#9  0x7f5576fc8f23 in QWidget::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt6Widgets.so.6
#10 0x7f5577054626 in QFrame::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt6Widgets.so.6
#11 0x7f55777332ca in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*,
QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Core.so.6
#12 0x7f5576f82d52 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#13 0x7f5576f7b62e in QApplication::notify(QObject*, QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#14 0x7f55777356d8 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Core.so.6
#15 0x7f5576f78238 in
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*,
QWidget*, QWidget**, QPointer&, bool, bool) () from
/lib/x86_64-linux-gnu/libQt6Widgets.so.6
#16 0x7f5576fd6955 in ?? () from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#17 0x7f5576fd7c95 in ?? () from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#18 0x7f5576f82d62 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#19 0x7f55777356d8 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) ()
   from /lib/x86_64-linux-gnu/libQt6Core.so.6
#20 0x7f5577d8f67b in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
() from /lib/x86_64-linux-gnu/libQt6Gui.so.6
) () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#22 0x7f5571db4c0e in ?? () from /lib/x86_64-linux-gnu/libQt6XcbQpa.so.6
#23 0x7f5575e401f4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x7f5575e43317 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x7f5575e43930 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x7f5577922f60 in
QEventDispatcherGlib::processEvents(QFlags)
() from /lib/x86_64-linux-gnu/libQt6Core.so.6
#27 0x7f557773f5ea in
QEventLoop::exec(QFlags) () from
/lib/x86_64-linux-gnu/libQt6Core.so.6
#28 0x7f55777385ca in QCoreApplication::exec() () from
/lib/x86_64-linux-gnu/libQt6Core.so.6
#29 0x56116e2d5c3a in ?? ()
#30 0x56116e22688b in ?? ()
#31 0x56116e229b48 in ?? ()
#32 0x7f55768456ca in __libc_start_call_main
(main=main@entry=0x56116e223d70 , argc=argc@entry=1,
argv=argv@entry=0x7fffd051b8d8) at
../sysdeps/nptl/libc_start_call_main.h:58
#33 0x7f5576845785 in __libc_start_main_impl (main=0x56116e223d70
, argc=1, argv=0x7fffd051b8d8, init=,
fini=, rtld_fini=,
stack_end=0x7fffd051b8c8) at ../csu/libc-start.c:360

OS: devuan ceres but :

freeciv-client-qt:
  Installed: 3.1.0+ds-1+b2
libqt6core6t64:
  Installed: 6.4.2+dfsg-21.1+b1


-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 6 (excalibur/ceres)
Release: 6
Codename: excalibur ceres
Architecture: x86_64

Kernel: Linux 6.7.0-gnmlibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages freeciv-client-qt depends on:
ii  freeciv-data 3.1.0+ds-1
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.37-15.1
ii  libcurl3t64-gnutls   8.6.0-4
ii  libgcc-s114-20240315-1
ii  libicu72 72.1-4+b1
ii  liblua5.4-0  5.4.6-3+b1
ii  liblzma5 5.6.0-0.2
ii  libqt6core6t64   6.4.2+dfsg-21.1+b1
ii  libqt6gui6t646.4.2+dfsg-21.1+b1
ii  libqt6widgets6t646.4.2+dfsg-21.1+b1
ii  libsdl2-2.0-02.30.1+dfsg-3
ii  libsdl2-mixer-2.0-0  2.8.0+dfsg-1+b1
ii  libstdc++6   

Bug#1001586: vim-gtk3: GVim sometimes freezes when receiving focus due to switching workspaces on Gnome (Wayland)

2024-03-24 Thread James McCoy
On Sun, Dec 12, 2021 at 04:03:21PM +0100, Mladen Mijatov wrote:
> GVim will sometimes freeze when switching between workspaces fast and in the
> midst of that main window receives focus. Just the interface will freeze but
> changes in mouse cursor would indicate that process beneath it is working as
> expected.
> 
> Issue is reproducible but it doesn't happen every time making it very annoying
> because it will randomly crash working environment causing loss of data.

Has this still been an issue?  If so, maybe the latest upload
(9.1.0199-1) will help, since it has some native wayland support.
See ":help gui-wayland".

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#851541: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify

2024-03-24 Thread Cyril Brulebois
Hi,

Tassia Camoes Araujo  (2024-03-25):
> I've reviewed the proposed patch, and I think it should be applied as
> soon as possible.
> 
> It seems Laura was waiting for a final review before applying this patch
> (long overdue!), which IMHO would bring much more clarity to the image
> verification process (usually, a big struggle to new users).
> 
> We should make a decision about the long key IDs request (points 1 and 2
> from #851541), and once those changes go online, I think both bugs could
> be closed (#902668 and #851541).
> 
> Thanks for all who have invested energy to clarify this process, and I
> hope we can benefit from your work very soon!
> 
> Cheers,
> 
> Tassia. 

Cc += debian-cd@ for information.


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


signature.asc
Description: PGP signature


Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify

2024-03-24 Thread Tassia Camoes Araujo
Hi,

I've reviewed the proposed patch, and I think it should be applied as
soon as possible.

It seems Laura was waiting for a final review before applying this patch
(long overdue!), which IMHO would bring much more clarity to the image
verification process (usually, a big struggle to new users).

We should make a decision about the long key IDs request (points 1 and 2
from #851541), and once those changes go online, I think both bugs could
be closed (#902668 and #851541).

Thanks for all who have invested energy to clarify this process, and I
hope we can benefit from your work very soon!

Cheers,

Tassia. 



Bug#1067647: google-perftools: FTBFS: #error Could not determine cache line length - unknown architecture

2024-03-24 Thread Thorsten Glaser
Source: google-perftools
Version: 2.15-3
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

In file included from src/common.h:43,
 from src/common.cc:43:
src/base/basictypes.h:390:5: error: #error Could not determine cache line 
length - unknown architecture
  390 | #   error Could not determine cache line length - unknown architecture
  | ^
make[1]: *** [Makefile:4970: src/libtcmalloc_internal_la-common.lo] Error 1



Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D

2024-03-24 Thread Alberto Garcia
On Sun, Mar 24, 2024 at 10:49:37PM +, Thorsten Glaser wrote:

> Please use libseccomp-dev B-D only on architectures where it
> actually exists (i.e. is not in state uncompiled).

Those would be: all of the official ones plus hppa, ppc64 and x32.

I can do that.

Berto



Bug#1067646: llvm-toolchain-17: please enable m68k build

2024-03-24 Thread Thorsten Glaser
Source: llvm-toolchain-17
Version: 1:17.0.6-9
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

Attempts to build llvm-toolchain-15 (needed for qt6) and 17 (which
is apparently what everyone should switch to, but 16 might also need
it) fail at configure stage:

  The target `M68k' is experimental and must be passed via
  LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.

Please do so ;-) I guess.



Bug#1067645: ITP: unicrypto -- Unified interface for some crypto algos

2024-03-24 Thread Josenilson Ferreira da Silva
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: unicrypto
  Version : 0.0.10
  Upstream Contact: Tamas Jos 
* URL : https://github.com/skelsec/unicrypto
* License : MIT/X
  Programming Lang: Python
  Description : Unified interface for some crypto algos

 Unicrypto is a library that provides a unified interface to a variety of
 cryptographic algorithms. With it, developers can easily integrate encryption
 into their applications, ensuring the security of data and communications.
 .
 The module also allows developers to have access to a wide range of
 encryption algorithms, including AES, DES, RC4 and TDES, among others.
 This library simplifies the process of implementing security in applications
 by providing a single consistent API for different algorithms, regardless of
 the underlying library used.



Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D

2024-03-24 Thread Thorsten Glaser
>Please use libseccomp-dev B-D only on architectures where it
>actually exists (i.e. is not in state uncompiled).
>
>webkit2gtk is a B-D for glade, which is depended on by the
>Xfce stack, as far as I can tell, whose t64 transition this blocks.

Might be useful to consider not depending on webkit2gtk in glade
for more architectures, especially these where the ratio of the
amount of users of the webkit integration by the chance of the
webkit packages being kept up to date is small; I see glade does
already have a mechanism to not use webkit on Itanic for example.

Feel free to reassign or clone-and-reassign depending on which
of these could get implemented.

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist



Bug#1067644: gcc-12: BD-Uninstallable on m68k due to gnat-11 vs gnat-12

2024-03-24 Thread Thorsten Glaser
Source: gcc-12
Version: 12.3.0-15

gcc-12 is BD-Uninstallable on m68k due to missing gnat-11
but gnat-12 is present and could probably be used, at least
in a “gnat-11 | gnat-12” alternative dependency maybe?



Bug#758969: bash: "! true &" sets $? to 1

2024-03-24 Thread Vincent Lefevre
Hi,

On 2024-03-24 00:57:26 +0100, Gioele Barabucci wrote:
> this issue does not seem to affect version 5.0-6 and later of bash.
> 
> $ ! true &
> [1] 2264193
> [1]+  Donetrue
> $ echo $?
> 0
> 
> Please reopen this bug if you can still reproduce this issue.

I confirm that this is now correct. Moreover, in the
/usr/share/doc/bash/changelog.gz file:

  This document details the changes between this version, bash-4.4-alpha, and
  the previous version, bash-4.3-release.
  [...]
  jj. Asynchronous commands now always set $? to 0 and are not affected by
  whether or not the command's exit status is being inverted.

which corresponds to this bug (I had reported the bug upstream,
see the "Forwarded" URL, and it got fixed at that time).

So it was fixed in bash 4.4.

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



Bug#1059997: razercfg: pyrazer modules installed in incorrect location

2024-03-24 Thread Craig Small
Package: razercfg
Version: 0.42+ds-4
Followup-For: Bug #1059997

Hi,

You have double "dist-packages" in the install path.

$ python3
Python 3.11.8 (main, Feb  7 2024, 21:52:08) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyrazer import *
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'pyrazer'
>>> 
$ dpkg --listfiles razercfg | grep dist-packages
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/dist-packages
/usr/lib/python3/dist-packages/dist-packages/pyrazer
/usr/lib/python3/dist-packages/dist-packages/pyrazer/__init__.py
/usr/lib/python3/dist-packages/dist-packages/pyrazer/main.py
/usr/lib/python3/dist-packages/dist-packages/pyrazer/ui.py
/usr/lib/python3/dist-packages/dist-packages/razercfg-0.42-py3.11.egg-info
/usr/lib/python3/dist-packages/dist-packages/razercfg-0.42-py3.11.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/dist-packages/razercfg-0.42-py3.11.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/dist-packages/razercfg-0.42-py3.11.egg-info/top_level.txt




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

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

Versions of packages razercfg depends on:
ii  init-system-helpers  1.66
ii  libc62.37-15
ii  libusb-1.0-0 2:1.0.27-1
ii  python3  3.11.6-1

razercfg recommends no packages.

Versions of packages razercfg suggests:
ii  python3-pyqt5  5.15.10+dfsg-1

-- no debconf information



Bug#1063965: pytest-services: autopkgtest regression with pytest 8

2024-03-24 Thread Timo Röhling

Control: reassign -1 python3-pytest 8.0.1-1
Control: close -1 8.1.1-1

It looks like this issue was caused by a regression in pytest 8.0 
and is fixed now.


On Thu, 15 Feb 2024 11:36:07 +0100 roehl...@debian.org wrote:

Package: pytest-services
Version: 2.2.1+ds-3
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: pytest-8

Dear maintainer,

your package has a autopkgtest regression with pytest 8.

Typically, packages will start failing if they

- have deprecation warnings of type PytestRemovedIn8Warning, or

- assume a particular pytest stdout/stderr output which might have
changed, or

- rely on implementation details of the pytest test collector, in
particular the pytest.Package class, which has been redesigned for
pytest 8.

Please refer to the upstream changelog [1] for a complete list of
breaking changes and the pytest (pseudo-)excuses [2] related to your
package for details of the regression.

It is possible that the autopkgtest regression is not directly caused
by pytest-services, but by one of its dependencies. In that case,
feel free to reassign the bug and mark your package as affected, but
do not close the bug until the autopkgtest passes.

Cheers Timo

[1]
https://docs.pytest.org/en/8.0.x/changelog.html#pytest-8-0-0rc1-2023-
12-30 [2]
https://qa.debian.org/excuses.php?experimental=1=pytest




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


signature.asc
Description: PGP signature


Bug#1063964: fixed in pytest-arraydiff 0.6.1-2

2024-03-24 Thread Timo Röhling

Control: reopen -1

On Thu, 29 Feb 2024 23:40:47 + Debian FTP Masters 

 - New Use-valid-test-module-names.patch (Closes: #1063964)

Unfortunately, this did not work.


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


signature.asc
Description: PGP signature


Bug#1063960: python-b2sdk: autopkgtest regression with pytest 8

2024-03-24 Thread Timo Röhling

Control: reassign -1 python3-pytest 8.0.1-1
Control: close -1 8.1.1-1

As it turns out, there was a regression in pytest 8.0 which has been 
fixed in pytest 8.1


Cheers
Timo

On Thu, 15 Feb 2024 11:36:15 +0100 roehl...@debian.org wrote:

Package: python-b2sdk
Version: 1.17.3-2
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: pytest-8

Dear maintainer,

your package has a autopkgtest regression with pytest 8.

Typically, packages will start failing if they

- have deprecation warnings of type PytestRemovedIn8Warning, or

- assume a particular pytest stdout/stderr output which might have
changed, or

- rely on implementation details of the pytest test collector, in
particular the pytest.Package class, which has been redesigned for
pytest 8.

Please refer to the upstream changelog [1] for a complete list of
breaking changes and the pytest (pseudo-)excuses [2] related to your
package for details of the regression.

It is possible that the autopkgtest regression is not directly caused
by python-b2sdk, but by one of its dependencies. In that case, feel
free to reassign the bug and mark your package as affected, but do
not close the bug until the autopkgtest passes.

Cheers Timo

[1]
https://docs.pytest.org/en/8.0.x/changelog.html#pytest-8-0-0rc1-2023-
12-30 [2]
https://qa.debian.org/excuses.php?experimental=1=pytest




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


signature.asc
Description: PGP signature


Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D

2024-03-24 Thread Thorsten Glaser
Source: webkit2gtk
Version: 2.42.5-2
Severity: important
Justification: ftbfs on d-ports architectures
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

Please use libseccomp-dev B-D only on architectures where it
actually exists (i.e. is not in state uncompiled).

webkit2gtk is a B-D for glade, which is depended on by the
Xfce stack, as far as I can tell, whose t64 transition this blocks.



Bug#1067115: gross: diff for NMU version 1.0.2-4.1

2024-03-24 Thread Adrian Bunk
On Sun, Mar 24, 2024 at 11:05:54PM +0100, Antonio Radici wrote:
> On Sat, Mar 23, 2024 at 11:45:58PM +0200, Adrian Bunk wrote:
> > Control: tags 1067115 + patch
> > Control: tags 1067115 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for gross (versioned as 1.0.2-4.1) and uploaded
> > it to DELAYED/2. Please feel free to tell me if I should cancel it.
> > 
> 
> Thanks for working on this, no reason to cancel it.
>...

Thanks, rescheduled for immediate upload.

cu
Adrian



Bug#1066928: ovn 23.03.1-1~deb12u2 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1066928 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: ovn
Version: 23.03.1-1~deb12u2

Explanation: fix insufficient validation of incoming BFD packets [CVE-2024-2182]



Bug#1065413: openssl 3.0.13-1~deb12u1 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1065413 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: openssl
Version: 3.0.13-1~deb12u1

Explanation: new upstream stable release; fix excessive time taken issues 
[CVE-2023-5678 CVE-2023-6237], vector register corruption issue on PowerPC 
[CVE-2023-6129], PKCS12 Decoding crashes [CVE-2024-0727]



Bug#1063951: fixed in barectf 3.1.2-2

2024-03-24 Thread Timo Röhling

Control: reopen -1
Control: notfixed -1 3.1.2-2

On Fri, 15 Mar 2024 21:44:05 + Debian FTP Masters 
 wrote:
   * [2375fb4] Disable pytest8 deprecation warnings (Closes: 
   #1063951)

 - Also (Closes: #1066742) built with pytest8
Unfortunately, this was not a permanent solution, because the 
features which PytestRemovedIn8Warning has been warning about, have 
been actually removed now (pytest 8.1).



Cheers
Timo


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


signature.asc
Description: PGP signature


Bug#1067115: gross: diff for NMU version 1.0.2-4.1

2024-03-24 Thread Antonio Radici
On Sat, Mar 23, 2024 at 11:45:58PM +0200, Adrian Bunk wrote:
> Control: tags 1067115 + patch
> Control: tags 1067115 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for gross (versioned as 1.0.2-4.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> 

Thanks for working on this, no reason to cancel it.

Sorry I couldn't get to this faster enough



Bug#1067639: sasl2-bin: terminates with smashed stack

2024-03-24 Thread Thorsten Glaser
Dixi quod…

>I was able to strace this:
[…]
>openat(AT_FDCWD, "/etc/__db.sasldb2", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0660) 
>= 3
>fcntl64(3, F_GETFD) = 0
>fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
>get_thread_area()   = 0xc0501500
>get_thread_area()   = 0xc0501500
>get_thread_area()   = 0xc0501500
>get_thread_area()   = 0xc0501500
>statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
>STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
>stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
>statx(AT_FDCWD, "/etc/__db.sasldb2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, 
>STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
>stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
>clock_gettime64(CLOCK_REALTIME, {tv_sec=1711315870, tv_nsec=459521594}) = 0
>clock_gettime64(CLOCK_REALTIME, {tv_sec=1711315870, tv_nsec=459846799}) = 0
>writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="stack smashing detected", 
>iov_len=23}, {iov_base=" ***: terminated\n", iov_len=17}], 3*** stack smashing 
>detected ***: terminated
>) = 44
>mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
>0xc002
>get_thread_area()   = 0xc0501500
>rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
>get_thread_area()   = 0xc0501500
>get_thread_area()   = 0xc0501500
>gettid()= 32759
>getpid()= 32759
>tgkill(32759, 32759, SIGABRT)   = 0
>--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=32759, si_uid=0} ---
>+++ killed by SIGABRT +++
>Aborted
>
>Best guess here is that the clock_gettime64 overwrote something?

This is possibly in db5.3 then.

(pbuild-31733)root@ara2:/# apt-get install gdb-minimal libdb5.3-dbg 
sasl2-bin-dbgsym libsasl2-2-dbgsym libc6-dbg
[…]
(pbuild-31733)root@ara2:/# gdb /usr/sbin/saslpasswd2
[…]
(gdb) run -c 'no:such:user' :
Cannot access memory at address 0x10b8
(gdb) b sasl_setpass
Breakpoint 2 at 0xe60
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0xe60

I don’t have much ideas how to go further because the
code paths are really hard to follow.

I also am not sure it’s in db5.3 any more, as libsasl2.so.2
isn’t linked against it…

bye,
//mirabilos
-- 
 cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können?  bis dahin gibts google nicht
mehr  ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen



Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

2024-03-24 Thread Thorsten Glaser
Dixi quod…

>OK, it’s not qemu. On ARAnyM (Atari):

I was able to strace this:

(pbuild-31733)root@ara2:/# echo '!' | strace -f saslpasswd2 -c 'no:such:user'
execve("/usr/sbin/saslpasswd2", ["saslpasswd2", "-c", "no:such:user"], 
0xefd2a90c /* 52 vars */) = 0
brk(NULL)   = 0xd0005000
openat(AT_FDCWD, "/usr/lib/libeatmydata/libeatmydata.so", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/lib/libeatmydata", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, 
STATX_BASIC_STATS, 0xef935c28) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=6940, ...}) = 0
mmap2(NULL, 6940, PROT_READ, MAP_PRIVATE, 3, 0) = 0xc0024000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libeatmydata.so", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=9460, ...}) = 0
mmap2(NULL, 24584, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0026000
mmap2(0xc0026000, 16392, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc0026000
munmap(0xc002b000, 4104)= 0
mprotect(0xc0027000, 8192, PROT_NONE)   = 0
mmap2(0xc0029000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xc0029000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/cowdancer/libcowdancer.so", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\34\4\0\0\0004"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=25936, ...}) = 0
mmap2(NULL, 41044, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc002b000
mmap2(0xc002c000, 32852, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc002c000
munmap(0xc002b000, 4096)= 0
munmap(0xc0035000, 84)  = 0
mprotect(0xc0031000, 8192, PROT_NONE)   = 0
mmap2(0xc0033000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0xc0033000
close(3)= 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libsasl2.so.2", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=91752, ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xc0035000
mmap2(NULL, 98724, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0037000
mmap2(0xc0038000, 90532, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc0038000
munmap(0xc0037000, 4096)= 0
munmap(0xc004f000, 420) = 0
mprotect(0xc004c000, 4096, PROT_NONE)   = 0
mmap2(0xc004d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0xc004d000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libc.so.6", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\2\320\210\0\0\0004"..., 512) 
= 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0755, stx_size=1535504, ...}) = 0
mmap2(NULL, 1585296, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc004f000
mmap2(0xc005, 1577104, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc005
munmap(0xc004f000, 4096)= 0
munmap(0xc01d2000, 144) = 0
mprotect(0xc01c1000, 4096, PROT_NONE)   = 0
mmap2(0xc01c2000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17) = 0xc01c2000
mmap2(0xc01c8000, 37008, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc01c8000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libdl.so.2", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=9528, ...}) = 0
mmap2(NULL, 24636, PROT_NONE, 

Bug#1067642: firefox-esr: The script for Debian’s reportbug hangs if torsocks is in play

2024-03-24 Thread Manny
Package: firefox-esr
Version: 102.6.0esr-1~deb11u1
Severity: normal
X-Debbugs-Cc: debbug.firefox-...@sideload.33mail.com

To report a bug on firefox-esr, I ran this:

  $ torsocks /usr/bin/reportbug --offline --paranoid --no-cc --email="$email" 
--draftpath="$draftpath" --output="$output_file" firefox-esr

This gets printed to the terminal:

===8<
Gathering additional data, this may take a while...
===8<

Then it goes to lunch indefinitely.  I had to kill a process that
resembled this:

  firefox-esr -dump-addons-info "$tmpfile"

When I manually run this:

  firefox-esr -dump-addons-info "$(mktemp)"

it completes quickly enough. But if I prefix torsocks like this:

  torsocks firefox-esr -dump-addons-info "$(mktemp)"

then it just hangs. This is the script that needs to be made robust
for running inside a torified network space:

  /usr/share/bug/firefox-esr/script

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libasound2   1.2.4-1.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u5
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.5-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u3
ii  pulseaudio 14.2-2

-- no debconf information



Bug#1067641: python-djangorestframework-simplejwt: CVE-2024-22513

2024-03-24 Thread Salvatore Bonaccorso
Source: python-djangorestframework-simplejwt
Version: 5.3.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for 
python-djangorestframework-simplejwt.

CVE-2024-22513[0]:
| djangorestframework-simplejwt version 5.3.1 and before is vulnerable
| to information disclosure. A user can access web application
| resources even after their account has been disabled due to missing
| user validation checks via the for_user method.


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-22513
https://www.cve.org/CVERecord?id=CVE-2024-22513
[1] https://github.com/dmdhrumilmistry/CVEs/tree/main/CVE-2024-22513

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

2024-03-24 Thread Thorsten Glaser
Dixi quod…

>The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the 
>chroot:

OK, it’s not qemu. On ARAnyM (Atari):

[…]
Setting up libldap-2.5-0:m68k (2.5.16+dfsg-2+b1) ...
Setting up sasl2-bin (2.1.28+dfsg1-5) ...
*** stack smashing detected ***: terminated
Aborted
dpkg: error processing package sasl2-bin (--configure):
 installed sasl2-bin package post-installation script subprocess returned error 
exit status 134
Processing triggers for libc-bin (2.37-15.1+b1) ...
Processing triggers for man-db (2.12.0-3+b2) ...
Not building database; man-db/auto-update is not 'true'.
Errors were encountered while processing:
 sasl2-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)


bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent



Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

2024-03-24 Thread Colin Watson
On Sat, Mar 23, 2024 at 01:49:19AM +, Thorsten Glaser wrote:
> Colin Watson dixit:
> >Could you try the somewhat further reduced patch in
> 
> The package made from that branch built fine in my cowbuilder,
> and I have all reason to assume it’ll do so in sbuild/buildd.

Thanks for the testing!

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



Bug#1007307: dbix-easy-perl: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru dbix-easy-perl-0.21/debian/changelog 
dbix-easy-perl-0.21/debian/changelog
--- dbix-easy-perl-0.21/debian/changelog2024-03-24 21:25:24.0 
+
+++ dbix-easy-perl-0.21/debian/changelog2024-03-24 21:15:35.0 
+
@@ -1,3 +1,11 @@
+dbix-easy-perl (0.21-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (Closes: #1007307).
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 24 Mar 2024 21:15:35 +
+
 dbix-easy-perl (0.21-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru dbix-easy-perl-0.21/debian/copyright 
dbix-easy-perl-0.21/debian/copyright
--- dbix-easy-perl-0.21/debian/copyright2014-01-28 16:28:04.0 
+
+++ dbix-easy-perl-0.21/debian/copyright2024-03-24 21:15:35.0 
+
@@ -1,13 +1,16 @@
-This package was debianized by Dennis Schön  on
-Thu, 25 Nov 1999 19:03:09 +0100.
-
-It was downloaded from http://www.linuxia.de/DBIx/Easy/DBIx-Easy.tar.gz
-
-Upstream Authors: Stefan Hornburg 
-  Dennis Schön 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Dennis Schön  on
+ Thu, 25 Nov 1999 19:03:09 +0100.
+Source:
+ http://www.linuxia.de/DBIx/Easy/DBIx-Easy.tar.gz
+Upstream-Contact:
+ Stefan Hornburg 
+ Dennis Schön 
 
+Files: *
 Copyright:
-
-It may be redistributed under the terms of the GNU GPL, Version 2 or
-later, found on Debian systems in the file /usr/share/common-licenses/GPL.
-
+ Copyright (C) 1999-2013 Stefan Hornburg (Racke) 
+License: GPL-2+
+ It may be redistributed under the terms of the GNU GPL, Version 2 or
+ later, found on Debian systems in the file /usr/share/common-licenses/GPL-2.
diff -Nru dbix-easy-perl-0.21/debian/source/format 
dbix-easy-perl-0.21/debian/source/format
--- dbix-easy-perl-0.21/debian/source/format1970-01-01 00:00:00.0 
+
+++ dbix-easy-perl-0.21/debian/source/format2024-03-24 21:15:35.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1067640: firefox-esr: PDF.js does not render annotations

2024-03-24 Thread Manny
Package: firefox-esr
Version: 102.6.0esr-1~deb11u1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.firefox-...@sideload.33mail.com

forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1797614

It was already reported upstream a year ago.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libasound2   1.2.4-1.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u5
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.5-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u3
ii  pulseaudio 14.2-2

-- no debconf information



Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations

2024-03-24 Thread Vagrant Cascadian
On 2024-03-24, nicolas.bouleng...@free.fr wrote:
> Hello.
> I failed to reproduce the issue on a porterbox.
>
> On arm64:
> # dpkg-source -x u-boot_2024.01+dfsg-3.dsc
> # cd u-boot_2024.01+dfsg
> # patch -p1 < ../b8d394100d6f858c0e80786f7087f96c11d698c3.diff
> # DEB_BUILD_PROFILES='pkg.uboot.notools 
> pkg.uboot.platform.a64-olinuxino' fake\
> root debian/rules binary-arch
> dpkg-gencontrol writes no warning
> debian/u-boot-{rockchip,sunxi}/DEBIAN/control contain the expected 
> Built-Using\
>   fields
>
> On armel, the control files correctly contain no Built-Using field.

I have not noticed the issues on armel, just armhf (with 0.0.5 or 0.0.6)
and arm64 (with 0.0.6).


> Could you please describe your build environment?

I use sbuild with unshare chroot mode...

Essentially, I build a tarball using a script like this:

  
https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest/-/blob/main/mm-sbuild

Then call sbuild from the source directory:

  sbuild --chroot-mode=unshare -d UNRELEASED -c sid-armhf --arch=armhf \
--no-arch-all --arch-any --source --no-run-lintian --no-clean-source \

--profiles=pkg.uboot.notools,pkg.uboot.subarch.rockchip,pkg.uboot.subarch.sunxi

Seems to behave the same with or without the build profiles, but using
the build profiles reduces the set of built packages to ones that
trigger the issue...

I use the u-boot git repository and cherry-pick
b8d394100d6f858c0e80786f7087f96c11d698c3 into current debian/latest
commit b09ea5f73b440d9f78e1de2b9b9e583ba4bc2541 tag
debian/2024.01+dfsg-3 and then bump debian/changelog appropriately.

I am running these builds on a honeycomb lx2 (arm64), which has support
for running armhf natively as well.

Just re-ran the tests again, and they still fail for me:

  
https://people.debian.org/~vagrant/dh-builtusing-issues/u-boot_2024.01+dfsg-4~0~20240324~0_arm64-2024-03-24T20:22:28Z.build.zst
  
https://people.debian.org/~vagrant/dh-builtusing-issues/u-boot_2024.01+dfsg-4~0~20240324~0_armhf-2024-03-24T20:21:58Z.build.zst

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

2024-03-24 Thread Thorsten Glaser
Package: sasl2-bin
Version: 2.1.28+dfsg1-5
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the 
chroot:

[…]
Setting up pkg-config:m68k (1.8.1-1) ...
Setting up libsasl2-2:m68k (2.1.28+dfsg1-5) ...
Setting up libsasl2-modules-gssapi-mit:m68k (2.1.28+dfsg1-5) ...
Setting up unixodbc-dev:m68k (2.3.12-1+b1) ...
Setting up libgnutls28-dev:m68k (3.8.3-1.1+b2) ...
Setting up libhcrypto5t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ...
Setting up libotp0t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ...
Setting up db-util (5.3.3) ...
Setting up bind9-libs:m68k (1:9.19.21-1+b1) ...
Setting up libsl0t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ...
Setting up sasl2-bin (2.1.28+dfsg1-5) ...
*** stack smashing detected ***: terminated
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
dpkg: error processing package sasl2-bin (--configure):
 installed sasl2-bin package post-installation script subprocess returned error 
exit status 134
Setting up libperl-dev:m68k (5.38.2-3.2+b1) ...
Setting up libsasl2-dev (2.1.28+dfsg1-5) ...
Setting up libgssrpc4t64:m68k (1.20.1-6+b1) ...
Setting up libhx509-5t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ...
dpkg: dependency problems prevent configuration of 
sbuild-build-depends-main-dummy:
 sbuild-build-depends-main-dummy depends on sasl2-bin; however:
  Package sasl2-bin is not configured yet.

dpkg: error processing package sbuild-build-depends-main-dummy (--configure):
 dependency problems - leaving unconfigured
[…]
Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ...
Setting up sasl2-bin (2.1.28+dfsg1-5) ...
BDB0002 __fop_file_setup:  Retry limit (100) exceeded
saslpasswd2: generic failure
dpkg: error processing package sasl2-bin (--configure):
 installed sasl2-bin package post-installation script subprocess returned error 
exit status 1
[…]

See: 
https://buildd.debian.org/status/fetch.php?pkg=openldap=m68k=2.5.16%2Bdfsg-2%2Bb2=1711312418=0

This does not seem to be specific to one buildd.
Any idea how this can be debugged?



Bug#1067636: nodejs: Testsuite fails with openssl 3.2

2024-03-24 Thread Jérémy Lal
Le dim. 24 mars 2024 à 21:51, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> Package: nodejs
> Version: 18.19.1+dfsg-6
> Severity: important
> Tags: sid
> control: affects -1 src:openssl
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: openssl-3.2
>
> Hi,
>
> I rebuilt nodejs in unstable against openssl 3.2 in experimental an a
> few tests failed:
>
> | Failed tests:
> | ./node /<>/test/parallel/test-crypto-rsa-dsa.js
> | ./node /<>/test/parallel/test-tls-alert-handling.js
> | ./node /<>/test/parallel/test-tls-client-auth.js
> | ./node /<>/test/parallel/test-tls-empty-sni-context.js
> | ./node --expose-internals
> /<>/test/parallel/test-tls-enable-trace.js
> | ./node --expose-internals
> /<>/test/parallel/test-tls-enable-trace-cli.js
> | ./node /<>/test/parallel/test-tls-getcipher.js
> | ./node /<>/test/parallel/test-tls-junk-server.js
> | ./node /<>/test/parallel/test-tls-psk-circuit.js
> | ./node /<>/test/parallel/test-tls-set-ciphers.js
> | ./node /<>/test/parallel/test-tls-junk-closes-server.js

Any idea how to proceed?
> I've been reading https://github.com/nodejs/node/issues/51152 but I
> don't think 3.2 support has been integrated somewhere as they just
> discussed their fork part and so on.
>
> I've been looking at the errors and some are "error code changed". I
> *think* the trace errors changed also slightly. I don't know why
> get/set-ciphers failed.


Could you share the full build log ?


Bug#1067638: nmu: libiscsi_1.19.0-3

2024-03-24 Thread Andrey Rakhmatullin
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libis...@packages.debian.org
Control: affects -1 + src:libiscsi
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libiscsi_1.19.0-3 . ANY . unstable . -m "Rebuild for time_t"

For https://release.debian.org/transitions/html/auto-rdma-core.html



Bug#1067637: nmu: kpipewire_5.27.10-1

2024-03-24 Thread Andrey Rakhmatullin
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: kpipew...@packages.debian.org
Control: affects -1 + src:kpipewire
User: release.debian@packages.debian.org
Usertags: binnmu

nmu kpipewire_5.27.10-1 . armel armhf . unstable . -m "Rebuild with
libpipewire-0.3-0t64"

https://packages.debian.org/sid/libkpipewire5



Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

2024-03-24 Thread Sebastian Andrzej Siewior
On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote:
> On Mon, 2024-03-04 at 07:38 +0100, Sebastian Andrzej Siewior wrote:
> > This is an update to the current stable OpenSSL release in the 3.0.x
> > series. It addresses the following CVE reports which were postponed
> > due to low severity:
> [...]
> > I'm not aware of a problems/ regression at this point.
> 
> Sorry for not getting to this sooner. Is this still the case?

Yes.

> Regards,
> 
> Adam

Sebastian



Bug#1032670: allegro4.4: CVE-2021-36489

2024-03-24 Thread Moritz Muehlenhoff
On Thu, Mar 21, 2024 at 09:33:51PM +0100, Andreas Rönnquist wrote:
> On Fri, 10 Mar 2023 18:04:23 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
>  wrote:
> > Source: allegro4.4
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for allegro4.4.
> > 
> > CVE-2021-36489[0]:
> > | Buffer Overflow vulnerability in Allegro through 5.2.6 allows
> > | attackers to cause a denial of service via crafted PCX/TGA/BMP files
> > | to allegro_image addon.
> > 
> > https://github.com/liballeg/allegro5/issues/1251
> > https://github.com/liballeg/allegro5/pull/1253
> > 
> > These fixes landed in Allegro 5.2.8.0:
> > https://github.com/liballeg/allegro5/commit/3f2dbd494241774d33aaf83910fd05b2a590604a
> >  (5.2.8.0)
> > https://github.com/liballeg/allegro5/commit/cca179bc16827f358153060cd10ac73d394e758c
> >  (5.2.8.0)
> > https://github.com/liballeg/allegro5/commit/a2c93939f6997a96ecac1865dbb4fa3f66b5e1b7
> >  (5.2.8.0)
> > https://github.com/liballeg/allegro5/commit/0294e28e6135292eab4b2916a7d2223b1bb6843e
> >  (5.2.8.0)
> > 
> > In allegro 4.4, code is in src/[pcx|tga].c instead
> > 
> 
> Hey
> 
> I just tried to reproduce this now on the version of Allegro 4.4 in
> Debian, and using the crash file as mentioned in
> https://github.com/liballeg/allegro5/issues/1251
> 
> I cannot reproduce the crash on 4.4.
> 
> Can you still reproduce the crash on allegro4.4 from the debian package?
> 
> For me when running './ex_bitmap crash' I get a dialog "Error reading
> bitmap file 'crash'", but no crash of the program

I never tried to reproduce these, but reproducability of a given PoC made 
against
a current version not working with an older version doesn't mean the old version
isn't affected. From a quick glance the equivalent of the checks added in 5 are
also needed in 4.4, e.g. rle_tga_read8() lacks a check for w overstepping c.

Given that all these image files are typically read from a trusted 
location/source
shipped by a given game it's not a big deal, but I'd suggest to keep the bug
open until 4.4 has been fully phased out or the fixes backported.

Cheers,
Moritz



Bug#1007543: daptup: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru daptup-0.12.7+nmu1/debian/changelog 
daptup-0.12.7+really0.12.7/debian/changelog
--- daptup-0.12.7+nmu1/debian/changelog 2021-01-05 18:22:46.0 +
+++ daptup-0.12.7+really0.12.7/debian/changelog 2024-03-24 20:30:39.0 
+
@@ -1,3 +1,11 @@
+daptup (0.12.7+really0.12.7-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (quilt). (Closes: #1007543)
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 24 Mar 2024 20:30:39 +
+
 daptup (0.12.7+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru daptup-0.12.7+nmu1/debian/control 
daptup-0.12.7+really0.12.7/debian/control
--- daptup-0.12.7+nmu1/debian/control   2015-07-25 10:17:55.0 +
+++ daptup-0.12.7+really0.12.7/debian/control   2024-03-24 20:30:39.0 
+
@@ -4,8 +4,8 @@
 Maintainer: Eugene V. Lyubimkin 
 Build-Depends-Indep: debhelper (>= 9), gettext
 Standards-Version: 3.9.6
-Vcs-Git: git://github.com/jackyf/daptup.git
-Vcs-Browser: http://github.com/jackyf/daptup
+Vcs-Git: https://github.com/jackyf/daptup.git
+Vcs-Browser: https://github.com/jackyf/daptup
 Homepage: http://sourceforge.net/projects/daptup
 
 Package: daptup
diff -Nru daptup-0.12.7+nmu1/debian/copyright 
daptup-0.12.7+really0.12.7/debian/copyright
--- daptup-0.12.7+nmu1/debian/copyright 2015-07-25 10:17:55.0 +
+++ daptup-0.12.7+really0.12.7/debian/copyright 2024-03-24 20:30:39.0 
+
@@ -1,15 +1,15 @@
-This package was debianized by Eugene V. Lyubimkin  on
-Tue, 13 May 2008 20:56:20 +0300.
-
-Sources were downloaded from http://github.com/jackyf/daptup.
-
-Upstream Author: 
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+This package was debianized by Eugene V. Lyubimkin 
+on Tue, 13 May 2008 20:56:20 +0300.
+Source:
+http://github.com/jackyf/daptup
+Upstream-Contact:
 Eugene V. Lyubimkin 
 
-Translators:
-
-   Arabic - Mohamed Magdy 
+Files: *
+Comment: Translators:
+Arabic - Mohamed Magdy 
 Czech - Miroslav Kure 
 Danish - Frank Damgaard 
 Dutch - Paul Gevers 
@@ -23,28 +23,27 @@
 Slovak - Ivan Masár 
 Swedish - Martin Bagge 
 Ukrainian - Eugene V. Lyubimkin 
-
-Program copyright: 
-
+Copyright: 
 Copyright © 2008-2009 Eugene V. Lyubimkin
-
-License: 
-
+License:  GPL-3+
 This program is free software; you can redistribute it and/or modify  
 it under the terms of the GNU General Public License v3 or later  
 as published by the Free Software Foundation. 
-
+ .
 This program is distributed in the hope that it will be useful,   
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 GNU General Public License for Libraries for more details.
-
+ .
 You should have received a copy of the GNU GPLv3  
 along with this program; if not, write to the 
 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,  
 MA 02110-1301, USA
 
-The Debian packaging is © 2008-2009,
-Eugene V. Lyubimkin 
-and is licensed under the GPLv3, see `/usr/share/common-licenses/GPL-3'.
-
+Files: debian/*
+Copyright:
+ The Debian packaging is © 2008-2009,
+ Eugene V. Lyubimkin 
+License: GPL-3
+ The Debian packaging is licensed under the GPLv3,
+ see `/usr/share/common-licenses/GPL-3'.
diff -Nru daptup-0.12.7+nmu1/debian/source/format 
daptup-0.12.7+really0.12.7/debian/source/format
--- daptup-0.12.7+nmu1/debian/source/format 1970-01-01 00:00:00.0 
+
+++ daptup-0.12.7+really0.12.7/debian/source/format 2024-03-24 
20:30:31.0 +
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1067636: nodejs: Testsuite fails with openssl 3.2

2024-03-24 Thread Sebastian Andrzej Siewior
Package: nodejs
Version: 18.19.1+dfsg-6
Severity: important
Tags: sid
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2

Hi,

I rebuilt nodejs in unstable against openssl 3.2 in experimental an a
few tests failed:

| Failed tests:
| ./node /<>/test/parallel/test-crypto-rsa-dsa.js
| ./node /<>/test/parallel/test-tls-alert-handling.js
| ./node /<>/test/parallel/test-tls-client-auth.js
| ./node /<>/test/parallel/test-tls-empty-sni-context.js
| ./node --expose-internals 
/<>/test/parallel/test-tls-enable-trace.js
| ./node --expose-internals 
/<>/test/parallel/test-tls-enable-trace-cli.js
| ./node /<>/test/parallel/test-tls-getcipher.js
| ./node /<>/test/parallel/test-tls-junk-server.js
| ./node /<>/test/parallel/test-tls-psk-circuit.js
| ./node /<>/test/parallel/test-tls-set-ciphers.js
| ./node /<>/test/parallel/test-tls-junk-closes-server.js

Any idea how to proceed?
I've been reading https://github.com/nodejs/node/issues/51152 but I
don't think 3.2 support has been integrated somewhere as they just
discussed their fork part and so on.

I've been looking at the errors and some are "error code changed". I
*think* the trace errors changed also slightly. I don't know why
get/set-ciphers failed.

Sebastian



Bug#1067635: RM: hdmi2usb-mode-switch -- ROM; unmaintained upstream, supporting old hardware

2024-03-24 Thread Stefano Rivera
Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: hdmi2usb-mode-swi...@packages.debian.org, 
debconf-vi...@lists.debian.org
Control: affects -1 + src:hdmi2usb-mode-switch
User: ftp.debian@packages.debian.org
Usertags: remove

ixo-usb-jtag and hdmi2usb-fx2-firmware FTBFS due to sdcc 4.4 (changed
syntax in sbit). I could possibly fix it, but I can't test it. I have
some devices, but they're in storage, not at hand.

Without them, I don't see any point in keeping hdmi2usb-mode-switch in
Debian.

This hardware is all long EoL, and the DebConf video team doesn't use it
any more.

Stefano



Bug#1067206: amavisd-new 2.13.0-3+deb12u1 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1067206 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: amavisd-new
Version: 2.13.0-3+deb12u1

Explanation: handle multiple boundary parameters that contain conflicting 
values [CVE-2024-28054]; fix race condition in postinst



Bug#1065562: postfix 3.7.11-0+deb12u1 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1065562 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.7.11-0+deb12u1

Explanation: new upstream stable release



Bug#1065376: libxml-stream-perl 1.24-4+deb12u1 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1065376 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: libxml-stream-perl
Version: 1.24-4+deb12u1

Explanation: fix compatibility with IO::Socket::SSL >= 2.078



Bug#1064993: systemd 252.23-1~deb12u1 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1064993 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: systemd
Version: 252.23-1~deb12u1

Explanation: new upstream stable release; fix denial of service issues 
[CVE-2023-50387 CVE-2023-50868]



Bug#1052455: freetype 2.12.1+dfsg-5+deb12u3 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1052455 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: freetype
Version: 2.12.1+dfsg-5+deb12u3

Explanation: disable COLRv1 support again; fix function existence check when 
calling get_colr_glyph_paint()



Bug#1064588: glibc 2.36-9+deb12u5 flagged for acceptance

2024-03-24 Thread Adam D Barratt
package release.debian.org
tags 1064588 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: glibc
Version: 2.36-9+deb12u5

Explanation: revert fix to always call destructors in reverse constructor order 
due to unforeseen application compatibility issues; fix a DTV corruption due to 
a reuse of a TLS module ID following dlclose with unused TLS



Bug#1067634: nmu: zbar_0.23.93-4

2024-03-24 Thread Jeremy Bícha
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: z...@packages.debian.org
Control: affects -1 src:zbar

Please binnmu zbar on armel for the time_t transition. When zbar was
last built, v4utils had not yet built on armel. This is causing
reverse dependencies like gst-plugins-bad1.0 to be in depwait.

https://buildd.debian.org/status/package.php?p=zbar
https://release.debian.org/transitions/html/auto-v4l-utils.html

nmu zbar_0.23.93-4 . armel . unstable . -m "Rebuild for time_t transition"

Thank you,
Jeremy Bícha



Bug#1067633: RM: hdmi2usb-fx2-firmware -- ROM; FTBFS, unmaintained upstream, supporting old hardware

2024-03-24 Thread Stefano Rivera
Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: hdmi2usb-fx2-firmw...@packages.debian.org, 
debconf-vi...@lists.debian.org
Control: affects -1 + src:hdmi2usb-fx2-firmware
User: ftp.debian@packages.debian.org
Usertags: remove

hdmi2usb-fx2-firmware FTBFS due to sdcc 4.4 (changed syntax in sbit). I
could possibly fix it, but I can't test it. I have some devices, but
they're in storage, not at hand.

This hardware is all long EoL, and the DebConf video team doesn't use it
any more.

Stefano



Bug#1067631: src:altree: autopkgtest timeouts on armel, armhf and ppc64el

2024-03-24 Thread Paul Gevers

Source: altree
Version: 1.3.2-2
Severity: important
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on armel, 
armhf and ppc64el. What's worse, it fails because it seems to hang and 
eventually times out due to autopkgtest. Can you please investigate the 
situation and fix it? I copied some of the output at the bottom of this 
report.


Tests that time out (while normally running in much less time) are bad 
for our infrastructure. I have added your package to our reject_list and 
will remove it once this bug is closed.


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


Paul

https://ci.debian.net/packages/a/altree/testing/ppc64el/44302877/

[---
 33s Analyzing file number 1
 33s read done
 33s Starting tree analysis
10033s autopkgtest [19:27:34]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; exec 
/tmp/autopkgtest-lxc.x1xe8end/downtmp/wrapper.sh 
--artifacts=/tmp/autopkgtest-lxc.x1xe8end/downtmp/run-unit-test-artifacts 
--chdir=/tmp/autopkgtest-lxc.x1xe8end/downtmp/build.CDX/src 
--env=DEB_BUILD_OPTIONS=parallel=12 --env=DEBIAN_FRONTEND=noninteractive 
--env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS 
--unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE 
--unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT 
--unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME 
--unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE 
--unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid 
--source-profile 
--stderr=/tmp/autopkgtest-lxc.x1xe8end/downtmp/run-unit-test-stderr 
--stdout=/tmp/autopkgtest-lxc.x1xe8end/downtmp/run-unit-test-stdout 
--tmp=/tmp/autopkgtest-lxc.x1xe8end/downtmp/autopkgtest_tmp 
--make-executable=/tmp/autopkgtest-lxc.x1xe8end/downtmp/build.CDX/src/debian/tests/run-unit-test 
--
/tmp/autopkgtest-lxc.x1xe8end/downtmp/build.CDX/src/debian/tests/run-unit-test" 
(kind: test)

10033s autopkgtest [19:27:34]: test run-unit-test: ---]


https://ci.debian.net/packages/a/altree/testing/armhf/44303364/

[---
 30s Analyzing file number 1
 30s read done
 30s Starting tree analysis
10030s autopkgtest [16:41:42]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; exec 
/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/wrapper.sh 
--artifacts=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/run-unit-test-artifacts 
--chdir=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/build.d9s/src 
--env=DEB_BUILD_OPTIONS=parallel=16 --env=DEBIAN_FRONTEND=noninteractive 
--env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS 
--unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE 
--unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT 
--unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME 
--unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE 
--unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid 
--source-profile 
--stderr=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/run-unit-test-stderr 
--stdout=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/run-unit-test-stdout 
--tmp=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/autopkgtest_tmp 
--make-executable=/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/build.d9s/src/debian/tests/run-unit-test 
--
/tmp/autopkgtest-lxc.t0hkn0wb/downtmp/build.d9s/src/debian/tests/run-unit-test" 
(kind: test)

10030s autopkgtest [16:41:42]: test run-unit-test: ---]


https://ci.debian.net/packages/a/altree/testing/armel/44303363/

[---
 27s Analyzing file number 1
 27s read done
 27s Starting tree analysis
10026s autopkgtest [16:42:42]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; exec 
/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/wrapper.sh 
--artifacts=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/run-unit-test-artifacts 
--chdir=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/build.TUH/src 
--env=DEB_BUILD_OPTIONS=parallel=16 --env=DEBIAN_FRONTEND=noninteractive 
--env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS 
--unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE 
--unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT 
--unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME 
--unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE 
--unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid 
--source-profile 
--stderr=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/run-unit-test-stderr 
--stdout=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/run-unit-test-stdout 
--tmp=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/autopkgtest_tmp 
--make-executable=/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/build.TUH/src/debian/tests/run-unit-test 
--
/tmp/autopkgtest-lxc.fyuvj4mn/downtmp/build.TUH/src/debian/tests/run-unit-test" 
(kind: test)

10026s autopkgtest [16:42:42]: test run-unit-test: ---]



Bug#1067632: RM: ixo-usb-jtag -- ROM; FTBFS, unmaintained upstream, supporting old hardware

2024-03-24 Thread Stefano Rivera
Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: ixo-usb-j...@packages.debian.org, debconf-vi...@lists.debian.org
Control: affects -1 + src:ixo-usb-jtag
User: ftp.debian@packages.debian.org
Usertags: remove

ixo-usb-jtag FTBFS due to sdcc 4.4 (changed syntax in sbit). I could
possibly fix it, but I can't test it. I have some devices, but they're
in storage, not at hand.

This hardware is all long EoL, and the DebConf video team doesn't use it
any more.

Stefano



Bug#1007546: d52: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru d52-3.4.1/debian/changelog d52-3.4.1/debian/changelog
--- d52-3.4.1/debian/changelog  2024-03-24 20:20:10.0 +
+++ d52-3.4.1/debian/changelog  2024-03-24 20:03:49.0 +
@@ -1,3 +1,11 @@
+d52 (3.4.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007546)
+  * d/copyright: Convert to machine-readable format. (Closes: #898214, #977211)
+
+ -- Bastian Germann   Sun, 24 Mar 2024 20:03:49 +
+
 d52 (3.4.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru d52-3.4.1/debian/control d52-3.4.1/debian/control
--- d52-3.4.1/debian/control2024-03-24 20:20:10.0 +
+++ d52-3.4.1/debian/control2024-03-24 20:03:49.0 +
@@ -4,7 +4,7 @@
 Maintainer: Uwe Hermann 
 Build-Depends: cdbs, debhelper (>= 5)
 Standards-Version: 3.7.3
-Homepage: http://home.pacbell.net/theposts
+Homepage: https://github.com/jblang/d52
 
 Package: d52
 Architecture: any
@@ -16,4 +16,3 @@
   - d52: a disassembler for 8052 code,
   - d48: a disassembler for 8048/8041 code,
   - dz80: a disassembler for Z80/8080/8085 code.
-
diff -Nru d52-3.4.1/debian/copyright d52-3.4.1/debian/copyright
--- d52-3.4.1/debian/copyright  2024-03-24 20:20:10.0 +
+++ d52-3.4.1/debian/copyright  2024-03-24 20:03:49.0 +
@@ -1,28 +1,20 @@
-This package was debianized by Uwe Hermann  on
-Sat, 16 Feb 2008 15:45:54 +0100.
-
-It was downloaded from:
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+This package was debianized by Uwe Hermann  on
+Sat, 16 Feb 2008 15:45:54 +0100.
+Source:
 http://home.pacbell.net/theposts
-
-Upstream Author:
-
+Upstream-Contact:
 Jeff Post 
 

-
 Files: *
 Copyright: © 1995-2007 Jeff Post 
 License: GPL-3+
-
-On Debian systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL-3'.
-

+ On Debian systems, the complete text of the GNU General
+ Public License can be found in `/usr/share/common-licenses/GPL-3'.
 
 Files: debian/*
 Copyright: © 2008 Uwe Hermann 
 License: GPL-2+
 The Debian packaging is (C) 2008, Uwe Hermann  and
 is licensed under the GPL (version 2 or later), see above.
-
diff -Nru d52-3.4.1/debian/patches/10_honor_nostrip.patch 
d52-3.4.1/debian/patches/10_honor_nostrip.patch
--- d52-3.4.1/debian/patches/10_honor_nostrip.patch 2024-03-24 
20:20:10.0 +
+++ d52-3.4.1/debian/patches/10_honor_nostrip.patch 2024-03-24 
20:03:49.0 +
@@ -1,5 +1,5 @@
 Makefile.orig  2008-02-16 16:13:55.0 +0100
-+++ Makefile   2008-02-16 16:14:32.0 +0100
+--- a/Makefile.orig2008-02-16 16:13:55.0 +0100
 b/Makefile 2008-02-16 16:14:32.0 +0100
 @@ -27,15 +27,12 @@
  
  d52: $(D52OBJS)
diff -Nru d52-3.4.1/debian/patches/series d52-3.4.1/debian/patches/series
--- d52-3.4.1/debian/patches/series 1970-01-01 00:00:00.0 +
+++ d52-3.4.1/debian/patches/series 2024-03-24 20:03:49.0 +
@@ -0,0 +1,2 @@
+10_honor_nostrip.patch
+20-fix-format-security-error.patch
diff -Nru d52-3.4.1/debian/rules d52-3.4.1/debian/rules
--- d52-3.4.1/debian/rules  2024-03-24 20:20:10.0 +
+++ d52-3.4.1/debian/rules  2024-03-24 20:03:49.0 +
@@ -4,7 +4,6 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/makefile.mk
-include /usr/share/cdbs/1/rules/simple-patchsys.mk
 
 install/d52::
install d52 debian/d52/usr/bin
diff -Nru d52-3.4.1/debian/source/format d52-3.4.1/debian/source/format
--- d52-3.4.1/debian/source/format  1970-01-01 00:00:00.0 +
+++ d52-3.4.1/debian/source/format  2024-03-24 20:03:49.0 +
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-24 Thread Lucas Castro

retitle 1064297 RFS: lsm/1.0.21-1 -- Link connectivity monitor tool


As the source package has changed the package could be retrieve by the 
following url.


The source builds the following binary packages:

  foolsm - Link connectivity monitor tool
  lsm - Link connectivity monitor tool - transitional package

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc


Em 24/03/2024 16:50, Lucas Castro escreveu:


Em 23/03/2024 13:08, Tobias Frost escreveu:

Control: tags -1 moreinfo

The source package name is still being renamed, and the source package
rename is not explictly stated in the changelog.


Source package already kept old project name, only binary renamed.


I had talked about the source package rename on IRC, and no problem 
was pointed as serious then the my conclusion it wasn't going to be a 
problem.


But, by the way, it's going to be kept as it was.



(I think this renane shouldn't be done, to keep the history of the
package, not only the tracker but also the BTS and all the other
services working on source packages.)

(You should also bump the timestamp in the d/changelog, when uploading a
new package to mentors.)

Timestamp bumped.


The patch in package should be fowarded; as it only changes *comments*,
consider dropping it completly.


Dropped the patch, ASAP I'll forward to upstream.


Already uploaded to mentors.



--
tobi


Thanks Tobias.




On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro 
wrote:

Em 06/03/2024 05:49, Daniel Gröber escreveu:

Hi Lucas,

On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:

Are you sure you want to change the source package name? Doing so

fractures

the history of the package on tracker.d.o and it's not really

necessary.

The upstream has changed software name but it's a good point about
tracker.d.o.

Right, so users will try to `apt install foolsm` in the future, but

the

source package name is largeley irellevant to them.


Quick package review:

 - d/postinst: I don't think it's useful to print the message

about editing

   the config. I've only seen packages do that in special

circumstances, do

   you have a justification for it being necessary here?

Really, really not. I really would like improve that, I guess to

write good

doc and manual pages is enough.

I would argue users (sysadmins in this case) are going to be

familiar with

the concept of having to configure a package before it becomes

useful and

while the daemon not being started at package installation is
unconventional in Debian automatic config reloading is by far not

universal

so any config change to make lsm useful is going to elicit a restart
anyway.

So I just don't see why we'd want a conspicuous message telling

people what

they already know :)


 - You declare Replaces+Conflicts on lsm but you don't seem to

take any

   care for the new binary package to actually be compatible

with the old

   one since the config location changed.

I'm in doubt, when the old config exist, if set dpkg to copy the

old config

from old location to the new one or if I just print/show up a

message to

users notifying about path update requirement.

I think an automatic upgrade is the way to go in this case as long

as the

config format is still fully compatible to the old lsm-1.0.4, but

since

copying will leave cruft behind for the user to cleanup manually I

think we

should mv the config.


If it's good/allowed do the copy, it could be applied in postinst.

I think

print/show up message is rightest way.

Consider that people upgrade Debian systems for many, many years

without

reinstalling. So every bit of cruft we leave behind due to

transitions such

as this accumulates. I don't see a technical need for not doing so

in this

case so I think we should clean up behind ourselves and move the

config to

the new location.

You should then absoluteley print a message in the log to note this

fact,

but perhaps not as conspicuously as you're printing the "configure

me"

message. Something like "Moving $OLD_PATH to $NEW_PATH" should

suffice

since the package(s) involved should be obvious from the filenames.

Just uploaded to mentors again, now the update occur smoothly.



--Daniel

Thanks for taking time on testing update.


OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

2024-03-24 Thread Adam D. Barratt
On Mon, 2024-03-04 at 07:38 +0100, Sebastian Andrzej Siewior wrote:
> This is an update to the current stable OpenSSL release in the 3.0.x
> series. It addresses the following CVE reports which were postponed
> due to low severity:
[...]
> I'm not aware of a problems/ regression at this point.

Sorry for not getting to this sooner. Is this still the case?

Regards,

Adam



Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-24 Thread Lucas Castro


Em 23/03/2024 13:08, Tobias Frost escreveu:

Control: tags -1 moreinfo

The source package name is still being renamed, and the source package
rename is not explictly stated in the changelog.


Source package already kept old project name, only binary renamed.


I had talked about the source package rename on IRC, and no problem was 
pointed as serious then the my conclusion it wasn't going to be a problem.


But, by the way, it's going to be kept as it was.



(I think this renane shouldn't be done, to keep the history of the
package, not only the tracker but also the BTS and all the other
services working on source packages.)

(You should also bump the timestamp in the d/changelog, when uploading a
new package to mentors.)

Timestamp bumped.


The patch in package should be fowarded; as it only changes *comments*,
consider dropping it completly.


Dropped the patch, ASAP I'll forward to upstream.


Already uploaded to mentors.



--
tobi


Thanks Tobias.




On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro 
wrote:

Em 06/03/2024 05:49, Daniel Gröber escreveu:

Hi Lucas,

On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:

Are you sure you want to change the source package name? Doing so

fractures

the history of the package on tracker.d.o and it's not really

necessary.

The upstream has changed software name but it's a good point about
tracker.d.o.

Right, so users will try to `apt install foolsm` in the future, but

the

source package name is largeley irellevant to them.


Quick package review:

     - d/postinst: I don't think it's useful to print the message

about editing

   the config. I've only seen packages do that in special

circumstances, do

   you have a justification for it being necessary here?

Really, really not. I really would like improve that, I guess to

write good

doc and manual pages is enough.

I would argue users (sysadmins in this case) are going to be

familiar with

the concept of having to configure a package before it becomes

useful and

while the daemon not being started at package installation is
unconventional in Debian automatic config reloading is by far not

universal

so any config change to make lsm useful is going to elicit a restart
anyway.

So I just don't see why we'd want a conspicuous message telling

people what

they already know :)


     - You declare Replaces+Conflicts on lsm but you don't seem to

take any

   care for the new binary package to actually be compatible

with the old

   one since the config location changed.

I'm in doubt, when the old config exist, if set dpkg to copy the

old config

from old location to the new one or if I just print/show up a

message to

users notifying about path update requirement.

I think an automatic upgrade is the way to go in this case as long

as the

config format is still fully compatible to the old lsm-1.0.4, but

since

copying will leave cruft behind for the user to cleanup manually I

think we

should mv the config.


If it's good/allowed do the copy, it could be applied in postinst.

I think

print/show up message is rightest way.

Consider that people upgrade Debian systems for many, many years

without

reinstalling. So every bit of cruft we leave behind due to

transitions such

as this accumulates. I don't see a technical need for not doing so

in this

case so I think we should clean up behind ourselves and move the

config to

the new location.

You should then absoluteley print a message in the log to note this

fact,

but perhaps not as conspicuously as you're printing the "configure

me"

message. Something like "Moving $OLD_PATH to $NEW_PATH" should

suffice

since the package(s) involved should be obvious from the filenames.

Just uploaded to mentors again, now the update occur smoothly.



--Daniel

Thanks for taking time on testing update.


OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1007516: cycfx2prog: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cycfx2prog-0.47/debian/changelog cycfx2prog-0.47/debian/changelog
--- cycfx2prog-0.47/debian/changelog2024-03-24 20:00:36.0 +
+++ cycfx2prog-0.47/debian/changelog2024-03-24 19:53:34.0 +
@@ -1,3 +1,11 @@
+cycfx2prog (0.47-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007516)
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 24 Mar 2024 19:53:34 +
+
 cycfx2prog (0.47-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru cycfx2prog-0.47/debian/copyright cycfx2prog-0.47/debian/copyright
--- cycfx2prog-0.47/debian/copyright2024-03-24 20:00:36.0 +
+++ cycfx2prog-0.47/debian/copyright2024-03-24 19:53:34.0 +
@@ -1,28 +1,20 @@
-This package was debianized by Uwe Hermann  on
-Fri, 15 Feb 2008 12:51:41 +0100.
-
-It was downloaded from:
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+This package was debianized by Uwe Hermann  on
+Fri, 15 Feb 2008 12:51:41 +0100.
+Source:
 http://www.triplespark.net/elec/periph/USB-FX2/software/
-
-Upstream Author: 
-
+Upstream-Contact: 
 Wolfgang Wieser 
 

-
 Files: *
 Copyright: © 2006-2009 Wolfgang Wieser 
 License: GPL-2
-
-On Debian systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL-2'.
-

+ On Debian systems, the complete text of the GNU General
+ Public License can be found in `/usr/share/common-licenses/GPL-2'.
 
 Files: debian/*
 Copyright: © 2008-2010 Uwe Hermann 
 License: GPL-2+
 The Debian packaging is © 2008-2010, Uwe Hermann  and
 is licensed under the GPL (version 2 or later), see above.
-
diff -Nru cycfx2prog-0.47/debian/source/format 
cycfx2prog-0.47/debian/source/format
--- cycfx2prog-0.47/debian/source/format1970-01-01 00:00:00.0 
+
+++ cycfx2prog-0.47/debian/source/format2024-03-24 19:53:34.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"

2024-03-24 Thread David Bremner
Source: emacs
Version: 29.2+1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team , 
debian-emac...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


According to the 29.3 release notes

* Changes in Emacs 29.3
Emacs 29.3 is an emergency bugfix release intended to fix several
security vulnerabilities described below.

** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode.
This is for security reasons, to avoid evaluating malicious Lisp code.

** New buffer-local variable 'untrusted-content'.
When this is non-nil, Lisp programs should treat buffer contents with
extra caution.

** Gnus now treats inline MIME contents as untrusted.
To get back previous insecure behavior, 'untrusted-content' should be
reset to nil in the buffer.

** LaTeX preview is now by default disabled for email attachments.
To get back previous insecure behavior, set the variable
'org--latex-preview-when-risky' to a non-nil value.

** Org mode now considers contents of remote files to be untrusted.
Remote files are recognized by calling 'file-remote-p'.

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYAhNIACgkQA0U5G1Wq
FSEANg//cukjqohXxNRpkxbutqHHvOB1aAr3d78jowjP3Yb9ozAArNxUjuJHEdSZ
5HCASm269atf5753maZILjyx3VmF/qUihyGjbbWjqMwNrQkkQiuXBfYn1F4R76/V
tyFile5NZVXIgYMykLb+rSHap6KMBnhjvLWSwNsDMuD8WB7OPH7KOI2xYqkUb7ue
SIgkCr0GJ+LaHOAYlRKkAYok4qwIfijLBw41Bt7t9Tawh+5d5nDkNPDphFOB+bG+
1hOQD8KVYWIceRK83wcDictSxbeTSo/cp6cEtVZX3yrDvBRbj3VKjKWL+0UIKfWO
iGWQYn622B7WbBIwEddQMmla+nxa5rxEN9VMEE8N5xcpI1lnL0lVSxw0jbT0FopJ
PmwFYmz1+pxB2fhRTv1T7ZTSAJS3BKQ9u2R8tuKO5ilSYp1zJrBBIazGPZ3Q+UBS
EoPh4hy5G4IZ3X3yaE9cX76fdDMMGPQ7HIinkw5A7KWb8zHse5m3+WG+iPNuveHU
GRwOB9pDDRTQrQVG8of2YVS0kLb9eu2jUD0sbi8As3P5Mr/gXHlrSgs5t1qg3HuA
Kkg7m7PAONZu0LBZNZsItm/V0weDqBdE+LZsa/1LUk3H+zvswhctlNLuZ7Y4mKqh
YpuwmZ2+cv1To2M/DKbBx2ngl5EiojF8hk5pGezcZ811NRFAQKc=
=BxE4
-END PGP SIGNATURE-



Bug#1007063: cli-common: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cli-common-0.10+nmu1/debian/changelog 
cli-common-0.10+nmu2/debian/changelog
--- cli-common-0.10+nmu1/debian/changelog   2022-04-21 12:30:10.0 
+
+++ cli-common-0.10+nmu2/debian/changelog   2024-03-24 19:40:23.0 
+
@@ -1,3 +1,10 @@
+cli-common (0.10+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007063)
+
+ -- Bastian Germann   Sun, 24 Mar 2024 19:40:23 +
+
 cli-common (0.10+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cli-common-0.10+nmu1/debian/copyright 
cli-common-0.10+nmu2/debian/copyright
--- cli-common-0.10+nmu1/debian/copyright   2019-03-11 15:26:56.0 
+
+++ cli-common-0.10+nmu2/debian/copyright   2024-03-24 19:40:23.0 
+
@@ -1,11 +1,10 @@
-This package was debianized by Mirco Bauer  using the
-keyboard.
-
-Upstream Authors:
-Mirco Bauer 
-Eduard Bloch 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment: This package was debianized by Mirco Bauer .
 
+Files: *
 Copyright:
-
-Distributed on the terms of the GNU General Public License which can
-be found in the file /usr/share/common-licenses/GPL on Debian systems.
+ Mirco Bauer 
+ Eduard Bloch 
+License: GPL
+ Distributed on the terms of the GNU General Public License which can
+ be found in the file /usr/share/common-licenses/GPL on Debian systems.
diff -Nru cli-common-0.10+nmu1/debian/source/format 
cli-common-0.10+nmu2/debian/source/format
--- cli-common-0.10+nmu1/debian/source/format   1970-01-01 00:00:00.0 
+
+++ cli-common-0.10+nmu2/debian/source/format   2024-03-24 19:40:23.0 
+
@@ -0,0 +1 @@
+3.0 (native)


Bug#1067628: FTBFS: Error: symbol `open64' is already define

2024-03-24 Thread Andrey Rakhmatullin
Source: cctools
Version: 9.9-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=cctools=armel=9.9-4%2Bb2=1711271394=0


/tmp/ccxWFvuU.s: Assembler messages:
/tmp/ccxWFvuU.s:1927: Error: symbol `open64' is already defined


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

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



Bug#1067627: FTBFS: error: comparison of integer expressions of different signedness: ‘long unsigned int’ and ‘long int’

2024-03-24 Thread Andrey Rakhmatullin
Source: xpra
Version: 3.1.5+dfsg1-0.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=xpra=i386=3.1.5%2Bdfsg1-0.2%2Bb3=1710056306=0

xpra/x11/bindings/keyboard_bindings.c: In function ‘__Pyx_PyInt_AndObjC’:
xpra/x11/bindings/keyboard_bindings.c:30158:36: error: comparison of integer
expressions of different signedness: ‘long unsigned int’ and ‘long int’
[-Werror=sign-compare]
30158 | if ((intval & PyLong_MASK) == intval) {
  |^~
xpra/x11/bindings/keyboard_bindings.c:30160:71: error: operand of ‘?:’ changes
signedness from ‘long int’ to ‘long unsigned int’ due to unsignedness of other
operand [-Werror=sign-compare]
30160 | long result = intval & (likely(__Pyx_PyLong_IsPos(op1)) ?
last_digit : (PyLong_MASK - last_digit + 1));
  |
^~


Note that the package enables -Werror.


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

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


Bug#1067626: FTBFS: fopen_fails test failed

2024-03-24 Thread Andrey Rakhmatullin
Source: pacemaker
Version: 2.1.6-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pacemaker=armel=2.1.6-5=1711156223=0

PASS: pcmk__output_new_test 1 - empty_formatters
PASS: pcmk__output_new_test 2 - invalid_params
PASS: pcmk__output_new_test 3 - no_such_format
PASS: pcmk__output_new_test 4 - create_fails
PASS: pcmk__output_new_test 5 - init_fails
FAIL: pcmk__output_new_test 6 - fopen_fails
PASS: pcmk__output_new_test 7 - everything_succeeds
PASS: pcmk__output_new_test 8 - no_fmt_name_given
ERROR: pcmk__output_new_test - exited with status 1


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

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



Bug#1067625: FTBFS on armel: undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'

2024-03-24 Thread Andrey Rakhmatullin
Source: transmission
Version: 4.0.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=transmission=armel=4.0.5-1%2Bb1=1711181507=0

/usr/bin/ld: ../../libtransmission/libtransmission.a(web.cc.o): undefined
reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'
/usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: DSO
missing from command line


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

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



Bug#1067624: FTBFS: error: ‘struct input_event’ has no member named ‘time’

2024-03-24 Thread Andrey Rakhmatullin
Source: antimicro
Version: 3.1.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=antimicro=armel=3.1.4-1%2Bb1=1711183999=0

/<>/src/eventhandlers/uinputeventhandler.cpp: In member function
‘void UInputEventHandler::write_uinput_event(int, int, int, int, bool)’:
/<>/src/eventhandlers/uinputeventhandler.cpp:454:22: error:
‘struct input_event’ has no member named ‘time’
  454 | gettimeofday(, nullptr);
  |  ^~~~
/<>/src/eventhandlers/uinputeventhandler.cpp:464:27: error:
‘struct input_event’ has no member named ‘time’
  464 | gettimeofday(, nullptr);
  |   ^~~~


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

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


Bug#1067623: FTBFS: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘__time64_t’ {aka ‘long long int’}

2024-03-24 Thread Andrey Rakhmatullin
Source: acm
Version: 6.0+20200416-1.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=acm=armel=6.0%2B20200416-1.1%2Bb2=1711183805=0

disscope.c: In function ‘main’:
disscope.c:242:45: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=]
  242 | printf ("Time stamp   %ld.%ld\n", tm.tv_sec,


Note that the package enables -Werror.


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

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


Bug#1043087: clamassassin: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru clamassassin-1.2.4/debian/changelog 
clamassassin-1.2.4/debian/changelog
--- clamassassin-1.2.4/debian/changelog 2024-03-24 19:05:09.0 +
+++ clamassassin-1.2.4/debian/changelog 2024-03-24 18:59:21.0 +
@@ -1,3 +1,11 @@
+clamassassin (1.2.4-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0, closes: #1043087.
+  * d/control: Add debhelper-generated misc:Depends.
+
+ -- Bastian Germann   Sun, 24 Mar 2024 18:59:21 +
+
 clamassassin (1.2.4-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru clamassassin-1.2.4/debian/control clamassassin-1.2.4/debian/control
--- clamassassin-1.2.4/debian/control   2024-03-24 19:05:09.0 +
+++ clamassassin-1.2.4/debian/control   2024-03-24 18:59:21.0 +
@@ -7,7 +7,7 @@
 
 Package: clamassassin
 Architecture: all
-Depends: clamav, procmail
+Depends: clamav, procmail, ${misc:Depends}
 Description: email virus filter wrapper for ClamAV
  clamassassin is a simple virus filter wrapper for ClamAV for use in procmail
  filters and similar applications. clamassassin's interface is similar to
diff -Nru clamassassin-1.2.4/debian/source/format 
clamassassin-1.2.4/debian/source/format
--- clamassassin-1.2.4/debian/source/format 1970-01-01 00:00:00.0 
+
+++ clamassassin-1.2.4/debian/source/format 2024-03-24 18:59:21.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1067616: FTBFS: error: ‘struct input_event’ has no member named ‘time’

2024-03-24 Thread Simon McVittie
On Sun, 24 Mar 2024 at 23:06:18 +0500, Andrey Rakhmatullin wrote:
> GLX/input_device_linuxevent.cpp: In member function ‘virtual void
> CL_InputDevice_LinuxEvent::keep_alive()’:
> GLX/input_device_linuxevent.cpp:269:72: error: ‘struct input_event’ has no
> member named ‘time’
>   269 |
> ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report
> Sync" );

Looks like another instance of essentially the same issue that's fixed in
SDL by . Applying the
same technique would probably work here too.

smcv



Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Julian Andres Klode
Control: reassign -1 grub-efi-amd64-signed
Control: fixed -1 1+2.12+1+b1
Control: close -1

On Sun, Mar 24, 2024 at 06:23:56PM +0100, Eduard Bloch wrote:
> reopen 1067486
> reassign 1067486 apt
> severity 1067486 normal
> thanks

This is stupid, you should know better.

> 
> Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode:
> 
> > > Please upload a new version so grub-efi-amd64-signed can be installable.
> > > Thanks!
> > 
> > I'm getting a bit tired of this. This is normal, the packages are
> > automatically generated but need to be approved by ftpteam. 
> 
> This might be a normal condition but a) this is not transparent to user,
> and b) it really does break apt's operation, at least partly.
> 
> For a) maybe we should make this somehow auto-checked remotely and shown
> in reportbug? Or would you have a better idea?
> 
> And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes,
> failing, user getting completely locked out. And "upgrade" operation
> installed just a fraction of the potential candidates (there were more
> reasons for that but the lack of dist-upgrade feature is still PITA).
> And the reason has not been obvious, and even debugging with
> -oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades.
> 
> And the eventual solution was close examination, and some
> guessing/observing that apt is confused and jumps between amd64 and
> i386, and then some FORCE magic, i.e.
> 
> dpkg --remove --force-depends grub-common:i386
> 
> (don't ask me how this package got installed before, that system
> installation has been migrated a lot). Another candidate was an old
> iproute:i386 package which I also had to remove.


These kinds of issues will be resolved eventually on grubs side, but
that aside, if you want to run unstable, you gotta learn to live with
these kind of situations and you gotta know what is a bug and what is
not. Seemingly you don't know how to deal with unstable, because you
should know that this is not a bug in apt.

This was a conscious decision by the release team to not have an
unstable-proposed and gate unstable by installability (and testing),
and we gotta live with it.

Users should be running testing, not unstable. We do not provide any
guarantees that dependencies can be resolved or that a dist-upgrade
won't remove your entire system for unstable. You should not use it.

The unsolicited backport to bookworm was worse because people trying
to install that also ended up with breakage, sadly there is no migration
for backports, there should be a bookworm-backports-proposed and a
britney. Again this is a process issue that you are welcome to raise
with the ftp team, release team, and backports team.

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



Bug#1043086: cl-irc-logger: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cl-irc-logger-0.9.4/debian/changelog 
cl-irc-logger-0.9.4/debian/changelog
--- cl-irc-logger-0.9.4/debian/changelog2024-03-24 18:52:52.0 
+
+++ cl-irc-logger-0.9.4/debian/changelog2024-03-24 18:44:09.0 
+
@@ -1,3 +1,10 @@
+cl-irc-logger (0.9.4-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Convert to source format 3.0 (closes: #1043086)
+
+ -- Bastian Germann   Sun, 24 Mar 2024 18:44:09 +
+
 cl-irc-logger (0.9.4-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cl-irc-logger-0.9.4/debian/copyright 
cl-irc-logger-0.9.4/debian/copyright
--- cl-irc-logger-0.9.4/debian/copyright2024-03-24 18:52:52.0 
+
+++ cl-irc-logger-0.9.4/debian/copyright2024-03-24 18:44:09.0 
+
@@ -1,30 +1,27 @@
-Debian Copyright Section
-
-
-Upstream Source URL: http://files.b9.com/irc-logger/
-Upstream Authors: Kevin Rosenberg 
-Debian Maintainer:  Kevin M. Rosenberg 
-
-Upstream Copyright Statement
-
-Copyright (c) 2003 Kevin Rosenberg
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED "AS IS" AND THERE ARE NEITHER EXPRESSED NOR
-IMPLIED WARRANTIES - THIS INCLUDES, BUT IS NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.IN
-NO WAY ARE THE AUTHORS LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES ; LOSS OF USE,
-DATA, OR PROFITS ; OR BUSINESS INTERRUPTION)
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source:
+ http://files.b9.com/irc-logger/
+Upstream-Contact:
+ Kevin Rosenberg 
+
+Files: *
+Copyright: (c) 2003 Kevin Rosenberg
+License: BSD-2-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ .
+ 1. Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+ .
+ 2. Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+ .
+ THIS SOFTWARE IS PROVIDED "AS IS" AND THERE ARE NEITHER EXPRESSED NOR
+ IMPLIED WARRANTIES - THIS INCLUDES, BUT IS NOT LIMITED TO, THE IMPLIED
+ WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.IN
+ NO WAY ARE THE AUTHORS LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES ; LOSS OF USE,
+ DATA, OR PROFITS ; OR BUSINESS INTERRUPTION)
diff -Nru cl-irc-logger-0.9.4/debian/source/format 
cl-irc-logger-0.9.4/debian/source/format
--- cl-irc-logger-0.9.4/debian/source/format1970-01-01 00:00:00.0 
+
+++ cl-irc-logger-0.9.4/debian/source/format2024-03-24 18:44:09.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early

2024-03-24 Thread Jmkr
Hello,

I also hit this bug when switching from BIOS to UEFI boot process. Details for 
context are in the next paragraph, but feel free to skip to the QUESTION part:).

After disabling the legacy BIOS support on my machines I noticed UEFI boot 
process uses the native LCD resolution. This causes smaller looking console 
fonts. It also makes GRUB use its GFXTERM font that in addition to being small 
has completely different style compared to "Uni2-VGA16.psf.gz". I previously 
used that ugly default looking font just to avoid even uglier noticeable font 
switching (during both booting and installing Debian). Thanks to Jörg Sommer's 
scripts I was finally able to set a much nicer and more adequately sized font 
("Uni2-TerminusBold24x12.psf.gz") without noticeable font switching during 
booting. I did not finish integrating this into my customized Debian installer 
yet, but it is still a nice improvement for my machines.

QUESTION:
I have one question about INITRAMFS-TOOLS PREREQ mechanism. My other scripts 
use this redundant-looking "PREREQ" variable + "prereqs" function:
...
PREREQ='...'

prereqs () {
echo "$PREREQ"
}

case "$1" in
prereqs)
prereqs
exit 0;;
esac
...
I tested that all my INITRAMFS-TOOLS scripts work with this code or without it 
(= echo '...' directly in "case" statement like in Jörg's scripts) - at least 
the system boots fine. But I noticed that the INITRAMFS-TOOLS(7) manpage also 
recommends such code. So does anyone know if and why the "PREREQ" variable + 
"prereqs" function is really necessary?

Regards,
Jmkr



Bug#1007331: cereal: please consider upgrading to 3.0 source format

2024-03-24 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cereal-0.24/debian/changelog cereal-0.24/debian/changelog
--- cereal-0.24/debian/changelog2024-03-24 18:34:28.0 +
+++ cereal-0.24/debian/changelog2024-03-24 18:20:32.0 +
@@ -1,3 +1,12 @@
+cereal (0.24-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007331)
+  * d/copyright: Convert to machine-readable format.
+  * d/control: Set Priority to optional from deprecated extra.
+
+ -- Bastian Germann   Sun, 24 Mar 2024 18:20:32 +
+
 cereal (0.24-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru cereal-0.24/debian/control cereal-0.24/debian/control
--- cereal-0.24/debian/control  2024-03-24 18:34:28.0 +
+++ cereal-0.24/debian/control  2024-03-24 18:20:32.0 +
@@ -1,6 +1,6 @@
 Source: cereal
 Section: utils
-Priority: extra
+Priority: optional
 Maintainer: Daniel Kahn Gillmor 
 Uploaders: Jameson Graef Rollins 
 Build-Depends: debhelper (>= 7.0)
diff -Nru cereal-0.24/debian/copyright cereal-0.24/debian/copyright
--- cereal-0.24/debian/copyright2024-03-24 18:34:28.0 +
+++ cereal-0.24/debian/copyright2024-03-24 18:20:32.0 +
@@ -1,12 +1,15 @@
-This package was debianized by Daniel Kahn Gillmor
- on Thu, 15 Mar 2007 01:12:29 -0400.
-
-It was downloaded from http://cmrg.fifthhorseman.net/wiki/cereal
-
-Upstream Authors: Jameson Graef Rollins  and 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Daniel Kahn Gillmor
+  on Thu, 15 Mar 2007 01:12:29 -0400.
+Source:
+ http://cmrg.fifthhorseman.net/wiki/cereal
+Upstream-Contact:
+ Jameson Graef Rollins  and 
  Daniel Kahn Gillmor 
 
+Files: *
 Copyright: 2007 Daniel Kahn Gillmor and Jameson Rollins
-
-License: cereal is distributed under the GNU GPL v3 or later
- (see /usr/share/common-licenses/GPL) 
+License: GPL-3+
+ cereal is distributed under the GNU GPL v3 or later
+ (see /usr/share/common-licenses/GPL-3) 
diff -Nru cereal-0.24/debian/source/format cereal-0.24/debian/source/format
--- cereal-0.24/debian/source/format1970-01-01 00:00:00.0 +
+++ cereal-0.24/debian/source/format2024-03-24 18:20:32.0 +
@@ -0,0 +1 @@
+3.0 (quilt)


Bug#1067622: FTBFS: error: missing initializer for member ‘input_event::value’

2024-03-24 Thread Andrey Rakhmatullin
Source: projecteur
Version: 0.10-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=projecteur=armel=0.10-2%2Bb2=1711185228=0

/<>/src/deviceinput.cc: In member function ‘void
InputMapper::Impl::emitNativeKeySequence(const NativeKeySequence&)’:
/<>/src/deviceinput.cc:697:64: error: narrowing conversion of
‘(int32_t)ie.DeviceInputEvent::value’ from ‘int32_t’ {aka ‘int’} to ‘__u16’
{aka ‘short unsigned int’} [-Werror=narrowing]
  697 |   events.emplace_back(input_event{{}, ie.type, ie.code, ie.value});
  | ~~~^
/<>/src/deviceinput.cc:697:69: error: missing initializer for
member ‘input_event::value’ [-Werror=missing-field-initializers]
  697 |   events.emplace_back(input_event{{}, ie.type, ie.code, ie.value});
  | ^
/<>/src/deviceinput.cc: In lambda function:
/<>/src/deviceinput.cc:893:55: error: narrowing conversion of
‘(int32_t)de.DeviceInputEvent::value’ from ‘int32_t’ {aka ‘int’} to ‘__u16’
{aka ‘short unsigned int’} [-Werror=narrowing]
  893 | struct input_event ie = {{}, de.type, de.code, de.value};
  |~~~^
/<>/src/deviceinput.cc:893:60: error: missing initializer for
member ‘input_event::value’ [-Werror=missing-field-initializers]
  893 | struct input_event ie = {{}, de.type, de.code, de.value};
  |^
/<>/src/deviceinput.cc: In member function ‘void
InputMapper::addEvents(const KeyEvent&)’:
/<>/src/deviceinput.cc:906:79: error: missing initializer for
member ‘input_event::value’ [-Werror=missing-field-initializers]
  906 |   if (!hasLastSYN) { events.emplace_back(input_event{{}, EV_SYN,
SYN_REPORT, 0}); }
  |
^



Note that this package enables -Werror.


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

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


Bug#1067529: libonvif: Please package new upstream version

2024-03-24 Thread Stephen Rhodes
Hi Petter,

Hope you are having a nice day. I am researching my options for making a
Debian package for a python program, hope to have something soon.

Best Regards,

Stephen

On Sat, Mar 23, 2024 at 1:51 AM Petter Reinholdtsen  wrote:

>
> Package: onvif-tools
> Version: 1.4.4-1
> Severity: wishlist
>
> According to https://github.com/sr99622/libonvif/tags >, the
> latest upstream version of libonvif is 2.0.1, while the latest Debian
> package is 1.4.4.
>
> Please update to the latest upstream version in Debian to make recording
> and multistream support available.
>
> --
> Happy hacking
> Petter Reinholdtsen
>


Bug#1067611: privoxy takes more than 2 mins to start.

2024-03-24 Thread Eric Valette

On 24/03/2024 19:01, Eric Valette wrote:

On 24/03/2024 18:46, Roland Rosenfeld wrote:

Hi Eric!



What do you see in the output of
   systemctl status network-online.target privoxy.service
On my system provoxy starts a the moment when network-online is active
and takes 1 second to start.
Can you see, when network-online is active on your system?  Is it just
after booting or does it also take these two minutes?



I can browse internet via another browser or read mail with thunderbird 
while privoxy is still starting up. So network is up I have no idea for 
network-online precisely but still.


systemctl status network-online.target privoxy.service
● network-online.target - Network is Online
  Loaded: loaded (/usr/lib/systemd/system/network-online.target; 
static)

  Active: active since Sun 2024-03-24 17:04:32 CET; 2h 4min ago
Docs: man:systemd.special(7)
  https://systemd.io/NETWORK_ONLINE

mars 24 17:04:32 tri-yann5 systemd[1]: Reached target 
network-online.target - Network is Online.


● privoxy.service - Privacy enhancing HTTP Proxy
  Loaded: loaded (/usr/lib/systemd/system/privoxy.service; enabled; 
preset: enabled)
  Active: active (running) since Sun 2024-03-24 17:04:33 CET; 2h 
4min ago

Docs: man:privoxy(8)
  https://www.privoxy.org/user-manual/
Main PID: 8125 (privoxy)
   Tasks: 9 (limit: 37429)
  Memory: 10.7M (peak: 30.9M)
 CPU: 1.423s
  CGroup: /system.slice/privoxy.service
  └─8125 /usr/sbin/privoxy --pidfile /run/privoxy.pid 
--user privoxy /etc/privoxy/config


so apprently the culprit is network online that comes long after TCP/IP 
stack is up and running with both IPV4 and V6 available.



systemctl is-enabled NetworkManager-wait-online.service 
systemd-networkd-wait-online.service

enabled
enabled

So I guess I should disable networkd-wait-online.service

-- eric




Bug#1067620: add max version to python3-ruamel.yaml dependency

2024-03-24 Thread David Mandelberg

Package: whipper
Version: 0.10.0-2

From https://github.com/whipper-team/whipper/issues/605 and 
https://github.com/whipper-team/whipper/issues/606 it looks like whipper 
fails with newer version of ruamel.yaml. Should the Debian package add a 
max version to the dependency to prevent it breaking when 
python3-ruamel.yaml is updated?




Bug#1067621: FTBFS on 32-bit time64 architectures: error: implicit declaration of function ‘gzopen64’

2024-03-24 Thread Andrey Rakhmatullin
Source: berkeley-abc
Version: 1.01+20230625git01b1bd1+dfsg-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=berkeley-
abc=armel=1.01%2B20230625git01b1bd1%2Bdfsg-3%2Bb2=1711273244=0

In file included from src/base/io/ioReadBlifMv.c:21:
src/base/io/ioReadBlifMv.c: In function ‘Io_MvLoadFileGz’:
./src/misc/zlib/zlib.h:1583:18: error: implicit declaration of function
‘gzopen64’; did you mean ‘gzopen’? [-Werror=implicit-function-declaration]
 1583 | #  define gzopen gzopen64


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

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


Bug#1067619: FTBFS: tests segfault

2024-03-24 Thread Andrey Rakhmatullin
Source: falcosecurity-libs
Version: 0.14.1-5.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=falcosecurity-
libs=i386=0.14.1-5.1=1709205669=0

[ RUN  ] sinsp_with_test_input.spawn_process
Segmentation fault
gmake[9]: *** [libsinsp/test/CMakeFiles/run-unit-test-
libsinsp.dir/build.make:73: libsinsp/test/CMakeFiles/run-unit-test-libsinsp]
Error 139


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

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



Bug#1067618: FTBFS: error: implicit declaration of function 'yyerror'; did you mean 'yyerrok'? [-Werror=implicit-function-declaration]

2024-03-24 Thread Andrey Rakhmatullin
Source: whitedune
Version: 0.30.10-2.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=whitedune=armel=0.30.10-2.2%2Bb1=1711185326=0

y.tab.c: In function 'yyparse':
y.tab.c:2666:7: error: implicit declaration of function 'yyerror'; did you mean
'yyerrok'? [-Werror=implicit-function-declaration]


linux/SDL_sysjoystick.c: In function ‘HandleHat’:
linux/SDL_sysjoystick.c:525:9: error: implicit declaration of function
‘SDL_PrivateJoystickHat’ [-Werror=implicit-function-declaration]
  525 | SDL_PrivateJoystickHat(stick, hat,
  | ^~
linux/SDL_sysjoystick.c: In function ‘JS_HandleEvents’:
linux/SDL_sysjoystick.c:567:21: error: implicit declaration of function
‘SDL_PrivateJoystickAxis’ [-Werror=implicit-function-declaration]
  567 | SDL_PrivateJoystickAxis(joystick,
  | ^~~
linux/SDL_sysjoystick.c:598:17: error: implicit declaration of function
‘SDL_PrivateJoystickButton’ [-Werror=implicit-function-declaration]
  598 | SDL_PrivateJoystickButton(joystick,
  | ^
linux/SDL_sysjoystick.c: In function ‘SDL_SYS_JoystickUpdate’:
linux/SDL_sysjoystick.c:717:13: error: implicit declaration of function
‘SDL_PrivateJoystickBall’ [-Werror=implicit-function-declaration]
  717 | SDL_PrivateJoystickBall(joystick, (Uint8)i, xrel, yrel);
  | ^~~


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

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


Bug#1067617: gnuchess: pgnsave only saves last move

2024-03-24 Thread Chris Moser
Package: gnuchess
Version: 6.2.7-1
Severity: normal
X-Debbugs-Cc: chrismmo...@gmail.com

Dear Maintainer,

To reproduce:
Run gnuchess from the CLI
gnuchess

Make a move, wait for gnuchess to make a move
e4

Save the game
pgnsave game0.pgn

Exit gnuchess and examine the game file
exit
cat game0.pgn

The move list shows only the final move of gnuchess ("e5" for example)
It should show the turn number and both the user and gnuchess moves "1. e4 e5"  

-Chris


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

Kernel: Linux 6.6.15-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 gnuchess depends on:
ii  libc6  2.37-15

Versions of packages gnuchess recommends:
ii  gnuchess-book  1.02-2.1

Versions of packages gnuchess suggests:
ii  xboard  4.9.1-2+b1

-- no debconf information



Bug#1067616: FTBFS: error: ‘struct input_event’ has no member named ‘time’

2024-03-24 Thread Andrey Rakhmatullin
Source: clanlib
Version: 1.0~svn3827-11.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=clanlib=armel=1.0%7Esvn3827-11.1=1711185366=0

GLX/input_device_linuxevent.cpp: In member function ‘virtual void
CL_InputDevice_LinuxEvent::keep_alive()’:
GLX/input_device_linuxevent.cpp:269:72: error: ‘struct input_event’ has no
member named ‘time’
  269 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report
Sync" );
  |
^~~~
GLX/input_device_linuxevent.cpp:269:91: error: ‘struct input_event’ has no
member named ‘time’
  269 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report
Sync" );
  |
^~~~
GLX/input_device_linuxevent.cpp:274:72: error: ‘struct input_event’ has no
member named ‘time’
  274 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
  |
^~~~
GLX/input_device_linuxevent.cpp:274:91: error: ‘struct input_event’ has no
member named ‘time’
  274 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
  |
^~~~
GLX/input_device_linuxevent.cpp:283:72: error: ‘struct input_event’ has no
member named ‘time’
  283 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
  |
^~~~
GLX/input_device_linuxevent.cpp:283:91: error: ‘struct input_event’ has no
member named ‘time’
  283 |
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,


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

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


Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

2024-03-24 Thread Chris Lamb
Alberto Bertogli wrote:

> I'll try to get a debian install to boot for armhf, but it'll take me a 
> bit because it's not straightforward (to put it mildly :).

Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.

> How urgent/important is this issue?

Medium? As it is technically a regression (as in, armhf used to build
before), this was filed with a severity of "serious". What this means
in practical terms is that newer versions of libfiu we upload will not
migrate to the staging area for the next release of Debian.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-



Bug#1067611: privoxy takes more than 2 mins to start.

2024-03-24 Thread Eric Valette

On 24/03/2024 18:46, Roland Rosenfeld wrote:

Hi Eric!

Thank you for your bug report.

On So, 24 Mär 2024, Eric Valette wrote:


Package: privoxy
Version: 3.0.34-3+b2
Severity: important

Usually the first thing I do after booting is starting firefox. Here
I have to start until privoxy starts which takes aroun two mins.

I purged the package, reinstalled. No change.


I didn't notice a problem with privoxy startup time, so let's try to
track down what's the root cause of your problem is.

privoxy waits for network-online.target before it starts.
Maybe you could check, whether network-online or privoxy is delaying
here.

What do you see in the output of
   systemctl status network-online.target privoxy.service
On my system provoxy starts a the moment when network-online is active
and takes 1 second to start.
Can you see, when network-online is active on your system?  Is it just
after booting or does it also take these two minutes?



I can browse internet via another browser or read mail with thunderbird 
while privoxy is still starting up. So network is up I have no idea for 
network-online precisely but still.


Even when the system is up, if I do service privoxy stop and then start 
it takes long so I bet it is privoxy.




If the former, this isn't a privoxy issue, since privoxy has to wait
for a working network, otherwise it isn't able to bind the interfaces
(this was a problem in
https://bugs.launchpad.net/ubuntu/+source/privoxy/+bug/1870101).

If it's a problem in privoxy, that it is really starting up delayed,
what do you see
  journalctl -u privoxy
or in /varl/log/privoxy/logfile?


I already did that without success. But I can try again.


Maybe you should (temporarily) increase debug level in
/etc/provoxy/config (maybe debug 4096 could be helpful, maybe others,
too).

Does your problem only happen on system startup or can you reproduce
it via
  systemctl stop privoxy; systemctl start privoxy


See above. Will spend some time to debug it but not now.


Greetings
Roland


-- eric




Bug#1067615: FTBFS: error: size of array ‘dummyinfo_does_not_fit’ is negative

2024-03-24 Thread Andrey Rakhmatullin
Source: osmo-pcu
Version: 1.1.0-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=osmo-
pcu=armel=1.1.0-3%2Bb2=1711272169=0

/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"osmo-pcu\"
-DPACKAGE_TARNAME=\"osmo-pcu\" -DPACKAGE_VERSION=\"1.1.0\"
-DPACKAGE_STRING=\"osmo-pcu\ 1.1.0\" -DPACKAGE_BUGREPORT=\"osmocom-net-
g...@lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"osmo-pcu\"
-DVERSION=\"1.1.0\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I.  -I../include -Wall -I/usr/include/ -pthread
-I/usr/include/ -pthread  -I/usr/include/ -pthread  -I/usr/include/ -pthread
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2  -g -O2 -Werror=implicit-function-declaration -ffile-
prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection
-Wformat -Werror=format-security -std=gnu11 -c -o osmobts_sock.lo
osmobts_sock.c
In file included from /usr/include/osmocom/core/msgb.h:20,
 from llc.c:21:
llc.c: In function ‘llc_queue_enqueue’:
llc.c:145:9: error: size of array ‘dummyinfo_does_not_fit’ is negative
  145 | osmo_static_assert(sizeof(*meta_storage) <=
sizeof(llc_msg->cb), info_does_not_fit);
  | ^~


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

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


Bug#1067611: privoxy takes more than 2 mins to start.

2024-03-24 Thread Roland Rosenfeld
Hi Eric!

Thank you for your bug report.

On So, 24 Mär 2024, Eric Valette wrote:

> Package: privoxy
> Version: 3.0.34-3+b2
> Severity: important
> 
> Usually the first thing I do after booting is starting firefox. Here
> I have to start until privoxy starts which takes aroun two mins.
> 
> I purged the package, reinstalled. No change.

I didn't notice a problem with privoxy startup time, so let's try to
track down what's the root cause of your problem is.

privoxy waits for network-online.target before it starts.
Maybe you could check, whether network-online or privoxy is delaying
here.

What do you see in the output of
  systemctl status network-online.target privoxy.service
On my system provoxy starts a the moment when network-online is active
and takes 1 second to start.
Can you see, when network-online is active on your system?  Is it just
after booting or does it also take these two minutes?

If the former, this isn't a privoxy issue, since privoxy has to wait
for a working network, otherwise it isn't able to bind the interfaces
(this was a problem in
https://bugs.launchpad.net/ubuntu/+source/privoxy/+bug/1870101).

If it's a problem in privoxy, that it is really starting up delayed,
what do you see
 journalctl -u privoxy
or in /varl/log/privoxy/logfile?
Maybe you should (temporarily) increase debug level in
/etc/provoxy/config (maybe debug 4096 could be helpful, maybe others,
too).

Does your problem only happen on system startup or can you reproduce
it via
 systemctl stop privoxy; systemctl start privoxy

Greetings
Roland



Bug#1066465: closed by Debian FTP Masters (reply to Filip Hroch ) (Bug#1066465: fixed in dcraw 9.28-4)

2024-03-24 Thread Andrey Rakhmatullin
Control: found -1 dcraw/9.28-4

On Sun, Mar 24, 2024 at 05:21:05PM +, Debian Bug Tracking System wrote:
>  dcraw (9.28-4) unstable; urgency=low
>  .
>* Added missing headers. Closes: #1066465
Unfortunately, by overwriting the 9.28-3.1 changes you removed the fix,
not added it, as your independent fix is not enough:
https://buildd.debian.org/status/fetch.php?pkg=dcraw=armhf=9.28-4=1711301891=0
This also suggests that you have some workflow problems which you should
fix, as ignoring NMUs, working on already closed bugs and uploading
packages that don't build shouldn't ideally happen.



Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken

2024-03-24 Thread Manny
Package: texlive-latex-extra
Version: 2020.20210202-3
Severity: normal
X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com

There is a Debian-specific bug in the manual located here:

  /usr/share/doc/texlive-doc/latex/pdfcomment/pdfcomment.pdf

Page 7 links to example.pdf here:

  http://mirror.ctan.org/macros/latex/contrib/pdfcomment/doc/example.pdf

It references the cloud location when in fact there is a local copy of
example.pdf in the same directory as the manual itself. This occurs in
a few other places in the manual, such as page 12. The links should
reference the local file so there is no network dependency. Anything
can go wrong with links into the cloud, such as websites joining
Cloudflare (which then denies access to several demographics of
people).

Apart from that minor issue, there’s a bigger problem upstream. The
“font” option is somewhat broken. Use of the font option produces
documents that only render correctly in Adobe Acrobat. Bug 1067612
gives more detail, sample code, and sample output:

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

Poppler is apparently dropping the ball on fonts, even the so-called
14 standard fonts that the manual claims are safe. The manual needs to
go further to clarify and warn. I wasted a lot of time trying to
figure out why even the most mainstream fonts were not rendering
before someone told me to try Acrobat.

There is very likely a defect in pdfcomment that cause a giant arrow
to appear in the middle of every page where \pdffreetextcomment is
used. It’s apparent in the attachments to bug 1067612:

  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1067612;filename=example_Acro.djvu;msg=5
  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1067612;filename=annotation_font_samples_Acro.djvu;msg=5

It’s also worth noting that the default font isn’t good for the
annotation purpose. An uppercase “I” is just a vertical bar which is
indistinguishable from a digit 1 or lowercase “l”. It’s not a good
default to be trapped with for annotations where you do not generally
have much text to infer context. E.g. if a lawyer wants to label
something “Exhibit I” there can be confusion.. is that Exhibit 1 or
Exhibit “l”?

There is a problem when pdfcomment is imported before the datetime2
package. This causes an option clash error:

  \usepackage{pdfcomment}
  \usepackage[calc,useregional]{datetime2}

But if that sequence is reversed, there is no error. I’m not sure if
that’s something that needs to be fixed in the code, but if not then I
suggest noting the idiosyncracy in the manual because it can be tricky
for users to sort out the problem.

I tried to report the upstream-specific bugs upstream. It was a
disaster. Hence why this bug report herein is a blend of upstream and
downstream bugs. I followed this process in attempt to register on
bitbucket:

① solved a CAPTCHA just to reach a reg. form (I have image loading
disabled but the graphical CAPTCHA puzzle displayed anyway [Firefox
bug?])

② disposable email address rejected (so Bitbucket can protect themselves from 
spam but other people cannot?)

③ tried a forwarding acct instead of disposable (accepted)

③ another CAPTCHA emerged, this time Google reCAPTCHA. I never solve
these because it violates so many digital right principles and I
boycott Google. I made an exception for this experiment. The puzzle
was empty because I disable images (can’t afford the
bandwidth). Exceptionally, I enable images for this poorly designed
website. I managed to solve enough of the ambiguous puzzles to get a
pass.

④ got the green checkmark ✓

⑤ clicked “sign up”

⑥ “We are having trouble verifying reCAPTCHA for this request. Please
try again. If the problem persists, try another browser/device or
reach out to Atlassian Support.”

So Google profited from my labor in solving a reCAPTCHA then my access
was refused by Bitbucket anyway.

It’s worth noting that the Debian Social Contract (DSC) and Debian
Free Software Guidelines (DFSG) condemn discrimination. Blind people
cannot likely get passed all those CAPTCHAs to reach the upstream bug
tracker. One might say the upstream bug tracker is not Debian’s
problem. OTOH, the texlive package (understandably) steers people to
file bugs upstream because this beast has the complexity of an OS in
itself. But at the same time there’s an infrastructural problem when
people are being directed into those shitty upstream walled gardens
particularly when thy are discriminatory. I don’t have the answer --
just laying out the problem.

It gets worse. So then (step ⑦) I attempted to e-mail the code author:

===8<
status=bounced (host $authors_own_mx_svr said: 550-host $my_ip
is listed at combined.mail.abusix.zone (127.0.0.11);
550 see https://lookup.abusix.com/search?q=$my_ip
(in reply to RCPT TO command))
===8<

If only the Debian-specific bug is worked and the rest of this report
is 

Bug#1066396: lftp: FTBFS: ./config.h:2540:11: fatal error: trio.h: No such file or directory

2024-03-24 Thread Andreas Metzler
Control: tags -1 patch

On 2024-03-24 Andrey Rakhmatullin  wrote:
> On Wed, Mar 13, 2024 at 01:03:20PM +0100, Lucas Nussbaum wrote:
> > > ./config.h:2540:11: fatal error: trio.h: No such file or directory
> > >  2540 | # include "trio.h"
> > >   |   ^~~~
> (this suggests that using trio is not actually supported but that's
> irrelevant)
> This is caused by the stdio detection failing and should be fixed by
> adding #include  to the test case code in m4/needtrio.m4 but this
> package doesn't run autoreconf so fixing d/rules to at least do that is
> also needed.
[...]

As a hotfix touch-magic can also be used.

cu Andreas

diff --git a/debian/rules b/debian/rules
index e0872ed..ab41336 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,6 +19,9 @@ CFLAGS += -g -Wall
 
 #configure: configure-stamp
 configure-stamp:
+	# Avoid autoconf rebuild due to patching input files.
+	touch --reference=aclocal.m4 configure m4/needtrio.m4
+	touch --reference=Makefile.am m4/needtrio.m4
 	dh_testdir
 	# Add here commands to configure the package.
 	CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure \
--- lftp-4.9.2.orig/configure
+++ lftp-4.9.2/configure
@@ -57429,6 +57429,7 @@ else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+	#include 
 	 int main()
 	 {
 	unsigned long long x=0,x1;
--- lftp-4.9.2.orig/m4/needtrio.m4
+++ lftp-4.9.2/m4/needtrio.m4
@@ -9,6 +9,7 @@ AC_DEFUN([LFTP_NEED_TRIO],[
   else
 
   AC_RUN_IFELSE([AC_LANG_SOURCE([[
+	#include 
 	 int main()
 	 {
 	unsigned long long x=0,x1;


Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch
reopen 1067486
reassign 1067486 apt
severity 1067486 normal
thanks

Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode:

> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 

This might be a normal condition but a) this is not transparent to user,
and b) it really does break apt's operation, at least partly.

For a) maybe we should make this somehow auto-checked remotely and shown
in reportbug? Or would you have a better idea?

And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes,
failing, user getting completely locked out. And "upgrade" operation
installed just a fraction of the potential candidates (there were more
reasons for that but the lack of dist-upgrade feature is still PITA).
And the reason has not been obvious, and even debugging with
-oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades.

And the eventual solution was close examination, and some
guessing/observing that apt is confused and jumps between amd64 and
i386, and then some FORCE magic, i.e.

dpkg --remove --force-depends grub-common:i386

(don't ask me how this package got installed before, that system
installation has been migrated a lot). Another candidate was an old
iproute:i386 package which I also had to remove.

Best regards,
Eduard.



Bug#1067613: openjdk-11: FTBFS on alpha: d/rules references deleted patch (trivial fix)

2024-03-24 Thread Thorsten Glaser
Source: openjdk-11
Version: 11.0.19+7-1
Severity: important
Justification: FTBFS on d-ports arch

 debian/rules binary-arch
: # apply some architecture specific patches ...
patch -p1 < debian/patches/alpha-float-const.diff
/bin/bash: line 1: debian/patches/alpha-float-const.diff: No such file or 
directory
make: *** [debian/rules:1016: stamps/unpack] Error 1


The patch got removed (ok, correct) but it needs to
be removed from where d/rules adds it to the list of
patches, too.



Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch
On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode 
 wrote:
> Version: 1+2.12+1+b1
> 
> (this should be the right version when it gets accepted)
> 
> On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote:
> > Package: grub-efi-amd64-signed
> > Version: 1+2.12+1
> > Severity: serious
> > X-Debbugs-Cc: sweetyf...@deepin.org
> > 
> > Hi,
> > 
> > grub-efi-amd64-signed seems uninstallable now in sid. This might caused
> > by a binNMU in src:grub2.
> > 
> > The following packages have unmet dependencies:
> >  grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not 
> > going to be installed
> > 
> > $ apt policy grub-common
> > grub-common:
> >   Installed: (none)
> >   Candidate: 2.12-1+b1
> >   Version table:
> >  2.12-1+b1 500
> > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages
> > 
> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 
> 
> And people are probably understandably hesitant to accept them because future
> binNMUs are expected.
> 
> So Please do not file bugs for them, it is out of our hands.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
> 



Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch
On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode 
 wrote:
> Version: 1+2.12+1+b1
> 
> (this should be the right version when it gets accepted)
> 
> On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote:
> > Package: grub-efi-amd64-signed
> > Version: 1+2.12+1
> > Severity: serious
> > X-Debbugs-Cc: sweetyf...@deepin.org
> > 
> > Hi,
> > 
> > grub-efi-amd64-signed seems uninstallable now in sid. This might caused
> > by a binNMU in src:grub2.
> > 
> > The following packages have unmet dependencies:
> >  grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not 
> > going to be installed
> > 
> > $ apt policy grub-common
> > grub-common:
> >   Installed: (none)
> >   Candidate: 2.12-1+b1
> >   Version table:
> >  2.12-1+b1 500
> > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages
> > 
> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 
> 
> And people are probably understandably hesitant to accept them because future
> binNMUs are expected.
> 
> So Please do not file bugs for them, it is out of our hands.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
> 



Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations

2024-03-24 Thread nicolas . boulenguez

Hello.
I failed to reproduce the issue on a porterbox.

On arm64:
# dpkg-source -x u-boot_2024.01+dfsg-3.dsc
# cd u-boot_2024.01+dfsg
# patch -p1 < ../b8d394100d6f858c0e80786f7087f96c11d698c3.diff
# DEB_BUILD_PROFILES='pkg.uboot.notools 
pkg.uboot.platform.a64-olinuxino' fake\

root debian/rules binary-arch
dpkg-gencontrol writes no warning
debian/u-boot-{rockchip,sunxi}/DEBIAN/control contain the expected 
Built-Using\

 fields

On armel, the control files correctly contain no Built-Using field.

Could you please describe your build environment?

  1   2   >