Bug#995341: Highly inappropriate behavior which the RT should be aware of

2021-10-03 Thread Holger Levsen 
On Fri, Oct 01, 2021 at 11:48:48AM +0200, Diederik de Haas wrote:
> I want to make sure that you're aware of what I consider HIGHLY inappropriate 
> behavior by Chuck where he is trying to sidestep/override the Xen maintainers 
> by filing this bug directly to the release.debian.org pseudo package.

why don't you give Chuck more slack and assume he filed this bug the way he did
with the best intentions? really.

and even if that would be wrong, treating it this way would not be wrong. :)


-- 
cheers,
Holger

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

Fischers Fritz fischt Plastik.


signature.asc
Description: PGP signature

Bug#995341: Highly inappropriate behavior which the RT should be aware of

2021-10-03 Thread Chuck Zmudzinski 

On 10/3/2021 11:21 AM, Chuck Zmudzinski wrote:

On 10/1/2021 5:48 AM, Diederik de Haas wrote:
We've already identified a possible fix, which I can point to if so 
desired,


I think the fix referred to is here:

https://salsa.debian.org/xen-team/debian-xen/-/tree/knorrie/for-diederik-3-fixes 



AFAICT, this fix involves adding three more commits


Slight correction - it actually looks like this proposal involves 3 fixes
for diederik, but it actually involves five new commits from the upstream
unstable Xen 4.16 branch, as indicated by the five new patches in the
debian/patches directory.


from the
unstable upstream Xen 4.16 branch in addition to the nine
commits already added from unstable upstream Xen 4.16
to provide better support for the Raspberry Pi 4 but with
the unintended side effect of #994899.

I do not object to this fix for Debian's current unstable
distribution. However, this bug concerns Debian's
current stable version, bullseye, not sid/unstable.

I would respectfully disagree with the Release Team's
decision to migrate the aforementioned fix from the
unstable release to bullseye unless the fix is accepted
by the upstream Xen project in its stable 4.14 branch and
its future stable point releases 4.14.x.

IMO, the debdiff attached to message #30:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341#30

is a better suited fix more in accordance with the stability/security
requirements of a typical Debian stable release.

Regards,

Chuck Zmudzinski

Bug#993824: transition: libqalculate

2021-10-03 Thread Sebastian Ramacher 
Hi Norbert, Phil

On 2021-09-27 10:22:31 +0900, Norbert Preining wrote:
> Hi Phil,
> 
> I pushed a commit with initial changes for libqalculate20-data dummy
> package. Please take a look.

Any news regarding libqalculate20-data?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

