Bug#977276: gnucobol FTCBFS: abuses AC_CHECK_FILE, uses AC_RUN_IFELSE

[Helmut Grohne]

On Tue, Mar 19, 2024 at 05:18:01AM +0100, Petter Reinholdtsen wrote:
> [Helmut Grohne]
> > The question of whether a particular version is still buggy has a
> > mechanical answer. You may head over to
> > https://tracker.debian.org/gnucobol and then follow the "cross" link in
> > the links section to https://crossqa.debian.net/src/gnucobol where you
> > see that it just works since version 5. Thus closing the bug.
> 
> Based on the feedback I got in https://bugs.debian.org/1067080 >,
> and the result on http://crossqa.debian.net/src/gnucobol3 > and
> http://crossqa.debian.net/src/gnucobol4 >, I suspect it should be
> reassigned to those packages instead.

Not really. My patch is addressing a configure failure, but gnucobol3
and gnucobol4 fail via help2man, which comes much after configure. So my
patch very likely is already upstreamed or no longer applicable in some
other way.

help2man is a more annoying issue and there really is no good solution
as running the tool for extracting the manual page is the thing we
cannot do. Options:
 * Move manual page to an Arch:all package (and skip generating it at
   arch-only build time).
 * Generate manual page at upload time and include it in the .dsc,
   rebuild it during native builds only.
 * Use something other than help2man.
 * When cross compiling, skip manual pages (breaks reproducibility).

None of these is particularly attractive, so opportunistically working
on this without a practical need (as opposed to QA fixing lingering
problems) does not seem warranted to me.

Helmut

Bug#1067127: RFS: emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake sources

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-cmake-mode":

 * Package name : emacs-cmake-mode
   Version  : 3.28.3+ds-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://cmake.org
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-cmake-mode
   Section  : editors

The source builds the following binary packages:

  elpa-cmake-mode - Emacs major mode for editing CMake sources

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

  https://mentors.debian.net/package/emacs-cmake-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-cmake-mode/emacs-cmake-mode_3.28.3+ds-1.dsc

Changes since the last upload:

 emacs-cmake-mode (3.28.3+ds-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.28.3+ds
   * Add d/upstream/metadata

Regards,
-- 
Xiyue Deng

Bug#1067126: RFS: lighttpd/1.4.75-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.75-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.75-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Thank you.  Glenn

P.S. There is a regression in lighttpd 1.4.74 that is fixed with a patch
in tag lighttpd-1.4.74-3 on salsa.d.o.  Does that need to go through the
release process for the changelog entries to automatically close bugs?
If so, please upload 1.4.74-3 to Unstable, and in a few days 1.4.75-1.
With the time64 migration, everything is stuck in Unstable, anyway.

Note: with lighttpd 1.4.74-3, lighttpd is time64 agnostic and so this
package could safely go to Testing, and will work properly (with 64-bit
time_t) on 32-bit platforms even without the rest of the time64 libs.

Bug#977276: gnucobol FTCBFS: abuses AC_CHECK_FILE, uses AC_RUN_IFELSE

[Petter Reinholdtsen]

[Helmut Grohne]
> The question of whether a particular version is still buggy has a
> mechanical answer. You may head over to
> https://tracker.debian.org/gnucobol and then follow the "cross" link in
> the links section to https://crossqa.debian.net/src/gnucobol where you
> see that it just works since version 5. Thus closing the bug.

Based on the feedback I got in https://bugs.debian.org/1067080 >,
and the result on http://crossqa.debian.net/src/gnucobol3 > and
http://crossqa.debian.net/src/gnucobol4 >, I suspect it should be
reassigned to those packages instead.

And upstreamed, of course. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#1066860: libprelude ftbfs on time_t64 archs

[Wookey]

This package FTBFS on armhf and armel as well:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations -Wbad-function-cast -Wcast-qual 
-Wcast-align -Wnested-externs -Wunused -Wformat -Wformat-security -I./include 
-I.. -I../src/include -I./libprelude-error -I../libmissing -I../libmissing 
-I/usr/include/p11-kit-1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/home/wookey/debian/libprelude-5.2.0=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -c prelude-log.c  -fPIC -DPIC -o .libs/prelude-log.o
prelude-log.c: In function 'do_log_v':
prelude-log.c:51:50: error: incompatible type for argument 1 of 'memmove'
   51 | #  define PRELUDE_VA_COPY(ap1, ap2) memmove ((ap1), (ap2), 
sizeof(va_list))
  |  ^
  |  |
  |  va_list
prelude-log.c:229:9: note: in expansion of macro 'PRELUDE_VA_COPY'
  229 | PRELUDE_VA_COPY(bkp, ap);
  | ^~~
In file included from /usr/include/features.h:490,
 from /usr/include/arm-linux-gnueabihf/sys/types.h:25,
 from ../libmissing/sys/types.h:39,
 from ../libmissing/ftw_.h:20,
 from ./include/libmissing.h:34,
 from prelude-log.c:24:
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:1: note: expected 
'void *' but argument is of type 'va_list'
   34 | __NTH (memmove (void *__dest, const void *__src, size_t __len))
  | ^
prelude-log.c:51:57: error: incompatible type for argument 2 of 'memmove'
   51 | #  define PRELUDE_VA_COPY(ap1, ap2) memmove ((ap1), (ap2), 
sizeof(va_list))
  | ^
  | |
  | va_list
prelude-log.c:229:9: note: in expansion of macro 'PRELUDE_VA_COPY'
  229 | PRELUDE_VA_COPY(bkp, ap);
  | ^~~
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:1: note: expected 
'const void *' but argument is of type 'va_list'
   34 | __NTH (memmove (void *__dest, const void *__src, size_t __len))
  | ^

There are some warnings too

Build logs:
https://buildd.debian.org/status/fetch.php?pkg=libprelude=armhf=5.2.0-5.3=1709143897=0
https://buildd.debian.org/status/fetch.php?pkg=libprelude=armel=5.2.0-5.3=1710726391=0

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C

[Soren Stoutner]

On Monday, March 18, 2024 2:21:16 PM MST itd wrote:
> > - d/watch / this dsc
> > 
> >   uscan download this:
> > c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1 
> > batsignal_1.8.0.orig.tar.gz>   
> >   your dsc contains:
> > d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b 
> > batsignal_1.8.0.orig.tar.xz>   
> >   when constructing your dsc, please make sure to use the same file as
> >   uscan would produce. (I've verified that the content of both orig files is
> >   identical)
> Ouch, sorry about that.  If I understand diffoscope correctly it's
> indeed only the timestamps that differ.  d/watch's version uses the date
> of the upstream repo's 1.8.0 tag.  My version, created via gbp, uses the
> date of my repo's upstream/1.8.0 tag.  I'll try to figure out how to
> solve this.

Without knowing for certain, I would suspect that the problem is that gbp is 
repacking your 
orig.tar as an .xz (the upstream is .gz).  That is fine if a repack is 
intended, but in that case 
the file name should be something more like batsignal_1.8.0+dfsg.orig.tar.xz or 
batsignal_1.8.0+ds.orig.tar.xz.

If you do intend to repackage the upstream tarball you should indicate it in 
the package 
version (+dfsg for upstream tarballs that need non-free components removed and 
+ds for 
tarballs that have things removed for reasons like size).

https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.
2BIB0_in_the_version_string_mean.3F[1]

If you don’t intend to repackage the upstream tarball you probably need to 
modify your 
configuration to not do so.

-- 
Soren Stoutner
so...@debian.org


[1] 
https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F


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

Bug#1066959: sysdig: wrong runtime dependency on old falcosecurity binary

[Dima Kogan]

Gianfranco Costamagna  writes:

> Hello, for some reasons sysdig has an hardcoded runtime dependency on
> libfalcosecurity0, now renamed in libfalcosecurity0t64. You can remove
> it and let debhelper create it via shlibs:Depends automatically

Thank you very much for catching and fixing this. The falco ABIs weren't
obviously stable earlier, but that might be better now, so hopefully we
can get away without a versioned dependency. I'll ask falco upstream
about stability in a bit.

Bug#1067125: RM: consolekit2/experimental -- ROM; t64 transition not needed

[Michael Hudson-Doyle]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: michael.hud...@ubuntu.com

A month or so ago I NMUed consolekit2 1.2.6-3.1~exp1 to experimental,
which ftbfs and turned out to be unnecessary. The package can be
removed.

Cheers,
mwh

Bug#1061493: consolekit: install PAM module and udev files into /usr

[Michael Hudson-Doyle]

On Fri, 15 Mar 2024 at 08:51, Mark Hindley  wrote:

> Control: notfound -1 1.2.6-3
>
> On Wed, Mar 13, 2024 at 10:40:40PM +0100, Andreas Beckmann wrote:
> > Followup-For: Bug #1061493
> > Control: found -1 1.2.6-3.1~exp1
> > Control: severity -1 serious
> > Control: tag -1 ftbfs
> >
> > This change causes consolekit2 to to FTBFS in experimental:
>
> Indeed. As it was an NMU, I think the etiquette is for the NMUer to fix.
>

Apologies for the disruption.


> In sid consolekit2 still builds cleanly. Therefore, marking notfound there.



> Michael, perhaps you would fix your NMU, or provide a better patch?
>

I thought I had uploaded a fix for this but in any case it was determined
that consolekit2 did not need to be part of the transition so the package
can be removed from experimental. I'll file a removal request in a moment,
or you can just upload over it.

Cheers,
mwh

Bug#1067124: ftp.debian.org: LTS package upload of pdns-recursor 4.1.11-1+deb10u2 REJECTED

[Daniel Leidert]

Package: ftp.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I tried to upload pdns-recursor_4.1.11-1+deb10u2 to buster-security as part of
LTS, but it failed with:

pdns-recursor_4.1.11-1+deb10u2_amd64.deb: Built-Using refers to non-existing 
source package publicsuffix (= 20220811.1734-0+deb10u1)

Please inject the required source package onto security-master.

Regards, Daniel

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmX4zdoACgkQS80FZ8KW
0F3DYBAAnaPAergxP6wrHUb4dJsD61GYRtXZO60LIAcalTxZsmT6zTr0mP+1vtVt
RIkqFlXB+Pte31lcwMQsuILpCZslTYk43kL9MqB5qEK2bt56gJuMGtDx9e5zfbhq
UWCIgBefKSrnCr1ZksIqD12zUN7/wpxsX/unUpRdyx8N/4kRvjM2bUUAhjheNf4V
U702oQ0ugtsEU/E/kpJXls/P1PfVpWzzs21D2GGblRO/ynnQr8dRtK/1bSZdIx04
nGrCVUGZ1U23+SFvLdSkt6Z0s9ACHnBi2FEPdji+2/ZfwX0euHdpcIuyt6y9fa9T
e/BzouaqNyGuq7VJkU1MG/wPBt6IcpNKX4z4gROaSceKG511XNEUIO8amGH4Y8F4
liwhT0MeuupNRpk+WcrH0EVbWtniYq3yek6gbUoAJrJ1vWLgUWjQDr6/jj2X/LOw
+J0ySvPl0GkfphZnflopLVzXMvfpAOlvgxfokSQqw+C0jsspq1P9GF6RJzedR7ZA
+8Qy4w5M9izWpksrSzvot38b42965mgoTRAasG9SXjAcOxQu1T211ukFJTUPlqpT
IghCXg1sC4AA9+lAFP9Yri+JYftflvh47BocKJ9nNghT5NDJAHgdXk6/eqldW+sl
n9ldmYzZOqoVgYU632tefvNx5J0Cuvxu02oIihPgYHCUkE4HYEI=
=9sWI
-END PGP SIGNATURE-

Bug#1067123: ITP: alligator -- kde rss reader that works on mobile and desktop

[Salvo "LtWorf" Tomaselli]

Package: wnpp
Severity: wishlist
Owner: "Salvo \"LtWorf\" Tomaselli" 
X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org

* Package name: alligator
  Version : 24.02
  Upstream Contact: Tobias Fella 
* URL : https://invent.kde.org/network/alligator
* License : GPL
  Programming Lang: C++
  Description : kde rss reader that works on mobile and desktop
It's an RSS reader based on kirigami, so it can work also on small touch 
devices.

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Mon, 18 Mar 2024 at 23:33, Bastian Germann  wrote:

> Hi,
>
> I have updated the salsa repo to build without gnulib.
>

Fantastic, thanks for doing this!

I am a little puzzled, I thought that the idea was to build with Debian
gnulib? I think that could be a simpler patch.

Looking at the patches, nothing seems really a problem though, except that
`quote(q)` should put single quotation marks around its argument. You could
use ASCII apostrophe for this:

