Bug#1020548: nfs-kernel-server causes kernel panic

[Klemens Kittan]

Package: nfs-kernel-server
Version: 1:1.3.4-2.5+deb10u1
Severity: important

I am using Debian GNU/Linux 10.13, kernel 5.10.0-0.deb10.16-amd64 and libc6
2.28-10+deb10u1.

As soon as the NFS server is accessed, I get a kernel panic and have to
restart the server. With the kernel 5.10.0-0.bpo.15-amd64 the problem does
not exist. As a workaround I have pinned the kernel.

Sep 19 11:42:14 fs1 kernel: [9.923891] NFSD: Using UMH upcall client
tracking operations.
Sep 19 11:42:14 fs1 kernel: [9.923897] NFSD: starting 90-second grace
period (net f098)
Sep 19 11:42:20 fs1 kernel: [   15.969957] [ cut here
]
Sep 19 11:42:20 fs1 kernel: [   15.970015] WARNING: CPU: 1 PID: 959 at
fs/nfsd/nfs4state.c:4998 nfsd4_process_open2+0x1305/0x1510 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.970017] Modules linked in: cbc cts
rpcsec_gss_krb5 binfmt_misc vsock_loopback
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock
xt_multiport xt_state xt_conntrack nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 libcrc32c xt_comment iptable_filter quota_v2 quota_tree
intel_rapl_msr intel_rapl_common crc32_pclmul vmwgfx nls_ascii nls_cp437
vfat ttm ghash_clmulni_intel fat drm_kms_helper aesni_intel libaes
crypto_simd cec cryptd glue_helper vmw_balloon rapl drm vmw_vmci joydev
evdev efi_pstore pcspkr serio_raw sg ac button nfsd nfs_acl lockd usbhid
auth_rpcgss grace hid usbcore dm_mod sunrpc usb_common efivarfs ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sr_mod cdrom sd_mod
ata_generic t10_pi crc_t10dif crct10dif_generic ata_piix crct10dif_pclmul
crct10dif_common libata psmouse crc32c_intel vmw_pvscsi vmxnet3 scsi_mod
i2c_piix4
Sep 19 11:42:20 fs1 kernel: [   15.970119] CPU: 1 PID: 959 Comm: nfsd Not
tainted 5.10.0-0.deb10.16-amd64 #1 Debian 5.10.127-2~bpo10+1
Sep 19 11:42:20 fs1 kernel: [   15.970120] Hardware name: VMware, Inc.
VMware7,1/440BX Desktop Reference Platform, BIOS
VMW71.00V.16707776.B64.2008070230 08/07/2020
Sep 19 11:42:20 fs1 kernel: [   15.970160] RIP:
0010:nfsd4_process_open2+0x1305/0x1510 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.970164] Code: ba 85 3f 89 c0 48 0f a3 05
38 4a eb c8 73 d9 48 8b 05 2f 08 04 00 48 85 c0 74 0d 48 8b 78 08 49 8d 75
1c e8 5d fe fc ff eb be <0f> 0b e9 0d f4 ff ff 0f 0b e9 8c f5 ff ff 48 c7
44 24 48 00 00 00
Sep 19 11:42:20 fs1 kernel: [   15.970166] RSP: 0018:9f0b406cfce0
EFLAGS: 00010246
Sep 19 11:42:20 fs1 kernel: [   15.970168] RAX:  RBX:
8ce4ddc011e0 RCX: 8ce4ca9946e0
Sep 19 11:42:20 fs1 kernel: [   15.970169] RDX: 0001 RSI:
8ce4cb2337f8 RDI: 8ce4cb2337a4
Sep 19 11:42:20 fs1 kernel: [   15.970170] RBP: 9f0b406cfdc0 R08:
8ce4cb2337a8 R09: 8ce4c45550c0
Sep 19 11:42:20 fs1 kernel: [   15.970171] R10:  R11:
 R12: 8ce4cb2337a0
Sep 19 11:42:20 fs1 kernel: [   15.970172] R13:  R14:
8ce4cb2337a0 R15: 8ce4ddd99730
Sep 19 11:42:20 fs1 kernel: [   15.970173] FS:  ()
GS:8ce5f7c8() knlGS:
Sep 19 11:42:20 fs1 kernel: [   15.970174] CS:  0010 DS:  ES:  CR0:
80050033
Sep 19 11:42:20 fs1 kernel: [   15.970175] CR2: 7fc1e1e7f710 CR3:
000184a0a003 CR4: 000606e0
Sep 19 11:42:20 fs1 kernel: [   15.970230] Call Trace:
Sep 19 11:42:20 fs1 kernel: [   15.970248]  ? nfsd_permission+0x63/0xe0
[nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.970260]  ? fh_verify+0x17a/0x6a0 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.970358]  ?
write_bytes_to_xdr_buf+0xbc/0xe0 [sunrpc]
Sep 19 11:42:20 fs1 kernel: [   15.971051]  nfsd4_open+0x3a1/0x720 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971142]  nfsd4_proc_compound+0x355/0x680
[nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971155]  nfsd_dispatch+0xd4/0x180 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971179]  svc_process_common+0x392/0x6c0
[sunrpc]
Sep 19 11:42:20 fs1 kernel: [   15.971203]  ? svc_recv+0x3c4/0x8a0 [sunrpc]
Sep 19 11:42:20 fs1 kernel: [   15.971214]  ? nfsd_svc+0x300/0x300 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971225]  ? nfsd_destroy+0x60/0x60 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971246]  svc_process+0xb7/0xf0 [sunrpc]
Sep 19 11:42:20 fs1 kernel: [   15.971257]  nfsd+0xe8/0x140 [nfsd]
Sep 19 11:42:20 fs1 kernel: [   15.971262]  kthread+0x116/0x130
Sep 19 11:42:20 fs1 kernel: [   15.971265]  ?
__kthread_cancel_work+0x40/0x40
Sep 19 11:42:20 fs1 kernel: [   15.971269]  ret_from_fork+0x22/0x30
Sep 19 11:42:20 fs1 kernel: [   15.971272] ---[ end trace 4468d10badfc4017
]---

Bug#1020531: dia: creating a text element kills all GUI fonts

[Dr. Nikolaus Klepp]

Hi!

I just found out that installing libfreetype6_2.10.4+dfsg-1+deb11u1_amd64.deb 
solves the problem. I assume that "Bitstream Vera Sans 345593.26171875" tries 
to create a font of size 345593, which is a bit strange. Looks like a overflow 
or division by zero to me.

I have a lot of old TTF fonsts installed + mscorefonts + bitmap fonts (enabled 
for Xorg). Desktop Environment is TDE. Anyway, the affectd Bitstream Vera Sans 
is from ttf-bitstream-vera 1.10-8.2

Special settings for GDK/GTK:

GDK_DPI_SCALE=1.25
GTK_CSD=0
LD_PRELOAD=libgtk3-nocsd.so.0

Nik


Anno domini 2022 Thu, 22 Sep 21:53:16 +0200
 Philippe SWARTVAGHER scripsit:
> Hello,
> 
> I cannot reproduce the bug on a up-to-date Debian Sid with XFCE.
> 
> Your version of dia is not the latest available (0.97.3+git20220525-4 is
> available in unstable), but that shouldn't be the origin of the bug
> since the difference between -3+b1 and -4 is only a change in the
> recommended packages.
> 
> Can you try to provide more context, so I can reproduce the issue? What
> is your desktop environment? Do you have any specific fonts installed?
> 
> Philippe.
> 
> Le 22/09/2022 à 20:56, Dr. Nikolaus Klepp a écrit :
> > Package: dia
> > Version: 0.97.3+git20220525-3+b1
> > Severity: important
> > X-Debbugs-Cc: off...@klepp.biz
> >
> > Dear Maintainer,
> >
> > Creating a text element breaks all GUI fonts in dia. Steps to reproduce:
> > - open dia
> > - create a text element
> > - right click on the text element
> >
> > --> all GUI fonts are invisible.
> >
> > Console log:
> > (dia:15743): Pango-WARNING **: 20:52:08.861: failed to create cairo scaled 
> > font, expect ugly output. the offending font is 'Bitstream Vera Sans 
> > 345593.26171875'
> > (dia:15743): Pango-WARNING **: 20:52:08.862: font_face status is: error 
> > occurred in libfreetype
> > (dia:15743): Pango-WARNING **: 20:52:08.862: scaled_font status is: error 
> > occurred in libfreetype
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> > merged-usr: no
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=de_AT:de
> > Shell: /bin/sh linked to /bin/dash
> > Init: sysvinit (via /sbin/init)
> > LSM: AppArmor: enabled
> >
> > Versions of packages dia depends on:
> > ii  dia-common   0.97.3+git20220525-3
> > ii  gir1.2-gtk-2.0   2.24.33-2
> > ii  libc62.34-8
> > ii  libcairo21.16.0-6
> > ii  libgcc-s112.2.0-2
> > ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
> > ii  libglib2.0-0 2.74.0-1
> > ii  libgraphene-1.0-01.10.8-1
> > ii  libgtk2.0-0  2.24.33-2
> > ii  libpango-1.0-0   1.50.10+ds-1
> > ii  libpangocairo-1.0-0  1.50.10+ds-1
> > ii  libpoppler12322.08.0-2.1
> > ii  libpython3.103.10.7-1
> > ii  libstdc++6   12.2.0-2
> > ii  libxml2  2.9.14+dfsg-1+b1
> > ii  zlib1g   1:1.2.11.dfsg-4.1
> >
> > Versions of packages dia recommends:
> > ii  dia-shapes   0.6.0-4
> > ii  gsfonts-x11  2:20200910-4
> >
> > dia suggests no packages.
> >
> > -- no debconf information
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...

Bug#985457: geoip-database update

