Bug#1051949: ITS: binfmtc

[Junichi Uekawa]

On Fri, 15 Sep 2023 03:02:15 +0900,
Bastian Germann wrote:
> 
> Source: binfmtc
> 
> binfmtc does not seem to be maintained anymore.
> I intend to salvage the package with the plan to orphan it in three weeks.
> Please notify me if you object.
> 

What does ITS stand for ?

Bug#1051971: owncloud-client-cmd: Error transfering https://BLAH/owncloud/remote.php/webdav/status.php - server replied: Forbidden

[Sergio Mendoza]

I can confirm that this new version works ok.  So, the bug can now
be closed.  Thanks for fixing things quickly!

Cheers,

Sergio.




On Wed, Sep 27, 2023 at 12:33:06PM +0200, Agustin Martin wrote:
> On Tue, Sep 26, 2023 at 10:11:12AM -0600, Sergio Mendoza wrote:
> > On Mon, Sep 25, 2023 at 03:40:42PM +0200, Agustin Martin wrote:
> > > On Mon, Sep 25, 2023 at 03:16:46PM +0200, Agustin Martin wrote:
> > > > On Thu, Sep 14, 2023 at 09:07:38PM -0600, Sergio Mendoza wrote:
> > > > > Package: owncloud-client-cmd
> > > > > Version: 3.2.0.10193+dfsg-1
> > > > > Severity: important
> > > > > 
> > > > > Dear mainteiner,
> > > > > 
> > > > >   With the new unstable version ( 3.2.0.10193+dfsg-1 ) of owncloudcmd,
> > > > > when I try to sync with the onwcloud server I get the following error:
> > > > > 
> > > > > 23-09-14 20:45:05:955 [ warning sync.checkserverjob ]:  error: 
> > > > > status.php replied 403
> > > > > 23-09-14 20:45:05:955 [ fatal default ]:Failed to resolve
> > > > > https://BLAH/owncloud/remote.php/webdav Error: Error transferring 
> > > > > https://BLAH/owncloud/remote.php/webdav/status.php - server replied: 
> > > > > Forbidden.
> > > > > Aborted
> > > > 
> > > > Hi,
> > > > 
> > > > For the records, that version has been working in my sid box until last
> > > > Thursday, where, after server upgrade from 10.12.1.3 to 10.13.1.3, this
> > > > error started to appear
> > 
> >   Yes.  I upgraded the server to version 10.13.1.3 but that was after
> > owncloud-client failed.  In any case what I did was to use rclone for
> > syncing.  It is slower, but does the job with the experimental bisync
> > option it provides.  No idea if I would ever go back to owncloud-client
> > since over the years I have had a few problems that are not easily solved.
> 
> Hi,
> 
> owncloud-client 4.2.0.11670+dfsg-1 has been uploaded to sid (thanks a lot,
> Pierre-Elliott).
> 
> I confirm that it fixes my problem with 3.2.0.10193+dfsg-1 and owncloud-client
> is working again in all my boxes against the common 10.13.1.3, server. For the
> records, I previously built a personal package with owncloud-client
> 3.2.1.10355 and it worked too. 
> 
> I think it would be interesting to know if 4.2.0.11670+dfsg-1 also fixes your
> problem and this bug report.
> 
> Regards,
> 
> -- 
> Agustin

Bug#1052973: octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1

[Rafael Laboissière]

Control: reassign -1 octave-dev 8.3.0-1
Control: affects -1 octave-image
Control: notfound -1 octave-image/2.14.0-4
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?64725

* Rafael Laboissière  [2023-09-26 22:00]:


Control: tags -1 + confirmed upstream

* Lucas Nussbaum  [2023-09-26 15:46]:


 Source: octave-image
 Version: 2.14.0-4
 Severity: serious
 Justification: FTBFS
 Tags: trixie sid ftbfs
 User: lu...@debian.org
 Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to 
build on amd64.



Relevant part (hopefully):


 Summary: 2073 tests, 1744 passed, 36 known failures, 0 skipped
 Some tests failed.  Giving up...
 make: *** [debian/rules:12: binary] Error 1


I think that this problem is triggered by a changing in behavior of 
the mkoctfile program, in the way it process its arguments, between 
versions 8.2 and 8.3 of Octave. I will try to get to this, as time 
permits.


As I suspected, this bug is related to Bug#1050082 and is caused by a 
misbehavior of mkoctfile, a tool used to build the *.oct files needed by 
Octave, when options -f* are given to it.


I have already filed a bug report upstream and I am hereby reassigning 
the present bug report to the octave-dev package.


Best,

Rafael Laboissière

Bug#1053089: lxdm.conf information

[陳昌倬]

control: tags -1 + unreproducible


I cannot reprocedure the issue on my machine. Need to find a way to
reprocedure it.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1053084: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053083: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053012: outdated

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053067: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053054: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053052: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053049: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053042: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053030: outdated report

[Vladimir Petko]

The report is outdated and the issue can not be reproduced with ant 1.10.14-1.

Bug#1053053: libjamon-java: FTBFS with default Java 21

[Emmanuel Bourg]

Control: notfound -1 2.7-8
Control: close -1

Le 27/09/2023 à 00:09, Vladimir Petko a écrit :


compile:
 [mkdir] Created dir: /<>/target/classes
 [javac] /<>/debian/build.xml:7: warning: 'includeantruntime' 
was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
 [javac] Compiling 94 source files to /<>/target/classes
 [javac] error: release version 7 not supported
 [javac] Usage: javac  
 [javac] use --help for a list of possible options


This no longer occurs with ant/1.10.14-1.

Emmanuel Bourg

Bug#1053187: linux: Enable Intel's Topology Aware Register and PM Capsule Interface (TPMI)

[Jair Gonzalez]

Source: linux
Version: 6.5.3-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: jair.gonza...@linux.intel.com,
miguel.bernal.ma...@linux.intel.com

Dear Maintainer,

Please enable the Intel's Topology Aware Register and PM Capsule
Interface (INTEL_TPMI) and support for the Running Average Power
Limit (RAPL) feature via TPMI (INTEL_RAPL_TPMI) on arch amd64/x86_64,
on Debian Trixie. 

TPMI is a flexible, extendable and software-driver-enumerable MMIO
interface for Power Management (PM) features. TPMI, planned for future
Intel® Xeon® processor generations, is designed using an architectural
PCI-e standards-based model so that PM feature support can be provided
cleanly as a driver and not as part of the base OS.

Intel RAPL is one of the features that benefits from this. Using the
TPMI interface has the advantage over the traditional MSR (Model
Specific Register) interface of not requiring scheduling a thread on
the target CPU to read or write. Also, TPMI provides an architectural
interface by supplying hierarchical tables and fields, which will not
need any model specific implementation.

In addition to RAPL, there are two other features that receive similar
benefits and which are selected by default by enabling INTEL_TPMI.
They are INTEL_UNCORE_FREQ_CONTROL_TPMI and INTEL_SPEED_SELECT_TPMI.

A MR was created with this proposal at:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/863

Thanks,
Jair Gonzalez

Bug#1053065: nekohtml: FTBFS with default Java 21

[Emmanuel Bourg]

Control: notfound -1 1.9.22.noko2-0.1

Le 27/09/2023 à 00:13, Vladimir Petko a écrit :


compile:
 [mkdir] Created dir: /<>/build/classes
  [echo] Compiling with Xerces-2.12.2
 [javac] Compiling 31 source files to /<>/build/classes
 [javac] warning: [options] bootstrap class path not set in conjunction 
with -source 7
 [javac] error: Source option 7 is no longer supported. Use 8 or later.
 [javac] error: Target option 7 is no longer supported. Use 8 or later.



This no longer occurs with ant/1.10.14-1.

Emmanuel Bourg

Bug#1053033: jmol: FTBFS with default Java 21

[Emmanuel Bourg]

On Wed, 27 Sep 2023 11:03:16 +1300 Vladimir Petko  wrote:


classes:
[mkdir] Created dir: /<>/build/classes
[javac] Compiling 1117 source files to /<>/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 7
[javac] error: Source option 7 is no longer supported. Use 8 or later.
[javac] error: Target option 7 is no longer supported. Use 8 or later.


This error no longer occurs with ant/1.10.14-1, but there is another
error caused by the addLast() method in the Lst class conflicting
with the newly introduced List.addLast() method. Changing the return
type of this method should fix the issue.