#define quote(q) "'" q "'"

-- 
https://rrt.sc3d.org

Bug#898392: fcitx: default cangjie package (fcitx-table-cangjie) does not add input method

[Boyuan Yang]

Control: tags -1 +wontfix +confirmed
X-Debbugs-CC: ryan@gmail.com

On Fri, 11 May 2018 11:20:09 +0800 Ryan Lue  wrote:
> Package: fcitx
> Version: 1:4.2.9.6-2
> Severity: normal
> Tags: l10n
> 
> There are currently four variants of cangjie tables for fcitx:
> 
> * fcitx-table-cangjie
> * fcitx-table-cangjie-big
> * fcitx-table-cangjie-3
> * fcitx-table-cangjie-5
> 
> While the latter three packages add new input methods to the fcitx menu,
> the first one does not.
> 
> I am posting this bug at the suggestion of Boyuan Yang, a “de factor
> contributor/maintainer of fcitx in Debian”.
> 
> https://groups.google.com/d/msg/fcitx/85q7fn-4kZg/5umJZnX7AgAJ
> 
> As a suggestion, perhaps all variants of cangjie could be unified under
> a single fcitx-table-cangjie metapackage?
> 
> Also, it’s not clear to me what the difference between any of these
> variants are. Perhaps some simple documentation belonging to the
> metapackage could help in that regard.

According to fcitx upstream, package fcitx-table-cangjie was disabled
upstream since 2013. The upstream git commit is
https://github.com/fcitx/fcitx/commit/8f95800f7c0b2edde40a4d158e855f5eb94c8635
. As a result, this package shall never be used anymore. Please use other
available cangjie packages.

I have updated the package description for fcitx-table-cangjie to reflect
this fact. A new upload to Debian Sid will be made shortly with updated
package description.

Thanks,
Boyuan Yang


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

Bug#977276: marked as done (gnucobol FTCBFS: abuses AC_CHECK_FILE, uses AC_RUN_IFELSE)

[Thorsten Alteholz]

Hi Helmut,

is there a reason you closed that bug?

  Thorsten

Bug#727656: Status of libpaper fork

[Bastian Germann]

Hi,

I have updated the salsa repo to build without gnulib.
Please check the patches.

Thanks,
Bastian

Bug#1067122: cups-daemon: cupsd ignores job-originating-host-name

[Paul Szabo]

Package: cups-daemon
Version: 2.4.2-3+deb12u5
Severity: normal
Tags: patch

I noticed that the cupsd server ignores (overrides) the value of
job-originating-host-name sent. I get good results with my proposed
patch for this issue, below.

Cheers, Paul
--
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia


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

Kernel: Linux 6.5+pk12.50 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-daemon depends on:
ii  adduser3.134
ii  bc 1.07.1-3+b1
ii  init-system-helpers1.65.2
ii  libavahi-client3   0.8-10
ii  libavahi-common3   0.8-10
ii  libc6  2.36-9+deb12u4
ii  libcups2   2.4.2-3+deb12u5
ii  libdbus-1-31.14.10-1~deb12u1
ii  libgssapi-krb5-2   1.20.1-2+deb12u1
ii  libpam0g   1.5.2-6+deb12u1
ii  libpaper1  1.1.29
ii  libsystemd0252.22-1~deb12u1++psz
ii  lsb-base   11.6
ii  procps 2:4.0.2-3
ii  ssl-cert   1.1.2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
pn  colord
pn  cups-browsed  
pn  ipp-usb   

Versions of packages cups-daemon suggests:
ii  cups   2.4.2-3+deb12u5
ii  cups-bsd   2.4.2-3+deb12u5
ii  cups-client2.4.2-3+deb12u5
ii  cups-common2.4.2-3+deb12u5
ii  cups-filters   1.28.17-3
pn  cups-pdf   
ii  cups-ppdc  2.4.2-3+deb12u5
ii  cups-server-common 2.4.2-3+deb12u5
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  ghostscript10.0.0~dfsg-11+deb12u3
ii  poppler-utils  22.12.0-2+b1
pn  smbclient  
ii  udev   252.22-1~deb12u1

-- no debconf information
--- cups-2.4.2/scheduler/ipp.c.ORIG 2024-03-18 16:35:43.0 +1100
+++ cups-2.4.2/scheduler/ipp.c  2024-03-18 16:38:21.073982871 +1100
@@ -1637,9 +1637,20 @@
 * Request contains a job-originating-host-name attribute; validate it...
 */
 