[Marco d'Itri]

> Am 11.03.2021 um 00:02 schrieb Marco d'Itri:
> > Did you consider packaging https://mailfud.org/geoip-legacy/, which is 
> > derived from the current GeoLite2 database?

Can we get any feedback on this? A three years old database is more 
harmful than useful at this point.
Are you still interested in maintaining this package?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1020486: libffi-dev: Error in `/usr/share/doc-base/libffi-dev.libffi', line 18: all `Format' sections are invalid

[tv.debian]

On Thu, 22 Sep 2022 07:40:21 +0200 "tv.debian" 
 wrote:

Package: libffi-dev
Version: 3.4.3-1
Severity: normal

Dear Maintainer,

on upgrade of libffi-dev 3.4.2-4 dpkg interrupts the configuration:

"
dpkg: error processing package libffi-dev:amd64 (--configure):
  dependency problems - leaving unconfigured
Processing triggers for install-info (6.8-6) ...
Processing triggers for doc-base (0.11.1) ...
Processing 3 changed doc-base files...
Error in `/usr/share/doc-base/libffi-dev.libffi', line 18: all `Format' 
sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details 
about the above error.

"

Thank you for your attention.

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

Kernel: Linux 5.19.10-deb64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libffi-dev depends on:
iu  libffi8  3.4.3-1

libffi-dev recommends no packages.

libffi-dev suggests no packages.

-- no debconf information




Hello,

after manually downgrading to Testing all libffi* packages, the upgrade 
to Unstable went OK. So as far as I am concerned the bug is resolved.

Bug#1020516: i386: nothing but a blinking underscore at the top left

[karogyoker999]

OK, now I know why these error messages were very familiar to me.
I had these error messages for kalgebra as well, and I suspect it is
because of SSE2. See more info here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016658

Version 2.0.8-2 for lightdm-gtk-greeter is very old. But what is this
2.0.8-2+b1 version? I can't find anything about what is this +b1, what
are the changes?
That might shed some light onto the problem.

Bug#1020546: lintian: spelling-error-in-binary moans about valid HTML entity name (curren)

[Olly Betts]

Package: lintian
Version: 2.115.3
Severity: normal

I get:

I: xapian-omega: spelling-error-in-binary curren current [usr/bin/omindex]

That's not a spelling error though, it's from a list of HTML entity
names (¤ is "¤"):

https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references

I'd suggest removing "curren" from the list.

Cheers,
Olly

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

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

Versions of packages lintian depends on:
ii  binutils2.38.90.20220713-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.38.90.20220713-2
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#971424: mailto:971...@bugs.debian.org

[Manuel Schneider]

Hi,


I can confirm that it works in bookworm on my pinephone.

I'd really appreciate it if you could backport the patch to stable?


Thanks
Manuel

Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[intrigeri]

Hi,

Guillem Jover (2022-09-23):
> On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
>> According to
>> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
>> _FORTIFY_SOURCE=3 improves memory management protections. It requires
>> glibc 2.34. It's been supported in Clang "for some time" and support
>> was added to GCC 12. I understand it has some performance impact.
>
> It would be nice to understand what's the impact here. Paul Wise also
> mentioned a thread on .

Unfortunately, I'm not knowledgeable enough in this area to provide
this information.

> If the intention is to update the default, then that would require a
> discussion on d-d:
>
>   
> 

My proposal, at least at this stage, is to *not* update the default:

>> I suppose we don't want to switch hardening=fortify fortification
>> level 3, at least to start with.

It may be that the cost (performance) / benefit (security) needs to be
assessed on a per-package basis, which would prevent us from ever
making this the default. Anyway, IMO that's a discussion for years
from now: we'll see how it works for distros that enable this feature,
and once it is available in an opt-in manner, it'll be easier to
gather the data we need to decide.

>> So perhaps a new hardening=XYZ flag could allow package maintainers to
>> opt-in?
>
> The main problem is that any new feature added to an area such as
> hardening will be automatically picked up by anything that is
> currently specifying hardening=all. :/

Ouch. Thanks, I did not think of this. That indeed makes it difficult
to add any new hardening build flag in an iterative manner :/

> I've been pondering about managing this kind of thing via
> , but I
> don't think that would even help with the =all problem. So I was
> thinking a potential solution would be to version the =all request
> somehow.
>
> We'd have =all meaning level 0, then say =all-v1 for the new defaults,
> that would also mean we can safely add new features that will not be
> part of the current =all.

Sounds good!

Should we track this versioning as a separate bug report, that would
block this one?

Thanks for your constructive reply,
cheers!

Bug#970234: consider dropping "No hard links in source packages"

[Helmut Grohne]

Hi Russ,

On Thu, Sep 22, 2022 at 07:20:00PM -0700, Russ Allbery wrote:
> From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Thu, 22 Sep 2022 19:15:52 -0700
> Subject: [PATCH] Allow hard links in source packages
> 
> It's not clear why this restriction was in place, and Debian
> included a package containing hard links without anyone noticing
> in the last release.
> ---
>  policy/ch-source.rst | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index c7415fc..a7df539 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably 
> possible.  [#]_
>  Restrictions on objects in source packages
>  --
>  
> -The source package must not contain any hard links,  [#]_ device special
> -files, sockets or setuid or setgid files.. [#]_
> +The source package must not contain device special files, sockets, or
> +setuid or setgid files. [#]_
>  
>  .. _s-debianrules:
>  
> @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for 
> any ``foo``.
> would be nice if the modification time of the upstream source would
> be preserved.
>  
> -.. [#]
> -   This is not currently detected when building source packages, but
> -   only when extracting them.
> -
> -   Hard links may be permitted at some point in the future, but would
> -   require a fair amount of work.
> -
>  .. [#]
> Setgid directories are allowed.
>  

Seconded.

Helmut


signature.asc
Description: PGP signature

Bug#1020544: siconos: FTBFS on s390x: Cholesky solve kNM_test failed

[Aron Xu]

Package: siconos
Version: 4.4.0+dfsg-1
Severity: important

The new version FTBFS on s390x in test suite 23, relevant log entry:

> Cholesky solve preserving matrix
> Cholesky solve kNM_test: ./numerics/src/tools/NumericsMatrix.c:3023: NM_csc: 
> > Assertion `A->matrix2->csc->m == A->size0 && "inconsistent size

Full build log is
https://buildd.debian.org/status/fetch.php?pkg=siconos&arch=s390x&ver=4.4.0%2Bdfsg-1&stamp=1663797112&raw=0

Regards,
Aron

Bug#1017648: How to apply the patch in bug 987512

[Francois Marier]

To apply the patch in the other bug, simply open
/usr/lib/tiger/systems/Linux/2/gen_mounts in a text editor (as root) and
then insert this line:

  [ "$1" = "fuse.portal" ] && LOCAL=0

in between:

   [ "$1" = "fuse.lxcfs" ] && LOCAL=0

and:

   [ "$1" = "fuse.clamfs" ] && LOCAL=0   # ClamFS anti-virus protected 
file system

The patch itself can be found here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=987512;filename=tiger-fuse_portal.patch;msg=5

Francois

-- 
https://fmarier.org/

Bug#1020543: RFS: domdf-python-tools/3.4.0-1 [ITP] -- Helpful functions for Python

[Nilson Silva]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "domdf-python-tools":

 * Package name : domdf-python-tools
   Version  : 3.4.0-1
   Upstream contact : Dominic Davis-Foster 
 * URL  : https://github.com/domdfcoding/domdf_python_tools
 * License  : CC-BY-SA, PSFL-2, Expat
 * Vcs  : 
https://salsa.debian.org/python-team/packages/domdf-python-tools
   Section  : python

The source builds the following binary packages:

  python3-domdf-python-tools - Helpful functions for Python

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

  https://mentors.debian.net/package/domdf-python-tools/

  https://salsa.debian.org/nilsonfsilva/domdf-python-tools

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/domdf-python-tools/domdf-python-tools_3.4.0-1.dsc

Changes for the initial release:

 domdf-python-tools (3.4.0-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1020324)

Note:

The documentation binary, I was not made because it depends on a dependency:
 https://github.com/sphinx-toolbox/sphinx-pyproject, which is not yet on debian

Regards, --   Josenilson Ferreira da SIlva




Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553

Bug#970234: consider dropping "No hard links in source packages"

[Russ Allbery]

Russ Allbery  writes:

> The fact that this has gone unnoticed in a source package in an existing
> release makes a pretty strong argument that nothing in Debian cares and
> we should just remove the constraint.

Here is a patch dropping the restriction on hard links in source packages
that I think is ready for seconds.  I'm copying Guillem for his review, in
case there's some dpkg concern.

-- 
Russ Allbery (r...@debian.org)  

>From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Thu, 22 Sep 2022 19:15:52 -0700
Subject: [PATCH] Allow hard links in source packages

It's not clear why this restriction was in place, and Debian
included a package containing hard links without anyone noticing
in the last release.
---
 policy/ch-source.rst | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index c7415fc..a7df539 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -282,8 +282,8 @@ source files in a package, as far as is reasonably possible.  [#]_
 Restrictions on objects in source packages
 --
 
-The source package must not contain any hard links,  [#]_ device special
-files, sockets or setuid or setgid files.. [#]_
+The source package must not contain device special files, sockets, or
+setuid or setgid files. [#]_
 
 .. _s-debianrules:
 
@@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for any ``foo``.
would be nice if the modification time of the upstream source would
be preserved.
 
-.. [#]
-   This is not currently detected when building source packages, but
-   only when extracting them.
-
-   Hard links may be permitted at some point in the future, but would
-   require a fair amount of work.
-
 .. [#]
Setgid directories are allowed.
 
-- 
2.37.2

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Russ Allbery]

Wouter Verhelst  writes:
> On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
>> Wouter Verhelst  writes:

>>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
>>> (probably after debconf though)

>> Here, a couple of years later, is a patch that does this, and which I
>> think is ready for seconds.

> Whoops, sorry; this completely slipped my mind.

Apologies, that probably sounded like I was complaining about you not
sending a patch.  I only meant to mention that this was a thread from a
long time back, which is why it might seem out of the blue.  I have
dropped so many Policy balls that I'm certainly not going to complain
about a bug slipping someone else's mind.  :)

> I think this could be expanded a bit?

> "This is done to reduce the risk of inconsistencies between repeated
> builds, in case a package is temporarily not available to be installed
> on a given architecture (which due to the nature of the unstable
> distribution might happen for any number of reasons) at the time of the
> (re-)build of a package."

> or something along those lines. The point is to make it clear how these
> inconsistencies are caused, which I think will help with understanding.

> (I realize your text is what the footnote originally said, but I think
> this suggestion would improve matters)

Here's an updated patch that expands that and also is more explicit, since
I found my own wording a bit hard to read.  I also added an example.  It
may be a bit verbose now, but this feels like an important topic to be
clear about given how often it comes up.

I also reworded the paragraph about backports to hopefully address
Holger's reading.  It's just trying to say that backports uses aptitude in
the normal way and doesn't do anything special to transform the
alternative.

-- 
Russ Allbery (r...@debian.org)  

>From 36373c7de4ae7a0ac0051848d5e1b8e181bcf78d Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 19:11:54 -0700
Subject: [PATCH] Improve alternative build dependency discussion

Alternatives in build dependencies are normally (except for
backports) handled specially by autobuilders to try to maintain
consistent builds.  This was documented in Policy, but in a
footnote that people often didn't see.

Move this text into the main body of the discussion of build
dependencies and reword it for additional clarity.  Add a pointer
to this discussion where alternative dependencies are introduced.
---
 policy/ch-relationships.rst | 61 +++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 5074428..e8978af 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other
 packages, the package names listed may also include lists of alternative
 package names, separated by vertical bar (pipe) symbols ``|``. In such a
 case, that part of the dependency can be satisfied by any one of the
-alternative packages.  [#]_
+alternative packages. (Alternative dependencies in ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted
+specially by Debian autobuilders. See :ref:`Relationships between source
+and binary packages ` for more details.)
 
 All of the fields may restrict their applicability to particular versions
 of each named package. This is done in parentheses after each individual
@@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in
 ``Build-Conflicts-Arch`` fields must be satisfied when these targets
 are invoked.
 
+Alternative dependencies are allowed in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's
+autobuilders normally discard the dependencies after the first. This is
+done to give alternative dependencies a consistent interpretation that
+reduces the risk of inconsistencies between repeated builds. If, for
+example, the first-listed dependency would normally be available but is
+temporarily not installable, the autobuilder fails rather than install a
+subsequent dependency that may significantly change the behavior of the
+package.
+
+More specifically, Debian autobuilders perform the following
+transformation on alternative dependencies in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields:
+
+#. Discard any alternatives that are restricted to architectures that do
+   not match the host architecture.
+#. Discard any alternatives specifying different package names than the
+   now-first alternative. (Alternatives specifying the same package name
+   are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
+
+For example, an autobuilder for the ``amd64`` architecture would treat the
+following dependency::
+
+foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Russ Allbery]

Charles Plessy  writes:

> In the spec, the word "paragraph" is only used in the specified context,
> so I always felt that there is no ambiguity.  But of course, it can
> create opportunities for misunderstanding when discussing about the
> spec.  So point taken about "paragraph", although interestingly, the
> Simple English definition of "paragraph" is quite spot on if one would
> replace "sentence" with "field": ”one or more sentences that are written
> together with no line breaks separating them.  Usually they are
> connected by a single idea.”
> ()

> The use of "paragraph" in the current spec is also consistent with
> Chapter 5 of the Policy, which also uses the word "paragraph".

Right, that's the motivation of this change.  It didn't start as being
about the copyright file, but about Policy.  Guillem was standardizing
terminology in dpkg.

I don't have a strong opinion about what word we choose.  I care more
about a few surrounding principles, specifically:

* We should use the same terminology when describing the copyright file as
  when describing Debian control files (and every other deb822 file).

* Policy should use the same terminology as dpkg.

* I'd prefer we not use the word "paragraph" because we also use that word
  to talk about normal prose paragraphs in the Description control field,
  and may similarly need to talk about prose paragraphs in the copyright
  file.

> By the way, in section 5.6.26 of the Policy, the word "stanza" is also
> used to mean something else than a "paragraph".

Thanks, I think regardless of how we resolve this bug that usage was
confusing.  It was also using two terms for the same concept in the same
section, since earlier the same construction was referred to as a
"portion."  I've fixed this to use "portion" consistently in this section.

-- 
Russ Allbery (r...@debian.org)  

Bug#1020275: dpkg-dev: Please add support for -D_FORTIFY_SOURCE=3 hardening build flag

[Guillem Jover]

Control: tags -1 moreinfo

On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: wishlist

> According to
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level,
> _FORTIFY_SOURCE=3 improves memory management protections. It requires
> glibc 2.34. It's been supported in Clang "for some time" and support
> was added to GCC 12. I understand it has some performance impact.

It would be nice to understand what's the impact here. Paul Wise also
mentioned a thread on .

If the intention is to update the default, then that would require a
discussion on d-d:

  


> I suppose we don't want to switch hardening=fortify fortification
> level 3, at least to start with.
> 
> So perhaps a new hardening=XYZ flag could allow package maintainers to
> opt-in?

The main problem is that any new feature added to an area such as
hardening will be automatically picked up by anything that is
currently specifying hardening=all. :/

I've been pondering about managing this kind of thing via
, but I
don't think that would even help with the =all problem. So I was
thinking a potential solution would be to version the =all request
somehow.

We'd have =all meaning level 0, then say =all-v1 for the new defaults,
that would also mean we can safely add new features that will not be
part of the current =all.

Thanks,
Guillem

Bug#1020267: Essential packages only provide functionality after being configured

[Russ Allbery]

Guillem Jover  writes:
> On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote:
>> Helmut Grohne  writes:
>>> […] It can be made explicit in section 3.8 quite easily:

>>>  Since dpkg will not prevent upgrading of other packages while an
>>>  ``essential`` package is in an unconfigured state, all ``essential``
>>>  packages must supply all of their core functionality even when
>>> -unconfigured. If the package cannot satisfy this requirement it must not
>>> +unconfigured after being configured at least once.
>>> +If the package cannot satisfy this requirement it must not
>>>  be tagged as essential, and any packages depending on this package must
>>>  instead have explicit dependency fields as appropriate.

> Seconded.

Thanks, this has been applied for the next release.

-- 
Russ Allbery (r...@debian.org)  

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Russ Allbery]

Russ Allbery  writes:

> Here is a patch that I believe implements that, and which I think is
> ready for seconds.

Thanks for the review, both.  This has now been applied for the next
release.

-- 
Russ Allbery (r...@debian.org)  

Bug#1020542: inetutils: telnet[d] descriptions: suggest different alternative packages

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Fri, 2022-09-23 at 02:20:21 +0200, Bastian Germann wrote:
> Source: inetutils
> Version: 2:2.3-5
> Severity: wishlist
> Control: block 1018949 by -1

> To help with #1018949 (netkit-telnet: Drop in favour of netkit-telnet-ssl),
> please suggest to install telnet[d]-ssl in the telnet[d] descriptions
> instead of the lately introduced packages.
> 
> This can prevent introducing the new netkit-telnet[d] packages in bookworm.
> They are unnecessary and duplicate code in the archive.

I agree with the sentiment, but I'd like to hear what Simon has to say
about this, and whether the packages are going to stay or not.

> I have included a patch that applies on the current main branch.

Thanks! Depending on what Simon says, I'd either merge this, or amend
it to add the references in addition to the current ones.

I also think the blocking is backwards, as this is not my decision to
make, only to sync the documentation with reality, on what might
happen on the netkit-telnet side. :)

Thanks,
Guillem

Bug#1018949: netkit-telnet: Drop in favour of netkit-telnet-ssl

[Bastian Germann]

Am 09.09.22 um 12:57 schrieb Simon Josefsson:

Just to be clear on this: There is one thing that you need to do to
enable clear-text use of in.telnetd:
It needs the command line argument -z nossl. This should be stated in
the telnetd package's description on the last
sentence: If you want to keep using the netkit implementation, then
install telnetd-ssl instead and run in.telnetd with
the argument -z nossl for the clear-text protocol.

Ah right.  That's the kind of differences between netkit-telnet and
netkit-telnet-ssl I was worried about, and having confidence there
aren't more of them seems challenging.  Help wanted here, if you want
to drive some particular change, feel free to do it!


As the automatic package transition is from the netkit packages to inetutils,
it is okay to have an additional flag to set when people decide to continue
using telnetd-ssl. I am confident that you do not need any other changes to
run telnet or telnetd compatibly.

I have asked for the suggested description change in #1020542.
When that is done, I would kindly ask you to reassign this bug as a RM bug or
allow me to do that for you. It would be nice of you to adopt the
netkit-telnet-ssl package instead.

Bug#1020542: inetutils: telnet[d] descriptions: suggest different alternative packages

[Bastian Germann]

Source: inetutils
Version: 2:2.3-5
Severity: wishlist
Control: block 1018949 by -1

To help with #1018949 (netkit-telnet: Drop in favour of netkit-telnet-ssl),
please suggest to install telnet[d]-ssl in the telnet[d] descriptions
instead of the lately introduced packages.

This can prevent introducing the new netkit-telnet[d] packages in bookworm.
They are unnecessary and duplicate code in the archive.

I have included a patch that applies on the current main branch.From: Bastian Germann 
Date: Fri, 23 Sep 2022 02:08:08 +0200
Subject: Mention the netkit ssl-enabled packages

To help with #1018949 (netkit-telnet: Drop in favour of netkit-telnet-ssl),
suggest to install telnet[d]-ssl in the telnet[d] descriptions.

This prevents introducing the new netkit-telnet[d] packages in bookworm.
They are unnecessary and duplicate code in the archive.
---
 debian/control | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index fd9b525..088862e 100644
--- a/debian/control
+++ b/debian/control
@@ -177,7 +177,7 @@ Description: transitional dummy package for inetutils-telnet default switch
  provided after Debian bookworm's release.
  .
  If you want to keep using the netkit implementation, then install
- netkit-telnet instead.
+ telnet-ssl instead.
 
 Package: inetutils-telnetd
 Architecture: any
@@ -217,7 +217,8 @@ Description: transitional dummy package for inetutils-telnetd default switch
  provided after Debian bookworm's release.
  .
  If you want to keep using the netkit implementation, then install
- netkit-telnetd instead.
+ telnetd-ssl instead and run in.telnetd with the argument -z nossl for the
+ clear-text protocol.
 
 Package: inetutils-talk
 Architecture: any

Bug#966000: tag

[Bastian Germann]

Control: tags -1 pending

On Fri, 2 Sep 2022 22:26:51 +0200 franc...@mzf.fr wrote:

Bastian or Antoine, would you like to review and sponsor the upload?


Done.

Bug#1020267: Essential packages only provide functionality after being configured

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 20:27:46 -0700, Russ Allbery wrote:
> Helmut Grohne  writes:
> > […] It can be made explicit in section 3.8 quite easily:
> 
> >  Since dpkg will not prevent upgrading of other packages while an
> >  ``essential`` package is in an unconfigured state, all ``essential``
> >  packages must supply all of their core functionality even when
> > -unconfigured. If the package cannot satisfy this requirement it must not
> > +unconfigured after being configured at least once.
> > +If the package cannot satisfy this requirement it must not
> >  be tagged as essential, and any packages depending on this package must
> >  instead have explicit dependency fields as appropriate.

Seconded.

Thanks,
Guillem


signature.asc
Description: PGP signature

Bug#1020464: www.debian.org: debian.org cookie logged_out_marketing_header_id

[Paul Wise]

Control: close -1

On Thu, 2022-09-22 at 15:27 +, Thorsten Glaser wrote:
> > Searching for the name indicates this is a GitLab/salsa cookie,
> > but I would expect that would set the cookie on salsa.d.o not d.o.
> > 
> > https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76076
> 
> Bingo!

As this is a bug in salsa.d.o not www.d.o, I am closing this bug.

I think the way to solve this more generally is to have your browser
never save cookies unless you approve them manually, but I understand
this functionality probably isn't available in lynx and requires using
browser extensions in other browsers.

I suggest you check if this issue also occurs with other GitLab
instances, such as the GNOME or FreeDesktop ones. If it occurs
elsewhere then talk to GitLab upstream about the problem so it
gets fixed everywhere. Otherwise talk to the Salsa admins.

https://gitlab.gnome.org/
https://gitlab.freedesktop.org/
https://gitlab.com/gitlab-org/gitlab/-/issues
https://wiki.debian.org/Salsa#Maintenance

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 19:36:36 -0700, Russ Allbery wrote:
> Felix Lechner  writes:
> > The installable stanzas in d/control (called "binary package paragraphs"
> > in policy) inherit the Section field from the source paragraph. There is
> > no reason to provide inheritance the other way around.
> 
> Huh, this pointed out to me that I don't know what the current behavior
> is.  I think I've always put a Section field in the first stanza and then
> overridden it as necessary, or at least I don't remember thinking about
> this before.

If you omit the field in the source stanza, then both dpkg-genchanges
and lintian will complain about it with a warning.

> The current Policy description of the Section field is rather cryptic:
> 
> This field specifies an application area into which the package has
> been classified. See Sections.
> 
> When it appears in the debian/control file, it gives the value for the
> subfield of the same name in the Files field of the .changes file. It
> also gives the default for the same field in the binary packages.
> 
> I understand what it's trying to say, but that's a very mechanical
> definition that isn't clear about the relationship between the Section
> field in the source stanza and the Section field in the binary stanzas.
> (It also claims Section is about an "application area," a term that I
> don't think we use anywhere else in Policy.)
> 
> So, what happens today if you put Section in a binary stanza but not in
> the source stanza?  Is it inherited from the binary stanza by the source
> stanza (I agree that seems weird)?  If so, from which binary stanza is it
> inherited, if there are several?  The definition of the Files field
> implies that the section may just be - in some cases.

Some of the fields found in the debian/control binary stanzas inherit
their values (if omitted) from the source stanza, otherwise they get
overridden.

The binary packages use a combination of information from
debian/changelog, the source stanza and their own binary stanza.

For non-binary packages (sources) or artifacts (say .buildinfo, or
byhand objects) there are no binary stanzas, so no information is
taken from them.

If you specify a Section field for every binary stanza, and omit it
from the source stanza, then dpkg-genchanges will have to fill it with
«-» when generating the .changes file.

If you omit the Section field from both the source stanza and one of
the binary stanzas, then that binary package will contain no Section
field, dpkg-genchanges will warn about both missing fields, and it
will fill the section value as «-» for that binary package on the
.changes file.

Thanks,
Guillem

Bug#1020541: transition: rakudo

[M. Zhou]

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

Dear release team,

We would like to upload rakudo 2022.07 to unstable (2022.04).
Hence requesting this transition to rebuild all raku packages.


Ben file:

title = "rakudo";
is_affected = .depends ~ "raku-api-2022.04" | .depends ~ "raku-api-2022.07";
is_good = .depends ~ "raku-api-2022.07";
is_bad = .depends ~ "raku-api-2022.04";
Thank you for using reportbug

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 21:42:37 -0700, Russ Allbery wrote:
> "Daniel Shahaf"  writes:
> > Here's a revision of the patch incorporating the feedback so far:
> 
> Thank you for this patch!  I confirmed that your description matches the
> regular expression.  This has now been applied for the next release of
> Debian Policy.

I also committed a changed based off this patch to dpkg's
deb-changelog(5) man page, which I mentioned some time ago I'd do,
but probably didn't as I thought the patch here still had the issue
discussed at the time.

Thanks,
Guillem

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Guillem Jover]

Hi!

On Thu, 2022-09-22 at 14:26:38 +0900, Charles Plessy wrote:
> Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> > I do find the use of paragraph the way we were previously using it to
> > be confusing, particularly given that the paragraphs contain fields
> > which in turn contain actual paragraphs in the normal sense of the
> > term.

Idem.

> > I don't want to keep using paragraph, but I'd be open to some other term
> > that Guillem was also open to (I think matching the terminology in dpkg is
> > very important).  Section or block are commonly used for things like this,
> > but aren't very precise, so I'm not that enthused by them.
> 
> In the spec, the word "paragraph" is only used in the specified context,
> so I always felt that there is no ambiguity.  But of course, it can
> create opportunities for misunderstanding when discussing about the
> spec.  So point taken about "paragraph", although interestingly, the
> Simple English definition of "paragraph" is quite spot on if one would
> replace "sentence" with "field": ”one or more sentences that are written
> together with no line breaks separating them.  Usually they are
> connected by a single idea.” ()

In the end nothing will match exactly, and we need to choose some
terminology. In this case, as previously mentioned, «stanza» has the
good properties of not usually applying to prose, being short, distinct
from the other terms and the less ambiguous of them all. It also makes
constructing sentences to describe things less cumbersome.

> I do not mind the word "section".  It is the term used in the manual
> page "systemd.syntax" that describes systemd's unit files, which means
> that readers may be already familiar with the concept.  One could argue
> that its definition in Simple English
> (, “A section of a thing or
> place is a part of it”) would allow a reader to think that a Field is
> also a section, but I feel it is unlikely to happen.  This said, one big
> disadvantage of "section" is that when searching for this word in a
> document, there may be a lot of noisy hits such as "refer to section xyz
> for details".

The problems with section, is that as you mention is not very
searchable, but worse we already have a field with the same name!

> I understand about avoiding ambiguity, but in my opinion it is the price
> to pay to be able to translate information into simple words from
> English to non-European languages.  Although the Policy itself is not
> going to be translated, I think that it can be advantageous if its
> contents can be discussed in simple words in people's native languages.

As a non-native speaker, and a translator, I agree having clear
wording in the original text is important, as otherwise that tends to
make translation work harder. But then, part of that work is to find
or create terminology, in many cases not existing yet in the
translated language, that might be suitable there, trying several terms
that might not necessarily be direct translations.

For a translation anecdote related to finding the right terms, when
triggers got introduced, and having to translate them to Catalan, we
initially used «gallets» (which would be the direct translation). But
when reading them that was bothering several of us as it sounded weird,
it could be read as “small roosters” («gall» being rooster, and «ets»
forming the plural diminutive), or being too close to «galets» which is
a type of pasta used for example in «sopa de galets» ("galets" soup). We
then switched to «activadors» which sounds way nicer, even though it's
not a direct translation. But if we had to translate the spec today,
that would be annoying as it uses «activating» all over the place, so
perhaps using «disparador» would be better. So, in the end this is a
process too, and terms can be changed if they are deemed confusing or
not helping convey the meaning. And in some others, you just need to
simply create new terminology, and describe what it means in specific
contexts.


For example for Catalan/Spanish «stanza» is simply «estrofa» which
seems like a nice term to use here.

Thanks,
Guillem

Bug#1020540: podman-remote should be built and offered as seperate package

[Norbert Lange]

Package: podman
Version: 4.2.1-0.1
Severity: minor
Tags: patch
X-Debbugs-Cc: nolang...@gmail.com

Hello,

I am aware of #1000521, I dont see it as resolved.

The problem is that you can run podman as service, and clients
can connect on for ex. an exposed unix socket.

Practical example is:

-   run rootless podman providing an unix socker
-   run an container jenkins/inbound-agent container
binding that socket
-   provide a binary that takes the same arguments as docker
while using the socket

Now the issue is, that you have to install podman and its many
dependencies in the jenkins/inbound-agent container.

Way better would be to use one of the simple remote-only clients,
this is a single file without any dependencies
(run ldd on both).

docker provides the docker-ce-cli package, podman the podman-remote
binary.

Debian should offer the package as independent package,
so client/server can be updated together.
Then containers can get a bind-mount to the host's
/usr/bin/podman-remote binary.


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

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

Versions of packages podman depends on:
ii  conmon   2.1.3+ds1-1
ii  crun 1.5+dfsg-1+b1
ii  golang-github-containers-common  0.49.1+ds1-1
ii  libc62.34-7
ii  libdevmapper1.02.1   2:1.02.185-1
ii  libgpgme11   1.17.1-4.1
ii  libseccomp2  2.5.4-1+b1

Versions of packages podman recommends:
pn  buildah   
pn  catatonit | tini | dumb-init  
ii  dbus-user-session 1.14.0-2
pn  fuse-overlayfs
ii  slirp4netns   1.2.0-1
ii  uidmap1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.42.0+ds1-1
pn  docker-compose  
ii  iptables1.8.8-1

-- no debconf information
diff -burN a/debian/control b/debian/control
--- a/debian/control2022-08-19 09:43:54.0 +0200
+++ b/debian/control2022-08-19 09:43:54.0 +0200
@@ -131,6 +131,32 @@
  .
  Podman is a daemon-less alternative to Docker.
 
+Package: podman-remote
+Architecture: any
+Built-Using: ${misc:Built-Using}
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: engine to run OCI-based containers in Pods
+ Podman is an engine for running OCI-based containers in Pods.
+ Podman provides a CLI interface for managing Pods, Containers, and
+ Container Images.
+ .
+ At a high level, the scope of libpod and podman is the following:
+  * Support multiple image formats including the OCI and Docker image
+formats.
+  * Support for multiple means to download images including trust & image
+verification.
+  * Container image management (managing image layers, overlay filesystems,
+etc).
+  * Full management of container lifecycle.
+  * Support for pods to manage groups of containers together.
+  * Resource isolation of containers and pods.
+  * Support for a Docker-compatible CLI interface through Podman.
+ .
+ Podman is a daemon-less alternative to Docker.
+ .
+ This package installs a smaller executable being only a
+ frontend to control a remote podman instance.
+
 Package: golang-github-containers-libpod-dev
 Architecture: all
 Depends: ${misc:Depends},
diff -burN a/debian/podman.install b/debian/podman.install
--- a/debian/podman.install 2022-08-19 09:43:54.0 +0200
+++ b/debian/podman.install 2022-08-19 09:43:54.0 +0200
@@ -1,5 +1,4 @@
 completions/zsh/_podman /usr/share/zsh/vendor-completions
-completions/zsh/_podman-remote  /usr/share/zsh/vendor-completions
 cni/87-podman-bridge.conflist  /etc/cni/net.d/
 
 debian/etc/containers/libpod.conf  /etc/containers/
diff -burN a/debian/podman-remote.install b/debian/podman-remote.install
--- a/debian/podman-remote.install  1970-01-01 01:00:00.0 +0100
+++ b/debian/podman-remote.install  2022-08-19 09:43:54.0 +0200
@@ -0,0 +1,3 @@
+completions/zsh/_podman-remote  /usr/share/zsh/vendor-completions
+
+usr/bin/podman-remote
diff -burN a/debian/podman-remote.manpages b/debian/podman-remote.manpages
--- a/debian/podman-remote.manpages 1970-01-01 01:00:00.0 +0100
+++ b/debian/podman-remote.manpages 2022-08-19 09:43:54.0 +0200
@@ -0,0 +1 @@
+docs/build/man/podman-remote*.1
diff -burN a/debian/rules b/debian/rules
--- a/debian/rules  2022-08-19 09:43:54.0 +0200
+++ b/debian/rules  2022-09-23 00:38:15.821251178 +0200
@@ -36,6 +36,7 @@
 
 ## https://podman.io/getting-started/installation#build-tags
 BUILDTAGS := apparmor,ostree,seccomp,

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Alberto Garcia]

On Thu, Sep 22, 2022 at 07:45:29AM +0900, Dominique MARTINET wrote:

> If you have time to build a package you might be faster than me, so
> I'd appreciate it :)

Hi, I built two sets of packages, the unpatched vanilla version of
2.38.0 and the one with the patch I mentioned in my previous comment:

https://people.debian.org/~berto/files/webkitgtk-2.38.0-arm64/

Can you test them both and tell me if things get better?

Thanks!

Berto

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

The issue also occurs when using the lookupcache=none option along with the 
5.10.X kernel.
I was hoping for this option to succeed and to investigate the performance 
impact, but it is no longer viable.
I believe that I am out of options to try with the 5.10.X kernel.
Please let me know where we stand.

> -Original Message-
> From: Jason Breitman
> Sent: Wednesday, September 21, 2022 1:01 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I now know that this behavior does exist in Debian Buster 10.8 and more
> specifically in the 4.19.X kernel after running stricter testing on more 
> servers.
> The 4.19.X kernel resolves itself immediately following the No such file or
> directory error which is different than the 5.X kernel requiring me to clear 
> the
> inode and dentry cache by running echo 2 > /proc/sys/vm/drop_caches.
> What further information is required to resolve this issue?
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Tuesday, September 13, 2022 4:41 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I downgraded the nfs-common package which required the downgrade of
> > the libevent packages and am using the 4.19.X kernel.
> > I see the issue running the initial test, but then the issue is gone when
> > running the test a subsequent time.
> >
> > libevent-2.1-6:amd64  2.1.8-stable-4
> > amd64
> > Asynchronous event notification library
> > libevent-core-2.1-6:amd64 2.1.8-stable-4
> > amd64
> > Asynchronous event notification library (core)
> > libevent-pthreads-2.1-6:amd64 2.1.8-stable-4
> > amd64
> > Asynchronous event notification library (pthreads)
> > linux-image-4.19.0-21-amd644.19.249-2  
> > amd64Linux
> > 4.19 for 64-bit PCs (signed)
> > nfs-common  1:1.3.4-2.5+deb10u1 
> >amd64NFS
> > support files common to client and server
> >
> > What other packages do I need to downgrade in order to get Debian 11.4 to
> > behave like Debian 10.8?
> > What additional questions can I answer so that we can move forward?
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Tuesday, September 6, 2022 5:18 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I also see the failure with the kernels below, but the 4.19.X kernel
> resolves
> > > the issue without dropping caches.
> > > linux-image-4.19.0-14-amd64   4.19.171-2 amd64
> > > Linux 4.19
> > for
> > > 64-bit PCs (signed)
> > > linux-image-4.19.0-21-amd64   4.19.249-2 amd64
> > > Linux 4.19
> > for
> > > 64-bit PCs (signed)
> > >
> > > I see the issue running the initial test, but then the issue is gone when
> > > running the test a subsequent time.
> > > I ran several tests to verify the behavior differences between the 4.19.X
> > and
> > > 5.X kernels.
> > >
> > > -- Test
> > > ls -l /mnt/dir/someOtherDir/* | grep '?'
> > >
> > > -- Error message - the error message is showing files that have been
> erased
> > > via rsync --delete
> > > ls: cannot access 'filename': No such file or directory
> > > -? ? ???? filename
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Friday, September 2, 2022 5:17 PM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > I have tested with the following kernels and see this issue in each 
> > > > case.
> > > >
> > > > linux-image-5.10.0-16-amd64  5.10.127-1 
> > > >  amd64
> > > Linux
> > > > 5.10 for 64-bit PCs (signed)
> > > > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  
> > > > amd64
> > > > Linux 5.15 for 64-bit PCs (signed)
> > > > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> > > > Linux 5.18 for 64-bit PCs (signed)
> > > >
> > > > An interesting note is that when using the 5.18 kernel, I had to run 
> > > > echo
> 3
> > >
> > > > /proc/sys/vm/drop_caches to resolve the issue.
> > > > echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10
> and
> > > > 5.15 kernels.
> > > >
> > > > > -Original Message-
> > > > > From: Jason Breitman
> > > > > Sent: Friday, August 26, 2022 3:36 PM
> > > > > To: 'Ben Hutchings' ;
> > '1017...@bugs.debian.org'
> > > > > <1017...@bugs.debian.org>
> > > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > > >
> > > > > I was able to identify another workaround today which may help you
> to
> > > > > identify the issue.
> > > > > The work

Bug#1019845: transition: glibc 2.35

[Aurelien Jarno]

On 2022-09-22 23:51, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-09-18 10:11:58 +0200, Sebastian Ramacher wrote:
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/glibc-2.35.html
> > 
> > On 2022-09-14 22:17:47 +0200, Aurelien Jarno wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > > 
> > > Dear release team,
> > > 
> > > I would like to get a transition slot for glibc 2.35. It has been
> > > available in experimental for one month and does not have any known
> > > major issue. It has been built successfully on all release architectures
> > > and many ports architectures. A few issues found through the autopkgtest
> > > pseudo excuses for experimental have been fixed. The remaining ones are
> > > due to britney bugs, broken autopkgtest or packages parts of the
> > > transition.
> > > 
> > > As glibc is using symbol versioning, there is no soname change. That
> > > said a few packages are using libc internal symbols and have to be
> > > rebuilt for this transition. Here is the corresponding ben file:
> > > 
> > >   title = "glibc";
> > >   is_affected = .depends ~ /libc[0-9.]* \(< > >   is_good = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> > >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.35\)/;
> > > 
> > > In addition a few new symbols have been added that might prevent a few
> > > other packages to migrate to testing until glibc migrates if they pick
> > > up the new symbols, however those are really limited in this version and
> > > mostly linked to the new math functions introduced for ISO C2x support,
> > > so unlikely to be massively used by default. Therefore overall this
> > > transition should be way simpler than the glibc 2.34 one.
> > > 
> > > Thanks for considering.
> > 
> > Let's start with this one after the udeb block is lifted and the D-I
> > alpha is done.
> 
> The udeb block was lifted. Please go ahead.

Thanks. I have uploaded it it, but it seems to be stuck in a dinstall
that takes a lot of time. I guess it'll be there (and maybe built on
some architectures) when I wake up tomorrow :)

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Steinar H. Gunderson]

On Fri, Sep 23, 2022 at 12:09:45AM +0200, Ondřej Surý wrote:
> Nope, the plan to follow upstream releases was acked by both the security
> and release teams, so I am not doing anything really surprising here.

Well, it is really surprising to users :-) Other packages that have been
doing the same thing (e.g. firefox and chromium) have been explicit about
fixing-by-wholesale-upgrading in the advisory in the past.

> So, let’s focus on what could be improved here. I don’t think anything like
> this will happen ever again in 9.16, but I’ll try to be more vigilant about
> possibly breaking changes next time.
> 
> Also Steinar, while I understand this has caused you some distress, this is
> not really a grave bug. It does not make: the package in question unusable
> or mostly so, or causes data loss, or introduces a security hole allowing
> access to the accounts of users who use the package.

I'm fine with downgrading the severity (it's mostly semantics anyway);
but do note that security updates are treated differently from nearly every
other update. In particular, unattended-upgrades will install them by
default, and administrators are urged to install them as quickly as possible
on their production servers without testing in a staging environment first.
This makes them much more sensitive than a normal stable update, which goes
through proposed-stable-updates first.

In our case, it happened to break the entire system; it uses 127.0.0.1
in resolv.conf, and login uses Kerberos, which is dependent on DNS...

Note that if we add “inline-signing yes;” on all of the zones with
dnssec-policy on, BIND crashes with an assertion failure on reloading the
config:

  Sep 22 22:32:52 cirkus named[3064511]: rbtdb.c:6837: REQUIRE(((rbtnode->nsec 
== DNS_RBT_NSEC_NSEC3 && (rdataset->type == 
((dns_rdatatype_t)dns_rdatatype_nsec3) || rdataset->covers == 
((dns_rdatatype_t)dns_rdatatype_nsec3))) || (rbtnode->nsec != 
DNS_RBT_NSEC_NSEC3 && rdataset->type != ((dns_rdatatype_t)dns_rdatatype_nsec3) 
&& rdataset->covers != ((dns_rdatatype_t)dns_rdatatype_nsec3 failed, back 
trace
  Sep 22 22:32:52 cirkus named[3064511]: #0 0x55dd86375f1d in ??
  Sep 22 22:32:52 cirkus named[3064511]: #1 0x7fddb899090a in ??
  Sep 22 22:32:52 cirkus named[3064511]: #2 0x7fddb8ac981c in ??
  Sep 22 22:32:52 cirkus named[3064511]: #3 0x7fddb8b9a461 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #4 0x7fddb89c36bd in ??
  Sep 22 22:32:52 cirkus named[3064511]: #5 0x7fddb89ac6a9 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #6 0x7fddb89ac825 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #7 0x7fddb89ad003 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #8 0x7fddb876ee7d in ??
  Sep 22 22:32:52 cirkus named[3064511]: #9 0x7fddb8780a23 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #10 0x7fddb876f714 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #11 0x7fddb89ac8d7 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #12 0x7fddb89c5ec6 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #13 0x7fddb8745ea7 in ??
  Sep 22 22:32:52 cirkus named[3064511]: #14 0x7fddb8327aef in ??
  Sep 22 22:32:52 cirkus named[3064511]: exiting (due to assertion failure)

This is the old version, though, so it might be better with the new one.

> As I said in the other email, I’ll take a look if I can soften the
> requirement for the configuration in the Debian package tomorrow. Perhaps
> just downgrade it to a prominent warning instead of hard error.

That would be most appreciated, yes.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1020539: xmlcopyeditor: xml copyeditor fails wxwidgets3.2 sizer checks

[Olly Betts]

Package: xmlcopyeditor
Version: 1.2.1.3-4.3
Severity: serious
Justification: makes the package in question unusable or mostly so
X-Debbugs-Cc: s...@techie.net

Since the update to use wxwidgets3.2, xmlcopyeditor pops up "An
assertion failed!" dialogs on startup, with similar messages on
stderr:

$ xmlcopyeditor 
./src/common/sizer.cpp(2258): assert "CheckSizerFlags(!((flags) & 
(wxALIGN_CENTRE_VERTICAL)))" failed in DoInsert(): wxALIGN_CENTRE_VERTICAL will 
be ignored in this sizer: only horizontal alignment flags can be used in 
vertical sizers

DO NOT PANIC !!

If you're an end user running a program not developed by you, please ignore 
this message, it is harmless, and please try reporting the problem to the 
program developers.

You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to 
suppress all such checks when running this program.

If you're the developer, simply remove this flag from your code to avoid 
getting this message. You can also call 
wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, 
but this is strongly not recommended.

This is because wx3.2 added consistency checks to sizer flag use and
moans when there are flags which don't make sense (which previously
were quietly ignored).

There seem to be two assertions that fail.

This fixes one of them:

diff -ru ../xmlcopyeditor-1.2.1.3/src/commandpanel.cpp 
xmlcopyeditor-1.2.1.3/src/commandpanel.cpp
--- ../xmlcopyeditor-1.2.1.3/src/commandpanel.cpp   2014-09-06 
13:54:53.0 +1200
+++ xmlcopyeditor-1.2.1.3/src/commandpanel.cpp  2022-09-21 16:23:36.927423010 
+1200
@@ -135,7 +135,7 @@
bottomSizer->Add ( outputSizer, 0, wxLEFT | wxRIGHT | 
wxALIGN_CENTER_VERTICAL, sizerOffset );
 
mainSizer = new wxBoxSizer ( wxVERTICAL );
-   mainSizer->Add ( commandEdit, 0, wxLEFT | wxRIGHT | 
wxALIGN_CENTER_VERTICAL | wxEXPAND, sizerOffset );
+   mainSizer->Add ( commandEdit, 0, wxLEFT | wxRIGHT | wxEXPAND, 
sizerOffset );
mainSizer->Add ( bottomSizer );
 
 
I didn't locate the other one from a quick look (the backtrace in the dialog
doesn't show any locations in xmlcopyeditor's code, even with the dbgsym
installed).

It's possible there are further problems if any sizers are built on demand
rather than at startup - I did a quick run through the menus and didn't hit
any, but I'm not an active user of this app.

Cheers,
Olly

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

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

Versions of packages xmlcopyeditor depends on:
ii  libaspell15 0.60.8-4+b1
ii  libc6   2.34-8
ii  libexpat1   2.4.8-2
ii  libgcc-s1   12.2.0-3
ii  libpcre32:8.39-14
ii  libstdc++6  12.2.0-3
ii  libwxbase3.2-0  3.2.1+dfsg-1
ii  libwxgtk3.2-0   3.2.1+dfsg-1
ii  libxerces-c3.2  3.2.3+debian-3+b1
ii  libxml2 2.9.14+dfsg-1+b1
ii  libxslt1.1  1.1.35-1

xmlcopyeditor recommends no packages.

xmlcopyeditor suggests no packages.

-- no debconf information

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Ondřej Surý]

Control: severity -1 important

Nope, the plan to follow upstream releases was acked by both the security and 
release teams, so I am not doing anything really surprising here. BIND 9 
packages are following the patch releases for each minor release (in the 
traditional major.minor.patch version triplet).

So, let’s focus on what could be improved here. I don’t think anything like 
this will happen ever again in 9.16, but I’ll try to be more vigilant about 
possibly breaking changes next time.

Also Steinar, while I understand this has caused you some distress, this is not 
really a grave bug. It does not make: the package in question unusable or 
mostly so, or causes data loss, or introduces a security hole allowing access 
to the accounts of users who use the package.

As I said in the other email, I’ll take a look if I can soften the requirement 
for the configuration in the Debian package tomorrow. Perhaps just downgrade it 
to a prominent warning instead of hard error.

Ondřej
--
Ondřej Surý  (He/Him)

> On 22. 9. 2022, at 23:16, Steinar H. Gunderson  wrote:
> 
> On Thu, Sep 22, 2022 at 08:13:53PM +0200, Ondřej Surý wrote:
>> I am sorry this has caused inconvenience for you, but the original problem 
>> here was that the implicit inline-signing with the dnssec-policy was also 
>> problematic and causing other problems, see the upstream issue: 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381
>> 
>> Especially this: 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381#note_308893
> 
> Sure, but that's not appropriate to change in a stable-security update.
> You can ask the SRMs whether it is applicable for a stable update
> (I would say no; the point of stable is that you know what issues
> you have and don't get new ones), but you cannot just put it into
> a security update unless they are positively required for the security
> issues in question.
> 
> /* Steinar */
> -- 
> Homepage: https://www.sesse.net/

Bug#1015207: transitions: ruby3.1-add

[Antonio Terceiro]

On Tue, Sep 20, 2022 at 09:04:11AM -0300, Antonio Terceiro wrote:
> On Mon, Sep 19, 2022 at 09:07:50AM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 = confirmed
> > 
> > On 2022-09-12 15:28:38 -0300, Antonio Terceiro wrote:
> > > Hi,
> > > 
> > > On Sun, Jul 17, 2022 at 02:08:14PM -0300, Lucas Kanashiro wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > Tags: moreinfo
> > > > 
> > > > Hi,
> > > > 
> > > > We would like to add support for ruby3.1 in ruby-defaults in unstable
> > > > soon. The ben file was already added to the transition tracker as
> > > > planned by elbrus.
> > > 
> > > I would like to start this transition, by uploading ruby-defaults
> > > enabling building against ruby3.1 to unstable. All the packages listed
> > > in the transition page build correctly, except a few ones. They all have
> > > bugs reported, and I just raised their severity to serious:
> > 
> > Please go ahead
> 
> Just uploaded. I have a few notes to the list of binNMUs below.

Thanks for the initial round of binNMUs. I'm going through the failures
and either fixing them or reporting bugs.

Please update the transition tracker with the attached patch.
From 45cd37e15c3e478e979dada18a7a5d8fe2dfeaab Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Thu, 22 Sep 2022 18:59:16 -0300
Subject: [PATCH] ruby3.1-add: ignore new package that builds only for the
 default ruby

---
 ongoing/ruby3.1-add.ben | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ongoing/ruby3.1-add.ben b/ongoing/ruby3.1-add.ben
index 5cf29c4..4eeb7a3 100644
--- a/ongoing/ruby3.1-add.ben
+++ b/ongoing/ruby3.1-add.ben
@@ -1,5 +1,5 @@
 title = "ruby3.1-add";
-is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & ! .source ~ /^(ruby3\.0|ruby3\.1|ruby-defaults|dislocker|epic5|graphviz|hivex|kamailio|klayout|kross-interpreters|libprelude|marisa|ngraph-gtk|notmuch|obexftp|redland-bindings|rubyluabridge|ruby-standalone|subtle|subversion|uwsgi|vim-command-t|weechat|robot-testing-framework|treil|vim|nbdkit)$/;
+is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & ! .source ~ /^(ruby3\.0|ruby3\.1|ruby-defaults|dislocker|epic5|graphviz|hivex|kamailio|klayout|kross-interpreters|libprelude|marisa|ngraph-gtk|notmuch|obexftp|redland-bindings|rubyluabridge|ruby-standalone|subtle|subversion|uwsgi|vim-command-t|weechat|robot-testing-framework|treil|vim|nbdkit|ignition-math|)$/;
 is_good = .depends ~ /ruby3.1/;
 is_bad = .depends ~ /ruby3.0/ & !.depends ~ /ruby3.1/;
 notes = "#1015207 ";
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 21:21:23 -0700, Russ Allbery wrote:
> Here is a patch to fix this wording in Policy.  I think it's ready for
> seconds.

> >From c98654d7effa875c6e11da16159ac3feded8f763 Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 21:17:55 -0700
> Subject: [PATCH] Binary and Description optional in .changes
> 
> In .changes files for source-only uploads, the Binary and
> Description fields are not present.  Document this, and be clearer
> in the description of the Description field for .changes files that
> only descriptions of binary packages are included.
> ---
>  policy/ch-controlfields.rst | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..f85f75d 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -278,7 +278,7 @@ The fields in this file are:
>  
>  -  :ref:`Source ` (mandatory)
>  
> --  :ref:`Binary ` (mandatory)
> +-  :ref:`Binary `

For deb-changes(5) I switched from “(required)” to “(required in
context)”, but I don't think there's any similar precedent in the
Debian policy. Just noting here mostly for reference or as possible
inspiration :), and not as any kind of blocker or conditional on
seconding.

>  
>  -  :ref:`Architecture ` (mandatory)
>  
> @@ -292,7 +292,7 @@ The fields in this file are:
>  
>  -  :ref:`Changed-By `
>  
> --  :ref:`Description ` (mandatory)
> +-  :ref:`Description `
>  
>  -  :ref:`Closes `
>  
> @@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on
>  this.
>  
>  In a ``.changes`` file, the ``Description`` field contains a summary of
> -the descriptions for the packages being uploaded. For this case, the
> -first line of the field value (the part on the same line as
> -``Description:``) is always empty. It is a multiline field, with one
> -line per package. Each line is indented by one space and contains the
> -name of a binary package, a space, a hyphen (``-``), a space, and the
> -short description line from that package.
> +the descriptions of the binary packages being uploaded. (``.changes``
> +files for uploads containing only source packages will not have this
> +field.)

Hmm, I guess that's fine, but perhaps it would be more precise and/or
future-proof to state instead that the field is only present if there
are binary packages included (or will be missing if they are not
present, but based on the binary packages instead of the source
packages)? Things that cross my mind might be say .changes that include
only byhand entries or similar, dunno.

> […] For this case, the first line of the field value (the part on the
> +same line as ``Description:``) is always empty. It is a multiline field,
> +with one line per binary package. Each line is indented by one space and
> +contains the name of a binary package, a space, a hyphen (``-``), a space,
> +and the short description line from that package.
>  
>  .. _s-f-Distribution:
>  
> @@ -924,7 +925,8 @@ every architecture. The source control file doesn't 
> contain details of
>  which architectures are appropriate for which of the binary packages.
>  
>  When it appears in a ``.changes`` file, it lists the names of the binary
> -packages being uploaded, separated by whitespace (not commas).
> +packages being uploaded, separated by whitespace (not commas). If only
> +source packages are being uploaded, this field will not be present.

Ditto.

>  
>  .. _s-f-Installed-Size:

Thanks,
Guillem

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Steinar H. Gunderson]

On Thu, Sep 22, 2022 at 08:13:53PM +0200, Ondřej Surý wrote:
> I am sorry this has caused inconvenience for you, but the original problem 
> here was that the implicit inline-signing with the dnssec-policy was also 
> problematic and causing other problems, see the upstream issue: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381
> 
> Especially this: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381#note_308893

Sure, but that's not appropriate to change in a stable-security update.
You can ask the SRMs whether it is applicable for a stable update
(I would say no; the point of stable is that you know what issues
you have and don't get new ones), but you cannot just put it into
a security update unless they are positively required for the security
issues in question.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1020538: ITP: golang-github-gopacket-gopacket -- Provides packet processing capabilities for Go

[Daniel Milde]

Package: wnpp
Severity: wishlist
Owner: Daniel Milde 

* Package name : golang-github-gopacket-gopacket
Version : 0.0~git20220825.b6a42f7-1
Upstream Author :
* URL : https://github.com/gopacket/gopacket
* License : BSD-3-clause
Programming Lang: Go
Description : Provides packet processing capabilities for Go

GoPacket
.
This library provides packet decoding capabilities for Go. Forked from
Google's repo (https://godoc.org/github.com/google/gopacket).


New dependency for fq.
It will be team-maintained within the Go Packaging Team.




OpenPGP_0xEF0BA1C4F3990103.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020537: ITP: golang-github-creasty-defaults -- Initialize structs with default values

[Daniel Milde]

Package: wnpp
Severity: wishlist
Owner: Daniel Milde 

* Package name : golang-github-creasty-defaults
Version : 1.6.0-1
Upstream Author : Yuki Iwanaga
* URL : https://github.com/creasty/defaults
* License : Expat
Programming Lang: Go
Description : Initialize structs with default values

defaults
.
Initialize structs with default values
.
* Supports almost all kind of types
* Scalar types
* int/8/16/32/64, uint/8/16/32/64, float32/64
* uintptr, bool, string
* Complex types
* map, slice, struct
* Nested types
* map[K1]map[K2]Struct, []map[K1]Struct[]
* Aliased types
* time.Duration
* e.g., type Enum string
* Pointer types
* e.g., *SampleStruct, *int
.
* Recursively initializes fields in a struct
* Dynamically sets default values by defaults.Setter (/setter.go)
interface
* Preserves non-initial values from being reset with a default value

New dependency for fq.
It will be team-maintained within the Go Packaging Team.




OpenPGP_0xEF0BA1C4F3990103.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020536: unicorn-engine: FTBFS on s390x: several test failures

[Antonio Terceiro]

Source: unicorn-engine
Version: 2.0.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Dear Maintainer,

unicorn-engine fails to build on s390x, with several test failures. It
seems to pass on all other release architectures.

8<8<8<-
FAILED: 26 of 33 unit tests have failed.


25% tests passed, 9 tests failed out of 12

Total Test time (real) =   0.31 sec

The following tests FAILED:
  1 - test_x86 (Failed)
  2 - test_arm (Failed)
  3 - test_arm64 (Failed)
  4 - test_m68k (Failed)
  5 - test_mips (Failed)
  7 - test_ppc (Failed)
  8 - test_riscv (Failed)
 11 - test_mem (Failed)
 12 - test_ctl (Failed)
Errors while running CTest
8<8<8<-

The full build log is available at
https://buildd.debian.org/status/fetch.php?pkg=unicorn-engine&arch=s390x&ver=2.0.0-3&stamp=1663852538&raw=0


signature.asc
Description: PGP signature

Bug#1019845: transition: glibc 2.35

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-09-18 10:11:58 +0200, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/glibc-2.35.html
> 
> On 2022-09-14 22:17:47 +0200, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.35. It has been
> > available in experimental for one month and does not have any known
> > major issue. It has been built successfully on all release architectures
> > and many ports architectures. A few issues found through the autopkgtest
> > pseudo excuses for experimental have been fixed. The remaining ones are
> > due to britney bugs, broken autopkgtest or packages parts of the
> > transition.
> > 
> > As glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition. Here is the corresponding ben file:
> > 
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(< >   is_good = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.35\)/;
> > 
> > In addition a few new symbols have been added that might prevent a few
> > other packages to migrate to testing until glibc migrates if they pick
> > up the new symbols, however those are really limited in this version and
> > mostly linked to the new math functions introduced for ISO C2x support,
> > so unlikely to be massively used by default. Therefore overall this
> > transition should be way simpler than the glibc 2.34 one.
> > 
> > Thanks for considering.
> 
> Let's start with this one after the udeb block is lifted and the D-I
> alpha is done.

The udeb block was lifted. Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Guillem Jover]

Hi!

On Tue, 2022-09-20 at 18:52:22 -0700, Russ Allbery wrote:
> Here is a patch that I believe implements that, and which I think is ready
> for seconds.

> >From 2260f7a3aafe93282860aad07b7d8c1544bcf0ce Mon Sep 17 00:00:00 2001
> From: Russ Allbery 
> Date: Tue, 20 Sep 2022 18:49:04 -0700
> Subject: [PATCH] new-version now passed to more maintainer scripts
> 
> Starting with dpkg 1.18.5, several maintainer script actions
> involving a new package version get that version as an argument
> after the old version. Update Policy's maintainer script
> documentation accordingly.
> ---
>  policy/ch-maintainerscripts.rst | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
> index 709aabf..724074c 100644
> --- a/policy/ch-maintainerscripts.rst
> +++ b/policy/ch-maintainerscripts.rst
> @@ -107,8 +107,8 @@ old version of a package that is being upgraded from or 
> downgraded from.
>  The ``preinst`` script may be called in the following ways:
>  
>  | ``new-preinst`` install
> -| ``new-preinst`` install *old-version*
> -| ``new-preinst`` upgrade *old-version*
> +| ``new-preinst`` install *old-version* *new-version*
> +| ``new-preinst`` upgrade *old-version* *new-version*
>  
>  The package will not yet be unpacked, so the ``preinst`` script
>  cannot rely on any files included in its package. Only essential
> @@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following 
> ways:
>  where dependencies are only "Half-Installed" due to a partial
>  upgrade.
>  
> -``new-prerm`` failed-upgrade *old-version*
> -Called during error handling when ``prerm upgrade`` fails. The new 
> package will not yet be
> -unpacked, and all the same constraints as for ``preinst upgrade``
> -apply.
> +``new-prerm`` failed-upgrade *old-version* *new-version*
> +Called during error handling when ``prerm upgrade`` fails. The new
> +package will not yet be unpacked, and all the same constraints as for
> +``preinst upgrade`` apply.
>  
>  The ``postrm`` script may be called in the following ways:
>  
> @@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways:
>  the package's dependencies if those dependencies are unavailable.
>  [#]_
>  
> -``new-postrm`` failed-upgrade *old-version*
> +``new-postrm`` failed-upgrade *old-version* *new-version*
>  Called when the old ``postrm upgrade`` action fails. The new package
>  will be unpacked, but only essential packages and pre-dependencies
>  can be relied on. Pre-dependencies will either be configured or will
> @@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways:
>  configured and was never removed.
>  
>  | ``new-postrm`` abort-install
> -| ``new-postrm`` abort-install *old-version*
> -| ``new-postrm`` abort-upgrade *old-version*
> +| ``new-postrm`` abort-install *old-version* *new-version*
> +| ``new-postrm`` abort-upgrade *old-version* *new-version*
>  
>  Called before unpacking the new package as part of the error
>  handling of ``preinst`` failures. May assume the same state as
> @@ -229,7 +229,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   new-prerm failed-upgrade *old-version*
> +   new-prerm failed-upgrade *old-version* *new-version*
>  
> If this works, the upgrade continues. If this does not work, the
> error unwind:
> @@ -305,13 +305,13 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-preinst* upgrade *old-version*
> +   *new-preinst* upgrade *old-version* *new-version*
>  
> If this fails, we call:
>  
> .. parsed-literal::
>  
> -   *new-postrm* abort-upgrade *old-version*
> +   *new-postrm* abort-upgrade *old-version* *new-version*
>  
> i.  If that works, then
>  
> @@ -331,13 +331,13 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-preinst* install *old-version*
> +   *new-preinst* install *old-version* *new-version*
>  
> Error unwind:
>  
> .. parsed-literal::
>  
> -   *new-postrm* abort-install *old-version*
> +   *new-postrm* abort-install *old-version* *new-version*
>  
> If this fails, the package is left in a "Half-Installed" state,
> which requires a reinstall. If it works, the packages is left in
> @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   *new-postrm* failed-upgrade *old-version*
> +   *new-postrm* failed-upgrade *old-version* *new-version*
>  
> If this works, installation continues. If not, Error unwind:
>  
> @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below.
>  
> .. parsed-literal::
>  
> -   

Bug#1020518: [debian-mysql] Bug#1020518: Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Ghislain Adnet]

Le 22/09/2022 à 18:37, Robie Basak a écrit :

On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote:

Again, note that I'm still speculating here because I don't follow the
exact sequence of events which is causing the third party packaging to
trip up here. If there's something we're doing wrong then we should fix
it, but nothing I've read so far suggests that.


Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf?
If so, then yes, /usr/share/mysql-common/configure-symlinks could
reasonably not call update-alternatives --install to maintain that
"sysadmin choice". It should probably print a warning in this case.


Sorry if i am not clear enough.

in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and 
not a mariadb one.

I have a perconna mysql server running and i want to install mytop that require 
a perl lib that require libmariad3b, that then, want to replace 
/etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf,
but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from 
the percona packages.

hope that clarify ?

sorry not native english speaker too so...

--
cordialement,
Ghislain ADNET.
AQUEOS.

Bug#1020535: Switch /etc/pcmcia to /etc/pcmciautils in hw-detect.sh

[Holger Wansing]

Package: hw-detect



Hi again,

Am 22. September 2022 18:35:49 MESZ schrieb Colin Watson :
>
>This seems very weird to me too, and it seems as though the hw-detect
>change is backwards - the template change there also now disagrees with
>hw-detect.sh.  I don't think I was involved in that side of it though
>(or I've forgotten), so this one is probably for Holger ...

Hmm, I did not notice, what happens with why such path in hw-detect.sh,
sorry.
So there is some more work to be done there.

Thus filing a new bug for this.
Also see 


Regards


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#823256: debian-policy: Update maintscript arguments with dpkg >= 1.18.5

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 06:52PM -07, Russ Allbery wrote:

>
> Starting with dpkg 1.18.5, several maintainer script actions
> involving a new package version get that version as an argument
> after the old version. Update Policy's maintainer script
> documentation accordingly.
> ---
>  policy/ch-maintainerscripts.rst | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
> index 709aabf..724074c 100644
> --- a/policy/ch-maintainerscripts.rst
> +++ b/policy/ch-maintainerscripts.rst
> @@ -107,8 +107,8 @@ old version of a package that is being upgraded from or 
> downgraded from.
>  The ``preinst`` script may be called in the following ways:
>
>  | ``new-preinst`` install
> -| ``new-preinst`` install *old-version*
> -| ``new-preinst`` upgrade *old-version*
> +| ``new-preinst`` install *old-version* *new-version*
> +| ``new-preinst`` upgrade *old-version* *new-version*
>
>  The package will not yet be unpacked, so the ``preinst`` script
>  cannot rely on any files included in its package. Only essential
> @@ -168,10 +168,10 @@ The ``prerm`` script may be called in the following 
> ways:
>  where dependencies are only "Half-Installed" due to a partial
>  upgrade.
>
> -``new-prerm`` failed-upgrade *old-version*
> -Called during error handling when ``prerm upgrade`` fails. The new 
> package will not yet be
> -unpacked, and all the same constraints as for ``preinst upgrade``
> -apply.
> +``new-prerm`` failed-upgrade *old-version* *new-version*
> +Called during error handling when ``prerm upgrade`` fails. The new
> +package will not yet be unpacked, and all the same constraints as for
> +``preinst upgrade`` apply.
>
>  The ``postrm`` script may be called in the following ways:
>
> @@ -189,7 +189,7 @@ The ``postrm`` script may be called in the following ways:
>  the package's dependencies if those dependencies are unavailable.
>  [#]_
>
> -``new-postrm`` failed-upgrade *old-version*
> +``new-postrm`` failed-upgrade *old-version* *new-version*
>  Called when the old ``postrm upgrade`` action fails. The new package
>  will be unpacked, but only essential packages and pre-dependencies
>  can be relied on. Pre-dependencies will either be configured or will
> @@ -197,8 +197,8 @@ The ``postrm`` script may be called in the following ways:
>  configured and was never removed.
>
>  | ``new-postrm`` abort-install
> -| ``new-postrm`` abort-install *old-version*
> -| ``new-postrm`` abort-upgrade *old-version*
> +| ``new-postrm`` abort-install *old-version* *new-version*
> +| ``new-postrm`` abort-upgrade *old-version* *new-version*
>
>  Called before unpacking the new package as part of the error
>  handling of ``preinst`` failures. May assume the same state as
> @@ -229,7 +229,7 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   new-prerm failed-upgrade *old-version*
> +   new-prerm failed-upgrade *old-version* *new-version*
>
> If this works, the upgrade continues. If this does not work, the
> error unwind:
> @@ -305,13 +305,13 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-preinst* upgrade *old-version*
> +   *new-preinst* upgrade *old-version* *new-version*
>
> If this fails, we call:
>
> .. parsed-literal::
>
> -   *new-postrm* abort-upgrade *old-version*
> +   *new-postrm* abort-upgrade *old-version* *new-version*
>
> i.  If that works, then
>
> @@ -331,13 +331,13 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-preinst* install *old-version*
> +   *new-preinst* install *old-version* *new-version*
>
> Error unwind:
>
> .. parsed-literal::
>
> -   *new-postrm* abort-install *old-version*
> +   *new-postrm* abort-install *old-version* *new-version*
>
> If this fails, the package is left in a "Half-Installed" state,
> which requires a reinstall. If it works, the packages is left in
> @@ -397,7 +397,7 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-postrm* failed-upgrade *old-version*
> +   *new-postrm* failed-upgrade *old-version* *new-version*
>
> If this works, installation continues. If not, Error unwind:
>
> @@ -410,7 +410,7 @@ These are the "error unwind" calls listed below.
>
> .. parsed-literal::
>
> -   *new-postrm* abort-upgrade *old-version*
> +   *new-postrm* abort-upgrade *old-version* *new-version*
>
> If this fails, the old version is left in a "Half-Installed"
> state. If it works, dpkg now calls:

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 09:21PM -07, Russ Allbery wrote:

> In .changes files for source-only uploads, the Binary and
> Description fields are not present.  Document this, and be clearer
> in the description of the Description field for .changes files that
> only descriptions of binary packages are included.
> ---
>  policy/ch-controlfields.rst | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..f85f75d 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -278,7 +278,7 @@ The fields in this file are:
>
>  -  :ref:`Source ` (mandatory)
>
> --  :ref:`Binary ` (mandatory)
> +-  :ref:`Binary `
>
>  -  :ref:`Architecture ` (mandatory)
>
> @@ -292,7 +292,7 @@ The fields in this file are:
>
>  -  :ref:`Changed-By `
>
> --  :ref:`Description ` (mandatory)
> +-  :ref:`Description `
>
>  -  :ref:`Closes `
>
> @@ -809,12 +809,13 @@ See :ref:`s-descriptions` for further information on
>  this.
>
>  In a ``.changes`` file, the ``Description`` field contains a summary of
> -the descriptions for the packages being uploaded. For this case, the
> -first line of the field value (the part on the same line as
> -``Description:``) is always empty. It is a multiline field, with one
> -line per package. Each line is indented by one space and contains the
> -name of a binary package, a space, a hyphen (``-``), a space, and the
> -short description line from that package.
> +the descriptions of the binary packages being uploaded. (``.changes``
> +files for uploads containing only source packages will not have this
> +field.) For this case, the first line of the field value (the part on the
> +same line as ``Description:``) is always empty. It is a multiline field,
> +with one line per binary package. Each line is indented by one space and
> +contains the name of a binary package, a space, a hyphen (``-``), a space,
> +and the short description line from that package.
>
>  .. _s-f-Distribution:
>
> @@ -924,7 +925,8 @@ every architecture. The source control file doesn't 
> contain details of
>  which architectures are appropriate for which of the binary packages.
>
>  When it appears in a ``.changes`` file, it lists the names of the binary
> -packages being uploaded, separated by whitespace (not commas).
> +packages being uploaded, separated by whitespace (not commas). If only
> +source packages are being uploaded, this field will not be present.
>
>  .. _s-f-Installed-Size:

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#992136: Don't require Standards-Version field when only udebs Standards-Version for udeb packages

[Sean Whitton]

control: tag -1 + pending

Hello,

On Tue 20 Sep 2022 at 06:39PM -07, Russ Allbery wrote:

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 428b8a7..ea8f4a3 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -540,6 +540,9 @@ Thus only the first three components of the policy 
> version are
>  significant in the *Standards-Version* control field, and so either
>  these three components or all four components may be specified. [#]_
>
> +udebs and source packages that only produce udebs do not use
> +``Standards-Version``.
> +
>  .. _s-f-Version:
>
>  ``Version``
> diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
> index 289c9a9..a279c26 100644
> --- a/policy/ch-scope.rst
> +++ b/policy/ch-scope.rst
> @@ -71,11 +71,11 @@ Much of the information presented in this manual will be 
> useful even
>  when building a package which is to be distributed in some other way or
>  is intended for local use only.
>
> -udebs (stripped-down binary packages used by the Debian Installer) do
> -not comply with all of the requirements discussed here. See the `Debian
> -Installer internals
> -manual `_ for
> -more information about them.
> +udebs (stripped-down binary packages used by the Debian Installer) and
> +source packages that produce only udebs do not comply with all of the
> +requirements discussed here. See the `Debian Installer internals manual
> +`_ for more information
> +about them.
>
>  .. [#]
> Informally, the criteria used for inclusion is that the material meet

Seconded and applied, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#597730: last conflicting libcue.so.1 was in stretch

[Alban Browaeys]

package libcdio
tag 597730 + stretch
thanks

From: Andreas Beckmann 
To: 562568-d...@bugs.debian.org
Subject: Re: 562568: Symbol conflict with libcdio10
Date: Sat, 20 Oct 2018 13:31:32 +0200

Version: 2.2.1-1

On Wed, 22 Sep 2010 18:03:06 +0200 Matthias Klose 
wrote:
>  > libcue has the internal symbol cdtext_init(), which is also
provided
>  > by libcdio10 (/usr/lib/libcdio.so.10.0.0).
> 
> I don't think it's an internal symbol, it's included in the header
file in the 
> libcue-dev package.

It is no longer exported by libcue.so.2


Andreas

Bug#983202: time_1.9-0.2.diff

[Holger Levsen]

hi,

i've uploaded time_1.9-0.2 with the attached diff to DELAYED/15.

time (1.9-0.2) unstable; urgency=medium

  * Non-maintainer upload by the Reproducible Builds team.
  * Add debian/patches/0001-doc-time.texi.patch to remove timestamp from
documentation. Closes: 983202. Patch by Vagrant Cascadian.

 -- Holger Levsen   Thu, 22 Sep 2022 21:35:24 +0200


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just 100 companies are responsible for 71% of global emissions.
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change
diff -Nru time-1.9/debian/changelog time-1.9/debian/changelog
--- time-1.9/debian/changelog	2021-01-10 20:28:43.0 +0100
+++ time-1.9/debian/changelog	2022-09-22 21:35:24.0 +0200
@@ -1,3 +1,11 @@
+time (1.9-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * Add debian/patches/0001-doc-time.texi.patch to remove timestamp from
+documentation. Closes: 983202. Patch by Vagrant Cascadian.
+
+ -- Holger Levsen   Thu, 22 Sep 2022 21:35:24 +0200
+
 time (1.9-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru time-1.9/debian/patches/0001-doc-time.texi.patch time-1.9/debian/patches/0001-doc-time.texi.patch
--- time-1.9/debian/patches/0001-doc-time.texi.patch	1970-01-01 01:00:00.0 +0100
+++ time-1.9/debian/patches/0001-doc-time.texi.patch	2022-09-22 21:34:52.0 +0200
@@ -0,0 +1,45 @@
+From 2048be16fa0418c231bc953e2d4350b117672ce0 Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Sat, 20 Feb 2021 22:28:30 +
+Subject: [PATCH] doc/time.texi: Remove timestamp from documentation.
+
+The date the package was built is misleading about when the
+documentation was last updated.
+
+https://reproducible-builds.org/docs/timestamps/
+---
+ doc/time.texi | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/doc/time.texi b/doc/time.texi
+index dfc0aa4..c660a66 100644
+--- a/doc/time.texi
 b/doc/time.texi
+@@ -11,7 +11,6 @@
+ This manual is for GNU @code{time} command for running programs
+ and summarizing the system resources they use.
+ version @value{VERSION}
+-updated @value{UPDATED}
+ 
+ Copyright @copyright{} 1991-2018 Free Software Foundation, Inc.
+ 
+@@ -37,7 +36,6 @@ Texts.  A copy of the license is included in the section entitled
+ @title Measuring Program Resource Use
+ @subtitle The GNU @code{time} Command
+ @subtitle version @value{VERSION}
+-@subtitle updated @value{UPDATED}
+ @author David MacKenzie
+ @page
+ @vskip 0pt plus 1filll
+@@ -54,7 +52,7 @@ Texts.  A copy of the license is included in the section entitled
+ 
+ This file documents the the GNU @code{time} command for running programs
+ and summarizing the system resources they use.
+-Version @value{VERSION}, updated @value{UPDATED}
++Version @value{VERSION}
+ @end ifnottex
+ 
+ 
+-- 
+2.30.1
+
diff -Nru time-1.9/debian/patches/series time-1.9/debian/patches/series
--- time-1.9/debian/patches/series	2021-01-10 13:47:40.0 +0100
+++ time-1.9/debian/patches/series	2022-09-22 21:35:24.0 +0200
@@ -1,2 +1,3 @@
 time-include-time_h.patch
 option-p-texi.patch
+0001-doc-time.texi.patch


signature.asc
Description: PGP signature

Bug#978748: libboost-dev: Boost 1.75

[Andrea Pappacoda]

Il giorno gio 22 set 2022 alle 22:23:55 +02:00:00, Anton Gladky 
 ha scritto:

it is "in work". We will definitely need people
for testing, filing and fixing bugs during transition.


Wonderful; I'll be sure to test it against my packages as soon as it'll 
be ready. Thanks for your work :D

Bug#1009931: gmp_6.2.1+dfsg1-1.1.diff

[Holger Levsen]

hi,

i've uploaded gmp_6.2.1+dfsg1-1.1 with the attached diff to DELAYED/15.

gmp (2:6.2.1+dfsg1-1.1) unstable; urgency=medium

  * Non-maintainer upload by the Reproducible Builds team.
  * debian/rules changes by Vagrant Cascadian:
- pass ASMFLAGS with debug-prefix-map to configure.
- replace embedded build path in gmp.h with a placeholder string.
Closes: #1009931


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just 100 companies are responsible for 71% of global emissions.
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change
diff -Nru gmp-6.2.1+dfsg1/debian/changelog gmp-6.2.1+dfsg1/debian/changelog
--- gmp-6.2.1+dfsg1/debian/changelog	2022-06-12 22:56:17.0 +0200
+++ gmp-6.2.1+dfsg1/debian/changelog	2022-09-22 20:43:57.0 +0200
@@ -1,3 +1,13 @@
+gmp (2:6.2.1+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * debian/rules changes by Vagrant Cascadian:
+- pass ASMFLAGS with debug-prefix-map to configure.
+- replace embedded build path in gmp.h with a placeholder string.
+Closes: #1009931
+
+ -- Holger Levsen   Thu, 22 Sep 2022 20:43:57 +0200
+
 gmp (2:6.2.1+dfsg1-1) unstable; urgency=medium
 
   [ Bastian Germann ]
diff -Nru gmp-6.2.1+dfsg1/debian/rules gmp-6.2.1+dfsg1/debian/rules
--- gmp-6.2.1+dfsg1/debian/rules	2022-06-12 22:55:58.0 +0200
+++ gmp-6.2.1+dfsg1/debian/rules	2022-09-22 20:31:51.0 +0200
@@ -72,7 +72,7 @@
 	mkdir -p build
 	cd build && ../configure $(confflags_ma) \
 	AR=$(AR) CC="$(CC)" CFLAGS="$(CFLAGS)" \
-	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)"
+	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)" ASMFLAGS="--debug-prefix-map=$(CURDIR)=."
 	touch $@
 
 build: build-stamp
@@ -100,6 +100,9 @@
 	# so override it at install.
 	$(MAKE) DESTDIR=`pwd`/debian/tmp includeexecdir=/usr/include/$(DEB_HOST_MULTIARCH) -C build install
 
+	# Replace embedded build path with a placeholder string
+	sed -i -e "s,$(CURDIR),BUILDPATH,g" debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/gmp.h
+
 	dh_install -plibgmp10 usr/lib/*/libgmp.so.*
 	dh_install -plibgmpxx4ldbl usr/lib/*/libgmpxx.so.*
 


signature.asc
Description: PGP signature

Bug#1020534: sgx: EPC section 0x50200000-0x55f7ffff (crash)

[Diederik de Haas]

On donderdag 22 september 2022 22:24:31 CEST Diederik de Haas wrote:
> Since kernel 5.18.2-1 I'm getting the following error/message in dmesg

FTR: the 'crash' seems to be in the SGX component, not the whole system.
I don't use SGX, so I don't know if or what for effect this has on its working.

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

Bug#1020534: sgx: EPC section 0x50200000-0x55f7ffff (crash)

[Diederik de Haas]

Source: linux
Version: 5.18.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since kernel 5.18.2-1 I'm getting the following error/message in dmesg:

[0.465573] DMAR: Intel(R) Virtualization Technology for Directed I/O
[0.465579] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[0.465581] software IO TLB: mapped [mem 
0x49be6000-0x4dbe6000] (64MB)
[0.465676] sgx: EPC section 0x5020-0x55f7
[0.466859] [ cut here ]
[0.466863] WARNING: CPU: 1 PID: 55 at arch/x86/kernel/cpu/sgx/main.c:446 
ksgxd+0x1b3/0x1c0
[0.466877] Modules linked in:
[0.466881] CPU: 1 PID: 55 Comm: ksgxd Not tainted 5.18.0-1-amd64 #1  Debian 
5.18.2-1
[0.466887] Hardware name: LENOVO 20HRCTO1WW/20HRCTO1WW, BIOS N1MET70W (1.55 
) 07/07/2022
[0.466889] RIP: 0010:ksgxd+0x1b3/0x1c0
[0.466896] Code: ff e9 f6 fe ff ff 48 89 df e8 99 dd 0c 00 84 c0 0f 84 c7 
fe ff ff 31 ff e8 fa dd 0c 00 84 c0 0f 85 98 fe ff ff e9 b3 fe ff ff <0f> 0b e9 
83 fe ff ff e8 a1 d8 90 00 90 0f 1f 44 00 00 41 57 48 c1
[0.466903] RSP: :b24640463ed8 EFLAGS: 00010283
[0.466913] RAX: b246403a1970 RBX: 9104c2753400 RCX: 
[0.466922] RDX: 8000 RSI: b246403a1930 RDI: 
[0.466925] RBP: 9104c1345300 R08: 9104c13456c0 R09: 9104c13456c0
[0.466928] R10:  R11: 0001 R12: b24640073ce0
[0.466930] R13: 9104c2789980 R14: a0a5c1c0 R15: 
[0.466933] FS:  () GS:91085168() 
knlGS:
[0.466937] CS:  0010 DS:  ES:  CR0: 80050033
[0.466940] CR2:  CR3: 00042d210001 CR4: 003706e0
[0.466943] DR0:  DR1:  DR2: 
[0.466945] DR3:  DR6: fffe0ff0 DR7: 0400
[0.466948] Call Trace:
[0.466952]  
[0.466956]  ? _raw_spin_lock_irqsave+0x24/0x50
[0.466976]  ? _raw_spin_unlock_irqrestore+0x23/0x40
[0.466982]  ? __kthread_parkme+0x36/0x80
[0.466990]  kthread+0xe8/0x110
[0.466994]  ? kthread_complete_and_exit+0x20/0x20
[0.466998]  ret_from_fork+0x22/0x30
[0.467008]  
[0.467010] ---[ end trace  ]---
[0.468117] Initialise system trusted keyrings
[0.468137] Key type blacklist registered
[0.468217] workingset: timestamp_bits=36 max_order=22 bucket_order=0
[0.472438] zbud: loaded


It does NOT occur with version 5.17.3-1 and 5.18-1~exp1, but it does
occur with 5.18.2-1, 5.18.16-1, 5.19.6-1 and I first noticed it with a
self-compiled 6.0-rc6 (custom branch based on Debian kernel's master
branch).

Where it does NOT occur, there is no message containing 'sgx' in dmesg
at all and where it DOES occur it appears to be the same with only a
variantion in line number with ``arch/x86/kernel/cpu/sgx/main.c``

There are 5 commits with 'sgx' in their primary commit message:

diederik@prancing-pony:~/dev/kernel.org/linux$ git log --oneline v5.18..v5.18.2 
| grep -ci sgx
5

And they are all sequential:

$ git log --oneline 
557b6a9ccceeec1ae13a83b4490458b92e064c0e..5aada654649d9bcf6b89d7c0d1ff4b794f9295d3
5aada654649d media: i2c: imx412: Fix reset GPIO polarity
22e83371210d x86/sgx: Ensure no data in PCMD page after truncate
0e1f97633953 x86/sgx: Fix race between reclaimer and page fault handler
69432ff18091 x86/sgx: Obtain backing storage page with enclave mutex held
876053dd7503 x86/sgx: Mark PCMD page as dirty when modifying contents
5ded81f42258 x86/sgx: Disconnect backing page references from dirty status
6ad9dbb202a9 HID: multitouch: add quirks to enable Lenovo X12 trackpoint

But I haven't verified that the issue got introduced with one of them.

No idea if it could be relevant, but the SGX related section in my BIOS
has the following settings (on a Lenovo ThinkPad X1 Carbon 5th gen):
Intel (R) SGX Control: Software Controlled
Current State: Enabled

(And an item to 'Change Owner EPOCH')

I haven't changed those settings between reboots with the various
kernels (or ever AFAIR).


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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYyzEdQAKCRDXblvOeH7b
blRMAQDxcH2fNVpKGoGU6AupSn7uQKSuNI0daaf+XKDCXbYiswD/T7R54kdPqh7L
xIpNsQJijfZ2r6+jVQ+232GODcbCkAs=
=B9if
-END PGP SIGNATURE-

Bug#978748: libboost-dev: Boost 1.75

[strager]

> We will definitely need people
> for testing, filing and fixing bugs during transition.

How can I help with testing? Is there a .deb I can download and install?

On Thu, Sep 22, 2022 at 1:27 PM Anton Gladky  wrote:
>
> Hi Andrea,
>
> it is "in work". We will definitely need people
> for testing, filing and fixing bugs during transition.
>
> Thanks for the proposal!
>
> Best regards
>
> Anton
>
>
> Am Do., 22. Sept. 2022 um 19:47 Uhr schrieb Andrea Pappacoda 
> :
>>
>> On Fri, 22 Apr 2022 17:39:35 +0200 Anton Gladky
>>  wrote:
>>  > I did some work a couple of months ago, packaging 1.78.
>>  > It worked, but I did not have time to finish it. I would probably
>>  > continue this work soon to prepare 1.79 or even 1.80 for the
>>  > next stable Debian version.
>>
>> Hi Anton, what's the status of your boost 1.80 packaging? I'm currently
>> having issues with a couple of packages depending on Boost because 1.74
>> contains a few bugs, and I'd be happy to help you with preparing the
>> next version if needed.
>>
>>

Bug#978748: libboost-dev: Boost 1.75

[Anton Gladky]

Hi Andrea,

it is "in work". We will definitely need people
for testing, filing and fixing bugs during transition.

Thanks for the proposal!

Best regards

Anton


Am Do., 22. Sept. 2022 um 19:47 Uhr schrieb Andrea Pappacoda <
and...@pappacoda.it>:

> On Fri, 22 Apr 2022 17:39:35 +0200 Anton Gladky
>  wrote:
>  > I did some work a couple of months ago, packaging 1.78.
>  > It worked, but I did not have time to finish it. I would probably
>  > continue this work soon to prepare 1.79 or even 1.80 for the
>  > next stable Debian version.
>
> Hi Anton, what's the status of your boost 1.80 packaging? I'm currently
> having issues with a couple of packages depending on Boost because 1.74
> contains a few bugs, and I'd be happy to help you with preparing the
> next version if needed.
>
>
>

Bug#824501: cclive: please make the build reproducible (timestamps)

[Vagrant Cascadian]

Control: tags 824501 pending

On 2016-05-16, Alexis Bienvenüe wrote:
> While working on the `€œreproducible builds'€ effort [1], we have noticed
> that 'cclive' could not be built reproducibly.
>
> The attached patch honours the SOURCE_DATE_EPOCH environment
> variable [2] to get a reproducible build date from the last
> debian changelog entry.
> Once applied, cclive can be built reproducibly in our current
> experimental framework.

I have uploaded an NMU to DELAYED/10 applying this fix.

diff -Nru cclive-0.9.3/debian/changelog cclive-0.9.3/debian/changelog
--- cclive-0.9.3/debian/changelog   2021-01-18 12:29:07.0 -0800
+++ cclive-0.9.3/debian/changelog   2022-09-22 12:46:21.0 -0700
@@ -1,3 +1,12 @@
+cclive (0.9.3-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Alexis Bienvenüe ]
+  * configure.ac: Honour SOURCE_DATE_EPOCH (Closes: #824501)
+
+ -- Vagrant Cascadian   Thu, 22 Sep 2022 
19:46:21 +
+
 cclive (0.9.3-0.2) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru 
cclive-0.9.3/debian/patches/configure.ac-honour-source_date_epoch.patch 
cclive-0.9.3/debian/patches/configure.ac-honour-source_date_epoch.patch
--- cclive-0.9.3/debian/patches/configure.ac-honour-source_date_epoch.patch 
1969-12-31 16:00:00.0 -0800
+++ cclive-0.9.3/debian/patches/configure.ac-honour-source_date_epoch.patch 
2022-09-22 12:46:21.0 -0700
@@ -0,0 +1,28 @@
+From: Alexis Bienvenüe 
+Date: Mon, 16 May 2016 21:03:42 +0200
+X-Dgit-Generated: 0.9.3-0.3 0d3d512774b1bee8ebdf3736620689c4e5d96bbf
+Subject: configure.ac: Honour SOURCE_DATE_EPOCH
+
+(Closes: #824501)
+
+Get build date from the environment variable SOURCE_DATE_EPOCH (is
+set) to make the build reproducible.  See
+https://reproducible-builds.org/specs/source-date-epoch/
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 0bae286..7becddd 100644
+--- a/configure.ac
 b/configure.ac
+@@ -37,7 +37,9 @@ AC_DEFINE_UNQUOTED([CXXFLAGS], "$CXXFLAGS", [Define to 
compiler flags])
+ AC_DEFINE_UNQUOTED([CXX], "$CXX", [Define to compiler])
+
+ AC_PATH_PROG([DATE], [date], [no])
+-AS_IF([test x"$DATE" != "xno"], [build_time=`$DATE +"%F %T %z"`])
++DATE_FMT="%F %T %z"
++SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(date +%s)}"
++build_time=$(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" 2>/dev/null)
+ AC_DEFINE_UNQUOTED([BUILD_TIME], ["$build_time"], [We have build time])
+
+ AC_PATH_PROG([A2X], [a2x], [no])
diff -Nru cclive-0.9.3/debian/patches/series cclive-0.9.3/debian/patches/series
--- cclive-0.9.3/debian/patches/series  2021-01-18 12:10:55.0 -0800
+++ cclive-0.9.3/debian/patches/series  2022-09-22 12:46:21.0 -0700
@@ -2,3 +2,4 @@
 gcc5.diff
 fix-FTBFS-missing-includes.patch
 fix_ftbfs.patch
+configure.ac-honour-source_date_epoch.patch


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Johannes Schauer Marin Rodrigues]

Package: dpkg
Version: 1.21.8
Severity: normal
X-Debbugs-Cc: jo...@debian.org

Hi,

steps to reproduce on amd64:

#!/bin/sh
set -exu
mkdir -p dpkgroot/var/lib/dpkg
echo "arm64" > dpkgroot/var/lib/dpkg/arch
cat << 'END' > dpkgroot/var/lib/dpkg/status
Package: perl-base
Status: install ok installed
Architecture: arm64
Version: 1
END
mkdir -p pkg/DEBIAN
cat << 'END' > pkg/DEBIAN/control
Package: perl-modules-5.34
Version: 1
Architecture: all
Depends: perl-base
END
dpkg-deb --build pkg pkg.deb
PATH=/usr/sbin:/usr/bin:/sbin:/bin dpkg \
--log=/dev/null \
--force-not-root \
--force-script-chrootless \
--root=dpkgroot \
--install pkg.deb

result:

Preparing to unpack pkg.deb ...
Unpacking perl-modules-5.34 (1) ...
dpkg: dependency problems prevent configuration of perl-modules-5.34:
 perl-modules-5.34 depends on perl-base.
dpkg: error processing package perl-modules-5.34 (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 perl-modules-5.34

If one changes "Architecture: arm64" to "Architecture: amd64" (the
architecture of my native dpkg) it works.

Maybe the prolbem is, that dpkg treats perl-modules-5.34 (it being
arch:all) implicitly as the native arch which is (wrongly) chosen to be
amd64 instead of arm64. And in that case, perl-base:arm64 cannot satisfy
its dependency.

Thanks!

cheers, josch

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Holger Levsen]

Hi Colin,

On Thu, Sep 22, 2022 at 08:53:07PM +0100, Colin Watson wrote:
> Yeah, this has taken me a bit longer than expected, but I have in fact
> been making some progress.  josch's patch has been very useful in that
> it provides an easy way to see differences between unsorted and sorted
> traversal, and I've taken my goal as being to drive those differences to
> zero.  The only bit I've committed so far has been:
> 
>   
> https://gitlab.com/cjwatson/man-db/-/commit/bb0f7086ba4ce4503761737bf612088c03b6c495

cool, thanks for the update and all your man-db work!

> I'll update this bug as I make further progress.

great, thanks again! 


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Imagine god created trillions of galaxies but freaks out because some dude
kisses another.


signature.asc
Description: PGP signature

Bug#1020531: dia: creating a text element kills all GUI fonts

[Philippe SWARTVAGHER]

Hello,

I cannot reproduce the bug on a up-to-date Debian Sid with XFCE.

Your version of dia is not the latest available (0.97.3+git20220525-4 is
available in unstable), but that shouldn't be the origin of the bug
since the difference between -3+b1 and -4 is only a change in the
recommended packages.

Can you try to provide more context, so I can reproduce the issue? What
is your desktop environment? Do you have any specific fonts installed?

Philippe.

Le 22/09/2022 à 20:56, Dr. Nikolaus Klepp a écrit :

Package: dia
Version: 0.97.3+git20220525-3+b1
Severity: important
X-Debbugs-Cc: off...@klepp.biz

Dear Maintainer,

Creating a text element breaks all GUI fonts in dia. Steps to reproduce:
- open dia
- create a text element
- right click on the text element

--> all GUI fonts are invisible.

Console log:
(dia:15743): Pango-WARNING **: 20:52:08.861: failed to create cairo scaled 
font, expect ugly output. the offending font is 'Bitstream Vera Sans 
345593.26171875'
(dia:15743): Pango-WARNING **: 20:52:08.862: font_face status is: error 
occurred in libfreetype
(dia:15743): Pango-WARNING **: 20:52:08.862: scaled_font status is: error 
occurred in libfreetype

-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dia depends on:
ii  dia-common   0.97.3+git20220525-3
ii  gir1.2-gtk-2.0   2.24.33-2
ii  libc62.34-8
ii  libcairo21.16.0-6
ii  libgcc-s112.2.0-2
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpoppler12322.08.0-2.1
ii  libpython3.103.10.7-1
ii  libstdc++6   12.2.0-2
ii  libxml2  2.9.14+dfsg-1+b1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-4
ii  gsfonts-x11  2:20200910-4

dia suggests no packages.

-- no debconf information

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Colin Watson]

Control: tag -1 - patch

On Thu, Sep 22, 2022 at 03:48:30PM +, Holger Levsen wrote:
> Colin, what's the status of this bug? You said you were working on improving
> josch' patch in May 2022...?! :)

Yeah, this has taken me a bit longer than expected, but I have in fact
been making some progress.  josch's patch has been very useful in that
it provides an easy way to see differences between unsorted and sorted
traversal, and I've taken my goal as being to drive those differences to
zero.  The only bit I've committed so far has been:

  
https://gitlab.com/cjwatson/man-db/-/commit/bb0f7086ba4ce4503761737bf612088c03b6c495

I also have a few hundred lines of somewhat untidy patch that I'll
commit in a few pieces as soon as I'm certain of it; this is all
essentially about stabilizing the decisions about which database entries
win compared to which other entries, so that the end result doesn't
change depending on the scan order.  With that, I'm down to on the order
of 150 lines of diff of accessdb output against the result of josch's
patch, and I think there are only about one or two problems left.

A lot of the remaining difficulties are due to somewhat impenetrable old
code which appeared to be trying to micro-optimize memory usage in a way
that I don't think makes sense nowadays, so I may take a bit of a
digression into reorganizing some of this.

I'll update this bug as I make further progress.

> Also, the bug is currently tagged 'patch', I guess it's appropriate to remove
> that tag?

Done.

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

Bug#1013005: onednn: ftbfs with GCC-12

[M. Zhou]

Control: fixed -1 2.6.1-1

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

[Soren Stoutner]

On Thursday, September 22, 2022 9:20:46 AM MST Agustin Martin wrote:
> First of all, I am curious about the reasons behind this new format,
> the problems it deals with and its advantages. I assume they are valid
> enough, but they imply yet another spellchecking engine/format. We
> currently have goog old ispell, aspell and hunspell. vim has its own
> spellchecker engine using its own format, with dicts that can be
> created from old myspell2 dicts. We did not add vim format dicts (from
> aspell dicts sources) since there seems to be some work to make vim
> use hunspell directly. And now these bdict dicts.

The .bdic format is specified by the upstream Chromium project, and is required 
by 
anything that is based off of Chromium's code, like Qt WebEngine.  I do not 
know why 
they went with a proprietary binary format, but I would assume that if they 
went to so 
much trouble to not use the standard Hunspell format there must have been 
something 
to make it worthwhile, like some performance improvement.  Perhaps I am giving 
Google too much credit for having logical reasons instead of making arbitrary 
decisions.

> From your info and proposed locations seems that these dicts are
> arch:all, ¿is that true?

I have not seen anything to indicate they are not arch:all.  Although it 
probably depends 
on how the binary data is processed.  There is a possibility there might be an 
endianess 
issue.

> Another question is what happens with affix files, which I see are
> used at build time, ¿are they used (from their path) at runtime or is
> all the info (dic+aff) bundled into the bdic file? If explicit affix
> files are still required at runtime, both bdic and aff files should
> probably be in the same dir. Otherwise I am more for a separate
> location. In this case, since bdic dicts seem to be more generic than
> just a qtwebengine issue and they are indeed created from hunspell
> files I would go for a rather generic name (may be something like
> /usr/share/hunspell-bdic or something without the hunspell name?)

The .bdic binary file contains all the information from the .dic and .aff 
files, so neither of 
them are needed by Qt WebEngine.  As such, I think a dedicated directory for 
the .bdic 
files is best.

My personal motivation for getting these dictionaries into Debian is that I am 
the 
developer of Privacy Browser, which is a web browser based on Qt WebEngine.  
The PC 
version is currently in a pre-alpha state.

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

When adding spell checking functionality, I realized that these dictionaries 
were not 
already packaged.  The little bit of poking around that I did showed that Arch 
Linux 
packages them, but I do not know if other distributions do so.

https://archlinux.org/todo/packaging-qtwebengine-dictionaries/[2]

There are a number of existing web browsers in Debian based on Qt WebEngine 
that 
could take advantage of the presence of these .bdic dictionaries.  A 
non-exhaustive list 
includes:  Konqueror, Falkon, qutebrowser, and angelfish.  If it ends up being 
feasible for 
Chromium to also use a system-wide .bdic location, then any Chromium fork would 
also 
benefit.

Once Privacy Browser reaches an alpha release, my intention is to maintain a 
Debian 
package for it.  I have the option of integrating the .bdics directly into the 
program's 
personal data folders, but that seems like a suboptimal approach, because 
anything else 
on the system that wanted to use them would have to have their own copy.  When 
the 
binary dictionaries are installed in the correct system-wide folder, any Qt 
WebEngine 
program can utilize them with a single line of code that specifies which 
dictionary to use 
(only one can be active at a time).  Of course, the program would also probably 
need to 
establish a GUI where the user can select which dictionary they would like to 
be active, 
which GUI involves more than a single line of code.

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


[1] https://www.stoutner.com/privacy-browser-pc/
[2] https://archlinux.org/todo/packaging-qtwebengine-dictionaries/


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

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Paul Gevers]

Hi,

On 22-09-2022 20:38, Salvatore Bonaccorso wrote:

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.



Why is this binNMU actually needed? bind9-dyndb-ldap has the
following:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>= 1.6.dfsg.2), 
libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 9.11)

which is satisifed as well after the bind9 update via
bullseye-security, and updates are possible. Do your request imply
that the relationship would be too lax?


I think there was a change after the bullseye release. The package in 
unstable has a strict relation instead of a larger-or-equal relation:


Depends: bind9-libs (= 1:9.18.6-2), libc6 (>= 2.34), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.5-0 (>= 2.5.4), libuuid1 (>= 2.16), bind9 (>= 9.11)


bind-dyndb-ldap (11.9-5) unstable; urgency=medium

  * support-9.18.diff: Fix build with bind9 9.18. (Closes: #1006014)
- drop patches that aren't needed anymore with this
  * control, rules: Use a strict dependency on bind9-libs that the
package was built against, in order to avoid bind9 updates breaking
the package. (Closes: #1004729)

 -- Timo Aaltonen   Wed, 23 Feb 2022 13:17:07 +0200

So, Timo, is the package in bullseye broken with the security update and 
does it need a fix, or is it fine?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020517: scrcpy: Does not display the Android window.

[Yangfl]

Xerxes  于2022年9月22日周四 23:15写道：
>
> Package: scrcpy
> Version: 1.24-1
> Severity: important
> X-Debbugs-Cc: xerxesl...@gmail.com
>
> Dear Maintainer,
>
> After using the "scrcpy" command, everything seems to be normal, but the 
> window with the Android system image does not open. Just for comparison, 
> using the flatpak version of the "guiscrcpy" program, it's working.
>
> After executing the command, the message that appears is:
>
> scrcpy 1.24 
> /usr/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 1.6 MB/s (40683 
> bytes in 0.024s)
> [server] INFO: Device: samsung SM-A730F (Android 9)
> INFO: Renderer: opengl
> INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 22.2.0-rc3
> INFO: Trilinear filtering enabled
> INFO: Initial texture: 1080x2216
>
> And nothing happens after that.
>
> The window with the Android system should appear. I already checked the 
> "debug mode" and permissions on the device.

Strange. Android 9 too, works fine to me. Does `scrcpy -V debug` help?

Bug#1020424: krb5: Versioned dependencies are needed in order to avoid version skew

[Sam Hartman]

> "Sam" == Sam Morris  writes:

Sam> When using a container image that has an older version of some
Sam> of the binary packages from krb5 in it, installing krb5-user
Sam> results in binary packages being installed that are a mix of
Sam> the newer and older version.

Thanks for filing; I understand the issue and will fix.

Bug#1017372: #1017372 plymouth: reproducible builds: year and week embedded in .pc files

[Holger Levsen]

hi Laurent,

what do you think of the proposed patch?

for your convinience: (see https://bugs.debian.org/1017372
for more explainations but this is the diff)

Subject: [PATCH] configure.ac: Avoid embedding the date in the version.

Use the version from the last debian/changelog entry, otherwise the
build will differ if built on a different year and week and from git
builds vs. builds from source tarball.
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 6e00c0c..0de1856 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_INIT([plymouth],
-m4_esyscmd_s([date +%y.%V.$(git rev-list $(git describe 
--abbrev=0)..HEAD --count) || echo 0]),
+m4_esyscmd_s([dpkg-parsechangelog --show-field Version]),


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money. (Greta Thunberg)


signature.asc
Description: PGP signature

Bug#1020532: gimp: text element crashes gimp

[Dr. Nikolaus Klepp]

Package: gimp
Version: 2.10.32-1+b1
Severity: important
X-Debbugs-Cc: off...@klepp.biz

Dear Maintainer,

Gimp crashes, when a text element is modified:

- open gimp, create new image
- create text element
- select some characters inside this text element 
- change the font size

--> gimp crashes


Console errors:

gimp: fatal error: Speicherzugriffsfehler
(script-fu:16693): LibGimpBase-WARNING **: 20:57:28.455: script-fu: 
gimp_wire_read(): error


-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data2.10.32-1
ii  graphviz 2.42.2-7
ii  libaa1   1.4p5-50
ii  libbabl-0.1-01:0.1.96-1
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.34-8
ii  libcairo21.16.0-6
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-2
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgegl-0.4-01:0.4.38-1+b1
ii  libgexiv2-2  0.14.0-1+b1
ii  libgimp2.0   2.10.32-1+b1
ii  libglib2.0-0 2.74.0-1
ii  libgs9   9.56.1~dfsg-1
ii  libgtk2.0-0  2.24.33-2
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b2.7.4-1+b1
ii  libheif1 1.13.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.13.1-1+b1
ii  liblzma5 5.2.5-2.1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr-3-1-303.1.5-4
ii  libopenjp2-7 2.5.0-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpangoft2-1.0-01.50.10+ds-1
ii  libpng16-16  1.6.37-5
ii  libpoppler-glib8 22.08.0-2.1
ii  librsvg2-2   2.54.4+dfsg-1
ii  libstdc++6   12.2.0-2
ii  libtiff5 4.4.0-4
ii  libwebp7 1.2.2-2+b1
ii  libwebpdemux21.2.2-2+b1
ii  libwebpmux3  1.2.2-2+b1
ii  libwmf-0.2-7 0.2.12-5
ii  libwmflite-0.2-7 0.2.12-5
ii  libx11-6 2:1.8.1-2
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-1
ii  libxmu6  2:1.1.3-3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages gimp recommends:
ii  ghostscript  9.56.1~dfsg-1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gvfs-backends 
ii  libasound21.2.7.2-1

-- no debconf information

Bug#1020531: dia: creating a text element kills all GUI fonts

[Dr. Nikolaus Klepp]

Package: dia
Version: 0.97.3+git20220525-3+b1
Severity: important
X-Debbugs-Cc: off...@klepp.biz

Dear Maintainer,

Creating a text element breaks all GUI fonts in dia. Steps to reproduce:
- open dia
- create a text element
- right click on the text element

--> all GUI fonts are invisible.

Console log:
(dia:15743): Pango-WARNING **: 20:52:08.861: failed to create cairo scaled 
font, expect ugly output. the offending font is 'Bitstream Vera Sans 
345593.26171875'
(dia:15743): Pango-WARNING **: 20:52:08.862: font_face status is: error 
occurred in libfreetype
(dia:15743): Pango-WARNING **: 20:52:08.862: scaled_font status is: error 
occurred in libfreetype

-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dia depends on:
ii  dia-common   0.97.3+git20220525-3
ii  gir1.2-gtk-2.0   2.24.33-2
ii  libc62.34-8
ii  libcairo21.16.0-6
ii  libgcc-s112.2.0-2
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpoppler12322.08.0-2.1
ii  libpython3.103.10.7-1
ii  libstdc++6   12.2.0-2
ii  libxml2  2.9.14+dfsg-1+b1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-4
ii  gsfonts-x11  2:20200910-4

dia suggests no packages.

-- no debconf information

Bug#1020530: ostree-push: New upstream version 1.0.0

[Dan Nicholson]

Package: ostree-push
Version: 0.20170708+gitabc601f-2

This has been out for a few months and is available on PyPI now. It would
be nice to get this packaged in Debian again.

I took a crack at packaging it. See:

https://salsa.debian.org/dbn/ostree-push/-/tree/debian/unstable
https://salsa.debian.org/dbn/ostree-push/-/tree/upstream/latest
https://salsa.debian.org/dbn/ostree-push/-/tree/pristine-lfs

--
Dan Nicholson  |  Endless OS Foundation

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Salvatore Bonaccorso]

Hi,

On Thu, Sep 22, 2022 at 06:13:29PM +0200, Ondřej Surý wrote:
> 
> > On 21. 9. 2022, at 20:35, Adam D. Barratt  wrote:
> > 
> > Control: tags -1 + bullseye
> > 
> > On Wed, 2022-09-21 at 13:47 +0200, Ondřej Surý wrote:
> >> nmu bind-dyndb-ldap_11.6-3 . ANY . bullseye . -m "rebuild for
> >> bind9_9.16.33-1~deb11u1"
> >> 
> >> Hi,
> >> 
> >> after the bind9_9.16.33-1~deb11u1 is release to bullseye-security,
> >> the
> >> bind-dyndb-ldap plugin will require binNMU.
> >> 
> > 
> > We can do that - once the packages are in p-u, because p-u chroots
> > don't pull in packages from the security archive - but it will mean
> > that users won't get the binNMUs until the next point release, which
> > probably isn't until November now.
> > 
> > Is that OK?
> 
> 
> Adding Paul, Salvatore and Timo into the bunch.
> 
> I honestly don't know because I don't use this package, but I think
> it might prevent the users using the bind-dyndb-ldap users from
> upgrading the bind9 package.
> 
> Should I then prepare a NMU for bullseye-security?
> 
> Looks like only viable solution long-term would be to build all the
> bind plugins from the src:bind9 package, but it's too late for bullseye.

Why is this binNMU actually needed? bind9-dyndb-ldap has the
following:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>= 1.6.dfsg.2), 
libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 9.11)

which is satisifed as well after the bind9 update via
bullseye-security, and updates are possible. Do your request imply
that the relationship would be too lax?

Regards,
Salvatore

Bug#1007137: libranlip: please make the build reproducible

[Vagrant Cascadian]

Control: tags 788000 pending
Control: tags 846975 pending
Control: tags 1007137 pending

Uploaded an NMU fixing these three reproducible builds bugs to
DELAYED/10.

diff -u libranlip-1.0/debian/changelog libranlip-1.0/debian/changelog
--- libranlip-1.0/debian/changelog
+++ libranlip-1.0/debian/changelog
@@ -1,3 +1,22 @@
+libranlip (1.0-4.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Dhole ]
+  * Makefile.in: Pass -n via GZIP_ENV to avoid embedding
+timestamps. (Closes: #788000)
+  * debian/rules: Pass -n to gzip when compressing files.
+(Closes: #788000)
+  * debian/rules: Use consistent date in packaged files. (Closes: #788000)
+
+  [ Valerie R Young ]
+  * debian/rules: Sort md5sums files. (Closes: #846975)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Use standard buildflags. (Closes: #1007137)
+
+ -- Vagrant Cascadian   Thu, 22 Sep 2022 
11:16:14 -0700
+
 libranlip (1.0-4.3) unstable; urgency=medium

   * Non-maintainer upload.
diff -u libranlip-1.0/debian/rules libranlip-1.0/debian/rules
--- libranlip-1.0/debian/rules
+++ libranlip-1.0/debian/rules
@@ -3,6 +3,10 @@
 # Copyright (c) 2005 Juan Esteban Monsalve Tobon 

 STRIP  = strip --remove-section=.comment --remove-section=.note
+BUILD_DATE=$(shell dpkg-parsechangelog --show-field Date)
+
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk

 build:
$(checkdir)
@@ -57,23 +61,27 @@
cp -p debian/changelog 
debian/libranlip1c2/usr/share/doc/libranlip1c2/changelog.Debian
cp -p docs/ranlip.ps debian/libranlip1c2/usr/share/doc/libranlip1c2/
cp -p examples/ranliptest* examples/makefile 
debian/libranlip1c2/usr/share/doc/libranlip1c2/examples
-   cd debian/libranlip1c2/usr/share/doc/libranlip1c2 && gzip -9 
changelog.Debian ranlip.ps examples/*
+   cd debian/libranlip1c2/usr/share/doc/libranlip1c2 && gzip -9n 
changelog.Debian ranlip.ps examples/*

ln -s libranlip1c2 debian/libranlip-dev/usr/share/doc/libranlip-dev

dpkg-shlibdeps debian/libranlip1c2/usr/lib/ranlip/*
dpkg-gencontrol -isp -plibranlip1c2 -Pdebian/libranlip1c2
-   cd debian/libranlip1c2 && md5sum `find * -type f ! -regex "DEBIAN/.*"` 
> DEBIAN/md5sums
+   cd debian/libranlip1c2 && md5sum `find * -type f ! -regex "DEBIAN/.*"` 
| LC_ALL=C sort > DEBIAN/md5sums
chown -R root.root debian/libranlip1c2
chmod -x debian/libranlip1c2/usr/lib/ranlip/*
chmod -R go=rX debian/libranlip1c2
+   find debian/libranlip1c2 -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build debian/libranlip1c2 ..

dpkg-gencontrol -isp -plibranlip-dev -Pdebian/libranlip-dev
-   cd debian/libranlip-dev && md5sum `find * -type f ! -regex "DEBIAN/.*"` 
> DEBIAN/md5sums
+   cd debian/libranlip-dev && md5sum `find * -type f ! -regex "DEBIAN/.*"` 
| LC_ALL=C sort > DEBIAN/md5sums
chown -R root.root debian/libranlip-dev
chmod -x debian/libranlip-dev/usr/lib/ranlip/libranlip.a 
debian/libranlip-dev/usr/lib/ranlip/libranlip.la
chmod -R go=rX debian/libranlip-dev
+   find debian/libranlip-dev -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build debian/libranlip-dev ..

 define checkdir
only in patch2:
unchanged:
--- libranlip-1.0.orig/Makefile.in
+++ libranlip-1.0/Makefile.in
@@ -409,7 +409,7 @@
 || { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
  && rm -fr $(distdir); }; }

-GZIP_ENV = --best
+GZIP_ENV = --best -n
 distuninstallcheck_listfiles = find . -type f -print
 distcleancheck_listfiles = find . -type f -print


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Ondřej Surý]

Hi Steinar,

I am sorry this has caused inconvenience for you, but the original problem here 
was that the implicit inline-signing with the dnssec-policy was also 
problematic and causing other problems, see the upstream issue: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3381

Especially this: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3381#note_308893

I guess what I can do in the package is to add a notice at the upgrade time.

Ondřej
--
Ondřej Surý  (He/Him)

> On 22. 9. 2022, at 20:03, Steinar H. Gunderson  wrote:
> 
> Package: bind9
> Version: 1:9.16.33-1~deb11u1
> Severity: grave
> 
> Hi,
> 
> After applying the security updates for DSA 5235-1, named completely breaks
> and refuses to start. (This caused downtime in production for us.) The reason
> seems to be that the patch includes a full minor version bump, including
> policy changes such as:
> 
> 5941.[func]Zones with dnssec-policy now require dynamic DNS or
>inline-siging to be configured explicitly. [GL #3381]
> 
> Since we have DNSSEC zones (as is recommended!), and use dnssec-policy to
> configure them (also recommended!) it dies on startup with
> 
> Sep 22 16:17:59 cirkus named[3045282]: /etc/bind/named.conf.local:388: 
> 'dnssec-policy;' requires dynamic DNS or inline-signing to be configured for 
> the zone
> Sep 22 16:17:59 cirkus named[3045282]: loading configuration: failure
> Sep 22 16:17:59 cirkus named[3045282]: exiting (due to fatal error)
> 
> It seems that one can change add “inline-signing yes;” manually to each zone
> to work around it, but this is not the kind of change that really should be
> done in a security update without a very good reason _and_ a very clear
> warning. :-)
> 
> It seems the test suite even had to be changed for this change, which should
> have been a pretty clear red flag:
> 
>  
> https://salsa.debian.org/dns-team/bind9/-/commit/9036610e13ed037f776460d7806ea0a0e3841bdf#6f59e8ac2674d0c1120aa79f6f2ac2aa946d99e5
> 
> I haven't checked if there are other breaking changes.
> 
> -- System Information:
> Debian Release: 11.5
>  APT prefers stable-security
>  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
> 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.19.10 (SMP w/56 CPU threads; PREEMPT)
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_NO:en_US:en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages bind9 depends on:
> ii  adduser   3.118
> ii  bind9-libs1:9.16.27-1~deb11u1
> pn  bind9-utils   
> pn  bind9utils
> ii  debconf [debconf-2.0] 1.5.77
> ii  dns-root-data 2021011101
> ii  init-system-helpers   1.60
> ii  iproute2  5.10.0-4
> pn  libbind9-140  
> pn  libbind9-161  
> ii  libc6 2.31-13+deb11u4
> ii  libcap2   1:2.44-1
> ii  libcom-err2 [libcomerr2]  1.46.2-2
> pn  libdns1104
> pn  libdns162 
> ii  libfstrm0 0.6.0-1+b1
> ii  libgeoip1 1.6.12-7
> ii  libgssapi-krb5-2  1.18.3-6+deb11u2
> pn  libirs141 
> pn  libisc1100
> pn  libisc160 
> pn  libisccc140   
> pn  libisccc161   
> pn  libisccfg140  
> pn  libisccfg163  
> pn  libjson-c3
> ii  libjson-c50.15-2
> ii  libk5crypto3  1.18.3-6+deb11u2
> ii  libkrb5-3 1.18.3-6+deb11u2
> ii  liblmdb0  0.9.24-1
> pn  liblwres141   
> pn  liblwres161   
> ii  libmaxminddb0 1.5.2-1
> ii  libnghttp2-14 1.43.0-1
> ii  libprotobuf-c11.3.3-1+b2
> pn  libssl1.0.2   
> ii  libssl1.1 1.1.1n-0+deb11u3
> ii  libuv11.40.0-2
> ii  libxml2   2.9.10+dfsg-6.7+deb11u2
> ii  lsb-base  11.1.0
> ii  net-tools 1.60+git20181103.0eebece-1
> ii  netbase   6.3
> ii  zlib1g1:1.2.11.dfsg-2+deb11u2
> 
> bind9 recommends no packages.
> 
> Versions of packages bind9 suggests:
> pn  bind-doc   
> ii  bind9-dnsutils [dnsutils]  1:9.16.27-1~deb11u1
> pn  bind9-doc  
> ii  dnsutils   1:9.16.27-1~deb11u1
> pn  resolvconf 
> pn  ufw
> 
> -- Configuration Files:
> /etc/bind/named.conf.local changed [not included]
> /etc/bind/named.conf.options changed [not included]

Bug#1020387: Chromium Dictionaries

[Soren Stoutner]

On Thursday, September 22, 2022 9:04:53 AM MST Andres Salomon wrote:
> FYI, chromium's documentation about this stuff is here:
> 
> https://chromium.googlesource.com/chromium/deps/hunspell_dictionaries/+/refs
> /heads/main/README.chromium

Thanks for that link.

> It appears that the dictionary files are versioned, and those versions
> are matched in chromium's source code:
> 
> https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/
> spellcheck/common/spellcheck_common.cc

My understanding from reading this documentation is that the versioning of the 
dictionaries is to facilitate automatic updating of the dictionary files.  If 
we could coax Chromium to use a system-wide directory, that would no longer be 
an issue because updates would be handled by apt-get.

> My understanding is that .config/chromium/Dictionaries isn't the source
> of dictionaries; when you add a language to chromium, a .bdic file for
> that (already installed) language doesn't show up there unless you
> first add the language in the "Preferred languages" chromium config
> screen, and then go into the spelling config screen and manually select
> that language under "Use spell check for".

My testing indicates that, when you add a new language under the languages 
Chromium config screen, it then adds an entry to the spelling config screen.  
If 
you turn that entry on (disabled by default), Chromium downloads the 
appropriate .bdic to ~/.config/chromium/Dictionaries from some central 
repository hard coded into Chromium's code.  This would explain why simply 
dropping a .bdic into that directory is not enough to enable it as an option 
in Chromium.

Given how this is structured, I am not sure how easy it would be to convince 
Chromium to use a system-wide directory for the .bdic storage.

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

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

Bug#855880: amqp-tools: manpages are empty

[Paul Gevers]

Control: retitle -1 manpages reference unavailable librabbitmq-tools(7)

Hi,

On Wed, 22 Feb 2017 17:21:12 -0300 Antonio Terceiro 
 wrote:

$ man amqp-publish
# (nothing happens)
$ ls -lh /usr/share/man/man1/amqp-*
-rw-r--r-- 1 root root 20 jul 23  2016 /usr/share/man/man1/amqp-consume.1.gz
-rw-r--r-- 1 root root 20 jul 23  2016 
/usr/share/man/man1/amqp-declare-queue.1.gz
-rw-r--r-- 1 root root 20 jul 23  2016 
/usr/share/man/man1/amqp-delete-queue.1.gz
-rw-r--r-- 1 root root 20 jul 23  2016 /usr/share/man/man1/amqp-get.1.gz
-rw-r--r-- 1 root root 20 jul 23  2016 /usr/share/man/man1/amqp-publish.1.gz
$ zcat /usr/share/man/man1/amqp-*
# (nothing)


This issue seems to be fixed, thanks for that. However, I note that the 
man pages reference librabbitmq-tools(7) but that isn't to be found 
anywhere in Debian, but I found it elsewhere [1].


Paul

[1] https://linux.die.net/man/7/librabbitmq-tools


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999458: zynaddsubfx

[Dennis Braun]

Hi guys,

sorry, i can't help with that atm.
If you know how to include the new gui properly, feel free to contribute:
https://salsa.debian.org/multimedia-team/zynaddsubfx/

Best regards,
Dennis

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Steinar H. Gunderson]

Package: bind9
Version: 1:9.16.33-1~deb11u1
Severity: grave

Hi,

After applying the security updates for DSA 5235-1, named completely breaks
and refuses to start. (This caused downtime in production for us.) The reason
seems to be that the patch includes a full minor version bump, including
policy changes such as:

5941.   [func]  Zones with dnssec-policy now require dynamic DNS or
inline-siging to be configured explicitly. [GL #3381]

Since we have DNSSEC zones (as is recommended!), and use dnssec-policy to
configure them (also recommended!) it dies on startup with

Sep 22 16:17:59 cirkus named[3045282]: /etc/bind/named.conf.local:388: 
'dnssec-policy;' requires dynamic DNS or inline-signing to be configured for 
the zone
Sep 22 16:17:59 cirkus named[3045282]: loading configuration: failure
Sep 22 16:17:59 cirkus named[3045282]: exiting (due to fatal error)

It seems that one can change add “inline-signing yes;” manually to each zone
to work around it, but this is not the kind of change that really should be
done in a security update without a very good reason _and_ a very clear
warning. :-)

It seems the test suite even had to be changed for this change, which should
have been a pretty clear red flag:

  
https://salsa.debian.org/dns-team/bind9/-/commit/9036610e13ed037f776460d7806ea0a0e3841bdf#6f59e8ac2674d0c1120aa79f6f2ac2aa946d99e5

I haven't checked if there are other breaking changes.

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

Kernel: Linux 5.19.10 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9 depends on:
ii  adduser   3.118
ii  bind9-libs1:9.16.27-1~deb11u1
pn  bind9-utils   
pn  bind9utils
ii  debconf [debconf-2.0] 1.5.77
ii  dns-root-data 2021011101
ii  init-system-helpers   1.60
ii  iproute2  5.10.0-4
pn  libbind9-140  
pn  libbind9-161  
ii  libc6 2.31-13+deb11u4
ii  libcap2   1:2.44-1
ii  libcom-err2 [libcomerr2]  1.46.2-2
pn  libdns1104
pn  libdns162 
ii  libfstrm0 0.6.0-1+b1
ii  libgeoip1 1.6.12-7
ii  libgssapi-krb5-2  1.18.3-6+deb11u2
pn  libirs141 
pn  libisc1100
pn  libisc160 
pn  libisccc140   
pn  libisccc161   
pn  libisccfg140  
pn  libisccfg163  
pn  libjson-c3
ii  libjson-c50.15-2
ii  libk5crypto3  1.18.3-6+deb11u2
ii  libkrb5-3 1.18.3-6+deb11u2
ii  liblmdb0  0.9.24-1
pn  liblwres141   
pn  liblwres161   
ii  libmaxminddb0 1.5.2-1
ii  libnghttp2-14 1.43.0-1
ii  libprotobuf-c11.3.3-1+b2
pn  libssl1.0.2   
ii  libssl1.1 1.1.1n-0+deb11u3
ii  libuv11.40.0-2
ii  libxml2   2.9.10+dfsg-6.7+deb11u2
ii  lsb-base  11.1.0
ii  net-tools 1.60+git20181103.0eebece-1
ii  netbase   6.3
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.27-1~deb11u1
pn  bind9-doc  
ii  dnsutils   1:9.16.27-1~deb11u1
pn  resolvconf 
pn  ufw

-- Configuration Files:
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]

Bug#1020528: dh-python: attempting to diff static library files raises UnicodeDecodeError

[Nick Rosbrook]

Package: dh-python
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

In verbose mode, if files differ in share_files(), dhpython will try to
show a diff of the files. When these files are static libraries, this
raises a UnicodeDecodeError. For example, from a recent numpy build on
Ubuntu kinetic[1].

In Ubuntu, the attached patch was applied to avoid diffing .a files,
just as is currently done for .so files:

  * dhpython/fs.py: do not try to diff static libraries in verbose mode (LP: 
#1990562)

Thanks,
Nick

[1] 
https://launchpadlibrarian.net/624822201/buildlog_ubuntu-kinetic-arm64.numpy_1%3A1.21.5-1build2_BUILDING.txt.gz
diff -Nru dh-python-5.20220819/dhpython/fs.py 
dh-python-5.20220819ubuntu1/dhpython/fs.py
--- dh-python-5.20220819/dhpython/fs.py 2022-08-19 16:34:55.0 -0400
+++ dh-python-5.20220819ubuntu1/dhpython/fs.py  2022-09-22 10:38:23.0 
-0400
@@ -144,7 +144,7 @@
 else:
 # The files differed so we cannot collapse them.
 log.warn('Paths differ: %s and %s', fpath1, fpath2)
-if options.verbose and not i.endswith('.so'):
+if options.verbose and not i.endswith(('.so','.a')):
 with open(fpath1) as fp1:
 fromlines = fp1.readlines()
 with open(fpath2) as fp2:

Bug#978748: libboost-dev: Boost 1.75

[Andrea Pappacoda]

On Fri, 22 Apr 2022 17:39:35 +0200 Anton Gladky 
 wrote:

> I did some work a couple of months ago, packaging 1.78.
> It worked, but I did not have time to finish it. I would probably
> continue this work soon to prepare 1.79 or even 1.80 for the
> next stable Debian version.

Hi Anton, what's the status of your boost 1.80 packaging? I'm currently 
having issues with a couple of packages depending on Boost because 1.74 
contains a few bugs, and I'd be happy to help you with preparing the 
next version if needed.

Bug#1020527: pam-p11: upcoming FTBFS

[Andreas Hasenack]

Package: pam-p11
Version: 0.3.1-1.1
Severity: normal

Dear Maintainer,

it's likely that the current pam-p11 source package will FTBFS in some
architectures if a rebuild is attempted at this time, with gcc-12. We
encountered this problem[1][2] in Ubuntu, and upstream committed a fix[3]
which we applied to the Ubuntu package.

I tried to propose a salsa PR, but it seems to be having problems at the
moment, so I'm filing this bug instead.

1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194
2. https://github.com/OpenSC/pam_p11/issues/24
3.
https://github.com/OpenSC/pam_p11/commit/f6ad88eac351db351940a08715dd3914cc601137

Bug#1020526: opensc: fix for uninitialized variables from upstream

[Andreas Hasenack]

Package: opensc
Version:
Severity: normal

Dear Maintainer,

a while ago (in 0.22.0-2) the -Wno-error=maybe-uninitialized flag was added
to the build of the package to workaround (back then) gcc-11 new stringent
checks. I suspect one of those was in the base64.c file, which was now
fixed upstream[1] (the same issue affected pam-p11[2]). Therefore that
upstream patch could be added, and the gcc -Wno-error=maybe-uninitialized
flag could be dropped.


1.
https://github.com/OpenSC/OpenSC/commit/c438a5083293eab1ac5c62a87470262393cf0e86
2. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194

Bug#1020442: heimdal breaks openldap autopkgtest: test smbk5pwd

[Paul Gevers]

Control: reassign 1020442 src:openldap 2.5.12+dfsg-2
Control: affects 1020442 src:heimdal

Hi,

On 22-09-2022 18:14, Ryan Tandy wrote:
The slapd autopkgtest does a chgrp/chmod to 
grant slapd access to the heimdal master key, but the permissions on the 
containing directory (/var/lib/heimdal-kdc) became more restrictive (now 
700). I will update the autopkgtest ASAP.


So, let's reassign to openldap. Doing so with this mail.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#782318: mylvmbackup: please make the build reproducible

[Vagrant Cascadian]

Control: tags 782318 pending

On 2015-04-10, Reiner Herrmann wrote:
> While working on Debian's “reproducible builds” effort [1], we have
> noticed that mylvmbackup doesn't build reproducibly.
> It embeds the current date into the mylvmbackup script.
>
> The attached patch fixes this by using the last changelog date
> as a timestamp that will be embedded.

Uploaded an NMU fixing this to DELAYED/10 with a slightly updated patch
using SOURCE_DATE_EPOCH:

diff -Nru mylvmbackup-0.15/debian/changelog mylvmbackup-0.15/debian/changelog
--- mylvmbackup-0.15/debian/changelog   2022-04-21 06:42:15.0 -0700
+++ mylvmbackup-0.15/debian/changelog   2022-09-22 10:11:19.0 -0700
@@ -1,3 +1,11 @@
+mylvmbackup (0.15-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Use SOURCE_DATE_EPOCH to set consistent build
+date. (Closes: #782318)
+
+ -- Vagrant Cascadian   Thu, 22 Sep 2022 
10:11:19 -0700
+
 mylvmbackup (0.15-1.2) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru mylvmbackup-0.15/debian/rules mylvmbackup-0.15/debian/rules
--- mylvmbackup-0.15/debian/rules   2014-05-22 10:27:25.0 -0700
+++ mylvmbackup-0.15/debian/rules   2022-09-22 10:11:19.0 -0700
@@ -3,9 +3,15 @@
 export DH_VERBOSE=1
 export DH_OPTIONS=-v

+# Use consistent date for reproducible builds
+BUILDDATE=$(shell date -u "+%Y-%m-%d" -d "@$(SOURCE_DATE_EPOCH)")
+
 %:
dh  $@

+override_dh_auto_build:
+   dh_auto_build -- BUILDDATE=$(BUILDDATE)
+
 override_dh_auto_install:
dh_auto_install -- prefix=/usr


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020525: ddskk: fails to install with emacs 1.28

[Andreas Beckmann]

Package: ddskk
Version: 17.1-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

  Preparing to unpack .../archives/ddskk_17.1-8_all.deb ...
  Unpacking ddskk (17.1-8) ...
  Setting up ddskk (17.1-8) ...
  Install emacsen-common for emacs
  emacsen-common: Handling install of emacsen flavor emacs
  Install ddskk for emacs
  install/ddskk: Handling install for emacsen flavor emacs
  ERROR: install script from ddskk package failed
  dpkg: error processing package ddskk (--configure):
   installed ddskk package post-installation script subprocess returned error 
exit status 1
  Processing triggers for install-info (6.8-6) ...
  Errors were encountered while processing:
   ddskk

This does not happen in testing which still has emacs 1.27.

(This could be another instance of #1020258, but there is no output
from the actual error available in the log.)

cheers,

Andreas

Bug#1020524: d/watch: use download.libsodium.org

[Andrea Pappacoda]

Source: libsodium
Version: 1.0.18-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, d/watch currently downloads sources from libsodium's GitHub repository,
while the recommended source is download.libsodium.org. As the libsodium
website contains signed tarballs, I believe it should be appropriate for this
package to use them, also because security is especially relevant to this
package.

I've also reported this on https://github.com/gcsideal/debian-
libsodium/issues/5

If you'd like to receive help with the libsodium package I'd be happy to lend a
hand; I really like the library!

Thanks :)


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYyyXKBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p9ALAQCIpF+iJKxZ1oSqCZUIJ7nf72wE+XUj
4YwRCa2NTrN90AEA+D/0n+spkD2AZPc9fUY9nUVStikGyMlUvBNFDsTBIgY=
=Zfz2
-END PGP SIGNATURE-

Bug#1020258: elpa-*: fails to install: libgccjit.so: error: error invoking gcc driver

[Andreas Beckmann]

Control: reassign -1 emacs 1:28.1+1-1
Control: retitle -1 emacs: elpa-*: fails to install: libgccjit.so: error: error 
invoking gcc driver

I'm seeing the 'error invoking gcc driver' error while installing the
following packages along emacs in sid:

elpa-bind-chord=2.4.1-1
elpa-circe=2.11-2
elpa-dap-mode=0.7-3
elpa-elscreen=1.4.6-9
elpa-ement=0.1.4-1
elpa-ess=18.10.2-3
elpa-evil-paredit=0.0.2-5
elpa-evil=1.14.0-1
elpa-folding=0.0~git20220110.1ce338b-1
elpa-git-commit=3.3.0-1
elpa-git-timemachine=4.11-1
elpa-lsp-haskell=1.0.20211214-1
elpa-lsp-java=0.20211124-2
elpa-lsp-mode=8.0.0-4
elpa-lsp-treemacs=0.4-3
elpa-lsp-ui=8.0.0-1
elpa-magit-annex=1.8.1-1
elpa-magit-forge=0.3.1-1
elpa-magit-todos=1.5.3-1
elpa-magit=3.3.0-1
elpa-password-store=1.7.4-5
elpa-persp-projectile=1:0.2.0-4
elpa-smart-mode-line-powerline-theme=2.14-1
elpa-snakemake=2.0.0-2
elpa-treemacs-evil=2.8-2
elpa-treemacs-magit=2.8-2
elpa-use-package-chords=2.4.1-1
elpa-weechat=0.5.0-5

I cannot reproduce this in testing (which still has emacs 1.27),
so this seems to stem from emacs 1.28 (and not gcc 12).

Andreas

Bug#1020523: repo: tests/test_git_trace2_event_log.py::EventLogTestCase::test_write_socket frequently hangs

[Andreas Beckmann]

Package: repo
Version: 2.28-1
Severity: important

Hi,

from time to time I'm doing rebuilds of the contrib and non-free archive
areas. repo has recently started to hang frequently (but not always)
during these rebuilds, always while running the
  tests/test_git_trace2_event_log.py::EventLogTestCase::test_write_socket
test.
This did not seem to happen during an older rebuild at the beginning of
August.

If there is anything I can do to help you debug this issue, please let
me know.

(My rebuilds are happening on amd64 in pbuilder chroots for amd64 and i386,
and under qemu in pbuilder chroots for armhf arm64 ppc64el).


Andreas

Bug#1020495: [Pkg-swan-devel] Bug#1020495: Error: unable to load VPN connection editor - on Identity tab at Gnome Network manager VPN

[Tobias Brunner]

That's because the settings app uses GTK 4, while `nm-connection-editor`
still uses GTK 3.  In order for the strongSwan plugin to work with GTK
4, it has to be built with `--with-gkt4`.  That creates an additional
version of the editor that's linked against GTK 4 (besides the one
linked against GTK 3).  These are actually two shared libraries that are
loaded dynamically at runtime by the main editor plugin depending on
whether it's loaded by a GTK 3 or 4 application.


Ah, thanks for the information. So that means at some point we should enable
that in our build I guess.


Yep.  Is it a problem if the package depends on both libgtk-3-0 and 
libgtk-4-0 as well as libnma0 and libnma-gtk4-0?  Or does that require a 
separate package for the GTK 4 version?  Or is there some metadata magic 
that can make it work with GTK 3 and/or GTK 4 (at least one, but does 
not require both)?


Technically, as I mentioned before, the main plugin 
(libnm-vpn-plugin-strongswan.so), that's the one actually loaded by NM 
or any other GUI, does not depend on libgtk or libnma.  However, 
depending on whether it was loaded by an application that uses GTK 3 or 
GTK 4 (it uses dlsym() to search for a GTK3-only symbol), it then 
dynamically loads either libnm-vpn-plugin-strongswan-editor.so or 
libnm-gtk4-vpn-plugin-strongswan-editor.so via dlopen(), which are 
linked against the corresponding libgtk/libnma.  So I guess one could 
argue that neither is a hard dependency for the package as the 
application that loads the plugin must have such a dependency on either 
version of these libraries anyway (at least libgtk, not sure about 
libnma).  So maybe those dependencies could also be omitted?


Regards,
Tobias

Bug#1020518: [debian-mysql] Bug#1020518: Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote:
> Again, note that I'm still speculating here because I don't follow the
> exact sequence of events which is causing the third party packaging to
> trip up here. If there's something we're doing wrong then we should fix
> it, but nothing I've read so far suggests that.

Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf?
If so, then yes, /usr/share/mysql-common/configure-symlinks could
reasonably not call update-alternatives --install to maintain that
"sysadmin choice". It should probably print a warning in this case.

But we should also take care of the "remove" call too, make sure that
also works if the "install" was skipped.


signature.asc
Description: PGP signature

Bug#1007025: git-multimail 1.6.0 package review

[Antoine Beaupré]

On 2022-09-22 17:03:24, Bo YU wrote:
> Hi,
> On Tue, Sep 20, 2022 at 10:56:05AM -0400, Antoine Beaupré wrote:
>>> https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1245009306
>>> (To avoid bring noisy for upstream, i just recorded it in a issue)
>>
>>I don't think pull requests are noisy... you should probably just submit
>>this as a PR upstream.
>
> Ok, got it. Will do.
> Sometime I mentioned the patch in the issue, the maintainer of upstream will
> pick it into if he think that is valuable.

Yeah, that's a reasonable assumption, but I find that maintainers often
process merge requests way more quickly and easily as they just need one
click to merge. :)

[...]

> I think the people found the issue also:
> https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1252529169
>
> Certainly, lintian will give a kindly warning:
> W: git-multimail: script-with-language-extension [usr/bin/git_multimail.py]
>
> If I understand correctly, this is a bug as you said.
> The workround is still to use launcher file in d/ as in previous commit?

I think the simplest solution is not to rewrite the launcher, but to
rename it. So in debian/rules, you would simply do:

override_dh_auto_install:
dh_auto_install
mv debian/git-multimail/usr/bin/git_multimail.py 
debian/git-multimail/usr/bin/git-multimail

Also, get rid of the noop sections like:

override_dh_installdocs:
dh_installdocs

Cheers!

-- 
I prefer the tumult of liberty to the quiet of servitude.
- Thomas Jefferson

Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 06:21:34PM +0200, Ghislain Adnet wrote:
> So perhaps we could see it another way :
> in this particular case i think that a client library, if it find an existing 
> /etc/mysql/my.cnf, should not do anything as it is there adn so everything it 
> need is okay.
> There is no need for a client library to change this part if it is here if it 
> only need one to exist.
> 
> Perhaps just adding a check
> if [[  ! -e /etc/mysql/my.cnf ]]; then
>   do touch server configuration in /etc/mysql/my.cnf
> fi

We use the Debian-system-wide update-alternatives mechanism, which has
standard and known behaviour. Further, third party packaging can simply
integrate with it to provide their own my.cnf as needed. If
/etc/mysql/my.cnf is properly overriden by packaging, even external
packaging, then the client library packages that touch it will leave it
alone.

I don't think it makes sense to introduce extra behaviour that might be
surprising for sysadmins who already know how update-alternatives works
and integrate with it.

Again, note that I'm still speculating here because I don't follow the
exact sequence of events which is causing the third party packaging to
trip up here. If there's something we're doing wrong then we should fix
it, but nothing I've read so far suggests that.


signature.asc
Description: PGP signature

Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Ghislain Adnet]

Le 22/09/2022 à 18:12, Robie Basak a écrit :

On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote:

* What outcome did you expect instead?

installing a client library should not require anything on the server side 
and should not modify server configuration of mariadb or other mysql flavors 
(imho ;p)


Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and
use /etc/mysql/my.cnf, and many common packages supplied by Debian link
to a MySQL/MariaDB library. So Debian ends up needing to ship a working
/etc/mysql/my.cnf essentially by default. It doesn't matter which side
of the fork is in use - it's necessary either way. Maybe upstream could
separate the two out, but they don't.


thanks for your quick answer

So perhaps we could see it another way :
in this particular case i think that a client library, if it find an existing 
/etc/mysql/my.cnf, should not do anything as it is there adn so everything it 
need is okay.
There is no need for a client library to change this part if it is here if it 
only need one to exist.

Perhaps just adding a check
if [[  ! -e /etc/mysql/my.cnf ]]; then
  do touch server configuration in /etc/mysql/my.cnf
fi



--
cordialement,
Ghislain ADNET.

Bug#1020257: closed by Debian FTP Masters (reply to bott...@debian.org (A. Maitland Bottoms)) (Bug#1020257: fixed in uhd 4.3.0.0+ds1-2)

[Andreas Beckmann]

Control: found -1 4.3.0.0+ds1-2

There is still a wrong version in debian/libuhd4.3.0-dpdk-tests.install:

dpdk/usr/bin/dpdk_* usr/lib/uhd/tests/4.2.0/

Andreas

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

[Agustin Martin]

El mar, 20 sept 2022 a las 22:33, Soren Stoutner
() escribió:
>
> Package: dictionaries-common
> Version: 1.28.18
> Severity: wishlist
> Tags: l10n
>
> Qt WebEngine has the ability to use Hunspell dictionaries for spell checking 
> with the WebEngine, but for some reason they require that the dictionary 
> files be converted to a special binary format (.bdic).  This conversion can 
> be done using qwebengine_convert_dict from the qtwebengine5-dev-tools 
> package.  The upstream documentation regarding this is found on Qt's website:
>
> https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker
>
> Once these libraries are available they can be used by any program that 
> includes Qt WebEngine.
>
> The purpose of this bug report is to create a central location for discussion 
> about the best way to package these dictionaries.

Hi, Soren.

Sorry for the delay. For some reason your messages went to the spambox
and I am becoming aware of them just now (as well as about all this
issue). Here goes a quick reply.

First of all, I am curious about the reasons behind this new format,
the problems it deals with and its advantages. I assume they are valid
enough, but they imply yet another spellchecking engine/format. We
currently have goog old ispell, aspell and hunspell. vim has its own
spellchecker engine using its own format, with dicts that can be
created from old myspell2 dicts. We did not add vim format dicts (from
aspell dicts sources) since there seems to be some work to make vim
use hunspell directly. And now these bdict dicts.

Some other questions here,

>From your info and proposed locations seems that these dicts are
arch:all, ¿is that true?

Another question is what happens with affix files, which I see are
used at build time, ¿are they used (from their path) at runtime or is
all the info (dic+aff) bundled into the bdic file? If explicit affix
files are still required at runtime, both bdic and aff files should
probably be in the same dir. Otherwise I am more for a separate
location. In this case, since bdic dicts seem to be more generic than
just a qtwebengine issue and they are indeed created from hunspell
files I would go for a rather generic name (may be something like
/usr/share/hunspell-bdic or something without the hunspell name?)

Regarding the binary package that should contain them, I tested with
en_US files and bdic file is smaller that .dic file, but not very
much, so size seems not the main reason to go one way or another. Do
not know for other languages. While it is easier to handle
dependencies with separate packages, I admit  I do not have a strong
opinion here,

Regards,

--
Agustin

Bug#1020522: ITP: ncspot - cross-platform TUI client for Spotify

[Blair Noctis]

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: ncspot
  Version : 0.11.1
  Upstream Author : Henrik Friedrichsen 
* URL : https://github.com/hrkfdn/ncspot/
* License : BSD-2-Clause
  Programming Lang: Rust
  Description : cross-platform TUI client for Spotify

ncspot is a cross-platform TUI client for Spotify. It has most of the features
provided by the official client, yet maintains a small memory footprint.


It's a Rust crate and fits in the Rust team packaging process.

-- 
Regards,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020442: heimdal breaks openldap autopkgtest: test smbk5pwd

[Ryan Tandy]

Thanks for raising the bug. The slapd autopkgtest does a chgrp/chmod to 
grant slapd access to the heimdal master key, but the permissions on the 
containing directory (/var/lib/heimdal-kdc) became more restrictive (now 
700). I will update the autopkgtest ASAP.

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Ondřej Surý]

> On 21. 9. 2022, at 20:35, Adam D. Barratt  wrote:
> 
> Control: tags -1 + bullseye
> 
> On Wed, 2022-09-21 at 13:47 +0200, Ondřej Surý wrote:
>> nmu bind-dyndb-ldap_11.6-3 . ANY . bullseye . -m "rebuild for
>> bind9_9.16.33-1~deb11u1"
>> 
>> Hi,
>> 
>> after the bind9_9.16.33-1~deb11u1 is release to bullseye-security,
>> the
>> bind-dyndb-ldap plugin will require binNMU.
>> 
> 
> We can do that - once the packages are in p-u, because p-u chroots
> don't pull in packages from the security archive - but it will mean
> that users won't get the binNMUs until the next point release, which
> probably isn't until November now.
> 
> Is that OK?


Adding Paul, Salvatore and Timo into the bunch.

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.

Should I then prepare a NMU for bullseye-security?

Looks like only viable solution long-term would be to build all the
bind plugins from the src:bind9 package, but it's too late for bullseye.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[Robie Basak]

On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote:
>* What outcome did you expect instead?
> 
>installing a client library should not require anything on the server side 
> and should not modify server configuration of mariadb or other mysql flavors 
> (imho ;p)

Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and
use /etc/mysql/my.cnf, and many common packages supplied by Debian link
to a MySQL/MariaDB library. So Debian ends up needing to ship a working
/etc/mysql/my.cnf essentially by default. It doesn't matter which side
of the fork is in use - it's necessary either way. Maybe upstream could
separate the two out, but they don't.

MySQL and MariaDB Debian maintainers worked out a way to make it work
regardless of the side of the fork in use using the update-alternatives
mechanism. I think there might still be some implementation bugs in how
they do that exactly, but I don't think they're relevant to what you're
reporting here.

If third parties are shipping apt packages that override some of this,
they need to integrate with distribution packages, not the other way
round. Issues with third party apt repositories aren't normally
considered bugs in Debian. This sounds like an issue with a third party
repository and a bug in their packaging, and not a bug in Debian.
However I'm not entirely sure as you haven't provided a detailed
analysis of why they've been unable to integrate.

I suggest that this bug needs to be either moreinfo or wontfix.


signature.asc
Description: PGP signature

Bug#1020519: cyrus-imapd: Permission problem sending redirect email from sieve rule

[Libor Klepáč]

Version: 3.2.6-2+deb11u2

Sorry, it's on Debian Bullseye , i filled the report from my machine
and forgot to change the version

Libor

Bug#1020495: [Pkg-swan-devel] Bug#1020495: Error: unable to load VPN connection editor - on Identity tab at Gnome Network manager VPN

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2022-09-22 at 11:44 +0200, Tobias Brunner wrote:
> That's because the settings app uses GTK 4, while `nm-connection-editor` 
> still uses GTK 3.  In order for the strongSwan plugin to work with GTK 
> 4, it has to be built with `--with-gkt4`.  That creates an additional 
> version of the editor that's linked against GTK 4 (besides the one 
> linked against GTK 3).  These are actually two shared libraries that are 
> loaded dynamically at runtime by the main editor plugin depending on 
> whether it's loaded by a GTK 3 or 4 application.

Ah, thanks for the information. So that means at some point we should enable
that in our build I guess.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmMsiaEACgkQ3rYcyPpX
RFv8dAf/Tr3M8QfC2G5BZyRV6vK8I2W7CS5ckiQzqbWy+/1T/KdfPO6sE9m99zGA
JXAU6up71pqpIcXNUynIPUkbCTy+B+FESzDRczPo0eNvTWG6WJsWIIcHuYEyVDgd
5Inh8QSHQrOhecPgisYx58KtYu7DLLINbceCwlzEW+v5WivzfYrrQ73fi6pmruof
gj/uKZktVXvg1cThKzaKw92mnwARJ6IQnWe1sqNvoF3ro8z+0KPvEbWBNMmhjzNE
0feUaGlwC7cAY7IyWnIhp43Rd6xbajAgK2c4dpRvgRaMNjhWYjWb+og+0qjpXHoO
Kugs8kn0X4AC6DJ/siw/BgPPHaKdUw==
=ltIE
-END PGP SIGNATURE-