2021-10-03 Thread Chuck Zmudzinski 
The original submitter has proposed a fix (see messages #30 and #35). 
Another contributor to this report has indicated the package maintainer 
does not endorse the submitter of the bug's proposed fix and is working 
on another fix (see messages #40 and #65). The original submitter of the 
bug thinks the possible solution proposed in messages #40 and #65 does 
not meet the typical stability/security requirements for a typical 
Debian stable release.

Bug#995341: Highly inappropriate behavior which the RT should be aware of

2021-10-03 Thread Chuck Zmudzinski 

On 10/1/2021 5:48 AM, Diederik de Haas wrote:

We've already identified a possible fix, which I can point to if so desired,


I think the fix referred to is here:

https://salsa.debian.org/xen-team/debian-xen/-/tree/knorrie/for-diederik-3-fixes

AFAICT, this fix involves adding three more commits from the
unstable upstream Xen 4.16 branch in addition to the nine
commits already added from unstable upstream Xen 4.16
to provide better support for the Raspberry Pi 4 but with
the unintended side effect of #994899.

I do not object to this fix for Debian's current unstable
distribution. However, this bug concerns Debian's
current stable version, bullseye, not sid/unstable.

I would respectfully disagree with the Release Team's
decision to migrate the aforementioned fix from the
unstable release to bullseye unless the fix is accepted
by the upstream Xen project in its stable 4.14 branch and
its future stable point releases 4.14.x.

IMO, the debdiff attached to message #30:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341#30

is a better suited fix more in accordance with the stability/security
requirements of a typical Debian stable release.

Regards,

Chuck Zmudzinski

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

2021-10-03 Thread Adrian Bunk 
On Sun, Oct 03, 2021 at 10:21:16AM -0400, Reinhard Tartler wrote:
>...
> The consistent OOM is surprising given that you state that the worker has
> 250GB of RAM. Looking at the logs,
> I note that the tests are being passed the option -p 160 by the dh-golang
> helper, so it will build
> and run test executables concurrently. That confirms to me that we are
> indeed running on these 250GB/160 core workers.
>...

No matter the amount of RAM, you will always have the limitation of
<= 4 GB address space for a process on 32bit.[1]

Starting one process per core is not a problem even if each process
uses takes 1 GB of RAM.[2]

Starting one thread per core in the same process would not be suprising
to fail, 20 MB per thread would suffice for running out of address space.

> regards,
> Reinhard

cu
Adrian

[1] 32bit arm has 3 GB address space
[2] 160 g++ processes might be a problem with only 1.5 GB RAM per core

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

2021-10-03 Thread Paul Gevers 
Hi Reinhard,

On 03-10-2021 16:21, Reinhard Tartler wrote:
> Note that the test doesn't do xz, but zstd compression,
> cf. https://github.com/klauspost/compress/blob/master/zstd/README.md
> 
> so your comment regarding --threads=0 does not seem to apply? -- not
> sure, please let me know what you think.

I was just using $(xz --threads=0) as an example, not claiming that that
was what's happening. Just that large amounts of cores and/or memory can
trigger weird "bugs".

> The consistent OOM is surprising given that you state that the worker
> has 250GB of RAM. Looking at the logs,
> I note that the tests are being passed the option -p 160 by the
> dh-golang helper, so it will build
> and run test executables concurrently. That confirms to me that we are
> indeed running on these 250GB/160 core workers.

We only have one armhf host, so *all* armhf tests are run there. I'm
also not seeing this problem back in the logs:
https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html.
But maybe the incident is too short to be caught by the once per 5
minutes poll.

> Is it possible that armhf is setting up ulimits that limits the amount
> of memory the test may allocate?

root@ci-worker-armel-01:~# ulimit
unlimited

> As far as I understand, all golang packages use autodep8 to declare the
> tests,
> which doesn't support adding the Architecture field.

I think you're right, but maybe we should fix autodep8 to enable the
change like the other overwrites in section `PACKAGE-SPECIFIC
CONFIGURATION` of $(man autodep8).

> In order to get
> around this,
> I guess I could remove the Testsuite field from debian/control and add a
> debian/tests/control that looks similar to what autodep8 generates, but adds
> the Architecture: !armhf  restriction.

Maybe until autodep8 is fixed? I fear that this may cause future trouble
if/when autodep8 support for golang gets updated.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

NEW changes in stable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: pyx3_0.15-3+deb11u1_mips64el-buildd.changes
  ACCEPT

NEW changes in oldstable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_10.3+deb10u11_mips64el-buildd.changes
  ACCEPT

NEW changes in stable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_11.1+deb11u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_mipsel-buildd.changes
  ACCEPT

Processed: set summary message #995341

2021-10-03 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> summary 995341 70
Summary recorded from message bug 995341 message 70
> thank you
Stopping processing here.

Please contact me if you need assistance.
-- 
995341: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995341
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

NEW changes in oldstable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_10.3+deb10u11_amd64-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_arm64-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_armel-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_armhf-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_i386-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_mips-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_mipsel-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_ppc64el-buildd.changes
  ACCEPT
Processing changes file: base-files_10.3+deb10u11_s390x-buildd.changes
  ACCEPT

NEW changes in stable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_11.1+deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_armel-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: base-files_11.1+deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_armel-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_s390x-buildd.changes
  ACCEPT

Bug#995620: nmu: tripwire_2.4.3.7-3+b3

2021-10-03 Thread Alberto Gonzalez Iniesta 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu tripwire_2.4.3.7-3+b3 . ANY . unstable . -m "Rebuild with new libc (Closes 
#994910)"

Thanks.

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

2021-10-03 Thread Reinhard Tartler 
Hi Paul,

thanks for getting back to me so quickly.

Adding Nilesh and Shengjing, we were discussing this issue on a separate,
private email conversation.

On Wed, Sep 29, 2021 at 2:45 PM Paul Gevers  wrote:

> Hi Reinhard,
>
> On 29-09-2021 02:56, Reinhard Tartler wrote:
> > Please unblock package golang-github-klauspost-compress
> >
> > The problem is with autopkgtest, on armel and armhf, the test
> > machines frequently run out of memory when executing the extensive
> > test suite.
>
> As our armhf worker has the most memory of all our workers (250GB) and
> most cores (160), that would hint at an very bad bug on armhf/armel, or
> bad parameters for e.g. xz (--threads=0 recently showed up as behaving
> badly with 160 cores).
>

So, after some cleanups in the package and a backported patch from upstream
that increases the test timeout from 2 to 4 minutes (and this consistently
fixes
failures on i386), we now have two runs in a row where the armhf builder
OOM:

https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-klauspost-compress/15714893/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-klauspost-compress/15733957/log.gz

Note that the test doesn't do xz, but zstd compression, cf.
https://github.com/klauspost/compress/blob/master/zstd/README.md
so your comment regarding --threads=0 does not seem to apply? -- not sure,
please let me know what you think.

The consistent OOM is surprising given that you state that the worker has
250GB of RAM. Looking at the logs,
I note that the tests are being passed the option -p 160 by the dh-golang
helper, so it will build
and run test executables concurrently. That confirms to me that we are
indeed running on these 250GB/160 core workers.

Is it possible that armhf is setting up ulimits that limits the amount of
memory the test may allocate?

The thing is, I am able to pass the tests just fine on the on the porterbox
abel.debian.org, which
has significantly fewer cores (4) and memory (4GB).

Maybe we need to limit the concurrent builds/test in debian/rules so that
it never users more than
let's say 8 cores or something?


>
> > I suggest the folling hints:
> >
> > force-badtest golang-github-klauspost-compress/*/armhf
> > force-badtest golang-github-klauspost-compress/*/armel
>
> If it's just to have golang-github-klauspost-compress migrate,
> force-skiptest would be better. But, as you want
> golang-github-klauspost-compress itself to migrate, I rather have it
> that you add an Architecture field to the test declaration and skip
> armel and armhf. Flaky tests are considered RC.
>

As far as I understand, all golang packages use autodep8 to declare the
tests,
which doesn't support adding the Architecture field. In order to get around
this,
I guess I could remove the Testsuite field from debian/control and add a
debian/tests/control that looks similar to what autodep8 generates, but adds
the Architecture: !armhf  restriction.

Is that best practice or am I overlooking something?

-- 
regards,
Reinhard

Bug#995630: transition: gupnp

2021-10-03 Thread Sebastian Ramacher 
Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gupnp.html

On 2021-10-03 08:11:25 -0400, Jeremy Bicha wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: gu...@packages.debain.org
> Severity: normal
> 
> I request permission to do the gupnp transition. I successfully test
> built all the source packages from the auto transition tracker on my
> computer today against the updated gupnp. We can do binNMUs for all of
> them.
> 
> https://release.debian.org/transitions/html/auto-gupnp.html

Please go ahead

Cheers

> 
> Thank you,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Processed: Re: Bug#995630: transition: gupnp

2021-10-03 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 confirmed
Bug #995630 [release.debian.org] transition: gupnp
Added tag(s) confirmed.
> forwarded -1 https://release.debian.org/transitions/html/auto-gupnp.html
Bug #995630 [release.debian.org] transition: gupnp
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/auto-gupnp.html'.

-- 
995630: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995630
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995636: transition: openssl

2021-10-03 Thread Kurt Roeckx 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

We would like to transition to OpenSSL 3.0.0. It's currently in
experimental. It has an soname change, so the binary packages got
renamed and binNMUs will be required.

We did a rebuild of packages and currently have 105 packages
that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started
filing bugs for that:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0


Kurt

NEW changes in oldstable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_10.3+deb10u11_source.changes
  ACCEPT

NEW changes in stable-new

2021-10-03 Thread Debian FTP Masters 
Processing changes file: base-files_11.1+deb11u1_source.changes
  ACCEPT
Processing changes file: pyx3_0.15-3+deb11u1_source.changes
  ACCEPT

Bug#995630: transition: gupnp

2021-10-03 Thread Jeremy Bicha 
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gu...@packages.debain.org
Severity: normal

I request permission to do the gupnp transition. I successfully test
built all the source packages from the auto transition tracker on my
computer today against the updated gupnp. We can do binNMUs for all of
them.

https://release.debian.org/transitions/html/auto-gupnp.html

Thank you,
Jeremy Bicha

Processed: pyx3 0.15-3+deb11u1 flagged for acceptance

2021-10-03 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> package release.debian.org
Limiting to bugs with field 'package' containing at least one of 
'release.debian.org'
Limit currently set to 'package':'release.debian.org'

> tags 993639 = bullseye pending
Bug #993639 [release.debian.org] bullseye-pu: package pyx3/0.15-3+deb11u1
Added tag(s) pending; removed tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
993639: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993639
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#993639: pyx3 0.15-3+deb11u1 flagged for acceptance

2021-10-03 Thread Adam D Barratt 
package release.debian.org
tags 993639 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: pyx3
Version: 0.15-3+deb11u1

Explanation: fix horizontal font alignment issue with texlive 2020

Uploading linux (5.14.9-1)

2021-10-03 Thread Salvatore Bonaccorso 
Hi

I would like to upload linux version 5.14.9-1 today to unstable, which
imports the stable versions from 5.14.7 up to 5.14.9. An ABI bump was
not tried to be avoided, there were enough upstream changes making it
warranted.  The upstream changes include a fix for #995491.

The additional packaging changes are

   * Bump ABI to 2
   * ext4: limit the number of blocks in one ADD_RANGE TLV (Closes: #995425)

Regards,
Salvatore


signature.asc
Description: PGP signature