Bug#1065794: 1065794 is pending

[Maximilian Engelhardt]

Control: tags -1 + pending

Hi Sebastian,

Thanks for your report. We (the Debian xen team) are aware of this issue and 
are currently preparing an upload fixing this problem. It should be uploaded 
to the archive soon.

Maxi

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

Bug#1063270: xen: NMU diff for 64-bit time_t transition

[Maximilian Engelhardt]

Control: found -1 4.17.2+76-ge1f9cb16e2-1

Hi Steve,

Thanks for taking care about the 64-bit time_t transition.

Unfortunately your attached patch looks a bit strange to me. It adds 
autogenerated files, but especially FTBFS in your experimental upload.

You can find an updated patch attached to this mail that only contains the 
relevant changes and does the rename in one more place to fix the FTBFS.

With this mail I also mark the xen version currently in testing as affected so 
this bug does not prevent the migration of the xen version currently in 
unstable (4.17.3+10-g091466ba55-1).

I also did compile xen in qemu for armhf one time with the current unstable 
version and one time with the change below to test the time_t transition.
The resulting binaries were the same (thanks xen is buildable reproducibly).
So maybe the transition is not needed for xen, but unfortunately my knowledge 
is not that much that I can say this for sure.


--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,10 @@ export DEB_VERSION
 # DEB_MAINTAINER is used by our delta queue
 export DEB_MAINTAINER := $(shell sed -ne 's/^Maintainer: \(.*\)$$/\1/p' 
debian/control)
 
+export DEB_BUILD_OPTIONS=abi=+lfs
+export _FILE_OFFSET_BITS=64
+export _TIME_BITS=64
+
 # This influences dpkg-buildflags to specify better linker
 # options.  See https://wiki.debian.org/Hardening
 # Apparently some of these might incur silent breakage
