Bug#1039555: RM: metview-python [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes & magics++

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: metview-pyt...@packages.debian.org
Control: affects -1 + src:metview-python
Control: block 1039548 by -1

Please remove metview-python from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Christian Kastner]

On 2023-06-27 00:15, Christian Kastner wrote:
> I just have one question about debvm though (hence Helmut in CC), which
> is beyond my depth: is that kernel direct boot something akin to EFI, or
> BIOS, or of its own kind?
> 
> As I've managed to land on a use case where EFI boot seems to be needed
> (PCI device passthrough), at least according to the various docs I found.

Having slept over this, I realize this isn't a big issue for sbuild-qemu
after all. It's only needed if sbuild-qemu wants to run build-time tests.

That would be a nice-to-have, but we also ship (or will ship) upstream's
extensive test suites as autopkgtests, so we have testing covered, and
that nice-to-have shouldn't be a blocker for anything.

Best,
Christian

Bug#1039554: RM: python-cdo [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes & cdo

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-...@packages.debian.org
Control: affects -1 + src:python-cdo
Control: block 1039538 by -1

Please remove python-cdo from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039553: RM: ruby-grib [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-g...@packages.debian.org
Control: affects -1 + src:ruby-grib

Please remove ruby-grib from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039552: RM: pygrib [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pyg...@packages.debian.org
Control: affects -1 + src:pygrib

Please remove pygrib from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039550: RM: metkit [s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: met...@packages.debian.org
Control: affects -1 + src:metkit

Please remove metkit from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039549: RM: magics-python [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: magics-pyt...@packages.debian.org
Control: affects -1 + src:magics-python

Please remove magics-python from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039547: RM: gnudatalanguage [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: gnudatalangu...@packages.debian.org
Control: affects -1 + src:gnudatalanguage

Please remove gnudatalanguage from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039546: RM: glgrib [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: glg...@packages.debian.org
Control: affects -1 + src:glgrib

Please remove glgrib from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039542: RM: emoslib [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: emos...@packages.debian.org
Control: affects -1 + src:emoslib

Please remove emoslib from the architectures where eccodes is no longer 
available

Kind Regards,

Bas

Bug#1035999: Debian 12 rc2 error: 'mdadm: No arrays found in config file or automatically'

[Daniel Baumann]

close 1035999
thanks

Hi Bill,

thank you for your patience - it took some time to systematically
reproduce your bug report.

I've tried the following permutations:

  1. virtualbox with one disk:
1.1 encrypted-partition-on-luks (guided partitioning)
  1.1.1 installing "standard" (no tasks selected)
  1.1.2 installing "gnome-desktop" (default task selection)
1.2 encrypted-partition-on-luks (manual partitioning)
  1.2.1 installing "standard" (no tasks selected)
  1.2.2 installing "gnome-desktop" (default task selection)

  2. virtualbox with two disks attached, only using one:
2.1 encrypted-partition-on-luks (guided partitioning)
  2.1.1 installing "standard" (no tasks selected)
  2.1.2 installing "gnome-desktop" (default task selection)
2.2 encrypted-partition-on-luks (manual partitioning)
  2.2.1 installing "standard" (no tasks selected)
  2.2.2 installing "gnome-desktop" (default task selection)

So in total I did 8 installation with debian-12.0.0-amd64-netinst.iso
and could not reproduce it. I tried everything twice, with a virtualbox
that has two disks attached just to be sure that there's no bug
"sneaking" in mdadm due to some autodetection.

At this point I'm out of ideas on how you ended up with mdadm in the
scenario you described. If you can still reproduce it, please let me
know how (and reopen the bug). In the meanwhile, I'm closing it.

Regards,
Daniel

Bug#1039541: RM: ecmwflibs [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecmwfl...@packages.debian.org
Control: affects -1 + src:ecmwflibs

Please remove ecmwflibs from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039540: RM: eccodes-python [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: eccodes-pyt...@packages.debian.org
Control: affects -1 + src:eccodes-python

Please remove eccodes-python from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039539: RM: cfgrib [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: cfg...@packages.debian.org
Control: affects -1 + src:cfgrib

Please remove cfgrib from the architectures where eccodes is no longer 
available.

Kind Regards,

Bas

Bug#1039538: RM: cdo [armel armhf i386 mipsel s390x] -- RoQA; Blocks removal of eccodes

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: c...@packages.debian.org
Control: affects -1 + src:cdo
Control: block 1039537 by -1

Please remove cdo from the architectures where eccodes is no longer available.

Kind Regards,

Bas

Bug#1039537: RM: eccodes [armel armhf i386 mipsel s390x] -- RoQA; Only supports 64bit little endian architectures

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecco...@packages.debian.org
Control: affects -1 + src:eccodes

Please remove eccodes from armel,armhf,i386,mipsel,s390x, it is no longer 
available on 32bit architectures and FTBFS on big endian architectures.

Kind Regards,

Bas

Bug#1028132: now ready

[Rene Engelhard]

Hi,

Am 27.06.23 um 00:15 schrieb Sebastian Ramacher:

On 2023-06-18 13:57:01 +0200, Rene Engelhard wrote:

Hi,

hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do
this now.

As said it's a no-op for anything except r-cran-hunspell which also is
prepared in experimental together with hunspell itself.

I might add a libhunspell-private-dev package later when I figured out how
to best prevent this by adding a strict dependency there instead of
hardcoding it... But even without that it's better to not have a copy of
private headers in r-cran-hunspell.

Can I upload to unstable?

Please go ahead


Uploaded, thanks.


Andreas, you can upload r-cran-hunspell.


Regards,


Rene

Bug#1039487: [Pkg-zfsonlinux-devel] Bug#1039487: zfs-dkms: autopkgtest fails on Linux 6.3 (arm64 only)

[Aron Xu]

Control: forwarded -1 https://github.com/openzfs/zfs/issues/14555

The issue first appeared in Linux 6.2, caused by commit
aaeca98456431a8d9382ecf48ac4843e252c07b3[1].

Let's wait a bit to see what upstream would respond. We could patch to
disable simd on arm64 (as well as the runtime benchmarks with simd) as
a last resort, though I personally wish to avoid that.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aaeca98456431a8d9382ecf48ac4843e252c07b3

Regards,
Aron

Bug#1039536: mirror submission for mirror.nasutek.com

[Michael Manley]

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

Submission-Type: new
Site: mirror.nasutek.com
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Michael Manley 
Country: CA Canada
Location: Beauharnois, Quebec
Sponsor: NasuTek Global Enterprises https://www.nasutek.com
Comment: CD Images are being mirrored @ http://mirror.nasutek.com/debian-cd as 
well as RSync




Trace Url: http://mirror.nasutek.com/debian/project/trace/
Trace Url: http://mirror.nasutek.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.nasutek.com/debian/project/trace/mirror.nasutek.com

Bug#1039457: mplayer: reproducible-builds: version differences caused by /bin/sh implementations

[Paul Wise]

On Sun, 25 Jun 2023 19:12:59 -0700 Vagrant Cascadian wrote:

> The patch to debian/rules fixes this by using a single printf call
> instead of two echo calls, and adjusting the escaped strings
> accordingly.
...
> + printf "$(OUR_VERSION)\n$(OUR_TITLE)\n"  >> version.h

This is sub-optimal because it means the variable content could be
interpreted by printf, which would mean the output would not be
identical to the variables. This form would avoid that issue:

   printf '%s\n%s\n' "$(OUR_VERSION)" "$(OUR_TITLE)" >> version.h
   
-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1039533: Offer a way to just print the numbers, not also the units

[Adrian Mariano]

The proposed option gives invalid/incorrect results.  The value of 1
mile is not in fact 1609.334---the "m" is an essential part of the
result.  If you want the bare number you can do

factor=$(units --terse 1mi m)

If you don't know what the unit to convert to is---"m" in this
case---then you don't know what the answer means, so you shouldn't be
trying to do anything with it.

So we will not add this feature.  

On Mon, Jun 26, 2023 at 06:42:17PM -0400, Dan Jacobson wrote:
> Package: units
> Version: 2.22-2
> Severity: wishlist
> X-Debbugs-CC: adri...@gnu.org
> 
> 
> Offer a way to just print the numbers, not also the units.
> 
> Currently one must do:
> set $(units --terse 1mi)
> echo $1
> 1609.344
> 
> So maybe have a units --just-the-numbers, when combined with --terse,
> would print just the 1609.344, not the "m".

Bug#1039535: alarm-clock-applet: Drop gconf recommends

[Jeremy Bícha]

Source: alarm-clock-applet
Version: 0.4.1-4

Please don't have alarm-clock-applet recommend
alarm-clock-applet-gconf-migration since that package is no longer
provided.

Thank you,
Jeremy Bícha

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Luca Boccassi  writes:

>> I take care of packages that do not meet the proposed policy. And I
>> don't have a systemd test environment.  I am curious what is the
>> recommended way to go forward.
>>
>> - upload a generator-converted .service without any test;
>> - set low-NMU to encourage interested party to upload a .service;
>> - leave the lack-of-systemd-service bug open until some one submit a
>>   patch or a merge request;
>> - you name it.
>
> Have you already tried booting a test environment in a container
> (lxc/nspawn/podman/docker) or in a VM?

Thanks, Luca.  That's doable.

The problem is that I am now too overloaded and therefore less motivated
to maintain a test environment that I don't use myself.

Russ Allbery  writes:

> systemd unit files for "typical" daemons are very simple to write (simpler
> than an init script in a lot of cases) and generally don't change much.  I
> would, if I were you, be tempted to just write an obvious and simple unit
> file and upload it and let people report bugs if it breaks.  This isn't
> ideal, but at least for simple daemons the risk is probably relatively
> low?  Maybe I'm too cavalier, though.
>
> I suspect there are also a fair number of people who would be happy to
> help write systemd unit files for packages, since (at least in my opinion)
> it's kind of fun.  This isn't the right place to coordinate that, but
> there must be some good spot in Debian.  debian-mentors, maybe?

Thanks Russ!  Your comments alleviated my hesitations to go for option
1.  Then hopefully everyone would be happy :)

Yours,
Benda

Bug#1039472: ca-certificates-java: openjdk-17 update caused install regressions

[Andreas Beckmann]

Followup-For: Bug #1039472
X-Debbugs-Cc: t...@security.debian.org
Control: found -1 20190909
Control: tag -1 patch

This affects bullseye as well:

bullseye# apt-get install openjdk-17-jre-headless=17.0.7+7-1~deb11u1

fails with

...
  Setting up ca-certificates-java (20190909) ...
  head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or 
directory
  Exception in thread "main" java.lang.InternalError: Error loading 
java.security file
at java.base/java.security.Security.initialize(Security.java:106)
at java.base/java.security.Security$1.run(Security.java:84)
at java.base/java.security.Security$1.run(Security.java:82)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.base/java.security.Security.(Security.java:82)
at java.base/sun.security.jca.ProviderList.(ProviderList.java:178)
at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:96)
at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at 
java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:93)
at java.base/sun.security.jca.Providers.(Providers.java:55)
at 
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
at 
java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193)
at org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50)
at 
org.debian.security.UpdateCertificates.(UpdateCertificates.java:65)
at 
org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51)
  dpkg: error processing package ca-certificates-java (--configure):
   installed ca-certificates-java package post-installation script subprocess 
returned error exit status 1
  dpkg: dependency problems prevent configuration of 
openjdk-17-jre-headless:amd64:
   openjdk-17-jre-headless:amd64 depends on ca-certificates-java (>= 
20190405~); however:
Package ca-certificates-java is not configured yet.

  dpkg: error processing package openjdk-17-jre-headless:amd64 (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for libc-bin (2.31-13+deb11u6) ...
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...

  /etc/ca-certificates/update.d/jks-keystore: 82: java: not found
  E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
  done.
  Errors were encountered while processing:
   ca-certificates-java
   openjdk-17-jre-headless:amd64


And for the reference, 

bookworm# apt-get install openjdk-17-jre=17.0.7+7-1~deb12u1

fails with 

...
  Setting up ca-certificates-java (20230103) ...
  Exception in thread "main" java.lang.InternalError: Error loading 
java.security file
at java.base/java.security.Security.initialize(Security.java:106)
at java.base/java.security.Security$1.run(Security.java:84)
at java.base/java.security.Security$1.run(Security.java:82)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.base/java.security.Security.(Security.java:82)
at java.base/sun.security.jca.ProviderList.(ProviderList.java:178)
at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:96)
at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at 
java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:93)
at java.base/sun.security.jca.Providers.(Providers.java:55)
at 
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
at 
java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193)
at org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50)
at 
org.debian.security.UpdateCertificates.(UpdateCertificates.java:65)
at 
org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51)
  dpkg: error processing package ca-certificates-java (--configure):
   installed ca-certificates-java package post-installation script subprocess 
returned error exit status 1
  dpkg: dependency problems prevent configuration of 
openjdk-17-jre-headless:amd64:
   openjdk-17-jre-headless:amd64 depends on ca-certificates-java (>= 
20190405~); however:
Package ca-certificates-java is not configured yet.
  
  dpkg: error processing package openjdk-17-jre-headless:amd64 (--configure):
   dependency problems - leaving unconfigured
  dpkg: dependency problems prevent configuration of openjdk-17-jre:amd64:
   openjdk-17-jre:amd64 depends on openjdk-17-jre-headless (= 
17.0.7+7-1~deb12u1); however:
Package 

Bug#1036461: Please update to at least v7.0.1

[Nicholas D Steeves]

Hello,

Boyuan Yang  writes:

> 在 2023-05-22星期一的 20:55 -0400，Nicholas D Steeves写道：
>> Roman Lebedev  writes:
>> 
> We could do bookworm-backport for easyeffects after Debian 12 release, no
> problem. The package belongs to Multimedia Team from the very beginning; its
> packaging repo can be moved to salsa multimedia-team at anytime.

Would you please move that repo?  I requested this from the salsa admins
on IRC, but didn't receive a reply.  I'll CC them now.