[javac] /home/ebourg/packaging/jmol/src/javajs/util/Lst.java:50: error: 
addLast(V) in Lst cannot implement addLast(E) in List
[javac]   public boolean addLast(V v) {
[javac]  ^
[javac]   return type boolean is not compatible with void
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in interface List
[javac] /home/ebourg/packaging/jmol/src/javajs/img/GifEncoder.java:239: error: methods 
addLast(V) from Lst and addLast(E) from ArrayList are inherited with 
the same signature
[javac]   private class ColorCell extends Lst {
[javac]   ^
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in class ArrayList
[javac] /home/ebourg/packaging/jmol/src/jspecview/common/MeasurementData.java:38: 
error: methods addLast(V) from Lst and addLast(E) from 
ArrayList are inherited with the same signature
[javac] public class MeasurementData extends Lst implements
[javac]^
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in class ArrayList
[javac] 
/home/ebourg/packaging/jmol/src/jspecview/common/IntegralData.java:26: error: 
addLast(V) in Lst cannot implement addLast(E) in List
[javac] public class IntegralData extends MeasurementData {
[javac]^
[javac]   return type boolean is not compatible with void
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in interface List
[javac] /home/ebourg/packaging/jmol/src/jspecview/common/PeakData.java:17: 
error: addLast(V) in Lst cannot implement addLast(E) in List
[javac] public class PeakData extends MeasurementData {
[javac]^
[javac]   return type boolean is not compatible with void
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in interface List
[javac] /home/ebourg/packaging/jmol/src/org/jmol/smiles/SmilesRingSet.java:37: error: 
methods addLast(V) from Lst and addLast(E) from 
ArrayList are inherited with the same signature
[javac] class SmilesRingSet extends Lst {
[javac] ^
[javac]   where V,E are type-variables:
[javac] V extends Object declared in class Lst
[javac] E extends Object declared in class ArrayList

Bug#1053060: maven-repo-helper: FTBFS with default Java 21

[Emmanuel Bourg]

Control: notfound -1 1.11

Le 27/09/2023 à 00:11, Vladimir Petko a écrit :


---
compile:
 [mkdir] Created dir: /<>/build/generated-sources
 [javac] /<>/debian/build.xml:45: warning: 'includeantruntime' 
was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
 [javac] Compiling 27 source files to /<>/build/classes
 [javac] error: Source option 7 is no longer supported. Use 8 or later.
 [javac] error: Target option 7 is no longer supported. Use 8 or later.


This no longer occurs with ant/1.10.14-1

Emmanuel Bourg

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi Julien,

thank you for your quick reply!

Quoting Julien Cristau (2023-09-28 17:49:51)
> I guess more than mixing two different things I disagree that that is
> debootstrap's responsibility, and so I disagree that that is a valid bug.  In
> my view it's more important for debootstrap to reliably be able to create
> chroots than some sort of philosophical purity about what is included in said
> chroot.  Package priorities are how the archive tells debootstrap which
> packages to install, and so since I don't see your (A) as a bug, I'm saying
> if there's a bug it's (B) and belongs with the archive.

I agree that debootstrap's reliability to create chroots is supremely
important. But do you see a bug with my change that makes it unreliable? It
changes what the chroot includes yes, but it does so in a reliable way unless I
missed something?

I also agree that "philosophical purity" is a bad argument but "package
priorities are how the archive tells debootstrap which packages to install" is
also not a practical argument but an argument of "we've always done it this way
and that's why we will continue to do it that way". This sounds to me like
another argument of "philosophical purity" instead of one motivated by
practical considerations.

So I'd like to take a step back. There was a big thread on d-devel about this
topic and arguments have been exchanged about this forth and back. I'd like to
use this email to rephrase the argument I have already made for this change.

> I also think your argument, even if I went along with it, breaks down when
> the apt package gets included, since apt is clearly not build-essential, so
> by that logic we'd go back to the days where builds used the host system's
> apt instead of including it in the chroot.

If my argument was of "philosophical purity" then it would indeed completely
break down with making apt the exception. But I'm trying to fix a practical
problem here and thus I'm fine with leaving apt the exception for now. Whether
or not to use apt from the outside would be another discussion we could have
but I do not think it is very useful to have the discussion today. The
practical side of the matter is, that the default schroot backend of sbuild is
unable to use apt from the outside and unless official buildds switch to the
unshare backend, apt has to be included in the chroot.

What this change is trying to achieve is to make it harder for source packages
to make it into the archive that have build dependencies missing. This is my
main motivation. This is also why having apt inside the chroot is not much of a
problem because I cannot remember having seen a source package in the archive
that needed apt to build but was missing it in its Build-Depends.

Source packages with missing build dependencies make QA work on the archive
harder. Santiago is not the only one who found these bugs, Helmut filed bugs
for missing B-D on tzdata and obviously I ran into the problem myself where I
wanted to build a source package but it failed to build because it did not
declare the B-D it actually needed. The time we spend on stumbling over these
bugs, filing them and waiting for them to be fixed could be spent doing more
useful things. We would not have these bugs if source packages were build on
the official buildds in an environment that didn't have extra packages
installed.

So I propose to change the debootstrap buildd variant to install fewer
packages: to help catch this sort of bugs early. In the best case, already on
the developer's machine when they try to build the package.

As always this is a trade-off. If this change to debootstrap is not made, these
bugs will continue to keep happening and the time of some of us will continue
to be wasted on this issue. What is the other side of the coin? If this change
is made, what would break? Santiago already analyzed the archive to find source
packages that would fail and filed bugs. So we know what would break and we
informed the maintainers. What else would break? Would anything else break
other than the principle that debootstrap historically just must include the
priority:required packages just because it has always done it like that?

I really do not understand why using the Priority field and only the Priority
field is a thing that just must keep being used by debootstrap. Why is it a
problem to use the Essential field instead?

Right now, debootstrap is the odd-one-out in the archive. To my knowledge there
is no other software (other than mmdebstrap which will mirror what debootstrap
does by design) which considers the Priority field when selecting packages that
need to be installed to satisfy the build-dependencies of a source package.
Sbuild for example is fine with working on chroots that just include
essenital+apt but it will only install build-essential and not
Priority:required packages. When asking apt to satisfy build dependencies, it
will install build-essenital but not Priority:required packages. When asking

Bug#1053111: e2fsprogs FTBFS when systemd.pc changes systemdsystemunitdir

[Theodore Ts'o]

On Tue, Sep 26, 2023 at 10:31:41PM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.47.0-2
> Tags: ftbfs patch
> User: helm...@debian.org
> Usertags: dep17m2
> 
> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. e2fsprogs' upstream build system consumes this
> variable while the packaging hard codes its current value. When we
> change it, e2fsprogs will FTBFS. Consider applying the attached patch to
> avoid this failure.

Out of curiosity, do you know when this change to systemdsystemunitdir
is planned to happen?  I was planning on releasing a 1.47.1 release in
the next month or two, and I'm curious about the planned timing of the
change in systemd.pc.  Are we talking about something that is going to
happen in days?  weeks?  months?

It would be helpful to know how urgently we need to get an updated
Debian source package released.

Thanks,

- Ted

Bug#1053045: king: FTBFS with default Java 21

[Emmanuel Bourg]

Control: notfound -1 2.24+dfsg2-1

This was already fixed with ant/1.10.14-1. I've rebuilt with OpenJDK 21 
and besides the language level there was no compilation error.


Emmanuel Bourg

Bug#1053186: apt dist-upgrade wants to remove manually installed packages

[Witold Baryluk]

Package: apt
Version: 2.7.3
Severity: important
X-Debbugs-Cc: witold.bary...@gmail.com

Hi.

Happens in 2.7.3 and 2.7.6

When on testing and unstable.  (as of this writing)

root@debian:~# apt dist-upgrade  --purge  -V
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
   erlang-dev (1:25.2.3+dfsg-1)
   erlang-dialyzer (1:25.2.3+dfsg-1)
   erlang-diameter (1:25.2.3+dfsg-1)
   erlang-edoc (1:25.2.3+dfsg-1)
   erlang-erl-docgen (1:25.2.3+dfsg-1)
   erlang-eunit (1:25.2.3+dfsg-1)
   erlang-examples (1:25.2.3+dfsg-1)
   erlang-jinterface (1:25.2.3+dfsg-1)
   erlang-megaco (1:25.2.3+dfsg-1)
   erlang-mode (1:25.2.3+dfsg-1)
   erlang-odbc (1:25.2.3+dfsg-1)
   erlang-src (1:25.2.3+dfsg-1)
   erlang-ssh (1:25.2.3+dfsg-1)
   gir1.2-javascriptcoregtk-4.0 (2.42.0-1)
   gir1.2-javascriptcoregtk-6.0 (2.42.0-1)
   libaom-dev (3.7.0~really3.6.1-1)
   libcld2-0 (0.0.0-git20150806-9)
   libcolord-gtk1 (0.3.0-4)
   libcpprest2.10 (2.10.18-1+b1)
   libdav1d-dev (1.2.1-2)
   libde265-dev (1.0.12-2)
   libheif-dev (1.16.2-2+b1)
   libjavascriptcoregtk-6.0-1 (2.42.0-1)
   liblucene++0v5 (3.0.8-8)
   libosmgpsmap-1.0-1 (1.2.0-2)
   libvpx-dev (1.12.0-1)
   poedit-common (3.3.2-2)
   python3-arrow (1.2.3-1)
   python3-listparser (0.18-3)
   python3-readability (0.8.1+dfsg1-3)
   python3-syndom (1.0-2)
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
   darktable* (4.4.2-1)
   erlang* (1:25.2.3+dfsg-1)
   erlang-common-test* (1:25.2.3+dfsg-1)
   erlang-debugger* (1:25.2.3+dfsg-1)
   erlang-et* (1:25.2.3+dfsg-1)
   erlang-observer* (1:25.2.3+dfsg-1)
   erlang-reltool* (1:25.2.3+dfsg-1)
   erlang-wx* (1:25.2.3+dfsg-1)
   gir1.2-webkit-6.0* (2.42.0-1)
   gir1.2-webkit2-4.0* (2.42.0-1)
   gnome* (1:44+1)
   gnome-calendar* (45.0-1)
   gnome-feeds* (2.2.0-2)
   gnome-initial-setup* (45.0-1)
   kimageformat-plugins* (5.107.0-3)
   libavif-dev* (0.11.1-3+b1)
   libedataserverui4-1.0-0* (3.50.0-1)
   libgd-dev* (2.3.3-9)
   libwebkit2gtk-4.0-37* (2.42.0-1)
   libwebkitgtk-6.0-4* (2.42.0-1)
   libwxgtk-webview3.2-1* (3.2.2+dfsg-4)
   network-manager-openconnect-gnome* (1.2.10-1)
   poedit* (3.3.2-2)
   rebar* (2.6.4-3)
The following packages have been kept back:
   gnuradio (3.10.5.1-3 => 3.10.7.0-3+b2)
   gnuradio-dev (3.10.5.1-3 => 3.10.7.0-3+b2)
   libavif15 (0.11.1-3 => 0.11.1-3+b1)
   libavif15:i386 (0.11.1-3 => 0.11.1-3+b1)
   libomp-dev (1:14.0-55.7 => 1:16.0-57)
   lldb (1:14.0-55.7 => 1:16.0-57)
   svt-av1 (1.6.0+dfsg-1 => 1.7.0+dfsg-2)
The following packages will be upgraded:
   libmpfr6 (4.2.0-1 => 4.2.1-1)
   librados2 (16.2.11+ds-2 => 16.2.11+ds-3)
   librbd1 (16.2.11+ds-2 => 16.2.11+ds-3)
3 upgraded, 0 newly installed, 24 to remove and 7 not upgraded.
Need to get 6,494 kB of archives.
After this operation, 213 MB disk space will be freed.
Do you want to continue? [Y/n] 



It is trying to remove erlang, gnome, dartkable, and few more programs
that were installed explicitly.

I fail to see why it is trying to do so.

Regards,
Witold


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^postgresql.*-15";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";

Bug#1053081: svnkit: FTBFS with default Java 21

[Emmanuel Bourg]

Le 27/09/2023 à 00:22, Vladimir Petko a écrit :


compile-library:
 [mkdir] Created dir: /<>/svnkit/bin
 [mkdir] Created dir: /<>/svnkit-cli/bin
 [mkdir] Created dir: /<>/svnkit-javahl16/bin
 [javac] /<>/debian/build.xml:20: warning: 'includeantruntime' 
was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
 [javac] Compiling 1082 source files to /<>/svnkit/bin
 [javac] warning: [options] bootstrap class path not set in conjunction 
with -source 7
 [javac] error: Source option 7 is no longer supported. Use 8 or later.
 [javac] error: Target option 7 is no longer supported. Use 8 or later.


This report is outdated, the error no longer occurs with ant/1.10.14-1.

Emmanuel Bourg

Bug#1051739: Package is uninstallable, bug unacknowledged, therefore release critical

[Bastian Germann]

On Thu, 21 Sep 2023 15:59:45 + Mike Gabriel 
 wrote:
Problem here is that the downloaded dropbox executable probably is  
still GTK-2+. I need to test this and see how easily portable to GTK-3  
is.


It is a PyQt5 application now. So the dependency is not needed at all. I have 
verified it.

Bug#1053185: ITP: python-varlink -- Python implementation of the Varlink protocol

[Luca Boccassi]

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

* Package name  : python-varlink
  Version   : 31.0.0
  Upstream Author   : various
* URL   : https://github.com/varlink/python
* License  : Apache-2.0
  Programming Lang: python
  Description: Python implementation of the Varlink protocol
  with client/server capabilities

Bug#1053087: xz-java: FTBFS with default Java 21

[Emmanuel Bourg]

Le 29/09/2023 à 00:58, Vladimir Petko a écrit :

The source level 7 is hardcoded in the build properties[1].

[1] https://sources.debian.org/src/xz-java/1.9-1/build.properties


That's not a problem, Ant is patched to detect an unsupported level for 
the JDK used and change it automatically.


Emmanuel Bourg

Bug#1053013: beansbinding: FTBFS with default Java 21

[Emmanuel Bourg]

Le 29/09/2023 à 01:00, Vladimir Petko a écrit :

The source level 7 is hardcoded in project properties[1].

[1] 
https://sources.debian.org/src/beansbinding/1.2.1-4/nbproject/project.properties/



The javadoc error you reported initially no longer occurs,
but when Ant adjusts the level there is this error later:

-do-compile:
[javac] Using javac -source 1.7 is no longer supported, switching to 8
[javac] Using javac -target 1.7 is no longer supported, switching to 8
[javac] Compiling 123 source files to 
/home/ebourg/packaging/beansbinding/build/classes
[javac] warning: source release 8 requires target release 8

So there is still a corner case not properly handled by Ant, I'll get a look.

Emmanuel Bourg

Bug#1053087: xz-java: FTBFS with default Java 21

[Vladimir Petko]

The source level 7 is hardcoded in the build properties[1].

[1] https://sources.debian.org/src/xz-java/1.9-1/build.properties

Bug#1053087: xz-java: FTBFS with default Java 21

[Emmanuel Bourg]

Le 29/09/2023 à 00:44, Vladimir Petko a écrit :

Please see the attached log:
The relevant part:
--

Preparing to unpack .../065-ant_1.10.13-2_all.deb ...
Unpacking ant (1.10.13-2)
--



ant/1.10.13-2 adjusted automatically the source/target level.

ant/1.10.14-1 adjusted automatically the release level, that's why 
xz-java was still failing to build with ant/1.10.13-2


I told you by mail to check again before reporting the issues :)

Emmanuel Bourg

Bug#1053013: beansbinding: FTBFS with default Java 21

[Vladimir Petko]

The source level 7 is hardcoded in project properties[1].

[1] 
https://sources.debian.org/src/beansbinding/1.2.1-4/nbproject/project.properties/

Bug#1053013: beansbinding: FTBFS with default Java 21

[Vladimir Petko]

Hi,

 Please see the attached log. The relevant part:
--
Preparing to unpack .../065-ant_1.10.13-2_all.deb ...
Unpacking ant (1.10.13-2) ...
-


buildlog_ubuntu-mantic-amd64.beansbinding_1.2.1-4build1_BUILDING.txt.gz
Description: application/gzip

Bug#1053032: fixed in jlibeps 0.1.ds3-7

[Emmanuel Bourg]

This change wasn't necessary, Ant automatically updates the 
source/target level, sorry for the trouble.


Emmanuel Bourg

Bug#1053087: xz-java: FTBFS with default Java 21

[Vladimir Petko]

Please see the attached log:
The relevant part:
--

Preparing to unpack .../065-ant_1.10.13-2_all.deb ...
Unpacking ant (1.10.13-2)
--


buildlog_ubuntu-mantic-amd64.xz-java_1.9-1build1_BUILDING.txt.gz
Description: application/gzip

Bug#1053013: beansbinding: FTBFS with default Java 21

[Emmanuel Bourg]

Le 26/09/2023 à 23:49, Vladimir Petko a écrit :


-javadoc-build:
 [mkdir] Created dir: /<>/dist/javadoc
   [javadoc] Generating Javadoc
   [javadoc] Debian build on Java 9+ detected: Adding the 
--ignore-source-errors option
   [javadoc] Debian build on Java 9+ detected: Adding the -Xdoclint:none option
   [javadoc] Javadoc execution
   [javadoc] error: Source option 7 is no longer supported. Use 8 or later.
   [javadoc] error: Target option 7 is no longer supported. Use 8 or later.
   [javadoc] 2 errors


This report is outdated, the error no longer occurs with ant/1.10.13-2.

Emmanuel Bourg

Bug#1036417: NMU 0.17-2.3

[Bastian Germann]

I am uploading a NMU to DELAYED/10 to fix this.
The debdiff is attached.diff -Nru binfmtc-0.17/NEWS binfmtc-0.17/NEWS
--- binfmtc-0.17/NEWS   2023-09-28 21:42:25.0 +
+++ binfmtc-0.17/NEWS   2009-02-07 20:43:10.0 +
@@ -1,8 +1,6 @@
-0.17 21 Sep 2011
+0.17 
 
 + -g option added to default for C++/C for easy debugging.
-+ realksh.c kernel printk message handling is more deterministic.
-! removed pascal support.
 
 0.16 4 Oct 2008
 
diff -Nru binfmtc-0.17/changelogs/ChangeLog.ibook-dancer 
binfmtc-0.17/changelogs/ChangeLog.ibook-dancer
--- binfmtc-0.17/changelogs/ChangeLog.ibook-dancer  2023-09-28 
21:42:25.0 +
+++ binfmtc-0.17/changelogs/ChangeLog.ibook-dancer  1970-01-01 
00:00:00.0 +
@@ -1,668 +0,0 @@
-# do not edit -- automatically generated by arch changelog
-# arch-tag: 
automatic-changelog--dan...@ibookg4.dancer.netfort.gr.jp--2005/binfmtc--mainline--0.1
-#
-
-2005-07-15 11:05:13 GMTJunichi Uekawa (dancer on ibook) 
patch-33
-
-Summary:
-  cprintf.c is done
-Revision:
-  binfmtc--mainline--0.1--patch-33
-
-cprintf.c is done
-
-
-modified files:
- ChangeLog changelogs/ChangeLog.ibook-dancer realcsh.1
- realcsh.c
-
-
-2005-07-06 22:45:12 GMTJunichi Uekawa (dancer on ibook) 
patch-32
-
-Summary:
-  merge work done in web/atoron
-Revision:
-  binfmtc--mainline--0.1--patch-32
-
-merge work done in web/atoron
-
-Patches applied:
-
- * dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-5
-   merge ibook for 0.4, 0.5 changes 
-
- * dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-6
-   add x86 test
-
-
-new files:
- tests/.arch-ids/asm-x86.S.id tests/asm-x86.S
-
-modified files:
- ChangeLog Makefile.am NEWS changelogs/ChangeLog.ibook-dancer
- changelogs/ChangeLog.mainline configure.ac debian/changelog
- tests/asm.sh
-
-new patches:
- dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-5
- dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-6
-
-
-2005-06-03 21:03:28 GMTJunichi Uekawa (dancer on ibook) 
patch-31
-
-Summary:
-  Pascal and Fortran bindings
-Revision:
-  binfmtc--mainline--0.1--patch-31
-
-Pascal and Fortran bindings
-
-
-new files:
- .arch-ids/binfmtc-lang-f.c.id .arch-ids/binfmtc-lang-p.c.id
- .arch-ids/binfmtf-interpreter.1.id
- .arch-ids/binfmtp-interpreter.1.id binfmtc-lang-f.c
- binfmtc-lang-p.c binfmtf-interpreter.1 binfmtp-interpreter.1
- debian/.arch-ids/fcompile.binfmts.id
- debian/.arch-ids/pcompile.binfmts.id debian/fcompile.binfmts
- debian/pcompile.binfmts tests/.arch-ids/fortran.f.id
- tests/.arch-ids/fortran.sh.id tests/.arch-ids/pascal.pas.id
- tests/.arch-ids/pascal.sh.id tests/fortran.f tests/fortran.sh
- tests/pascal.pas tests/pascal.sh
-
-modified files:
- ChangeLog Makefile.am NEWS binfmtc-interpreter.c
- changelogs/ChangeLog.ibook-dancer configure.ac
- debian/binfmtc.postinst debian/binfmtc.postrm debian/changelog
- debian/control debian/rules
-
-
-2005-06-03 15:36:36 GMTJunichi Uekawa (dancer on ibook) 
patch-30
-
-Summary:
-  fix process waiting for file deletion
-Revision:
-  binfmtc--mainline--0.1--patch-30
-
-fix process waiting for file deletion
-
-
-modified files:
- ChangeLog NEWS binfmtc-interpreter.c
- changelogs/ChangeLog.ibook-dancer configure.ac
- debian/changelog
-
-
-2005-06-03 10:47:23 GMTJunichi Uekawa (dancer on ibook) 
patch-29
-
-Summary:
-  demorevert
-Revision:
-  binfmtc--mainline--0.1--patch-29
-
-demorevert
-
-
-modified files:
- changelogs/ChangeLog.ibook-dancer debian/changelog
- debian/rules
-
-
-2005-06-03 09:08:39 GMTJunichi Uekawa (dancer on ibook) 
patch-28
-
-Summary:
-  merge from web mainstream
-Revision:
-  binfmtc--mainline--0.1--patch-28
-
-merge from web mainstream
-
-Patches applied:
-
- * dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-2
-   merge ibook
-
- * dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-3
-   0.2 release on web
-
- * dan...@netfort.gr.jp--2005-web/binfmtc--mainline--0.1--patch-4
-   Add java support
-
-
-new files:
- .arch-ids/binfmtc-lang-gcj.c.id
- .arch-ids/binfmtgcj-interpreter.1.id binfmtc-lang-gcj.c
- binfmtgcj-interpreter.1 debian/.arch-ids/gcjcompile.binfmts.id
- debian/gcjcompile.binfmts tests/.arch-ids/java.sh.id
- tests/.arch-ids/javatest.java.id tests/java.sh
- tests/javatest.java
-
-modified files:
- ChangeLog Makefile.am NEWS binfmtasm-interpreter.1
- binfmtc-interpreter.1 changelogs/ChangeLog.ibook-dancer
- changelogs/ChangeLog.mainline configure.ac
- debian/binfmtc.postinst debian/binfmtc.postrm 

Bug#1007049: NMU 1.71-2.3

[Bastian Germann]

I am uploading a NMU to DELAYED/10 to fix this.
The debdiff is attached.diff -Nru appconfig-1.71/debian/changelog appconfig-1.71/debian/changelog
--- appconfig-1.71/debian/changelog 2023-09-28 21:51:49.0 +
+++ appconfig-1.71/debian/changelog 2023-09-28 21:47:18.0 +
@@ -1,3 +1,11 @@
+appconfig (1.71-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libappconfig-perl Multi-Arch: foreign. (Closes: #984507)
+  * Convert to source format 3.0. (Closes: #1007049)
+
+ -- Bastian Germann   Thu, 28 Sep 2023 21:47:18 +
+
 appconfig (1.71-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru appconfig-1.71/debian/control appconfig-1.71/debian/control
--- appconfig-1.71/debian/control   2023-09-28 21:51:49.0 +
+++ appconfig-1.71/debian/control   2023-09-28 21:47:18.0 +
@@ -8,6 +8,7 @@
 
 Package: libappconfig-perl
 Architecture: all
+Multi-Arch: foreign
 Depends: ${perl:Depends}, ${misc:Depends}
 Description: Perl module for configuration file and command line handling
  AppConfig is a bundle of Perl5 modules for reading configuration
diff -Nru appconfig-1.71/debian/patches/debian.patch 
appconfig-1.71/debian/patches/debian.patch
--- appconfig-1.71/debian/patches/debian.patch  1970-01-01 00:00:00.0 
+
+++ appconfig-1.71/debian/patches/debian.patch  2023-09-28 21:47:18.0 
+
@@ -0,0 +1,22 @@
+--- appconfig-1.71.orig/lib/AppConfig.pm
 appconfig-1.71/lib/AppConfig.pm
+@@ -548,7 +548,7 @@ variable.
+ =item ARGCOUNT
+ 
+ Specifies the number and type of arguments that the variable expects.
+-Constants in C<:expand> tag set define ARGCOUNT_NONE - simple on/off flag
++Constants in C<:argcount> tag set define ARGCOUNT_NONE - simple on/off flag
+ (default), ARGCOUNT_ONE - single value, ARGCOUNT_LIST - multiple values
+ accessed via list reference, ARGCOUNT_HASH - hash table, "key=value",
+ accessed via hash reference.
+--- appconfig-1.71.orig/lib/AppConfig/CGI.pm
 appconfig-1.71/lib/AppConfig/CGI.pm
+@@ -214,7 +214,7 @@ module via the cgi() method.
+ 
+ =head1 AUTHOR
+ 
+-Andy Wardley, Ca...@wardley.org>
++Andy Wardley, Ca...@wardley.orge>
+ 
+ =head1 COPYRIGHT
+ 
diff -Nru appconfig-1.71/debian/patches/series 
appconfig-1.71/debian/patches/series
--- appconfig-1.71/debian/patches/series1970-01-01 00:00:00.0 
+
+++ appconfig-1.71/debian/patches/series2023-09-28 21:47:18.0 
+
@@ -0,0 +1 @@
+debian.patch
diff -Nru appconfig-1.71/debian/source/format 
appconfig-1.71/debian/source/format
--- appconfig-1.71/debian/source/format 1970-01-01 00:00:00.0 +
+++ appconfig-1.71/debian/source/format 2023-09-28 21:47:18.0 +
@@ -0,0 +1 @@
+3.0 (quilt)
diff -Nru appconfig-1.71/lib/AppConfig/CGI.pm 
appconfig-1.71/lib/AppConfig/CGI.pm
--- appconfig-1.71/lib/AppConfig/CGI.pm 2023-09-28 21:51:49.0 +
+++ appconfig-1.71/lib/AppConfig/CGI.pm 2015-03-01 22:21:49.0 +
@@ -214,7 +214,7 @@
 
 =head1 AUTHOR
 
-Andy Wardley, Ca...@wardley.orge>
+Andy Wardley, Ca...@wardley.org>
 
 =head1 COPYRIGHT
 
diff -Nru appconfig-1.71/lib/AppConfig.pm appconfig-1.71/lib/AppConfig.pm
--- appconfig-1.71/lib/AppConfig.pm 2023-09-28 21:51:49.0 +
+++ appconfig-1.71/lib/AppConfig.pm 2015-03-01 22:23:44.0 +
@@ -548,7 +548,7 @@
 =item ARGCOUNT
 
 Specifies the number and type of arguments that the variable expects.
-Constants in C<:argcount> tag set define ARGCOUNT_NONE - simple on/off flag
+Constants in C<:expand> tag set define ARGCOUNT_NONE - simple on/off flag
 (default), ARGCOUNT_ONE - single value, ARGCOUNT_LIST - multiple values
 accessed via list reference, ARGCOUNT_HASH - hash table, "key=value",
 accessed via hash reference.

Bug#1053087: xz-java: FTBFS with default Java 21

[Emmanuel Bourg]

Le 27/09/2023 à 00:24, Vladimir Petko a écrit :


compile:
 [mkdir] Created dir: /<>/build/classes
 [javac] Compiling 108 source files to /<>/build/classes
 [javac] Ignoring source, target and bootclasspath as release has been set
 [javac] error: release version 7 not supported
 [javac] Usage: javac  
 [javac] use --help for a list of possible options


This report is outdated, the error no longer occurs with ant/1.10.13-2.

Emmanuel Bourg

Bug#1051229: tlp 1.6 doesn't conflict with power-profile-daemon anymore

[Raphaël Halimi]

Control: tags -1 wontfix
Control: close -1

Dear Sebastien,

Thanks for your suggestion and your patch, but I prefer to follow 
upstream's advice and keep the conflict in place to disallow 
co-installation of TLP and PPD.


Regards,

--
Raphaël Halimi

Bug#1053182: libvpx: diff for NMU version 1.12.0-1.1

[Salvatore Bonaccorso]

X-Debbugs-CC: Sebastian Ramacher 

Control: tags 1053182 + patch
Control: tags 1053182 + pending


Dear maintainer,

I've prepared an NMU for libvpx (versioned as 1.12.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru libvpx-1.12.0/debian/changelog libvpx-1.12.0/debian/changelog
--- libvpx-1.12.0/debian/changelog	2022-07-09 15:20:25.0 +0200
+++ libvpx-1.12.0/debian/changelog	2023-09-28 23:07:11.0 +0200
@@ -1,3 +1,11 @@
+libvpx (1.12.0-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * encode_api_test: add ConfigResizeChangeThreadCount
+  * VP8: disallow thread count changes (CVE-2023-5217) (Closes: #1053182)
+
+ -- Salvatore Bonaccorso   Thu, 28 Sep 2023 23:07:11 +0200
+
 libvpx (1.12.0-1) unstable; urgency=medium
 
   * Team upload
diff -Nru libvpx-1.12.0/debian/patches/0002-encode_api_test-add-ConfigResizeChangeThreadCount.patch libvpx-1.12.0/debian/patches/0002-encode_api_test-add-ConfigResizeChangeThreadCount.patch
--- libvpx-1.12.0/debian/patches/0002-encode_api_test-add-ConfigResizeChangeThreadCount.patch	1970-01-01 01:00:00.0 +0100
+++ libvpx-1.12.0/debian/patches/0002-encode_api_test-add-ConfigResizeChangeThreadCount.patch	2023-09-28 23:07:11.0 +0200
@@ -0,0 +1,89 @@
+From: James Zern 
+Date: Mon, 25 Sep 2023 18:53:41 -0700
+Subject: encode_api_test: add ConfigResizeChangeThreadCount
+Origin: https://github.com/webmproject/libvpx/commit/af6dedd715f4307669366944cca6e0417b290282
+Bug-Debian: https://bugs.debian.org/1053182
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-5217
+
+Update thread counts and resolution to ensure allocations are updated
+correctly. VP8 is disabled to avoid a crash.
+
+Bug: chromium:1486441
+Change-Id: Ie89776d9818d27dc351eff298a44c699e850761b
+---
+ test/encode_api_test.cc | 50 -
+ 1 file changed, 49 insertions(+), 1 deletion(-)
+
+--- a/test/encode_api_test.cc
 b/test/encode_api_test.cc
+@@ -304,7 +304,6 @@ TEST(EncodeAPI, SetRoi) {
+ 
+ void InitCodec(const vpx_codec_iface_t , int width, int height,
+vpx_codec_ctx_t *enc, vpx_codec_enc_cfg_t *cfg) {
+-  ASSERT_EQ(vpx_codec_enc_config_default(, cfg, 0), VPX_CODEC_OK);
+   cfg->g_w = width;
+   cfg->g_h = height;
+   cfg->g_lag_in_frames = 0;
+@@ -342,6 +341,7 @@ TEST(EncodeAPI, ConfigChangeThreadCount)
+ vpx_codec_ctx_t ctx = {};
+   } enc;
+ 
++  ASSERT_EQ(vpx_codec_enc_config_default(iface, , 0), VPX_CODEC_OK);
+   EXPECT_NO_FATAL_FAILURE(
+   InitCodec(*iface, kWidth, kHeight, , ));
+   if (IsVP9(iface)) {
+@@ -353,6 +353,54 @@ TEST(EncodeAPI, ConfigChangeThreadCount)
+ 
+   for (const auto threads : { 1, 4, 8, 6, 2, 1 }) {
+ cfg.g_threads = threads;
++EXPECT_NO_FATAL_FAILURE(EncodeWithConfig(cfg, ))
++<< "iteration: " << i << " threads: " << threads;
++  }
++}
++  }
++}
++
++TEST(EncodeAPI, ConfigResizeChangeThreadCount) {
++  constexpr int kInitWidth = 1024;
++  constexpr int kInitHeight = 1024;
++
++  for (const auto *iface : kCodecIfaces) {
++SCOPED_TRACE(vpx_codec_iface_name(iface));
++if (!IsVP9(iface)) {
++  GTEST_SKIP() << "TODO(https://crbug.com/1486441) remove this condition "
++  "after VP8 is fixed.";
++}
++for (int i = 0; i < (IsVP9(iface) ? 2 : 1); ++i) {
++  vpx_codec_enc_cfg_t cfg = {};
++  struct Encoder {
++~Encoder() { EXPECT_EQ(vpx_codec_destroy(), VPX_CODEC_OK); }
++vpx_codec_ctx_t ctx = {};
++  } enc;
++
++  ASSERT_EQ(vpx_codec_enc_config_default(iface, , 0), VPX_CODEC_OK);
++  // Start in threaded mode to ensure resolution and thread related
++  // allocations are updated correctly across changes in resolution and
++  // thread counts. See https://crbug.com/1486441.
++  cfg.g_threads = 4;
++  EXPECT_NO_FATAL_FAILURE(
++  InitCodec(*iface, kInitWidth, kInitHeight, , ));
++  if (IsVP9(iface)) {
++EXPECT_EQ(vpx_codec_control_(, VP9E_SET_TILE_COLUMNS, 6),
++  VPX_CODEC_OK);
++EXPECT_EQ(vpx_codec_control_(, VP9E_SET_ROW_MT, i),
++  VPX_CODEC_OK);
++  }
++
++  cfg.g_w = 1000;
++  cfg.g_h = 608;
++  EXPECT_EQ(vpx_codec_enc_config_set(, ), VPX_CODEC_OK)
++  << vpx_codec_error_detail();
++
++  cfg.g_w = 16;
++  cfg.g_h = 720;
++
++  for (const auto threads : { 1, 4, 8, 6, 2, 1 }) {
++cfg.g_threads = threads;
+ EXPECT_NO_FATAL_FAILURE(EncodeWithConfig(cfg, ))
+ << "iteration: " << i << " threads: " << threads;
+   }
diff -Nru libvpx-1.12.0/debian/patches/0003-VP8-disallow-thread-count-changes.patch libvpx-1.12.0/debian/patches/0003-VP8-disallow-thread-count-changes.patch
--- libvpx-1.12.0/debian/patches/0003-VP8-disallow-thread-count-changes.patch	1970-01-01 01:00:00.0 +0100
+++ 

Bug#1053184: Updating the mono Uploaders list

[Tobias Frost]

Source: mono
Version: 6.8.0.105+dfsg-3.3 6.8.0.105+dfsg-3.3~deb11u1 5.18.0.240+dfsg-3 
5.18.0.240+dfsg-3+deb10u1 3.2.8+dfsg-10+deb8u1 3.2.8+dfsg-10 6.8.0.105+dfsg-3.5 
4.6.2.7+dfsg-1 4.6.2.7+dfsg-1+deb9u1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Jo Shields  has retired, so can't work on
the mono package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.


signature.asc
Description: PGP signature

Bug#1053183: galera-4: FTBFS on sparc64: one of sever post-build test fail

[Otto Kekäläinen]

Source: galera-4
Version: 26.4.16-1
Severity: normal
Justification: unofficial architecture
Tags. ftbfs
X-Debbugs-CC: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64

Galera does build on sparc64, but one of the post-build tests simply
crash. Looking at old galera-4 builds and even galera-3 builds, this
issue issue is visible in all build logs.

Running tests...
/usr/bin/ctest --force-new-ctest-process --output-on-failure
Test project /<>/obj-sparc64-linux-gnu
Start 1: gu_tests
1/7 Test #1: gu_tests .   Passed7.65 sec
Start 2: gu_tests++
2/7 Test #2: gu_tests++ ...   Passed   49.06 sec
Start 3: check_gcomm
3/7 Test #3: check_gcomm ..   Passed   19.58 sec
Start 4: gcache_tests
4/7 Test #4: gcache_tests .   Passed0.34 sec
Start 5: gcs_tests
5/7 Test #5: gcs_tests    Passed   10.94 sec
Start 6: galera_check
6/7 Test #6: galera_check .***Failed9.18 sec
Running suite(s): DataSet
50%: Checks: 2, Failures: 0, Errors: 1
./galera/tests/data_set_check.cpp:216:E:DataSet:ver1:0: (after this
point) Received signal 10 (Bus error)
Running suite(s): KeySet
75%: Checks: 4, Failures: 0, Errors: 1
./galera/tests/key_set_check.cpp:93:E:KeySet:ver1_3:0: (after this
point) Received signal 10 (Bus error)
Running suite(s): WriteSet
80%: Checks: 5, Failures: 0, Errors: 1
./galera/tests/write_set_ng_check.cpp:101:E:WriteSet
basic:ver3_basic_rsv1:0: (after this point) Received signal 10 (Bus
error)
Running suite(s): certification
100%: Checks: 6, Failures: 0, Errors: 0
Running suite(s): trx_handle
100%: Checks: 4, Failures: 0, Errors: 0
Running suite(s): service_thd
100%: Checks: 3, Failures: 0, Errors: 0
Running suite(s): ist
100%: Checks: 14, Failures: 0, Errors: 0
Running suite(s): saved_state
100%: Checks: 3, Failures: 0, Errors: 0
Running suite(s): Defaults
100%: Checks: 1, Failures: 0, Errors: 0
Running suite(s): progress_suite
100%: Checks: 1, Failures: 0, Errors: 0
Total tests failed: 3
Start 7: wsrep_test
7/7 Test #7: wsrep_test ...   Passed0.08 sec
86% tests passed, 1 tests failed out of 7
Total Test time (real) =  96.90 sec
The following tests FAILED:
 6 - galera_check (Failed)


Example: 
https://buildd.debian.org/status/fetch.php?pkg=galera-4=sparc64=26.4.16-1=1695521394=0

Bug#1053130: bookworm-pu: package glibc/2.36-9+deb12u2

[Aurelien Jarno]

On 2023-09-28 20:58, Adam D. Barratt wrote:
> Control: tags -1 confirmed
> 
> On Wed, 2023-09-27 at 23:47 +0200, Aurelien Jarno wrote:
> > The upstream glibc stable branch got a few fixes since the latest
> > point
> > released, including two security fixes.
> > 
> 
> Please go ahead.
> 

Thanks for the fast review, I have just uploaded it.

Regards
Aurelien

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

Bug#1053182: libvpx: CVE-2023-5217

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for libvpx.

CVE-2023-5217[0]:
| Heap buffer overflow in vp8 encoding in libvpx in Google Chrome
| prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker
| to potentially exploit heap corruption via a crafted HTML page.
| (Chromium security severity: High)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5217
https://www.cve.org/CVERecord?id=CVE-2023-5217
[1] 
https://github.com/webmproject/libvpx/commit/3fbd1dca6a4d2dad332a2110d646e4ffef36d590
[2] 
https://github.com/webmproject/libvpx/commit/af6dedd715f4307669366944cca6e0417b290282

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053181: ruby-kramdown-rfc2629: new upstream version available: 1.7.1

[Daniel Kahn Gillmor]

Source: ruby-kramdown-rfc2629
Version: 1.6.22-1
Severity: wishlist
X-Debbugs-Cc: d...@fifthhorseman.net

kramdown-rfc now has version 1.7.1 out.  it would be great to have
that in debian.

Thanks!

--dkg

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

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

Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1

[Adam D. Barratt]

On Thu, 2023-09-28 at 13:28 -0700, Soren Stoutner wrote:
> I’m afraid I don’t understand your comments.  Are you saying I should
> wait longer for someone to review it or are you saying I should go
> ahead with the upload?

"Please go ahead" meant exactly that, i.e. "Please go ahead with the
upload". The "confirmed" tag also indicates that.

The comment on patience was more general. Just over a week is not a
long time to have waited.

> On Thursday, September 28, 2023 1:07:47 PM MST Adam D. Barratt wrote:
> > More patience. :-p A week is not long to have waited, there's no
> > need
> > to chase.
> > 
> > Please go ahead.
> > 

Regards,

Adam

Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1

[Adam D. Barratt]

Control: tags -1 confirmed

On Fri, 2023-09-08 at 13:32 +0200, Frode Nordahl wrote:
> We would like to upload the latest stable point release of ovn 23.03
> to bookworm-p-u. Stable release branches are maintained upstream with
> the intention of providing bug fixes only and no compatibility
> breakages, and with automated non-trivial CI jobs that also cover
> Debian and Ubuntu.
> 
> Debdiff attached. Packaging updated with gbp/salsa config for new
> bookworm stable branch and in-flight patches to fix an issue with
> unnecessary logging breaking one of the tests introduced in the point
> release.

As Salvatore noted, the mail I'm quoting never made it to debian-
release, most likely due to the size of the attached diff.

For future reference, you may wish to try to reduce the size of the
attachment by e.g. compressing the diff. You could also filter out e.g.
test suite changes, so long as you clearly note in the request exactly
what filtering you have applied. For instance, your original diff comes
to

 78 files changed, 5643 insertions(+), 1808 deletions(-)

but excluding "*/tests/*" reduces that to

 62 files changed, 2179 insertions(+), 791 deletions(-)

Please go ahead, using the newer diff with the bug closure in the
changelog.

Regards,

Adam

Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1

[Soren Stoutner]

I’m afraid I don’t understand your comments.  Are you saying I should wait 
longer for someone to review it or are you saying I should go ahead with the 
upload?

On Thursday, September 28, 2023 1:07:47 PM MST Adam D. Barratt wrote:
> More patience. :-p A week is not long to have waited, there's no need
> to chase.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam


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

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

Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1

[Luca Boccassi]

On Thu, 28 Sept 2023 at 21:13, Adam D. Barratt  wrote:
>
> On Tue, 2023-09-19 at 08:59 +0100, Luca Boccassi wrote:
> > On Tue, 19 Sept 2023 at 08:21, Salvatore Bonaccorso <
> > car...@debian.org> wrote:
> [...]
> > > Two obervations: Can you please close #1043598 in the
> > > debian/changelog as well as the update addresses CVE-2023-3153.
> [...]
> > Changelog mentions CVE and bug:
> >
> > ovn (23.03.1-1~deb12u1) bookworm; urgency=medium
> >
> >   * Team upload.
> >   * Update upstream source from tag 'upstream/23.03.1'
> > - Add CoPP for the svc_monitor_mac. This addresses CVE-2023-3153.
> > (Closes: #1043598)
> >   * d/p/*vif-plug-representor*: Lower severity of failure to set udev
> > receive buffer size (LP: #2034700).
> >
>
> In fact, the debdiff that was attached to the request does not contain
> that bug closure:
>
> +  * Team upload.
> +  * Update upstream source from tag 'upstream/23.03.1'
> +- Add CoPP for the svc_monitor_mac. This addresses CVE-2023-3153.
> +  * d/p/*vif-plug-representor*: Lower severity of failure to set udev
> +receive buffer size (LP: #2034700).
>
> Is it not the correct debdiff?

Yes it was the old one, I just downloaded it from the original mail,
forgetting that we made that change later. New one:
https://pastebin.ubuntu.com/p/5TV6fWFYtx/

Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1

[Adam D. Barratt]

On Tue, 2023-09-19 at 08:59 +0100, Luca Boccassi wrote:
> On Tue, 19 Sept 2023 at 08:21, Salvatore Bonaccorso <
> car...@debian.org> wrote:
[...]
> > Two obervations: Can you please close #1043598 in the
> > debian/changelog as well as the update addresses CVE-2023-3153.
[...]
> Changelog mentions CVE and bug:
> 
> ovn (23.03.1-1~deb12u1) bookworm; urgency=medium
> 
>   * Team upload.
>   * Update upstream source from tag 'upstream/23.03.1'
> - Add CoPP for the svc_monitor_mac. This addresses CVE-2023-3153.
> (Closes: #1043598)
>   * d/p/*vif-plug-representor*: Lower severity of failure to set udev
> receive buffer size (LP: #2034700).
> 

In fact, the debdiff that was attached to the request does not contain
that bug closure:

+  * Team upload.
+  * Update upstream source from tag 'upstream/23.03.1'
+- Add CoPP for the svc_monitor_mac. This addresses CVE-2023-3153.
+  * d/p/*vif-plug-representor*: Lower severity of failure to set udev
+receive buffer size (LP: #2034700).

Is it not the correct debdiff?

Regards,

Adam

Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1

[Adam D. Barratt]

Control: tags -1 confirmed

On Thu, 2023-09-28 at 12:49 -0700, Soren Stoutner wrote:
> Are the any changes I should make before I upload a package?

More patience. :-p A week is not long to have waited, there's no need
to chase.

Please go ahead.

Regards,

Adam

Bug#1053180: openssl: Make RSA decryption API safe to use with PKCS#1 v1.5 padding (Marvin/Bleichenbacher)

[Matt Taggart]

Package: openssl
Version: 3.0.11-1

Recently "The Marvin Attack" aka Bleichenbacher timing attack has been 
in the news again:

  https://people.redhat.com/~hkario/marvin/

CVE-2022-4304 was already fixed in all but buster:
  https://security-tracker.debian.org/tracker/CVE-2022-4304

But the page references an API level pull request upstream:
  https://github.com/openssl/openssl/pull/13817

and there is also this corresponding issue:
  https://github.com/openssl/openssl/issues/13421

The history on that issue is long and complicated and it's not clear to 
me if this has been fixed and if so on what releases? Maybe someone with 
more knowledge of this can make more sense of it?


If it hasn't been fixed this bug can track it.
If it has been fixed it would be nice to have something in changelog or 
NEWS mentioning it.


But separate from that, it would be good to move away from this old 
potentially hazardous method. Is there some way of determining what 
software in Debian might be using this (via openssl API) so those things 
could get fixed as well?


Not much can be done about non-Debian software running on Debian, but we 
want old software to continue to function (at least for a while, 
eventually some sort of logged warning might be nice).


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1053130: bookworm-pu: package glibc/2.36-9+deb12u2

[Adam D. Barratt]

Control: tags -1 confirmed

On Wed, 2023-09-27 at 23:47 +0200, Aurelien Jarno wrote:
> The upstream glibc stable branch got a few fixes since the latest
> point
> released, including two security fixes.
> 

Please go ahead.

Regards,

Adam

Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1

[Nicholas D Steeves]

Manphiz  writes:

> Hi Nicholas,
>
> Thanks for sponsoring the NMU!  I have pushed the release commit to
> debian/2.2.0+git20200805-1.1 in my repo[1].  Let me know if the tag name
> looks OK.
>
> [1] 
> https://salsa.debian.org/manphiz/silversearcher-ag/-/tags/debian%2F2.2.0+git20200805-1.1
>

You're welcome!  Looks good, so I merged it to the project.

--N


signature.asc
Description: PGP signature

Bug#1020478: hunspell-br: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Would you be interested in a patch to implement this functionality?

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

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

Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1

[Soren Stoutner]

Are the any changes I should make before I upload a package?

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

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

Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1

[Manphiz]

Nicholas D Steeves  writes:

> Xiyue Deng  writes:
>
>> Control: tags 62 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for silversearcher-ag (versioned as 
>> 2.2.0+git20200805-1.1)
>> and uploaded it to mentors.debian.net. Please feel free to tell me if I 
>> should
>> delay it longer.
>
> You may have noticed that the timer fired and that the upload was
> accepted :) Please push a release tag to you forked remote, and then
> I'll merge your work into the debian/collab-maint project.
>
> Best,
> Nicholas
>

Hi Nicholas,

Thanks for sponsoring the NMU!  I have pushed the release commit to
debian/2.2.0+git20200805-1.1 in my repo[1].  Let me know if the tag name
looks OK.

[1] 
https://salsa.debian.org/manphiz/silversearcher-ag/-/tags/debian%2F2.2.0+git20200805-1.1

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1052718: [Pkg-swan-devel] Bug#1052718: strongswan FTBFS when systemd.pc changes systemdsystemunitdir

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2023-09-26 at 12:54 +0200, Helmut Grohne wrote:
> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. strongswan's upstream build system consumes this
> variable while the packaging hard codes its current value. As we change
> it, strongswan will FTBFS. Consider applying the attached patch to avoid
> this failure.

Hey Helmut, thanks for the patch, it'll be part of the next upload.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUV06UACgkQ3rYcyPpX
RFsoGQf/UwyBWg+w+lcxdCzqYyzAAPRHDmqJGMHoXHs1U/oMAh0wOojvKBBZp4IF
eyejYo2BUT4Kl5023IbYeTSliXK1NiM6/eUY09yiLbCFyqBbUi8End/lKwex4r8U
i6qKxVZc18PnAVdYj8RgIx9LZ/anti/6ntSrXOSotynqM4JO1vZ4dzOVggbDaAbO
Kk1on2EbYxm7wgCWG52uyC5p8WIOVKOBUXrC8S9Ti4qZ05Jg6S+P5vU/9HovwqsH
vKE3IukiEZzrhTGx1w9SmrYac+BjaVwlXLP6oUVPWWTHCbmTewnTvpIE+GXnvjic
GAzcKiPBlyzoZQiLzoxm737At4mbgw==
=Sp2r
-END PGP SIGNATURE-

Bug#1053177: bullseye-pu: package xen/4.14.6-1

[Hans van Kranenburg]

Hi Adam,

On 9/28/23 19:09, Adam D. Barratt wrote:
> On Thu, 2023-09-28 at 18:27 +0200, Hans van Kranenburg wrote:
>> Xen 4.14 support (and security support) has ended upstream. The
>> upstream
>> stable branch for version 4.14 is frozen now, and a final maintenance
>> release version 4.14.6 has been released. We'd like to put this final
>> update into Bullseye, to properly finish the Xen work for Bullseye.
>> Also, a few security fixes (regarding CVE-2023-20593 CVE-2023-20569
>> CVE-2022-40982) are included.
>>
>> https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
>>
> 
> --- xen-4.14.5+94-ge49571868d/automation/scripts/qemu-smoke-x86-64.sh 
> 2023-03-21 13:07:44.0 +0100
> +++ xen-4.14.6/automation/scripts/qemu-smoke-x86-64.sh2023-08-07 
> 14:11:14.0 +0200
> @@ -5,11 +5,6 @@
>  # variant should be either pv or pvh
>  variant=$1
>  
> -# Install QEMU
> -export DEBIAN_FRONTENT=noninteractive
> -apt-get -qy update
> -apt-get -qy install qemu-system-x86
> 
> I realise this is an upstream change, but is it really intended to stop
> installing QEMU in a QEMU smoke test?

This particular change can be seen as the contents of the following
commit, in this case for 4.14:

 8< 

commit 98ec8ad2eeb96eb9d4b7f9bfd1ef3a994c63af17
Refs: RELEASE-4.14.5-103-g98ec8ad2eeb9
Author: Michal Orzel 
AuthorDate: Wed Apr 26 09:29:45 2023 +0200
Commit: Jan Beulich 
CommitDate: Wed Apr 26 09:29:45 2023 +0200

automation: Remove installation of packages from test scripts

Now, when these packages are already installed in the respective
containers, we can remove them from the test scripts.

Signed-off-by: Michal Orzel 
Reviewed-by: Stefano Stabellini 
master commit: 72cfe1c3ad1fae95f4f0ac51dbdd6838264fdd7f
master date: 2022-12-09 14:55:33 -0800

 >8 

This is part of a change to the upstream test machinery. The commit that
it's picked from (the 72cfe1c3ad1 thing) lockstep follows a previous
change to the development / master branch:

 8< 

commit 1ed7da301020ee1e16177cb3d9caa817f195a59a
Author: Michal Orzel 
Date:   Thu Nov 17 17:16:42 2022 +0100

automation: Install packages required by tests in containers

Installation of additional packages from the test scripts when running
the tests has some drawbacks. It is slower than cloning containers
and can
fail due to some network issues (apparently it often happens on x86
rackspace). This patch is adding the packages required by the tests
to be
installed when building the containers.

>From qemu-alpine-x86_64.sh into debian:stretch:
 - cpio,
 - busybox-static.

>From qemu-smoke-*-{arm,arm64}.sh into debian:unstable-arm64v8:
 - u-boot-qemu,
 - u-boot-tools,
 - device-tree-compiler,
 - curl,
 - cpio,
 - busybox-static.

The follow-up patch will remove installation of these packages from the
test scripts. This is done in order not to break the CI in-between.

Signed-off-by: Michal Orzel 
Reviewed-by: Stefano Stabellini 

 >8 

The Xen Project OSSTest machinery is used to run testing for the current
development version of Xen, as well as for the stable branch lines that
are still under active support.

After building/compiling the source code, all kinds of test scenarios
are executed, comprising tests for different virtualization modes, or
different kinds of functionality, but also different kinds of actual
hardware. AIUI, wanting to be able to do all of this quickly boils down
to a 'feet in the mud' situation, which involves automating interaction
with PDUs to be able to physically cut off power from a misbehaving
piece of server hardware, or, capturing actual serial console cable
output. I can understand that, at least for practical reasons, there is
no desire to duplicate/replicate all of this for each supported Xen version.

AIUI, The Xen source tree contains code/scripts to help setting up the
test cases, as well as to be able to run them. For the first part, the
current development code is used (the master branch), and for the second
part, well, whatever is in a branch line needs to be able to behave
correctly in that environment.

This is the reason why we can find the change with title "automation:
Install packages required by tests in containers" only once, committed
to the master branch at the time the change took place, and why similar
but possibly different variations on "automation: Remove installation of
packages from test scripts" do exist in various other branches, such as
stable-4.17 and stable-4.14 etc.

Also, note that for Debian, we don't do anything with this part of the
upstream source tree, or, at least, I mean, changes in there must not
cause changes in the actual debs that we ship.

Thanks for the question, it was a fun small exercise to go have a look
at what's actually happening here, since we normally don't really have
to interact with this stuff while doing the downstream 

Bug#1051241: headsup for gtk + pipewire update

[Jeremy Bícha]

Control: severity -1 serious

I am bumping the priority now because we are uploading the new Rust
GTK libraries now. It will take several hours for the libraries to
build.

Thank you,
Jeremy Bícha

Bug#999962: silversearcher-ag: diff for NMU version 2.2.0+git20200805-1.1

[Nicholas D Steeves]

Xiyue Deng  writes:

> Control: tags 62 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for silversearcher-ag (versioned as 
> 2.2.0+git20200805-1.1)
> and uploaded it to mentors.debian.net. Please feel free to tell me if I should
> delay it longer.

You may have noticed that the timer fired and that the upload was
accepted :) Please push a release tag to you forked remote, and then
I'll merge your work into the debian/collab-maint project.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1053003: mmdebstrap: Support build profile

[David Paul]

On Tue, 26 Sep 2023 23:27:20 +0200
Johannes Schauer Marin Rodrigues  wrote:

> Quoting David (Plasma) Paul (2023-09-26 22:25:47)
> > Please accept the attached patch to add support for the 
> > build profile to mmdebstrap. Please let me know if there's anything
> > you'd like me to clarify or change.  
> 
> I haven't tried your diff yet, but I've read it and it looks like it
> does the right thing. Thank you!
> 
> May I ask in which situation you found yourself wanting to build
> mmdebstrap without its manual pages?

It's not so much that I necessarily want to build mmdebstrap without
its manpages; rather, that I find it useful to document which build
dependencies are strictly needed to produce a functional program binary
and which are only required to do things like generate documentation or
run a testsuite. Build profiles, thus, provide an ideal way of adding
this metadata in a easily actionable manner.

[...]
> > Also, FWIW, the mmtarfilter script contains a section of code
> > headed by a comment explaining that it is for compatibility with
> > Python versions older than 3.8. As the aforementioned 'match'
> > statement makes the script in its current form error out with any
> > Python version less than 3.10, this code path may no longer be
> > necessary.  
> 
> The codepath is still necessary. What is not necessary anymore is to
> explicitly pass format=tarfile.PAX_FORMAT because that format became
> the default in 3.8.

Ok, I wasn't sure. Thanks for confirming.

> I adjusted the comment, thank you!

Thank you!

-- 
Plasma

Bug#1052629: bookworm-pu: package roundcube/1.6.3+dfsg-1~deb12u1

[Adam D. Barratt]

On Thu, 2023-09-28 at 20:33 +0200, Guilhem Moulin wrote:
> On Thu, 28 Sep 2023 at 18:53:46 +0100, Adam D. Barratt wrote:
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -1,5 +1,54 @@
> > # Changelog Roundcube Webmail
> > 
> > +## Unreleased
> > +
> > 
> > That seems wrong, given that you're uploading a released version.
> 
> Well spotted but that one is upstream's, see
> https://github.com/roundcube/roundcubemail/blob/1.6.3/CHANGELOG.md :-
> )
> 

I realised. :-) I felt it was worth mentioning in any case.

Regards,

Adam

Bug#1052629: bookworm-pu: package roundcube/1.6.3+dfsg-1~deb12u1

[Guilhem Moulin]

On Thu, 28 Sep 2023 at 18:53:46 +0100, Adam D. Barratt wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -1,5 +1,54 @@
> # Changelog Roundcube Webmail
> 
> +## Unreleased
> +
> 
> That seems wrong, given that you're uploading a released version.

Well spotted but that one is upstream's, see
https://github.com/roundcube/roundcubemail/blob/1.6.3/CHANGELOG.md :-)
(Also there also a few occurrences of “Version 1.6-git” in that release,
upstream probably forgot to run the pre-release script.)

> Please go ahead.

Thanks!

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1053142: chromium cannot startup after libfreetype6 upgrade to 2.12.1+dfsg-5+deb12u1

[Bernhard Schmidt]

Control: affects -1 src:freetype

Technically it probably should be the other way around, but I fear this
will be missed otherwise. Marking freetype as affected to at least it
shows up there.

Bug#1052629: bookworm-pu: package roundcube/1.6.3+dfsg-1~deb12u1

[Adam D. Barratt]

Control: tags -1 confirmed

On Mon, 2023-09-25 at 15:31 +0200, Guilhem Moulin wrote:
> On Mon, 25 Sep 2023 at 15:15:57 +0200, Guilhem Moulin wrote:
> > [ Other info ]
> > 
> > In addition to the debdiff.gz between 1.6.1+dfsg-1 (bookworm) and
> > 1.6.3+dfsg-1~deb12u1,
> > I attach a patch-applied diff excluding upstream's tests/**,
> > program/localization/**,
> > and plugins/*/localization/**, which should more accurately show
> > what
> > this p-u is about.
> 
> Now with the attachement :-)

--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,54 @@
 # Changelog Roundcube Webmail
 
+## Unreleased
+

That seems wrong, given that you're uploading a released version.

Please go ahead.

Regards,

Adam

Bug#1052363: bullseye-pu: cups/2.3.3op2-3+deb11u4

[Thorsten Alteholz]

On 27.09.23 20:33, Adam D. Barratt wrote:


Thanks; please go ahead.


great, thanks, ...

... and uploaded.

  Thorsten

Bug#1052361: bookworm-pu: cups/2.4.2-3+deb12u2

[Thorsten Alteholz]

On 27.09.23 20:32, Adam D. Barratt wrote:


Please go ahead.


great, thanks, ...

... and uploaded.

  Thorsten

Bug#1053102: bookworm-pu: package curl/7.88.1-10+deb12u3

[Adam D. Barratt]

Control: tags -1 confirmed

On Wed, 2023-09-27 at 21:24 +0800, Carlos Henrique Lima Melara wrote:
> A vulnerability was discovered and reported to Curl upstream [1] with
> the following CVE ID: CVE-2023-38039.
> 
> The description of the CVE is:
> 
> > When curl retrieves an HTTP response, it stores the incoming
> > headers so that they can be accessed later via the libcurl headers
> > API. However, curl did not have a limit in how many or how large
> > headers it would accept in a response, allowing a malicious server
> > to stream an endless series of headers and eventually cause curl to
> > run out of heap memory.
> 

Please go ahead.

Regards,

Adam

Bug#1053179: libavif: drop doc generation on arches without pandoc

[Drew Parsons]

Source: libavif
Version: 0.11.1-3
Severity: normal

The libavif build attempts to build docs (the man page) using pandoc
for each architecture. This is a problem since pandoc is not available
on several architectures.

debian/rules for libavif contains doc logic, defining MAN_PAGES_FLAG.
Currently it is only switched off if nodoc is used.

It would be helpful for the arches which don't have pandoc to switch
off the MAN_PAGES_FLAG for these selected architectures, similar to
the architecture-specific configuration already used to set SVT_FLAG.

The affected architectures are summarised on the build page
https://buildd.debian.org/status/package.php?p=libavif :

hppa
hurd-i386
loong64
sparc64

pandoc is only used to generate the man page.  I guess it does not
significantly differ between architectures.  Perhaps a copy of the
amd64 man page could be stored in the debian dir and used for these
architectures that can't generate their own man page.

Bug#1051241: headsup for gtk + pipewire update

[Jeremy Bícha]

Control: severity -1 important

Jonas,

I went ahead and pushed helvum 0.4.1 to a wip/gnome45 branch of the
Salsa repo. (I also pushed the pristine-tar and upstream/latest
branches since that seemed to be helpful.)

We are nearly ready to upload the new Rust GNOME 45 stack (rust-gtk
0.7, rust-glib 0.18, etc.) to Unstable. The new Rust libraries are
currently staged in Experimental.

My helvum package update built and appeared to run fine for me.

There is a smaller transition for rust-pipewire 0.7 but since that's
currently blocked by needing rust-convert-case accepted through NEW,
we intend to do the rust-pipewire transition later.

There is a newer helvum, 0.5.1, released today but maybe easiest to
wait for that update until we do the rust-pipewire transition.

Thank you,
Jeremy Bícha

Bug#1053161: A lot of warning tex.el and latex.el and font-latex.el and ...

[Janusz S . Bień]

On Thu, Sep 28 2023 at 12:15 -03, Marcelo Laia wrote:
> Hi Ikumi,
>
> Thank you so much!
>
> I filled a bug on Debian Bug Tracking.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053161
>
> Thank you!
>
> Marcelo Laia
>
> Enviado a partir de dispositivo móvel
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/auctex/attachments/20230928/e698c772/attachment.htm>

Install from ELPA?

Regards

JSB

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1053177: bullseye-pu: package xen/4.14.6-1

[Adam D. Barratt]

On Thu, 2023-09-28 at 18:27 +0200, Hans van Kranenburg wrote:
> Xen 4.14 support (and security support) has ended upstream. The
> upstream
> stable branch for version 4.14 is frozen now, and a final maintenance
> release version 4.14.6 has been released. We'd like to put this final
> update into Bullseye, to properly finish the Xen work for Bullseye.
> Also, a few security fixes (regarding CVE-2023-20593 CVE-2023-20569
> CVE-2022-40982) are included.
> 
> https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
> 

--- xen-4.14.5+94-ge49571868d/automation/scripts/qemu-smoke-x86-64.sh   
2023-03-21 13:07:44.0 +0100
+++ xen-4.14.6/automation/scripts/qemu-smoke-x86-64.sh  2023-08-07 
14:11:14.0 +0200
@@ -5,11 +5,6 @@
 # variant should be either pv or pvh
 variant=$1
 
-# Install QEMU
-export DEBIAN_FRONTENT=noninteractive
-apt-get -qy update
-apt-get -qy install qemu-system-x86

I realise this is an upstream change, but is it really intended to stop
installing QEMU in a QEMU smoke test?

Regards,

Adam

Bug#1053178: hg-git: incompatible with mercurial 6.5

[Julien Cristau]

Source: hg-git
Version: 1.0.2-1
Severity: grave
X-Debbugs-Cc: jcris...@debian.org

Hi,

hg-git looks like it needs an update for compatibility with current
mercurial, see e.g. 
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hg-git/38210693/log.gz

> ** Unknown exception encountered with possibly-broken third-party extension 
> "hggit" unknown (dulwich 0.21.6)
> ** which supports versions 6.4 of Mercurial.
> ** Please disable "hggit" and try your action again.
> ** If that fixes the bug please report it to 
> https://foss.heptapod.net/mercurial/hg-git/issues
> ** Python 3.11.5 (main, Aug 29 2023, 15:31:31) [GCC 13.2.0]
> ** Mercurial Distributed SCM (version 6.5.2)
> ** Extensions loaded: hggit unknown (dulwich 0.21.6)
> Traceback (most recent call last):
>   File "/usr/bin/hg", line 59, in 
> dispatch.run()
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 143, in 
> run
> status = dispatch(req)
>  ^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 232, in 
> dispatch
> status = _rundispatch(req)
>  ^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 276, in 
> _rundispatch
> ret = _runcatch(req) or 0
>   ^^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 457, in 
> _runcatch
> return _callcatch(ui, _runcatchfunc)
>^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 467, in 
> _callcatch
> return scmutil.callcatch(ui, func)
>^^^
>   File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 153, in 
> callcatch
> return func()
>^^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 447, in 
> _runcatchfunc
> return _dispatch(req)
>^^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1272, in 
> _dispatch
> return runcommand(
>^^^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 905, in 
> runcommand
> ret = _runcommand(ui, options, cmd, d)
>   
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1284, in 
> _runcommand
> return cmdfunc()
>^
>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1270, in 
> 
> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
> ^
>   File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1881, in check
> return func(*args, **kwargs)
>^
>   File "/usr/lib/python3/dist-packages/mercurial/commands.py", line 1992, in 
> clone
> r = hg.clone(
> ^
>   File "/usr/lib/python3/dist-packages/hggit/schemes.py", line 121, in clone
> srcpeer, destpeer = orig(*args, **opts)
> ^^^
>   File "/usr/lib/python3/dist-packages/mercurial/hg.py", line 727, in clone
> srcpeer = peer(ui, peeropts, src_path)
>   
>   File "/usr/lib/python3/dist-packages/hggit/schemes.py", line 112, in peer
> newpeer = orig(uiorrepo, *args, **opts)
>   ^
>   File "/usr/lib/python3/dist-packages/mercurial/hg.py", line 286, in peer
> peer = repo.peer(path=peer_path, remotehidden=remotehidden)
>
> TypeError: gitrepo.peer() got an unexpected keyword argument 'remotehidden'

Cheers,
Julien

Bug#1053175: colord-gtk: Team uploads without team maintenance

[Bastian Germann]

Am 28.09.23 um 18:35 schrieb Jeremy Bícha:

Why did you use that high of a severity? Is something specifically wrong with 
colord or colord-gtk?


Because it seems like a package hijack. But please lower as you please.

Bug#1053151: unblock: apt/2.7.6

[Julian Andres Klode]

On Thu, Sep 28, 2023 at 11:32:26AM +0200, Julian Andres Klode wrote:
> On Thu, Sep 28, 2023 at 11:22:44AM +0200, Julian Andres Klode wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: a...@packages.debian.org, j...@debian.org, 
> > debian-c...@lists.debian.org
> > Control: affects -1 + src:apt
> > 
> > Please unblock package apt (well remove the sramacher block)
> > 
> > apt 2.7.5 was blocked last week by sramacher because there were
> > arguments it broke chroots. The concerns have been addressed 
> > promptly in 2.7.6 by downgrading the error to 2 warnings.
> > 
> > Sebastian has been ignoring me since raising the issue and
> > instituting the block.
> 
> Please also override the age to 10 though, or remove the block
> on Monday / end of Sunday; it's mostly I want to have some
> confirmation, not an immediate unblock, I don't believe that
> is strictly necessary to migrate precisely now.
> 
> I do think this was an unnecessary use of power given that
> we did have an RC bug preventing the transition due to the
> added error and another one could have been filed instead
> if so wished.
> 
> For more context: apt 2.7.5 instituted an error on unmerged-usr
> systems to prevent people from running into broken maintainer
> scripts due to running on unsupported system layouts; apt
> 2.7.6 turned this into a warning before the Y/n prompt and
> a warning at the end of the run so that you can't miss it.

It seems there has been some misunderstanding on my side.

In my mind, I wanted to not "escalate" this to the team and
give Sebastian the chance to take care of this himself, which
is why I pinged him on Monday after not hearing since Wednesday
and then only send the email today after it's been a total of
8 days.

I understand now that I should have just asked the team directly,
and want to apologize if I caused any grief. The whole merged-usr
topic is pretty heated, and I realize that the way I mistakingly
framed this was not the most constructive way to make progress.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1053175: colord-gtk: Team uploads without team maintenance

[Jeremy Bícha]

On Thu, Sep 28, 2023 at 12:30 PM Bastian Germann  wrote:
> Source: colord-gtk
> Version: 0.3.0-1
> Severity: important
> X-Debbugs-Cc: jbi...@ubuntu.com
>
> Jeremy, you have uploaded several versions of colord-gtk as team uploads.
> The maintainer is not a team but Christopher James Halse Rogers who seems
> to be missing in action. Can you please clarify the state of this package?

Why did you use that high of a severity? Is something specifically
wrong with colord or colord-gtk?

Maybe we should formally move these packages to one of the Freedesktop
packaging teams though.

Thank you,
Jeremy Bícha

Bug#1053176: colord: Team upload without team maintenance

[Bastian Germann]

Source: colord
Version: 1.4.6-3
Severity: important
X-Debbugs-Cc: jbi...@ubuntu.com

Jeremy, you have uploaded a version of colord as team upload.
The maintainer is not a team but Christopher James Halse Rogers who seems
to be missing in action. Can you please clarify the state of this package?

Bug#1053175: colord-gtk: Team uploads without team maintenance

[Bastian Germann]

Source: colord-gtk
Version: 0.3.0-1
Severity: important
X-Debbugs-Cc: jbi...@ubuntu.com

Jeremy, you have uploaded several versions of colord-gtk as team uploads.
The maintainer is not a team but Christopher James Halse Rogers who seems
to be missing in action. Can you please clarify the state of this package?

Bug#1051910: mirror submission for ossmirror.mycloud.services

[Adam D. Barratt]

Hi,

mirrors@ is the correct address. I suspect people are simply busy.
(Well, I know people are.)

Regards,

Adam

On Thu, 2023-09-28 at 13:10 +0800, OSSMirror@OnboardCloud wrote:
> Hi Adam,
>  
> Thanks for sharing. Looks like we are almost near the ½ way mark to
> reaching 50 points today.
>  
> Separately, we have written in to mirr...@debian.org on 14/9 to ask
> about hosting official “.country.” mirrors but did not receive any
> reply till date. Do you know if we have written to the correct
> address or are you able to refer us to the correct party to
> discuss/review this?
>  
> Best regards,
>  
> -Original Message-
> From: Adam D. Barratt 
> Date: Tuesday, 26 September 2023 at 1:54 AM
> To: OSSMirror@OnboardCloud 
> Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>
> Subject: Re: Bug#1051910: mirror submission for
> ossmirror.mycloud.services
> 
> Hi,
>  
> The published list is generated by an automated process that checks
> on
> the status of the mirror in recent days. You can see the current
> status
> of your mirror at
> https://mirror-master.debian.org/status/mirror-info/ossmirror.mycloud.services.html
>  
> The score needs to reach at least 50 currently before the automation
> will consider including it.
>  
> Regards,
>  
> Adam
>  
> On Mon, 2023-09-25 at 09:52 +0800, OSSMirror@OnboardCloud wrote:
> > Hi Adam,
> >  
> > We were looking at the mirror listing and our mirror does not seem
> to
> > have been listed yet.
> >  
> > https://www.debian.org/mirror/list-full#SG
> >  
> >  
> > May I enquire do you know roughly how long does it take for the
> > mirror to be listed?
> >  
> > Best regards,
> >  
> > -Original Message-
> > From: OSSMirror@OnboardCloud 
> > Date: Sunday, 24 September 2023 at 3:31 AM
> > To: Adam D. Barratt 
> > Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>
> > Subject: Re: Bug#1051910: mirror submission for
> > ossmirror.mycloud.services
> >
> > Thanks Adam for the clarification and kind assistance!
> >  
> > On 24 Sep 2023, at 2:56 AM, Adam D. Barratt <
> a...@adam-barratt.org.uk
> > > wrote:
> >  
> > On Sun, 2023-09-24 at 01:57 +0800, OSSMirror@OnboardCloud wrote:
> > > Hi Adam,
> > >
> > > Thanks for the reply. Could you elaborate further what do you
> mean
> > as
> > > the /debian/ works:
> > >
> > > http://ossmirror.mycloud.services/debian/
> > >
> >  
> > Ah, right - I was mislead by the index of
> > http://ossmirror.mycloud.services implying that only /os/ existed,
> > and
> > didn't check for an alias.
> >  
> > Regards,
> >  
> > Adam
> >  
> >  
> >  
>  
>  
>  
>  

Bug#977674: Corrupt changes file when built with --source-only-changes

[Ferenc Wágner]

On Mon, 25 Jan 2021 17:45:29 +0100 Johannes Schauer Marin Rodrigues 
 wrote:

> The problem is, that when you combine --source-only-changes with --keyid, then
> debsign will be run twice (once for the normal changes file and once for the
> source-only changes file) and both times with --re-sign.  This means, that the
> second invocation will possibly also change the signature of files that were
> already processed by the first invocation and this means that the checksum of
> the first changes file doesn't match anymore.
> 
> To fix the problem, one might suggest to just run the second invocation of
> debsign with --no-re-sign so that everything that is already signed does not
> get changed and only those things that don't have a signature get signed.
> 
> But this triggers a bug in debsign where the dsc will not even be considered
> for signing if the buildinfo was already signed.

Since the buildinfo file of an upload contains the checksums of the dsc, this
behaviour makes sense, as signing the dsc would break the buildinfo.  On the
other hand for the same reason, if the buildinfo is signed the dsc should
already be signed as well.  In the sbuild --source --source-only-changes case
it most certainly will be, because the first debsign invocation signed it.
What use case would using --no-re-sign for the second call break?
-- 
Regards,
Feri.

Bug#1038240: chromium: Build with system libsrtp

[Soren Stoutner]

On Wednesday, September 27, 2023 8:02:43 PM MST Andres Salomon wrote:
> On Fri, 16 Jun 2023 11:15:32 -0700 Soren Stoutner 
> Really odd that I now get a "permission denied" error when I try to
> access that upstream bug. :(

I also get that, but when I log in it then allows me to see it.  Perhaps that 
is because I am the original submitter of the bug.  The bug is now labeled 
“Restrict-View-Google”.  Perhaps they are taking it seriously as a security 
bug?

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

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

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

[Andres Salomon]

Thanks! Can we also roll that fix into the freetype bookworm p-u? Looks 
pretty simple to me; just ensuring that sfnt->get_colr_glyph_paint 
isn't NULL before calling it.




On Thu, Sep 28 2023 at 11:33:45 AM -04:00:00, Ben Wagner 
 wrote:

I have been able to figure out what is going on. The crash is due to a
typo in FreeType which was recently fixed [0]. This change is also
needed. I can confirm in a local build that with this typo fix the
reported Chromium crash (in libfreetype.so.6) is fixed. To be clear,
this FreeType change [0] is needed in addition to the the COLRv1
disable [1].

[0] 

[1] 



On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner > wrote:


 I will take a look into this, but I am confused.
 FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
 function. This change will affect its behavior to always return 0
 (false) but that often happens anyway even without this change (most
 fonts don't have COLRv1 tables). For now it's fine to to revert the
 change as the original issue does not currently affect many users, 
but

 it is an issue that will need to be addressed.

 On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster > wrote:

 >
 > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
 >>
 >> Hi Andres,
 >>
 >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
 >> >
 >> > Control: affects -1 chromium
 >> >
 >> >
 >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
 >> > > Hi,
 >> > >
 >> > > In chromium source code, function 
SkScalerContext::GlyphMetrics

 >> > > SkScalerContext_FreeType::generateMetrics() will call
 >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 
exists. Somehow
 >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this 
patch applied, and

 >> > > chromium will not be able to run.
 >> >
 >> >
 >> > This smells like an ABI change that doesn't really seem 
appropriate for a point release update. I can patch 
TT_SUPPORT_COLRV1 out of bookworm's Chromium, but I wonder if any 
other packages are using it on bookworm?

 >> >
 >> > For the record, Skia has the following code:
 >> >
 >> > #ifdef TT_SUPPORT_COLRV1
 >> >
 >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if 
FT_STATIC_CAST is defined.

 >> > #if (((FREETYPE_MAJOR)  < 2) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
(FREETYPE_PATCH) < 1)) && \

 >> > !defined(FT_STATIC_CAST)
 >> > #undef TT_SUPPORT_COLRV1
 >> >
 >> >
 >> > So on bullseye (with freetype 2.10) it doesn't try to use 
COLRV1. On sid (with freetype 2.13) it will use COLRV1. If 
freetype's COLRV1 is going to remain disabled on bookworm via the 
proposed-update (with chromium being the only broken package), then 
I'll probably just bump that version check to only allow 
TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.

 >>
 >> FreeType 2.12.1 was released with experimental COLRv1 support 
enabled.
 >> This was unintentional, as the implementation shipped in this 
release

 >> was incomplete and incompatible with the final COLRv1 API.
 >>
 >> Upstream's intention was to enable COLRv1 support in FreeType 
2.13.0,

 >> which has a stable and complete COLRv1 API.
 >>
 >> I'm surprised Chromium actually used an experimental API, 
although

 >> this version check copied above seems like a bug.
 >>
 >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
 >> firefox*, godot and paraview are fine. Most of the openjdk-* 
packages

 >> aren't in bookworm.
 >
 >
 > After discussing the timing of Debian 12.2 with a release 
manager, I’ll revert the change shortly.

 >
 > Hugh

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Julien Cristau]

On Thu, Sep 28, 2023 at 12:42:27PM +0200, Santiago Vila wrote:
> El 28/9/23 a las 11:50, Julien Cristau escribió:
> > I still think that is absolutely the wrong thing to do, and makes
> > debootstrap more fragile for no good reason.
> 
> Julien, I believe you are mixing two different things here.
> 
> (A) What this bug is really about.
> 
> (B) What the effect of the bug is.
> 
> The bug (A) is that debootstrap, being the tool used to create chroots
> to build packages, has the responsibility of ensuring that
> the chroot is composed by build-essential packages only, and it
> should try hard not to install packages which are not build-essential.
> 
I guess more than mixing two different things I disagree that that is
debootstrap's responsibility, and so I disagree that that is a valid
bug.  In my view it's more important for debootstrap to reliably be able
to create chroots than some sort of philosophical purity about what is
included in said chroot.  Package priorities are how the archive tells
debootstrap which packages to install, and so since I don't see your (A)
as a bug, I'm saying if there's a bug it's (B) and belongs with the
archive.

I also think your argument, even if I went along with it, breaks down
when the apt package gets included, since apt is clearly not
build-essential, so by that logic we'd go back to the days where builds
used the host system's apt instead of including it in the chroot.

> In other words, the bug says that the algorithm followed by debootstrap
> to determine which packages should be installed is *flawed*.
> 
> Then there is the effect of the bug (B). The effect, obviously,
> is that we end up having non-build-essential packages in a chroot
> when using the buildd profile, which is definitely not ok.
> 
> Why do you suggest that we fix only the effects of the bug but not
> the bug itself? In other words: Why are you apparently mixing (A) and (B)
> as if they were the same thing?
> 
> True, the ftpmasters might change priorities so that debootstrap
> does the right thing by default, but this would be "by pure chance",
> as the algorithm would still be wrong.
> 

> Even if they change the priorities today, it would suffice that
> some day another essential package becomes non-essential but still required,
> and then we would have to wait another seven years for debootstrap
> to do the right thing again.
> 
There's no reason that would need to take seven years, so I don't know
what that point is about.

Cheers,
Julien

Bug#1049903: petsc: misbuild with gcc-13

[Drew Parsons]

Source: petsc
Followup-For: Bug #1049903
Control: severity 1049903 important
Control: tags 1049903 moreinfo

I said previously I'd apply the patch, but I wanted to check the
problem first.  No problem is showing at
https://tests.reproducible-builds.org/debian/rb-pkg/petsc.html
even in the experimental rebuilds.

I tried rebuilding in an experimental chroot on barriere.debian.org
porterbox (amd64), using libc6-dev 2.38-3 with 13.2.0-4.
No problem there either, even with libc6 version 28.

It sounds like some problem might have entered into ubuntu mantic.
I think it would be better to track down that problem rather than
papering over it and ignoring it.

Downgrading severity since the error is not reliably reproducible.

Is Ubuntu still affected by the problem?

Bug#1053174: Block Ben Tris

[Christoph Berg]

Package: bugs.debian.org

Hi,

we keep seeing non-actionable bug reports from Ben Tris that look like
this:

> Subject: Re: Bug#1052524: postgresql-16: Ow that hurts! On the short 
> description.
>
> Package: postgresql-16
> Severity: minor
> X-Debbugs-Cc: benatt...@gezapig.nl
> 
> Dear Maintainer,
> 
> Is it really not The World's Most Advanced Relational Database?
> Please, do not tell me it is true, it hurts me so badly.
> 
> Please change the short description to a friendlier one. (while you're doing,
> please also remove free and open-source (sounds pretty dumb while you're in
> main) from the long description?  Else I have to make a separate bug report 
> for
> that)

People (including me) have been trying to tell him to stop this,
without any reaction.

Please block Ben Tris from filing any new bugs, it's just a waste of
time for maintainers.

Christoph

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

[Ben Wagner]

I have been able to figure out what is going on. The crash is due to a
typo in FreeType which was recently fixed [0]. This change is also
needed. I can confirm in a local build that with this typo fix the
reported Chromium crash (in libfreetype.so.6) is fixed. To be clear,
this FreeType change [0] is needed in addition to the the COLRv1
disable [1].

[0] 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/16f311d72582c117796a23e22074fe9624760ee1
[1] 
https://salsa.debian.org/debian/freetype/-/commit/f65637c7f84fa2ccfb14c11d0ed0f315fe83636d

On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner  wrote:
>
> I will take a look into this, but I am confused.
> FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
> function. This change will affect its behavior to always return 0
> (false) but that often happens anyway even without this change (most
> fonts don't have COLRv1 tables). For now it's fine to to revert the
> change as the original issue does not currently affect many users, but
> it is an issue that will need to be addressed.
>
> On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster  wrote:
> >
> > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
> >>
> >> Hi Andres,
> >>
> >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
> >> >
> >> > Control: affects -1 chromium
> >> >
> >> >
> >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
> >> > > Hi,
> >> > >
> >> > > In chromium source code, function SkScalerContext::GlyphMetrics
> >> > > SkScalerContext_FreeType::generateMetrics() will call
> >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, 
> >> > > and
> >> > > chromium will not be able to run.
> >> >
> >> >
> >> > This smells like an ABI change that doesn't really seem appropriate for 
> >> > a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
> >> > Chromium, but I wonder if any other packages are using it on bookworm?
> >> >
> >> > For the record, Skia has the following code:
> >> >
> >> > #ifdef TT_SUPPORT_COLRV1
> >> >
> >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST 
> >> > is defined.
> >> > #if (((FREETYPE_MAJOR)  < 2) || \
> >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
> >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
> >> > (FREETYPE_PATCH) < 1)) && \
> >> > !defined(FT_STATIC_CAST)
> >> > #undef TT_SUPPORT_COLRV1
> >> >
> >> >
> >> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid 
> >> > (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going 
> >> > to remain disabled on bookworm via the proposed-update (with chromium 
> >> > being the only broken package), then I'll probably just bump that 
> >> > version check to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.
> >>
> >> FreeType 2.12.1 was released with experimental COLRv1 support enabled.
> >> This was unintentional, as the implementation shipped in this release
> >> was incomplete and incompatible with the final COLRv1 API.
> >>
> >> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0,
> >> which has a stable and complete COLRv1 API.
> >>
> >> I'm surprised Chromium actually used an experimental API, although
> >> this version check copied above seems like a bug.
> >>
> >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
> >> firefox*, godot and paraview are fine. Most of the openjdk-* packages
> >> aren't in bookworm.
> >
> >
> > After discussing the timing of Debian 12.2 with a release manager, I’ll 
> > revert the change shortly.
> >
> > Hugh

Bug#1052243: dkms: Signature keys unexpectedly overridden

[Andreas Beckmann]

Control: tag -1 - moreinfo + upstream
Control: severity -1 normal

On 28/09/2023 17.05, Tobias Bossert wrote:

 > Did both files exist?

Indeed, in my case the `.key` existed while the one meant for the 
certificate had a different extension...So as you confirmed, the 
observed "overwriting" behavior is intended. However, I think my point 
about not expecting this is still valid -  as the neither the comment in 
the `/etc/dkms/framework.conf` nor the man page does mention this with 
any word.


Thanks for confirming.
Downgrading the severity since this is only a documentation issue.

Andreas

Bug#1052059: bookworm-pu?

[Guilhem Moulin]

On Thu, 28 Sep 2023 at 18:26:07 +0300, Martin Dosch via 
Pkg-roundcube-maintainers wrote:
> Are there plans to also upload it to stable-pu?

See #1052629

-- 
Guilhem.

Bug#1052059: bookworm-pu?

[Martin Dosch]

Dear Guilhem,

I just realized that it was uploaded for oo-stable and o-stable-pu.
Are there plans to also upload it to stable-pu?

Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1053167: Please remove librbd-dev build-depends on 32 bits arch

[Martin Steigerwald]

Hi Thomas.

Am Donnerstag, dem 28.09.2023 um 16:38 +0200 schrieb Thomas Goirand:
> So please remove librbd-dev in build-depends of your package for all
> 32 bits arch, and remove Ceph support in all 32 bits binaries. I'll
> upload Ceph with Build-Depends: architecture-is-64-bit as soon as this
> is done
> for the 4 affected packages:
> - fio
> - libvirt
> - tcmu
> - qemu

I am quite busy.

First day I can possibly look into that is next Wednesday. I hope I
manage to get to it on that day. If you like you can provide a merge
request on Salsa, but as it is a minor change I should be able to get to
it next Wednesday as long as I have a little time slot for it.

Ciao,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Jonas Hasselberg
 •
Chris Hudson
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1052243: dkms: Signature keys unexpectedly overridden

[Tobias Bossert]

Hi Andreas

> Did both files exist?

Indeed, in my case the `.key` existed while the one meant for the 
certificate had a different extension...So as you confirmed, the 
observed "overwriting" behavior is intended. However, I think my point  
about not expecting this is still valid -  as the neither the comment in 
the `/etc/dkms/framework.conf` nor the man page does mention this with 
any word.


Tobias

On 28.09.23 15:49, Andreas Beckmann wrote:

Control: tag -1 moreinfo

On Tue, 19 Sep 2023 13:37:01 +0200 Tobias Bossert 
 wrote:

Package: dkms
Version: 3.0.11-3


Enrolled my own secureboot key chain (PK, KEK, db) and wanted dkms to 
sign kernel modules automatically.


I tried to reproduce that in a sid chroot by setting
    mok_signing_key=/etc/dkms/mok.key
    mok_certificate=/etc/dkms/mok.pub
in framework.conf and created them with
    openssl req -new -x509 -nodes -days 36500 \
-subj "/CN=DKMS module signing key" -newkey rsa:2048 \
-keyout /etc/dkms/mok.key -outform DER -out /etc/dkms/mok.pub

Then I installed linux-headers-amd64 and dkms-test-dkms.
That didn't modify my keys.

* What exactly did you do (or not do) that was effective (or 
ineffective)?


Set `mok_signing_key=` and `mok_certificate` in 
`/etc/dkms/framework.conf` to my DB.key/DB.crt and then installed the 
`nvidia-driver` using apt.


Did both files exist?


* What was the outcome of this action?

My DB.key and DB.crt were overridden by some new keys.


This should only have happened if one of the files was missing.
And that I can reproduce in my chroot, if I rename one of the files, a 
new pair gets generated.



* What outcome did you expect instead?

Even if my configuration is wrong, I would never expect that setting 
`mok_signing_key=` overriddes anything.


dkms doesn't know where the mok_signing_key= and mok_certificate= 
settings come from. The values could be

* builtin defaults
* distribution defaults set in framework.conf
* user customized values set in framework.conf
* empty, which causes a fallback to builtin defaults

If either the .key or the .crt file is missing, dkms will generate a 
new .key and self-signed .crt in the locations pointed to by 
mok_signing_key= and mok_certificate=



Andreas

Bug#1053173: Please remove librados-dev from build-depends on all 32 bits arch

[Thomas Goirand]

Source: eckit
Version: 1.20.2-1
Severity: important

Hi,

I'd like to remove 32 bits support from Ceph, because upstream makes some
64 bits assumptions a bit everywhere, because it's not tested in upstream
CI, and because it is increasingly difficult to build Ceph on a smaller
addressing footprint (we used to have many tricks to reduce the build footprint
that isn't sustainable in the long run).

So please remove librados-dev in build-depends of your package for all 32
bits arch, and remove Ceph support in all 32 bits binaries. I'll upload
Ceph with Build-Depends: architecture-is-64-bit as soon as this is done
for the affected packages:
- fio
- libvirt
- tcmu
- qemu
- eckit
- fdb
- nfs-ganesha
- uwsgi
- xrootd

Cheers,

Thomas Goirand (zigo)

Bug#1053172: Please remove librbd-dev build-depends on all 32 bits arch

[Thomas Goirand]

Package: qemu
Severity: important

Hi,

I'd like to remove 32 bits support from Ceph, because upstream makes some
64 bits assumptions a bit everywhere, because it's not tested in upstream
CI, and because it is increasingly difficult to build Ceph on a smaller
addressing footprint (we used to have many tricks to reduce the build footprint
that isn't sustainable in the long run).

So please remove librbd-dev in build-depends of your package for all 32
bits arch, and remove Ceph support in all 32 bits binaries. I'll upload
Ceph with Build-Depends: architecture-is-64-bit as soon as this is done
for the 4 affected packages:
- fio
- libvirt
- tcmu
- qemu

Cheers,

Thomas Goirand (zigo)

Bug#1053171: smplayer has one incompatibility with mpv (Bookworm)

[Alf]

Package: smplayer
Version: 22.7.0~ds0-1 amd64
Severity: normal


Generally smplayer works fine with installed mpv 0.35.0-3 in Bookworm.
However there is one use case where I need a dirty hack to get it working:

Watching TV via dvb-c and importing the channels.conf (generated by w-scan).

When configuring smplayer via the GUI by
Options -> Settings -> TV and Radio -> Search channels on start-up
it does not find the working channels.conf in ~/.config/mpv/channels.conf.
I could not find any file/location where I could configure the search path 
manually.
Luckily the "mouse over" on this item displays a bubble help indicating
that it is looking for the channels.conf in ~/.mplayer directory.
This path should be updated to search both mpv's and mplayer's configuration 
directories.

So I created the not existing directory (mkdir ~/.mplayer) and set a symlink
 ln -s ~/.config/mpv/channels.conf ~/.mplayer/

That way smplayer lets me select channels and watch TV as expected.

In other configuration items there is no need and smplayer uses mpv as an 
alternative
to mplayer without any tricks.


Regards,
Alf

Bug#1051781: python3-h5py: where is the egg files

[Drew Parsons]

Source: h5py
Followup-For: Bug #1051781

I'm reorganising the package with separate distinfo metadata for the
different variants.  I think this will fix your problem

Bug#956102: Privacy Compliance Department

[Privacy Notification]

Disclaimer. This e-mail and its attachments are addressed to the named addressee(s) only and are intended exclusively for the use by the addressee or the entity to which it is addressed. If you are not the named addressee or authorized to receive this message on behalf of the named addressee, any disclosure, reproduction or use of this communication is strictly prohibited and may be unlawful. If you received this message in error, please notify the sender immediately and delete this message and its attachments from your system immediately. The information contained in this e-mail may be confidential, privileged or proprietary information, and may be subject to intellectual property rights.

bugs.debian.org
Description: Binary data

Bug#1038660: Privacy Compliance Department

[Privacy Notification]

Disclaimer. This e-mail and its attachments are addressed to the named addressee(s) only and are intended exclusively for the use by the addressee or the entity to which it is addressed. If you are not the named addressee or authorized to receive this message on behalf of the named addressee, any disclosure, reproduction or use of this communication is strictly prohibited and may be unlawful. If you received this message in error, please notify the sender immediately and delete this message and its attachments from your system immediately. The information contained in this e-mail may be confidential, privileged or proprietary information, and may be subject to intellectual property rights.

bugs.debian.org
Description: Binary data

Bug#1021816: Privacy Compliance Department

[Privacy Notification]

Disclaimer. This e-mail and its attachments are addressed to the named addressee(s) only and are intended exclusively for the use by the addressee or the entity to which it is addressed. If you are not the named addressee or authorized to receive this message on behalf of the named addressee, any disclosure, reproduction or use of this communication is strictly prohibited and may be unlawful. If you received this message in error, please notify the sender immediately and delete this message and its attachments from your system immediately. The information contained in this e-mail may be confidential, privileged or proprietary information, and may be subject to intellectual property rights.

bugs.debian.org
Description: Binary data

Bug#1053170: Apache NOTICE file missing from binary package

[John Thorvald Wodder II]

Package: bat
Version: 0.23.0-4
Severity: serious

bat's upstream source and the rust-bat_0.23.0.orig.tar.gz file both contain a
NOTICE file which, per the packages's Apache 2.0 license, must be preserved in
derivative works.  However, this NOTICE file is not present in the binary .deb
packages distributed by Debian.

Note that bat itself embeds the text of the NOTICE file in its own binary, and
the text is displayed when running `batcat --acknowledgements`.  However, Paul
Wise has stated on the debian-legal mailing list that the NOTICE should still
be distributed as a file in the .deb packages:

https://lists.debian.org/debian-legal/2023/09/msg00012.html

Bug#1053169: Please remove librbd-dev build-depends on all 32 bits arch

[Thomas Goirand]

Source: tcmu
Version: 1.5.4-4.1
Severity: important

Hi,

I'd like to remove 32 bits support from Ceph, because upstream makes some
64 bits assumptions a bit everywhere, because it's not tested in upstream
CI, and because it is increasingly difficult to build Ceph on a smaller
addressing footprint (we used to have many tricks to reduce the build footprint
that isn't sustainable in the long run).

So please remove librbd-dev in build-depends of your package for all 32
bits arch, and remove Ceph support in all 32 bits binaries. I'll upload
Ceph with Build-Depends: architecture-is-64-bit as soon as this is done
for the 4 affected packages:
- fio
- libvirt
- tcmu
- qemu

Cheers,

Thomas Goirand (zigo)