@@ -26,7 +30,7 @@ export DEB_MAINTAINER := $(shell sed -ne 's/^Maintainer: 
\(.*\)$$/\1/p' debian/c
 # Inexplicably, if you tell make `export V=value' and `$(shell ...)'
 # it does not pass V to the shell.  WTF.  So we set a variable
 # dbmo which we include in the relevant $(shell ...) invocations.
-dbmo= DEB_BUILD_MAINT_OPTIONS="hardening=+all"
+dbmo= DEB_BUILD_MAINT_OPTIONS="hardening=+all abi=+lfs" _FILE_OFFSET_BITS=64 
_TIME_BITS=64
 
 # Architecture handling.
 #

diff -Nru xen-4.17.3+10-g091466ba55/debian/changelog xen-4.17.3+10-g091466ba55/debian/changelog
--- xen-4.17.3+10-g091466ba55/debian/changelog	2024-02-04 13:45:17.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/changelog	2024-02-05 23:37:19.0 +0100
@@ -1,3 +1,10 @@
+xen (4.17.3+10-g091466ba55-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 05 Feb 2024 22:37:19 +
+
 xen (4.17.3+10-g091466ba55-1) unstable; urgency=medium
 
   * Update to new upstream version 4.17.3+10-g091466ba55, which also contains
diff -Nru xen-4.17.3+10-g091466ba55/debian/control xen-4.17.3+10-g091466ba55/debian/control
--- xen-4.17.3+10-g091466ba55/debian/control	2024-02-04 13:45:17.0 +0100
+++ xen-4.17.3+10-g091466ba55/debian/control	2024-02-05 23:37:19.0 +0100
@@ -212,16 +212,16 @@
 Section: libdevel
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends},
-	 libxenmisc4.17 (= ${binary:Version}),
-	 libxencall1 (= ${binary:Version}),
-	 libxendevicemodel1 (= ${binary:Version}),
-	 libxenevtchn1 (= ${binary:Version}),
-	 libxenforeignmemory1 (= ${binary:Version}),
-	 libxengnttab1 (= ${binary:Version}),
-	 libxenstore4 (= ${binary:Version}),
-	 libxentoolcore1 (= ${binary:Version}),
-	 libxentoollog1 (= ${binary:Version}),
-	 libxenhypfs1 (= ${binary:Version}),
+	 libxenmisc4.17t64 (= ${binary:Version}),
+	 libxencall1t64 (= ${binary:Version}),
+	 libxendevicemodel1t64 (= ${binary:Version}),
+	 libxenevtchn1t64 (= ${binary:Version}),
+	 libxenforeignmemory1t64 (= ${binary:Version}),
+	 libxengnttab1t64 (= ${binary:Version}),
+	 libxenstore4t64 (= ${binary:Version}),
+	 libxentoolcore1t64 (= ${binary:Version}),
+	 libxentoollog1t64 (= ${binary:Version}),
+	 libxenhypfs1t64 (= ${binary:Version}),
 Description: Public headers and libs for Xen
  This package contains the public headers and static libraries for Xen.
  .
@@ -236,7 +236,10 @@
  Most of the other included libraries are internal, and intended for
  use by the Xen toolstack, rather than directly.
 
-Package: libxenmisc4.17
+Package: libxenmisc4.17t64
+Provides: ${t64:Provides}
+Replaces: libxenmisc4.17
+Breaks: libxenmisc4.17 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -247,7 +250,10 @@
  knowledge of hypervisor-version-specific hypercall ABIs.
 Multi-Arch: same
 
-Package: libxencall1
+Package: libxencall1t64
+Provides: ${t64:Provides}
+Replaces: libxencall1
+Breaks: libxencall1 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -255,7 +261,10 @@
  Shared library for Xen utilities.
 Multi-Arch: same
 
-Package: libxendevicemodel1
+Package: libxendevicemodel1t64
+Provides: ${t64:Provides}
+Replaces: libxendevicemodel1
+Breaks: libxendevicemodel1 (<< ${source:Version})
 Section: libs
 Architecture: amd64 arm64 armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -263,7 +272,10 @@
  Shared library for Xen utilities.
 Multi-Arch: 

Bug#1062048: xen: FTBFS with Python 3.12 as default

[Maximilian Engelhardt]

Control: tags -1 +fixed-upstream

Hi,

this issue has been fixed upstream by
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=40be6307ec005539635e7b8fcef67e989dc441f6

and was backported to the upstream stable-4.17 branch in
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=4000522008711b1329a7cbb24612dfc355f3e46c

We will include the fix in the next upload.

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

Bug#1042102: Also fixed in upstream stable-4.17 branch

[Maximilian Engelhardt]

This commit got also included in the upstream stable-4.17 branch:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=a91b946345b0c0550d0ee28816a15d3fc16abc50

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

Bug#1036601: xenstore-utils: broken symlink /usr/bin/xenstore-control

[Maximilian Engelhardt]

Control: retitle -1 xenstore-utils: broken symlink /usr/bin/xenstore-control

This is a bit more complicated:

Up to bullseye the binaries in the xenstore-utils package were independent of 
the running xen version (as the xenstore interface is more or less supposed to 
be stable).

Starting with bookworm the xenstore-control binary is now linked against 
unstable xen api libraries (libxenguest.so and libxenctrl.so) which are 
included in the libxenmisc4.17 package.
The upstream commit for this change is [1] and the documentation also says 
that the control command interface is not xen version independent.

Because of the additional shared library dependencies our shuffle-binaries 
script [3] kicks in and sets up the xen-utils-wrapper for xenstore-control.

The xen-utils-wrapper is only included in the xen-utils-common package. But 
adding that dependency would not be enough. It would make the /usr/bin/
xenstore-control symlink not broken, but the wrapper would not find the real 
binary, as it is included in the xen-utils-4.17 package at the /usr/lib/
xen-4.17/bin/xenstore-control path.

Installing only xenstore-utils and xen-utils-common in a dom-U gives the 
following output when executing xenstore-control:
$ xenstore-control 
ERROR:  Can't find version 4.17 of xen utils (maybe xen-utils-4.17 was already 
removed before rebooting out of Xen 4.17), bailing out!


Some options I see for fixing this:

