Bug#941296: tuxcmd-modules: reproducible-builds: embedded build paths in various binaries

[Chris Lamb]

tags 1011500 + pending patch
thanks

I've just uploaded an updated version of tuxcmd-modules 0.6.70+ds-5.1
to DELAYED/3. This variant of the upload actually includes the fix for
#941296 which was missed when preparing the upload.
  
  tuxcmd-modules (0.6.70+ds-5.1) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply a patch by Vagrant Cascadian to ensure that tuxcmd-modules does not
  embed build paths in various binaries. (Closes: #1011500)
* Apply a patch by Helmut Grohne to make it possible to cross-build
  tuxcmd-modules. (Closes: #941296)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for tuxcmd-modules-0.6.70+ds tuxcmd-modules-0.6.70+ds

 changelog|   10 +++
 patches/crossbuild.patch |  130 +++
 patches/reproducible-build.patch |   68 
 patches/series   |2 
 4 files changed, 210 insertions(+)

diff -Nru tuxcmd-modules-0.6.70+ds/debian/changelog 
tuxcmd-modules-0.6.70+ds/debian/changelog
--- tuxcmd-modules-0.6.70+ds/debian/changelog   2013-05-10 21:00:35.0 
+0100
+++ tuxcmd-modules-0.6.70+ds/debian/changelog   2022-11-17 17:15:30.0 
+
@@ -1,3 +1,13 @@
+tuxcmd-modules (0.6.70+ds-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch by Vagrant Cascadian to ensure that tuxcmd-modules does not
+embed build paths in various binaries. (Closes: #1011500)
+  * Apply a patch by Helmut Grohne to make it possible to cross-build
+tuxcmd-modules. (Closes: #941296)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:15:30 +
+
 tuxcmd-modules (0.6.70+ds-5) unstable; urgency=low
 
   * QA upload.
diff -Nru tuxcmd-modules-0.6.70+ds/debian/patches/crossbuild.patch 
tuxcmd-modules-0.6.70+ds/debian/patches/crossbuild.patch
--- tuxcmd-modules-0.6.70+ds/debian/patches/crossbuild.patch1970-01-01 
01:00:00.0 +0100
+++ tuxcmd-modules-0.6.70+ds/debian/patches/crossbuild.patch2022-11-17 
17:15:30.0 +
@@ -0,0 +1,130 @@
+--- tuxcmd-modules-0.6.70+ds.orig/gvfs/Makefile
 tuxcmd-modules-0.6.70+ds/gvfs/Makefile
+@@ -5,6 +5,7 @@ INSTALL_DATA = ${INSTALL} -m 644
+ 
+ # compiler options
+ CC = gcc
++PKG_CONFIG ?= pkg-config
+ CFLAGS =-I. -I/usr/include \
+   -Wall -fPIC -O2 -g \
+   -DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_GNU_SOURCE
+@@ -20,13 +21,13 @@ VFS_OBJECTS=gvfs.o
+ 
+ .SUFFIXES: .c
+ .c.o:
+-  $(CC) $(CFLAGS) `pkg-config glib-2.0 gio-2.0 --cflags` -c $<
++  $(CC) $(CFLAGS) `$(PKG_CONFIG) glib-2.0 gio-2.0 --cflags` -c $<
+ 
+ 
+ all shared static: libgvfs_plugin.so
+ 
+ libgvfs_plugin.so: $(VFS_COMMON_OBJECTS) $(VFS_OBJECTS)
+-  $(CC) -shared -o libgvfs_plugin.so $(VFS_COMMON_OBJECTS) $(VFS_OBJECTS) 
$(CFLAGS) `pkg-config glib-2.0 gio-2.0 --libs`
++  $(CC) -shared -o libgvfs_plugin.so $(VFS_COMMON_OBJECTS) $(VFS_OBJECTS) 
$(CFLAGS) `$(PKG_CONFIG) glib-2.0 gio-2.0 --libs`
+ 
+ strutils.o: strutils.c strutils.h
+ treepathutils.o: treepathutils.c treepathutils.h
+--- tuxcmd-modules-0.6.70+ds.orig/libarchive/Makefile
 tuxcmd-modules-0.6.70+ds/libarchive/Makefile
+@@ -7,7 +7,8 @@ DIR_LIBARCHIVE=./libarchive-2.5.5
+ 
+ # compiler options
+ CC = gcc
+-CPP = g++
++CXX = g++
++PKG_CONFIG ?= pkg-config
+ CFLAGS =-I. -I/usr/include -I$(DIR_COMMON) \
+   -Wall -fPIC -O2 -g \
+   -DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_GNU_SOURCE \
+@@ -23,20 +24,20 @@ VFS_OBJECTS=libarchive.o
+ 
+ .SUFFIXES: .c .cpp
+ .c.o:
+-  $(CC) $(CFLAGS) `pkg-config glib-2.0 --cflags` -c $<
++  $(CC) $(CFLAGS) `$(PKG_CONFIG) glib-2.0 --cflags` -c $<
+ .cpp.o:
+-  $(CPP) $(CFLAGS) `pkg-config glib-2.0 --cflags` -c $<
++  $(CXX) $(CFLAGS) `$(PKG_CONFIG) glib-2.0 --cflags` -c $<
+ 
+ 
+ all: static
+ 
+ 
+ shared: $(VFS_COMMON_OBJECTS) $(VFS_OBJECTS)
+-  $(CC) -shared -o libarchive_plugin.so $(VFS_COMMON_OBJECTS) 
$(VFS_OBJECTS) $(CFLAGS) `pkg-config glib-2.0 --libs` -larchive -lz -lbz2
++  $(CC) -shared -o libarchive_plugin.so $(VFS_COMMON_OBJECTS) 
$(VFS_OBJECTS) $(CFLAGS) `$(PKG_CONFIG) glib-2.0 --libs` -larchive -lz -lbz2
+ 
+ static: CFLAGS += -I$(DIR_LIBARCHIVE)/libarchive
+ static: lib_libarchive_compile $(VFS_COMMON_OBJECTS) $(VFS_OBJECTS)
+-  $(CC) -shared -o libarchive_plugin.so $(VFS_COMMON_OBJECTS) 
$(VFS_OBJECTS) $(DIR_LIBARCHIVE)/.libs/libarchive.a $(CFLAGS) `pkg-config 
glib-2.0 --libs` -lz -lbz2
++  $(CC) -shared -o libarchive_plugin.so $(VFS_COMMON_OBJECTS) 
$(VFS_OBJECTS) $(DIR_LIBARCHIVE)/.libs/libarchive.a $(CFLAGS) `$(PKG_CONFIG) 
glib-2.0 --libs` -lz -lbz2
+ 
+ lib_libarchive_compile:
+   @which uudecode > /dev/null || exit 1;
+--- tuxcmd-modules-0.6.70+ds.orig/zip/Makefile
 tuxcmd-modules-0.6.70+ds/zip/Makefile
+@@ -6,7 +6,8 @@ DIR_ZIPARCHIVE = ./ZipArchive/
+ 
+ # compiler options
+ CC = gcc

Bug#1024350: ITP: fapolicyd -- File Access Policy Daemon

[Nobuhiro Iwamatsu]

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

* Package name: fapolicyd
  Version : 1.1.7
  Upstream Author : Steve Grubb 
* URL : https://github.com/linux-application-whitelisting/fapolicyd
* License : GPL-3
  Programming Lang: C
  Description : File Access Policy Daemon

  Fapolicyd is a simple application whitelisting daemon for Linux.

Bug#1019830: codeblocks: Please transition to wxwidgets3.2

[Olly Betts]

On Fri, Nov 18, 2022 at 11:06:07AM +0800, Bo YU wrote:
> On Fri, Nov 18, 2022 at 3:34 AM Olly Betts  wrote:
> > Looking at upstream's SVN history I can see changes for wx3.2
> > compatibility so it looks like they're on top of this.
> >
> > Therefore I'd suggest trying an upstream SVN snapshot rather than
> > wasting energy trying to address issues upstream have likely already
> > been solved.
> 
> Sorry, I forget to update here. I have feedbacked this to upstream:
> https://forums.codeblocks.org/index.php/topic,25076.0.html (reply #10)

Thanks.  Upstream says there:

| I suggest you to pick the current trunk code (r13000), it is not a
| release but it is more stable than 20.03

So they're explicitly saying that r13000 is a better option than what's
currently in testing and unstable.

> Maybe the upstream will release stable version before sid freeze, so we can
> wait some time to see what happens.

The problem with waiting until shortly before the freeze to update a
package to use wxwidgets3.2 is that we get very little time to address
any problems that crop up from the transition, so it's really much
better to update earlier - in this case to r13000.

If upstream make a release before the freeze it should be an easy update
from r13000 to that; if they don't then we release with r13000, which is
better than 20.03 anyway.

Cheers,
Olly

Bug#1023674: astra-toolbox build depends on gcc-10 that should not be in bookworm

[Andreas Beckmann]

Control: tag -1 pending

On Tue, 08 Nov 2022 20:09:24 +0200 Adrian Bunk  wrote:

#1003037 might contain some background information on how to fix this.


Already fixed in git.

Andreas

Bug#984641: ifmail: Status files for non-default domains are created in directories without domain hex number suffix

[Marco d'Itri]

On Mar 06, Björn Wiberg  wrote:

> Perhaps this is something that can be reported upstream?
There has been no upstream in 20 years.
This may be a bug or a configuration mistake, I am not sure.
Also see #256232.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1024349: diffoscope -- Fails its autopkgtests blocking testing migration

[Nilesh Patra]

Package: diffoscope
Version: 226
Severity: serious
X-Debbugs-Cc: la...@debian.org

Hi,

diffocope fails its autopkgtest blocking testing migration both for
itself and r-base[1].

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = < 
/tmp/autopkgtest-lxc.zwiyv6ce/downtmp/autopkgtest_tmp/tests/data/test1.html>
other = < 
/tmp/autopkgtest-lxc.zwiyv6ce/downtmp/autopkgtest_tmp/tests/data/test1.html>
source = None

def compare(self, other, source=None):
difference = super().compare(other, source)

# Show text-only differences as a sub-diff.
try:
text = Difference.from_operation(Htmltotext, self.path, other.path)
if text is not None:
difference.add_details([text])
except RequiredToolNotFound as exc:  # noqa
>   difference.add_comment(exc.get_comment())
E   AttributeError: 'NoneType' object has no attribute 'add_comment'

__class__  = 
difference = None
other  = < 
/tmp/autopkgtest-lxc.zwiyv6ce/downtmp/autopkgtest_tmp/tests/data/test1.html>
self   = < 
/tmp/autopkgtest-lxc.zwiyv6ce/downtmp/autopkgtest_tmp/tests/data/test1.html>
source = None

/usr/lib/python3/dist-packages/diffoscope/comparators/html.py:48: AttributeError
__ test_diff ___


This does not seem to have stemmed from r-base, rather some python thingy 
instead.

[1]: 
https://ci.debian.net/data/autopkgtest/testing/amd64/d/diffoscope/28424728/log.gz


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

Kernel: Linux 6.0.0-3-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 diffoscope depends on:
ii  diffoscope-minimal  225

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.3.1-1
ii  androguard   3.4.0~a1-6
ii  apksigner31.0.2-1
ii  apktool  2.6.1+dfsg.1-2
ii  binutils-multiarch   2.39-8
ii  bzip21.0.8-5+b1
ii  caca-utils   0.99.beta20-3
ii  colord   1.4.6-1
ii  coreboot-utils   4.15~dfsg-2
ii  db-util  5.3.2
ii  default-jdk-headless 2:1.17-73
ii  device-tree-compiler 1.6.1-4
ii  docx2txt 1.4-5
ii  e2fsprogs1.46.6~rc1-1+b1
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:5.1.2-1
ii  fontforge-extras 1:20220308~dfsg-1
ii  fonttools4.37.4-1
ii  fp-utils 3.2.2+dfsg-15
ii  fp-utils-3.2.2 [fp-utils]3.2.2+dfsg-15
ii  genisoimage  9:1.1.11-3.4
ii  gettext  0.21-9
ii  ghc  9.0.2-4
ii  ghostscript  9.56.1~dfsg-1
ii  giflib-tools 5.2.1-2.5
ii  gnumeric 1.12.53-1.1
ii  gnupg2.2.40-1
ii  gnupg-utils  2.2.40-1
ii  hdf5-tools   1.10.8+repack-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4
ii  jsbeautifier 1.14.4-1
ii  libarchive-tools 3.6.0-1
ii  libxmlb-dev  0.3.8-1
ii  llvm 1:14.0-55.2+b1
ii  lz4 [liblz4-tool]1.9.4-1
ii  mono-utils   6.8.0.105+dfsg-3.2
ii  ocaml-nox4.13.1-3
ii  odt2txt  0.5-7
ii  oggvideotools0.9.1-6
ii  openssh-client   1:9.0p1-1+b2
ii  openssl  3.0.7-1
ii  pgpdump  0.34-1
ii  poppler-utils22.08.0-2.1
ii  procyon-decompiler   0.6.0-1
ii  python3-argcomplete  2.0.0-1
ii  python3-binwalk  2.3.3+dfsg1-2
ii  python3-debian   0.1.48
ii  python3-defusedxml   0.7.1-2
ii  python3-guestfs  1:1.48.4-2+b3
ii  python3-jsondiff 1.3.1-2
ii  python3-pdfminer 20220319+dfsg-1
ii  python3-progressbar  2.5-3
ii  python3-pypdf2   2.11.1-1
ii  python3-pyxattr  0.7.2-2+b2
ii  python3-rpm  4.17.1.1+dfsg-1+b1
ii  python3-tlsh 3.4.4+20151206-1.4+b3
ii  r-base-core  4.2.1-3
pn  radare2  
ii  rpm2cpio 4.17.1.1+dfsg-1+b1
ii  sng 

Bug#1024018: python-cleo: CVE-2022-42966

[Emmanuel Arias]

Hi,

thanks for the report.

I made some checks and seems that the issue is in version 1.0.0a*. That 
they are prereleases.


In previous versions the manage of Table was in clickit, perhaps the 
issue is also in clickit?


So, cleo package in Debian doesn't have that issue.

Cheers,

Emmanuel



OpenPGP_0xFA9DEC5DE11C63F1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023861: RFS: libunwind/1.6.2-0.1 [NMU] -- libunwind-based non local goto - runtime

[Bo YU]

Package: sponsorship-requests
Followup-For: Bug #1023861

(Thanks bartm to help me to change the title of the reportbug)

Changelog:

libunwind (1.6.2-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream version 1.6.2 (Closes: #1009052)
   * Set std-ver to 4.6.1
   * Rebase debian/patches

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1019830: codeblocks: Please transition to wxwidgets3.2

[Bo YU]

Hi,

On Fri, Nov 18, 2022 at 3:34 AM Olly Betts  wrote:
>
> On Sun, Oct 30, 2022 at 03:52:13PM +0800, Bo YU wrote:
> > I have tried to build the package with libwxgtk3.2-dev, but
> > unfortunately, it fails:
> [snip]
> > Could you help to have a look?
>
> Looking at upstream's SVN history I can see changes for wx3.2
> compatibility so it looks like they're on top of this.
>
> Therefore I'd suggest trying an upstream SVN snapshot rather than
> wasting energy trying to address issues upstream have likely already
> been solved.

Sorry, I forget to update here. I have feedbacked this to upstream:
https://forums.codeblocks.org/index.php/topic,25076.0.html (reply #10)
Maybe the upstream will release stable version before sid freeze, so we can
wait some time to see what happens.

BR,
Bo
>
> Cheers,
> Olly

Bug#1024205: cloudpickle: FTBFS with py3.11

[Dan Bungert]

https://github.com/cloudpipe/cloudpickle/pull/486/commits/9b332800fa09bec1f03fd4dd10ca69d1655c809c
is also desired, for compatibility with python3.11 3.11.0-3.

-Dan

Bug#1014274: reverse dependencies

[Daniel Gröber]

Hi Petter,

On Tue, Sep 06, 2022 at 10:52:23AM +0200, Petter Reinholdtsen wrote:
> I mean to talk to the reverse dependency maintainers.  

Since qflow and arachne-pnr are science-team maintained and Steffen was
kind enough to grant me DM rights for them I've uploaded fixes for both to
unstable.

> Once the path forward is agreed with the reverse dependency maintainers,
> one of the options might be for them to drop mips64el from their
> packages too (and request the removal of their mips64el packages from
> the archive).

For qflow I've opted for deliberatly making the build fail on unsupported
architectures as we do for yosys now. As for arachne-pnr I've simply
switched an (uneccesarry) Depends: yosys to be a Suggests: yosys instead. I
hope that unblocks this RM request.

Do I need to file a seperate RM request for qflow or can this be handled as
part of this request? In case of the former qflow should be removed on
mipsel64el as well.

Thanks,
--Daniel

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Guillem Jover]

On Thu, 2022-11-17 at 13:52:38 +, Amr Ibrahim wrote:
> On Sat, 24 Sep 2022 21:37:45 +0200 Guillem Jover  wrote:
> > I've kept the package on hold since, but try to upgrade from time to
> > time to see whether its fixed. Last time I did with the latest version
> > currently in sid, it seemed to be still broken.
> 
> Is this still broken in Chromium?

Well, nothing has changed in webext-keepassxc-browser since my last
reply, so I'd assume yes. In any case I just upgraded again to check
and, yes it's still broken.

> There is no problem in Firefox, and this bug report is preventing
> the package to migrate to testing

Sure, but that makes it unusable with Chromium which would be a
disservice to those users, so not migrating seems entirely the right
outcome.

Thanks,
Guillem

Bug#1024348: RFS: analog/2:6.0.17-3 -- web server log analyzer

[Lourisvaldo Figueredo Junior]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "analog":

 * Package name : analog
   Version  : 2:6.0.17-3
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://www.c-amie.co.uk/software/analog
 * License  : public-domain, GD, BSD-4-clause, GPL-2+, PCRE, zlib, 
libpng
 * Vcs  : https://salsa.debian.org/debian/analog
   Section  : web

The source builds the following binary packages:

  analog - web server log analyzer

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/analog/
analog_6.0.17-3.dsc

Changes since the last upload:

 analog (2:6.0.17-3) unstable; urgency=medium
 .
   * debian/analog.lintian-overrides: added to override warning about
 documentation outside /usr/share/doc. The files are not documentation.
   * debian/config: removed old package check, version 2:5.23-3.
   * debian/copyright: fix spelling error.
   * debian/lang/*: added UTF-8 language files, which were converted with iconv
 from the upstream lang directory. Consequently:
   - debian/install: changed to install UTF-8 language files from
 debian/lang directory.
   - debian/README.Debian: added explanation about debian/lang directory.
   * debian/po/de.po: changed to UTF-8 text encoding.
   * debian/po/pt_BR.po: changed to UTF-8 text encoding.
   * debian/po/sv.po: changed to UTF-8 text encoding.
   * debian/watch: updated.

Regards,
-- 
  Lourisvaldo Figueredo Junior

Bug#1013729: [Pkg-rust-maintainers] Bug#1013729: re: rust-zbus: Please upgrade to version 2.2.0

[Zeeshan Ali Khan]

Hi Peter,

On Thu, 17 Nov 2022 at 23:32, Peter Green  wrote:
>
> Zeeshan Ali Khan wrote:
> > zbus creator/maintainer here.
>
> Thanks for weighing in.

Np, thanks for your detailed response.

> > Why annoyingly? Where else should I provide the release notes? I take
> > the time to write proper release notes for each release so I'd
> > appreciate some appreciation for that. :) Most projects these days
> > don't bother at all and if they do, they just copy the git log.
>
> Firstly it's a bit hidden, I suspect most people get their releases
> from crates.io,

Well IMO the best place to publish them would be on crates.io itself
when one does `cargo publish` but unfortunately that's not supported.
So folks do have to click on the repo.

> click on the link to the repository when they want to
> view what is going on with development and don't even realise that
> the releases tab on the gitlab project is being used.

That's to do with Gitlab not being super popular so folks don't know
where to click but once you've seen it, you know where they are.

> Secondly it throws multiple crates and multiple branches in together.

We've a mono repo so there has to be multiple crates, unfortunately. I
don't think we're alone on this one at all though. I don't think it's
very hard to search in there for particular releases.

Not sure what you mean by branches. They're just releases. We only
support the latest release cycle so there aren't really any branches.

> this can mean looking through quite a lot of entries to find the one
> you want.

You may have a point here but I understood you were looking for
entries for particular releases and I don't think that's hard to find.

> When packages bother to maintain a changelog (which sadly most don't)
> the convention in the rust community seems to be a file called
> CHANGELOG.md in the root of the source tree.

Don't you think all the problems you mentioned above about difficulty
searching for particular entries, would apply here as well?

The CHANGELOG.md is typically just a copy of the git log. I
never understood the point of re-adding git log into a file tracked by
git. It does have the advantage of easy discoverability because the
practice is quite common.

FWIW, I have also recently started to include release notes in release
tags annotations.

>  > Indeed. I strongly suggest bumping directly to the latest v3.
>
> If v2 to v3 is a trivial change, then I think it does indeed make
> sense to skip v2.

>From a user (dependent apps/crates) perspective, it's quite trivial.
Internally, it was a big effort (not as big as v2 though). Only reason
to bump the major version was some API breakage that could affect some
folks.

> That still leaves the question of what to do about v1 to v2.

I'd just ignore v2. If you port to v2, most likely porting to v3 would
be trivial.

> My
> experience trying to port libslirp was that it was not a trivial
> task. I didn't try to port squeekboard, so maybe it was something
> weird about how libslirp uses the crate.

I'm not familiar with libslirp. v2 is a big change since we almost
re-wrote the core and the API is now primarily async.

> I went through serveral pages of releases and found the release
> notes for version 2.0 but they didn't really enlighten me.

If I had the time, I would have provided a porting guide. :( I think
the main way to get into the API is the book. Comparing it to the v1,
is as close as to a porting guide you can get I guess:

https://dbus.pages.freedesktop.org/zbus/
https://dbus.pages.freedesktop.org/zbus/1.0/

>  > or if there's anything I can do to help.
>
> What would be helpful is persuading/helping upstreams of projects
> that use zbus and are currently in Debian to move to the latest
> version of zbus. Mainly libslirp and squeekboard.

Right, I can give it a shot but an important point to keep in mind
here is that this can easily become a chicken issue. E.g I've been
actively pushing for an upgrade to zbus 3 in the netavark project but
they can't merge until zbus3 is packaged for Ubuntu. Incidentally,
that's how I end up here:
https://github.com/containers/netavark/pull/412

So keeping that in mind and also the fact that v2 and v3 are a
completely different thing than v1, perhaps v3 could be packaged
separately?




--
Regards,

Zeeshan Ali Khan

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[John David Anglin]

Hi Stefano,

On 2022-11-17 3:37 p.m., Stefano Rivera wrote:

Hi John (2022.11.16_21:17:59_+)

Generally speaking python-cffi test failures point to libffi bugs. So,
I'd start by trying to verify the behaviour of the underlying behaviour
in libffi, from C.

If the python-cffi test checks the passing of structs larger than 8 bytes, then 
maybe there is a problem:
https://github.com/libffi/libffi/issues/749

The hppa libffi code passes these by value.

This seems to have changed in this commit:
commit e4c5d46b0abaa8a12e97f0e0673e3efdda59fab8
Author: Anthony Green 
Date:   Mon Sep 5 12:19:57 2022 -0400

    Pass large structs by value

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:

Salvatore> We were originally thinking so (and Moritz added krb5 to
Salvatore> the DSA needed list), as at least for 32bit architectures
Salvatore> it might be possible to go beyond denial of service and
Salvatore> potentially leading to remote code execution. But if your
Salvatore> assesment on the issue makes you confident it's not DSA
Salvatore> worthy we can re-evaluate.

So, looking at the code and the upstream advisory, it looks like the
information exposure vulnerability with cross-realm trust applies to
64-bit arches too.

Anyway I've fixed for unstable.
I  have a proposed fix for bullseye on the bullseye branch of
https://salsa.debian.org/debian/krb5.
Can you take a look and see if I did that right?  Do you want me to
upload that, or would you rather upload to the security queue?


signature.asc
Description: PGP signature

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:
Salvatore> Thanks for sharing the analysis. Can you prepare debdiff
Salvatore> for bullseye-security accordingly, so we can release an
Salvatore> update via a DSA?

diff --git a/debian/changelog b/debian/changelog
index d6eaa38262..60fb20b347 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.18.3-6+deb11u3) bullseye-security; urgency=high
+
+  * Integer overflows in PAC parsing; potentially critical for 32-bit
+KDCs or when cross-realm acts maliciously; DOS in other conditions;
+CVE-2022-42898, Closes: #1024267
+
+ -- Sam Hartman   Thu, 17 Nov 2022 12:41:46 -0700
+
 krb5 (1.18.3-6+deb11u2) bullseye; urgency=medium
 
   * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
diff --git a/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch 
b/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch
new file mode 100644
index 00..04dbfd4788
--- /dev/null
+++ b/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch
@@ -0,0 +1,104 @@
+From: Greg Hudson 
+Date: Mon, 17 Oct 2022 20:25:11 -0400
+Subject: Fix integer overflows in PAC parsing
+
+In krb5_parse_pac(), check for buffer counts large enough to threaten
+integer overflow in the header length and memory length calculations.
+Avoid potential integer overflows when checking the length of each
+buffer.  Credit to OSS-Fuzz for discovering one of the issues.
+
+CVE-2022-42898:
+
+In MIT krb5 releases 1.8 and later, an authenticated attacker may be
+able to cause a KDC or kadmind process to crash by reading beyond the
+bounds of allocated memory, creating a denial of service.  A
+privileged attacker may similarly be able to cause a Kerberos or GSS
+application service to crash.  On 32-bit platforms, an attacker can
+also cause insufficient memory to be allocated for the result,
+potentially leading to remote code execution in a KDC, kadmind, or GSS
+or Kerberos application server process.  An attacker with the
+privileges of a cross-realm KDC may be able to extract secrets from a
+KDC process's memory by having them copied into the PAC of a new
+ticket.
+
+(cherry picked from commit ea92d2f0fcceb54a70910fa32e9a0d7a5afc3583)
+
+ticket: 9074
+version_fixed: 1.20.1
+
+(cherry picked from commit b99de751dd35360c0fccac74a40f4a60dbf1ceea)
+---
+ src/lib/krb5/krb/pac.c   |  9 +++--
+ src/lib/krb5/krb/t_pac.c | 18 ++
+ 2 files changed, 25 insertions(+), 2 deletions(-)
+
+diff --git a/src/lib/krb5/krb/pac.c b/src/lib/krb5/krb/pac.c
+index 950beda..1b9ef12 100644
+--- a/src/lib/krb5/krb/pac.c
 b/src/lib/krb5/krb/pac.c
+@@ -27,6 +27,8 @@
+ #include "k5-int.h"
+ #include "authdata.h"
+ 
++#define MAX_BUFFERS 4096
++
+ /* draft-brezak-win2k-krb-authz-00 */
+ 
+ /*
+@@ -316,6 +318,9 @@ krb5_pac_parse(krb5_context context,
+ if (version != 0)
+ return EINVAL;
+ 
++if (cbuffers < 1 || cbuffers > MAX_BUFFERS)
++return ERANGE;
++
+ header_len = PACTYPE_LENGTH + (cbuffers * PAC_INFO_BUFFER_LENGTH);
+ if (len < header_len)
+ return ERANGE;
+@@ -348,8 +353,8 @@ krb5_pac_parse(krb5_context context,
+ krb5_pac_free(context, pac);
+ return EINVAL;
+ }
+-if (buffer->Offset < header_len ||
+-buffer->Offset + buffer->cbBufferSize > len) {
++if (buffer->Offset < header_len || buffer->Offset > len ||
++buffer->cbBufferSize > len - buffer->Offset) {
+ krb5_pac_free(context, pac);
+ return ERANGE;
+ }
+diff --git a/src/lib/krb5/krb/t_pac.c b/src/lib/krb5/krb/t_pac.c
+index ee47152..ccd1653 100644
+--- a/src/lib/krb5/krb/t_pac.c
 b/src/lib/krb5/krb/t_pac.c
+@@ -431,6 +431,16 @@ static const unsigned char s4u_pac_ent_xrealm[] = {
+ 0x8a, 0x81, 0x9c, 0x9c, 0x00, 0x00, 0x00, 0x00
+ };
+ 
++static const unsigned char fuzz1[] = {
++0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00,
++0x06, 0xff, 0xff, 0xff, 0x00, 0x00, 0xf5
++};
++
++static const unsigned char fuzz2[] = {
++0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00,
++0x20, 0x20
++};
++
+ static const char *s4u_principal = "w2...@acme.com";
+ static const char *s4u_enterprise = "w2k8u@a...@acme.com";
+ 
+@@ -646,6 +656,14 @@ main(int argc, char **argv)
+ krb5_free_principal(context, sep);
+ }
+ 
++/* Check problematic PACs found by fuzzing. */
++ret = krb5_pac_parse(context, fuzz1, sizeof(fuzz1), );
++if (!ret)
++err(context, ret, "krb5_pac_parse should have failed");
++ret = krb5_pac_parse(context, fuzz2, sizeof(fuzz2), );
++if (!ret)
++err(context, ret, "krb5_pac_parse should have failed");
++
+ /*
+  * Test empty free
+  */
diff --git a/debian/patches/series b/debian/patches/series
index c02427759f..a62749cd49 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -11,3 +11,4 @@ debian-local/0008-Use-isystem-for-include-paths.patch
 

Bug#1021374: zephyr: reproducible-builds patches

[Sam Hartman]

> "Vagrant" == Vagrant Cascadian  writes:

Vagrant> Would you be amenable to an NMU to unstable applying the
Vagrant> following patches and fixing these issues? If yes, should I
Vagrant> build upon the package in experimental? Plans for using
Vagrant> salsa.debian.org? dgit?

I'd definitely be open to an nmu.
I'd recommend building on unstable and just uploading a source package.
Zephyr used to be maintained in subversion.  The maintainer died, and
discussions about how to convert to git kind of stalled out, which is
why the package is such a mess.


signature.asc
Description: PGP signature

Bug#897975: [gdm3]

[Alban Browaeys]

The wayland issue should be gone in bookworm/sid.
As stated in https://gitlab.gnome.org/GNOME/gdm/-/issues/103,
https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/128 is merged (in
gdm 40).
It supersedes https://gitlab.gnome.org/GNOME/gdm/merge_requests/37

I cannot tell about the initial gdm3 "ICELockAuthFile fail: Already
exists" Xorg related issue. It seems unrelated.

Cheers,

Alban

Bug#897975: [gdm3]

[Alban Browaeys]

The wayland issue should be gone in bookworm/sid.
As stated in https://gitlab.gnome.org/GNOME/gdm/-/issues/103,
https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/128 is merged (in
gdm 40).
It supersedes https://gitlab.gnome.org/GNOME/gdm/merge_requests/37

I cannot tell about the initial gdm3 "ICELockAuthFile fail: Already
exists" Xorg related issue. It seems unrelated.

Cheers,

Alban

Bug#1020180: bug 1020180 is forwarded to https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3

[Adrian Bunk]

On Thu, Nov 17, 2022 at 05:23:16PM -0500, Nicholas D Steeves wrote:
> Adrian Bunk  writes:
> 
> > forwarded 1020180 
> > https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3
> > thanks
> 
> Thank you for setting this metadata, and for finding the specific commit
> :)
> 
> I've leaning towards packaging a git snapshot, and then encouraging
> upstream to make a release if it seems release-candidate-like, because
> then our source will be closer to upstream.  Of course, ideally we'll
> have a tagged release in bookworm, Also, upstream hasn't made a release
> in over 18 months, and abo-abo, the primary developer hasn't been heard
> from in something like a year,

https://github.com/abo-abo/swiper/commit/e32289080957e4f6ee48dcb879c437eea62a1133
 ivy.el (ivy-occur-flush-lines): Add
master 
abo-abo committed Sep 10, 2022

> so I think upstream may appreciate the vote of confidence!

Upstream might not appreciate people complaining for years about a buggy
git snapshot of the software in a stable Debian release.

> What do you think?

I cannot give an informed opinion on that for a software I do not use,
maintained by an upstream I do not know.

Are there other fixes relevant for Emacs 28 in upstream git?
What quality are releases of this software usually?
What quality are git snapshots of this software usually?

> Kind regards,
> Nicholas

cu
Adrian

Bug#1013729: [Pkg-rust-maintainers] Bug#1013729: re: rust-zbus: Please upgrade to version 2.2.0

[Peter Green]

Zeeshan Ali Khan wrote:

zbus creator/maintainer here.


Thanks for weighing in.


Why annoyingly? Where else should I provide the release notes? I take
the time to write proper release notes for each release so I'd
appreciate some appreciation for that. :) Most projects these days
don't bother at all and if they do, they just copy the git log.


Firstly it's a bit hidden, I suspect most people get their releases
from crates.io, click on the link to the repository when they want to
view what is going on with development and don't even realise that
the releases tab on the gitlab project is being used.

Secondly it throws multiple crates and multiple branches in together.
this can mean looking through quite a lot of entries to find the one
you want.

When packages bother to maintain a changelog (which sadly most don't)
the convention in the rust community seems to be a file called
CHANGELOG.md in the root of the source tree.


> Indeed. I strongly suggest bumping directly to the latest v3.

If v2 to v3 is a trivial change, then I think it does indeed make
sense to skip v2.

That still leaves the question of what to do about v1 to v2. My
experience trying to port libslirp was that it was not a trivial
task. I didn't try to port squeekboard, so maybe it was something
weird about how libslirp uses the crate.

I went through serveral pages of releases and found the release
notes for version 2.0 but they didn't really enlighten me.

> or if there's anything I can do to help.

What would be helpful is persuading/helping upstreams of projects
that use zbus and are currently in Debian to move to the latest
version of zbus. Mainly libslirp and squeekboard.

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

On Thursday, November 17, 2022 3:18:17 PM MST Mattia Rizzolo wrote:> 
> What I do want to see *before* we actually release a lo-dicts with these
> is something that actually reads and make use of them *first*.

Privacy Browser PC uses them.

https://www.stoutner.com/privacy-browser-pc/[1]

I would like to package up an alpha release of Privacy Browser PC.  One of the 
things I am 
waiting on is getting spell checking working correctly.  Part of this is the 
Privacy Browser 
needs to be able to enumerate the installed dictionaries so that users can 
select between 
them.  How it does this depends on where the dictionaries are placed and 
requires that the 
Qt packages have the correct symlinks.  So, I considered having these 
dictionaries 
packaged and in Debian was an important first step.

Originally I planned to have Privacy Browser packaged by the end of the year, 
but at the 
current pace it looks like it is going to take longer than I expected to get 
all the 
prerequisites in place (this being one of them) so I am now looking for an 
early 2023 
release (hopefully before the freeze).

> > At this point, the only question left is where this should be documented
> > and who should write the documentation.  I am assuming that
> > /usr/share/doc/ dictionaries-common-dev/dsdt-policy.html is the correct
> > place for
> > documentation.  I am willing to submit a PR if nobody else prefers to do
> > so
> > instead.
> 
> mh, what documentation are you talking about??

The documentation for any packager of future Hunspell languages so that they 
know that 
they need to include compiled .bdic files, where they should be placed, and how 
to do it.

-- 
Soren Stoutner
so...@stoutner.com


[1] https://www.stoutner.com/privacy-browser-pc/


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

Bug#1024345: kmscon should register a blacklist with needrestart

[Victor Westerhuis]

On 17/11/2022 22:20, Paul Saunders wrote:

Package: kmscon
Version: 9.0.0-2+b1
Severity: wishlist

Dear Maintainer,

needrestart contains blacklist configuration so that it doesn't attempt
to restart services which manage user logins (such as display managers
and gettys). kmscon should 'register' with needrestart when installed
(i.e. create a file in /etc/needrestart/conf.d/) to protect itself in a
similar manner.

You are absolutely right. I added a blacklist entry to needrestart on my 
own installation ages ago, I just never thought about adding it to the 
package. I'll try to fix this soon.

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

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

Versions of packages kmscon depends on:
ii  libc6  2.36-4
ii  libdrm22.4.114-1
ii  libegl11.5.0-1
ii  libgbm122.2.0-1
ii  libgles2   1.5.0-1
ii  libglib2.0-0   2.74.1-2
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpixman-1-0  0.42.2-1
ii  libsystemd0252.1-1
ii  libtsm44.0.2-0.3
ii  libudev1   252.1-1
ii  libxkbcommon0  1.4.1-1

kmscon recommends no packages.

kmscon suggests no packages.

-- no debconf information


--
Victor Westerhuis 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#834050: libpam-ldap: please make the build reproducible

[Vagrant Cascadian]

On 2022-11-17, Lucas Castro wrote:
> Thanks. = )

Well hi there!

Would you mind me re-uploading without delay or a reduced delay?

live well,
  vagrant

> Em 17/11/2022 16:48, Vagrant Cascadian escreveu:
>> Control: tags 834050 pending
>>
>> On 2017-02-15, Chris Lamb wrote:
>>> Lucas Castro wrote:
>>>
 I suppose the patch hadn't fixed the bug.
>>> Ah, try:
>>>
>>>--- libpam-ldap-186.orig/vers_string
>>>+++ libpam-ldap-186/vers_string
>>>@@ -14,6 +14,10 @@ if ($ENV{'PROGRAM'}) { $PROGRAM = $ENV{'
>>>   
>>> chop($AUTHOR);
>>> chop($DATE=`date -u`);
>>>+if (defined $ENV{SOURCE_DATE_EPOCH}) {
>>>+chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
>>>+$AUTHOR="NO DEVELOPER SET";
>>>+}
>>> chop($CWD=`pwd`);
>>>   
>>> ($PROJECT, $VERSION) = split(/\-/, ());
>> This solved both the timestamp and build user issue!
>>
>> There was another issue where the package and version information is
>> derived from the top-level build directory, but this can be fixed easily
>> by passing PROGRAM to dh_auto_build.
>>
>> Uploaded an NMU to DELAYED/10 which fixes both outstanding issues:
>>
>> diff -Nru libpam-ldap-186/debian/changelog libpam-ldap-186/debian/changelog
>> --- libpam-ldap-186/debian/changelog 2017-05-31 10:19:41.0 -0700
>> +++ libpam-ldap-186/debian/changelog 2022-11-17 11:42:13.0 -0800
>> @@ -1,3 +1,17 @@
>> +libpam-ldap (186-4.1) unstable; urgency=medium
>> +
>> +  * Non-maintainer upload.
>> +
>> +  [ Chris Lamb ]
>> +  * vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is
>> +set. (Closes: #834050)
>> +
>> +  [ Vagrant Cascadian ]
>> +  * debian/rules: Pass PROGRAM to dh_auto_build override.
>> +(Closes: #834050)
>> +
>> + -- Vagrant Cascadian   Thu, 17 Nov 2022 
>> 11:42:13 -0800
>> +
>>   libpam-ldap (186-4) unstable; urgency=medium
>>   
>> * Install /usr/share/pam-configs/ldap
>> diff -Nru libpam-ldap-186/debian/patches/series 
>> libpam-ldap-186/debian/patches/series
>> --- libpam-ldap-186/debian/patches/series2017-02-10 20:39:24.0 
>> -0800
>> +++ libpam-ldap-186/debian/patches/series2022-11-17 11:42:13.0 
>> -0800
>> @@ -6,3 +6,4 @@
>>   reproducible_build.patch
>>   configfile_install.patch
>>   configfile_references.patch
>> +vers_string-use-fixed-value-for-author-i.patch
>> diff -Nru 
>> libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
>>  
>> libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
>> --- 
>> libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
>> 1969-12-31 16:00:00.0 -0800
>> +++ 
>> libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
>> 2022-11-17 11:42:13.0 -0800
>> @@ -0,0 +1,21 @@
>> +From: Chris Lamb 
>> +Date: Wed, 15 Feb 2017 17:12:58 +1300
>> +X-Dgit-Generated: 186-4.1 98efdb0f8a716ed9c1403523c90f3b0b6ff8c493
>> +Subject: vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is 
>> set.
>> +
>> +(Closes: #834050)
>> +
>> +---
>> +
>> +diff --git a/vers_string b/vers_string
>> +index 11af68a..5a072f3 100755
>> +--- a/vers_string
>>  b/vers_string
>> +@@ -16,6 +16,7 @@ chop($AUTHOR);
>> + chop($DATE=`date -u`);
>> + if (defined $ENV{SOURCE_DATE_EPOCH}) {
>> +chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
>> ++   $AUTHOR="NO DEVELOPER SET";
>> + }
>> + chop($CWD=`pwd`);
>> +
>> diff -Nru libpam-ldap-186/debian/rules libpam-ldap-186/debian/rules
>> --- libpam-ldap-186/debian/rules 2017-05-31 10:19:28.0 -0700
>> +++ libpam-ldap-186/debian/rules 2022-11-17 11:42:13.0 -0800
>> @@ -4,6 +4,8 @@
>>   
>>   export DEB_BUILD_MAINT_OPTIONS= hardening=+bindnow
>>   
>> +include /usr/share/dpkg/pkg-info.mk
>> +
>>   %:
>>  dh $@ --with autoreconf
>>   
>> @@ -17,3 +19,6 @@
>>  dh_install
>>  install -D -m 644 debian/libpam-ldap.pam-auth-update \
>>  debian/libpam-ldap/usr/share/pam-configs/ldap
>> +
>> +override_dh_auto_build:
>> +dh_auto_build -- PROGRAM=$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
>>
>>
>>
>> live well,
>>vagrant


signature.asc
Description: PGP signature

Bug#1020180: bug 1020180 is forwarded to https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3

[Nicholas D Steeves]

Adrian Bunk  writes:

> forwarded 1020180 
> https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3
> thanks

Thank you for setting this metadata, and for finding the specific commit
:)

I've leaning towards packaging a git snapshot, and then encouraging
upstream to make a release if it seems release-candidate-like, because
then our source will be closer to upstream.  Of course, ideally we'll
have a tagged release in bookworm, Also, upstream hasn't made a release
in over 18 months, and abo-abo, the primary developer hasn't been heard
from in something like a year, so I think upstream may appreciate the
vote of confidence!

What do you think?

Kind regards,
Nicholas

Bug#1024347: jo: Please update package to 1.9

[Cord Beermann]

Package: jo
Version: 1.4-1
Severity: wishlist

Hi,

theres a new release at https://github.com/jpmens/jo/releases/tag/1.9

Cord

Bug#831587: NMU for reproducible builds and cross building fixes

[Vagrant Cascadian]

Control: tags 831587 pending
Control: tags 986653 pending

Uploaded an NMU to DELAYED/10 fixing these reproducible builds and
cross-building issues:

diff -Nru stressapptest-1.0.6/debian/changelog 
stressapptest-1.0.6/debian/changelog
--- stressapptest-1.0.6/debian/changelog2022-09-04 14:42:31.0 
-0700
+++ stressapptest-1.0.6/debian/changelog2022-11-17 14:06:40.0 
-0800
@@ -1,3 +1,15 @@
+stressapptest (1.0.6-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Bernhard M. Wiedemann ]
+  * Allow to override build date with SOURCE_DATE_EPOCH (Closes: #831587)
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS. (Closes: #986653)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 14:06:40 -0800
+
 stressapptest (1.0.6-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru 
stressapptest-1.0.6/debian/patches/allow-to-override-build-date-with-source.patch
 
stressapptest-1.0.6/debian/patches/allow-to-override-build-date-with-source.patch
--- 
stressapptest-1.0.6/debian/patches/allow-to-override-build-date-with-source.patch
   1969-12-31 16:00:00.0 -0800
+++ 
stressapptest-1.0.6/debian/patches/allow-to-override-build-date-with-source.patch
   2022-11-17 14:06:40.0 -0800
@@ -0,0 +1,36 @@
+From: Bernhard M. Wiedemann 
+Date: Sun, 9 Sep 2018 05:34:37 +0200
+X-Dgit-Generated: 1.0.6-2.2 5763ff92141056c712e2f63a5c1363090e2581aa
+Subject: Allow to override build date with SOURCE_DATE_EPOCH
+
+(Closes: #831587)
+
+in order to make builds reproducible.
+See https://reproducible-builds.org/ for why this is good
+and https://reproducible-builds.org/specs/source-date-epoch/
+for the definition of this variable.
+This date call works with all variants of date (GNU,BSD,Solaris).
+
+Also do not capture build user+host in this case
+to allow to get the same build results anywhere and anytime.
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 603ba73..818d357 100644
+--- a/configure.ac
 b/configure.ac
+@@ -99,6 +99,13 @@ timestamp=$(date)
+ AC_MSG_CHECKING([current timestamp])
+ AC_MSG_RESULT([$timestamp])
+ 
++if test -n "$SOURCE_DATE_EPOCH"
++then
++  timestamp=$(date -u -d "@$SOURCE_DATE_EPOCH" 2>/dev/null || date -u -r 
"$SOURCE_DATE_EPOCH" 2>/dev/null || date -u)
++  username=reproducible
++  hostname=reproducible
++fi
++
+ AC_DEFINE_UNQUOTED([STRESSAPPTEST_TIMESTAMP],
+"$username @ $hostname on $timestamp",
+[Timestamp when ./configure was executed])
diff -Nru stressapptest-1.0.6/debian/patches/fix-ftcbfs.-closes-986653.patch 
stressapptest-1.0.6/debian/patches/fix-ftcbfs.-closes-986653.patch
--- stressapptest-1.0.6/debian/patches/fix-ftcbfs.-closes-986653.patch  
1969-12-31 16:00:00.0 -0800
+++ stressapptest-1.0.6/debian/patches/fix-ftcbfs.-closes-986653.patch  
2022-11-17 14:06:40.0 -0800
@@ -0,0 +1,41 @@
+From: Helmut Grohne 
+Date: Thu, 8 Apr 2021 20:38:30 +0200
+X-Dgit-Generated: 1.0.6-2.2 3b999e567fe8d9786f08825a389114ddf6e6cf15
+Subject: Fix FTCBFS. (Closes: #986653)
+
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 818d357..82de856 100644
+--- a/configure.ac
 b/configure.ac
+@@ -127,26 +127,9 @@ AC_SEARCH_LIBS([io_setup], [aio])
+ AC_CHECK_HEADERS([sys/shm.h])
+ AC_SEARCH_LIBS([shm_open], [rt])
+ 
+-AC_MSG_CHECKING(for pthread_barrier)
+-AC_CACHE_VAL(
+-  ac_cv_func_pthread_barrier,
+-  AC_TRY_RUN(
+-[
+-  #include 
+-  int main(void)
+-  {
+-pthread_barrier_t t;
+-return 0;
+-  }
+-],
+-ac_cv_func_pthread_barrier=yes,
+-ac_cv_func_pthread_barrier=no
+-  )
+-)
+-AC_MSG_RESULT($ac_cv_func_pthread_barrier)
+-if test "$ac_cv_func_pthread_barrier" = "yes"; then
++AC_CHECK_TYPE([pthread_barrier_t],[
+   AC_DEFINE(HAVE_PTHREAD_BARRIER, [1], [Define to 1 if the system has 
`pthread_barrier'.])
+-fi
++],[],[#include ])
+ 
+ # Checks for typedefs, structures, and compiler characteristics.
+ AC_HEADER_STDBOOL
diff -Nru stressapptest-1.0.6/debian/patches/series 
stressapptest-1.0.6/debian/patches/series
--- stressapptest-1.0.6/debian/patches/series   2022-09-04 14:42:31.0 
-0700
+++ stressapptest-1.0.6/debian/patches/series   2022-11-17 14:06:40.0 
-0800
@@ -2,3 +2,5 @@
 support_i486_builds
 support_i586_builds
 gcc-12
+allow-to-override-build-date-with-source.patch
+fix-ftcbfs.-closes-986653.patch


The reproducible builds patch was pulled from upstream git, which was
similar to the patch originally submitted.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Mattia Rizzolo]

On Thu, Nov 17, 2022 at 02:25:17PM -0700, Soren Stoutner wrote:
> Based on the lack of opposition, it seems that the following is the consensus 
> for packaging .bdic files.

thanks for driving this silent resolution ahah :D

> 1.  The .bdic files should be compiled at package creation time.
> 2.  The .bdic files should be included in the existing Hunspell language 
> binary 
> packages.

well, I can confirm these 2 points match my preference, so…

> 3.  The .bdic files should be installed in /usr/share/hunspell-bdic.

… and I don't really have an opinion here.

What I do want to see *before* we actually release a lo-dicts with these
is something that actually reads and make use of them *first*.

> At this point, the only question left is where this should be documented and 
> who should write the documentation.  I am assuming that /usr/share/doc/
> dictionaries-common-dev/dsdt-policy.html is the correct place for 
> documentation.  I am willing to submit a PR if nobody else prefers to do so 
> instead.

mh, what documentation are you talking about??

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1024065: info: infinite(?) loop with LC_ALL=C

[Hilmar Preuße]

Control: tags -1 + pending patch

Am 14.11.2022 um 11:44 teilte Jakub Wilk mit:

Hi,


This seems to hang forever:

   $ LC_ALL=C info python3.10 -n 'Other Language Changes<3>'


Upstream has provided a patch (which solved the issue for me), new
packages for amd64 are here [1]. If you need build for other arch for
testing please build the package for it.

Hilmar

[1] https://freeshell.de/~hille42/texinfo/
--
sigfault

Bug#1024135: [Pkg-rust-maintainers] Bug#1024135: rust-sysinfo: please upgrade to 0.24

[Peter Green]

Please upgrade to newer upstream release 0.24, needed by projects I am
preparing for Debian.


Taking a quick look at the reverse dependencies i'm thinking it likely
makes more sense to go straight to 0.26, does that version work for you?

Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090

[Rob Klingsten]

Package: cdrom
Severity: important
Tags: d-i

Dear Maintainer,

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

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

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

Downloaded debian-11.5.0-amd64-netinst.iso, verified SHA512 signature and 
flashed to USB stick (dd if= of=/dev/sdb). The
Dell Optiplex 5090 is a UEFI-only system. In the BIOS, I previously disabled 
TPM, Secure Boot and Absolute (computer Lojack).

Booting from the netinst USB stick, the computer boots into the Grub CLI. 'ls' 
shows the following:

(proc) (hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0) (cd0,msdos2)

There does not appear to be any usable partition detected on the USB stick that 
contains a kernel. The contents of (cd0,msdos2) are
just an 'efi' directory.

I have tried multiple USB sticks, downloaded the ISO several times all with a 
good SHA512, tried dd and also cp  /dev/sdb, makes
no difference. I've tried the live Gnome image as well, same problem.

I expect the computer to boot properly into the Debian installer.

Bug#1024345: kmscon should register a blacklist with needrestart

[Paul Saunders]

Package: kmscon
Version: 9.0.0-2+b1
Severity: wishlist

Dear Maintainer,

needrestart contains blacklist configuration so that it doesn't attempt
to restart services which manage user logins (such as display managers
and gettys). kmscon should 'register' with needrestart when installed
(i.e. create a file in /etc/needrestart/conf.d/) to protect itself in a
similar manner.

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

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

Versions of packages kmscon depends on:
ii  libc6  2.36-4
ii  libdrm22.4.114-1
ii  libegl11.5.0-1
ii  libgbm122.2.0-1
ii  libgles2   1.5.0-1
ii  libglib2.0-0   2.74.1-2
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpixman-1-0  0.42.2-1
ii  libsystemd0252.1-1
ii  libtsm44.0.2-0.3
ii  libudev1   252.1-1
ii  libxkbcommon0  1.4.1-1

kmscon recommends no packages.

kmscon suggests no packages.

-- no debconf information

Bug#1024057: slapd: service restart does not always restart slapd

[Alister Winfield]

Last time I had this slapd was waiting until all clients disconnect.. Perhaps 
that still happens.

> On 17 Nov 2022, at 20:09, Mike Gabriel  
> wrote:
> 
> Hi Ryan,
> 
>> On  Mi 16 Nov 2022 18:42:49 CET, Ryan Tandy wrote:
>> 
>> Hi Mike,
>> 
>> Sorry, I should have been more explicit. What I'm really looking for is 
>> journal output (journalctl -u slapd.service) or equivalent from the actual 
>> restart event. Specifically anything showing why slapd fails to restart, or 
>> any errors are emitted during the attempted restart.
>> 
>> thanks,
>> Ryan
> 
> Unfortunately, the problem does not occur always and my journalctl -u 
> slapd.service only lasts an hour into the past (???, I use Debian's defaults 
> here, ???).
> 
> I just tried to reproduce the issue manually, but failed (restarts worked).
> 
> I will update this bug report if I will be able to reproduce the issue and 
> get a fresh log from journalctl. (However, we have work-around in place now 
> and maybe won't see the issue again).
> 
> Greets,
> Mike
> 
> -- 
> 
> DAS-NETZWERKTEAM
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
> 
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
> 
> ___
> Pkg-openldap-devel mailing list
> pkg-openldap-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-openldap-devel

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

Based on the lack of opposition, it seems that the following is the consensus 
for packaging .bdic files.

1.  The .bdic files should be compiled at package creation time.
2.  The .bdic files should be included in the existing Hunspell language binary 
packages.
3.  The .bdic files should be installed in /usr/share/hunspell-bdic.

At this point, the only question left is where this should be documented and 
who should write the documentation.  I am assuming that /usr/share/doc/
dictionaries-common-dev/dsdt-policy.html is the correct place for 
documentation.  I am willing to submit a PR if nobody else prefers to do so 
instead.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#835259: quvi: please make the build reproducible

[Vagrant Cascadian]

Control: tags 835259 pending

On 2016-08-23, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], I noticed
> that quvi could not be built reproducibly.

I have pushed the fix to git:

  
https://salsa.debian.org/debian/quvi/-/commit/ee4df0abd727be942ff593c68de110bc6c6e504e

And also pushed the changes to git and uploaded an NMU fixing this issue
to DELAYED/10:

diff -Nru quvi-0.9.5/debian/changelog quvi-0.9.5/debian/changelog
--- quvi-0.9.5/debian/changelog 2022-08-25 07:53:26.0 -0700
+++ quvi-0.9.5/debian/changelog 2022-11-17 13:01:22.0 -0800
@@ -1,3 +1,12 @@
+quvi (0.9.5-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Make the build reproducible. (Closes: #835259)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 13:01:22 -0800
+
 quvi (0.9.5-0.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru quvi-0.9.5/debian/patches/reproducible-build.patch 
quvi-0.9.5/debian/patches/reproducible-build.patch
--- quvi-0.9.5/debian/patches/reproducible-build.patch  1969-12-31 
16:00:00.0 -0800
+++ quvi-0.9.5/debian/patches/reproducible-build.patch  2022-11-17 
12:59:49.0 -0800
@@ -0,0 +1,21 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-23
+
+--- quvi-0.9.4.orig/configure.ac
 quvi-0.9.4/configure.ac
+@@ -47,7 +47,13 @@ AC_DEFINE_UNQUOTED([CFLAGS], "$CFLAGS",
+ AC_DEFINE_UNQUOTED([CC], "$CC", [Define to compiler])
+ 
+ AC_PATH_PROG([DATE], [date], [no])
+-AS_IF([test x"$DATE" != "xno"], [build_time=`$DATE +"%F %T %z"`])
++AS_IF([test x"$DATE" != "xno"], [
++  if test x"$SOURCE_DATE_EPOCH" = "x"; then
++build_time=`$DATE +"%F %T %z"`
++  else
++build_time=`$DATE --utc --date="@$SOURCE_DATE_EPOCH" +"%F %T %z"`
++  fi
++])
+ AC_DEFINE_UNQUOTED([BUILD_TIME], ["$build_time"], [We have build time])
+ 
+ AC_PATH_PROG([A2X], [a2x], [no])
diff -Nru quvi-0.9.5/debian/patches/series quvi-0.9.5/debian/patches/series
--- quvi-0.9.5/debian/patches/series2022-08-25 07:45:22.0 -0700
+++ quvi-0.9.5/debian/patches/series2022-11-17 12:59:49.0 -0800
@@ -1,2 +1,3 @@
+reproducible-build.patch
 0001-Fix-FTBFS-with-autoconf-2.70.patch
 0002-Avoid-duplicated-symbol-write.patch


This is a partial fix, as quvi still records build paths, but we do not
test build path variations for bookworm/testing on
tests.reproducible-builds.org, so it will at least become reproducible
once it migrates to bookworm!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024344: precious - new version of rust-serial-test.

[Peter Green]

Package: precious
Version: 0.3.0-1
Severity: serious

I've just uploaded version 0.9 of rust-serial-test, the dependencies in precious
need updating to match. A debdiff is attatched.

If I get no response i'll probablly NMU this in a week or so.diff -Nru precious-0.3.0/debian/changelog precious-0.3.0/debian/changelog
--- precious-0.3.0/debian/changelog 2022-10-04 15:00:58.0 +
+++ precious-0.3.0/debian/changelog 2022-11-17 20:57:47.0 +
@@ -1,3 +1,11 @@
+precious (0.3.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch 1001_serial_test.patch to bump serial_test dev-dependency to 0.9
+and update build-depedencies accordingly.
+
+ -- Peter Michael Green   Thu, 17 Nov 2022 20:57:47 +
+
 precious (0.3.0-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru precious-0.3.0/debian/control precious-0.3.0/debian/control
--- precious-0.3.0/debian/control   2022-10-04 14:56:55.0 +
+++ precious-0.3.0/debian/control   2022-11-17 20:53:32.0 +
@@ -28,7 +28,7 @@
  librust-regex-1+default-dev,
  librust-serde-1+default-dev (>= 1.0.130),
  librust-serde-1+derive-dev (>= 1.0.130),
- librust-serial-test-0.5+default-dev ,
+ librust-serial-test-0.9+default-dev ,
  librust-tempfile-3+default-dev ,
  librust-thiserror-1+default-dev (>= 1.0.30),
  librust-toml-0.5+default-dev (>= 0.5.8),
diff -Nru precious-0.3.0/debian/patches/1001_serial_test.patch 
precious-0.3.0/debian/patches/1001_serial_test.patch
--- precious-0.3.0/debian/patches/1001_serial_test.patch1970-01-01 
00:00:00.0 +
+++ precious-0.3.0/debian/patches/1001_serial_test.patch2022-11-17 
20:52:35.0 +
@@ -0,0 +1,34 @@
+Index: precious-0.3.0/precious-core/Cargo.toml
+===
+--- precious-0.3.0.orig/precious-core/Cargo.toml
 precious-0.3.0/precious-core/Cargo.toml
+@@ -31,4 +31,4 @@ which = ">= 3.0.0, < 5.0.0"
+ [dev-dependencies]
+ precious-testhelper = { version = "0.3.0", path = "../precious-testhelper" }
+ pretty_assertions = "1.1.0"
+-serial_test = "0.5.1"
++serial_test = "0.9"
+Index: precious-0.3.0/precious-exec/Cargo.toml
+===
+--- precious-0.3.0.orig/precious-exec/Cargo.toml
 precious-0.3.0/precious-exec/Cargo.toml
+@@ -16,5 +16,5 @@ which = ">= 3.0.0, < 5.0.0"
+ 
+ [dev-dependencies]
+ pretty_assertions = "1.1.0"
+-serial_test = "0.5.1"
++serial_test = "0.9"
+ tempfile = "3.3.0"
+Index: precious-0.3.0/precious-integration/Cargo.toml
+===
+--- precious-0.3.0.orig/precious-integration/Cargo.toml
 precious-0.3.0/precious-integration/Cargo.toml
+@@ -13,7 +13,7 @@ regex = "1.5.5"
+ precious-core = { version = "0.3.0", path = "../precious-core" }
+ precious-exec = { version = "0.3.0", path = "../precious-exec" }
+ precious-testhelper = { version = "0.3.0", path = "../precious-testhelper" }
+-serial_test = "0.5.1"
++serial_test = "0.9"
+ 
+ [[test]]
+ name = "integration_tests"
diff -Nru precious-0.3.0/debian/patches/series 
precious-0.3.0/debian/patches/series
--- precious-0.3.0/debian/patches/series2022-10-04 14:50:23.0 
+
+++ precious-0.3.0/debian/patches/series2022-11-17 20:50:58.0 
+
@@ -1,3 +1,4 @@
 2001_clap.patch
 2001_regex.patch
 2002_privacy.patch
+1001_serial_test.patch

Bug#834050: libpam-ldap: please make the build reproducible

[Lucas Castro]

Thanks. = )

Em 17/11/2022 16:48, Vagrant Cascadian escreveu:

Control: tags 834050 pending

On 2017-02-15, Chris Lamb wrote:

Lucas Castro wrote:


I suppose the patch hadn't fixed the bug.

Ah, try:

   --- libpam-ldap-186.orig/vers_string
   +++ libpam-ldap-186/vers_string
   @@ -14,6 +14,10 @@ if ($ENV{'PROGRAM'}) { $PROGRAM = $ENV{'
  
chop($AUTHOR);

chop($DATE=`date -u`);
   +if (defined $ENV{SOURCE_DATE_EPOCH}) {
   +chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
   +$AUTHOR="NO DEVELOPER SET";
   +}
chop($CWD=`pwd`);
  
($PROJECT, $VERSION) = split(/\-/, ());

This solved both the timestamp and build user issue!

There was another issue where the package and version information is
derived from the top-level build directory, but this can be fixed easily
by passing PROGRAM to dh_auto_build.

Uploaded an NMU to DELAYED/10 which fixes both outstanding issues:

diff -Nru libpam-ldap-186/debian/changelog libpam-ldap-186/debian/changelog
--- libpam-ldap-186/debian/changelog2017-05-31 10:19:41.0 -0700
+++ libpam-ldap-186/debian/changelog2022-11-17 11:42:13.0 -0800
@@ -1,3 +1,17 @@
+libpam-ldap (186-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is
+set. (Closes: #834050)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Pass PROGRAM to dh_auto_build override.
+(Closes: #834050)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 
11:42:13 -0800
+
  libpam-ldap (186-4) unstable; urgency=medium
  
* Install /usr/share/pam-configs/ldap

diff -Nru libpam-ldap-186/debian/patches/series 
libpam-ldap-186/debian/patches/series
--- libpam-ldap-186/debian/patches/series   2017-02-10 20:39:24.0 
-0800
+++ libpam-ldap-186/debian/patches/series   2022-11-17 11:42:13.0 
-0800
@@ -6,3 +6,4 @@
  reproducible_build.patch
  configfile_install.patch
  configfile_references.patch
+vers_string-use-fixed-value-for-author-i.patch
diff -Nru 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
--- 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch   
1969-12-31 16:00:00.0 -0800
+++ 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch   
2022-11-17 11:42:13.0 -0800
@@ -0,0 +1,21 @@
+From: Chris Lamb 
+Date: Wed, 15 Feb 2017 17:12:58 +1300
+X-Dgit-Generated: 186-4.1 98efdb0f8a716ed9c1403523c90f3b0b6ff8c493
+Subject: vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is set.
+
+(Closes: #834050)
+
+---
+
+diff --git a/vers_string b/vers_string
+index 11af68a..5a072f3 100755
+--- a/vers_string
 b/vers_string
+@@ -16,6 +16,7 @@ chop($AUTHOR);
+ chop($DATE=`date -u`);
+ if (defined $ENV{SOURCE_DATE_EPOCH}) {
+   chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
++  $AUTHOR="NO DEVELOPER SET";
+ }
+ chop($CWD=`pwd`);
+
diff -Nru libpam-ldap-186/debian/rules libpam-ldap-186/debian/rules
--- libpam-ldap-186/debian/rules2017-05-31 10:19:28.0 -0700
+++ libpam-ldap-186/debian/rules2022-11-17 11:42:13.0 -0800
@@ -4,6 +4,8 @@
  
  export DEB_BUILD_MAINT_OPTIONS= hardening=+bindnow
  
+include /usr/share/dpkg/pkg-info.mk

+
  %:
dh $@ --with autoreconf
  
@@ -17,3 +19,6 @@

dh_install
install -D -m 644 debian/libpam-ldap.pam-auth-update \
debian/libpam-ldap/usr/share/pam-configs/ldap
+
+override_dh_auto_build:
+   dh_auto_build -- PROGRAM=$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)



live well,
   vagrant


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024336: /usr/share/aclocal/pkg.m4 is older than the one in the reference pkg-config

[Andrej Shadura]

Control: tag -1 pending

Hi,

On Thu, 17 Nov 2022, at 19:48, Simon McVittie wrote:
> The original/reference pkg-config version 0.29.2 used to be in Debian
> and shipped /usr/share/aclocal/pkg.m4 serial 12, but pkgconf 1.8.0 only
> provides serial 11, corresponding to original/reference pkg-config version
> 0.29.1. This is a regression between Debian packages pkg-config (<< 1),
> which was the original/reference pkg-config, and pkg-config (>= 1), which
> is a transitional package towards pkgconf.

> This appears to have been fixed upstream in 1.9.0.

Thanks, will update it.

-- 
Cheers,
  Andrej

Bug#834016: ddd: please make the build reproducible

[Vagrant Cascadian]

Control: tags 834016 pending

> Whilst working on the "reproducible builds" effort [0], we noticed
> that ddd could not be built reproducibly.

I have pushed the fix to git:

  
https://salsa.debian.org/debian/ddd/-/commit/3aa51771bacd797f68cbcf23b5f62b834148a2f6
  
And uploaded an NMU to DELAYED/10 fixing this and another fix already
included in git:

diff -Nru ddd-3.3.12/debian/changelog ddd-3.3.12/debian/changelog
--- ddd-3.3.12/debian/changelog 2021-02-10 13:05:37.0 -0800
+++ ddd-3.3.12/debian/changelog 2022-11-17 12:13:34.0 -0800
@@ -1,3 +1,16 @@
+ddd (1:3.3.12-5.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Debian Janitor ]
+  * Apply multi-arch hints.
++ ddd-doc: Add Multi-Arch: foreign.
+
+  [ Chris Lamb ]
+  * Make the build reproducible. (Closes: #834016)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 
12:13:34 -0800
+
 ddd (1:3.3.12-5.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ddd-3.3.12/debian/control ddd-3.3.12/debian/control
--- ddd-3.3.12/debian/control   2021-02-10 12:59:52.0 -0800
+++ ddd-3.3.12/debian/control   2022-11-17 12:09:44.0 -0800
@@ -39,6 +39,7 @@
 Depends: ${misc:Depends}
 Recommends: pdf-viewer, postscript-viewer, ddd
 Replaces: ddd (<< 3.1.90)
+Multi-Arch: foreign
 Description: Additional documentation for the Data Display Debugger
  The "Debugging with DDD" and "Writing DDD Themes" User's Guide and 
  Reference Manual in PDF format ("info" versions are included in the "ddd"
diff -Nru ddd-3.3.12/debian/patches/007_reproducible_build.diff 
ddd-3.3.12/debian/patches/007_reproducible_build.diff
--- ddd-3.3.12/debian/patches/007_reproducible_build.diff   1969-12-31 
16:00:00.0 -0800
+++ ddd-3.3.12/debian/patches/007_reproducible_build.diff   2022-11-17 
12:10:26.0 -0800
@@ -0,0 +1,17 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-11
+
+--- ddd-3.3.12.orig/ddd/config-info
 ddd-3.3.12/ddd/config-info
+@@ -59,6 +59,10 @@ esac
+ month=`date '+%m'`
+ day=`date '+%d'`
+ date=${year}-${month}-${day}
++if [ -n "${SOURCE_DATE_EPOCH}" ]
++then
++  date=`date --utc --date="@${SOURCE_DATE_EPOCH}" '+%Y-%m-%d'`
++fi
+ (
+ echo "@(#)Built $date by $userinfo"
+ if $features; then
diff -Nru ddd-3.3.12/debian/patches/series ddd-3.3.12/debian/patches/series
--- ddd-3.3.12/debian/patches/series2021-02-10 12:59:52.0 -0800
+++ ddd-3.3.12/debian/patches/series2022-11-17 12:10:26.0 -0800
@@ -8,3 +8,4 @@
 tinfo_support.diff
 remove_broken_ICE_MOTIF_DIALOGS_OWN_SELECTION_LIST.diff
 fix-ftbfs-gcc-9.patch
+007_reproducible_build.diff


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024271: python-cffi: FTBFS on hppa - c/test_c.py test faults and drops core

[Stefano Rivera]

Hi John (2022.11.16_21:17:59_+)

Generally speaking python-cffi test failures point to libffi bugs. So,
I'd start by trying to verify the behaviour of the underlying behaviour
in libffi, from C.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1024265: opengv: Build for all supported python3 versions or Build-Depend on python3-dev

[Tyler Weaver]

Control: tags -1 patchFrom 73eef02134beab56bd32d126bcf68b922f648246 Mon Sep 17 00:00:00 2001
From: Tyler Weaver 
Date: Thu, 17 Nov 2022 13:35:24 -0700
Subject: [PATCH] Use pybuild to build for multiple Python versions

Closes: #1024265
---
 debian/rules | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index 466bb78..0f766ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,14 +4,11 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-%:
-	dh $@ --with python3
+export PYBUILD_CONFIGURE_ARGS=-DBUILD_TESTS=ON -DBUILD_PYTHON=ON -DBUILD_SHARED_LIBS=ON
+export PYBUILD_SYSTEM=cmake
 
-override_dh_auto_configure:
-	dh_auto_configure -- \
-		-DBUILD_TESTS=ON \
-		-DBUILD_PYTHON=ON \
-		-DBUILD_SHARED_LIBS=ON
+%:
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_build-arch:
 	dh_auto_build -a
@@ -34,3 +31,4 @@ override_dh_auto_clean:
 	rm -rf doc/html doc/latex
 
 
+
-- 
2.34.1



publickey - maybe@tylerjw.dev - 0xED8559C2.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1024343: insighttoolkit4: releasability with bookworm?

[Étienne Mollier]

Package: release.debian.org
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org

Dear Release Team,

I would like to seek advice whether build-depending on gcc-11
for insighttoolkit4 would be an acceptable tradeoff to maintain
this library in the upcoming bookworm?  Even, whether trying to
bring it to bookworm would be acceptable at all?

The library is not maintained anymore for quite some time, in
favor of it's up-to-date version insighttoolkit5.  I also
suspect maintainability of the old version will be a problem
from a security point of view: for instance some un-vendored
libraries went back in the source package after breakages in the
test suite caused by updates in the system libraries.

However, there are still several reverse dependencies which have
not made the jump to itk-5.y yet, and are currently out of
testing due to depending on packages which are not part of the
testing distribution anymore.  Also, I noticed in the RC bug[1]
affecting it that there has been quite some effort from
different parties to try to help bringing it back to testing,
but to no avail.  Finally, I had been hoping to keep the library
in a somewhat working condition for downstream users to be able
to migrate somewhat smoothly from itk-4.y to itk-5.y in
bookworm; the latter was not made available in bullseye alas.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012950

Thank you for your effort in coordinating the construction of
Debian releases!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/tty1, please excuse my verbosity
   `-on air: Symphony X - Charon


signature.asc
Description: PGP signature

Bug#974868: samba-vfs-modules: Still causing issues - at least on armv5tel/armel

[Michael Tokarev]

17.11.2022 14:09, ArtMG wrote:
..

I have now reproduced the error on 4.13.13 on 32bit, and confirmed it is *still* an issue 
with 4.16.7 on 32bit. However when I switch to 64bit OS version, the error does *not* 
occur, not even in 4.13.13. The TimeMachine client successfully mounts the share and 
completes multiple backups, and the server smbd logs are clean, with no overflow 
warnings, and definitely no "Invalid or incomplete multibyte or wide character" 
errors.



Do you have ability to compile samba?  If yes (maybe with a debian package),
can you please try the attached patch?  It removes the useless and actually
wrong check for the off_t overflowing size_t.

Or alternatively I can provide pre-built binaries.

Thanks,

/mjtdiff --git a/source3/modules/vfs_fruit.c b/source3/modules/vfs_fruit.c
index 4058d4834e7..8e31e74f2a6 100644
--- a/source3/modules/vfs_fruit.c
+++ b/source3/modules/vfs_fruit.c
@@ -5273,17 +5273,6 @@ static bool fruit_tmsize_do_dirent(vfs_handle_struct *handle,
 		return true;
 	}
 
-	/*
-	 * Arithmetic on 32-bit systems may cause overflow, depending on
-	 * size_t precision. First we check its unlikely, then we
-	 * force the precision into target off_t, then we check that
-	 * the total did not overflow either.
-	 */
-	if (bandsize > SIZE_MAX/nbands) {
-		DBG_ERR("tmsize potential overflow: bandsize [%zu] nbands [%zu]\n",
-			bandsize, nbands);
-		return false;
-	}
 	tm_size = (off_t)bandsize * (off_t)nbands;
 
 	if (state->total_size + tm_size < state->total_size) {

Bug#1024342: /etc/X11/Xsession.d/90x11-common_ssh-agent: ssh-agent missing on second log-in

[Martin von Gagern]

Package: x11-common
Version: 1:7.7+23
Severity: normal
File: /etc/X11/Xsession.d/90x11-common_ssh-agent

Dear Maintainer,

When logging out of Cinnamon and back in, I don't have ssh-agent
running any more.

Several current desktop environments persist environment variables
across logins, so that on a logout followed by a login these variables
are available. I have found code for doing so in Gnome [1] and
Cinnamon [2]. The X11 ssh-agent session startup script checks [ -z
"$SSH_AUTH_SOCK" ] as a precondition for launching ssh-agent [3]. So
when taken together, the first login will launch ssh-agent, then save
environment variables to dbus. The next session will be initialized
with these environment variables (presumably something systemd does,
haven't checked) and will therefore skip launching ssh-agent, despite
the fact that the previous agent got terminated at shutdown of the
first session.

One possible solution to this would be to replace [ -z
"$SSH_AUTH_SOCK" ] with [ ! -S "$SSH_AUTH_SOCK" ], i.e. to check that
the environment variable is not only set but actually refers to a
socket. That way, when ssh-agent for the first session terminates, the
socket will get closed and the next session will launch its own agent
despite the fact that the environment variable got persisted.

An alternative might be to also inspect SSH_AGENT_PID, and when it's
set and doesn't refer to a running process then that could also be
taken as in indication that a new agent is needed. I can't think of a
reasonable scenario that would warrant such a complex approach; I'd
think that the solution in the previous paragraph should be enough,
but if I'm missing some legitimate use case where the environment
variable would be set before the agent gets launched, then the PID
might offer a viable and even safer alternative.

Personally I'm not a fan of environment variables getting persisted in
this fashion, but given that it is default behavior in multiple
desktop environments, and probably there for a reason, I think it
makes sense to cater for it in the script. The benefits should
outweigh potential drawbacks in weird corner cases.

My current workaround, based on [4], is having this in my ~/.xsessionrc:

if [ -n "$SSH_AUTH_SOCK" ] && [ ! -S "$SSH_AUTH_SOCK" ]; then
  unset SSH_AUTH_SOCK
  unset SSH_AGENT_PID
fi

[1] 
https://salsa.debian.org/gnome-team/gnome-session/-/blob/81c88fa3485949f8c7ea12e68d07e8060d368e79/gnome-session/gsm-util.c#L544-707
[2] 
https://salsa.debian.org/cinnamon-team/cinnamon-session/-/blob/255fd6600dfafe131ca3247d641fdd64098f7f47/cinnamon-session/csm-util.c#L569-715
[3] 
https://salsa.debian.org/xorg-team/xorg/-/blob/d6af3f0a48de41f74069a8befc4fe9ca0fcd0118/debian/local/Xsession.d/90x11-common_ssh-agent#L10
[4] https://utcc.utoronto.ca/~cks/space/blog/linux/Fedora26CinnamonSSHAgent

-- System Information:
Debian Release: rodete
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-common depends on:
ii  lsb-base  11.2

x11-common recommends no packages.

x11-common suggests no packages.

-- no debconf information

Bug#1024057: slapd: service restart does not always restart slapd

[Mike Gabriel]

Hi Ryan,

On  Mi 16 Nov 2022 18:42:49 CET, Ryan Tandy wrote:


Hi Mike,

Sorry, I should have been more explicit. What I'm really looking for  
is journal output (journalctl -u slapd.service) or equivalent from  
the actual restart event. Specifically anything showing why slapd  
fails to restart, or any errors are emitted during the attempted  
restart.


thanks,
Ryan


Unfortunately, the problem does not occur always and my journalctl -u  
slapd.service only lasts an hour into the past (???, I use Debian's  
defaults here, ???).


I just tried to reproduce the issue manually, but failed (restarts worked).

I will update this bug report if I will be able to reproduce the issue  
and get a fresh log from journalctl. (However, we have work-around in  
place now and maybe won't see the issue again).


Greets,
Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpfY4cvITUXT.pgp
Description: Digitale PGP-Signatur

Bug#834050: libpam-ldap: please make the build reproducible

[Vagrant Cascadian]

Control: tags 834050 pending

On 2017-02-15, Chris Lamb wrote:
> Lucas Castro wrote:
>
>> I suppose the patch hadn't fixed the bug.
>
> Ah, try:
>
>   --- libpam-ldap-186.orig/vers_string
>   +++ libpam-ldap-186/vers_string
>   @@ -14,6 +14,10 @@ if ($ENV{'PROGRAM'}) { $PROGRAM = $ENV{'
>  
>chop($AUTHOR);
>chop($DATE=`date -u`);
>   +if (defined $ENV{SOURCE_DATE_EPOCH}) {
>   +   chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
>   +   $AUTHOR="NO DEVELOPER SET";
>   +}
>chop($CWD=`pwd`);
>  
>($PROJECT, $VERSION) = split(/\-/, ());

This solved both the timestamp and build user issue!

There was another issue where the package and version information is
derived from the top-level build directory, but this can be fixed easily
by passing PROGRAM to dh_auto_build.

Uploaded an NMU to DELAYED/10 which fixes both outstanding issues:

diff -Nru libpam-ldap-186/debian/changelog libpam-ldap-186/debian/changelog
--- libpam-ldap-186/debian/changelog2017-05-31 10:19:41.0 -0700
+++ libpam-ldap-186/debian/changelog2022-11-17 11:42:13.0 -0800
@@ -1,3 +1,17 @@
+libpam-ldap (186-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is
+set. (Closes: #834050)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Pass PROGRAM to dh_auto_build override.
+(Closes: #834050)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 
11:42:13 -0800
+
 libpam-ldap (186-4) unstable; urgency=medium
 
   * Install /usr/share/pam-configs/ldap
diff -Nru libpam-ldap-186/debian/patches/series 
libpam-ldap-186/debian/patches/series
--- libpam-ldap-186/debian/patches/series   2017-02-10 20:39:24.0 
-0800
+++ libpam-ldap-186/debian/patches/series   2022-11-17 11:42:13.0 
-0800
@@ -6,3 +6,4 @@
 reproducible_build.patch
 configfile_install.patch
 configfile_references.patch
+vers_string-use-fixed-value-for-author-i.patch
diff -Nru 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch
--- 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch   
1969-12-31 16:00:00.0 -0800
+++ 
libpam-ldap-186/debian/patches/vers_string-use-fixed-value-for-author-i.patch   
2022-11-17 11:42:13.0 -0800
@@ -0,0 +1,21 @@
+From: Chris Lamb 
+Date: Wed, 15 Feb 2017 17:12:58 +1300
+X-Dgit-Generated: 186-4.1 98efdb0f8a716ed9c1403523c90f3b0b6ff8c493
+Subject: vers_string: Use fixed value for AUTHOR if SOURCE_DATE_EPOCH is set.
+
+(Closes: #834050)
+
+---
+
+diff --git a/vers_string b/vers_string
+index 11af68a..5a072f3 100755
+--- a/vers_string
 b/vers_string
+@@ -16,6 +16,7 @@ chop($AUTHOR);
+ chop($DATE=`date -u`);
+ if (defined $ENV{SOURCE_DATE_EPOCH}) {
+   chop($DATE=`LC_ALL=C date --date="@\${SOURCE_DATE_EPOCH}" -u`);
++  $AUTHOR="NO DEVELOPER SET";
+ }
+ chop($CWD=`pwd`);
+ 
diff -Nru libpam-ldap-186/debian/rules libpam-ldap-186/debian/rules
--- libpam-ldap-186/debian/rules2017-05-31 10:19:28.0 -0700
+++ libpam-ldap-186/debian/rules2022-11-17 11:42:13.0 -0800
@@ -4,6 +4,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS= hardening=+bindnow
 
+include /usr/share/dpkg/pkg-info.mk
+
 %:
dh $@ --with autoreconf
 
@@ -17,3 +19,6 @@
dh_install
install -D -m 644 debian/libpam-ldap.pam-auth-update \
debian/libpam-ldap/usr/share/pam-configs/ldap
+
+override_dh_auto_build:
+   dh_auto_build -- PROGRAM=$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)



live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails

[gregor herrmann]

On Thu, 17 Nov 2022 19:10:49 +, Niko Tyni wrote:

> > > From the log:
> > >not ok 2 - ZLIB_VERSION (1.2.11) matches 
> > > Compress::Raw::Zlib::zlib_version
> > ># Failed test (t/compress/CompTestUtils.pm at line 61)
> > >#  got: '1.2.11'
> > ># expected: '1.2.13'
> > Hu?
> Uh, I was debugging this manually with 'perl t/02zlib.t'
> and must have mixed up the logs. Sorry!

No worries, I guessed later that you might have done some manual
debugging.
 
> > Some quick thoughts:
> > - we could play with zlib_version vs. ZLIB_VERSION (1.2.13 vs.
> >   1.2.11, according to t/000prereq.t) in t/02zlib.t
> Yeah I guess that's the way to go if we want to allow the version skew.
> I think I have a slight preference for this over the rebuild solution.

Alright.

So something like this?

#v+
--- a/t/02zlib.t.orig   2022-11-17 19:42:16.512726239 +
+++ b/t/02zlib.t2022-11-17 19:45:06.421757489 +
@@ -12,7 +12,7 @@
 
 use Test::More  ;
 
-use constant ZLIB_1_2_12_0 => 0x12C0;
+use constant ZLIB_1_2_12_0 => '1.2.12';
 
 BEGIN
 {
@@ -489,7 +489,7 @@
 
 # Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib
 # ZLIB_NG has the fix for all versions
-if (ZLIB_VERNUM >= ZLIB_1_2_12_0 ||  Compress::Raw::Zlib::is_zlibng)
+if ($Zlib_ver gt ZLIB_1_2_12_0 ||  Compress::Raw::Zlib::is_zlibng)
 {
 cmp_ok $status, '==', Z_STREAM_END ;
 }
@@ -523,7 +523,7 @@
 $GOT = '';
 $status = $k->inflate($rest, $GOT);
 # Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib
-if (ZLIB_VERNUM >= ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
+if ($Zlib_ver gt ZLIB_1_2_12_0 || Compress::Raw::Zlib::is_zlibng)
 {
 cmp_ok $status, '==', Z_STREAM_END ;
 }
#v-

$Zlib_ver comes from line 44:
my $Zlib_ver = Compress::Raw::Zlib::zlib_version ;

And I'm never sure if 'gt' is a good idea for comparing versions or I
should wrap my head around version->parse().
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Salvatore Bonaccorso]

Hi Sam,

On Thu, Nov 17, 2022 at 09:49:20AM -0700, Sam Hartman wrote:
> > "Salvatore" == Salvatore Bonaccorso  writes:
> >> Will fix for unstable tomorrow.
> 
> Salvatore> Thank you.
> 
> >> I'm still trying to understand the practical impact.  Do you
> >> think you're going to want to issue a DSA for stable?
> 
> Salvatore> We were originally thinking so (and Moritz added krb5 to
> Salvatore> the DSA needed list), as at least for 32bit architectures
> Salvatore> it might be possible to go beyond denial of service and
> Salvatore> potentially leading to remote code execution. But if your
> Salvatore> assesment on the issue makes you confident it's not DSA
> Salvatore> worthy we can re-evaluate.
> 
> I strongly encourage a DSA.
> There's the 32-bit issue, but I'm also concerned about what happens if
> there is a cross-realm trust.
> I think the issue is that with cross-realm trust you may be able to get
> the KDC to produce a  PACcontaining out-of-bounds memory  and send it out.
> And then if you have a service that can decrypt that PAC, look at that
> memory, possibly including tservice keys.
> So it may lead to an entire realm compromise.
> What I can't entirely tell is whether that's limited to 32-bit
> architectures or whether you could potentially have that happen on
> 64-bit architectures.
> 
> Either way that's really bad.

Thanks for sharing the analysis. Can you prepare debdiff for
bullseye-security accordingly, so we can release an update via a DSA?

Regards,
Salvatore

Bug#1019830: codeblocks: Please transition to wxwidgets3.2

[Olly Betts]

On Sun, Oct 30, 2022 at 03:52:13PM +0800, Bo YU wrote:
> I have tried to build the package with libwxgtk3.2-dev, but
> unfortunately, it fails:
[snip]
> Could you help to have a look?

Looking at upstream's SVN history I can see changes for wx3.2
compatibility so it looks like they're on top of this.

Therefore I'd suggest trying an upstream SVN snapshot rather than
wasting energy trying to address issues upstream have likely already
been solved.

Cheers,
Olly

Bug#982842: open-iscsi: do not use iscsistart in the boot process

[Eric Mackay]

I have a merge request to open-iscsi that would add iscsid/iscsiadm capability 
to initrd:
https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/14

The default behavior is unaffected, so users would explicitly enable this 
feature if they want it.

Using an iscsi root in initrd is of significant importance in
cloud computing, and ensuring robust and reliable boot capability
while using iscsi is best done with iscsid/iscsiadm and not iscsistart.

Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails

[Niko Tyni]

On Wed, Nov 16, 2022 at 10:44:33PM +0100, gregor herrmann wrote:
> On Wed, 16 Nov 2022 21:56:31 +0200, Niko Tyni wrote:
> 
> > From the log:
> > 
> >not ok 2 - ZLIB_VERSION (1.2.11) matches 
> > Compress::Raw::Zlib::zlib_version
> ># Failed test (t/compress/CompTestUtils.pm at line 61)
> >#  got: '1.2.11'
> ># expected: '1.2.13'
> ># 
> ># The version of zlib.h does not match the version of libz
> ># 
> ># You have zlib.h version 1.2.11
> >#  and libz   version 1.2.13
> ># 
> ># You probably have two versions of zlib installed on your system.
> ># Try removing the one you don't want to use and rebuild.
> 
> Hu?

Uh, I was debugging this manually with 'perl t/02zlib.t'
and must have mixed up the logs. Sorry!

> Some quick thoughts:
> - we could play with zlib_version vs. ZLIB_VERSION (1.2.13 vs.
>   1.2.11, according to t/000prereq.t) in t/02zlib.t

Yeah I guess that's the way to go if we want to allow the version skew.
I think I have a slight preference for this over the rebuild solution.

> Assuming this is not a recurring pattern, a one-time binNMU might be
> not so bad …

If this is for safety rather than just fixing the failing test, we'd
want to do that for src:perl as well.
-- 
Niko

Bug#1024341: RM: lostirc -- RoQA; unmaintained, dead upstream, depends on obsolete libs, alternatives exist

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove lostirc. The last maintainer upload was in 2008, it's
orphaned without an adopter since 2016, depends on obsolete GTK2,
is dead upstream and there are plenty of alternatives in the archive.

Bug#1024340: RM: kanjipad -- RoQA; unmaintained, dead upstream, depends on obsolete libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove kanjipad. The last maintainer upload was in 2013, it's orphaned
without an adopter since 2020, depends on obsolete GTK2 and is dead upstream.
Popcon is practically non-existent.

Bug#1024339: RM: ion -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ion. It's unmaintained (last maintainer upload in 2014 and 
orphaned
without adopter since 1.5 years) and RC-buggy (FTBFS with GCC >= 7) since 2017.

Bug#1024338: RM: setcolortemperature -- RoQA; dead upstream, replaced by xsct

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove setcolortemperature. Development has ceased and
https://github.com/Tookmund/setcolortemperature (and the original
O: bug) point to xsct, which is now packaged in Debian.

Bug#1024337: RM: twoftpd -- RoQA; unmaintained, dead upstream, plenty of alternatives

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove twoftpd. The last maintainer upload was in 2014, it's orphaned 
without
an adopter since 2019 and dead upstream. And there's plenty of ftpd 
alternatives in
the archive.

Bug#1024336: /usr/share/aclocal/pkg.m4 is older than the one in the reference pkg-config

[Simon McVittie]

Package: pkgconf
Version: 1.8.0-10
Severity: normal
File: /usr/share/aclocal/pkg.m4
Tags: fixed-upstream

The original/reference pkg-config version 0.29.2 used to be in Debian
and shipped /usr/share/aclocal/pkg.m4 serial 12, but pkgconf 1.8.0 only
provides serial 11, corresponding to original/reference pkg-config version
0.29.1. This is a regression between Debian packages pkg-config (<< 1),
which was the original/reference pkg-config, and pkg-config (>= 1), which
is a transitional package towards pkgconf.

This means that doing a fresh build of an Autotools package will install
an older pkg.m4 which lacks the new macros PKG_WITH_MODULES,
PKG_HAVE_WITH_MODULES and PKG_HAVE_DEFINE_WITH_MODULES, and provides
less clear messages about what packages it is checking for.

(Mitigation: doing an `autoreconf` in an upstream `make dist` tree that
was prepared elsewhere will not overwrite m4/pkg.m4 with the version
with a lower serial number.)

This appears to have been fixed upstream in 1.9.0.

smcv

Bug#833612: nsnake: please make the build reproducible

[Vagrant Cascadian]

Control: tags 833612 pending

I have uploaded an NMU to DELAYED/10 fixing this issue:

diff -Nru nsnake-3.0.1/debian/changelog nsnake-3.0.1/debian/changelog
--- nsnake-3.0.1/debian/changelog   2014-08-13 15:55:57.0 -0700
+++ nsnake-3.0.1/debian/changelog   2022-11-17 09:49:38.0 -0800
@@ -1,3 +1,12 @@
+nsnake (3.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Make the build reproducible. (Closes: #833612)
+
+ -- Vagrant Cascadian   Thu, 17 Nov 2022 
17:49:38 +
+
 nsnake (3.0.1-2) unstable; urgency=medium
 
   * Updated maintainer mail address
diff -Nru 
nsnake-3.0.1/debian/patches/make-the-build-reproducible.-closes-8336.patch 
nsnake-3.0.1/debian/patches/make-the-build-reproducible.-closes-8336.patch
--- nsnake-3.0.1/debian/patches/make-the-build-reproducible.-closes-8336.patch  
1969-12-31 16:00:00.0 -0800
+++ nsnake-3.0.1/debian/patches/make-the-build-reproducible.-closes-8336.patch  
2022-11-17 09:49:38.0 -0800
@@ -0,0 +1,24 @@
+From: Chris Lamb 
+Date: Sun, 7 Aug 2016 00:52:48 +0200
+X-Dgit-Generated: 3.0.1-2.1 2c94f0b53f31d2df9ae65987475821855541d1cb
+Subject: Make the build reproducible. (Closes: #833612)
+
+
+---
+
+diff --git a/Makefile b/Makefile
+index 749cb37..4fe7e93 100644
+--- a/Makefile
 b/Makefile
+@@ -39,7 +39,11 @@
+ # General Info
+ PACKAGE = nsnake
+ VERSION = 3.0.0
++ifdef SOURCE_DATE_EPOCH
++DATE= $(shell LC_ALL=C date --utc --date="@$(SOURCE_DATE_EPOCH)" "+%b%Y")
++else
+ DATE= $(shell date "+%b%Y")
++endif
+ 
+ # Install dirs
+ PREFIX  = /usr
diff -Nru nsnake-3.0.1/debian/patches/series nsnake-3.0.1/debian/patches/series
--- nsnake-3.0.1/debian/patches/series  2014-08-12 11:54:28.0 -0700
+++ nsnake-3.0.1/debian/patches/series  2022-11-17 09:49:38.0 -0800
@@ -1,2 +1,3 @@
 install-on-usr-games.patch
 hardening.patch
+make-the-build-reproducible.-closes-8336.patch


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024329: u-boot: extlinux.conf prompt value is ignored

[Manuel Traut]

Hi vagrant,

On Thu, Nov 17, 2022 at 09:01:59AM -0800, Vagrant Cascadian wrote:
> On 2022-11-17, Manuel Traut wrote:
> > during testing on the imx6 colibri board i recognized
> > that the prompt value of extlinux.conf is ignored.
> >
> > The attached patch fixes the problem.
> 
> Could you spell this out in a little more detail exactly what is
> missing? Maybe cut-and-paste what it looks like with and without the
> patch applied?

regarding the documentation if there is

prompt = 0

in the extlinux.conf it shall not ask the user for input.

In combination with timeout = 0 it boots directly into the configured
target.

https://github.com/u-boot/u-boot/blob/master/common/menu.c#L347

However this does not work, because prompt is set to one per default
in the source code and is not read from the extlinux.conf

https://github.com/u-boot/u-boot/blob/master/boot/pxe_utils.c#L1328

> I'm also curious why this is noticed with the imx6 colibri board and
> presumably not other boards... I have definitely used the
> pxeboot/extlinux functionality with many other boards (maybe I'm not
> using this specific functionality in this code path, though).

This feature is probably broken for all boards.
Maybe ordinary users are fine with having a 1 second timeout, however
in our use-case booting as fast as possible is important.

> > Can it be added to debian or shall I try to submit
> > it upstream first?
> 
> Submitting something like this upstream is always a good idea. Feel free
> to CC me. I suspect upstream will want more verbosity in the error
> description too...

Ok, I will do so tomorrow and add you to Cc.

Thanks for your support
Manuel

> Depending on how that goes, I'll consider applying and/or backporting in
> Debian.
> 
> Thanks!
> 
> live well,
>   vagrant
> 
> > From: Manuel Traut 
> > Date: Thu, 17 Nov 2022 16:38:47 +0100
> > Subject: distro/pxe boot: read prompt value from config
> >
> > Currently the configuration of prompt in extlinux.conf is
> > ignored.
> >
> > Read it from the file, if not given do not fail.
> >
> > Signed-off-by: Manuel Traut 
> > ---
> >  boot/pxe_utils.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> > index 8133006..a6c56e0 100644
> > --- a/boot/pxe_utils.c
> > +++ b/boot/pxe_utils.c
> > @@ -1359,7 +1359,10 @@ static int parse_pxefile_top(struct pxe_context 
> > *ctx, char *p, unsigned long bas
> > break;
> >  
> > case T_PROMPT:
> > -   eol_or_eof();
> > +   err = parse_integer(, >prompt);
> > +   // Do not fail if prompt configuration is missing
> > +if (err <  0)
> > +   eol_or_eof();
> > break;
> >  
> > case T_EOL:

Bug#1020805: png23d: reproducible-builds: Embedded build paths in binaries

[Chris Lamb]

tags 1020805 + pending patch
thanks

I've just uploaded png23d 1.10-1.3 to DELAYED/10:
  
  png23d (1.10-1.3) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply a patch by Vagrant Cascadian to make the build reproducible.
  (Closes: #1020805)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for png23d-1.10 png23d-1.10

 changelog|8 
 patches/reproducible_build.patch |   11 +++
 patches/series   |1 +
 3 files changed, 20 insertions(+)

diff -Nru png23d-1.10/debian/changelog png23d-1.10/debian/changelog
--- png23d-1.10/debian/changelog2016-01-28 11:46:16.0 +
+++ png23d-1.10/debian/changelog2022-11-17 17:52:41.0 +
@@ -1,3 +1,11 @@
+png23d (1.10-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch by Vagrant Cascadian to make the build reproducible.
+(Closes: #1020805)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:52:41 +
+
 png23d (1.10-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru png23d-1.10/debian/patches/reproducible_build.patch 
png23d-1.10/debian/patches/reproducible_build.patch
--- png23d-1.10/debian/patches/reproducible_build.patch 1970-01-01 
01:00:00.0 +0100
+++ png23d-1.10/debian/patches/reproducible_build.patch 2022-11-17 
17:52:41.0 +
@@ -0,0 +1,11 @@
+--- png23d-1.10.orig/Makefile
 png23d-1.10/Makefile
+@@ -22,7 +22,7 @@ endif
+ OPTFLAGS=-O2
+ #OPTFLAGS=-O0
+ 
+-CFLAGS+=$(WARNFLAGS) -MMD -DVERSION=$(VERSION) $(OPTFLAGS) -g
++CFLAGS+=$(WARNFLAGS) -MMD -DVERSION=$(VERSION) $(OPTFLAGS) -g 
-ffile-prefix-map=$(CURDIR)=.
+ 
+ LDFLAGS+=-lpng
+ 
diff -Nru png23d-1.10/debian/patches/series png23d-1.10/debian/patches/series
--- png23d-1.10/debian/patches/series   2016-01-28 11:46:16.0 +
+++ png23d-1.10/debian/patches/series   2022-11-17 17:52:41.0 +
@@ -1,2 +1,3 @@
 ftbfs
 ld_as-needed.patch
+reproducible_build.patch

Bug#1020751: waili: reproducible-builds: Embedded build paths in binaries

[Chris Lamb]

tags 1020751 + pending patch
thanks

I've just uploaded waili 19990723-22.2 to DELAYED/10:
  
  waili (19990723-22.2) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply a patch by Vagrant Cascadian to make the build reproducible.
  (Closes: #1020751)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for waili-19990723 waili-19990723

 changelog|8 
 patches/reproducible_build.patch |   11 +++
 patches/series   |1 +
 3 files changed, 20 insertions(+)

diff -Nru waili-19990723/debian/changelog waili-19990723/debian/changelog
--- waili-19990723/debian/changelog 2014-10-09 11:11:19.0 +0100
+++ waili-19990723/debian/changelog 2022-11-17 17:41:37.0 +
@@ -1,3 +1,11 @@
+waili (19990723-22.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch by Vagrant Cascadian to make the build reproducible.
+(Closes: #1020751)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:41:37 +
+
 waili (19990723-22.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru waili-19990723/debian/patches/reproducible_build.patch 
waili-19990723/debian/patches/reproducible_build.patch
--- waili-19990723/debian/patches/reproducible_build.patch  1970-01-01 
01:00:00.0 +0100
+++ waili-19990723/debian/patches/reproducible_build.patch  2022-11-17 
17:41:37.0 +
@@ -0,0 +1,11 @@
+--- waili-19990723.orig/config/Rules.Linux.g++
 waili-19990723/config/Rules.Linux.g++
+@@ -37,7 +37,7 @@ OPTFLAGS =   -O3 -fomit-frame-pointer
+ 
+ #changed for Debian: much cleaner; and you can move the directory around
+ CFLAGS =  -Wall $(TIFFINC) $(TIFFDEF) $(OPTFLAGS) $(DEBUGFLAGS)
+-CPPFLAGS =   -I$(TOPDIR)/include $(TIFFINC) $(TIFFDEF) 
++CPPFLAGS =   -I../include $(TIFFINC) $(TIFFDEF)
+ 
+ 
+ #changed for debian: if -lwaili is specified, libtool fails to work
diff -Nru waili-19990723/debian/patches/series 
waili-19990723/debian/patches/series
--- waili-19990723/debian/patches/series2014-01-13 14:18:01.0 
+
+++ waili-19990723/debian/patches/series2022-11-17 17:41:37.0 
+
@@ -21,3 +21,4 @@
 
 #lll
 dpkg-buildflags.patch
+reproducible_build.patch

Bug#1018039: FTBFS on ppc64el with gcc-12

[Adrian Bunk]

On Thu, Nov 17, 2022 at 12:46:59PM +0100, John Paul Adrian Glaubitz wrote:
>...
> On 8/24/22 16:50, Frédéric Bonnard wrote:
> > powerpc-utils 1.3.9-1 fails to build atm with gcc-12.
> > I checked latest 1.3.10 and it's roughly the same.
> > I've opened an issue upstream.
> 
> Interestingly, the error due to "-Werror=maybe-uninitialized" does not show
> on the openSUSE builds, see [1]. openSUSE does not ship any patch to address
> the issue though.

openSUSE overwrites the CFLAGS set in configure.ac (including -Werror) with
  make CFLAGS="..."

> Fedora doesn't seem to have a patch to address the issue either [2].
>...

https://src.fedoraproject.org/rpms/powerpc-utils/blob/rawhide/f/powerpc-utils.spec#_72

> Adrian
>...

cu
Adrian

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Jonas Smedegaard]

Quoting Christoph Anton Mitterer (2022-11-17 16:25:12)
> On Thu, 2022-11-17 at 06:51 +0100, Jonas Smedegaard wrote:
> > This has already been discussed upstream
> 
> Ah ok... 
> 
> > upstream nowadays mention
> > in their documentation that several distros name it "git-delta".
> 
> I had seen that, but it rather seems like a "some distros do that" -
> not like a "we call ourselfs that".

That's my understanding as well - sorry if I was too terse previously (I
was on my way out the dorr, but excited about your post so wanted to
respond before I left).


> > The executable will be named "delta" as that name is vacant (for now
> > -
> > let's see when package is actually ready for upload into Debian).
> 
> My main point was anyway mostly that it seems to be a wonderful tool -
> not only for git - and it could be that people just oversee that it
> also works for diff/grep.

I agree that "git-delta" might mislead some to expect it to be specific
to git, but I disagree that introducing another prefix/suffix helps
much.  What helps the most, and also seems possibly, is to name it
"delta" - just not right now - and with that long-term plan I think it
is double confusing to introduce a _third_ name (since the name
"git-delta" has already been introduced by some downstreams).


Oke way you can help is to initiate the process of (attempting to) kick
out (or alternatively rename) current package "delta" from Debian.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1020804: paxctl: reproducible-builds: Embedded build paths in /sbin/paxctl

[Chris Lamb]

tags 1020804 + pending patch
thanks

I've just uploaded paxctl 0.9-1.1 to DELAYED/10:
  
  paxctl (0.9-1.1) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply a patch by Vagrant Cascadian to make the build reproducible.
  (Closes: #1020804)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for paxctl-0.9 paxctl-0.9

 changelog |8 
 rules |3 +++
 2 files changed, 11 insertions(+)

diff -Nru paxctl-0.9/debian/changelog paxctl-0.9/debian/changelog
--- paxctl-0.9/debian/changelog 2014-09-06 14:16:48.0 +0100
+++ paxctl-0.9/debian/changelog 2022-11-17 17:38:19.0 +
@@ -1,3 +1,11 @@
+paxctl (0.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch by Vagrant Cascadian to make the build reproducible.
+(Closes: #1020804)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:38:19 +
+
 paxctl (0.9-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru paxctl-0.9/debian/rules paxctl-0.9/debian/rules
--- paxctl-0.9/debian/rules 2014-09-06 14:16:48.0 +0100
+++ paxctl-0.9/debian/rules 2022-11-17 17:38:19.0 +
@@ -6,3 +6,6 @@
 
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build -- CFLAGS="$(CFLAGS)"

Bug#1024335: diffoscope: FTBFS against python 3.11

[Dan Bungert]

Package: diffoscope
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1996926

diffoscope will FTBFS in tests when run with python 3.11.  Can be observed both
on Debian Sid and Ubuntu Lunar.

https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/d/diffoscope/20221103_074104_c1d72@/log.gz

(that log also shows a lxml error, but that problem goes away when triggering
tests with lxml from proposed)

__ test_diff __

differences = []

@skip_unless_file_version_is_at_least("5.39")
@skipif(
sys.version_info < (3, 8),
reason="Python 3.7 cannot de-marshal test1.pyc-renamed",
)
def test_diff(differences):
assert_diff_startswith(
>   differences[0],
"pyc_expected_diff",
)
E   IndexError: list index out of range

differences = []

tests/comparators/test_python.py:61: IndexError

Bug#1021374: zephyr: please make the build reproducible

[Chris Lamb]

tags 828867 + pending patch
tags 1021374 + pending patch
thanks

I've just uploaded zephyr 3.1.2-1.1 to DELAYED/10:
  
  zephyr (3.1.2-1.1) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply patches by Vagrant Cascadian and Reiner Herrmann to make the build
  reproducible. (Closes: #828867, #1021374)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for zephyr-3.1.2 zephyr-3.1.2

 changelog|8 
 patches/reproducible-build.patch |   17 +
 patches/series   |1 +
 rules|2 +-
 4 files changed, 27 insertions(+), 1 deletion(-)

diff -Nru zephyr-3.1.2/debian/changelog zephyr-3.1.2/debian/changelog
--- zephyr-3.1.2/debian/changelog   2013-10-28 14:57:21.0 +
+++ zephyr-3.1.2/debian/changelog   2022-11-17 17:29:45.0 +
@@ -1,3 +1,11 @@
+zephyr (3.1.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patches by Vagrant Cascadian and Reiner Herrmann to make the build
+reproducible. (Closes: #828867, #1021374)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:29:45 +
+
 zephyr (3.1.2-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru zephyr-3.1.2/debian/patches/reproducible-build.patch 
zephyr-3.1.2/debian/patches/reproducible-build.patch
--- zephyr-3.1.2/debian/patches/reproducible-build.patch1970-01-01 
01:00:00.0 +0100
+++ zephyr-3.1.2/debian/patches/reproducible-build.patch2022-11-17 
17:29:45.0 +
@@ -0,0 +1,17 @@
+Author: Reiner Herrmann 
+Description: Strip non-deterministic information from the version string
+
+--- a/new_vers.sh
 b/new_vers.sh
+@@ -2,10 +2,7 @@
+ #
+ top_srcdir=${1:-`pwd`}
+ 
+-u=${USER-the_zephyr_builder}
+-h=`hostname`
+-t=`date`
+ v=`sh ${top_srcdir}/get_vers.sh ${top_srcdir}`
+ 
+ umask 002
+-/bin/echo "#define ZEPHYR_VERSION_STRING \"${v} (${t}) ${u}@${h}\"" > 
h/zephyr_version.h
++/bin/echo "#define ZEPHYR_VERSION_STRING \"${v}\"" > h/zephyr_version.h
diff -Nru zephyr-3.1.2/debian/patches/series zephyr-3.1.2/debian/patches/series
--- zephyr-3.1.2/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ zephyr-3.1.2/debian/patches/series  2022-11-17 17:29:45.0 +
@@ -0,0 +1 @@
+reproducible-build.patch
diff -Nru zephyr-3.1.2/debian/rules zephyr-3.1.2/debian/rules
--- zephyr-3.1.2/debian/rules   2013-07-08 16:46:41.0 +0100
+++ zephyr-3.1.2/debian/rules   2022-11-17 17:29:45.0 +
@@ -9,7 +9,7 @@
 # Uncomment this to turn on verbose mode. 
 #export DH_VERBOSE=1
 VARIETALS=krb5
-CFLAGS=-g -O
+CFLAGS=-g -O -ffile-prefix-map=$(CURDIR)=.
 
 PACKAGES:=-plibzephyr4 -pzephyr-clients -pzephyr-server -plibzephyr-dev 
$(foreach i,$(VARIETALS),-plibzephyr4-$(i) -pzephyr-server-$(i))
 

Bug#1011500: tuxcmd-modules: reproducible-builds: embedded build paths in various binaries

[Chris Lamb]

tags 1011500 + pending patch
tags 941296 + pending patch
thanks

I've just uploaded tuxcmd-modules 0.6.70+ds-5.1 to DELAYED/10:
  
  tuxcmd-modules (0.6.70+ds-5.1) unstable; urgency=medium
  .
* Non-maintainer upload.
* Apply a patch by Vagrant Cascadian to ensure that tuxcmd-modules does not
  embed build paths in various binaries. (Closes: #1011500)
* Apply a patch by Helmut Grohne to make it possible to cross-build
  tuxcmd-modules. (Closes: #941296)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for tuxcmd-modules-0.6.70+ds tuxcmd-modules-0.6.70+ds

 changelog|   10 +
 patches/reproducible-build.patch |   68 +++
 patches/series   |1 
 3 files changed, 79 insertions(+)

diff -Nru tuxcmd-modules-0.6.70+ds/debian/changelog 
tuxcmd-modules-0.6.70+ds/debian/changelog
--- tuxcmd-modules-0.6.70+ds/debian/changelog   2013-05-10 21:00:35.0 
+0100
+++ tuxcmd-modules-0.6.70+ds/debian/changelog   2022-11-17 17:15:30.0 
+
@@ -1,3 +1,13 @@
+tuxcmd-modules (0.6.70+ds-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch by Vagrant Cascadian to ensure that tuxcmd-modules does not
+embed build paths in various binaries. (Closes: #1011500)
+  * Apply a patch by Helmut Grohne to make it possible to cross-build
+tuxcmd-modules. (Closes: #941296)
+
+ -- Chris Lamb   Thu, 17 Nov 2022 17:15:30 +
+
 tuxcmd-modules (0.6.70+ds-5) unstable; urgency=low
 
   * QA upload.
diff -Nru tuxcmd-modules-0.6.70+ds/debian/patches/reproducible-build.patch 
tuxcmd-modules-0.6.70+ds/debian/patches/reproducible-build.patch
--- tuxcmd-modules-0.6.70+ds/debian/patches/reproducible-build.patch
1970-01-01 01:00:00.0 +0100
+++ tuxcmd-modules-0.6.70+ds/debian/patches/reproducible-build.patch
2022-11-17 17:15:30.0 +
@@ -0,0 +1,68 @@
+--- tuxcmd-modules-0.6.70+ds.orig/Makefile
 tuxcmd-modules-0.6.70+ds/Makefile
+@@ -1,5 +1,7 @@
+ SUBDIRS = zip libarchive gvfs
+ 
++export BUILDPATH = $(CURDIR)
++
+ all install clean shared static::
+   target=`echo $@ | sed s/-recursive//`; \
+   list='$(SUBDIRS)'; for subdir in $$list; do \
+--- tuxcmd-modules-0.6.70+ds.orig/gvfs/Makefile
 tuxcmd-modules-0.6.70+ds/gvfs/Makefile
+@@ -9,6 +9,8 @@ CFLAGS =-I. -I/usr/include \
+   -Wall -fPIC -O2 -g \
+   -DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_GNU_SOURCE
+ 
++# Avoid embedding build path
++CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
+ 
+ # VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
+ VFS_COMMON_OBJECTS=
+--- tuxcmd-modules-0.6.70+ds.orig/libarchive/Makefile
 tuxcmd-modules-0.6.70+ds/libarchive/Makefile
+@@ -13,6 +13,9 @@ CFLAGS =-I. -I/usr/include -I$(DIR_COMMO
+   -DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_GNU_SOURCE \
+   -D__VERBOSE_DEBUGx
+ 
++# Avoid embedding build path
++CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
++
+ VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
+ 
+ VFS_OBJECTS=libarchive.o
+--- tuxcmd-modules-0.6.70+ds.orig/zip/Makefile
 tuxcmd-modules-0.6.70+ds/zip/Makefile
+@@ -12,6 +12,8 @@ CFLAGS =-I. -I$(DIR_ZIPARCHIVE) -I/usr/i
+   -DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_GNU_SOURCE \
+   -D__VERBOSE_DEBUGx
+ 
++# Avoid embedding build path
++CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
+ 
+ VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
+ 
+--- tuxcmd-modules-0.6.70+ds.orig/zip/Makefile.ziparch
 tuxcmd-modules-0.6.70+ds/zip/Makefile.ziparch
+@@ -19,6 +19,9 @@ CCC=cc
+ CFLAGS = -D ZIP_ARCHIVE_LNX -fPIC -g -O2
+ #CFLAGS =
+ 
++# Avoid embedding build path
++CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
++
+ ifdef INTERNAL_BZIP2
+ CFLAGS += -D ZIP_ARCHIVE_BZIP2_INTERNAL 
+ endif
+--- tuxcmd-modules-0.6.70+ds.orig/zip/ZipArchive/Makefile
 tuxcmd-modules-0.6.70+ds/zip/ZipArchive/Makefile
+@@ -23,6 +23,9 @@ ifdef INTERNAL_BZIP2
+ CFLAGS += -D ZIP_ARCHIVE_BZIP2_INTERNAL
+ endif
+ 
++# Avoid embedding build path
++CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
++
+ ZIPARCHLIB = libziparch.a
+ 
+ ZIPPIELOCATION = ../Zippie/
diff -Nru tuxcmd-modules-0.6.70+ds/debian/patches/series 
tuxcmd-modules-0.6.70+ds/debian/patches/series
--- tuxcmd-modules-0.6.70+ds/debian/patches/series  2013-05-10 
21:00:35.0 +0100
+++ tuxcmd-modules-0.6.70+ds/debian/patches/series  2022-11-17 
17:15:30.0 +
@@ -2,3 +2,4 @@
 Fix-FTBFS-because-removal-of-ARCHIVE_LIBRARY_VERSION.patch
 glib-single-include.patch
 fix-FTBFS-with-gcc-4.7.patch
+reproducible-build.patch

Bug#1024334: nano: New upstream version: 7.0 (15 Nov 2022)

[Andrew Chadwick]

Package: nano
Version: 6.4-1
Severity: wishlist
X-Debbugs-Cc: a.t.chadw...@gmail.com

Dear Maintainer,

Version 7.0 of nano is now available from its upstream. Please could the 
Debian repositories be updated with it, when you have a chance?

* https://www.nano-editor.org/download.php
* https://lists.gnu.org/archive/html/info-gnu/2022-11/msg5.html
* https://qa.debian.org/cgi-bin/watch?pkg=nano


many thanks,
Andrew

Bug#1024333: gambc: Can't import srfi-1 in gsi

[Tero Isannainen]

Package: gambc
Version: 4.9.3-1.2
Severity: important
X-Debbugs-Cc: tisan...@yahoo.com

Dear Maintainer,

I'm not able to use the libraries with gsi. I tried gsi, but the problem
is probably generic.

I start gsi by:

shell> gsi

I get the regular "welcome" message and a prompt:

Gambit v4.9.3

> _

Then I try the module import:

> (import (srfi 1))

and I get:

*** ERROR IN (console)@1.2 -- Unbound variable: import

This is not expected. The "srfi-1" library should be build-in.

If I compile Gambit from source, I get the expected behavior and I'm
able to do the import.

Best regards,
  Tero


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/32 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 gambc depends on:
ii  libc6   2.33-7
ii  libgambit4  4.9.3-1.2
ii  libgambit4-dev  4.9.3-1.2

Versions of packages gambc recommends:
ii  gambc-doc  4.9.3-1.2

gambc suggests no packages.

-- no debconf information

Bug#1024332: linux-image-6.0.8-1-amd64: Audio fails to start

[madtibo]

Package: src:linux
Version: 6.0.8-1
Followup-For: Bug #1022558

Just experienced the same problem on a Thinkpad T14 Gen1 AMD.

I found a way to get my sound back using the following commands:

sudo modprobe -r snd_rn_pci_acp3x
systemctl --user restart pulseaudio
sudo modprobe snd_rn_pci_acp3x

(found here: https://askubuntu.com/a/1292143/390010)


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-4-amd64 root=/dev/mapper/almaren--vg-root ro quiet

** Not tainted

** Kernel log:
[ 6016.484585] usb 6-2: Manufacturer: PixArt
[ 6016.521543] hid: raw HID events driver (C) Jiri Kosina
[ 6016.534459] usbcore: registered new interface driver usbhid
[ 6016.534467] usbhid: USB HID core driver
[ 6016.540572] input: PixArt MSI GM08 OpticalMouse as 
/devices/pci:00/:00:08.1/:06:00.4/usb6/6-2/6-2:1.0/0003:0DB0:0D08.0001/input/input19
[ 6016.540695] hid-generic 0003:0DB0:0D08.0001: input,hidraw0: USB HID v1.11 
Mouse [PixArt MSI GM08 OpticalMouse] on usb-:06:00.4-2/input0
[ 6016.540826] input: PixArt MSI GM08 OpticalMouse Keyboard as 
/devices/pci:00/:00:08.1/:06:00.4/usb6/6-2/6-2:1.1/0003:0DB0:0D08.0002/input/input21
[ 6016.598581] hid-generic 0003:0DB0:0D08.0002: input,hiddev0,hidraw1: USB HID 
v1.11 Keyboard [PixArt MSI GM08 OpticalMouse] on usb-:06:00.4-2/input1
[ 7053.896051] br-8a1e2a395cdd: port 8(vethc50eac1) entered disabled state
[ 7053.896141] veth51fd414: renamed from eth0
[ 7053.973596] br-8a1e2a395cdd: port 8(vethc50eac1) entered disabled state
[ 7053.974424] device vethc50eac1 left promiscuous mode
[ 7053.974432] br-8a1e2a395cdd: port 8(vethc50eac1) entered disabled state
[ 7060.911818] br-8a1e2a395cdd: port 8(veth9b41a9d) entered blocking state
[ 7060.911827] br-8a1e2a395cdd: port 8(veth9b41a9d) entered disabled state
[ 7060.911980] device veth9b41a9d entered promiscuous mode
[ 7061.186105] eth0: renamed from veth7713ef5
[ 7061.226264] IPv6: ADDRCONF(NETDEV_CHANGE): veth9b41a9d: link becomes ready
[ 7061.226377] br-8a1e2a395cdd: port 8(veth9b41a9d) entered blocking state
[ 7061.226386] br-8a1e2a395cdd: port 8(veth9b41a9d) entered forwarding state
[ 7415.226330] kauditd_printk_skb: 2 callbacks suppressed
[ 7415.226336] audit: type=1400 audit(1668697680.112:335): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.228254] audit: type=1400 audit(1668697680.112:336): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.230038] audit: type=1400 audit(1668697680.116:337): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.233854] audit: type=1400 audit(1668697680.120:338): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.236415] audit: type=1400 audit(1668697680.120:339): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.241217] audit: type=1400 audit(1668697680.124:340): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.245310] audit: type=1400 audit(1668697680.128:341): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.247778] audit: type=1400 audit(1668697680.132:342): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.249077] audit: type=1400 audit(1668697680.132:343): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 7415.253378] audit: type=1400 audit(1668697680.136:344): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cups-browsed" 
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=1807 comm="cups-browsed" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 8394.989275] br-8a1e2a395cdd: 

Bug#1024329: u-boot: extlinux.conf prompt value is ignored

[Vagrant Cascadian]

On 2022-11-17, Manuel Traut wrote:
> during testing on the imx6 colibri board i recognized
> that the prompt value of extlinux.conf is ignored.
>
> The attached patch fixes the problem.

Could you spell this out in a little more detail exactly what is
missing? Maybe cut-and-paste what it looks like with and without the
patch applied?

I'm also curious why this is noticed with the imx6 colibri board and
presumably not other boards... I have definitely used the
pxeboot/extlinux functionality with many other boards (maybe I'm not
using this specific functionality in this code path, though).


> Can it be added to debian or shall I try to submit
> it upstream first?

Submitting something like this upstream is always a good idea. Feel free
to CC me. I suspect upstream will want more verbosity in the error
description too...

Depending on how that goes, I'll consider applying and/or backporting in
Debian.

Thanks!

live well,
  vagrant

> From: Manuel Traut 
> Date: Thu, 17 Nov 2022 16:38:47 +0100
> Subject: distro/pxe boot: read prompt value from config
>
> Currently the configuration of prompt in extlinux.conf is
> ignored.
>
> Read it from the file, if not given do not fail.
>
> Signed-off-by: Manuel Traut 
> ---
>  boot/pxe_utils.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> index 8133006..a6c56e0 100644
> --- a/boot/pxe_utils.c
> +++ b/boot/pxe_utils.c
> @@ -1359,7 +1359,10 @@ static int parse_pxefile_top(struct pxe_context *ctx, 
> char *p, unsigned long bas
>   break;
>  
>   case T_PROMPT:
> - eol_or_eof();
> + err = parse_integer(, >prompt);
> + // Do not fail if prompt configuration is missing
> +if (err <  0)
> + eol_or_eof();
>   break;
>  
>   case T_EOL:


signature.asc
Description: PGP signature

Bug#1024331: ITP: sway-notification-center -- Notification center for the Sway window manager

[matthias . geiger1024]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Matthias Geiger 
X-Debbugs-Cc: team+swa...@tracker.debian.org
Severity: wishlist

* Package name    : sway-notification-center
  Version : 0.7.2
  Upstream Author : Erik Reider 
* URL : https://github.com/ErikReider/SwayNotificationCenter
* License : GPL-3
  Programming Lang: Vala
  Description : Notification center for the Sway window manager

A notification center for wlroots based WM like Sway. The inital packaging is 
done (see https://salsa.debian.org/werdahias/sway-notification-center). I would 
need a sponsor for this package.

cc-ing swaywm-team:

Please let me know if you'd like this being maintained under your umbrella.
I'd also appreciate it if someone could sponsor my package.

Cheers

Matthias Geiger 

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:
>> Will fix for unstable tomorrow.

Salvatore> Thank you.

>> I'm still trying to understand the practical impact.  Do you
>> think you're going to want to issue a DSA for stable?

Salvatore> We were originally thinking so (and Moritz added krb5 to
Salvatore> the DSA needed list), as at least for 32bit architectures
Salvatore> it might be possible to go beyond denial of service and
Salvatore> potentially leading to remote code execution. But if your
Salvatore> assesment on the issue makes you confident it's not DSA
Salvatore> worthy we can re-evaluate.

I strongly encourage a DSA.
There's the 32-bit issue, but I'm also concerned about what happens if
there is a cross-realm trust.
I think the issue is that with cross-realm trust you may be able to get
the KDC to produce a  PACcontaining out-of-bounds memory  and send it out.
And then if you have a service that can decrypt that PAC, look at that
memory, possibly including tservice keys.
So it may lead to an entire realm compromise.
What I can't entirely tell is whether that's limited to 32-bit
architectures or whether you could potentially have that happen on
64-bit architectures.

Either way that's really bad.


signature.asc
Description: PGP signature

Bug#1014463: podman-toolbox: Toolbox only works with fedora-toolbox:34

[Sam Morris]

Package: podman-toolbox
Version: 0.0.99.3-1
Followup-For: Bug #1014463
X-Debbugs-Cc: s...@robots.org.uk

I think the log messages are a red herring and the underlying issue is
that the toolbox binary is not able to run inside the container.

Toolbox appears to work by bind-mounting /usr/bin/toolbox into the
container. 'toolbox init-container' is set as the entry point, and it's
_this_ command that's failing to start; but the output isn't shown by
toolbox and you get the generic 'invalid entry point PID of container'
error message instead.

$ toolbox create -i quay.io/centos/centos:stream8
Created container: centos-stream8
Enter with: toolbox enter centos-stream8

$ podman inspect centos-stream8 | jq '.[].ImageName'
"quay.io/centos/centos:stream8"

$ podman inspect centos-stream8 | jq '.[].Config.Cmd' -c

["toolbox","--log-level","debug","init-container","--gid","876099160","--home","/home/sam","--shell","/bin/bash","--uid","1423121","--user","sam","--monitor-host"]

$ podman start --attach centos-stream8
toolbox: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by 
toolbox)

$ podman unshare

# podman mount centos-stream8

/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged

# grep ^NAME= 
/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged/etc/os-release
 
NAME="CentOS Stream"

# ldd 
/home/sam/.local/share/containers/storage/overlay/02976304f367a933a73eb3590c79acea57dc62e47f2642df560237190ea669b5/merged/lib64/libc.so.6
[...]
Version definitions:
[...]
28 0x00 0x06969187 GLIBC_2.27
GLIBC_2.26 
29 0x00 0x06969188 GLIBC_2.28
GLIBC_2.27 
30 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.28 
[...]

# exit
exit

I'm not seeing an easy way to fix this... if toolbox is built against
unstable then it's often going to pull in glibc symbols that are newer
than the container images that it tries to run.

In this case it's only a single symbol that is used from GLIBC_2.32.

$ objdump -T /usr/bin/toolbox | fgrep GLIBC_2.32
  DF *UND*   (GLIBC_2.32) 
pthread_sigmask


According to

this is fixed by , which
was closed a year ago. Maybe the libc-wrappers.a static library that
provides this symbol isn't being built by Debian for some reason...

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages podman-toolbox depends on:
ii  flatpak  1.10.7-0+deb11u1
ii  libc62.36-4
ii  podman   4.2.0+ds1-3
ii  uidmap   1:4.8.1-1

Versions of packages podman-toolbox recommends:
ii  bash-completion  1:2.11-2

podman-toolbox suggests no packages.

-- no debconf information

Bug#1024093: pipewire: Upgrade to pipewire 0.3.60-1 breaks sound

[Dylan Aïssi]

Hi Chris,

Le jeu. 17 nov. 2022 à 17:21, Chris Nospam  a écrit :
>
> As you have suggested, I have made an entry to the upstream bug report that I 
> am probably also affected, although the issue seems to be already closed.
>

Thanks!

I received the notification from the upstream bug while I was
preparing a patched version of the package :-).
You should be able to update your package from debian/unstable in the
next few minutes (hours?).

Best,
Dylan

Bug#1024330: vfu compiled without unicode support

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Looks like vfu compiled without unicode support.
Instead of cyrillic symbols it shows some mess.
Please check screenshot attached.

Also attached a patch for fixing this problem. Tested with vfu 4.21.
This patch is very simple so it can be easily adapted to upstream version


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information
Patch for adding UTF-8 support to vfu file manager
--- a/vfu/makefile
+++ b/vfu/makefile
@@ -40,7 +40,7 @@
 AR_1   = $(AR) rv
 RANLIB_1   = $(RANLIB)
 CCFLAGS_1  = -I../vstring -I../vslib -I/usr/include/ncurses -O2 $(CFLAGS) 
$(CPPFLAGS) $(CCDEF)  
-LDFLAGS_1  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncurses $(LDFLAGS) $(LDDEF) 
+LDFLAGS_1  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncursesw $(LDFLAGS) $(LDDEF) 
 DEPFLAGS_1 = 
 ARFLAGS_1  = 
 TARGET_1   = vfu
@@ -226,7 +226,7 @@
 AR_3   = $(AR) rv
 RANLIB_3   = $(RANLIB)
 CCFLAGS_3  = -I../vstring -I../vslib -I/usr/include/ncurses -O0 -g $(CFLAGS) 
$(CPPFLAGS) $(CCDEF)  
-LDFLAGS_3  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncurses -g $(LDFLAGS) $(LDDEF) 
+LDFLAGS_3  = -L../vstring -L../vslib -lvstring -lvslib -lvscon -lpcre 
-lncursesw -g $(LDFLAGS) $(LDDEF) 
 DEPFLAGS_3 = 
 ARFLAGS_3  = 
 TARGET_3   = vfu-debug
--- a/vslib/makefile
+++ b/vslib/makefile
@@ -249,7 +249,7 @@
 AR_4   = $(AR) rv
 RANLIB_4   = $(RANLIB)
 CCFLAGS_4  = -g -I../vstring -I. -I../yascreen -DUSE_YASCREEN -O0 -DTEST 
$(CFLAGS) $(CPPFLAGS) $(CCDEF)  
-LDFLAGS_4  = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncurses 
$(LDFLAGS) $(LDDEF) 
+LDFLAGS_4  = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncursesw 
$(LDFLAGS) $(LDDEF) 
 DEPFLAGS_4 = 
 ARFLAGS_4  = 
 TARGET_4   = test
--- a/vslib/mm.conf
+++ b/vslib/mm.conf
@@ -67,7 +67,7 @@
 AR  = $(AR) rv
 RANLIB  = $(RANLIB)
 CCFLAGS = -g -I../vstring -I. -I../yascreen -DUSE_YASCREEN -O0 -DTEST 
$(CFLAGS) $(CPPFLAGS) $(CCDEF) 
-LDFLAGS = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncurses 
$(LDFLAGS) $(LDDEF)
+LDFLAGS = -g -L../vstring -L. -lvstring -lvslib -lvscon -lpcre -lncursesw 
$(LDFLAGS) $(LDDEF)
 DEPS= libvslib.a libvscon.a
 SRC = t/test.cpp
 

Bug#1024327: gv hangs on any file

[Vincent Lefevre]

On 2022-11-17 17:02:47 +0100, Vincent Lefevre wrote:
> When I try to view any Postscript or PDF file with gv, I get the warning
> 
> Warning: Cannot convert string 
> "-*-Courier-Medium-R-Normal--*-100-*-*-M-*-ISO8859-1" to type FontStruct
> 
> then gv hangs on a blank page, with a throbber.

A "strace -f" shows that gv executes /usr/bin/gs, which fails
with exit status 1:

[...]
1949581 openat(AT_FDCWD, 
"/usr/share/ghostscript/10.00.0/Resource/Init/gs_init.ps", O_RDONLY) = 3
1949581 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=94573, ...}, 
AT_EMPTY_PATH) = 0
1949581 lseek(3, 0, SEEK_CUR)   = 0
1949581 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=94573, ...}, 
AT_EMPTY_PATH) = 0
1949581 lseek(3, 0, SEEK_SET)   = 0
1949581 read(3, "% Copyright (C) 2001-2022 Artifex Software, Inc.\n% All Rights 
Reserved.\n%\n% This software is provided AS-IS with no warranty, either 
express or\n% implied.\n%\n% This software is distributed under license and may 
not be copied,\n% modified or distributed excep"..., 4096) = 4096
1949581 read(3, "IDFALLBACK exch def\n/.bind /bind load def\n\n  /VMDEBUG\n
INITDEBUG {{print mark\nsystemdict /level2dict known\n 
{ .currentglobal dup //false .setglobal vmstatus\n   //true 
.setglobal vmstatus 3 -1 roll pop\n   6"..., 4096) = 4096
1949581 read(3, " by -dOverprint={enable|disable|simulate} \\n\\n) print\n  
% Set the new variable appropriately.\n  /Overprint SimulateOverprint { /enable 
} { /disable } ifelse def\n} if\n\n% Acquire environment 
variables.\ncurrentdict /DEVICE known not\n { (GS_DEVICE) getenv "..., 4096) = 
4096
1949581 read(3, "laycount .delaycount 1 add put\n   }\n   { pop /.bind 
cvx exec\n   }\n  ifelse\n} .bind odef\n} executeonly 
if\n\n.currentglobal //true .setglobal\n/.undefinternalnameslist 10 dict 
def\n.setglobal\n\n% Under normal operation .undefinternalnames sim"..., 4096) 
= 4096
1949581 read(3, "vice pop\ndup //null ne { /BeginPage .knownget } { pop 
//false } ifelse {\n% Stack: ... pagecount proc\n   count 2 
.execn\n% Stack: ... ..???.. oldcount\n   count 1 add exch 
sub { pop } repeat\n} {\n  pop\n} "..., 4096) = 4096
1949581 read(3, "   { /filter .systemvar /undefined signalerror }\n 
 ifelse\n} odef\n% Internal uses of stopped that aren't going to do a 
stop if an error occurs\n% should use .internalstopped to avoid setting 
newerror et al.\n/.internalstopped { //null 1 .s"..., 4096) = 4096
1949581 brk(0x55a88f09f000) = 0x55a88f09f000
1949581 read(3, "rix load  /typecheck signalerror\n  } if\n} 
if\ndup length 6 ne { /setmatrix load  /rangecheck signalerror } if\n   
 dup aload pop .setmatrix pop\n} odef\n\n/.confirmread {\n  //systemdict 
/TTYPAUSE get {\n(/dev/tty) (r) file dup rea"..., 4096) = 4096
1949581 read(3, "r the Level 2 spec even in Level 1.\n/.copydict\t\t% 
  .copydict \n{ dup 3 -1 roll { put dup } 
forall pop } bind def\n/findlibfile {\n  .systemvmlibfile { dup .filename pop 
exch //true } { //false } ifelse\n} odef\n/.growdictlengt"..., 4096) = 4096
1949581 read(3, "ecause we want the file to be\n% reopened if a startjob does a 
restore.\n/.runstdin {\n  { { (%stdin) (r) file cvx } .runexec } execute0\n} 
bind def\n% Define the procedure that the C code uses for running commands\n% 
given on the command line with -c.  We turn "..., 4096) = 4096
1949581 read(3, "ef\n }\nifelse\n$error /position currentfile 
status\n { currentfile { fileposition } //.internalstopped exec { pop 
//null } if\n }\n {\t\t% If this was a scanner error, the file is no 
longer current,\n% but the command holds "..., 4096) = 4096
1949581 read(3, "only flush\n  } ifelse\n  //.printerror_long 
exec\n}\n   ifelse\n   //.clearerror exec flush\n }\n { 
% newerror is //false, test to see if user has set handleerror to a different\n 
  % routine, if so execute it, otherwis"..., 4096) = 4096
1949581 read(3, "[only] procedures.\n/.dict 8 dict dup\nbegin def\n  /.cvp {1 
index exch 1 .writecvp} bind def\n  /.p {1 index exch writestring} bind def\n  
/.p1 {2 index exch writestring} bind def\n  /.p2 {3 index exch writestring} 
bind def\n  /.print\n{ dup type .dict ex"..., 4096) = 4096
1949581 openat(AT_FDCWD, 
"/usr/share/ghostscript/10.00.0/Resource/Init/gs_std_e.ps", O_RDONLY) = 5
1949581 newfstatat(5, "", {st_mode=S_IFREG|0644, st_size=3143, ...}, 
AT_EMPTY_PATH) = 0
1949581 lseek(5, 0, SEEK_CUR)   = 0
1949581 newfstatat(5, "", {st_mode=S_IFREG|0644, st_size=3143, ...}, 
AT_EMPTY_PATH) = 0
1949581 lseek(5, 0, SEEK_SET)   = 0
1949581 read(5, "% Copyright (C) 2001-2021 Artifex Software, Inc.\n% All Rights 
Reserved.\n%\n% This software is provided AS-IS with no warranty, either 
express or\n% implied.\n%\n% This software is distributed 

Bug#1024329: u-boot: extlinux.conf prompt value is ignored

[Manuel Traut]

Source: u-boot
Version: 2021.01+dfsg-5
Severity: normal
Tags: patch
X-Debbugs-Cc: manuel.tr...@mt.com

Hi vagrant,

during testing on the imx6 colibri board i recognized
that the prompt value of extlinux.conf is ignored.

The attached patch fixes the problem.

Can it be added to debian or shall I try to submit
it upstream first?

cu, Manuel
From: Manuel Traut 
Date: Thu, 17 Nov 2022 16:38:47 +0100
Subject: distro/pxe boot: read prompt value from config

Currently the configuration of prompt in extlinux.conf is
ignored.

Read it from the file, if not given do not fail.

Signed-off-by: Manuel Traut 
---
 boot/pxe_utils.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 8133006..a6c56e0 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -1359,7 +1359,10 @@ static int parse_pxefile_top(struct pxe_context *ctx, 
char *p, unsigned long bas
break;
 
case T_PROMPT:
-   eol_or_eof();
+   err = parse_integer(, >prompt);
+   // Do not fail if prompt configuration is missing
+if (err <  0)
+   eol_or_eof();
break;
 
case T_EOL:

Bug#1024093: pipewire: Upgrade to pipewire 0.3.60-1 breaks sound

[Chris Nospam]

Hi Dylan,

thanks for maintaining pipewire and your hint!

Now I did the upgrade on my bare metal installation and there the problem does 
not show up (in contrast to the virtualized one). So it is most likely the 
upstream issue you have mentioned. However, it is unclear/difficult for me how 
to try out the in the upstream issue mentioned "pushed fix" in my vm.
As you have suggested, I have made an entry to the upstream bug report that I 
am probably also affected, although the issue seems to be already closed.

Chris

Bug#1007255: khal: Emits warnings about deprecated localize tz method

[Detlev Zundel]

Package: khal
Version: 1:0.10.4~ds-4
Followup-For: Bug #1007255

So I finally also ran into this problem.  Upstream has a lot of issues around
the timezone warnings, but I especially looked at this one:

https://github.com/pimutils/khal/issues/1092

So it seems upstream has fixed the problem and indeed installing khal via pip
gives me a version 0.10.6.dev105+g5191ee8 running without problems:

dzu@krikkit:/opt/src/git/khal (master)$ pip install
git+https://github.com/pimutils/khal
Defaulting to user installation because normal site-packages is not writeable
Collecting git+https://github.com/pimutils/khal
  Cloning https://github.com/pimutils/khal to /tmp/pip-req-build-sthm81rz
  Running command git clone --filter=blob:none --quiet
https://github.com/pimutils/khal /tmp/pip-req-build-sthm81rz
  Resolved https://github.com/pimutils/khal to commit
5191ee88456b004d1d9d415045d57259ac6c03c8
 []
Successfully built khal
Installing collected packages: khal
Successfully installed khal-0.10.6.dev105+g5191ee8
dzu@krikkit:/opt/src/git/khal (master)$

So very likely an updated Debian package will also solve this problem.


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

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

Versions of packages khal depends on:
ii  python33.10.6-1
ii  python3-atomicwrites   1.4.1-1
ii  python3-click  8.0.3-1
ii  python3-click-log  0.3.2-1
ii  python3-configobj  5.0.6-5
ii  python3-dateutil   2.8.2-1
ii  python3-icalendar  4.0.3-5
ii  python3-packaging  21.3-1.1
ii  python3-pkg-resources  65.5.0-1
ii  python3-tz 2022.6-1
ii  python3-tzlocal4.2-1
ii  python3-urwid  2.1.2-2+b2
ii  python3-xdg0.27-3

Versions of packages khal recommends:
ii  python3-setproctitle  1.3.1-1+b1

Versions of packages khal suggests:
pn  khal-doc  

-- no debconf information

Bug#1024328: IPv6 connectivity broken with 6.0.x. RAs seem to be dropped for the CDC_NCM interface

[Santiago R.R.]

Package: src:linux
Version: 6.0.8-1
Severity: important
Tags: ipv6
Control: Found -1 6.1~rc3-1~exp1

Dear linux maintainers,

The related machine to this bug is connected to the network via a Dell
D6000 USB-C docking station. Since a recent linux-image-amd64 update, it
cannot reach external networks on IPv6. It is able to autoconfigure an
IPv6 address, but it doesn't get any answer to the router sollicitations
messages, so it is not able to configure any default route.

A WiFi interface successfully configures its ip6 route, running on the
same kernel.

The problem didn't exist on 5.x, since 5.9 (when IP6 multicast support
for cdc_ncm was fixed). I've just checked with
linux-image-5.10.0-12-amd64.
And the problem is also present in linux-image-6.1.0-0-amd64 6.1~rc3-1~exp1.

Concerned devices is:

  *-network
   description: Ethernet interface
   physical id: 14
   bus info: usb@2:1.1
   logical name: enxabcdef123456
   serial: ab:cd:ef:12:34:56
   size: 100Mbit/s
   capabilities: ethernet physical
   configuration: autonegotiation=off broadcast=yes driver=cdc_ncm 
driverversion=6.0.0-4-amd64 duplex=half firmware=CDC NCM (SEND ZLP) ip=x.x.x.x 
link=yes multicast=yes port=twisted pair speed=100Mbit/s


Cheers,

 -- S

-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-4-amd64 root=/dev/mapper/bartik--vg-root ro quiet

** Not tainted

** Kernel log:
[   12.633673] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   12.634019] iwlwifi :02:00.0: loaded firmware version 36.ca7b901d.0 
8265-36.ucode op_mode iwlmvm
[   12.672303] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3246: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.672306] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.672308] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   12.672310] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   12.672311] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   12.672312] snd_hda_codec_realtek hdaudioC1D0:  Headset Mic=0x19
[   12.672313] snd_hda_codec_realtek hdaudioC1D0:  Headphone Mic=0x1a
[   12.672314] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   12.704042] intel_rapl_common: Found RAPL domain package
[   12.704045] intel_rapl_common: Found RAPL domain core
[   12.704046] intel_rapl_common: Found RAPL domain uncore
[   12.704048] intel_rapl_common: Found RAPL domain dram
[   12.704049] intel_rapl_common: Found RAPL domain psys
[   12.771464] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[   12.802604] Bluetooth: Core ver 2.22
[   12.802625] NET: Registered PF_BLUETOOTH protocol family
[   12.802626] Bluetooth: HCI device and connection manager initialized
[   12.802629] Bluetooth: HCI socket layer initialized
[   12.802630] Bluetooth: L2CAP socket layer initialized
[   12.802633] Bluetooth: SCO socket layer initialized
[   12.897269] dell_laptop: Using i8042 filter function for receiving events
[   12.919215] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   12.919268] thermal thermal_zone8: failed to read out thermal zone (-61)
[   12.982819] iwlwifi :02:00.0: base HW address: 18:1d:ea:6d:5f:56, OTP 
minor version: 0x0
[   13.061505] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   13.081186] usbcore: registered new interface driver btusb
[   13.082374] Bluetooth: hci0: Firmware revision 0.1 build 19 week 44 2021
[   13.085593] iwlwifi :02:00.0 wlp2s0: renamed from wlan0
[   13.138032] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 
subsystem
[   13.138813] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota 
mode: none.
[   13.138822] ext2 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   13.142725] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota 
mode: none.
[   13.298521] audit: type=1400 audit(1668698064.713:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="firejail-default" pid=686 
comm="apparmor_parser"
[   13.300258] audit: type=1400 audit(1668698064.717:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=688 
comm="apparmor_parser"
[   13.301053] audit: type=1400 audit(1668698064.717:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=690 
comm="apparmor_parser"
[   13.301058] audit: type=1400 audit(1668698064.717:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=690 comm="apparmor_parser"
[   13.303175] audit: type=1400 audit(1668698064.717:6): 

Bug#1024327: gv hangs on any file

[Vincent Lefevre]

Package: gv
Version: 1:3.7.4-2+b1
Severity: grave
Justification: renders package unusable

When I try to view any Postscript or PDF file with gv, I get the warning

Warning: Cannot convert string 
"-*-Courier-Medium-R-Normal--*-100-*-*-M-*-ISO8859-1" to type FontStruct

then gv hangs on a blank page, with a throbber.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 gv depends on:
ii  ghostscript-x  10.0.0~dfsg-6
ii  libc6  2.36-5
ii  libx11-6   2:1.8.1-2
ii  libxinerama1   2:1.1.4-3
ii  libxmu62:1.1.3-3
ii  libxt6 1:1.2.1-1
ii  xaw3dg 1.5+F-1

gv recommends no packages.

gv suggests no packages.

-- no debconf information

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

Bug#1024324: Unable to reproduce

[Yadd]

Control: tags -1 + moreinfo

Hi,

when trying your debian/watch, I got a ../dhcpcd-9.4.1.tar.xz

Could you update your report using `uscan -vv` ?

Bug#1024210: dbus-python: ftbfs on riscv64 due to timeout

[Simon McVittie]

On Thu, 17 Nov 2022 at 22:18:04 +0800, Bo YU wrote:
> > On Wed, 2022-11-16 at 12:23 +0800, Bo YU wrote:
> > > The package has a ftbfs issue on riscv64 due to timeout from tests.

I'd prefer to resolve this by extending the timeout, which is relatively
straightforward in Meson, or by reducing the number of repeats. You
don't need to send an updated patch, I'll deal with this.

> > I guess this happens on every architecture, presumably the problem is
> > the slow build hardware, not the riscv64 hardware?
> 
> It seems that it's currently only failing on riscv64

The problem is just that an arbitrary timeout in the upstream build
system is too short for slower machines. The same test takes about
5 seconds on armel, 18 seconds on alpha, 29 to 30 seconds on riscv64
and 12 to 30 seconds on mips64el, and the arbitrary timeout is 30 seconds,
so riscv64 was just unlucky.

mips64el also timed out after 30 seconds in
https://buildd.debian.org/status/fetch.php?pkg=dbus-python=mips64el=1.3.2-2=1668379900=0
but then succeeded in 12 seconds when it was retried in
https://buildd.debian.org/status/fetch.php?pkg=dbus-python=mips64el=1.3.2-2=1668382124=0
(maybe mipsel-osuosl-04 is faster than mipsel-aql-01).

> For riscv64, I suspect that the package uses dbus-daemon instead of dbus
> to cause the timeout on 1.3.2-2. Before the version, it build
> successfully on riscv64.

The source change in 1.3.2-2 is just coincidence. It's using the same
dbus-run-session(1) and dbus-daemon(1) executables to run its test either
way, and 1.3.2-1+b1 had the same failure on riscv64.

1.3.2-1 and 1.3.0-1 took about 29 seconds on riscv64, so they succeeded
but were very close to also failing.

> > Looking at the bug that this test prevents, it seems that just changing
> > the loop from 100 to 2 would be enough.

I'd prefer to keep enough repetitions to avoid boundary conditions,
but something like 10 would probably be sufficient.

> > Another option might be to have the test provide a progress indicator
> > to the test supervisor, so that as long as the imports are succeeding,
> > the test is able to continue.

That's not how Meson tests work: it would time out after an arbitrary
length of time, however much output the test produced. We just need to
make the arbitrary length of time long enough for the test to pass on
any reasonable machine, or make the number of repetitions shorter so that
the test finishes sooner.

> Ok, Will wait for the maintainer's advices for days and then forward
> this to upstream maybe.

There is no need to contact the upstream, the upstream is also me.

smcv

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Nilesh Patra]

Control: reassign -1 bart-cuda 0.8.00-1
Control: fixed -1 0.8.00-2
Control: close -1

On Thu, Nov 17, 2022 at 05:34:05PM +0200, Adrian Bunk wrote:
> The situation around gcc-11 is less obvious, 
> and gcc-11 usage in nvidia-cuda-toolkit is a separate bug.

OK then, re-assigning and closing.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

On Thu, Nov 17, 2022 at 08:50:39PM +0530, Nilesh Patra wrote:
> On Thu, Nov 17, 2022 at 03:58:42PM +0100, Andreas Beckmann wrote:
> > On 17/11/2022 15.34, Nilesh Patra wrote:
> > > In that case, I am re-assigning this to nvidia-cuda-toolkit since nvcc 
> > > needs to
> > > support gcc-12.
> > 
> > Please tell this $VENDOR.
> > 
> > > There is absolutely nothing that can be done at bart-cuda's end to fix 
> > > this if
> > > only gcc-12 is being released.
> > 
> > Every B-D user of cuda stuff should use B-D: nvidia-cuda-toolkit-gcc (and
> > cuda-gcc/cuda-g++ if needed) and not worry about (or even hardcode) gcc
> > versions.
> 
> I thought I had already uploaded with this change but apparently hadn't. New 
> upload incoming.
> 
> But that said,
> 
> $ apt show nvidia-cuda-toolkit-gcc 2>/dev/null | grep 'Depends'
> Depends: g++-11, gcc-11, nvidia-cuda-toolkit (= 11.6.2-2)
> 
> So this bug is still kind of valid. Please let me know if that's not the case.

This bug is about bart-cuda using gcc-10 (not even 11), which should 
really not be in bookworm.

The situation around gcc-11 is less obvious, 
and gcc-11 usage in nvidia-cuda-toolkit is a separate bug.

> Best,
> Nilesh

cu
Adrian

Bug#1024326: bullseye to bookworm upgrade failure: Could not locate dkms.conf file

[Antoine Beaupre]

Package: zfs-dkms
Version: 2.1.6-3
Severity: serious

I have tried to upgrade to bookworm today and kernel builds fail on
zfs-dkms. It fails with:

dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.

It's odd because zfs 2.0.3 is gone now... The package has been
upgraded at this point... Yet the /var/lib/dkms/zfs/2.0.3 directory
was still around. Removing it fixes the problem:

rm -rf /var/lib/dkms/zfs/2.0.3

Note that I am doing batch upgrades with a special procedure, with
this command:

env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none 
APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \
apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o 
Dpkg::Options::='--force-confold' &&

... which might have cause the old directory to not be removed.

See this for my upgrade procedure:

https://anarc.at/services/upgrades/bookworm/

More of the error log:

Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-6.0.0-4-amd64 (--configure):
 installed linux-image-6.0.0-4-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.0.0-4-amd64 (= 6.0.8-1); however:
  Package linux-image-6.0.0-4-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up linux-headers-6.0.0-4-amd64 (6.0.8-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could 
not locate dkms.conf file.
File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.0.0-4-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.0.0-4-amd64 (--configure):
 installed linux-headers-6.0.0-4-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.0.0-4-amd64 (= 6.0.8-1); 
however:
  Package linux-headers-6.0.0-4-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.0.0-4-amd64
 linux-image-amd64
 linux-headers-6.0.0-4-amd64
 linux-headers-amd64



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.79
pn  dkms   
ii  file   1:5.41-4
ii  libc6-dev [libc-dev]   2.36-4
ii  libpython3-stdlib  3.10.6-1
ii  lsb-release12.0-1
ii  perl   5.36.0-4
ii  python3-distutils  3.10.8-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.0.8-1
pn  zfs-zed 
pn  zfsutils-linux  

Versions of packages zfs-dkms suggests:
ii  debhelper  13.10.1

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Andreas Beckmann]

On 17/11/2022 16.20, Nilesh Patra wrote:

$ apt show nvidia-cuda-toolkit-gcc 2>/dev/null | grep 'Depends'
Depends: g++-11, gcc-11, nvidia-cuda-toolkit (= 11.6.2-2)

So this bug is still kind of valid. Please let me know if that's not the case.


Even 11.8 (unpackaged) does only support gcc-11 ... in case some day 
there is a version supporting gcc-12, I can make the switch centrally.


Andreas

Bug#1022347: cppimport: FTBFS: dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/cppimport_22.08.02-1.diff.gO41k5

[Joshua Peisach]

Hi Lucas,

VCS has 22.08.02-2 which should fix this.

On Sun, 23 Oct 2022 14:59:40 +0200 Lucas Nussbaum  wrote:
> Source: cppimport
> Version: 22.08.02-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> >  debian/rules clean
> > dh clean --with python3 --buildsystem=pybuild
> >dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:240: python3.10 setup.py clean 
> > /usr/lib/python3/dist-packages/setuptools/dist.py:530: UserWarning: 
> > Normalizing '22.08.02' to '22.8.2'
> >   warnings.warn(tmpl.format(**locals()))
> > running clean
> > removing '/<>/.pybuild/cpython3_3.10_cppimport/build' (and 
> > everything under it)
> > 'build/bdist.linux-x86_64' does not exist -- can't clean it
> > 'build/scripts-3.10' does not exist -- can't clean it
> >dh_autoreconf_clean -O--buildsystem=pybuild
> >dh_clean -O--buildsystem=pybuild
> >  dpkg-source -b .
> > dpkg-source: info: using options from 
> > cppimport-22.08.02/debian/source/options: 
> > --extend-diff-ignore=^[^/]*[.]egg-info/
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building cppimport using existing 
> > ./cppimport_22.08.02.orig.tar.gz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: local changes detected, the modified files are:
> >  cppimport-22.08.02/cppimport/_version.py
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/cppimport_22.08.02-1.diff.gO41k5
> > dpkg-source: info: Hint: make sure the version in debian/changelog matches 
> > the unpacked source tree
> > dpkg-source: info: you can integrate the local changes with dpkg-source 
> > --commit
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
> > 
> > Build finished at 2022-10-23T07:40:14Z
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2022/10/23/cppimport_22.08.02-1_unstable.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221023;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221023=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 
> 

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Christoph Anton Mitterer]

On Thu, 2022-11-17 at 06:51 +0100, Jonas Smedegaard wrote:
> This has already been discussed upstream

Ah ok... 

> upstream nowadays mention
> in their documentation that several distros name it "git-delta".

I had seen that, but it rather seems like a "some distros do that" -
not like a "we call ourselfs that".


> The executable will be named "delta" as that name is vacant (for now
> -
> let's see when package is actually ready for upload into Debian).

My main point was anyway mostly that it seems to be a wonderful tool -
not only for git - and it could be that people just oversee that it
also works for diff/grep.


Cheers,
Chris.

Bug#1024325: RFS: game-music-emu/0.6.3-4 [ITA] -- Playback library for video game music files - development files

[Ileana Dumitrescu]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "game-music-emu":

 * Package name : game-music-emu
   Version  : 0.6.3-4
   Upstream contact : Shay Green 
 * URL  : https://bitbucket.org/mpyne/game-music-emu/wiki/Home
 * License  : LGPL-2.1+, MIT
 * Vcs  : [fill in URL of packaging vcs]
   Section  : sound

The source builds the following binary packages:

  libgme0 - Playback library for video game music files - shared library
  libgme-dev - Playback library for video game music files - development files

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

  https://mentors.debian.net/package/game-music-emu/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/game-music-emu/game-music-emu_0.6.3-4.dsc

Changes since the last upload:

 game-music-emu (0.6.3-4) unstable; urgency=medium
 .
   * debian/control:
 + Adopt package (Closes: #1018069)
 + Update debhelper, debhelper-compat version to 13
 + Add Rules-Requires-Root line
 + Bump Standards-Version to 4.6.1
   * debian/copyright: Update to dep5 format
   * debian/libgme0.symbols: Removed lines from diff output

There is currently no VCS repository for this package, so I created
one at https://salsa.debian.org/ildumi95/game-music-emu/ which can be
moved to another location after it is sponsored.

Regards,
-- 
  Ileana Dumitrescu

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Nilesh Patra]

On Thu, Nov 17, 2022 at 03:58:42PM +0100, Andreas Beckmann wrote:
> On 17/11/2022 15.34, Nilesh Patra wrote:
> > In that case, I am re-assigning this to nvidia-cuda-toolkit since nvcc 
> > needs to
> > support gcc-12.
> 
> Please tell this $VENDOR.
> 
> > There is absolutely nothing that can be done at bart-cuda's end to fix this 
> > if
> > only gcc-12 is being released.
> 
> Every B-D user of cuda stuff should use B-D: nvidia-cuda-toolkit-gcc (and
> cuda-gcc/cuda-g++ if needed) and not worry about (or even hardcode) gcc
> versions.

I thought I had already uploaded with this change but apparently hadn't. New 
upload incoming.

But that said,

$ apt show nvidia-cuda-toolkit-gcc 2>/dev/null | grep 'Depends'
Depends: g++-11, gcc-11, nvidia-cuda-toolkit (= 11.6.2-2)

So this bug is still kind of valid. Please let me know if that's not the case.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Andreas Beckmann]

On 17/11/2022 15.34, Nilesh Patra wrote:

In that case, I am re-assigning this to nvidia-cuda-toolkit since nvcc needs to
support gcc-12.


Please tell this $VENDOR.


There is absolutely nothing that can be done at bart-cuda's end to fix this if
only gcc-12 is being released.


Every B-D user of cuda stuff should use B-D: nvidia-cuda-toolkit-gcc 
(and cuda-gcc/cuda-g++ if needed) and not worry about (or even hardcode) 
gcc versions.



Andreas

Bug#1024324: uscan: Git mode produces tar.xz instead of expected orig.tar.xz

[Martin-Éric Racine]

Package: devscripts
Version: 2.22.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

version=4
opts="mode=git,pgpmode=gittag" \
https://github.com/NetworkConfiguration/dhcpcd.git refs/tags/dhcpcd-([\d\.]+) \
debian uupdate --no-symlink

uscan --verbose produces the following:
[...]
uscan info: Looking at $base = 
https://github.com/NetworkConfiguration/dhcpcd.git with
$filepattern = refs/tags/dhcpcd-([\d\.]+) found
$newfile = refs/tags/dhcpcd-9.4.1
$newversion  = 9.4.1
$lastversion = 7.1.0
uscan info: Upstream URL(+tag) to download is identified as
https://github.com/NetworkConfiguration/dhcpcd.git refs/tags/dhcpcd-9.4.1
uscan info: Filename (filenamemangled) for downloaded file: dhcpcd5-9.4.1.tar.xz
uscan: Newest version of dhcpcd5 on remote site is 9.4.1, local version is 7.1.0
uscan:  => Newer package available from:
=> https://github.com/NetworkConfiguration/dhcpcd.git 
refs/tags/dhcpcd-9.4.1
uscan info: Downloading upstream package: dhcpcd-9.4.1
Cloning into bare repository '../dhcpcd5-temporary.145920.git'...
remote: Enumerating objects: 150, done.
remote: Counting objects: 100% (150/150), done.
remote: Compressing objects: 100% (136/136), done.
remote: Total 150 (delta 30), reused 70 (delta 12), pack-reused 0
Receiving objects: 100% (150/150), 410.66 KiB | 4.03 MiB/s, done.
Resolving deltas: 100% (30/30), done.
uscan info: Successfully downloaded upstream package: dhcpcd-9.4.1
uscan warn: No keyring file, skipping gpg verification
uscan info: Scan finished

$ dir ../dhcpcd*tar*
dhcpcd5_7.1.0-2.debian.tar.xz  dhcpcd5_7.1.0.orig.tar.gz  dhcpcd5-9.4.1.tar.xz

- -- Package-specific info:

- --- /etc/devscripts.conf ---
Empty.

- --- ~/.devscripts ---
DEBSIGN_KEYID=C89002C77A8BEC6A4E6D7390AE1F8277C4B4D7B6

- -- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.9
ii  fakeroot  1.30.1-1
ii  file  1:5.41-4
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-5
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-4
ii  python3   3.10.6-3
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.5.4
ii  curl7.86.0-2
ii  dctrl-tools 2.24-3
pn  debian-keyring  
ii  dput1.1.2
ii  equivs  2.3.1
ii  libdistro-info-perl 1.2
ii  libdpkg-perl1.21.9
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-2
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.16-1
ii  licensecheck3.3.0-1
ii  lintian 2.115.3
ii  man-db  2.11.1-1
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.3.0+nmu1+b1
ii  python3-debian  0.1.48
ii  python3-magic   2:0.4.26-2
ii  python3-requests2.27.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.27-3
ii  strace  5.10-1
ii  unzip   6.0-27
ii  wget1.21.3-1+b1
ii  xz-utils5.2.7-0.1

Versions of packages devscripts suggests:
ii  adequate 0.15.7
ii  at   3.2.5-1+b1
ii  autopkgtest  5.27
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20220412cvs-1
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.10.1
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
ii  

Bug#1018069: O: game-music-emu -- Playback library for video game music files - development files

[Ileana Dumitrescu]

I intend to adopt the package game-music-emu.

Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Bug#987533: geeqie: thumbnails are not loaded automatically

[Andreas Rönnquist]

On Sun, 25 Apr 2021 10:32:13 +0200 Emilian Nowak  wrote:
> Package: geeqie
> Version: 1:1.6-8
> Severity: normal
> X-Debbugs-Cc: emil.no...@gmail.com
> 
> Dear Maintainer,
> 
> 
> 
> When I open geeqie in new directory with images thumbnails are never showed.
> I have to manually "Select All" -> then refresh
> 

Hi

Sorry for not getting back to you earlier. 

Can you reproduce this with the latest geeqie 1:2.0.1-5 in unstable? It
contains changes that affects this behaviour.

Please try to reproduce, and get back to me with info if you can or not
- if you cannot, I'll close this bug.

best and thanks in advance
/Andreas Rönnquist
gus...@debian.org

Bug#1024323: mirror submission for debian.a1.bg

[Alexander Velin]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.a1.bg
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Alexander Velin 
Country: BG Bulgaria
Location: Sofia
Sponsor: A1 https://www.a1.bg
Comment: push from debian.inf.tu-dresden.de




Trace Url: http://debian.a1.bg/debian/project/trace/
Trace Url: http://debian.a1.bg/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.a1.bg/debian/project/trace/debian.a1.bg

Bug#963576: ITP: golang-github-stevenroose-gonfig -- Go package for program configuration

[Anoop MS]

On Wed, 24 Jun 2020 00:35:21 +0200 "Leo Antunes"  wrote:

> 
> Package: wnpp
>  Severity: wishlist
>  Owner: Leo Antunes 
>  
>  * Package name : golang-github-stevenroose-gonfig
>  Version : 0.1.5-1
>  Upstream Author : Steven Roose
>  * URL : https://github.com/stevenroose/gonfig
>  * License : Expat
>  Programming Lang: Go
>  Description : Go package for program configuration
>  
>  gonfig is a configuration library designed using the following
>  principles:
>  - The configuration variables are fully specified and loaded into a
>  struct variable.
>  - You only need one statement to load the configuration fully.
>  - Configuration variables can be retrieved from various sources, in
>  this order of increasing priority:
>  - default values from the struct definition
>  - the value already in the object when passed into Load()
>  - config file in either YAML, TOML, JSON or a custom decoder
>  - environment variables
>  - command line flags
>  
>  Furthermore, it has the following features:
>  - supported types for interpreting:
>  - native Go types: all int, uint, string, bool
>  - types that implement TextUnmarshaler from the "encoding" package
>  - byte slices ([]byte) are interpreted as base64
>  - slices of the above mentioned types
>  - map[string]interface{}
>  - the location of the config file can be passed through command line
>  flags or environment variables
>  - printing help message (and hiding individual flags)
>  
>  This package is needed for #963575
> 
Hi,

I would like to package and maintain this.

Regards,
Anoop

Bug#1023677: Processed: Re: bart-cuda build depends on gcc-10 that should not be in bookworm

[Andreas Beckmann]

Control: reassign -1 src:bart-cuda 0.8.00-1
Control: tag -1 pending

That is already fixed in bart-cuda's git repository.

Andreas