Other than that, easyeffects 7.0.1-1 is now in testing and can be
backported.  I've been testing in on bookworm since I made the upload to
experimental, and it works well.

Warm regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Nicholas D Steeves]

Dear release team, please skip to the bottom for the info you're looking
for.

Salvatore Bonaccorso  writes:

> What is as well different for the uploads is to which upload queue you
> would upload in the end. ftp-master for the proposed-updates via point
> release, security-master for the security uploads.
>
> There are two good entry points about the uploads for stable:

Yikes, how did I miss these?

> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

I've updated the metadata of the blocked bug to show that the version in
bullseye is in fact affected (it already was on the security tracker, of
course).  The rest of the info is there.

> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#handling-security-related-bugs

The vulnerability is already public, and at the blocked bug Salvatore
advised me that a DSA is not required and that uploading to
stable-updates for the next point release is the correct action.

> Hope this helps!

Yes, definitely, much obliged!

Can I upload now?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1038866: closed by Debian FTP Masters (reply to Michael Tautschnig ) (Bug#1038866: fixed in cbmc 5.84.0-6)

[Adrian Bunk]

Control: reopen -1

On Mon, Jun 26, 2023 at 05:24:03AM +, Debian Bug Tracking System wrote:
>...
> Tests failed
>   1 of 453 tests failed, 350 tests skipped
> 
> 
> Failed test: __asm_fstcw-01
>...

This still fails:
https://buildd.debian.org/status/logs.php?pkg=cbmc=5.84.0-6

cu
Adrian

Bug#1039534: squeekboard: Fails to build on Debian Unstable

[Jeremy Bícha]

Source: squeekboard
Version: 1.22.0-2
Severity: serious
Tags: ftbfs sid trixie upstream

squeekboard fails to build in Debian Unstable.

https://buildd.debian.org/status/package.php?p=squeekboard

squeekboard build-depends on missing:
- librust-gtk+v3-22-dev:amd64 (>= 0.14)

The current version of rust-gtk provides librust-gtk+v3-24-dev

Thank you,
Jeremy Bícha

Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[Thomas Uhle]

On Tue, 27 Jun 2023, أحمد المحمودي wrote:


On Tue, Jun 27, 2023 at 12:42:46AM +0200, Thomas Uhle wrote:
> On Mon, 26 Jun 2023, أحمد المحمودي wrote:
>
> > Could this be related to #1023566 ?
---end quoted text---

Sorry, I copied the wrong issue number, I meant: #1035669


It does not seem to be related to #1035669.  It might be though. 
I really don't know.


Best regards,

Thomas Uhle

Bug#1039503: wrongly splits up extended grapheme clusters (like certain emoji)

[Steinar H. Gunderson]

On Mon, Jun 26, 2023 at 08:04:28PM +0200, Steinar H. Gunderson wrote:
> Is it possible to retrofit these rules? This specific rule would seem to
> hit a lot of modern emoji sequences (the Unicode Consortium seems to prefer
> using such sequences instead of defining new code points where possible);
> I would assume including the full table of grapheme clusters would help
> e.g. Korean text, too, although I cannot read Korean and have no idea
> whether it's actually a problem.

The attached patch seems to get us halfway there; screen now combines all of
them correctly into one cluster. However, it's still split for whatever
reason; only if I redraw (C-a l) the flag shows up, and the text breaking is
wrong, so I assume there's at least something wrong with the width
calculation, and possibly lots of other things I've not thought of. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
Description: Better detection of grapheme clusters
Author: Steinar H. Gunderson 
Bug-Debian: https://bugs.debian.org/1039503
Last-Update: 2023-06-25

---

--- screen-4.9.0.orig/ansi.c
+++ screen-4.9.0/ansi.c
@@ -694,9 +702,9 @@ register int len;
 		}
 		  curr->w_rend.font = 0;
 		}
-	  if (curr->w_encoding == UTF8 && c >= 0x0300 && utf8_iscomb(c))
+	  if (curr->w_encoding == UTF8 && c >= 0x0300)
 		{
-		  int ox, oy;
+		  int ox, oy, c_prev;
 		  struct mchar omc;
 
 		  ox = curr->w_x - 1;
@@ -718,15 +726,20 @@ register int len;
 			  omc.mbcs = 0xff;
 			}
 		}
-		  if (ox >= 0)
-		{
-		  utf8_handle_comb(c, );
-		  MFixLine(curr, oy, );
-		  copy_mchar2mline(, >w_mlines[oy], ox);
-		  LPutChar(>w_layer, , ox, oy);
-		  LGotoPos(>w_layer, curr->w_x, curr->w_y);
-		}
-		  break;
+  c_prev = omc.image | (omc.font << 8) | omc.fontx << 16;
+  if (!grapheme_cluster_break(c_prev, c))
+{
+		  if (ox >= 0)
+		{
+		  utf8_handle_comb(c, );
+		  MFixLine(curr, oy, );
+		  copy_mchar2mline(, >w_mlines[oy], ox);
+		  LPutChar(>w_layer, , ox, oy);
+		  LGotoPos(>w_layer, curr->w_x, curr->w_y);
+		}
+		  break;
+}
+  /* fall through */
 		}
 #  ifdef DW_CHARS
 		if (curr->w_encoding == UTF8 && utf8_isdouble(c))
--- screen-4.9.0.orig/encoding.c
+++ screen-4.9.0/encoding.c
@@ -1215,6 +1221,398 @@ int c;
   return bisearch(c, combining, sizeof(combining) / sizeof(struct interval) - 1);
 }
 