[a] make xenstore-utils depend on xen-utils-V
[b] move the /usr/bin/xenstore-control symlink to xen-utils-V
[c] split the xenstore-utils package in a xen version independent and xen 
version dependent package.

Disadvantage from [a] is that xenstore-utils can also be used inside a dom-U 
and would pull lots of unused stuff. [c] seems to be a bit overkill for only 
one binary file, so I currently see [b] as the best option.

So does anybody have any opinion, ideas or something else to say about all 
this? Or any better ideas?


[1] 
https://salsa.debian.org/xen-team/debian-xen/-/commit/7f97193e6aa858df03be501440e0ade8cceb9ec5
[2] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/docs/misc/xenstore.txt#L378
[3] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/shuffle-binaries


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

Bug#975160: NMU still in DELAYED queue

[Maximilian Engelhardt]

Ping to avoid autoremoval. The NMU from Adrian Bunk should hit the archive 
within one day now.

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

Bug#975822: patch attached

[Maximilian Engelhardt]

Control: tags -1 + patch

Attached is a simple patch fixing this issue in my local test build.

Adrian Bunk, you marked this bug as pending, are you planning to upload a 
fixed version or has this been a mix up in bug numbers like in your other mail 
in this bug?

Thanks,
Maxidiff -ur pyramid-jinja2-2.7+dfsg/debian/control new/pyramid-jinja2-2.7+dfsg/debian/control
--- pyramid-jinja2-2.7+dfsg/debian/control	2019-09-15 07:04:51.0 +0200
+++ new/pyramid-jinja2-2.7+dfsg/debian/control	2021-02-03 19:50:23.514196939 +0100
@@ -10,6 +10,7 @@
  python3-jinja2,
  python3-zope.deprecation,
  python3-pyramid,
+ python3-webtest,
 Standards-Version: 3.9.8
 Homepage: https://pypi.python.org/pypi/pyramid_jinja2
 X-Python3-Version: >= 3.2


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

Bug#887733: Should this bug be closed?

[Maximilian Engelhardt]

This bug is still open but has been marked as fixed in the versions currently 
in testing/unstable and stable. It also has been fixed in oldstable-security. 
Should it be closed or is there any reason to still keep it open?

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

Bug#918479: freecad autopkgtest

[Maximilian Engelhardt]

Hi,

I had a quick look at this bug and notices the upstream parameters for 
launching the test command changed in [1]. Maybe it's enough to adjust the 
commands in 'debian/tests/freecadtest' [2] from

  freecadcmd -t 1
  freecadcmd -t 2

to 

  freecadcmd -t 0

However I currently don't have a proper system to test this, so there might be 
other bugs.

Thanks,
Maxi

[1] https://github.com/FreeCAD/FreeCAD/pull/331
[2] 
https://sources.debian.org/src/freecad/0.17+dfsg1-6/debian/tests/freecadtest/

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

Bug#859560: fixed in xen 4.8.1-1

[Maximilian Engelhardt]

On Dienstag, 25. April 2017 00:08:20 CEST Ivar Smolin wrote:
> On Tue, 18 Apr 2017 17:34:15 + Ian Jackson
> 
>  wrote:
> > Source: xen
> > Source-Version: 4.8.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > xen, which is due to be installed in the Debian FTP archive.
> 
> Thanks for fixing!
> 
> This bug affects also Xen 4.4.x, Jessie is still vulnerable.


Hi, what's the status of this in Jessie?

According to https://security-tracker.debian.org/tracker/CVE-2017-7228 Jessie 
is still vulnerable.

Thanks,
Maxi

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

Bug#845798: patch for amarok

[Maximilian Engelhardt]

Hi,

I created a patch for amarok that switches to using mariadb. I don't see how 
the current mysql-defaults system can be used in amarok, as there is no 
default-mysqld-dev package.