+   /*
+* PSz 18 Mar 24
+* Override if the value is clearly wrong or impossible, or if
+* the value is "localhost" but relative to some remote machine.
+* Do not override just because we are not talking to localhost;
+* in particular, keep and treasure the value sent to us from
+* some intermediate or proxy server.
+*if (attr->value_tag != IPP_TAG_NAME ||
+*attr->num_values != 1 ||
+*strcmp(con->http->hostname, "localhost"))
+*/
 if (attr->value_tag != IPP_TAG_NAME ||
 attr->num_values != 1 ||
-strcmp(con->http->hostname, "localhost"))
+!strcmp(attr->values[0].string.text, "localhost"))
 {
  /*
   * Can't override the value if we aren't connected via localhost.

Bug#1066092: koko: please enable blhc-recommended build hardening.

[James Addison]

Source: koko
Followup-For: Bug #1066092
X-Debbugs-Cc: marco.matti...@hotmail.it
Control: tags -1 - fixed pending
Control: reassign -1 blhc
Control: severity -1 normal
Control: merge -1 1043522
Control: tags -1 fixed-upstream

Hi Marco,

On Sat, 16 Mar 2024 22:50:05 +0100, Marco wrote:
>  I believe this is not a bug in koko: can you please check the build log 
> against blhc 0.14 (not yet in Debian)? Background is [1].

Thank you!  You're absolutely correct.  I rebuilt koko and ran both blhc 0.13
(from Debian) and also blhc 0.14 (from upstream) against the output of the
dpkg-buildpackage build logs from that, and the results were:

  * blhc 0.13 produced the error messages reported here and 8 as exit code.
  * blhc 0.14 produced no output and 0 as exit code.

Reassigning and merging with bug #1043522 - thanks again.
James

Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C

[itd]

Hi tobi,

Tobias Frost  writes:

> (Policy requires that the "Maintainer" has "their correct name and a working 
> email
> address", see Policy §3.3. I know that there are exceptions, but I'm not
> sure about the conditions they require (for DMs/DDs, at least DAM needs
> to know your name, but I don't know the rules for Debian Contributors.
> Due to that, I will not sponsor this package, but I can certainly review the
> package.)

understood, thanks for the review!

> Inital releases needs an ITP bug. Please file one and add the appropiate
> Closes: # stanca.

Will look into this.

> Let me know your salsa username and I'll make that happen.

My salsa username is: itd

> A short, possibly incomplete review:
> - d/copyright: I suggest to have the same license for debian/* as for
>   upstream, as this eases forwarding patches etc. Though ISC is
>   considered by the FSF to be compatible with the GPL, this is likely
>   fine too to keep it at is is.

Makes sense and works for me.  Updated.

> - d/watch / this dsc
>   uscan download this:
> c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1  
> batsignal_1.8.0.orig.tar.gz
>  
>   your dsc contains:
> d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b  
> batsignal_1.8.0.orig.tar.xz
>
>   when constructing your dsc, please make sure to use the same file as
>   uscan would produce. (I've verified that the content of both orig files is 
> identical)

Ouch, sorry about that.  If I understand diffoscope correctly it's
indeed only the timestamps that differ.  d/watch's version uses the date
of the upstream repo's 1.8.0 tag.  My version, created via gbp, uses the
date of my repo's upstream/1.8.0 tag.  I'll try to figure out how to
solve this.

> Package looks good, otherwise. Make sure to remove the moreinfo tag when
> the above issues are fixed.

Not fixed so not removed.

Thanks again!

Regards
itd

Bug#1067038: RFS: notifymuch/0.1~git20151223.0.9d4aaf5-1 -- Display desktop notifications for unread mail in notmuch database

[itd]

itd  writes:

>  * Package name : notifymuch
>Version  : 0.1~git20151223.0.9d4aaf5-1
>Upstream contact : https://github.com/kspi/notifymuch/
>  * URL  : https://github.com/kspi/notifymuch/
>  * License  : GPL-3
>  * Vcs  : https://salsa.debian.org/itd/notifymuch

Thanks for granting me access to /debian/notifymuch.  I've pushed my
changes there, updated Vcs-* in debian/control, and switched to
upstream's license for debian/ (convinced by the argument in #10670370).
The updated package should be available on mentors.debian.net soon.

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

[Vincent Lefevre]

On 2024-03-18 20:58:02 +0100, Gilles Filippini wrote:
> Vincent Lefevre a écrit le 03/03/2024 à 01:08 :
> > Package: libhdf5-103-1t64
> > Version: 1.10.10+repack-3.1
> > Severity: serious
> > 
> > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64.
> > This makes the upgrade of curl impossible.
> 
> How am I expected to solve this issue? As I understand it a binNMU should
> suffice. Am I right?

I think that the issue has now been fixed on the curl side:

https://salsa.debian.org/debian/curl/-/commit/40bdd3894230d325d382d59684c32d74202eee5c

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

Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

[Dima Kogan]

"Dr. Burkard Lutz"  writes:

> there is no other upstream source except salsa.debian.org
> Is that sufficient?

Hi. This is certainly sufficient, but it raises more questions. These
tools weren't available to the public before this, I'm guessing, and
this is the initial public release?

Most programs in Debian (and every other distro) are separated into the
"upstream" part that contains the program being packaged, and the
"debianization": the packaging logic. While not strictly required, it
would be good to do that here as well. What if somebody finds these
tools, and wants to use them in some other distro? Hosting the sources
on salsa implies that there's something debian-specific in galvani, and
from reading the description, it sounds like there isn't.

So, unless you really feel strongly about doing it this way, I would
suggest that you

- Create a new "galvani" project someplace non-debian-specific (github,
  gitlab, etc...) with a README that tells people how to get the
  software. It can say "please use Debian and 'apt install galvani'" if
  that's what you want to communicate.

- Each release of "galvani" should have a git tag

- The repo on salsa should have the canonical structure used by most
  packages: an "upstream" branch containing the upstream sources from a
  release tarball and a "master" branch containing these sources + the
  debianization. One can debate about the technical pros/cons of doing
  this, but it's the standard, and will make it easier for you and
  others to manage this package.

Look at other packages for examples of how to structure this. You want
to have a debian/watch file that points to your repo; something like
this:

  https://salsa.debian.org/science-team/mrcal/-/blob/master/debian/watch

And you want to use the "uscan" program to read this file, to download
the sources. And you want to use the "gbp import-orig" tool to ingest
new tarballs.

Furthermore, I would encourage you to do this as part of a team. For
instance, the debian-science team:

  https://salsa.debian.org/science-team/

Doing this sends a signal that you are OK with other people helping
maintain this package. Their policies are described here:

  https://wiki.debian.org/Teams/DebianScience

I would suggest that you subscribe to their mailing list, and ask for
help there, if you need it. Or feel free to talk to me further on this
bug.

Bug#1067121: supysonic: flaky autopkgtest including times out

[Paul Gevers]

Source: supysonic
Version: 0.7.6+ds-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails. What's worse, sometimes that failure is due to 
it timing out after 2h47, while a normal run only takes minutes. It 
seems to hang. From a quick inspection, I didn't see this on amd64, but 
it happens on arm64, armel, armhf, i386 (failure but no timeout) ppc64el 
and s390x.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067120: nmu: apache2_2.4.58-1

[Stefan Fritsch]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: apac...@packages.debian.org
Control: affects -1 + src:apache2
User: release.debian@packages.debian.org
Usertags: binnmu

libaprutil1t64 1.6.3-1.1 contains a wrong symbol file, causing a wrong
dependency on libaprutil164 (missing a "t") for packages using the
apr_dbd_init or apr_ldap_init symbols. AFAICS, only apache2 is affected.  

Note that there is already apache2 2.4.58-1+b2 . I am not sure which
version is the correct one in the nmu syntax.

nmu apache2_2.4.58-1 . ANY . unstable . -m "Rebuild with fixed libaprutil1t64 
for #1067035"
dw apache2_2.4.58-1 . ANY . -m "libaprutil1-dev (>= 1.6.3-2)"

Bug#1067119: nfswatch FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: nfswatch
Version: 4.99.12-1.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nfswatch fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, it cross builds just fine as dh_auto_build passes the
standard substitution. I'm attaching a patch for your convenience.

Helmut
--- nfswatch-4.99.12.orig/Makefile
+++ nfswatch-4.99.12/Makefile
@@ -33,6 +33,7 @@
 INSTALL=install
 MANSUF=	8.gz
 STRIP=	-s
+PKG_CONFIG?= pkg-config
 
 IRIX40CFLAGS=	-DIRIX40 -O -cckr
 IRIX51CFLAGS=	-DIRIX51 -DIRIX40 -O -cckr -D_BSD_SIGNALS
@@ -45,7 +46,7 @@
 SVR4CFLAGS=	-DSVR4 -O
 ULTRIXCFLAGS=	-DULTRIX -O
 DECOSFCFLAGS=	-DDECOSF -O
-LINUXCFLAGS=	-DLINUX -O -Wall -W $(shell pkg-config --cflags libtirpc) $(RPM_OPT_FLAGS)
+LINUXCFLAGS=	-DLINUX -O -Wall -W $(shell $(PKG_CONFIG) --cflags libtirpc) $(RPM_OPT_FLAGS)
 
 IRIX40LIBS=	-lcurses -ltermcap -lsun -lm
 IRIX51LIBS=	-lcurses -ltermcap -lm
@@ -58,7 +59,7 @@
 ULTRIXLIBS=	-lcurses -ltermcap -lm
 #DECOSFLIBS=	-lcurses -ltermcap -lm
 DECOSFLIBS=	-lcurses -ltermcap -lm pfopen.c
-LINUXLIBS=	-lpcap $(shell pkg-config --libs libtirpc) -lncurses -lm
+LINUXLIBS=	-lpcap $(shell $(PKG_CONFIG) --libs libtirpc) -lncurses -lm
 
 CFLAGS=
 LIBS=

Bug#1067118: nmu: hdf5_1.10.10+repack-3.1

[Gilles Filippini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During the ongoing 64 bit time_t transition it seems HDF5 should have been
triggered *after* curl. See #1065331.

As I understand it this should be fixed via the following binNMU request:

nmu hdf5_1.10.10+repack-3.1 . ANY . unstable . -m "binNMU to depend on 
libcurl4t64"

Thanks,
_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmX4o2YACgkQ7+hsbH/+
z4N+SQf/bgkEXassUkLIzCVBI5KnjM1uZXxp7tHgDsbPcx/Y769EZXUFSPLWaA3i
1E2ietil02tCgTa1njciUlsqPL6Din/vUbI7zX+Xjs1DfHVPleY56isPNfEQSVVE
qcmQekQvozFzrs5kxhbpkW7ZG9oiMujKclwjS72K3bSbWdORYzkWVkVA8njyEzfk
5ays8yOyzAq0VJ+vshWy7l0EqTkoX/qLsIsyVUHTf6A6Ii/p5Pr37/bB3x11EsGx
vF8fBHY6EvB77clpWVK6EmjiIMxZpZC0dr6wXS4BepOSAPkjoeUuec1KR/HHeFpQ
FPDFnxXVf++eO5U/c1Q3F8wCQ4YWCw==
=F5hi
-END PGP SIGNATURE-

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

[Gilles Filippini]

Hi Vincent,

Vincent Lefevre a écrit le 03/03/2024 à 01:08 :

Package: libhdf5-103-1t64
Version: 1.10.10+repack-3.1
Severity: serious

libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64.
This makes the upgrade of curl impossible.


How am I expected to solve this issue? As I understand it a binNMU 
should suffice. Am I right?


Thanks,
_g.



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

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

Versions of packages libhdf5-103-1t64 depends on:
ii  libc6   2.37-15.1
ii  libcurl48.6.0-3
ii  libssl3t64  3.1.5-1.1
ii  libsz2  1.1.2-1
ii  zlib1g  1:1.3.dfsg-3.1

libhdf5-103-1t64 recommends no packages.

libhdf5-103-1t64 suggests no packages.

-- no debconf information

Bug#1064095: hdf5: NMU diff for 64-bit time_t transition

[Gilles Filippini]

Hi Steve,

Steve Langasek a écrit le 01/03/2024 à 06:06 :

Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.


I fail to see this change in your patch. Is that wanted?

I've started working on the last HDF5 upstream release (1.14.3 currently 
in experimental). As I read your patch I have nothing to do beside 
adding the versionned build-dependency on dpkg-dev. Am I right?



Thanks!


Thank you!

_g.

Bug#988730: CVE-2017-18641

[Salvatore Bonaccorso]

Hi Mathias,

On Sun, Mar 17, 2024 at 05:41:30PM +, Mathias Gibbens wrote:
> On Sun, 2024-01-28 at 08:44 +0100, Salvatore Bonaccorso wrote:
> > Thanks for the update. Do you know of any plans of making
> > distrobuilder available?
> 
>   distrobuilder is now available in both testing and unstable. I'll be
> reaching out to some of the users of lxc-templates to let them know and
> suggesting that they migrate to using distrobuilder.

Thanks for your update!

Regards,
Salvatore

Bug#1067117: budgie-desktop: Fails to build with mutter >= 45

[Jeremy Bícha]

Source: budgie-desktop
Version: 10.8.2-3
Severity: serious
Tags: ftbfs sid trixie
Control: block -1 by 1040005

budgie-desktop fails to build with mutter 45 (or 46). I have tried to
do what I could to get magpie into Debian as the preferred replacement
for budgie-desktop's mutter dependency but ultimately magpie has not
been accepted into Debian yet.

It feels impractical to continue delaying updating GNOME Shell in
Debian when budgie-desktop has a rather low popcon compared to
gnome-shell. Therefore, I'd like to proceed with the Mutter/GNOME
Shell transition very soon after the 32-bit time_t transition
completes. budgie-desktop would be removed from Testing until it is
buildable and installable again.

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/

[Stefan Fritsch]

Am 18.03.24 um 19:30 schrieb Stefan Fritsch:


Am 13.03.24 um 22:32 schrieb Sebastian Ramacher:

Source: apr-util
Version: 1.6.3-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in 
the past)

X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0


It looks to me like it tried to use a non 64bit time_t libapr1 during 
build, which does not work because libapr1 changes abi with the time_t 
transition. Adding a versioned build-depends should help. I will check 
later.


Unfortunately, apr-util build-deps are uninstallable on armhf/armel 
right now due to postgres not being built for 64bit time_t. So, there is 
no easy way to test this. I will upload anyway.

Bug#1066974: freecad: package got copletely removed from Debian testing

[Amr Ibrahim]

 Ursprüngliche Nachricht 
Von: Kurt Kremitzki 
An: Amr Ibrahim , 1066...@bugs.debian.org
Betreff: Re: Bug#1066974: freecad: package got copletely removed from Debian
testing
Datum: 16.03.2024 16:04:34


> - on armel, it seems FEM workbench tests are failing, but it isn't enough to
> e.g. disable that workbench, because then the failures just pop up elsewhere.
> I've repeated this "disable test, different test segfaults elsewhere" pattern
> about 5 times. It seems like, for some reason, the armel builds are no longer
> viable. It isn't ideal, but FreeCAD is probably not getting much use on the
> arch, so it may be that it ought to be removed from the architecture.


I believe this old 32-bit armel architecture is too weak for 3D CAD and out of
interest of CAD users. For a modern 64-bit ARM-based system I think arm64 is the
way to go these days.

Bug#1067116: ITP: libhyprcursor -- hyprland cursor format, library and utilities

[Alan M Varghese]

Package: wnpp
Severity: wishlist
Owner: Alan M Varghese 
X-Debbugs-Cc: debian-de...@lists.debian.org, a...@digistorm.in

* Package name: libhyprcursor
  Version : 0.1.4
  Upstream Contact: vaxerski  
* URL : https://github.com/hyprwm/hyprcursor
* License : BSD-3-Clause
  Programming Lang: C, C++
  Description : hyprland cursor format, library and utilities

>From the README:
"
XCursor sucks, and we still use it today.
 - Scaling of XCursors is horrible
 - XCursor does not support vector cursors
 - XCursor is ridiculously space-inefficient

Hyprcursor fixes all three. It's an efficient cursor theme format that
doesn't suck as much.

### Notable advantages over XCursor
 - Automatic scaling according to a configurable, per-cursor method.
 - Support for SVG cursors
 - Way more space-efficient. As an example, Bibata-XCursor is 44.1MB, while 
it's 6.6MB in hyprcursor.
"

hyprcursor is a new dependency for hyprland[1].

The package would generate a library and a binary utility to convert
xcursor themes to hyprcursor format. The utility has a runtime
dependency on xcur2png[2], which is also not available in Debian.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[2] https://github.com/eworm-de/xcur2png

Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/

[Stefan Fritsch]

Am 13.03.24 um 22:32 schrieb Sebastian Ramacher:

Source: apr-util
Version: 1.6.3-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0


It looks to me like it tried to use a non 64bit time_t libapr1 during 
build, which does not work because libapr1 changes abi with the time_t 
transition. Adding a versioned build-depends should help. I will check 
later.




testldap:  SUCCESS
testdbd :  SUCCESS
testdate:  SUCCESS
testmemcache:  Error 111 occurred attempting to reach memcached on 
localhost:11211.  Skipping apr_memcache tests...
SUCCESS
testredis   :  Error 111 occurred attempting to reach Redis on 
localhost:6379.  Skipping apr_redis tests...
SUCCESS
testxml :  SUCCESS
testxlate   :  SUCCESS
testrmm :  SUCCESS
testdbm :  BDB1565 DB->put: method not permitted before handle's 
open method
/bin/bash: line 3: 3132384 Segmentation fault  LD_LIBRARY_PATH="`echo 
"../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 
's/::*$//'`" ./$prog -v
Programs failed: testall
make[2]: *** [Makefile:60: check] Error 139

Cheers

Bug#1067081: RFS: emacs-libvterm/0.0.2+git20240102.c3a3a23-1 [Team] -- fully-fledged terminal emulator inside GNU Emacs based on libvterm - module

[Xiyue Deng]

Martin  writes:

> Hi,
>
> I can sponsor this, but would build the package from git.
>
> (Note, that pristine-tar contains the .gz tar file, while the .dsc
> refers to a .xz one. Doesn't matter much.)
>
> Cheers

Thanks a lot, Martin!  I have synced to the latest snapshot so that I
can drop the typo patch and also fixed the inconsistent of tarball in
pristine-tar.  New package also uploaded to mentors[1].  PTAL.  TIA!

[1] https://mentors.debian.net/package/emacs-libvterm/

-- 
Xiyue Deng

Bug#1064939: simple-scan: Please update to 46.0

[Jeremy Bícha]

Control: retitle -1 simple-scan: Please update to 46.0

simple-scan 46.0 has been released

https://gitlab.gnome.org/GNOME/simple-scan/-/blob/46.0/NEWS

Thank you,
Jeremy Bícha

Bug#1064861: Merge Request and upload

[Arthur Diniz]

Raised a merge request in Salsa with that patch.

https://salsa.debian.org/kubernetes-team/packages/kubectx/-/merge_requests/2

Ulises are you moving forward with the upload or I can handle it from here?


Thanks!

Bug#1064027: RFS: mercurial-evolve/11.1.1-1

[Tobias Frost]

can you upload your dsc to mentors?
TIA!


On Thu, 15 Feb 2024 22:46:21 +0100 Georges Racinet
 wrote:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: andrew.shad...@collabora.co.uk, jcris...@debian.org
> 
> Dear uploaders,
> 
> I have pushed a new version 11.1.1-1 of the mercurial-evolve package
to
> https://salsa.debian.org/python-team/packages/mercurial-evolve
> 
> Note that the previous version, 10.5.3, does not work with
> the current Mercurial version (6.6) in unstable.
> 
> Is anyone available to upload it to the archive?
> 
> Thank you so much,
> 
> Cc Andrew, who did the previous uploads, and Julien, who is the
Mercurial
> package maintainer.
> 
> G. Racinet.
> 
> 

Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Burak Gerz]

Hello


Here [1] is a first attempt to package libuio

[1]: https://salsa.debian.org/burakg/libuio


Regards

Burak

Bug#1067115: gross: CVE-2023-52159

[Salvatore Bonaccorso]

Source: gross
Version: 1.0.2-4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gross.

CVE-2023-52159[0]:
| A stack-based buffer overflow vulnerability in gross 0.9.3 through
| 1.x before 1.0.4 allows remote attackers to trigger a denial of
| service (grossd daemon crash) or potentially execute arbitrary code
| in grossd via crafted SMTP transaction parameters that cause an
| incorrect strncat for a log entry.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-52159
https://www.cve.org/CVERecord?id=CVE-2023-52159
[1] 
https://codeberg.org/bizdelnick/gross/wiki/Known-vulnerabilities#cve-2023-52159

Regards,
Salvatore

Bug#1067059: ruby-hdfeos5: FTBFS with gcc-14 (-Werror=implicit-function-declaration)

[Sebastiaan Couwenberg]

Control: tags -1 pending

This is fixed in git with patch that adds the external function definitions.

Youhei, you marked the other patches as forwarded, how did you forward 
those patches upstream? There is no upstream metadata or 
Upstream-Contact which informs us of where to send patches.


Can you share those details and document them in the package?

Kind Regards,

Bas

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

Bug#1066974: freecad: package got copletely removed from Debian testing

[Tobias Frost]

On Sat, Mar 16, 2024 at 10:04:34AM -0500, Kurt Kremitzki wrote:
> The current status of this:
> 
> - the Path workbench has a test which checks string equality on
> generated vs expected G-code for an operation. On the i386 arch only,
> the produced G-code is not what is expected, although it is
> consistent. In a G-code viewer, what is produced is visually
> identical, just with an increased number of arcs of shorter length.
> I've patched this test with a special-case check to use a different
> "expected" string id the arch is i386, and this works, even if not
> elegant; the further yak-shaving needed has been discussed with
> upstream.

I think this is a feasible way forward. 
(I'd also not focus too much on i386, as this architecture is showing
it's age and hardware supporting only i386 must be quite ancient in
2024, especially when doing CAD on it.)
Said that, I think it makes sense to keep it working on a best effort
basis, but this should not be a blocker for the other archs.
IOW, I think your patch/approach is more than appropiate.

> 
> - on armel, it seems FEM workbench tests are failing, but it isn't
> enough to e.g. disable that workbench, because then the failures just
> pop up elsewhere. I've repeated this "disable test, different test
> segfaults elsewhere" pattern about 5 times. It seems like, for some
> reason, the armel builds are no longer viable. It isn't ideal, but
> FreeCAD is probably not getting much use on the arch, so it may be
> that it ought to be removed from the architecture.

I agree, armel is not the target audience for a CAD system, it is like
i386, just worse by magintudes in terms of perfomance/usablity.

> I would appreciate some feedback on these 2 items. I could do an
> upload with a patch for the Path test and request armel removal if
> nobody has any better suggestions or reservations about this approach.

IMHO a sane solution. Thanks for caring!

> Thanks,
> Kurt


signature.asc
Description: PGP signature

Bug#1067113: libhiredis-dev: cmake config incompatible with upstream

[Chris Lamb]

[adding  to CC]

Sylvain Joubert wrote:

> The CMake config provided by this package seems incompatible with the upstream
> one.
> Currently, the package provides data under the name "Hiredis" with a capital
> leading H, while upstream is named "hiredis" lowercase
> ".../cmake/Hiredis/HiredisConfig{,Version}.cmake" vs.
> ".../cmake/hiredis/hiredis-config.cmake" (see
> https://github.com/redis/hiredis/blob/master/CMakeLists.txt#L137-L150)
>
> This means that a client CMake project can't switch transparently between an
> Debian install and a custom cmake build of hiredis.
>
> Could you rename the cmake configuration provided by Debian to match upstream,
> or even build hiredis using the official CMake support?

I'm looping in Tom Lee here as they added the CMake changes back in
2018 (via #784768?).

Yes, perhaps these changes are simply not needed anymore. However, I
don't quite understand the changes made in 07_cmake.patch completely
to make a determination on my own. I think I might know how to fix
this (eg. change the definition of CMAKE_PATH and then update
libhiredis-dev.install to match?), but, again, I'm just not familiar
enough.

No objection to solving this issue in a general sense, though. :)


Regards,

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

Bug#1067114: ITP: python-sphinx-codeautolink -- Automatic links from code examples to reference documentation

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: python-sphinx-codeautolink -- Automatic links from code examples 
to reference documentation
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name : python-sphinx-codeautolink
Version : 0.15.0
Upstream Author : Copyright: (c) 2021-2023 Felix Hildén 
* URL : https://sphinx-codeautolink.rtfd.io/
* License : expat
Programming Lang: Python
Description : Automatic links from code examples to reference documentation
This plugin for the Sphinx documenation tool makes code examples clickable by
inserting links from individual code elements to the corresponding reference
documentation. We aim for a minimal setup assuming your examples are already
valid Python.
.
For a live demo, see our online documentation on
`Read The Docs `_.

Remark: This package is maintained by Debian Python Team at
https://salsa.debian.org/python-team/packages/python-sphinx-codeautolink

--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067054: Re: Bug#1067054: Debian 12 - Copy files on USB 3

[pham...@bluewin.ch]

>What you're describing sounds just as likely to be a hardware problem
>with the enclosure, to be honest. Does it work 100% reliably elsewhere?

Hello Steve,

I recently spoke on a forum with a user who also had a USB C box from another 
brand and who had the same problem as mine...

So the problem doesn't seem to only concern me.

Under Windows 11 there is no problem, everything works perfectly. The transfer 
takes place everywhere at 400 MB/sec. So it's not a hardware problem contrary 
to what you say.

I will soon receive a 2.5 inch USB C drive enclosure from another brand. I can 
do tests again if you want but the result will be the same, that's for sure!!

For my part, I more than strongly suspect a teething problem with the USB 3 
type C driver under Linux...

Regard.

Philippe

Bug#1060736: Would you agree with swapping Maintainer and Uploaders in eric?

[Andreas Tille]

Control: tags -1 pending
thanks

Hi again,

since I know you from Debian Science team and you are usually
comfortable with setting Maintainer to the team I've done so
besides fixing the bug and polished the package a bit.  I also
upgraded to the latest upstream version.

Please confirm that this all is OK before I upload (feel free
to upload yourself which is perfectly fine for me).

Kind regards
Andreas.

Am Mon, Mar 11, 2024 at 10:13:50PM +0100 schrieb Andreas Tille:
> Hi Gudjon,
> 
> in case you agree with the suggested change of policy discussed on the
> debian-python mailing list[1] would you agree to set DPT as maintainer?
> If yes, I'd volunteer to do this, fix bug #1065855 and #1060736.
> 
> Kind regards and thanks for working on this package
> Andreas.
> 
> 
> [1] https://lists.debian.org/debian-python/2024/02/msg00052.html
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#1039809: tagging 1039809

[James Valleroy]

tags 1039809 + pending
thanks

I applied a change to support phpunit 11:
https://salsa.debian.org/php-team/pear/php-nikic-fast-route/-/commit/121a9e9e4fcacbcfdbf745b43d5656cfe049373a

It also builds ok with phpunit 9.6.17, however some of the tests are 
skipped with the changes for phpunit 11 applied.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067113: libhiredis-dev: cmake config incompatible with upstream

[Sylvain Joubert]

Package: libhiredis-dev
Version: 1.2.0-6
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

The CMake config provided by this package seems incompatible with the upstream
one.
Currently, the package provides data under the name "Hiredis" with a capital
leading H, while upstream is named "hiredis" lowercase
".../cmake/Hiredis/HiredisConfig{,Version}.cmake" vs.
".../cmake/hiredis/hiredis-config.cmake" (see
https://github.com/redis/hiredis/blob/master/CMakeLists.txt#L137-L150)

This means that a client CMake project can't switch transparently between an
Debian install and a custom cmake build of hiredis.

Could you rename the cmake configuration provided by Debian to match upstream,
or even build hiredis using the official CMake support?

Thanks.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libhiredis-dev depends on:
ii  libhiredis1.1.0  1.2.0-6

libhiredis-dev recommends no packages.

libhiredis-dev suggests no packages.

-- no debconf information

Bug#1067112: fangfrisch: missing dependency on clamdscan

[Joost van Baal-Ilić]

Package: fangfrisch
Version: 1.9.0-1
Severity: normal

Hi,

Thanks for maintaining fangfrisch!

When running

 clamav@donmel:~$ fangfrisch --conf /etc/fangfrisch.conf initdb

, in order to get fangfrisch properly setup, the fangfrisch software fails with:

 Mar 18 16:01:29 donmel fangfrisch[143542]: ERROR: /bin/sh: 1: clamdscan: not 
found

.  Please add clamdscan to fangfrisch's debian/control "Depends: ": that should
fix this.

Thanks, Bye,

Joost

Bug#1055771: sysvinit script corrections

[Frank Lienhard]

On 17.03.2024 20:24, Jonas Smedegaard wrote:

It would be helful if you could double-check using newest package and
with*only*  the init script change, leaving all other settings at their
defaults and with no prior Radicale-related files created on the system
- and then check if the logging works as intended.

I'm not totally certain what you mean by that.
Here is what I think. Using a fresh install, install radicale and only 
add the logging part to the initscript or the $dir part, too?


Without any changes in /etc/radicale. (tha is the 5-minute install from 
the radicale website).


greets
Frank

Bug#1067111: python3-pysaml2: Python source files missing

[Michael Fladischer]

Package: python3-pysaml2
Version: 7.4.2-1
Severity: serious
Justification: 10

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

starting with 7.4.2-1 all the Python source files for saml2 package are missing
in python3-pysaml2 binary package.

Regards,
Michael


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

Kernel: Linux 5.10.110-rockchip-rk3588 (SMP w/8 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pysaml2 depends on:
ii  python3  3.11.8-1
ii  python3-cffi 1.16.0-2
ii  python3-cffi-backend 1.16.0-2+b1
ii  python3-cryptography 41.0.7-5
ii  python3-dateutil 2.8.2-3
ii  python3-defusedxml   0.7.1-2
ii  python3-importlib-resources  6.0.1-1
ii  python3-mako 1.3.2-1
ii  python3-memcache 1.59-8
ii  python3-pyasn1   0.4.8-4
ii  python3-repoze.who   2.2-4
ii  python3-responses0.24.1-1
ii  python3-setuptools   68.1.2-2
ii  python3-xmlschema1.10.0-7
ii  xmlsec1  1.2.39-5+b1

python3-pysaml2 recommends no packages.

python3-pysaml2 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmX4VFsbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqtJQH/AsZok55cBnZ1Mc5u1+b
pkmEj7IRvQBCPeiWmxF/WGmZTCJJKhzjb7jlWLqmLiI9gMg5R/QhgFXyVVXfbxWR
8pdh+fhYbDr0rp5uTP37R/8Agup0wMS5uJqVSTKEuGcXEb/n6UDoOqcnfGAGutN8
HJ/0U2ZbvAAUKYhqjsMaDD2pR/VFmHQozbF6tyvpUFmcg/mW0UPQBaWMfME7irwD
wvArzATaSMF5ufVe1++BKF1h4bpysO6/YlhFWNbbREICJASky7RO5veerveOlMm6
YkJ6gg1nazHqltL/V+cuSGBiChyEuu43ODZN1hgA+HMZyou9rQxFvrD/lMkdSvu+
M1A=
=VOju
-END PGP SIGNATURE-

Bug#1067110: xymon: Upgrade process hangs with zombie in postinst

[Axel Beckert]

Package: xymon
Severity: serious
Version: 4.3.30-2
Tags: pending

Due to a superfluous leftover debconf initialisation in xymon.postinst
not being removed with the cleaning up of old transition code, upgrading
xymon (but not xymon-client) resulted in a hanging upgrade process as
well as in a xymon.postinst zombie process.

A fix is committed locally and I'll upload soon, but it still needs some
more testing how to handle further, but more harmless leftovers from
that incomplete code removal.

Filing this bug mostly due to several transitions (well, mostly t64
transitions) being listed on https://tracker.debian.org/pkg/xymon to
make clear why an upload is currently necessary.

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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#1067109: rustc: Please remove cmake3 from build-depends

[Emanuele Rocca]

Source: rustc
Version: 1.70.0+dfsg1-6
Severity: minor

Hi!

While looking at the rustc build-deps still missing due to the time64
transition, I noticed that rustc build depends on cmake | cmake3. The
latter does not exist, so it should be removed.

Thanks,
  Emanuele

Bug#1036884: transition: time64_t

[Emanuele Rocca]

On 2024-03-13 02:08, Emanuele Rocca wrote:
> When it comes to actually satisfying build-depends properly it seems
> that as of right now the missing ones are libcurl4-gnutls-dev and
> libgit2-dev.

Cargo is now done. With libcurl4-gnutls-dev and libgit2-dev available I
could bootstrap it on armhf/armel, and Fabian later took care of a
source-only upload. We had to drop git from build-depends, not yet
installable on 32bit arm. Without git a (small) minority of tests are
not being run, but that seemed acceptable.

Next up for the rust world is rustc, which is currently blocked on
llvm-16-dev, itself stuck on a cycle between php and postgres.

Bug#1067103: libisoburn1t64: should not depend on libburn4 nor libisofs6 after time_t transition

[Thomas Schmitt]

Hi,

being the one who usually prepares the releases, i am currently standing
in hands-off position until the time_t change is completed.
The package tracker is still complaining bitterly about the current
intermediate state.

Consider to re-open
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062380
  "libisoburn: NMU diff for 64-bit time_t transition"
and/or to contact its submitter.


Have a nice day :)

Thomas

Bug#1065203: Acknowledgement (regression: TypeError: find_username() missing 1 required positional argument: 'ssh_conf')

[Yaroslav Halchenko]

I submitted MR with this fix and overall small refactoring of the code
there to improve functionality at 

https://salsa.debian.org/debian/dput-ng/-/merge_requests/34

Please review/merge/release

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1067108: alien-arena: FTBFS with -Werror=implicit-function-declaration

[Andreas Beckmann]

Source: alien-arena
Version: 7.71.3+dfsg-3
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)

Hi,

alien-arena FTBFS with -Werror=implicit-function-declaration which was
recently enabled by default in dpkg 1.22.6 to support the 64-bit time_t
transition. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

gcc -DHAVE_CONFIG_H -I. -I../config  -DCOR_DATADIR='"/usr/share/alienarena"' 
-I../source -isystem ../source/unix -Wdate-time -D_FORTIFY_SOURCE=2 -fpic -g 
-O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/alien-arena-7.71.3+dfsg=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-fcommon -ffast-math -fno-strict-aliasing -c -o game/libgame_a-g_unlagged.o 
`test -f 'game/g_unlagged.c' || echo './'`game/g_unlagged.c
game/g_unlagged.c: In function 'G_TimeShiftClient':
game/g_unlagged.c:187:25: error: implicit declaration of function 
'Cvar_SetValue' [-Werror=implicit-function-declaration]
  187 | Cvar_SetValue( "g_antilagprojectiles", 0);
  | ^


Andreas

Bug#1067054: Debian 12 - Copy files on USB 3

[Steve McIntyre]

pham...@bluewin.ch wrote:
>
>For complement of information :
>The SSD used is a Samsung 850 Pro 256 GB and the case is a Satechi ST-TCDEM. 
>Write rates were high at the start of the copy (450 MB/sec then dropped before
>the crash to +/- 30 Mb/sec).
> 
> 
> Restoring the disk image with this same SSD but integrated in a Delock USB 3 
> Type A case to a USB A socket on my computer works correctly with a transfer
>rate of 60 to 90 MB/s.
> 
> 
>The same SSD still plugged into the Delock USB 3 Type A box but connected to 
>my machine on a USB C port completes the restoration of the image with a 
>constant
>transfer rate of +/- 41MB/sec.
>Regards.

What you're describing sounds just as likely to be a hardware problem
with the enclosure, to be honest. Does it work 100% reliably elsewhere?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#1067107: After installing debian 12.5 no login possible

[Thomas Schweikle]

Package: Debian installer
Version: As on Debian live-CD/DVD for Debian 12.5
Severity: critical

1. Download debian live-CD/DVD from:
https://cdimage.debian.org/debian-cd/current/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso
or
https://ftp.gwdg.de/debian-cd/12.5.0-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso
2. Boot from this DVD
3. Doubble click on "Install to harddisk"
4. Select to erase a partitioned harddisk
5. Select "German"
6. For User and Passwort enter
Full name: demo Demo
Username: de-de
Password 1st: start123
Password 2nd: start123
7. Click install
8. Wait until the installer finishes and reboots into this newly installed
system
9. Try to login with the credentials given above:
User: de-de
Password: start123

The newly installed system just tells: unknown user or password, user or
password wrong. You wont be able to login.
Having a closer look at the system installed:
- The system language ist set to en_US, instead, as selected to de_DE.
- The keyboard language and layout ist set to en_US, instead, as selected
to de_DE.
- The user given isn't created at all.
- The password isn't entered into /etc/passwd or /etc/shadow.
- Root is created, but does not have a password, while passwordless logins
are prohibited

Conclusion: it is not possible to login to the system. Youl have to hack it
to get access.

-- 
Thomas

Bug#1067106: bullseye-pu: package nvidia-settings/470.239.06-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
As a followup for enabling src:nvidia-graphics-drivers on ppc64el
(to be in sync with sid), we need to enable building the nvidia-settings
binary package for ppc64el, too.
Lets switch to the latest 470.* upstream release at the same time (to be
in sync again with the driver package), this only has some typo
corrections and the version bump as upstream changes.

[ Impact ]
nvidia-driver:ppc64el has unsatisfiable Recomends.

[ Tests ]
Would require ppc64el hardware with nvidia GPU and nvidia driver usage.

[ Risks ]
There are no risky changes to the binary packages that were previously
built.

[ Checklist ]
  [+] *all* changes are documented in the d/changelog
  [+] I reviewed all changes and I approve them
  [+] attach debdiff against the package in (old)stable
  [+] the issue is verified as fixed in unstable

[ Changes ]

nvidia-settings (470.239.06-1) bullseye; urgency=medium

  * New upstream release 470.141.03.
  * Build for ppc64el.
  * Upload to bullseye.

 -- Andreas Beckmann   Mon, 18 Mar 2024 14:38:21 +0100

 debian/changelog  |  8 
 debian/control|  2 +-
 debian/gbp.conf   |  2 +-
 doc/version.mk|  2 +-
 samples/version.mk|  2 +-
 src/libXNVCtrl/version.mk |  2 +-
 src/nvml.h| 41 +
 src/version.mk|  2 +-
 version.mk|  2 +-
 9 files changed, 36 insertions(+), 27 deletions(-)


[ Other info ]
I'm not planning to backport the split of src:libxnvctrl from
src:nvidia-settings to bullseye.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 54f627f..504c78e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+nvidia-settings (470.239.06-1) bullseye; urgency=medium
+
+  * New upstream release 470.141.03.
+  * Build for ppc64el.
+  * Upload to bullseye.
+
+ -- Andreas Beckmann   Mon, 18 Mar 2024 14:38:21 +0100
+
 nvidia-settings (470.141.03-1~deb11u1) bullseye; urgency=medium
 
   * Rebuild for bullseye.
diff --git a/debian/control b/debian/control
index 281c4ff..3d776af 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,7 @@ Vcs-Git: 
https://salsa.debian.org/nvidia-team/nvidia-settings.git
 
 Package: nvidia-settings
 Section: contrib/x11
-Architecture: amd64 arm64
+Architecture: amd64 arm64 ppc64el
 Pre-Depends:
  nvidia-installer-cleanup,
 Depends:
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 8ebcf1c..5cca736 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 upstream-vcs-tag = %(version)s
 upstream-branch = upstream
-debian-branch = master
+debian-branch = bullseye
 debian-tag = debian/%(version)s
diff --git a/doc/version.mk b/doc/version.mk
index cca9ae5..7a608de 100644
--- a/doc/version.mk
+++ b/doc/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 470.141.03
+NVIDIA_VERSION = 470.239.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/samples/version.mk b/samples/version.mk
index cca9ae5..7a608de 100644
--- a/samples/version.mk
+++ b/samples/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 470.141.03
+NVIDIA_VERSION = 470.239.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/libXNVCtrl/version.mk b/src/libXNVCtrl/version.mk
index cca9ae5..7a608de 100644
--- a/src/libXNVCtrl/version.mk
+++ b/src/libXNVCtrl/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 470.141.03
+NVIDIA_VERSION = 470.239.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/nvml.h b/src/nvml.h
index 4bd1a9e..1db12bf 100644
--- a/src/nvml.h
+++ b/src/nvml.h
@@ -403,6 +403,7 @@ typedef enum nvmlGpuP2PStatus_enum
 {
 NVML_P2P_STATUS_OK = 0,
 NVML_P2P_STATUS_CHIPSET_NOT_SUPPORED,
+NVML_P2P_STATUS_CHIPSET_NOT_SUPPORTED = 
NVML_P2P_STATUS_CHIPSET_NOT_SUPPORED,
 NVML_P2P_STATUS_GPU_NOT_SUPPORTED,
 NVML_P2P_STATUS_IOH_TOPOLOGY_NOT_SUPPORTED,
 NVML_P2P_STATUS_DISABLED_BY_REGKEY,
@@ -1813,7 +1814,7 @@ typedef struct nvmlEncoderSessionInfo_st
  */
 typedef enum nvmlFBCSessionType_enum
 {
-NVML_FBC_SESSION_TYPE_UNKNOWN = 0, //!< Unknwon
+NVML_FBC_SESSION_TYPE_UNKNOWN = 0, //!< Unknown
 NVML_FBC_SESSION_TYPE_TOSYS,   //!< ToSys
 NVML_FBC_SESSION_TYPE_CUDA,//!< Cuda
 NVML_FBC_SESSION_TYPE_VID, //!< Vid
@@ -4258,10 +4259,10 @@ nvmlReturn_t DECLDIR nvmlDeviceGetEncoderStats 
(nvmlDevice_t device, unsigned in
  * Retrieves information about active encoder sessions on a target device.
  *
  * An array of active encoder sessions is returned in the caller-supplied 
buffer pointed at by \a sessionInfos. The
- * array elememt count is passed in \a sessionCount, and \a sessionCount is 
used to return the number of sessions
+ * array element count is passed in \a sessionCount, and \a sessionCount is 
used to return the number of sessions
  * 

Bug#1067105: After installing Debian wont let you in with a given User/Password combination

[Thomas Schweikle]

Package: Debian installer
Version: As on Debian live-CD/DVD for Debian 12.5
Severity: critical


1. Download debian live-CD/DVD from:
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-12.5.0-amd64-DVD-1.iso
or 
https://ftp.gwdg.de/debian-cd/12.5.0-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso

-- 
Thomas

Bug#969354: google requires SPF or DKIM

[Matus UHLAR - fantomas]

Since google requires working SPF or DKIM, I recommend setting up either one 
for people using gmail accounts.


The advantage of DKIM is that it works in case of someone is forwarding mail 
to address hosted on other servers.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
On the other hand, you have different fingers.

Bug#1067027: python-cryptography build-dependencies unsatisfiable.

[Peter Green]

On 17/03/2024 13:01, Jérémy Lal wrote:


The last missing piece seems to be version >= 3 of
https://tracker.debian.org/pkg/rust-pem

I've uploaded this to experimental, please tell me when you are ready for it
to be uploaded to unstable.

Bug#1067104: server stalls: AH00046: child process 2876749 still did not exit, sending a SIGKILL

[Yaroslav Halchenko]

Package: apache2
Version: 2.4.57-2
Severity: important

Server was working just fine for years and recently started to stall
completely after 3-7 days of functioning normally.  error logs get filled up
first with AH03490 and then eventually with AH00045 messages:

[Sun Mar 17 02:26:01.353381 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
...
[Sun Mar 17 22:00:42.201774 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Sun Mar 17 22:00:42.995574 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Sun Mar 17 22:00:42.998488 2024] [mpm_event:notice] [pid 2649373:tid 
139846579189632] AH00492: caught SIGWINCH, shutting down gracefully
[Sun Mar 17 22:00:46.358981 2024] [core:warn] [pid 2649373:tid 
139846579189632] AH00045: child process 2649375 still did not exit, sending a 
SIGTERM
[Sun Mar 17 22:00:46.359064 2024] [core:warn] [pid 2649373:tid 
139846579189632] AH00045: child process 2649376 still did not exit, sending a 
SIGTERM

until I restart the beast.

$> grep AH03490 error.log | wc -l
70404
$> grep AH00045 error.log | wc -l
48

Server has a number of virtualserver's configured.
Seems has started about a month ago

$> for e in error.log*; do zgrep AH03490 $e| head -n 1 ; done
[Sun Mar 17 02:26:01.353381 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Mon Mar 11 16:47:41.181900 2024] [mpm_event:error] [pid 1172065:tid 
140192799893376] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Tue Mar 05 00:00:12.307813 2024] [mpm_event:error] [pid 2686718:tid 
139644504094592] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Sun Feb 25 03:23:33.382200 2024] [mpm_event:error] [pid 2686718:tid 
139644504094592] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Sat Feb 24 01:02:29.148887 2024] [mpm_event:error] [pid 2686718:tid 
139644504094592] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
[Tue Feb 13 14:28:00.653754 2024] [mpm_event:error] [pid 2434335:tid 
140300052350848] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.

and likely after I configured some wsgi

$> zgrep apache /var/log/dpkg.log.* | grep 2024
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 install 
libapache2-mod-python:amd64  3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 status half-installed 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 status unpacked 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 configure 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1 
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 status unpacked 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:34:23 status half-configured 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:34:25 status installed 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:51:18 status installed 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:51:19 remove 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1 
/var/log/dpkg.log.2.gz:2024-02-02 12:51:19 status half-configured 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:51:21 status half-installed 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:51:21 status config-files 
libapache2-mod-python:amd64 3.5.0+git20211031.e6458ec-1+deb12u1
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 install 
libapache2-mod-wsgi-py3:amd64  4.9.4-1+b2
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 status half-installed 
libapache2-mod-wsgi-py3:amd64 4.9.4-1+b2
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 status unpacked 
libapache2-mod-wsgi-py3:amd64 4.9.4-1+b2
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 configure 
libapache2-mod-wsgi-py3:amd64 4.9.4-1+b2 
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 status unpacked 
libapache2-mod-wsgi-py3:amd64 4.9.4-1+b2
/var/log/dpkg.log.2.gz:2024-02-02 12:52:11 status half-configured 
libapache2-mod-wsgi-py3:amd64 4.9.4-1+b2
/var/log/dpkg.log.2.gz:2024-02-02 12:52:14 status installed 
libapache2-mod-wsgi-py3:amd64 

Bug#1067103: libisoburn1t64: should not depend on libburn4 nor libisofs6 after time_t transition

[Daniel Serpell]

Package: libisoburn1t64
Version: 1.5.6-1.1+b1
Severity: serious
Tags: patch
Justification: bad depends after time_t transition, uninstalable.

This package shold not depend on the old libisofs and libburn, that got
renamed in the time_t transition.

Attached patch fixes this.

Regards,
Daniel.

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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)