+static bool
+is_grapheme_extend(c)
+int c;
+{
+  /* https://unicode.org/Public/15.0.0/ucd/DerivedCoreProperties.txt */
+  static const struct interval grapheme_extend[] = {
+{ 0x0300, 0x036F }, { 0x0483, 0x0487 }, { 0x0488, 0x0489 }, 
+{ 0x0591, 0x05BD }, { 0x05BF, 0x05BF }, { 0x05C1, 0x05C2 }, 
+{ 0x05C4, 0x05C5 }, { 0x05C7, 0x05C7 }, { 0x0610, 0x061A }, 
+{ 0x064B, 0x065F }, { 0x0670, 0x0670 }, { 0x06D6, 0x06DC }, 
+{ 0x06DF, 0x06E4 }, { 0x06E7, 0x06E8 }, { 0x06EA, 0x06ED }, 
+{ 0x0711, 0x0711 }, { 0x0730, 0x074A }, { 0x07A6, 0x07B0 }, 
+{ 0x07EB, 0x07F3 }, { 0x07FD, 0x07FD }, { 0x0816, 0x0819 }, 
+{ 0x081B, 0x0823 }, { 0x0825, 0x0827 }, { 0x0829, 0x082D }, 
+{ 0x0859, 0x085B }, { 0x0898, 0x089F }, { 0x08CA, 0x08E1 }, 
+{ 0x08E3, 0x0902 }, { 0x093A, 0x093A }, { 0x093C, 0x093C }, 
+{ 0x0941, 0x0948 }, { 0x094D, 0x094D }, { 0x0951, 0x0957 }, 
+{ 0x0962, 0x0963 }, { 0x0981, 0x0981 }, { 0x09BC, 0x09BC }, 
+{ 0x09BE, 0x09BE }, { 0x09C1, 0x09C4 }, { 0x09CD, 0x09CD }, 
+{ 0x09D7, 0x09D7 }, { 0x09E2, 0x09E3 }, { 0x09FE, 0x09FE }, 
+{ 0x0A01, 0x0A02 }, { 0x0A3C, 0x0A3C }, { 0x0A41, 0x0A42 }, 
+{ 0x0A47, 0x0A48 }, { 0x0A4B, 0x0A4D }, { 0x0A51, 0x0A51 }, 
+{ 0x0A70, 0x0A71 }, { 0x0A75, 0x0A75 }, { 0x0A81, 0x0A82 }, 
+{ 0x0ABC, 0x0ABC }, { 0x0AC1, 0x0AC5 }, { 0x0AC7, 0x0AC8 }, 
+{ 0x0ACD, 0x0ACD }, { 0x0AE2, 0x0AE3 }, { 0x0AFA, 0x0AFF }, 
+{ 0x0B01, 0x0B01 }, { 0x0B3C, 0x0B3C }, { 0x0B3E, 0x0B3E }, 
+{ 0x0B3F, 0x0B3F }, { 0x0B41, 0x0B44 }, { 0x0B4D, 0x0B4D }, 
+{ 0x0B55, 0x0B56 }, { 0x0B57, 0x0B57 }, { 0x0B62, 0x0B63 }, 
+{ 0x0B82, 0x0B82 }, { 0x0BBE, 0x0BBE }, { 0x0BC0, 0x0BC0 }, 
+{ 0x0BCD, 0x0BCD }, { 0x0BD7, 0x0BD7 }, { 0x0C00, 0x0C00 }, 
+{ 0x0C04, 0x0C04 }, { 0x0C3C, 0x0C3C }, { 0x0C3E, 0x0C40 }, 
+{ 0x0C46, 0x0C48 }, { 0x0C4A, 0x0C4D }, { 0x0C55, 0x0C56 }, 
+{ 0x0C62, 0x0C63 }, { 0x0C81, 0x0C81 }, { 0x0CBC, 0x0CBC }, 
+{ 0x0CBF, 0x0CBF }, { 0x0CC2, 0x0CC2 }, { 0x0CC6, 0x0CC6 }, 
+{ 0x0CCC, 0x0CCD }, { 0x0CD5, 0x0CD6 }, { 0x0CE2, 0x0CE3 }, 
+{ 0x0D00, 0x0D01 }, { 0x0D3B, 0x0D3C }, { 0x0D3E, 0x0D3E }, 
+{ 0x0D41, 0x0D44 }, { 0x0D4D, 0x0D4D }, { 0x0D57, 0x0D57 }, 
+{ 0x0D62, 0x0D63 }, { 0x0D81, 0x0D81 }, { 0x0DCA, 0x0DCA }, 
+{ 0x0DCF, 0x0DCF }, { 0x0DD2, 0x0DD4 }, { 0x0DD6, 0x0DD6 }, 
+{ 0x0DDF, 0x0DDF }, { 0x0E31, 0x0E31 }, { 0x0E34, 0x0E3A }, 
+{ 0x0E47, 0x0E4E }, { 0x0EB1, 0x0EB1 }, { 0x0EB4, 0x0EBC }, 
+{ 0x0EC8, 

Bug#1039528: plastimatch: FTBFS: Could not find a package configuration file provided by "VTK"

[Adrian Bunk]

Control: reassign -1 libinsighttoolkit5-dev 5.3.0-3
Control: affects -1 src:plastimatch

There are actually tow separate issues, both in libinsighttoolkit5-dev:
https://buildd.debian.org/status/logs.php?pkg=plastimatch=1.9.4%2Bdfsg.1-1%2Bb1=amd64

On Tue, Jun 27, 2023 at 12:09:04AM +0200, Sebastian Ramacher wrote:
> Source: plastimatch
> Version: 1.9.4+dfsg.1-1
>...
> CMake Error at 
> /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/Modules/ITKVtkGlue.cmake:16 
> (find_package):
>   Could not find a package configuration file provided by "VTK" with any of
>   the following names:
> 
> VTKConfig.cmake
> vtk-config.cmake
> 
>   Add the installation prefix of "VTK" to CMAKE_PREFIX_PATH or set "VTK_DIR"
>   to a directory containing one of the above files.  If "VTK" provides a
>   separate development package or SDK, be sure it has been installed.
>...

1. The VTK build dependencies for the recent VTK changes also hae to 
   become dependencies of libinsighttoolkit5-dev.


In file included from /<>/src/plastimatch/base/dcmtk_config.h:16,
 from /<>/src/plastimatch/base/metadata.h:12,
 from /<>/src/plastimatch/base/astroid_dose.h:8,
 from /<>/src/plastimatch/base/astroid_dose.cxx:7:
/usr/include/dcmtk/config/osconfig.h:1153:2: error: invalid preprocessing 
directive #errorDCMTK
 1153 | #error\
  |  ^~
 1154 | DCMTK was configured to use C++17 features, but your compiler does not 
or was not configured to provide them.
  | ~

2. This is caused by libinsighttoolkit5-dev injecting -std=c++14 into 
   reverse dependencies, the fix is likely something like
   
https://github.com/InsightSoftwareConsortium/ITK/commit/513507e4c70172d5431563f89dc77c6bae1ad5b1

cu
Adrian

Bug#1039484: transition: gpsd

[Boian Bonev]

Control: tags -1 -moreinfo

Hi,

On Tue, 2023-06-27 at 00:13 +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> On 2023-06-26 13:24:57 +, Boian Bonev wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: g...@packages.debian.org, b...@debian.org
> > Control: affects -1 + src:gpsd
> > 
> > New version of gpsd 3.25 introduces changes in shared libraries API (and of
> > course ABI)
> > soname is bumped from 28 to 30
> > 
> > All rdeps should be good to binNMU against the new libraries, after
> > patching some of
> > them and asking the respective maintainers to upload to unstable.
> 
> Have bugs for those issues been filed?

No, bugs were not filed.

I went the path of filing PRs and/or sending patches over email. All those are
already merged and the fixed packages have been uploaded.

Sorry for being unclear that the above is already complete.

~exp2 differs from ~exp1 by a patch that fixes the build on Hurd. The rest of
the ports did built fine besides alpha (not enough builders or it got stuck)
and the ones that are missing deps... I am not expecting the build on alpha to
fail.

With best regards,
b.


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

Bug#1023566: Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[أحمد المحمودي]

On Tue, Jun 27, 2023 at 12:42:46AM +0200, Thomas Uhle wrote:
> On Mon, 26 Jun 2023, أحمد المحمودي wrote:
> 
> > Could this be related to #1023566 ?
---end quoted text---

Sorry, I copied the wrong issue number, I meant: #1035669

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1039522: usrmerge: cannot complete upgrade to bookworm because of #842145

[Luca Boccassi]

On Mon, 26 Jun 2023 at 23:45, Giuseppe Sacco  wrote:
>
> Hi Marco,
>
> Il giorno lun, 26/06/2023 alle 23.10 +0200, Marco d'Itri ha scritto:
> > On Jun 26, Giuseppe Sacco  wrote:
> > > Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
> > > automatically. See #842145 for details.
> > What is the purpose of opening this new bug about the same issue?
>
> The original bug report does not offer any details, nor solution about the
> problem. Moreover, it does mention a problem about an old debian release
> (stretch). This is a quite old bug that probably people think it cannot be
> really still open.
> A new report, about bookworm, may probably be more easily found in an Internet
> search.

The solution is provided in that bug:

> Since convert-usrmerge can be run in a chroot on the NFS server maybe it 
> would be easier to just make it fail if the
> root is NFS-mounted.

Just like in the overlay or container cases, instead of converting the
client, convert the server first.

Kind regards,
Luca Boccassi

Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[Thomas Uhle]

On Tue, 27 Jun 2023, أحمد المحمودي wrote:


I wonder if this is an issue in libgirepository1.0-dev ? According to
[1], there is a generated dependency on libharfbuzz-gobject0 for sparc64
arch only.

[1] https://packages.debian.org/sid/gir1.2-harfbuzz-0.0


So it is just correct for sparc64, and all the binary packages for the 
other architectures are missing the dependency on libharfbuzz-gobject0. 
If it is an issue of dh_girepository, then it propably is in the package 
gobject-introspection, and not libgirepository1.0-dev.


Best regards,

Thomas Uhle

Bug#1023566: Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[Thomas Uhle]

On Mon, 26 Jun 2023, أحمد المحمودي wrote:


Could this be related to #1023566 ?


No, I don't think so.

This other bug ticket is about Matlab shipping its own version of 
libfreetype.so.6 which is older than version 2.11.0.  Since Debian's 
version of libharfbuzz.so.0 needs version 2.11.0 of libfreetype.so.6 
at least because of function FT_Get_Transform(), Matlab is crashing. 
This is because Matlab is setting $LD_LIBRARY_PATH for its own set of 
libraries.  There are only two solutions: either get rid of Matlab's 
libfreetype.so.6 (as Drew Parsons has suggested) so that the runtime 
linker takes Debian's libfreetype.so.6 or copy an older version of 
libharfbuzz.so.0 to Matlab's own library path, e.g. libharfbuzz.so.0 
from Debian 11 (bullseye).


Best regards,

Thomas Uhle

Bug#1038018: agg: Depends on SDL 1.2

[John Horigan]

libagg/libagg2 come with several example programs that exercise the
library. After the library is built, these programs are built to ensure
that the headers are correct and the library exports the correct symbols.
The resulting binaries are discarded. If libsdl1.2-compat-dev works for
this test built step then I would prefer to use this instead of porting the
examples to SDL2.

I propose to make a new release of libagg/libagg2 using the latest upstream
rev, close this bug using libsdl1.2-compat-dev, and closing a minor bug.

-- john

On Sun, 25 Jun 2023 14:33:38 +0100 Simon McVittie  wrote:
> On Thu, 15 Jun 2023 at 12:31:50 +0100, Simon McVittie wrote:
> > If possible, please port this package to SDL 2 and close this bug.
>
> I couldn't find any sign that agg's reverse dependencies (contextfree,
> desmume, exactimage, svgpp) actually need the SDL 1.2 platform plugin,
> so another possible way to close this bug would be to disable the SDL
> 1.2 plugin. If you do this, please coordinate with the maintainers of
> the reverse dependencies to make sure this won't break them.
>
> > 4. Install libsdl1.2-compat-dev and recompile the package.
>
> I tried this on a porterbox and it seems to build fine. I didn't test
> the resulting binaries.
>
> smcv
>
>

Bug#1039522: usrmerge: cannot complete upgrade to bookworm because of #842145

[Giuseppe Sacco]

Hi Marco,

Il giorno lun, 26/06/2023 alle 23.10 +0200, Marco d'Itri ha scritto:
> On Jun 26, Giuseppe Sacco  wrote:
> > Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
> > automatically. See #842145 for details.
> What is the purpose of opening this new bug about the same issue?

The original bug report does not offer any details, nor solution about the
problem. Moreover, it does mention a problem about an old debian release
(stretch). This is a quite old bug that probably people think it cannot be
really still open.
A new report, about bookworm, may probably be more easily found in an Internet
search.

BTW, 7 years ago you wrote that you didn't had any environment to test this.
If this still stands, I may give you access to this machine, if required. Just
send me a private e-mail with an ssh public key. Or, I may try any suggestion
you might have.

Bye,
Giuseppe

Bug#1039533: Offer a way to just print the numbers, not also the units

[Dan Jacobson]

Package: units
Version: 2.22-2
Severity: wishlist
X-Debbugs-CC: adri...@gnu.org


Offer a way to just print the numbers, not also the units.

Currently one must do:
set $(units --terse 1mi)
echo $1
1609.344

So maybe have a units --just-the-numbers, when combined with --terse,
would print just the 1609.344, not the "m".

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Nick Hastings]

Hi Thorsten,

* Linux regression tracking (Thorsten Leemhuis)  
[230626 21:09]:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Nick, what's the status/was there any progress? Did you do what Mario
> suggested and file a nouveau bug?

It was not apparent that the suggestion to open "a Nouveau drm bug" was
addressed to me.

> I ask, as I still have this on my list of regressions and it seems there
> was no progress in three+ weeks now.

I have not pursued this further since as far as I could tell I already
provided all requested information and I don't actually use nouveau, so
I blacklisted it.

Regards,

Nick.

> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot backburner: slow progress, likely just affects one machine
> #regzbot poke
> 
> 
> On 02.06.23 02:57, Limonciello, Mario wrote:
> > [AMD Official Use Only - General]
> > 
> >> -Original Message-
> >> From: Nick Hastings 
> >> Sent: Thursday, June 1, 2023 7:02 PM
> >> To: Karol Herbst 
> >> Cc: Limonciello, Mario ; Lyude Paul
> >> ; Lukas Wunner ; Salvatore
> >> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> >> Wysocki ; Len Brown ; linux-
> >> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> >> regressi...@lists.linux.dev
> >> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> >> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
> >>
> >> Hi,
> >>
> >> * Karol Herbst  [230602 03:10]:
> >>> On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
> >>>  wrote:
> > -Original Message-
> > From: Karol Herbst 
> > Sent: Thursday, June 1, 2023 12:19 PM
> > To: Limonciello, Mario 
> > Cc: Nick Hastings ; Lyude Paul
> > ; Lukas Wunner ; Salvatore
> > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > Wysocki ; Len Brown ; linux-
> > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > regressi...@lists.linux.dev
> > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> >> system)
> >
> > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> >  wrote:
> >>
> >> [AMD Official Use Only - General]
> >>
> >>> -Original Message-
> >>> From: Karol Herbst 
> >>> Sent: Thursday, June 1, 2023 11:33 AM
> >>> To: Limonciello, Mario 
> >>> Cc: Nick Hastings ; Lyude Paul
> >>> ; Lukas Wunner ; Salvatore
> >>> Bonaccorso ; 1036...@bugs.debian.org; Rafael
> >> J.
> >>> Wysocki ; Len Brown ; linux-
> >>> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> >>> regressi...@lists.linux.dev
> >>> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video
> >> _OSI
> >>> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > system)
> >>>
> >>> On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> 
>  Lyude, Lukas, Karol
> 
>  This thread is in relation to this commit:
> 
>  24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> 
>  Nick has found that runtime PM is *not* working for nouveau.
> 
> >>>
> >>> keep in mind we have a list of PCIe controllers where we apply a
> >>> workaround:
> >>>
> >
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> >>> /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> >>>
> >>> And I suspect there might be one or two more IDs we'll have to add
> >>> there. Do we have any logs?
> >>
> >> There's some archived onto the distro bug.  Search this page for
> > "journalctl.log.gz"
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> >>
> >
> > interesting.. It seems to be the same controller used here. I wonder
> > if the pci topology is different or if the workaround is applied at
> > all.
> 
>  I didn't see the message in the log about the workaround being applied
>  in that log, so I guess PCI topology difference is a likely suspect.
> 
> >>>
> >>> yeah, but I also couldn't see a log with the usual nouveau messages,
> >>> so it's kinda weird.
> >>>
> >>> Anyway, the output of `lspci -tvnn` would help
> >>
> >> % lspci -tvnn
> >> -[:00]-+-00.0  Intel Corporation Device [8086:3e20]
> >>+-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650
> >> Mobile / Max-Q] [10de:1f91]
> > 
> > So the bridge it's connected to is the same that the quirk *should have 
> > been* triggering.
> > 
> > May 29 15:02:42 xps kernel: pci :00:01.0: [8086:1901] type 01 class 
> > 0x060400
> > 
> > Since 

Bug#1039532: debvm: autopkgtest fails due to missing testdep on debian-archive-keyring

[Brian Murray]

Package: debvm
Version: 0.2.12
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic
X-Debbugs-Cc: br...@ubuntu.com

Dear Maintainer,

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

The description, from Brian Murray, follows:

Two autopkgtests, command1 and command2, included with debvm are failing in 
Ubuntu due to a missing test dependency on debian-archive-keyring. Sample 
failure:

Get:1 http://deb.debian.org/debian sid InRelease [195 kB]
Err:1 http://deb.debian.org/debian sid InRelease
  The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
Reading package lists...
W: GPG error: http://deb.debian.org/debian sid InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
E: The repository 'http://deb.debian.org/debian sid InRelease' is not signed.
E: command failed: /usr/share/mmdebstrap/hooks/maybe-merged-usr/setup00.sh
I: main() received signal PIPE: waiting for setup...
bash: line 1:  1306 Hangup  bash -ec './tests/create-and-run.sh 
$(dpkg --print-architecture) sid' 2> >(tee -a 
/tmp/autopkgtest.k9nz7H/command1-stderr 1>&2) > >(tee -a 
/tmp/autopkgtest.k9nz7H/command1-stdout)
Hangup
autopkgtest [18:43:46]: test command1: ---]
command1 FAIL non-zero exit status 255

A full log file can be found at:
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/d/debvm/20230602_184405_93dba@/log.gz

Adding debian-archive-keyring to the dependencies in debian/tests/control will 
resolve the issue.

Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[أحمد المحمودي]

I wonder if this is an issue in libgirepository1.0-dev ? According to 
[1], there is a generated dependency on libharfbuzz-gobject0 for sparc64 
arch only.

[1] https://packages.debian.org/sid/gir1.2-harfbuzz-0.0

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1039531: autoconf2.64: Keep out of testing

[Bastian Germann]

Source: autoconf2.64
Version: 2.64+dfsg-1.1
Severity: serious

Please keep the obsolete autoconf2.64 out of testing.

Bug#1039530: RFS: golang-github-azuread-microsoft-authentication-library-for-go/1.0.0-1 [ITP] -- Sign in users or apps with Microsoft Accounts or Azure AD identities

[Matt Hickford]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package
"golang-github-azuread-microsoft-authentication-library-for-go":

 * Package name :
golang-github-azuread-microsoft-authentication-library-for-go
   Version  : 1.0.0-1
 * URL  :
https://github.com/AzureAD/microsoft-authentication-library-for-go
 * License  : Expat
 * Vcs  :
https://salsa.debian.org/go-team/packages/golang-github-azuread-microsoft-authentication-library-for-go
   Section  : golang

The source builds the following binary packages:

  golang-github-azuread-microsoft-authentication-library-for-go-dev -
Sign in users or apps with Microsoft Accounts or Azure AD identities

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

  
https://mentors.debian.net/package/golang-github-azuread-microsoft-authentication-library-for-go/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-azuread-microsoft-authentication-library-for-go/golang-github-azuread-microsoft-authentication-library-for-go_1.0.0-1.dsc

Changes for the initial release:

 golang-github-azuread-microsoft-authentication-library-for-go
(1.0.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1039471)

Regards,

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Christian Kastner]

On 2023-06-26 21:20, Johannes Schauer Marin Rodrigues wrote:
> this is not a daydream and I think we have nearly all building blocks in place
> to make all of this happen very soon! Here is a summary:
> 
>  1. You use `debvm-create --arch $foo` to create a filesystem image for any
> architecture supported by QEMU without superuser privileges. The
> debvm-create utility is a thin wrapper around mmdebstrap and passes all 
> the
> right arguments to create this filesystem image.
> 
>  2. You use either autopkgtest-virt-qemu or autopkgtest-virt-ssh (depending on
> whether Simon prefers merge request !236 or !237) to run your autopkgtest
> through qemu with that disk image
> 
>  3. ???
> 
>  4. Profit!

As somebody who uses QEMU images for a lot of things, I'm really glad to
hear this. Finally! Getting rid of root is a such a big win, in many ways.

> If you want to upgrade the disk image you can do so by using `debvm-run` which
> gives you a root shell for that disk image where you can just run "apt
> upgrade".
> 
> Now lets get to your "bonus". Once either MR !236 or !237 is accepted I will
> rewrite sbuild-qemu-create to not call autopkgtest-build-qemu (which uses 
> vmdb2
> which requires root) but debvm-create instead. Similarly, the sbuild-qemu
> script will be adapted to call sbuild with the autopkgtest backend and the
> right option (again depending on whether MR !236 or !237 get merged). And the
> sbuild-qemu-update tool will automate the updating so that you don't have to
> run debvm-run yourself.
> 
> Of course once either MR !236 or !237 get merged, you do not have to wait for
> me to change sbuild-qemu. Even before I have done this work you can always
> manually call sbuild with the autopkgtest backend and do your package builds 
> in
> the QEMU image created by debvm-create without superuser privileges.

For FWIW, as stated earlier I fully support this -- in the sense that
whatever changes are necessary or convenient, just go for it. e.g.: I
chose Python for those scripts, but if Perl is more convenient, just
drop the old stuff. Or if I can help, let me know.

I just have one question about debvm though (hence Helmut in CC), which
is beyond my depth: is that kernel direct boot something akin to EFI, or
BIOS, or of its own kind?