$ diff -u debian.orig/amarok-2.8.0/debian/control 
debian/amarok-2.8.0/debian/control
--- debian.orig/amarok-2.8.0/debian/control 2016-12-01 20:16:40.0 
+0100
+++ debian/amarok-2.8.0/debian/control  2016-12-15 20:26:31.791265529 +0100
@@ -11,12 +11,12 @@
  kdelibs5-dev (>= 4:4.8.4),
  libmtp-dev (>= 1.0.0), libqjson-dev,
  libglib2.0-dev, libgpod-nogtk-dev (>= 0.7.0) | libgpod-dev (>= 0.7.0),
- libmysqld-pic (>= 5.5.23+dfsg), libwrap0-dev,
+ libmariadbd-dev, libwrap0-dev,
  libcurl4-gnutls-dev, libxml2-dev, libloudmouth1-dev,
  libgtk2.0-dev, libqca2-dev, liblastfm-dev (>= 1.0.3),
  libavformat-dev (>= 4:0.5), libofa0-dev, libaio-dev [linux-any],
  libgcrypt20-dev
-Build-Depends-Indep: mysql-server-core-5.6 | virtual-mysql-server-core
+Build-Depends-Indep: mariadb-server-core-10.0 | virtual-mysql-server-core
 Standards-Version: 3.9.8
 Homepage: http://amarok.kde.org
 Vcs-Git: https://anonscm.debian.org/git/pkg-kde/kde-extras/amarok.git

I compile tested the patch in pbuilder and tested the resulting .debs on my 
system.

It would be great If this could get reviewed and if acceptable uploaded to 
unstable so we can get an amarok in stretch.

Thanks,
Maxi

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

Bug#775005: [macchanger] MAC randomization doesn't generate a random MAC

[Maximilian Engelhardt]

Package: macchanger
Version: 1.7.0-3.2
Severity: grave

Trying to randomize the MAC address of an interface toggles between two MAC 
addresses instead of setting a random MAC address. See the following example:

$ macchanger -A wlan8
Current MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
$ macchanger -A wlan8
Current MAC:   00:05:01:98:26:05 (CISCO SYSTEMS, INC.)
Permanent MAC: 24:fd:52:XX:XX:XX (Liteon Technology Corporation)
New MAC:   00:05:01:98:56:c3 (CISCO SYSTEMS, INC.)


The problem here seems to be in the random_seed function where macchanger 
tries to open different devices for random numbers and takes the first one 
where open() is successful but never checks if the following read() is 
successful.

http://sources.debian.net/src/macchanger/1.7.0-5/src/main.c/#L92

also see this strace snippet:

open(/dev/hwrng, O_RDONLY)= 3
read(3, 0x7fffe23909ec, 4)  = -1 ENODEV (No such device)
close(3)= 0


I don't know why I do have this non-working /dev/hwrng device. It gets somehow 
automatically created by loading the b43 kernel module.

Macchanger should check if the read() was successful and if not try the next 
entropy device or at least abort with an error instead pretending to set a 
random MAC address which clearly is not random.


Another problem I spotted is that if reading from an entropy device does work 
only sizeof(unsigned int) entropy is read, which is only guaranteed to be 2 
octets. However from these are then up to 6 octets of random data generated 
(in case of a fully random MAC) which clearly does not work as expected.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.18.0-trunk-amd64

Debian Release: 8.0
  500 testing security.debian.org 
  500 testing mirror.stusta.mhn.de 
  500 testing http.debian.net 

--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6(= 2.4) | 
dpkg (= 1.15.4)  | 
 OR install-info  | 


Package's Recommends field is empty.

Package's Suggests field is empty.

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

Bug#741743: [src:kicad] FTBFS on all architectures

[Maximilian Engelhardt]

Source: kicad
Version: 0.20140224+bzr4027-3
Severity: serious

Hello,

kicad currently FTBFS on all architectures.

See here for the build logs:
https://buildd.debian.org/status/package.php?p=kicad

Maxi



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

Bug#306261: #306261 and sarge

[Maximilian Engelhardt]

Hello,

according to bugzilla this bug is fixed in version 2.4.3-20050321+2, but
debian sarge still has version 2.4.3-20050321+1 affected by this bug.
Could you please upload a fixed version to sarge?

Maxi



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