Versions of packages libisoburn1t64 depends on:
ii  libburn4t64 [libburn4]1.5.6-1.1
ii  libc6 2.37-15.1
ii  libisofs6t64 [libisofs6]  1.5.6.pl01-1.1
ii  libjte2   1.22-4+b1
ii  libreadline8t64   8.2-3.1

libisoburn1t64 recommends no packages.

libisoburn1t64 suggests no packages.

-- no debconf information
diff --git a/debian/control b/debian/control
index f0e0a2c..6a0dc2f 100644
--- a/debian/control
+++ b/debian/control
@@ -23,9 +23,7 @@ Breaks: libisoburn1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends},
- ${misc:Depends},
- libburn4 (>= 1.5.6),
- libisofs6 (>= 1.5.6)
+ ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: library to handle creation and inspection of ISO-9660 file systems
  libisoburn is a frontend for the libraries libburn and libisofs. It handles

Bug#1067102: librsvg: please make the build reproducible

[Chris Lamb]

Source: librsvg
Version: 2.57.92+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
librsvg could not be built reproducibly due to a typo in debian/rules:

# debhelper >= 13.4 makes all of /usr/libexec executable, which is not
# quite right for installed-tests
override_dh_fixperms:
dh_fixperms -Xusr/libexec/rsvg/tests
ifneq ($(filter %-tests,$(binaries)),)
chmod --recursive --changes a+rX,u+w,og-w 
debian/*-tests/usr/libexec/rsvg/tests
endif

This should refer to "$(built_binaries)", not "$(binaries)"… and so
the line is not run... resulting in the build varying depending on the
build system's umask. :)

A patch that corrects this typo is attached.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/rules  2024-03-18 12:02:58.659721987 +
--- b/debian/rules  2024-03-18 12:57:15.97414 +
@@ -52,7 +52,7 @@
 # quite right for installed-tests
 override_dh_fixperms:
dh_fixperms -Xusr/libexec/rsvg/tests
-ifneq ($(filter %-tests,$(binaries)),)
+ifneq ($(filter %-tests,$(built_binaries)),)
chmod --recursive --changes a+rX,u+w,og-w 
debian/*-tests/usr/libexec/rsvg/tests
 endif
 

Bug#1038919: icingaweb2-module-graphite: [L10N,DE] icingaweb2-module-graphite updated german programm translation

[David Kunz]

close #1038919 1.2.3-1
thanks

Hi,

this bug has been fixed in above version, hence closing.

Regards,
David

Bug#1067101: storm-lang: please make the build reproducible

[Chris Lamb]

Source: storm-lang
Version: 0.6.20-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
storm-lang could not be built reproducibly:

│ │ │ ├── ./usr/share/doc/storm-lang/html/05-Downloads/index.html
│ │ │ │ @@ -322,15 +322,15 @@
[…]
│ │ │ │  
│ │ │ │ -Binary releases for 0.6.20-1+debian (2024-02-21)
│ │ │ │ +Binary releases for 0.6.20-1+debian (2024-02-23)
│ │ │ │  

A patch is attached that modifies an *existing* patch to ensure that
this date does not vary depending on the build machine's timezone.

  [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/patches/build-files b/debian/patches/build-files
index ec9c5ba..b33396c 100644
--- a/debian/patches/build-files
+++ b/debian/patches/build-files
@@ -145,5 +145,5 @@ Author: Filip Strömbäck 
 +#!/bin/bash
 +
 +date=$(sed -En 's/--.*<.*>  ([^ ].*)/\1/p' debian/changelog | head -n 1)
-+date=$(date --date="$date" "+%Y-%m-%d")
++date=$(date --utc --date="$date" "+%Y-%m-%d")
 +release/Storm_mps -r root -f markdown.doc.generate --  --clear --date=$date 
Storm storm doc "$1"

Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences

[Julian Gilbey]

On Mon, Mar 18, 2024 at 12:12:06PM +, Torrance, Douglas wrote:
> Control: tags -1 - moreinfo + confirmed
> [...]
> > 
> > Oh, and just to add on to this: I believe that this will become a
> > SyntaxError in Python 3.13 or Python 3.14.
> 
> Ok, thanks for clarifying!
> 
> I was able to reproduce the warnings in Python 3.12:
> ...
> 
> They were silent using Python 3.11, which is suppose is why I hadn't seen them
> before.

Just checked the Python docs: see the second point of
https://docs.python.org/3/whatsnew/3.12.html#other-language-changes

Best wishes,

   Julian

Bug#1067100: bochs: please make the build reproducible

[Chris Lamb]

Source: bochs
Version: 2.8+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
bochs could not be built reproducibly:

│ │ │ ├── /usr/share/bochs/BIOS-bochs-latest
│ │ │ │ @@ -7548,16 +7548,16 @@
[]
│ │ │ │  0001d810: 5333 2072 6573 756d 6520 6361 6c6c 6564  S3 resume called
│ │ │ │ -0001d820: 2025 7820 3078 256c 780a 0030 332f 3137   %x 0x%lx..03/17
│ │ │ │ -0001d830: 2f32 3400 4249 4f53 2042 5549 4c44 2044  /24.BIOS BUILD D
│ │ │ │ +0001d820: 2025 7820 3078 256c 780a 0030 342f 3139   %x 0x%lx..04/19
│ │ │ │ +0001d830: 2f32 3500 4249 4f53 2042 5549 4c44 2044  /25.BIOS BUILD D
│ │ │ │  0001d840: 4154 453a 2025 730a 0049 4e54 3138 3a20  ATE: %s..INT18:

A patch is attached that seeds this date from SOURCE_DATE_EPOCH if
available.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-03-18 12:53:29.510214179 
+
@@ -0,0 +1,20 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-03-18
+
+--- bochs-2.8+dfsg.orig/bios/Makefile.in
 bochs-2.8+dfsg/bios/Makefile.in
+@@ -47,7 +47,12 @@ LOCAL_CXXFLAGS =
+ 
+ # UPSTREAM_RELEASE_DATE = $(shell grep "Updated:" ../README | sed 
's/Updated://')
+ # BUILDDATE = `date -u -d '$(UPSTREAM_RELEASE_DATE)' '+%m/%d/%y'`
+-BUILDDATE = `date -u '+%m/%d/%y'`
++DATE_FMT = +%m/%d/%y
++ifdef SOURCE_DATE_EPOCH
++BUILDDATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || 
date -u "$(DATE_FMT)")
++else
++BUILDDATE ?= $(shell date "$(DATE_FMT)")
++endif
+ BIOS_BUILD_DATE = "-DBIOS_BUILD_DATE=\"$(BUILDDATE)\""
+ #
+ #  end configurable options --
--- a/debian/patches/series 2024-03-18 12:08:12.631304482 +
--- b/debian/patches/series 2024-03-18 12:53:28.550214427 +
@@ -7,3 +7,4 @@
 cross-build-1.patch
 narrowing-conversions.patch
 instrument-stub-class.patch
+reproducible-build.patch

Bug#1067099: woof-doom: please make the build reproducible

[Chris Lamb]

Source: woof-doom
Version: 14.3.0+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
woof-doom could not be built reproducibly:

│ │ │ │ ├── /usr/share/metainfo/io.github.fabiangreffrath.woof.metainfo.xml
│ │ │ │ │ @@ -35,10 +35,10 @@
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ -
│ │ │ │ │ +
│ │ │ │ │

A patch is attached that uses CMake's "UTC" argument to make sure that
this value does not vary due to the build system's timezone. (CMake is
already magically making the date inherit from SOURCE_DATE_EPOCH.)

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-03-18 13:03:40.906056433 
+
@@ -0,0 +1,12 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-03-18
+
+--- woof-doom-14.3.0+dfsg.orig/data/CMakeLists.txt
 woof-doom-14.3.0+dfsg/data/CMakeLists.txt
+@@ -1,4 +1,4 @@
+-string(TIMESTAMP PROJECT_DATE "%Y-%m-%d")
++string(TIMESTAMP PROJECT_DATE "%Y-%m-%d" UTC)
+ 
+ configure_file(io.github.fabiangreffrath.woof.metainfo.in
+io.github.fabiangreffrath.woof.metainfo.xml
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-03-18 13:03:39.342056834 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

[Dima Kogan]

Hi. Where's the upstream source for this? I would expect to see a link
here:

- debian/copyright (Source field)
- debian/control (Copyright field)
- debian/upstream/metadata

Usually the upstream source would live somewher outside of Debian (for
any non-debian-specific programs, like this one). salsa.debian.org would
contain the debianized sources.

Thanks

Bug#1067098: mpl-sphinx-theme: please make the build reproducible

[Chris Lamb]

Source: mpl-sphinx-theme
Version: 3.5.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
mpl-sphinx-theme could not be built reproducibly.

This is because it embedded the build date in the documentation:

│ │ │ ├── ./usr/share/doc/python-mpl-sphinx-theme-doc/html/genindex.html
│ │ │ │ @@ -184,15 +184,15 @@
│ │ │ │
│ │ │ │
│ │ │ │  
│ │ │ │
│ │ │ │  
│ │ │ │  
│ │ │ │
│ │ │ │ - Copyright 2024 - 2024 The Matplotlib development team.
│ │ │ │ + Copyright 2024 - 2025 The Matplotlib development team.
│ │ │ │  

(Etc.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-03-18 12:59:19.650123651 
+
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-03-18
+
+--- mpl-sphinx-theme-3.5.0.orig/docs/conf.py
 mpl-sphinx-theme-3.5.0/docs/conf.py
+@@ -1,5 +1,12 @@
++import os
++import time
+ import datetime
+ 
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
++
+ # Configuration file for the Sphinx documentation builder for
+ # matplotlib projects.
+ 
+@@ -10,7 +17,7 @@ is_release_build = tags.has('release')
+ 
+ project = "Matplotlib Sphinx Theme"
+ copyright = (
+-f"2012 - {datetime.datetime.now().year} The Matplotlib development team"
++f"2012 - {build_date.year} The Matplotlib development team"
+ )
+ author = "Matplotlib Developers"
+ 
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-03-18 12:59:16.218124536 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1065197: RFS: cevomapgen/32-1 [ITP] -- External Map Generator for C-Evo

[Peter Blackman]

Control: tags -1 -moreinfo
Control: retitle -1 RFS: cevomapgen/32-1 [ITP] -- External Map Generator 
for C-Evo



On 17/03/2024 10:48, Tobias Frost wrote:

Control: tags -1 moreinfo

Hi Peter,

(There was also #1040494, which seems not to have been sponsored.
In this case, please reopen the old RFS bug and don't file new bugs.)

Noted

Here's a very short review, (including copyright review)

- lintian:
   - Comments should be directly over the overriden tag, otherwise the
 override justification is not correctly picked up

Done



   - O: cevomapgen: no-manual-page [usr/games/cevomapgen]
 I disagree this should be overriden, and I disagree that gui
 programs don't need a manpage.

I've added man pages now


- d/copyright
   I see that there are files with years from 1999-2023 and one 2024.
   Please review your d/copyright file and record the years correctly.

Done


Hi Tobias,

Thanks for your review. I was working on a new upstream release,
and have incorporated your suggestions.

Bug#1061710: gnome-terminal: Switch to GTK4 version

[Jeremy Bícha]

https://discourse.gnome.org/t/terminal-and-vte-news/20030

Thank you,
Jeremy Bícha

Bug#1066923: icingaweb2-module-generictts: [INTL:de] updated German po file translation

[David Kunz]

close #1066923 2.1.0-2
thanks

Hi,

this bug has been fixed in above version, hence closing.

Regards,
David

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

[Chris Lamb]

Dear Alberto,

Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.


Best wishes,

Chris


- Original message -
From: Sebastian Ramacher 
To: Debian Bug Tracking System 
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: 
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. 
-I../../libfiu/ -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1

Bug#1064861: patch

[Ulises Vitulli]

tags 1064861 + patch
thanks


commit 53718adb77727095fa3d9a18ea78e21889a46442 (HEAD-> fix_1064861)
Author: Dererk 
Date:   Mon Mar 18 09:35:00 2024 -0300

   [Fix #1064861] destination of symlinks completions wrong

diff --git a/debian/kubectx.links b/debian/kubectx.links
index c167aad..ffee50d 100644
--- a/debian/kubectx.links
+++ b/debian/kubectx.links
@@ -1,7 +1,7 @@
usr/share/kubectx/completion/kubectx.bash 
usr/share/bash-completion/completions/kubectx.bash
usr/share/kubectx/completion/kubectx.fish 
usr/share/fish/vendor_completions.d/kubectx.fish
-usr/share/kubectx/completion/kubectx.zsh 
usr/share/zsh/vendor-completions/_kubectx.zsh
+usr/share/kubectx/completion/_kubectx.zsh 
usr/share/zsh/vendor-completions/_kubectx.zsh


usr/share/kubectx/completion/kubens.bash 
usr/share/bash-completion/completions/kubens.bash
usr/share/kubectx/completion/kubens.fish 
usr/share/fish/vendor_completions.d/kubens.fish
-usr/share/kubectx/completion/kubens.zsh 
usr/share/zsh/vendor-completions/_kubens.zsh
+usr/share/kubectx/completion/_kubens.zsh 
usr/share/zsh/vendor-completions/_kubens.zsh

Bug#1065197: RFS: cevomapgen/31-1 [ITP] -- External Map Generator for C-Evo

[Peter B]

On 17/03/2024 10:27, Tobias Frost wrote:

The source builds the following binary packages:

     cevomapgen - External Map Generator for C-Evo



cevomapgen is a tool for use with c-evo-dh
https://tracker.debian.org/pkg/c-evo-dh

Would it make sense to call it also c-evo-mapgen, to use the same scheme
as the game package?


Hi Tobias,

Good idea. A couple of issues though;

I don't want to change the overall project name now.
Its been released elsewhere and promoted in various forums for nearly a 
year.

The name originated from
  https://www.cix.co.uk/~spot/civmapgen/CivMapGen.htm
from which the program was adapted.

c-evo-mapgen is already in use here
https://github.com/samboy/c-evo-mapgen

What I have done, is to change the name of the Debian binary package to 
c-evo-map-gen,

and updated the doc-base indices accordingly

So putting c-evo into synaptic or doc-base now brings up both the game 
and the map tool.

This is better, so thanks for the suggestion.


Cheers,
Peter

Bug#1067097: gamemode-daemon: Fails to Set CPU Governor - pkexec not authorized

[Jake Piotrowski]

Package: gamemode-daemon
Version: 1.8.1-2
Severity: important

Dear Maintainer,

gamemoded -t fails with a message of "ERROR: Governor was not set to
performance (was actually powersave)!".

This is after installing using the meta package of "gamemode". From journalctl
it appears the package is missing some polkit rules:

Mar 18 07:11:18 jakepiot gamemoded[3930]: ERROR: External process failed with
exit code 127
Mar 18 07:11:18 jakepiot gamemoded[3930]: ERROR: Output was:
Mar 18 07:11:18 jakepiot gamemoded[3930]: ERROR: External process failed with
exit code 127
Mar 18 07:11:18 jakepiot gamemoded[3930]: ERROR: Output was:
Mar 18 07:11:18 jakepiot gamemoded[3930]: ERROR: Failed to update
split_lock_mitigate
Mar 18 07:11:18 jakepiot pkexec[4063]: jake: Error executing command as another
user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/jake]
[COMMAND=/usr/libexec/cpugovctl set performance]
Mar 18 07:11:18 jakepiot gamemoded[4063]: Error executing command as another
user: Not authorized
Mar 18 07:11:18 jakepiot gamemoded[4063]: This incident has been reported.


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

Kernel: Linux 6.6.15-amd64 (SMP w/16 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 gamemode-daemon depends on:
ii  init-system-helpers  1.66
ii  libc62.37-15
ii  libinih1 57-1
ii  libsystemd0  255.4-1
ii  pkexec   124-1

gamemode-daemon recommends no packages.

gamemode-daemon suggests no packages.

-- no debconf information

Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences

[Torrance, Douglas]

Control: tags -1 - moreinfo + confirmed

On Mon 18 Mar 2024 05:54:25 AM GMT, Julian Gilbey  wrote:

On Mon, Mar 18, 2024 at 05:48:14AM +, Julian Gilbey wrote:

I was building or testing a package using sbuild or autopkgtest using
lxc, I don't remember which.  One of the dependencies was dot2tex, so
it was being installed on a clean chroot (or equivalent).  The
warnings appeared during the dpkg installation of the package
(probably during the configure step).

But either way, all of these are, indeed, syntax errors and need to be
corrected.  (It turns out, just looking at the first example on line
1236, that they cannot all be fixed by turning them into raw strings:
this string has both '\p', which should be '\\p' (with a literal
backslash), and '\n', which presumably is intended as a new line
character.


Oh, and just to add on to this: I believe that this will become a
SyntaxError in Python 3.13 or Python 3.14.


Ok, thanks for clarifying!

I was able to reproduce the warnings in Python 3.12:

$ python3.12
Python 3.12.2 (main, Mar  3 2024, 09:11:00) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import dot2tex

/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:900: SyntaxWarning: invalid 
escape sequence '\i'
 variables['<>'] = "\input{gvcols.tex}"
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1236: SyntaxWarning: invalid 
escape sequence '\p'
...

They were silent using Python 3.11, which is suppose is why I hadn't seen them
before.

Doug


signature.asc
Description: PGP signature

Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

[Burkard Lutz]

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

* Package name: galvani
  Version : 0.34-1
  Upstream Contact: Burkard Lutz 
* URL : https://salsa.debian.org/blutz/galvani
* License : GPL-2+
  Programming Lang: C++
  Description : reads data from a device with graphical plots and
evaluation

Galvani reads measurement data from digital multimeters or other digital
devices over a serial interface. Galvani supports communication to the
instrument over a serial (RS232C) or USB (USB-TMC) interface, also by SCPI
commands.
Measurement data are plotted in a diagram. Two channels can be used for data
recording - therefore two devices can be used in parallel. Galvani uses
libserial to communicate to RS232C interfaces.
I am looking for a sponsor to publish the package on debian.

Bug#1064731: [Pkg-electronics-devel] Bug#1064731: sdcc: FTBFS: /bin/sh: 1: inkscape: not found

[Jonathan McDowell]

Control: retitle -1 sdcc: FTBFS: Error building LyX documentation

On Sun, Feb 25, 2024 at 08:45:34PM +0100, Lucas Nussbaum via 
Pkg-electronics-devel wrote:
> Source: sdcc
> Version: 4.2.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240224 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

The inkscape error here is a red herring; even switching from
librsvg2-bin back to inkscape doesn't do any better. Something in the
LyX -> LaTeX dependency tree must have changed. :(

J.

-- 
... "What the f**k was that?" -- Mayor of Hiroshima

Bug#1066919: icingaweb2-module-fileshipper: [INTL:de] updated German po file translation

[David Kunz]

close #1066919 1.2.0-3
thanks

Hi,

this bug has been fixed in above version, hence closing.

Regards,
David

Bug#1067095: keepassxc: update to new upstream release 2.7.7

[Carl Johnson]

Package: keepassxc
Version: 2.7.6+dfsg.1-1
Severity: wishlist
X-Debbugs-Cc: kni9p...@anonaddy.me

Dear Maintainer,

please update KeePassXC to the latest upstream release 2.7.7.

Thanks for your work!


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

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 keepassxc depends on:
ii  libargon2-10~20190702+dfsg-4+b1
ii  libbotan-2-19  2.19.4+dfsg-1
ii  libc6  2.37-15.1
ii  libgcc-s1  14-20240315-1
ii  libminizip11:1.3.dfsg-3+b1
ii  libpcsclite1   2.0.1-1+b1
ii  libqrencode4   4.1.1-1+b2
ii  libqt5concurrent5  5.15.10+dfsg-7
ii  libqt5core5a   5.15.10+dfsg-7
ii  libqt5dbus55.15.10+dfsg-7
ii  libqt5gui5 5.15.10+dfsg-7
ii  libqt5network5 5.15.10+dfsg-7
ii  libqt5svg5 5.15.10-2+b1
ii  libqt5widgets5 5.15.10+dfsg-7
ii  libqt5x11extras5   5.15.10-2+b1
ii  libreadline8   8.2-3+b1
ii  libstdc++6 14-20240315-1
ii  libusb-1.0-0   2:1.0.27-1
ii  libx11-6   2:1.8.7-1
ii  libxtst6   2:1.2.3-1.1
ii  libzxcvbn0 2.5+dfsg-2
ii  zlib1g 1:1.3.dfsg-3.1

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1

Versions of packages keepassxc suggests:
ii  webext-keepassxc-browser  1.9.0.2+repack1-1
pn  xclip 

-- no debconf information

Bug#1067094: pacman-package-manager: FTBFS on armel/armh

[Luca Boccassi]

Source: pacman-package-manager
Version: 6.0.2-4.1
Severity: grave

Pacman currently fails to build on armel/armhf, probably as a fallout
from the time64 changes.

Given it seems extremely unlikely to be needed on those architectures,
given Archlinux doesn't even support them, I'd recommend to simply
build-depend on architecture-is-64-bit to drop all 32 bit arches
support, and revert the libalpm13 package rename that added the t64
suffix.

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Josh Triplett]

On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
> Was there some recent packaging situation that prompted you to think
> about this?  I'm cautious about adding it in the absence of that.

Mostly, recent discussions in various places regarding whether packages
are required to use *cron* to run periodic jobs. Policy says what
packages must do if they install a cronjob, but that itself does not
mandate the use of cron specifically. It seemed worth explicitly stating
the understood-but-unwritten interpretation that having Policy about XYZ
does not mandate that packages use XYZ.

I've also seen a few arguments over the decades that amount to "Policy
talks about A, and doesn't talk about B" being used as some amount of
weight towards A or against B.

And finally, I have occasionally seen someone try to build a Debian
package by sitting down with the Policy manual, and start down the route
of trying to supply everything Policy talks about that seems like it
makes sense for the package. The mention of "Policy talking about where
to install info documentation, but that doesn't mean you have to have
info documentation" was not a hypothetical; I've seen that and similar
reasoning a non-zero number of times.

I figured that something like this text would help address all of those.

Bug#405859: GLUT_ALPHA does not work with DRI

[Fabio Pedretti]

Version: 8.0-1

mga driver was removed from mesa since 8.0 in 2012:
https://docs.mesa3d.org/relnotes/8.0.html

Bug#1067093: Impacket Patches for PR 1714 and 1715

[Arszilla]

Package: impacket
Version: 0.11.0-2

Hi there,

Currently, I am helping the Kali Team to package NetExec 
(https://github.com/Pennyw0rth/NetExec) as per 
https://bugs.kali.org/view.php?id=8533. NetExec (nxc/netexec) is a fork of 
crackmapexec (which has been discontinued) and is still in active development. 
Sadly, packaging netexec is not simple as it requires me to solve several 
dependency issues, one of which is impacket/python3-impacket.

Currently, NetExec is using a fork of Fortra/SecureAuthCorp's impacket, which 
was created due to several functionality-breaking changes that were implemented 
by Fortra without regard to how they might impact the users of their library.

I have discussed the situation with some maintainers of NetExec, explaining the 
choices I have regarding facilitating the packaging of their tool as a mere 
volunteer/contributor. After discussions and research that lasted days, it was 
concluded that there are two options available:
1. Submit PRs to Fortra and hope the changes they introduced are reverted, 
alongside the additions that the netexec devs have made. The netexec devs have 
submitted 2 PRs, https://github.com/fortra/impacket/pull/1714 and 
https://github.com/fortra/impacket/pull/1715. If these are approved by Fortra, 
the python3-impacket package would need to be updated subsequently with the 
changes so that packaging could continue.
2. Create a new package of the fork named python3-impacket-nxc, which would 
install the forked impacket library to 
/usr/lib/python3/dist-packages/impacket_nxc/ and proceed with packaging. 
However, since netexec maintainers want to be able to pull the changes from the 
mainstream with little-to-no manual intervention, a patch must be generated 
(which I did generate) that would replace all relevant instances of impacket 
(such as "from impacket import X") with impacket_nxc (to make sure the new 
package would be installed in a new path and unique namespace to avoid 
collisions). However, this patch is over 6700 lines and modifies ~260 files, 
thus even if it was split into multiple files, it might be a pain to maintain 
and update.

After discussing these 2 options, it was concluded that a 2nd impacket package 
might lead to confusion on both the maintainer (Kali Team/me) and the end-user 
sides; hence, the netexec maintainer submitting PRs to accommodate Option #1. 
However, Fortra is slow to respond to PR requests at times. As a result, I 
wanted to question the possibility of using patch files for the 2 MRs 
introduced by the netexec maintainers, allowing me to continue packaging 
netexec without the need for a second impacket package.

If this is acceptable on your end, I'd sincerely appreciate it if you could 
guide me through the process of providing you with the patch files, as I am 
fairly new to reporting these types of issues to the Debian side of things.

Kind regards.

Bug#1067092: man-db: “man -K --regex” fails to match whole words in some cases

[Colin Watson]

On Mon, Mar 18, 2024 at 11:54:42AM +0100, Manny wrote:
> Searching the whole DB for a whole word requires using --regex and
> then using word boundaries. So to find pages that reference the TZ
> environment variable, this *should* work (in principle):
> 
>   $ man -aK --regex '\'
> 
> It appears to work because it finds many pages. But it misses the
> “tree” package (/usr/share/man/man1/tree.1.gz).
> 
>   $ zgrep 'TZ' /usr/share/man/man1/tree.1.gz
>   \fBTZ\fPTimezone for timefmt output, see \fBstrftime\fP(3).
> 
> As you can see, the nroff language intereferes with matching the
> regular expression as “TZ” is surrounded by code. Users of man-db
> obviously do not intend to have their regex matched against nroff
> code. Thus operations are being performed in the wrong order. The
> regular expression matching needs to happen on nroff-decoded text.

In principle I certainly agree that this would be more usable, but I've
considered this in the past and given up as making it perform well would
have been very difficult.  There's a note about this in man(1), under
the description of -K:

  Note that this searches the sources of the manual pages, not the
  rendered text, and so may include false positives due to things
  like comments in source files, or false negatives due to things
  like hyphens being written as "\-" in source files.  Searching
  the rendered text would be much slower.

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

Bug#1066921: icingaweb2_module_eventdb: [INTL:de] updated German po file translation

[David Kunz]

Close #1066921 
 1.3.0-4


Thanks


Hi,

this bug has been fixed in above version, hence closing.

Regards,

David

Bug#1067092: man-db: “man -K --regex” fails to match whole words in some cases

[Manny]

Package: man-db
Version: 2.9.4-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.man...@sideload.33mail.com

Searching the whole DB for a whole word requires using --regex and
then using word boundaries. So to find pages that reference the TZ
environment variable, this *should* work (in principle):

  $ man -aK --regex '\'

It appears to work because it finds many pages. But it misses the
“tree” package (/usr/share/man/man1/tree.1.gz).

  $ zgrep 'TZ' /usr/share/man/man1/tree.1.gz
  \fBTZ\fPTimezone for timefmt output, see \fBstrftime\fP(3).

As you can see, the nroff language intereferes with matching the
regular expression as “TZ” is surrounded by code. Users of man-db
obviously do not intend to have their regex matched against nroff
code. Thus operations are being performed in the wrong order. The
regular expression matching needs to happen on nroff-decoded text.

  $ zcat /usr/share/man/man1/tree.1.gz | nroff -man | grep '\'
   TZTimezone for timefmt output, see strftime(3).

* Workaround *

One approach:

  $ find /usr/share/man/ -iname \*gz -exec zcat {} + | nroff -man | grep 
'\<'"$whole_word"'\>'

In rare situations such as environment variable searches, case
sensitivity can be leveraged:

  $ man -aKI --regex TZ

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

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

Versions of packages man-db depends on:
ii  bsdextrautils  2.36.1-8+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  groff-base 1.22.4-6
ii  libc6  2.31-13+deb11u5
ii  libgdbm6   1.19-2
ii  libpipeline1   1.5.3-1
ii  libseccomp22.5.1-1+deb11u1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor  2.13.6-10
ii  elinks [www-browser]  0.13.2-1+b1
ii  firefox-esr [www-browser] 102.6.0esr-1~deb11u1
pn  groff 
ii  less  551-2
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
ii  ungoogled-chromium [www-browser]  90.0.4430.212-1.sid1
ii  w3m [www-browser] 0.5.3+git20210102-6

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true

Bug#646929: libgl1-mesa-glx: message "failed to create drawable" when starting Firefox

[Fabio Pedretti]

Version: 8.0-1

It looks like this was addressed in mesa years ago with this commit:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=4833104718677caad0027d5e7539ca9bba389392

Bug#1065083: $icingaweb2-module-director: [INTL:de] updated German icingaweb2-module-director translation\

[David Kunz]

close #1065083 1.10.2-2

thanks


Hi

this bug has been fixed in above version, hence closing.

Regards,

David

Bug#775235: use llvm's getCPUTargetFeatures() over getHostCPUName()

[Fabio Pedretti]

It looks like the src/gallium/auxiliary/gallivm/lp_bld_misc.cpp file
in mesa was heavily updated for managing newer llvm versions, even if
mesa is still using getHostCPUName and still not getCPUTargetFeatures.

Michael, do you think there is still something to do in mesa?

Steve and Bernhard, are you still able to reproduce the original issue?

Bug#1067088: [Pkg-zfsonlinux-devel] Bug#1067088: zfs-linux: missing B-D: libtirpc-dev

[Aron Xu]

Control: tags -1 + pending

On Mon, Mar 18, 2024 at 5:31 PM Andreas Beckmann  wrote:
>
>
> This could be fixed by adding an explicit Build-Depends on libtirpc-dev.
> The glibc change will likely be reverted in the short term, but given
> its a change we want to do for Trixie, this will only lower the severity
> of the bug.
>

This has been fixed in git and will be addressed in the next upload.

https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/f2ca97fdca7a35d63a3bae1af106bc3c238ca95f

Regards,
Aron

Bug#1067083: python-uinput: FTBFS on arm{el,hf}: libsuinput/src/suinput.c:48:28: error: ‘struct input_event’ has no member named ‘time’

[Simon McVittie]

On Mon, 18 Mar 2024 at 09:12:36 +0100, Sebastian Ramacher wrote:
> arm-linux-gnueabihf-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
> -Werror=implicit-function-declaration -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.11 -c libsuinput/src/suinput.c -o 
> build/temp.linux-armv7l-cpython-311/libsuinput/src/suinput.o
> libsuinput/src/suinput.c: In function ‘suinput_emit’:
> libsuinput/src/suinput.c:48:28: error: ‘struct input_event’ has no member 
> named ‘time’
>48 | gettimeofday(, 0);
>   |^

This is probably the same thing fixed by
. Untested pseudocode
for a fix:

-gettimeofday(, 0);
+struct timeval timestamp;
+gettimeofday(, 0);
+event.input_event_sec = timestamp.tv_sec;
+event.input_event_usec = timestamp.tv_usec;

smcv

Bug#1063980: Mark affected test xfail and reduce bug severity + report upstream

[Andreas Tille]

Control: tags -1 important
Control: tags -1 upstream
Control: forwarded -1 https://github.com/jnothman/UpSetPlot/issues/273
thanks

Hi,

I've checked the new upstream version of python-upsetplot which shows
the same problem.  Thus I marked the one affected test xfail and
reported the problem upstream.  Since the package builds again now
and is passing its autopkgtest I reduced the severity of the bug from
serious to important.

Kind regards
Andreas.


-- 
http://fam-tille.de

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

[original poster]

* Romain Francoise  [2024-03-17 19:52]:
>
> tcpdump has no special handling of TZ, it just calls strftime() which
> handles TZ as described in strftime(3).

Thanks for the quick feedback.

That’s a bit tricky one then. Users of tcpdump wouldn’t generally know
that strftime() is in use and thus don’t know to visit that man
page.

To investigate what’s done conventionally, I ran this command:

  $ man -IaK --regex TZ | sed -ne '/\.*zone/{x;G;p};/^NAME/{N;s/\n/ /;h}'

which short-listed some pages. Of those, “man tree” shows a good
complete example. It contains:

===8<
ENVIRONMENT
   LS_COLORS  Color information created by dircolors
   TREE_COLORSUses this for color information over LS_COLORS if it is 
set.
   TREE_CHARSET   Character set for tree to use in HTML mode.
   CLICOLOR   Enables colorization even if TREE_COLORS or LS_COLORS is 
not set.
   CLICOLOR_FORCE Always enables colorization (effectively -C)
   LC_CTYPE   Locale for filename output.
   LC_TIMELocale for timefmt output, see strftime(3).
   TZ Timezone for timefmt output, see strftime(3).
…
SEE ALSO
   dircolors(1), ls(1), find(1), du(1), strftime(3)
===8<

But if tcpdump were to document the TZ variable and strftime() were to
make a change so TZ no longer has effect, then tcpdump would have to
keep tabs on strftime(), in principle. OTOH, the “see strftime(3)” gives
users enough info to react if that happens.

Alternatively, a minimal change would be to add strftime(3) to the SEE ALSO
section. The current tcpdump man page misses it:

===8<
SEE ALSO
   stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-filter(7), 
pcap-tstamp(7)
===8<

Bug#1065553: fonts-jetbrains-mono: Jetbrains-Mono 2.304 broken in Gnome Terminal

[Agathe Porte]

Control: tag -1 unreproducible

Hi,

2024-03-06 16:09 CET, Guy Rutenberg:
> After updating fonts-jetbrains-mono from version 2.242+ds-3 to 2.304+ds-4, the
> font is displayed as gibbrish in Gnome Terminal. Other apps do render the font
> correctly. Reverting back to 2.242+ds-3 fixes the issue.

Cannot reproduce, see attached screenshot.

$ LANG=en dpkg -l fonts-jetbrains-mono gnome-terminal
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description

+++----
ii  fonts-jetbrains-mono 2.304+ds-4   all  free and open-source 
typeface for developers
ii  gnome-terminal   3.51.90-1amd64GNOME terminal emulator 
application

Best regards,

Agathe.

Bug#1067091: xfce4-terminal: Non-ascii chars incorrectly displayed

[Laurent Martelli]

Package: xfce4-terminal
Version: 1.1.1-1
Severity: normal
X-Debbugs-Cc: martellilaur...@gmail.com

Dear Maintainer,

Since version 1.1.0 (also tested on 1.1.3 from unstable), non ASCII chars do
not show correctly in command output (filenames from "ls" for instance). For
instance "différées" is displayed as "différées".

It works well on 1.0.4.

Here's my locale setup :
laurent@logo:~$ locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=


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

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

Versions of packages xfce4-terminal depends on:
ii  exo-utils   4.18.0-1+b1
ii  libatk1.0-0t64 [libatk1.0-0]2.51.90-4
ii  libc6   2.37-15
ii  libcairo2   1.18.0-1+b1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii  libglib2.0-02.78.4-5
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-5
ii  libgtk-3-0t64 [libgtk-3-0]  3.24.41-3
ii  libpango-1.0-0  1.51.0+ds-4
ii  libpcre2-8-010.42-4
ii  libutempter01.2.1-3
ii  libvte-2.91-0   0.75.92-1
ii  libx11-62:1.8.7-1
ii  libxfce4ui-2-0  4.18.4-1
ii  libxfce4util7   4.18.1-2
ii  libxfconf-0-3   4.18.1-1+b1
ii  perl5.38.2-3

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4

xfce4-terminal suggests no packages.

-- no debconf information