As I've managed to land on a use case where EFI boot seems to be needed
(PCI device passthrough), at least according to the various docs I found.

Best,
Christia

Bug#1028132: now ready

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2023-06-18 13:57:01 +0200, Rene Engelhard wrote:
> Hi,
> 
> hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do
> this now.
> 
> As said it's a no-op for anything except r-cran-hunspell which also is
> prepared in experimental together with hunspell itself.
> 
> I might add a libhunspell-private-dev package later when I figured out how
> to best prevent this by adding a strict dependency there instead of
> hardcoding it... But even without that it's better to not have a copy of
> private headers in r-cran-hunspell.
> 
> Can I upload to unstable?

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1039104: transition: draco

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-06-25 20:05:18 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: dr...@packages.debian.org
> Control: affects -1 + src:draco
> 
> Dear release team,
> 
> I want to transition draco after a SONAME bump. AFAICT the new version
> builds fine with the reverse dependencies.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1039484: transition: gpsd

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-06-26 13:24:57 +, Boian Bonev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: g...@packages.debian.org, b...@debian.org
> Control: affects -1 + src:gpsd
> 
> New version of gpsd 3.25 introduces changes in shared libraries API (and of 
> course ABI)
> soname is bumped from 28 to 30
> 
> All rdeps should be good to binNMU against the new libraries, after patching 
> some of
> them and asking the respective maintainers to upload to unstable.

Have bugs for those issues been filed?

Cheers
-- 
Sebastian Ramacher

Bug#1039106: transition: tinygltf

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-06-25 20:19:38 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: tinyg...@packages.debian.org
> Control: affects -1 + src:tinygltf
> 
> Dear release team,
> 
> I want to transition tinygltf after a SONAME bump. I confirmed that
> Open3D builds with the new release on amd64. The Ben tracker is good:
> 
> https://release.debian.org/transitions/html/auto-tinygltf.html

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1039528: plastimatch: FTBFS: Could not find a package configuration file provided by "VTK"

[Sebastian Ramacher]

Source: plastimatch
Version: 1.9.4+dfsg.1-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=plastimatch=amd64=1.9.4%2Bdfsg.1-1%2Bb1=1687808525=0

-- Found HDF5: 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.so;/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so;/usr/lib/x86_64-linux-gnu/libcrypto.so;/usr/lib/x86_64-linux-gnu/libcurl.so;/usr/lib/x86_64-linux-gnu/libpthread.a;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.a;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so;/usr/lib/x86_64-linux-gnu/libcrypto.so;/usr/lib/x86_64-linux-gnu/libcurl.so;/usr/lib/x86_64-linux-gnu/libpthread.a;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.a;/usr/lib/x86_64-linux-gnu/libm.so
 (found version "1.10.8") found components: CXX C HL 
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/Modules/ITKVtkGlue.cmake:16 
(find_package):
  Could not find a package configuration file provided by "VTK" with any of
  the following names:

VTKConfig.cmake
vtk-config.cmake

  Add the installation prefix of "VTK" to CMAKE_PREFIX_PATH or set "VTK_DIR"
  to a directory containing one of the above files.  If "VTK" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:76 (include)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:31 
(itk_module_load)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:129 
(_itk_module_config_recurse)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKConfig.cmake:89 (itk_module_config)
  CMakeLists.txt:573 (find_package)


-- Configuring incomplete, errors occurred!
cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
==> CMakeCache.txt <==
# This is the CMakeCache file.
# For build in directory: /<>/obj-x86_64-linux-gnu
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Build plastimatch as shared library
BUILD_SHARED_LIBS:BOOL=ON

//Build the testing tree.
BUILD_TESTING:BOOL=ON

//Path to a program.
CMAKE_ADDR2LINE:FILEPATH=/usr/bin/addr2line

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//No help, variable specified on the command line.
CMAKE_BUILD_TYPE:STRING=RELEASE

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-12

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-12

//Flags used by the CXX compiler during all build types.
CMAKE_CXX_FLAGS:STRING=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2

//Flags used by the CXX compiler during DEBUG builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-12

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-12

//Flags used by the C compiler during all build types.
CMAKE_C_FLAGS:STRING=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2

//Flags used by the C compiler during DEBUG builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the C compiler during MINSIZEREL builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the C compiler during RELEASE builds.
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the C compiler during RELWITHDEBINFO builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Path to a program.

Bug#1039529: sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared

[Sebastian Ramacher]

Source: sight
Version: 21.1.1-3
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=sight=amd64=21.1.1-3%2Bb2=1687809257=0

[ 66%] Linking CXX shared library 
../../../lib/x86_64-linux-gnu/libsight_module_filter_vision.so
cd /<>/obj-x86_64-linux-gnu/modules/filter/vision && 
/usr/bin/cmake -E cmake_link_script 
CMakeFiles/module_filter_vision.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wl,--as-needed -Wl,--sort-common -Wl,-O2 
-Wl,-z,relro -Wl,-z,now -shared 
-Wl,-soname,libsight_module_filter_vision.so.21.1 -o 
../../../lib/x86_64-linux-gnu/libsight_module_filter_vision.so.21.1.0 
CMakeFiles/module_filter_vision.dir/Plugin.cpp.o 
CMakeFiles/module_filter_vision.dir/SColourImageMasking.cpp.o 
CMakeFiles/module_filter_vision.dir/SDepthImageMasking.cpp.o 
CMakeFiles/module_filter_vision.dir/SOpticalFlow.cpp.o 
CMakeFiles/module_filter_vision.dir/SPointCloudFromDepthMap.cpp.o 
CMakeFiles/module_filter_vision.dir/STransformDepthMap2mm.cpp.o 
CMakeFiles/module_filter_vision.dir/STransformDepthTL2mm.cpp.o 
CMakeFiles/module_filter_vision.dir/SUltrasoundImage.cpp.o 
CMakeFiles/module_filter_vision.dir/registerServices.cpp.o  
-Wl,-rpath,/<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/libopencv_highgui.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_video.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_service.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_geometry_data.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_filter_vision.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_io_opencv.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libopencv_videoio.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_dnn.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_features2d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_flann.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_activity.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libopencv_ml.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0 
../../../lib/x86_64-linux-gnu/libsight_data.so.21.1.0 
../../../lib/x86_64-linux-gnu/libsight_core.so.21.1.0 
/usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_log_setup.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_log.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_regex.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 
/usr/lib/x86_64-linux-gnu/libxml2.so /usr/lib/x86_64-linux-gnu/libcrypto.so 
-ldl /usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_features2d.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_flann.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.4.6.0 
/usr/lib/x86_64-linux-gnu/libopencv_core.so.4.6.0 
In file included from /usr/include/ITK-5.3/itkLightObject.h:21,
 from /usr/include/ITK-5.3/itkObject.h:31,
 from /usr/include/ITK-5.3/itkLightProcessObject.h:21,
 from /usr/include/ITK-5.3/itkImageIOBase.h:24,
 from 
/<>/libs/io/itk/inr2itk/itkInrImageIOFactory.hpp:25,
 from /<>/libs/io/itk/ImageReader.cpp:25:
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: 
‘LightObject’ in namespace ‘sight::io::itk’ does not name a type
   48 | itkNewMacro(Self);
  | ^~~
/<>/libs/io/itk/helper/ProgressItkToFw.hxx: In static member 
function ‘static sight::io::itk::LocalCommand::Pointer 
sight::io::itk::LocalCommand::New()’:
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: 
‘ObjectFactory’ is not a member of ‘sight::io::itk’; did you mean 
‘itk::ObjectFactory’?
   48 | itkNewMacro(Self);
  | ^~~
In file included from /usr/include/ITK-5.3/itkLightProcessObject.h:22:
/usr/include/ITK-5.3/itkObjectFactory.h:55:7: note: ‘itk::ObjectFactory’ 
declared here
   55 | class ObjectFactory : public ObjectFactoryBase
  |   ^
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: expected 
primary-expression before ‘>’ token
   48 | itkNewMacro(Self);
  | ^~~
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ 
has not been declared
   48 | itkNewMacro(Self);
  | ^~~
[ 66%] Building CXX object libs/io/vtk/CMakeFiles/io_vtk.dir/ImageReader.cpp.o

Cheers
-- 
Sebastian 

Bug#1039527: strongswan: outdated d/copyright file

[Andreas Hasenack]

Package: strongswan
Version: 5.9.11-1
Severity: normal

Dear Maintainer,

on a recent build of strongswan, lintian is reporting that many source
files are not covered by the current d/copyright contents. I'm going
to paste it below:


W: strongswan source: file-without-copyright-information
.tarball-git-version [debian/copyright]
W: strongswan source: file-without-copyright-information AUTHORS
[debian/copyright]
W: strongswan source: file-without-copyright-information
Android.common.mk [debian/copyright]
W: strongswan source: file-without-copyright-information
Android.common.mk.in [debian/copyright]
W: strongswan source: file-without-copyright-information Android.mk
[debian/copyright]
W: strongswan source: file-without-copyright-information ChangeLog
[debian/copyright]
W: strongswan source: file-without-copyright-information Doxyfile.in
[debian/copyright]
W: strongswan source: file-without-copyright-information INSTALL
[debian/copyright]
W: strongswan source: file-without-copyright-information Makefile.am
[debian/copyright]
W: strongswan source: file-without-copyright-information Makefile.in
[debian/copyright]
W: strongswan source: file-without-copyright-information NEWS [debian/copyright]
W: strongswan source: file-without-copyright-information README
[debian/copyright]
W: strongswan source: file-without-copyright-information TODO [debian/copyright]
W: strongswan source: file-without-copyright-information aclocal.m4
[debian/copyright]
W: strongswan source: file-without-copyright-information compile
[debian/copyright]
W: strongswan source: file-without-copyright-information config.guess
[debian/copyright]
W: strongswan source: file-without-copyright-information config.h.in
[debian/copyright]
W: strongswan source: file-without-copyright-information config.sub
[debian/copyright]
W: strongswan source: file-without-copyright-information configure
[debian/copyright]
W: strongswan source: file-without-copyright-information configure.ac
[debian/copyright]
W: strongswan source: file-without-copyright-information depcomp
[debian/copyright]
W: strongswan source: file-without-copyright-information
fuzz/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
fuzz/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
init/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
init/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd-starter/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd-starter/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd-starter/strongswan-starter.service.in [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
init/systemd/strongswan.service.in [debian/copyright]
W: strongswan source: file-without-copyright-information install-sh
[debian/copyright]
W: strongswan source: file-without-copyright-information
m4/config/libtool.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/config/ltoptions.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/config/ltsugar.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/config/ltversion.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/config/lt~obsolete.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/macros/add-plugin.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/macros/enable-disable.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/macros/split-package-version.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
m4/macros/with.m4 [debian/copyright]
W: strongswan source: file-without-copyright-information
man/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
man/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
man/ipsec.conf.5.in [debian/copyright]
W: strongswan source: file-without-copyright-information
man/ipsec.secrets.5.in [debian/copyright]
W: strongswan source: file-without-copyright-information missing
[debian/copyright]
W: strongswan source: file-without-copyright-information
scripts/Makefile.am [debian/copyright]
W: strongswan source: file-without-copyright-information
scripts/Makefile.in [debian/copyright]
W: strongswan source: file-without-copyright-information
scripts/git-version [debian/copyright]
W: strongswan source: file-without-copyright-information
scripts/os_info.c [debian/copyright]
W: strongswan source: file-without-copyright-information

Bug#1039498: gir1.2-harfbuzz-0.0: missing dependency on libharfbuzz-gobject0

[أحمد المحمودي]

Could this be related to #1023566 ?
-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1039526: gcc-9-cross-mipsen: Update to autoconf2.69

[Bastian Germann]

Source: gcc-9-cross-mipsen
Version: 4+c2

Please update the autoconf2.64 build dependency to autoconf2.69 which is also 
implied by gcc-9-source.
It is of the last autoconf2.64 reverse dependencies, so updating contributes to 
dropping autoconf2.64 from the archive.

Bug#1039508: systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size"

[Michael Biebl]

Am 26.06.23 um 22:34 schrieb Michael Biebl:

We will most likely provide backports of v253 and later via 
bookworm-backports (this doesn't affect the install media though).


If you want to see this fixed directly in unstable, i.e. for v252, I 


I meant "stable" obviously, ...



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039525: gcc-9-cross-ports: Update to autoconf2.69

[Bastian Germann]

Source: gcc-9-cross-ports
Version: 25

Please update the autoconf2.64 build dependency to autoconf2.69 which is also 
implied by gcc-9-source.
It is of the last autoconf2.64 reverse dependencies, so updating contributes to 
dropping autoconf2.64 from the archive.

Bug#1039524: ITP: node-proxy-agent -- Maps proxy protocols to http.Agent implementations

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-proxy-agent
  Version : 5.0.0
  Upstream Author : Nathan Rajlich  
(http://n8.io/)

* URL : https://github.com/TooTallNate/node-proxy-agent
* License : Expat
  Programming Lang: JavaScript
  Description : Maps proxy protocols to http.Agent implementations

This module provides a function that returns proxying http.Agent
instances to use based off of a given proxy URI.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039523: ITP: x2gokdrive -- KDrive graphical server backend for X2Go Server

[Mike Gabriel]

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

* Package name: x2gokdrive
  Version : 0.0.0.1
  Upstream Contact: Oleksandr Shneyder 
* URL : https://code.x2go.org/gitweb?p=x2gokdrive.git;a=summary
* License : GPL-2+
  Programming Lang: C
  Description : KDrive graphical server backend for X2Go Server

 X2Go is a server based computing environment with
- session resuming
- low bandwidth support
- session brokerage support
- client-side mass storage mounting support
- client-side printing support
- audio support
- authentication by smartcard and USB stick
 .
 This package is built from the X.org xserver module. X2Go KDrive is a
 KDrive-based Xserver for X2Go. It provides support for running modern
 desktop environments like GNOME, KDE Plasma, Cinnamon, etc. in X2Go
 Sessions.
 .
 The X2Go KDrive graphical backend is not suitable for low bandwidth WAN
 connections between X2Go Client and X2Go Server. It is supposed for X2Go
 being used on the local area network.
 .
 More information about X.Org can be found at:
 https://www.x.org>
 .
 More information about X2Go can be found at:
 https://wiki.x2go.org>
 .
 This package will be maintained under the umbrella of the Debian Remote
 Packaging Team.

Bug#1039522: usrmerge: cannot complete upgrade to bookworm because of #842145

[Marco d'Itri]

On Jun 26, Giuseppe Sacco  wrote:

> Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
> automatically. See #842145 for details.
What is the purpose of opening this new bug about the same issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1039521: Also caring for junit:junit

[Pierre Gruet]

Hello again,

Sorry, it seems I sent the bug report too early. There should be another 
change in java/util.pom.xml : the junit artifact misses the "test" 
scope. Precisely, we should change the junit stanza to



junit
junit
test


Else, junit would be needed during the build of rdeps even when one 
would not run any test (DEB_BUILD_OPTIONS=nocheck e.g.).


Thanks again,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039522: usrmerge: cannot complete upgrade to bookworm because of #842145

[Giuseppe Sacco]

Package: usrmerge
Version: 35
Severity: normal

Dear Maintainer,
while upgrading a diskless system, I've got this message:

root@aristotele:~# dpkg --configure --pending
Configurazione di usrmerge (35)...

Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run
automatically. See #842145 for details.

E: usrmerge failed.
dpkg: errore nell'elaborare il pacchetto usrmerge (--configure):
 il sottoprocesso installato pacchetto usrmerge script post-installation ha 
restituito lo stato di errore 1
Si sono verificati degli errori nell'elaborazione:
 usrmerge


stopping the upgrade. In fact, the upgrade cannot continue with usrmerge 
enable. I tried removing usrmerge
and putting it on hold using dpkg --set-selections, but then "apt upgrade" stop 
again here:

preparativi per estrarre .../usr-is-merged_35_all.deb...


**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
**


dpkg: errore nell'elaborare l'archivio 
/var/cache/apt/archives/usr-is-merged_35_all.deb (--unpack):
 il sottoprocesso nuovo pacchetto usr-is-merged script pre-installation ha 
restituito lo stato di errore 1
Si sono verificati degli errori nell'elaborazione:
 /var/cache/apt/archives/usr-is-merged_35_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


and the whole process cannot go any further.

Bye,
Giuseppe

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-3
ii  perl    5.36.0-7

usrmerge recommends no packages.

usrmerge suggests no packages.

-- no debconf information

Bug#1038603: Seems fixed in unstable

[Aurelien Jarno]

control: retitle -1 libisl23: amd64/i386 baseline violation: uses BMI 
instructions
control: severity -1 serious
control: reassign -1 libisl23
control: found -1 0.25-1
control: fixed -1 0.26-3

Hi,

On 2023-06-19 20:27, Jeronimo Pellegrini wrote:
> The new uploaded libisl23 (version 0.26-3) seems to have fixed the
> problem (I have successfully compiled darktable with GCC 12).
> 
> Thanks a lot Matthias for the really wuick fix to the problem!

I also got bitten by this bug. It is indeed fixed in testing/unstable,
but it also needs to get fixed in stable. Let's start by assigning the
bug to the package that has the bug with the right versions.

I have used the version from stable for the found, even if the bug is
theoretically present in oldstable, it's just that it has been built on
buildds without extra instruction set compared to the baseline

Regards
Aurelien

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

Bug#1039521: requires unpackaged j2objc artifacts through pom.xml

[Pierre Gruet]

Package: libprotobuf-java
Version: 3.21.12-3
Severity: important
Tags: patch

Dear Maintainer,

I am in the progress of updating one of my packages, genomicsdb. While doing
so, I stumbled upon an issue in the file

/usr/share/maven-repo/com/google/protobuf/protobuf-java-util/3.21.12/protobuf-java-util-debian.pom
that is shipped by libprotobuf-java. It requires the j2objc-annotations
artifact as one of its dependencies, although this is not available in Debian.
I suggest to enrich a bit the dedicated patch you wrote for src:protobuf in
order to move this dependency out of the way. Right now, the new upstream
version of genomicsdb cannot be built.

The enclosed patch does this.

I will be happy to give more information if needed.

Thanks for considering,

-- 
Pierre
diff -Nru protobuf-3.21.12/debian/patches/no_j2objc.patch 
protobuf-3.21.12/debian/patches/no_j2objc.patch
--- protobuf-3.21.12/debian/patches/no_j2objc.patch 2022-03-11 
01:28:07.0 +0100
+++ protobuf-3.21.12/debian/patches/no_j2objc.patch 2023-06-26 
20:52:50.0 +0200
@@ -8,7 +8,7 @@
 
 --- a/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
 +++ b/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
-@@ -38,7 +38,7 @@ import static com.google.common.math.Lon
+@@ -38,7 +38,7 @@
  
  //import com.google.errorprone.annotations.CanIgnoreReturnValue;
  //import com.google.errorprone.annotations.CompileTimeConstant;
@@ -17,7 +17,7 @@
  import com.google.protobuf.Duration;
  import com.google.protobuf.Timestamp;
  import java.io.Serializable;
-@@ -338,7 +338,6 @@ public final class Timestamps {
+@@ -338,7 +338,6 @@
 * @throws IllegalArgumentException if the year is before 1 CE or after 
 CE
 */
@SuppressWarnings("GoodTime") // this is a legacy conversion API
@@ -25,3 +25,19 @@
public static Timestamp fromDate(Date date) {
  if (date instanceof java.sql.Timestamp) {
java.sql.Timestamp sqlTimestamp = (java.sql.Timestamp) date;
+--- a/java/util/pom.xml
 b/java/util/pom.xml
+@@ -27,11 +27,11 @@
+   error_prone_annotations
+   2.5.1
+ 
+-
++
+ 
+   com.google.code.findbugs
+   jsr305

Bug#1039508: systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size"

[Michael Biebl]

Am 26.06.23 um 21:39 schrieb James L Baker:


And this github issue thread identifies the cause as systemd, and reports a 
merged patch which corrects it:
https://github.com/systemd/systemd/issues/25911

Is there any chance to include a more recent version of systemd (the "-boot" or 
"-boot-efi" packages, I assume) with the install media?  Or a recommended way to load a 
newer package version during install, prior to first boot?


We will most likely provide backports of v253 and later via 
bookworm-backports (this doesn't affect the install media though).


If you want to see this fixed directly in unstable, i.e. for v252, I 
would first ask in the upstream issue, that 
https://github.com/systemd/systemd/pull/25948 is also backported to 
v252-stable.


Once that happens, we can consider cherry-picking it in Debian.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009071: nmu

[matthias . geiger1024]

Sure it is:

https://salsa.debian.org/rust-team/debcargo-conf/-/commit/81914839c41a7ab99a910c1f90316e0a1c59d2af

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1039519: ITP: golang-maunium-go-mauflag -- Extendable argument parser for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-maunium-go-mauflag
  Version : 1.0.0-1
  Upstream Author : 2016 Maunium
* URL : https://github.com/tulir/mauflag.git
* License : GPL-3
  Programming Lang: Go
  Description : Extendable argument parser for Golang
 Mauflag is an extendable argument parser for golang that mostly
 follows GNU Program Argument Syntax Conventions.
 .
 This is a transitive dep of gomuks.

Bug#1039517: trixie : install bug

[Jean-Claude CATY]

Package: installation-reports
Boot method: I tried to install debian testing (trixie). First using 
debian-testing-amd64-DVD-1.iso, second with 
debian-testing-amd64-netinst.iso on USB key.

https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
images date's are 2023-06-12

*Machine: *
Processor: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
*Memory:*
cat /proc/meminfo
   MemTotal:    7793616 kB
   MemFree: 4302748 kB


*Partitions: *
   to do during install

*Résultat de lspci -knn (ou lspci -nn) :*
lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor 
DRAM Controller [8086:0c00] (rev 06)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 
v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] 
(rev 06)
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor HD Audio Controller [8086:0c0c] (rev 06)
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series 
Chipset Family USB xHCI [8086:8c31] (rev 05)
00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 
Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series 
Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series 
Chipset High Definition Audio Controller [8086:8c20] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series 
Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d5)
00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series 
Chipset Family PCI Express Root Port #2 [8086:8c12] (rev d5)
00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series 
Chipset Family PCI Express Root Port #3 [8086:8c14] (rev d5)
00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series 
Chipset Family PCI Express Root Port #5 [8086:8c18] (rev d5)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series 
Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
00:1f.0 ISA bridge [0601]: Intel Corporation H81 Express LPC Controller 
[8086:8c5c] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series 
Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset 
Family SMBus Controller [8086:8c22] (rev 05)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] 
(rev 06)
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] 
(rev 0c)
05:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042A USB 3.0 
Host Controller [1b21:1142]


*Installation du système de base :*
[O] = OK, [E] = Error (développez plus bas s'il vous plait), [ ] = non 
essayé


Initial boot:   [O]
Detect network card:    [O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:    [E] installation problem while trying install 
libbpf1_1.1.0-1_amd64.deb

Clock/timezone setup:   [ ]
User/password setup:    [ ]
Install tasks:  [ ]
Install boot loader:    [ ]
Overall install:    [ ]

Comments/Problems:
There was a problem during install with libbpf1_1.1.0-1_amd64.deb
iso's sha256sum are ok.
I tried to replace libbpf1_1.1.0-1_amd64.deb in ISOs but the problem is 
similar.


--
*Envoyé depuis une machine pilotée par GNU/Linux Debian, dépourvue de 
#$]@!¤ (CrimeAuSoft 20 doses)*
*Vous pouvez crypter les courriels à mon attention en utilisant ma clé 
publique jointe à ce courriel*


*Jean-Claude CATY 
(jc2023.c...@laposte.net)*
*Animateur GNU/Linux (Linux de base / avancé)*
*Club Informatique Loriolais*
*Maison des associations*   *GPS : Latitude : 44°45'07.0"N*
*GPS : Longitude : 04°49'17.1"E*
*Place Hannibal*
*26270 Loriol*



OpenPGP_0x3165709FEE52B44B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039518: fs-uae: please repack to not embed lua

[Bastien Roucariès]

Source: fs-uae
Severity: important

Dear Maintainer,

Your package embed lua;

It is best practice to repack in order to avoid accidental compilation

Thanks

Bastien


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

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

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?

[Dirk Eddelbuettel]

Hi Paul,

I really appreciate the diligence and detail you put into this.

But I would like to offer a simple shortcut.  I am also CCing debian-r again
as this has come up time and time again, is guaranteed to come up again for
as long as combine autopkgtests with letting packages go stake.


Point 0: Trust CRAN.

  CRAN *never* lets a package onto their repo in their (complete) reverse
  depends checks reveal anything.

  Ever.  (Unless a coordinated update is made.)

  E.g. I just sent a patch to uwot (aka r-cran-uwot) because my RcppAnnoy
  package (aka r-cran-rcppannoy) updated upstream annoy, introduces a C++
  namespace in the header and breaks downstream compilation. So I altered
  uwot accordingly (last week), waited a few days for the maintainer to
  update it (big-ish package, he had other pending changes), it got onto CRAN
  today so I likely send RcppAnnoy tomorrow.

  CRAN very strongly believes in 'everything works at @HEAD' so if everything
  is current, everything is generally installable at all times.  This is
  unparalleled in open source. No other repo gives such guarantees. I have
  worked with them as both package maintainer (for Debian) and upstream for
  twenty years.  The trust is earned.


Point 1: So check CRAN for the newly updated package

  See
https://cloud.r-project.org/web/packages/mvtnorm/index.html
  and esp the results aggregation
https://cloud.r-project.org/web/checks/check_results_mvtnorm.html
  which is *pristine*.

  So the smoke starts to come from our corners.


Point 2: So check CRAN for borked package

  See
https://cloud.r-project.org/web/packages/pammtools/index.html
  and note how it was update in March and is at 0.5.91

  Whereas we are at 0.5.8.


So I think that is not a bug in mvtnorm aka r-cran-mvtnorm.

You could of course ask me to add versioning info to r-cran-mvtnorm but as I
strongly suspect that the issue goes away once pammtools aka r-cran-pammtools
updates, I think that that would be the wrong way to go.


Sorry for the long email but there **value** in CRAN. We would be foolish to
ignore it.

Cheers, Dirk
 



On 26 June 2023 at 21:53, Paul Gevers wrote:
| Source: mvtnorm, r-cran-pammtools
| Control: found -1 mvtnorm/1.2-2-1
| Control: found -1 r-cran-pammtools/0.5.8-1
| Severity: serious
| Tags: sid bookworm
| User: debian...@lists.debian.org
| Usertags: breaks needs-update
| 
| Dear maintainer(s),
| 
| With a recent upload of mvtnorm the autopkgtest of r-cran-pammtools 
| fails in testing when that autopkgtest is run with the binary packages 
| of mvtnorm from unstable. It passes when run with only packages from 
| testing. In tabular form:
| 
| passfail
| mvtnormfrom testing1.2-2-1
| r-cran-pammtools   from testing0.5.8-1
| versioned deps [0] from testingfrom unstable
| all others from testingfrom testing
| 
| I note that with both versions from unstable the test also passes, which 
| hints at either a missing *versioned* test dependency in 
| r-cran-pammtools (if it *only* breaks the test), or missing versioned 
| Breaks in mvtnorm *and* a missing versioned Depends in r-cran-pammtools 
| if r-cran-pammtools is really broken with the wrong version of mvtnorm.
| 
| I copied some of the output at the bottom of this report.
| 
| Currently this regression is blocking both the migration of mvtnorm to 
| testing [1] and the migration of r-cran-pammtools to testing [2]. Due to 
| the nature of this issue, I filed this bug report against both packages. 
| Can you please investigate the situation and reassign the bug to the 
| right package?
| 
| More information about this bug and the reason for filing it can be found on
| https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
| 
| Paul
| 
| [0] You can see what packages were added from the second line of the log 
| file quoted below. The migration software adds source package from 
| unstable to the list if they are needed to install packages from 
| mvtnorm/1.2-2-1. I.e. due to versioned dependencies or breaks/conflicts.
| [1] https://qa.debian.org/excuses.php?package=mvtnorm
| [2] https://qa.debian.org/excuses.php?package=r-cran-pammtools
| 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pammtools/34886689/log.gz
| 
|   46s BEGIN TEST testthat.R
|   46s  46s R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
|   46s Copyright (C) 2023 The R Foundation for Statistical Computing
|   46s Platform: x86_64-pc-linux-gnu (64-bit)
|   46s  46s R is free software and comes with ABSOLUTELY NO WARRANTY.
|   46s You are welcome to redistribute it under certain conditions.
|   46s Type 'license()' or 'licence()' for distribution details.
|   46s  46s R is a collaborative project with many contributors.
|   46s Type 'contributors()' for more information and
|   46s 'citation()' on how to cite R or R packages in publications.
|   46s  46s Type 'demo()' for some demos, 'help()' for 

Bug#1039516: RFS: shotwell/0.32.1-1 -- digital photo organizer

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : shotwell
   Version  : 0.32.1-1
   Upstream contact : Jim Nelson 
   URL  : https://wiki.gnome.org/Apps/Shotwell
   License  : LGPL-2.1
   Vcs  : https://git.jff.email/cgit/shotwell.git
   Section  : gnome

The source builds the following binary packages:

  shotwell - digital photo organizer
  shotwell-common - digital photo organizer - common files

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.32.1-1.dsc

or from

 git https://git.jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.32.1-1

Changes since the last upload:

 shotwell (0.32.1-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #1034018, #1034011, #1034017):
 - debian/rules:
   + Replace unity-support with unity_support.
 - debian/control:
   + Add libportal-gtk3-dev, libwebp-dev, and libsecret-1-dev to Build-
Depends.
   + Switch Build-Depends to libwebkit2gtk-4.1-dev.
   + Add bump minimum release of libgexiv2-dev to >= 0.12.0-2~.
 - Thanks to Jeremy Bícha .
   * debian/control:
 - Change to new repository.
 - Move Build Depend webp-pixbuf-loader to Depends (Closes: #1034010)
   + Thanks to Jeremy Bícha .
   * debian/copyright:
 - Add year 2023 to myself.
 - Refresh for the new release.
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1039515: RFS: sane-backends/1.2.1-3 -- API development library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

   Package name : sane-backends
   Version  : 1.2.1-3
   Upstream contact : 
   URL  : http://www.sane-project.org
   License  : Artistic, GPL-2, GPL-2+, GPL-3+, 
  GPL-2+ with sane exception, LGPL-2.1+
   Vcs  : https://git.jff.email/cgit/sane-backends.git
   Section  : graphics

The source builds the following binary packages:

  sane-utils - API library for scanners -- utilities
  libsane-common - API library for scanners -- documentation and support files
  libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.2.1-3.dsc

or from

 git https://git.jff.email/cgit/sane-backends.git/?h=release%2Fdebian%2F1.2.1-3


Changes since the last upload:

 sane-backends (1.2.1-3) unstable; urgency=medium
 .
   * debian/control:
 - Drop transitional package libsane (Closes: #1038302).
   + Thanks to Holger Levsen .
 - Change to new repository URL.
   * debian/patches/0040-remove_git.patch:
 - Update .tarball-version to the current version (Closes: #1036870).
   + Thanks to Jan Binder .
   * debian/patches/0175-fix_tests.patch:
 - Update to the current version.
   * New debian/po/ro.po (Closes: #1033709).
 - Thanks to "Remus-Gabriel Chelu" .
   * debian/copyright:
 - Correcting the license of debian/po/fr.po to GPL-2+ with sane exception
   and remove the GFDL-1.1 text (Closes: #1033979).
   + Thanks to Bastian Germann 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1039513: RFS: ipmitool/1.8.19-6 -- utility for IPMI control with kernel driver or LAN interface (daemon)

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : ipmitool
   Version  : 1.8.19-6
   Upstream contact : [fill in name and email of upstream]
   URL  : https://github.com/ipmitool/ipmitool
   License  : BSD-3-clause
   Vcs  : https://git.jff.email/cgit/ipmitool.git
   Section  : utils

The source builds the following binary packages:

  ipmitool - utility for IPMI control with kernel driver or LAN interface
(daemon)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.19-6.dsc

or from

 git https://git.jff.email/cgit/ipmitool.git/?h=release%2Fdebian%2F1.8.19-6


Changes since the last upload:

 ipmitool (1.8.19-6) unstable; urgency=medium
 .
   * Upload to unstable.
   * debian/control:
 - Change to new repository URL.
   * debian/rules:
 - Add tag get_e-numbers to download a new enterprise-numbers.txt.
   * debian/enterprise-numbers.txt:
 - Download a new version.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1039514: RFS: cil/0.07.00-13 -- command line issue tracker

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : cil
   Version  : 0.07.00-13
   Upstream contact : Andrew Chilton 
   URL  : https://github.com/chilts/cil
   License  : GPL-3+
   Vcs  : https://git.jff.email/cgit/cil.git
   Section  : perl

The source builds the following binary packages:

  cil - command line issue tracker

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

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

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

 dget -x https://mentors.debian.net/debian/pool/main/c/cil/cil_0.07.00-13.dsc

or from 

 git https://git.jff.email/cgit/cil.git/?h=release%2Fdebian%2F0.07.00-13

Changes since the last upload:

 cil (0.07.00-13) unstable; urgency=medium
 .
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
   * Migrate to debhelper-compat 13:
 - Change debhelper (>= 11) to debhelper-compat (= 13) in debian/control.
 - Remove debian/compat.
   * debian/control:
 - Change to new repository URL.
 - Add Rules-Requires-Root: binary-targets.
   * debian/copyright:
 - Add 2023 to myself.
   * debian/watch:
 - Bump to version 4.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1039512: RFS: simple-scan/44.0-1 -- Simple Scanning Utility

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "simple-scan":

   Package name : simple-scan
   Version  : 44.0-1
   Upstream contact : Robert Ancell 
   URL  : https://gitlab.gnome.org/GNOME/simple-scan
   License  : GPL-3+
   Vcs  : https://git.jff.email/cgit/simple-scan.git
   Section  : gnome

The source builds the following binary packages:

  simple-scan - Simple Scanning Utility

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

  https://mentors.debian.net/package/simple-scan/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_44.0-1.dsc

or from 

 git https://git.jff.email/cgit/simple-scan.git/?h=release%2Fdebian%2F44.0-1


Changes since the last upload:

 simple-scan (44.0-1) unstable; urgency=medium
 .
   * New upstream release.
 - Add Build-Depend libjson-glib-dev, libfribidi-dev, gir1.2-rsvg-2.0,
   libgirepository1.0-dev
 - Remove Build-Depend , cmake
   * debian/control:
 - Change to new repository.
 - Switch libgdk-pixbuf2.0-dev to libgdk-pixbuf-2.0-dev (Closes: #1037399).
   * debian/copyright:
 - Refresh for the new release.
 - Add year 2023 to myself.
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  HU6U7Z6H
Wire: @joergfringsfuerst
Skype:jff-skype@jff.email
Ring: jff
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1035475: bullseye-pu: package dkimpy/1.0.5-1

[Scott Kitterman]

On Monday, June 26, 2023 3:26:19 PM EDT Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Wed, May 03, 2023 at 01:44:43PM -0400, Scott Kitterman wrote:
> > This is a new upstream release that we targetted to address bugs that
> > would generally be suitable for Debian post-release updates.
> 
> Please go ahead.

Uploaded.

Thanks,

Scott K

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

Bug#1039511: graphviz: Please install Tcl bindings in /usr/lib/tcltk

[Thomas Uhle]

Source: graphviz
Version: 2.42.2-7
Severity: wishlist

Dear maintainer,

similar to what is done for libgv-perl, could you please install the 
files for the Tcl bindings in /usr/lib/tcltk//gv2.43.0 
instead of /usr/lib//graphviz/tcl because /usr/lib/tcltk 
is the place where Tcl is automatically searching for installed packages 
and so it would not be necessary to set $TCLLIBPATH any longer.
Could you also please consider to rename the package libgv-tcl to tcl-gv 
similar to other Tcl packages in Debian.  You have already done 
something alike for the package python3-gv.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?

[Paul Gevers]

Source: mvtnorm, r-cran-pammtools
Control: found -1 mvtnorm/1.2-2-1
Control: found -1 r-cran-pammtools/0.5.8-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of mvtnorm the autopkgtest of r-cran-pammtools 
fails in testing when that autopkgtest is run with the binary packages 
of mvtnorm from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
mvtnormfrom testing1.2-2-1
r-cran-pammtools   from testing0.5.8-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I note that with both versions from unstable the test also passes, which 
hints at either a missing *versioned* test dependency in 
r-cran-pammtools (if it *only* breaks the test), or missing versioned 
Breaks in mvtnorm *and* a missing versioned Depends in r-cran-pammtools 
if r-cran-pammtools is really broken with the wrong version of mvtnorm.


I copied some of the output at the bottom of this report.

Currently this regression is blocking both the migration of mvtnorm to 
testing [1] and the migration of r-cran-pammtools to testing [2]. Due to 
the nature of this issue, I filed this bug report against both packages. 
Can you please investigate the situation and reassign the bug to the 
right package?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
mvtnorm/1.2-2-1. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=mvtnorm
[2] https://qa.debian.org/excuses.php?package=r-cran-pammtools

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pammtools/34886689/log.gz

 46s BEGIN TEST testthat.R
 46s  46s R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
 46s Copyright (C) 2023 The R Foundation for Statistical Computing
 46s Platform: x86_64-pc-linux-gnu (64-bit)
 46s  46s R is free software and comes with ABSOLUTELY NO WARRANTY.
 46s You are welcome to redistribute it under certain conditions.
 46s Type 'license()' or 'licence()' for distribution details.
 46s  46s R is a collaborative project with many contributors.
 46s Type 'contributors()' for more information and
 46s 'citation()' on how to cite R or R packages in publications.
 46s  46s Type 'demo()' for some demos, 'help()' for on-line help, or
 46s 'help.start()' for an HTML browser interface to help.
 46s Type 'q()' to quit R.
 46s  46s > Sys.setenv("R_TESTS" = "") # see 
https://github.com/hadley/testthat/issues/86

 46s > library(testthat)
 46s > library(checkmate)
 46s > library(dplyr)
 47s  47s Attaching package: ‘dplyr’
 47s  47s The following object is masked from ‘package:testthat’:
 47s  47s matches
 47s  47s The following objects are masked from ‘package:stats’:
 47s  47s filter, lag
 47s  47s The following objects are masked from ‘package:base’:
 47s  47s intersect, setdiff, setequal, union
 47s  47s > library(purrr)
 47s  47s Attaching package: ‘purrr’
 47s  47s The following object is masked from ‘package:testthat’:
 47s  47s is_null
 47s  47s > library(tidyr)
 47s  47s Attaching package: ‘tidyr’
 47s  47s The following object is masked from ‘package:testthat’:
 47s  47s matches
 47s  47s > # library(pammtools)
 47s >  47s > test_check("pammtools")
 47s Loading required package: pammtools
 48s  48s Attaching package: ‘pammtools’
 48s  48s The following object is masked from ‘package:stats’:
 48s  48s filter
 48s  59s [ FAIL 2 | WARN 8 | SKIP 0 | PASS 341 ]
 59s  59s ══ Failed tests 

 59s ── Error ('test-cumulative-effect.R:29'): LL helpers and as_ped 
produce equivalent LL windows ──
 59s Error in `vectbl_assign(x[[j]], i, recycled_value[[j]])`: DLL 
requires the use of native symbols

 59s Backtrace:
 59s  ▆
 59s   1. ├─pammtools::sim_pexp(...) at test-cumulative-effect.R:29:2
 59s   2. │ ├─base::suppressMessages(ped <- ped %>% 
left_join(reduce(df2, full_join)))

 59s   3. │ │ └─base::withCallingHandlers(...)
 59s   4. │ └─ped %>% left_join(reduce(df2, full_join))
 59s   5. ├─dplyr::left_join(., reduce(df2, full_join))
 59s   6. ├─pammtools:::left_join.ped(., reduce(df2, full_join))
 59s   7. │ └─pammtools:::ped_classes(y)
 59s   8. │   └─class(ped) %in% ...
 59s   9. └─purrr::reduce(df2, full_join)
 59s  10.   └─purrr:::reduce_impl(.x, .f, ..., .init = .init, .dir = .dir)
 59s  11. ├─dplyr (local) fn(out, elt, ...)
 59s  12. └─dplyr:::full_join.data.frame(out, elt, ...)
 59s  13.   └─dplyr:::join_mutate(...)
 59s  14. ├─base::`[<-`(`*tmp*`, 

Bug#890505: gnome-software does not support uninstallation of unused dependencies

[asciiwolf]

Enabling the "packagekit_autoremove" gnome-software meson build option should 
be enough to resolve this issue.

Bug#1039509: davmail: autopkgtest regression on ppc64el: Exception in thread "Shutdown"

[Paul Gevers]

Source: davmail
Version: 6.1.0.3423-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of davmail the autopkgtest of davmail fails in 
testing when that autopkgtest is run with the binary packages of davmail 
from unstable on ppc64el. It passes when run with only packages from 
testing. In tabular form:


   passfail
davmailfrom testing6.1.0.3423-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[1] https://qa.debian.org/excuses.php?package=davmail

https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/davmail/34813750/log.gz

 50s 2023-06-24 23:58:02,749 DEBUG [main] davmail.DavGateway  - Start 
DavMail in server mode
 50s 2023-06-24 23:58:02,795 INFO  [main] davmail  - DavMail Gateway 
6.1.0-trunk listening on SMTP port 1025 POP port 1110 IMAP port 1143 
CALDAV port 1080 LDAP port 1389  60s 2023-06-24 23:58:12,566 DEBUG 
[davmail.smtp.SmtpServer] davmail  - Connection from /127.0.0.1 on port 1025
 60s 2023-06-24 23:58:12,569 INFO  [davmail.smtp.SmtpServer] 
davmail.connection  - CONNECT - 127.0.0.1:41156  60s 2023-06-24 
23:58:12,571 DEBUG [Shutdown] davmail  - Stopping DavMail gateway
 60s 2023-06-24 23:58:12,572 INFO  [davmail.smtp.SmtpServer] 
davmail.connection  - DISCONNECT - 127.0.0.1:41156  60s Exception in 
thread "Shutdown" java.lang.IllegalMonitorStateException: current thread 
is not owner
 60s 2023-06-24 23:58:12,579 INFO  [Shutdown] davmail  - DavMail 
gateway stopped

 60sat java.base/java.lang.Object.notifyAll(Native Method)
 60sat davmail.DavGateway$1.run(DavGateway.java:100)
 60s autopkgtest [23:58:12]: test binary-starts



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039508: systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size"

[James L Baker]

Package: systemd-boot
Severity: important

Dear Maintainer,


   * I [fresh-] installed the latest version of Proxmox VE (8.0), which is 
based on Debian 12.
   * First boot after installation resulted in the error "Error preparing 
initrd: Bad Buffer Size" at boot, preventing system from loading.
   * I expected the system to boot normally.

I was asked by the bugzilla folks at Proxmox to report this problem to you, as 
it is an issue with the current systemd-boot package.

(I have omitted reportbug system information, as the reporting system is *not* 
the system on which the issue occurs.)

-- Original report to Proxmox bugzilla:
https://bugzilla.proxmox.com/show_bug.cgi?id=4798

Environment:
- Dell r620 (x2)
- 2x Xeon E5-2620 (each)
- 64GB RAM (each)
- BIOS 2.9.0 (dated 2020-02)
- UEFI boot
- PERC h310 SAS controller (IT mode)
- PVE installed on 2x Dell/Seagate 15k SAS drives in ZFS mirror
- Install media 8.0-2 ISO

The first boot after a new install results in an "Error preparing initrd: Bad 
Buffer Size" error on both mentioned hosts.  Previously, PVE v7.4 installed, 
booted, and ran fine on this hardware - I'd begun migration to Proxmox (v7) for 
virtual hosting last week, but started over once v8 was released.

This Proxmox forum thread mentions the error occurring for others:
https://forum.proxmox.com/threads/error-preparing-initrd-bad-buffer-size.129427/

And this github issue thread identifies the cause as systemd, and reports a 
merged patch which corrects it:
https://github.com/systemd/systemd/issues/25911

Is there any chance to include a more recent version of systemd (the "-boot" or 
"-boot-efi" packages, I assume) with the install media?  Or a recommended way 
to load a newer package version during install, prior to first boot?

A possible workaround is to install 7.4 then immediately upgrade to 8; I have 
not yet attempted this.

More context:
https://github.com/NixOS/nixpkgs/issues/227431#issuecomment-1556474041

-- End original report

Obviously, the report text is specific to Proxmox, but the issue lies with the 
current implemenation of systemd-boot.
Please consider implementing the patch at 
https://github.com/systemd/systemd/commit/f70f992273a7add1ec98a894ffadb1f1e43c0c31

Thank you.

Bug#1035046: bullseye-pu: package lacme/0.8.0-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Apr 28, 2023 at 10:58:04AM +0200, Guilhem Moulin wrote:
> The ACME specification (RFC 8555 sec. 7.1.6) clearly reads that state
> transition for Order Objects follows (‘pending’ →) ‘ready’ →
> ‘processing’ → ‘valid’, but lacme 0.8.0-2 fails to handle the transition
> via ‘processing’ state.
> https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039040: bullseye-pu: cups/2.3.3op2-3+deb11u3

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Jun 24, 2023 at 09:40:34PM +, Thorsten Alteholz wrote:
> The attached debdiff for cups fixes CVE-2023-32324 and CVE-2023-34241 in
> Bullseye. Both CVE have been marked as no-dsa by the security team.
> 
> The same fixes have been already uploaded to Unstable and nobody complained
> yet.
> 

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039507: ITP: node-pac-proxy-agent -- PAC file proxy `http.Agent` implementation for HTTP and HTTPS

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-pac-proxy-agent
  Version : 5.0.0
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/node-pac-proxy-agent
* License : Expat
  Programming Lang: JavaScript
  Description : PAC file proxy `http.Agent` implementation for HTTP 
and HTTPS


This module provides an http.Agent implementation that retreives the
specified PAC proxy file and uses it to resolve which HTTP, HTTPS, or SOCKS
proxy, or if a direct connection should be used to connect to the HTTP
endpoint. It is designed to be be used with the built-in http and https
modules.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037188: bullseye-pu: package git/2.30.2-1+deb11u3

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Jun 07, 2023 at 01:22:25PM +0200, Andreas Beckmann wrote:
> [ Reason ]
> git-el in bullseye is uninstallable in any sensible combination with
> emacs/xemacs (it only installs fine in a minimal chroot w/o
> --install-recommends).
> The package was dropped from sid shortly after the bullseye release,
> let's to the same in bullseye.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039506: mini-buildd: reproducible builds: embeds hostname in manpages and documentation

[Vagrant Cascadian]

Source: mini-buildd
Version: 2.0.0
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The hostname is embedded in mini-buildd.8 manpage and mini-buildd.html:

  
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/mini-buildd.html

  /usr/share/doc/mini-buildd/html/_static/man/mini-buildd.html

  
Public·(fully·qualified)·hostname·used·for·all·services.·(default:·ionos11-amd64.debian.net)
  vs.
  
Public·(fully·qualified)·hostname·used·for·all·services.·(default:·i-capture-the-hostname)

The attached patch fixes this by not setting a default for --hostname in
the help output.

I have not tested that this has no unintended side-effects, only that it
builds reproducibly; maybe there is a better way to fix this issue.


This seems somewhat similar to the issue with build paths that was fixed
in 2.1.0 in experimental:

  
https://salsa.debian.org/debian/mini-buildd/-/commit/ff52b7aa1f6b7371b21a4beae822e6dae1fb37f2


According to my local tests, With this patch applied mini-buildd should
build reproducibly on tests.reproducible-builds.org! (presuming the
buildpath patch from experimental is also applied to unstable)


Thanks for maintaining mini-buildd!


live well,
  vagrant
From e0dc5984b7fd5c8f0e6fc608ec210dffa81e1232 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 26 Jun 2023 12:10:11 -0700
Subject: [PATCH] src/mini-buildd: Do not set default value for --hostname.

The build machine hostname ends up getting embedded in documentation
and manpages.
---
 src/mini-buildd | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mini-buildd b/src/mini-buildd
index c6092b5a..bc318499 100755
--- a/src/mini-buildd
+++ b/src/mini-buildd
@@ -62,7 +62,6 @@ class CLI(cli.CLI):
 
 group_conf.add_argument("-N", "--hostname",
 action="store",
-default=config.HOSTNAME_FQDN,
 help="Public (fully qualified) hostname used for all services.")
 
 group_conf.add_argument("-E", "--http-endpoint", action="store", nargs="+",
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

[Richard Laager]

I'm not sure if you saw this, as he didn't send it directly to you, but 
Matt Selsky asked:


> Can you please share your ntp.conf or if there's a particular server
> that seems to cause this segfault so that we can try to reproduce it?

Also, can you get a stack trace? There are some instructions in the 
Debian wiki:

https://wiki.debian.org/HowToGetABacktrace

--
Richard

Bug#1035475: bullseye-pu: package dkimpy/1.0.5-1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, May 03, 2023 at 01:44:43PM -0400, Scott Kitterman wrote:
> This is a new upstream release that we targetted to address bugs that
> would generally be suitable for Debian post-release updates.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2023-06-26 20:20:47)
> If I may share my thoughts (daydreams?!?) about this issue, I was hoping to
> see a (relatively) simple command able to create a QEMU/KVM image for
> autopkgtest without requiring superuser privileges. An image that could be
> easily upgraded after creation (without the need to re-create it from
> scratch). Bonus, if the image can then be used also for interactive testing
> of packages and for package building.
> 
> Basically, I was hoping to see [sbuild-qemu-create] drop the requirement
> of superuser privileges (thus dropping the behind-the-scenes use of
> vmdb2 and switching to some other backend)...
> 
> [sbuild-qemu-create]: 
> 
> I am not sure I clearly understand whether this may happen or whether
> this is actually going to happen soon...

this is not a daydream and I think we have nearly all building blocks in place
to make all of this happen very soon! Here is a summary:

 1. You use `debvm-create --arch $foo` to create a filesystem image for any
architecture supported by QEMU without superuser privileges. The
debvm-create utility is a thin wrapper around mmdebstrap and passes all the
right arguments to create this filesystem image.

 2. You use either autopkgtest-virt-qemu or autopkgtest-virt-ssh (depending on
whether Simon prefers merge request !236 or !237) to run your autopkgtest
through qemu with that disk image

 3. ???

 4. Profit!

If you want to upgrade the disk image you can do so by using `debvm-run` which
gives you a root shell for that disk image where you can just run "apt
upgrade".

Now lets get to your "bonus". Once either MR !236 or !237 is accepted I will
rewrite sbuild-qemu-create to not call autopkgtest-build-qemu (which uses vmdb2
which requires root) but debvm-create instead. Similarly, the sbuild-qemu
script will be adapted to call sbuild with the autopkgtest backend and the
right option (again depending on whether MR !236 or !237 get merged). And the
sbuild-qemu-update tool will automate the updating so that you don't have to
run debvm-run yourself.

Of course once either MR !236 or !237 get merged, you do not have to wait for
me to change sbuild-qemu. Even before I have done this work you can always
manually call sbuild with the autopkgtest backend and do your package builds in
the QEMU image created by debvm-create without superuser privileges.

So I don't think it's a daydream. Two merge requests exist that provide the
necessary functionality for debvm support and we hopefully only have to go
through a few more iterations with Simon to get either of them into a state
where they can get merged (or in case of !237, shipped by debvm itself).

So stay tuned! :D

cheers, josch

signature.asc
Description: signature

Bug#1039505: freedroidrpg: Please remove external/lua

[Bastien Roucariès]

Source: freedroidrpg
Version: 1.0-1 
Severity: important

Dear Maintainer, Cher julien

Could you repack and remove the external lua (+ds suffix) ?

It is best pratice to remove code embed old version of packaged software.

Bastien



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

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

Bug#1039490: lldb-16: lldb should not depend on llvm-dev

[Sylvestre Ledru]

Hello



Dear Maintainer,

lldb pulls in alot development headers, static libraries which it should
noot require during runtime.
I believe this is a simple mistake, but if not then the dependent stuff should
be partitioned out from the huge llvm-dev package.


Thanks. I wonder if I had a reason for doing it or not :p

Cheers
S

Bug#1030953: fixed in pipewire 0.3.72-1

[Thomas Uhle]

Hello Dylan,

thank you for renaming pipewire-libcamera to libspa-0.2-libcamera!

Best regards,

Thomas Uhle

Bug#1039500: menu: reproducible builds: embeds timestamp in menu.info.gz

[Bill Allombert]

On Mon, Jun 26, 2023 at 11:05:11AM -0700, Vagrant Cascadian wrote:
> Source: menu
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> The timestamp is embedded in the gzip headers of menu.info.gz:
> 
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/menu.html
> 
>   /usr/share/info/menu.info.gz
> 
>   
> gzip·compressed·data,·was·"menu.info",·last·modified:·Mon·Jun·26·13:22:38·2023,·max·compression,·from·Unix
>   vs.
>   
> gzip·compressed·data,·was·"menu.info",·last·modified:·Sun·Jul·28·19:49:45·2024,·max·compression,·from·Unix
> 
> The attached patch to debian/rules works around this by uncompressing
> the menu.info.gz and letting dh_compress handle the compression.
> 
> A better solution might be to fix this upstream, by using "gzip
> --no-name". It looks like doc/Makefile.* would be the place, but I had
> no luck adding it to the gzip calls there.

You need to rerun automake.

But the actual bug is that the Makefile remove menu.info, which causes it to be
regenerated with a different timestamp, which was not intended. 

Also if you know how to fix the C++ warning, tell me.

hints.h: In constructor 'hints::hints()':
hints.h:72:9: warning: member 'hints::hint_nentry' is used uninitialized 
[-Wuninitialized]
   72 | hint_nentry), hint_nentry(6), hint_topnentry(6), max_ntry(5),
  | ^~~

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1037980: transmission-daemon: memory leaks

[Pavel Kreuzt]

If this helps, I tried building Debian src package for my own system
applying the Gentoo patch proposed on #1015003 instead of the Debian pkg
openssl patch. Memory usage remains stable after several hours and didn't
notice side effects for the moment, but didn't test the program deeply.

Bug#1039301: openrc: ships sysv-init script without systemd unit

[Mark Hindley]

Control: tags -1 invalid

Luca,

On Sun, Jun 25, 2023 at 11:26:01PM +0100, bl...@debian.org wrote:
> Package: openrc
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service

I am afraid I can see no possible use case where anybody would run openrc under
systemd. Do you have one?

Mark

Bug#1039504: kde-plasma-desktop: Monitor fails to sleep

[Velent]

Subject: kde-plasma-desktop: Monitor fails to sleep
Package: kde-plasma-desktop
Version: 5:142
Severity: normal
X-Debbugs-Cc: vele...@proton.me

Dear Maintainer,
I have a problem with KDE screen timeout sleep feature.
When timeout exceeds and monitor should switch off into sleep mode, it
instantly wakes up.
It happens on both Wayland and X11.
I am using the AMD RX 6500 XT with amdgpu driver, monitor connected into a HDMI
port.
In similar threads on KDE bug tracker
(https://bugs.kde.org/show_bug.cgi?id=379474) there were a suggestions that
turning off kscreen background service should fix this, but in my case it
didn't work.

Here's logs of moment when display should turn off, but waes up:
Wayland
Jun 23 04:57:36 kernel: amdgpu :2d:00.0: [drm] User-defined mode not
supported: "2560x1440": 75 296000 2560 2568 2600 2666 1440 1443 1448 1481 0x60
0x9
Jun 23 04:57:36 polkit-kde-authentication-agent-1[1919]: qt.qpa.wayland:
Creating a fake screen in order for Qt not to crash
Jun 23 04:57:36 kactivitymanagerd[1859]: qt.qpa.wayland: Creating a fake screen
in order for Qt not to crash
Jun 23 04:57:36 DiscoverNotifier[2190]: qt.qpa.wayland: Creating a fake screen
in order for Qt not to crash
Jun 23 04:57:36 baloorunner[3184]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 plasmashell[2642]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 org.kde.kwalletd5[2366]: qt.qpa.wayland: Creating a fake screen
in order for Qt not to crash
Jun 23 04:57:36 org.kde.kdeconnect[2147]: qt.qpa.wayland: Creating a fake
screen in order for Qt not to crash
Jun 23 04:57:36 xdg-desktop-portal-kde[2297]: qt.qpa.wayland: Creating a fake
screen in order for Qt not to crash
Jun 23 04:57:36 plasmashell[3242]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 plasmashell[3878]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 plasmashell[3924]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 org_kde_powerdevil[1920]: qt.qpa.wayland: Creating a fake
screen in order for Qt not to crash
Jun 23 04:57:36 kded5[1839]: qt.qpa.wayland: Creating a fake screen in order
for Qt not to crash
Jun 23 04:57:36 dbus-daemon[1707]: [session uid=1000 pid=1707] Activating via
systemd: service name='org.kde.kscreen.osdService' unit='plasma-kscreen-
osd.service' requested by ':1.17' (uid=1000 pid=1839 comm="/usr/bin/kded5")
Jun 23 04:57:36 org_kde_powerdevil[4401]: qt.qpa.wayland: Creating a fake
screen in order for Qt not to crash
Jun 23 04:57:36 kded5[4403]: qt.qpa.wayland: Creating a fake screen in order
for Qt not to crash
Jun 23 04:57:36 org_kde_powerdevil[4402]: qt.qpa.wayland: Creating a fake
screen in order for Qt not to crash
Jun 23 04:57:36 kded5[4412]: qt.qpa.wayland: Creating a fake screen in order
for Qt not to crash
Jun 23 04:57:36 org_kde_powerdevil[4401]: Initializing "/usr/lib/x86_64-linux-
gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
Jun 23 04:57:36 kded5[4412]: Initializing "/usr/lib/x86_64-linux-
gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
Jun 23 04:57:36 org_kde_powerdevil[4402]: Initializing "/usr/lib/x86_64-linux-
gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
Jun 23 04:57:36 kded5[4403]: Initializing "/usr/lib/x86_64-linux-
gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
Jun 23 04:57:36 systemd[1687]: Starting plasma-kscreen-osd.service - KScreen
OSD service...
Jun 23 04:57:36 dbus-daemon[1707]: [session uid=1000 pid=1707] Successfully
activated service 'org.kde.kscreen.osdService'
Jun 23 04:57:36 systemd[1687]: Started plasma-kscreen-osd.service - KScreen OSD
service.
Jun 23 04:57:36 plasmashell[1860]: qt.qpa.wayland: Creating a fake screen in
order for Qt not to crash
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml:387:21:
Unable to assign [undefined] to bool
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml:500:25:
Unable to assign [undefined] to bool
Jun 23 04:57:36 plasmashell[1860]: qt.qpa.wayland: Wayland does not support
QWindow::requestActivate()
Jun 23 04:57:36 plasmashell[1860]: qt.qpa.wayland: Wayland does not support
QWindow::requestActivate()
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml:20:
TypeError: Cannot read property 'pluginName' of null
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml:75:
TypeError: Cannot read property 'configuration' of null
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml:78:
TypeError: Cannot read property 'pluginName' of null
Jun 23 04:57:36 plasmashell[1860]:
file:///usr/share/plasma/wallpapers/org.kde.image/contents/ui/main.qml:80:
TypeError: 

Bug#1039503: wrongly splits up extended grapheme clusters (like certain emoji)

[Steinar H. Gunderson]

Package: screen
Version: 4.9.0-4
Severity: normal
Tags: upstream

Hi,

I was trying to figure out why irssi sometimes garbles the display when certain
emoji are involved in the channel topic; after some debugging, it seems the 
issue
is with screen, not irssi. To reproduce, start up screen and do (in a shell)

  echo '\0360\0237\0217\0263\0357\0270\0217\0342\0200\0215\0360\0237\0214\0210'

(That is UTF-8 for U+1F3F3 U+FE0F U+200D U+1F308.)

Outside of screen, I correctly get ️‍, , RAINBOW FLAG. However, inside
screen, I get ️, space,  (WHITE FLAG, space, RAINBOW). Curiously enough,
if I switch windows and get an irssi redraw, it actually gets drawn correctly,
but that's probably something more complex.

I've tried following the code, and this is my understanding of what's going on:
screen really wants one cell = one codepoint, yet it needs to support combining
characters. So internally, it seems to keep a sort of cache of combining 
sequences,
using the otherwise-reserved-for-surrogates range U+D800..U+DFFF.

This seems to happen in two steps; utf8_handle_comb() (in encoding.c) adds more
code points to a given sequence, allocating points and keeping a linked list.
(There's some confusion in that the “font” member of struct mchar is used to
hold the upper 8 bits of the resulting surrogate, but I think that's just some
sort of hack because the “image” member is 8-bit only? And there's something
about double-wide characters that I don't fully understand.) Then, at display
time, ToUtf8_comb() follows this linked list back to output the entire sequence.

The screen debug log appears to go through this (I've kept only what I think
are relevant messages):

  read UNICODE 1f3f3
  read UNICODE fe0f
  combinig char 1f3f3 fe0f -> d800
  bring to front: 0
  GotoPos (1,1) -> (0,1)
  ---LGotoPos 1 1
  read UNICODE 200d
  combinig char d800 200d -> d801
  bring to front: 1
  bring to front: 0
  GotoPos (1,1) -> (0,1)
  ---LGotoPos 1 1
  read UNICODE 1f308
  ---LGotoPos 0 1

Seemingly, it understands that the two first codepoints are to be combined,
allocates U+D800 for that, and then continues reading. Then it reads
the third one, combines it with U+D800 to create U+D801, but then mistakenly
does _not_ combine U+1F308 with it. This is why we end up with two different
things on screen.

It really seems to me that screen simply doesn't understand Unicode extended
grapheme clusters, only the legacy “legacy grapheme clusters”; from UAX#29
(https://unicode.org/reports/tr29/):

  A legacy grapheme cluster is defined as a base (such as A or カ) followed by
  zero or more continuing characters. One way to think of this is as a sequence
  of characters that form a “stack”.

This seems to come from ansi.c line 705 (WriteString()):

  if (curr->w_encoding == UTF8 && c >= 0x0300 && utf8_iscomb(c))
   {
 […]
 utf8_handle_comb(c, );

In other words, it thinks certain code points are inherently combining
and thus are to be attached to the previous character. However, that's
changed since Unicode 5.1.0, circa 2008; now all of these four together
should form an extended grapheme cluster.

The rules for extended grapheme clusters are locale-dependent, but I'd
guess screen would do just fine with the default grapheme clusters
(certainly much better than today). The rules are actually pretty simple,
if a tad verbose:

https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundary_Rules

In particular, I would believe what we need here is rule GB11,
“Do not break within emoji modifier sequences or emoji zwj sequences.”:

  \p{Extended_Pictographic} Extend* ZWJ × \p{Extended_Pictographic}

where “×” means “don't break here”, i.e., continue to run
utf8_handle_comb(). Specifically, the rule matches because:

  U+1F3F3 WAVING WHITE FLAG is indeed Extended_Pictographic
  (according to 
https://unicode.org/Public/15.0.0/ucd/emoji/emoji-data.txt)
  U+FE0F  VARIATION SELECTOR-16 is Extend, because it is Grapheme_Extend
  (according to 
https://unicode.org/Public/15.0.0/ucd/DerivedCoreProperties.txt)
  U+200D  ZERO-WIDTH JOINER is, well, ZWJ
  U+1F308 RAINBOW is also Extended_Pictographic (same file)

Is it possible to retrofit these rules? This specific rule would seem to
hit a lot of modern emoji sequences (the Unicode Consortium seems to prefer
using such sequences instead of defining new code points where possible);
I would assume including the full table of grapheme clusters would help
e.g. Korean text, too, although I cannot read Korean and have no idea
whether it's actually a problem.

As a hack, it seems that anything that follows a ZWJ would be very likely
to keep being part of the same grapheme cluster, but I haven't tested this
out in practice.

FWIW, tmux seems to have no problems showing the flag, although I haven't
checked its implementation.

-- Package-specific info:
File Existence and Permissions
--

drwxr-xr-x 34 root root   1140 Jun 26 17:15 /run
lrwxrwxrwx  1 root root  4 

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Mon, 26 Jun 2023 08:33:09 +0200 Johannes Schauer Marin Rodrigues wrote:

> Francesco, you initially reported this issue. Do you share my conclusion that
> debvm solves the problem you raised about creating autopktest disk images
> without superuser privileges?
> 
> Thanks!

Hi Johannes,
thanks for following up on this bug report!

I really appreciate all the investigation and development work done by
you and others, but I must confess that I somewhat lost track of all
the details.:-p

If I may share my thoughts (daydreams?!?) about this issue, I was hoping
to see a (relatively) simple command able to create a QEMU/KVM image
for autopkgtest without requiring superuser privileges. An image
that could be easily upgraded after creation (without the need to
re-create it from scratch). Bonus, if the image can then be used
also for interactive testing of packages and for package building.

Basically, I was hoping to see [sbuild-qemu-create] drop the requirement
of superuser privileges (thus dropping the behind-the-scenes use of
vmdb2 and switching to some other backend)...

[sbuild-qemu-create]: 

I am not sure I clearly understand whether this may happen or whether
this is actually going to happen soon...



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp6NOd08LU3d.pgp
Description: PGP signature

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

[Francesco P. Lovergine]

On Mon, Jun 26, 2023 at 07:28:36PM +0200, Francesco P. Lovergine wrote:


Updated debdiff attached.



Sorry wrong diff, this is the correct one :-/

--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Now do not enable proftpd.socket to avoid conflicts at boot time.
+(Closes: #1038416)
+  * Introduced a new prerm script to manage stop of service/socket before
+remove.
+  * Added an entry to NEWS file to explain the change in unit files
+and how to deal with changes.
+  * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine   Thu, 22 Jun 2023 11:15:57 +0200
+
 proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
 
   * Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS	2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,16 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note
+that you will need to
+systemctl disable --now proftpd.socket
+systemctl enable --now proftpd.service
+after upgrade, if you run the proftpd in (default) standalone mode and you did not
+do that before. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416
+for more information. For other information about inetd/standalone switching
+see also the relevant section in /usr/share/doc/proftpd-core/README.Debian.gz. 
+
+ -- Francesco Paolo Lovergine   Wed, 21 Jun 2023 15:21:32 +0200
+
 proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
 
 The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm	2023-06-22 11:15:57.0 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian	2023-06-22 11:15:57.0 +0200
@@ -104,8 +104,7 @@
 
 That could be done by running 
 
-	service proftpd stop
-	systemctl disable proftpd.service
+	systemctl disable --now proftpd.service
 
 then changing from 'standalone' to 'inetd' the ServerType entry in
 /etc/proftpd/proftpd.conf, and: 
@@ -131,10 +130,7 @@
 
   - or using systemd support for socket. To do that run:
 
-	systemctl stop proftpd.service
-	systemctl disable proftpd.service
-	systemctl enable proftpd.socket
-	systemctl start proftpd.socket
+	systemctl enable --now proftpd.socket
 
 ** Other information
 
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/rules proftpd-dfsg-1.3.8+dfsg/debian/rules
--- proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/rules	2023-06-22 11:15:57.0 +0200
@@ -93,7 +93,7 @@
 	dh_installinit --name=$(NAME)
 
 override_dh_installsystemd:
-	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).socket
+	dh_installsystemd -p$(PACKAGE) --no-enable --no-start --name=$(NAME) $(NAME).socket
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME)@ $(NAME)@.service
 	dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).service
 

Bug#1039301: openrc: ships sysv-init script without systemd unit

[Luca Boccassi]

Control: close -1

On Mon, 26 Jun 2023 at 19:13, Mark Hindley  wrote:
>
> Control: tags -1 invalid
>
> Luca,
>
> On Sun, Jun 25, 2023 at 11:26:01PM +0100, bl...@debian.org wrote:
> > Package: openrc
> > Severity: important
> > User: bl...@debian.org
> > Usertags: missing-systemd-service
>
> I am afraid I can see no possible use case where anybody would run openrc 
> under
> systemd. Do you have one?

Eheh certainly not, I took out elogind of the list of packages marked
by lintian.org via the missing-systemd-service-for-init.d-script tag,
but forgot to take out this one. If not done already, would be good to
add an override for that tag in the package.

Kind regards,
Luca Boccassi

Bug#1039502: python3-nose2: missing dependency on python3-coverage

[Thomas Uhle]

Package: python3-nose2
Version: 0.12.0-1
Severity: normal

Dear maintainers,

after the upgrade from bullseye to bookworm, python3-nose2 no longer 
depends on python3-coverage, but the included nose2/plugins/coverage.py 
still depends on it.
Could you please consider to either let python3-nose2 depend again on 
python3-coverage or to add this dependency to Recommends at least.


Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.1.0-9-arm64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-nose2 depends on:
ii  python33.11.2-1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-six1.16.0-4

python3-nose2 recommends no packages.

Versions of packages python3-nose2 suggests:
pn  python-nose2-doc  

-- no debconf information