Bug#1053800: transition: libgit2

[Peter Green]

The Rust Team did not react.


Too bad. Please raise the bug to RC.


Apologies for not engaging with this sooner, I had mentally
filed it as "deal with this once the cargo update is done"
but the cargo update has been taking a lot longer than hoped.

I've uploaded a new version of the rust bindings, this also
involved updating a bunch of other rust packages for the
new version of the rust bindings.

Going through the packages on the transition tracker.
that currently show red x's on architectures other than
mips64el and that have something to do with rust.

git-delta (sid only):
Maintained by Jonas. Will need a sourcefull upload for
semver bumps, I will file a bug once the packages it
depends on are built.

rust-bat:
I've uploaded a fixed package.

rust-cargo-c:
Uses the rust git bindings indirectly, a binnmu should
suffice here.

rust-cargo-outdated:
Doesn't enforce an upper limit on the version of the
git bindings, a binnmu should suffice here.

rust-debcargo:
I've uploaded a fixed package.

rust-exa:
I've Uploaded a fixed package.

rust-ripasso-cursive:
Suffers from unrelated FTBFS issue.

cargo:
f_g has uploaded a fix.

re: rust-grep-regex REMOVED from testing

[Peter Green]

  Previous version: 0.1.11-1
  Current version:  (not in testing)
  Hint: 
# 2023-11-04
# blocks lots of packages from migrating
# 1053431


Assuming your goal was to allow rust-regex and friends to
migrate to testing, you will also want to set removal
hints for rust-matchers and rust-loom.

Re: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Peter Green]

On 28/04/2023 06:05, Helmut Grohne wrote:

Can you go into more detail as to what you mean with "don't support
version ranges"?


You can place a lower bound on the version, place an upper bound
on the version or constrain to a precise version. But you can't
constrain to a range of versions.


  In principle, you could declare the Replacs to be
slightly broader than necessary (i.e. instead of declaring against the
specific range, you can replace all old packages). Do you agree that
this is feasible?

It would indeed be feasible to continue declaring the breaks
against the virtual package, while declaring the replaces
against the physical package.

My only concern is this may bring in bug reports complaining
about a replaces without a matching breaks. Tehcnically I
don't see anything in policy actually forbidding such but
it goes against the norm.

  5. In a different bug, Samuel Thibault observed that the target package
 was not part of bullseye. As such, an upgrade scenario involving it
 was unlikely. All of the 6 affected librus-*-dev packages are not
 part of bullseye. We could argue that the risk of these effects
 showing up in practice is not big enough to warrant an invasive fix.
 Rather, we'd downgrade them to important (and upgrade to serious
 when we see them in the wild) and close them after bookworm (since
 we don't support skip upgrades).


While the target packages aren't part of bullseye, they could well end up pulled
in as part of an upgrade, since the purpose of these packages is to continue
providing older versions of a crate when the main package of the crate is
upgraded.

It then comes down to unpack order, if the package manager unpacks the upgrade
before the new package then all is cool. OTOH if the new package is unpacked
first you would have a conflict.

What I don't know is how real-world package managers handle installation
order and thus how likely seeing the "bad" ordering is in practice.

The issue won't go away after bookworm. These particular packages won't be
affected for a bookworm->trixie upgrade but future packages almost certainly
will be.

On the other hand these are packages that are mostly used as
build-dependencies and are rarely installed on end-user systems.


Do any other members of the rust team have an opinion on this? I'm
personally inclined towards option 1 and intend to implement it if
noone objects in the next couple of days.

Let me know if you see 4 as a viable option.

I would say it's viable.

Do the release team have an opinion on this? It looks like only one of
the packages involved (rust-env-logger-0.7) is a key package.

I filed these as serious, because these are policy violations with a
trivial fix. You made it quite clear that the premise of the fix being
trivial is false here. If the cure is worse than the symptoms


I don't think the cure is worse than the symptoms.

Re: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Peter Green]

Summarising a number of bug reports by Helmut Ghrone:


Please ensure that librust---dev has sufficient Breaks and 
Replaces declarations.


The issue specifically appears to be that the breaks+replaces are declared
against a virtual package, it seems dpkg is honoring the breaks against the
virtual package but not the replaces. So it correctly marks the package from
stable as broken, but fails to actually unpack the package from testing.

Declaring against the physical package is also problematic becase Debian package
relationships don't support version ranges. What this would likely mean in
practice is it would be possible to co-install the "current" semver alongside
one previous semver, but it would not be possible to co-install two different
previous semvers.

Another option may be to use "Conflicts" instead of "Breaks". This should force
the old package to be upgraded or removed before the semver-specific package
can be unpacked.

I feel the timing of these bugs is very unfortunate. I don't object to
people running QA checks, but it's generally easier to deal with bugs if
they are reported earlier in the freeze process. The timing of these bugs
leaves little time for discussion if we are to get the fixes in before the
full freeze.

As I see it we have a few options to deal with this for bookworm.

1. Make debcargo Use Conflicts instead of Breaks.
2. Make debcargo declare Breaks/Replaces against the physical package
   version using a << dependency. This will allow the non-semver suffixed
   package to be installed alongside one semver-suffixed package, but with
   our current virtual packages scheme would not allow two semver-suffixed
   packages of the same crate to be coinstalled.
3. Add manual breaks/replaces for the versions in bullseye, this will
   paper over the issue for bullseye-bookworm upgrades, but is not a long
   term fix.

Do any other members of the rust team have an opinion on this? I'm
personally inclined towards option 1 and intend to implement it if
noone objects in the next couple of days.

Do the release team have an opinion on this? It looks like only one of
the packages involved (rust-env-logger-0.7) is a key package.

reason for removal of zeroc-ice on armhf and arm64.

[Peter Green]

I recently became aware that mumble's build-dependencies were no longer
satisfiable on armhf due to a missing zeroc-ice. I looked at the build
logs for zeroc-ice and all were green. So I looked at the removal log
and found the following.


[Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

libzeroc-ice-dev |  3.7.8-2.1 | arm64, armhf
libzeroc-ice3.7 |  3.7.8-2.1 | arm64, armhf
libzeroc-icestorm3.7 |  3.7.8-2.1 | arm64, armhf
mumble-server |1.3.4-4 | arm64, armhf
php-zeroc-ice |  3.7.8-2.1 | arm64, armhf
python3-zeroc-ice |  3.7.8-2.1 | arm64, armhf
zeroc-glacier2 |  3.7.8-2.1 | arm64, armhf
zeroc-ice-compilers |  3.7.8-2.1 | arm64, armhf
zeroc-ice-utils |  3.7.8-2.1 | arm64, armhf
zeroc-icebox |  3.7.8-2.1 | arm64, armhf
zeroc-icebridge |  3.7.8-2.1 | arm64, armhf
zeroc-icegrid |  3.7.8-2.1 | arm64, armhf
zeroc-icepatch2 |  3.7.8-2.1 | arm64, armhf
Closed bugs: 1031160

--- Reason ---
RoQA; openjfx no longer builds on arm64 and armhf, build-depends not available


This strikes me as strange in a couple of ways.

1. The only relationships of zeroc-ice to openjfx are in build-depends-indep
   and in the binary dependencies of an arch all package. Afaict it is perfectly
   normal for build-depends-indep and the binary dependencies of arch all
   packages to only be satisfiable on a subset of the architectures where
2. Only one of the two binaries from the mumble source package was removed.

Was this removal just a mistake? or was there a reason behind it that I am not
seeing?

Re: Apparently uncoordinated libnetpbm transition.

[Peter Green]

On 25/04/2022 14:55, Paul Gevers wrote:

Hi Andreas,

On 07-04-2022 09:21, Andreas Tille wrote:

Sorry, that's my fault.  I'm preparing an upload to fix #1007984
targeting new.


Looking at https://ftp-master.debian.org/new/netpbm-free_2:10.98.00-1.html, is there 
any reason why you didn't add "Provides:
libnetpbm9-dev, libnetpbm10-dev"?

If that would work, it would prevent updates in at least 7 source packages: 
https://qa.debian.org/dose/debcheck/src_testing_main/1650862802/amd64.html If 
it wouldn't work, it seems to me that an unversioned -dev package doesn't bring 
us much.

Paul

(I was about to ping ftp master to accept your package, but in the current 
state it wouldn't solve the problem)


The version with the unversioned libnetpbm-dev was rejected.
(due to reasons unrelated to the package rename)

https://alioth-lists.debian.net/pipermail/pkg-phototools-devel/2022-May/014623.html

Bug#1009080: transition: libgit2

[peter green]

libgit2-glib has now been fixed, so I believe it is time to binnmu
git-evtag and gnome-builder, both packages were sucessfully binnmu'd
in raspbian.

testing migration of mir-core and stdx-allocator binnmus

[Peter Green]

I noticed that stdx-allocator had unsatisfiable build-dependencies
in testing, checking why I discovered that this was because the
mir-core binnmus had not migrated to testing. The update_output says.


trying: mir-core/i386
skipped: mir-core/i386 (0, 37, 5)
got: 25+0: a-1:a-21:a-0:a-0:i-2:m-0:m-0:p-0:s-1
* i386: libstdx-allocator-dev, libstdx-allocator0
trying: -libphobos2-ldc-shared98/i386
skipped: -libphobos2-ldc-shared98/i386 (0, 38, 4)
got: 41+0: a-1:a-21:a-0:a-0:i-18:m-0:m-0:p-0:s-1
* i386: appstream-generator, gir-to-d, libglibd-2.0-0, libglibd-2.0-dev, 
libgstreamerd-3-0, libgstreamerd-3-dev, libgtkd-3-0, libgtkd-3-dev, 
libgtkdsv-3-0, libgtkdsv-3-dev, libmir-core-dev, libmir-core0, libpeasd-3-0, 
libpeasd-3-dev, libstdx-allocator-dev, libstdx-allocator0, libvted-3-0, 
libvted-3-dev
trying: mir-core/amd64
skipped: mir-core/amd64 (0, 39, 3)
got: 25+0: a-3:a-21:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* amd64: libstdx-allocator-dev, libstdx-allocator0
trying: -libphobos2-ldc-shared98/amd64
skipped: -libphobos2-ldc-shared98/amd64 (0, 40, 2)
got: 41+0: a-19:a-21:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* amd64: appstream-generator, gir-to-d, libglibd-2.0-0, libglibd-2.0-dev, 
libgstreamerd-3-0, libgstreamerd-3-dev, libgtkd-3-0, libgtkd-3-dev, 
libgtkdsv-3-0, libgtkdsv-3-dev, libmir-core-dev, libmir-core0, libpeasd-3-0, 
libpeasd-3-dev, libstdx-allocator-dev, libstdx-allocator0, libvted-3-0, 
libvted-3-dev
trying: mir-core/arm64
skipped: mir-core/arm64 (0, 41, 1)
got: 25+0: a-1:a-23:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* arm64: libstdx-allocator-dev, libstdx-allocator0



trying: stdx-allocator/i386
skipped: stdx-allocator/i386 (0, 24, 18)
got: 25+0: a-1:a-21:a-0:a-0:i-2:m-0:m-0:p-0:s-1
* i386: libstdx-allocator-dev, libstdx-allocator0
trying: stdx-allocator/amd64
skipped: stdx-allocator/amd64 (0, 25, 17)
got: 25+0: a-3:a-21:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* amd64: libstdx-allocator-dev, libstdx-allocator0
trying: stdx-allocator/arm64
skipped: stdx-allocator/arm64 (0, 26, 16)
got: 25+0: a-1:a-23:a-0:a-0:i-0:m-0:m-0:p-0:s-1
* arm64: libstdx-allocator-dev, libstdx-allocator0





Can you add a hint to try these packages together?

Apparently uncoordinated libnetpbm transition.

[Peter Green]

A new version of netpbm-free was recently uploaded to unstable which
replaced the libnetpbm9, libnetpbm9-dev, libnetpbm10 and libnetpbm10-dev
packages with libnetpbm11 and libnetpbm11-dev packages.

I could not find any evidence of an attempt to coordinate this transition
with the release team, nor could I find any evidence of bug reports filed
against the reverse dependencies. Since the dev package has also been
renamed it seems to me that this transition cannot be performed with
binnmus and sourceful uploads of the reverse dependencies will be needed.

Bug#993079: release.debian.org: autopkgtest scheduling does not seem to understand virtual packages correctly.

[peter green]

On 27/08/2021 10:10, plugwash wrote:

Britney now seems to understand versioned virtual packages (at least in simple
cases) for the main migration and for auto removals, but it still does not
seem to properly understand them for testing migration.Typo, that should have said 
"it still does not seem to properly understand them

for scheduling/selecting autopkgtests".

Bug#988453: rust-rustyline 3.0.0-2+deb10u2 flagged for acceptance

[peter green]

On 11/06/2021 18:21, Adam D Barratt wrote:

package release.debian.org
tags 988453 = buster pending
thanks

Hi,

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


Thanks, unfortunately I've discovered yet another issue (sorry I should have 
spotted this
earlier, but buildd.debian.org misleadingly says "uncompiled").

The upstream commit I applied fixes the build with rustc 1.41 but breaks it 
with 1.34, buster
armel still has rustc 1.34, so this means that the 3.0.0-2+deb10u2  upload 
FTBFS on armel.

To make the code build with both rustc versions another upstream commit was 
needed, I have
applied this and prepared a debdiff, should I upload it?
diff -Nru rust-rustyline-3.0.0/debian/changelog 
rust-rustyline-3.0.0/debian/changelog
--- rust-rustyline-3.0.0/debian/changelog   2021-06-11 14:49:59.0 
+
+++ rust-rustyline-3.0.0/debian/changelog   2021-06-12 15:19:47.0 
+
@@ -1,3 +1,11 @@
+rust-rustyline (3.0.0-2+deb10u3) buster; urgency=medium
+
+  * Team upload.
+  * Apply another upstream patch so that the code builds with
+both rustc 1.34 and rustc 1.41
+
+ -- Peter Michael Green   Sat, 12 Jun 2021 15:19:47 +
+
 rust-rustyline (3.0.0-2+deb10u2) buster; urgency=medium
 
   * Team upload.
diff -Nru rust-rustyline-3.0.0/debian/patches/newer-rustc.patch 
rust-rustyline-3.0.0/debian/patches/newer-rustc.patch
--- rust-rustyline-3.0.0/debian/patches/newer-rustc.patch   2021-05-04 
09:26:41.0 +
+++ rust-rustyline-3.0.0/debian/patches/newer-rustc.patch   2021-06-12 
15:19:17.0 +
@@ -1,3 +1,8 @@
+This patch combines the two upstream commits below, the patched code has been
+tested to build succesfully on both rustc 1.34 (in buster armel at the time of
+writing) and rustc 1.41 (in buster on other architectures at the time of 
+writing)
+
 commit e383956f3fc9f313d8cf979f1a9772bea9eb1eb8
 Author: gwenn 
 Date:   Fri May 17 19:20:14 2019 +0200
@@ -6,25 +11,29 @@
 
 See #217
 
-diff --git a/examples/example.rs b/examples/example.rs
-index 8bb2e7e..204791f 100644
 a/examples/example.rs
-+++ b/examples/example.rs
-@@ -80,8 +80,8 @@ fn main() {
- loop {
+commit 6e5099f644d81e8546bf4a1a2c21e002597f5bc6
+Author: gwenn 
+Date:   Fri May 17 20:52:06 2019 +0200
+
+Another try
+
+Index: rust-rustyline-3.0.0/examples/example.rs
+===
+--- rust-rustyline-3.0.0.orig/examples/example.rs
 rust-rustyline-3.0.0/examples/example.rs
+@@ -76,7 +76,7 @@ fn main() {
  let readline = rl.readline(PROMPT);
  match readline {
--Ok(line) => {
+ Ok(line) => {
 -rl.add_history_entry(line.as_ref());
-+Ok(ref line) => {
-+rl.add_history_entry(line);
++rl.add_history_entry(line.as_str());
  println!("Line: {}", line);
  }
  Err(ReadlineError::Interrupted) => {
-diff --git a/src/history.rs b/src/history.rs
-index b1cb596..b7cc317 100644
 a/src/history.rs
-+++ b/src/history.rs
+Index: rust-rustyline-3.0.0/src/history.rs
+===
+--- rust-rustyline-3.0.0.orig/src/history.rs
 rust-rustyline-3.0.0/src/history.rs
 @@ -148,7 +148,7 @@ impl History {
  let file = File::open()?;
  let rdr = BufReader::new(file);
@@ -34,16 +43,16 @@
  }
  Ok(())
  }
-diff --git a/src/lib.rs b/src/lib.rs
-index 4f6162b..54672fb 100644
 a/src/lib.rs
-+++ b/src/lib.rs
-@@ -624,7 +624,7 @@ fn readline_raw(
+Index: rust-rustyline-3.0.0/src/lib.rs
+===
+--- rust-rustyline-3.0.0.orig/src/lib.rs
 rust-rustyline-3.0.0/src/lib.rs
+@@ -652,7 +652,7 @@ fn readline_raw(
  let user_input = readline_edit(prompt, initial, editor, _mode);
  if editor.config.auto_add_history() {
  if let Ok(ref line) = user_input {
 -editor.add_history_entry(line.as_ref());
-+editor.add_history_entry(line);
++editor.add_history_entry(line.as_str());
  }
  }
  drop(guard); // disable_raw_mode(original_mode)?;

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

[peter green]

On 11/06/2021 09:15, Adam D. Barratt wrote:

It looks like that's #932172, which was fixed in dh-cargo 19; buster
currently has 17. It would be worth considering a backport of the fix
to dh-cargo, to avoid such issues in other packages.


Agreed, I'll raise the issue in that bug report and if noone objects
i'll prepare an upload.


In this specific case, yes, please prepare another upload resolving the
issue, bearing in mind that the window for getting the fixed fix into
10.10 closes during this weekend. If you're confident that the fix will
be accepted, please feel free to upload it at the same time as
attaching a debdiff to this bug log.


Done.
diff -Nru rust-rustyline-3.0.0/debian/changelog 
rust-rustyline-3.0.0/debian/changelog
--- rust-rustyline-3.0.0/debian/changelog   2021-05-04 09:27:11.0 
+
+++ rust-rustyline-3.0.0/debian/changelog   2021-06-11 14:49:59.0 
+
@@ -1,3 +1,12 @@
+rust-rustyline (3.0.0-2+deb10u2) buster; urgency=medium
+
+  * Team upload.
+  * Reset timestamp on .cargo-vcs-info.json to avoid
+1970 timestamp which triggers a ftpmaster autoreject.
+(Closes: 989636)
+
+ -- Peter Michael Green   Fri, 11 Jun 2021 14:49:59 +
+
 rust-rustyline (3.0.0-2+deb10u1) buster; urgency=medium
 
   * Team upload.
diff -Nru rust-rustyline-3.0.0/debian/rules rust-rustyline-3.0.0/debian/rules
--- rust-rustyline-3.0.0/debian/rules   2019-02-03 20:19:06.0 +
+++ rust-rustyline-3.0.0/debian/rules   2021-06-11 14:49:59.0 +
@@ -1,3 +1,8 @@
 #!/usr/bin/make -f
 %:
dh $@ --buildsystem cargo
+
+override_dh_testdir:
+   dh_testdir
+   #avoid 1970 timestamp in package
+   touch .cargo_vcs_info.json

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

[peter green]

On 29/05/2021 15:17, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Thu, 2021-05-13 at 11:13 +0100, plugwash wrote:

rust-rustyline fails to build in buster due to a change of behaviour
in rustc,
this has been fixed in bullseye/sid for some time and I was able to
locate
the upstream commit that fixes the failure by bisecting and then
apply it to
the package from buster.



Please go ahead.


I uploaded the package.

Unfortunately it seems that the binaries were rejected due to a file
with a 1970 timestamp (this timestamp already exists in the version
currently in buster), should I go ahead and prepare another upload
fixing that?



Regards,

Adam

Re: Fixing rust package FTBFS in buster

[peter green]

On 08/05/2021 17:36, Adrian Bunk wrote:

On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote:

On 04/05/2021 12:28, Santiago Vila wrote:

On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:

This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.


Unfortunately I don't think a proper fix will be forthcoming, upstream
has abandoned the crate in question.


It does not need to be a perfect fix. It is enough that dpkg-buildpackage
exits with status 0. If the tests are no longer valid, disabling them
should be much better than nothing, because packages in stable must
build in stable.


I'm prepared prepare such uploads if the stable release managers
are prepared to accept them.


Usually they are receptive for reasonable FTBFS fixes,
and my rust-rustyline bug was part of me doing a find+fix round.


...
rust-simd: abandoned upstream, not in testing/unstable probably not properly 
fixible, could disable test build during package build to fix FTBFS.
rust-coresimd: abandoned upstream, not in testing/unstable probably not 
properly fixible, could disable test build during package build to fix FTBFS.
rust-nodrop-union: abandoned upstream, not in testing, broken in unstable 
probably not properly fixible, could disable test build during package build to 
fix FTBFS.


Is it only the test that is broken?
Or is the test due to some minor functionality breakage?
In that case, ignoring test problems would be the correct action.

But if the packages are just completely broken with current rustc,
then RM bugs against release.debian.org asking for removal in the
next buster point release would be the correct action for such
leaf packages.


As best I can tell they are just completely broken with current rustc.

They are not leaf packages (though naive search tools may
think they are because most dependencies between rust packages
go via virtual packages).

The reverse dependency graphs look like

librust-simd-dev -> librust-encoding-rs+simd-accel-dev, 
librust-encoding-rs+simd-dev
librust-coresimd-dev -> librust-packed-simd+coresimd-dev
librust-nodrop-union-dev -> librust-nodrop+nodrop-union-dev, 
librust-nodrop+use-union-dev

So before rust-simd, rust-coresimd and rust-nodrop-union could
be dropped it would be nessacery to modify rust-encoding-rs, rust-packed-simd
and rust-nodrop to drop the binary packages that depend on them.

I'm quite prepared to do this if there is consensus to do so
but I'm not going to make unilateral moves here.

Fixing rust package FTBFS in buster (was: Bug#931003: Removed package(s) from unstable )

[peter green]

On 04/05/2021 12:28, Santiago Vila wrote:

On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:

This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.


Unfortunately I don't think a proper fix will be forthcoming, upstream
has abandoned the crate in question.


It does not need to be a perfect fix. It is enough that dpkg-buildpackage
exits with status 0. If the tests are no longer valid, disabling them
should be much better than nothing, because packages in stable must
build in stable.


I'm prepared prepare such uploads if the stable release managers
are prepared to accept them.




There are already 74 packages which FTBFS in stable (by my count),


Do you have a list?


Last time I tried this is what I found:

https://people.debian.org/~sanvila/ftbfs-in-buster/


Thanks, looks like I misinterpreted your number as referring to rust packages
specifically rather than to all packages. Looks like there are four rust
packages in your FTBFS lists. The good news is that none of them seem to
be applications.

Of the four

rust-simd: abandoned upstream, not in testing/unstable probably not properly 
fixible, could disable test build during package build to fix FTBFS.
rust-coresimd: abandoned upstream, not in testing/unstable probably not 
properly fixible, could disable test build during package build to fix FTBFS.
rust-nodrop-union: abandoned upstream, not in testing, broken in unstable 
probably not properly fixible, could disable test build during package build to 
fix FTBFS.
rust-rustyline: fixed upstream and in testing/unstable, I was able to bisect 
and backport the fix (see bug 988025 )

re: Bug#931003: Bug#931003: Removed package(s) from unstable

[peter green]

This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.


Unfortunately I don't think a proper fix will be forthcoming, upstream
has abandoned the crate in question.

Afaict the only purpose this package serves in buster is to satisfy the
dependencies of "librust-encoding-rs+simd-dev" and
"librust-encoding-rs+simd-accel-dev" neither of which have any reverse
dependencies.

it looks like "librust-encoding-rs+simd-dev" and 
"librust-encoding-rs+simd-accel-dev"
were dropped in unstable by the rust-encoding-rs upload 0.8.15-2 just prior to 
the
buster release, but these changes did not make it into buster.

There are already 74 packages which FTBFS in stable (by my count), 


Do you have a list?

Are the stable release managers open to patches fixing such issues?

(note that FTBFS indications on reproducible builds are IME not reliable,
I have seen plenty of FTBFS on there that look like either resource
exhaustion or quirks of the particular builders they are using, they
also report FTBFS even on architectures where a package has no binaries in
Debian)


it would be much better if every mantainer cared about their own packages.


For the most part maintainers care for their packages in testing/unstable,
then when a stable release happens things get frozen. So normally packages
that built successfully in test rebuilds during the freeze should continue
to build successfully throughout the releases stable lifecycle.

Unfortunately firefox/thunderbird support lifecycles combined with it
being one of the most security-sensitive packages in Debian requires
periodic updates to new firefox/thunderbird release series even in stable
releases, that in turn has lead to new major versions of rustc being
uploaded even during freezes and even to stable releases.

The rust team has been struggling for lack of manpower, particularly
experienced manpower for some time. I've been trying to help where I
can but I'm still a relative newcomer to rust (though I understand the
rust packaging system a lot better than I did 6 months ago).

I do wonder if it would make sense to use seperate package names for
the rust backports done to support firefox/thunderbird updates in
stable so the rest of the rust ecosystem is not affected.

ccing the release team and the mozilla maintainers to see if they have
any input on this.

Re: Release status of i386 for Bullseye and long term support for 3 years?

[peter green]

   Then there was the short netbook boom, but AFAIR some early ones
   had 64bit CPUs but 32bit-only firmware.

My memory is that at the height of the boom the dominant processors
were the N270 and N280, which are 32-bit only. By the time 64-bit
netbook processors showed up the boom was on the decline.


There are at least two more:


5. People running Debian on virtual machines.

You can run an i386 VM with vmware or virtualbox with no special
hardware support. An x86-64 VM on the other hand requires VT-x
(or the AMD equivilent). While processor support for this is
the norm nowadays it's still often disabled by default
which can be a pain if you need to get IT support to access
bios setup on a machine.

i386 hardware is so numerous and widely spread, that every tiny fraction 
of i386 users might be more users than half of our release architectures 
combined. It is not even clear whether this is just an exaggeration or 
might be literally true:


i386 still gives 17281 popcon submissions, that is about
a tenth of amd64, but it's also over 10 times the next highest port

Now that probably doesn't reflect true usage, in particular
users who install using images tend to miss out on the popcon
question, but I still suspect that i386 is up there in the top
few most used architectures.

Bug#971571: transition: libgit2

[peter green]

I've rebuilt the relevant reverse-build-dependencies from unstable


In addition to the packages mentioned here, it seems there is another
package involved: golang-gopkg-libgit2-git2go.v28 . It only builds
arch-all packages and does not directly depend on the library, but it
FTBFS and it's autopkgtest fails with the new version.

The FTBFS was picked up in a rebuild test by Lucas and a bug report
was filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976522

Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[peter green]

On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote:

On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:

This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
The bootstrap happens with the upstream binaries as we've done in the past.
I have also avoided the bump to LLVM 9/10, we use buster's LLVM 7 instead.


The updated rustc is in buster-proposed-updates now, but it failed to build for
armel. Looks like my change to debian/architecture.mk to use
arm-unknown-linux-gnueabi rather than armv5te-unknown-linux-gnueabi broke this a
bit. The reason for that change was that there were no armv5te binaries
upstream, and the arm ones are ARMv5 so should be good to bootstrap rustc on
armel. However, rustc now defaults to ARMv6 for arm-unknown-linux-gnueabi (see
vendor/cc/src/lib.rs), which could be causing some issues. Or perhaps the issue
lies elsewhere.

Anyway my attempts at getting rustc 1.41 bootstrapped on armel have failed so
far (I have tried to lower that -march to armv5te, and also attempted to build
for armv5te-unknown-linux-gnueabi while using the arm-unknown-linux-gnueabi
binaries). Any help from the armel porters would be appreciated.


I'll take a look, can't promise anything but I've had to deal with similar 
issues
in raspbian before.

android-framework-23 autorm weirdness.

[peter green]

The tracker for android-framework-23 shows it as due for autoremoval today (and 
IIRC has been saying that for some time)
, and indeed britney is trying to remove it but is failing to do so.

Strangely the tracker for andriod-framework-23 says it will cause the 
autoremoval of android-platform-dalvik and libscout
but the tracker pages for those packages say they aren't due for autoremoval 
until the 22 september.

Any idea what is going on?

Bug#969158: expeyes: maybe a false positive generated by mail_autoremovals.pl?

[Peter Green]

(note: this mail represents my opinions as an ordinary dd, I am not a member of 
the release team)

due to the fact that it is supposed to (build-)depend on binutils-avr, which
FTBFS.


As I understand it "(build-)depends" should be interpreted as
"depends or build-depends"



The source package expeyes generates one binary package, microhope, which
declares a dependency on avr-libc; should I downgrade this dependency down to
a recommendation? The binary package microhope does not need  binutils-avr
as it is mainly an editor for small C or assembly language snippets. It needs
binutils-avr only when the end user will try to compile and link one one the
edited snippets.


The package description for microhope implies that while it may technically
be "mostly an editor" it's reason for existing is avr development. Downgrading
the dependency to a reccomends is arguably correct (reccomends is described as
"The Recommends field should list packages that would be found together with
this one in all but unusual installations.") and would get the autoremovals
tool out of your hair, but I would still question if a package that can't
fulfill it's primary purpose belongs in a Debian release.

IMO what really needs to happen here is that binutils-avr needs to be fixed,
either by changing the actual code or by changing the compiler flags to make
gcc less picky.

Bug#962563: transition: nettle

[peter green]

I just went through the remaining items on the transition tracker for this 
transition
filing bug reports where appropriate.

freewheeling:
sid-only, unrelated FTBFS bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946863

haskell-hopenpgp/haskell-hopenpgp-tools:
haskell-incremental-parser has picked up a build-depends on a package that has 
never
built on 6/10 release architectures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965299

ocamlnet:
FTBFS on most architectures, doesn't look related to nettle transition
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965300

opendht:
FTBFS, doesn't look related to nettle transition.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965301

caml-crush (sid-only):
no binnmu scheduled (builds successfully on reproducible builds)

ring (sid-only):
unrelated FTBFS
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961837

dpaste (sid-only)
FTBFS on reproducible builds, depends on rc buggy package.

Is it time to remove python-numpy from testing?

[peter green]

python-numpy* is no longer buildable in testing due to the removal of the 
"cython" binary package.
The maintainer has requested removal of python-numpy from unstable but the 
ftpmasters have not yet
actioned it, presumably because there are still reverse-dependencies in 
unstable. A rc bug is
present but will not cause autoremoval because python-numpy is on the "key 
packages" list.

All of the reverse dependencies of python-numpy have already been removed from 
testing. So IMO
it makes sense to remove python-numpy from testing at this point, do other 
people agree?

* Note: since buster the python-numpy source package only builds python 2 
related binary packages,
the python3 numpy binary packages are now built from the numpy source package.

why did hypercorn migrate to testing?

[peter green]

At the start of the month python-asynctest and hypercorn were removed from
testing due to a rc bug in python-asynctest and the fact that hypercorn
build-depends on python3-asynctest (which is built from the python-asynctest
source package).

However hypercorn just migrated to testing again, despite the fact that
python-asynctest is rc buggy and not in testing. This leaves hypercorn
in violation of "packages must be buildable within the same release".

Any idea why this happened?

future of aufs in Debian.

[peter green]

The aufs package last saw a maintainer upload in September 2019 and was 
last-updated (by a NMU) in October 2019. It has had broken build-dependencies 
in testing for half a year now (since Linux 5.3.9-3 migrated to testing in 
November 2019).

According to dak rm the aufs source-package has two reverse-dependencies, 
aufs-tools and fsprotect neither of which has any reverse-dependencies.

Adrian filed a rc bug in November 2019 which received no maintainer response, however the 
package was not autoremoved from testing due to aufs and aufs-tools being considered a 
"key packages" due to high popcon. This popcon actually seems to be growing in 
both absolute and percentage terms. I presume the high popcon is due to some deriviative 
(hence debian-derivatives and debian-live in cc) using aufs in their live image builds 
(as far as I can tell debian's own live images seem to use overlayfs instead nowadays).

aufs does seem to still be maintained upstream with upstream claiming support 
for Linux 5.6.

According to contributors.debian.net Jan Luca Naumann (the aufs maintainer) was 
last active in September 2019. Jan: are you still around? and if so do you 
still intend to maintain the aufs package? if not is someone else going to step 
up to the plate? or should these packages be removed from testing?

Bug#958988: key packages script does not take account of virtual packages.

[peter green]

package: qa.debian.org
user: qa.debian@packages.debian.org
usertags: udd
x-debbugs-cc: debian-release@lists.debian.org

The debian rust team makes heavy use of virtual packages to reduce the number 
of real packages in the archive (and in some cases the number of trips through 
new) while retaining flexibility to split if necessary (either for multiple 
versions of a crate or where featuresets that previously had the same 
dependencies diverge).

Unfortunately the key packages script does not take virtual packages into 
account. The result of this is that a large number of rust packages that ought 
to be on the key packages list (as a result of firefox depending on cbindgen 
which build-depends on a bunch of rust packages) are not on there.

This raises a couple of questions.

1. What should the policy be on handling virtual packages? it seems to me that 
virtual packages with only a single provider should be treated much the same as 
real packages but what about those with multiple providers? ignore them? pick 
one according to priority and popcon? include them all? (it seems like the 
latter could lead to unnessacery growth of the key packages list).
2. how to actually implement that? it looks to me like it would involve 
extending add_pkg_sources in 
https://salsa.debian.org/qa/udd/-/blob/master/scripts/update-key-packages.pl 
but I'm not a perl guy or a udd guy.

rust-grep testing migration.

[peter green]

Hi

Rust-grep is currently blocked from testing migration because of an autopkgtest 
failure on arm64, it appears that the test failed due to a version mismatch 
issue. The test was run over three weeks ago and the offending version is no 
longer in testing.

I tried hitting the "retry" button a few days ago and the test appeared in the 
pending queue for a while. However it has now disappeared from the pending queue and yet 
there are no new test results at 
https://ci.debian.net/data/autopkgtest/testing/arm64/r/rust-grep/

Can someone take a look and try to unjam things?

testing migration of gtk-d and tilix binnmus

[peter green]

While investigating self-contained buildability issues in testing I noticed 
that the gtk-d and tilix binnmus were not migrating to testing.

I'm not an expert on reading britney output but I think they may be being 
blocked by dependencies on each other and britney needs a hint to try them 
together. Can someone take a look?

state of the rust ecosystem (and particularly rust-cbindgen) in Debian (was: Requesting backport of cbindgen > 0.10.0 to buster)

[peter green]

(note: these are my observations as a maintainer of a derivative)


The rust ecosystem in Debian
recently had (and I expect still has) trouble to properly migrate to
testing

Indeed there are still issues, most notablly IMO that firefox-esr's 
build-dependencies have been unsatisfiable in testing for over 7 months because 
rust-cbindgen has not been able to migrate to testing.


and is missing a *demonstrated* sane dependency and versioning
scheme (in the context of how Debian is working *at this moment* in time).

A big difference with rust and most other languages in this regard seems to be 
that rust dependencies, both upstream and as source and binary dependencies in 
Debian are typically pessimistic.

Contrast this with most other languages in Debian, for C/C++ stuff the binary 
dependencies are typically somewhat pessimistic, but the source dependencies 
are typically optimistic. For most interpreted languages, both the source and 
binary dependencies are optimistic.

Another factor is that the rust packages make heavy use of versioned provides. 
Unfortunately while apt and britney seem to handle these fine the 
packages.debian.org web interface and the autoremovals system do not (or at 
least did not last time I looked). The former makes understanding rust 
dependencies difficult. The latter made filing rc bugs against rust packages 
with broken dependencies in testing fairly fruitless.

Yet another issue is that it took "rust-compiler-builtins" a long time to get 
through new, this blocked a lot of rust packages from transitioning to testing for a long 
time, which in turn blocked migration of new versions of a number of fairly important 
packages.

The result of all this was a massively snarled up dependency tangle preventing 
stuff migrating to testing.

It seems that in the end Paul Gevers (elbrus) decided to just do a mass removal 
of rust stuff from testing, this did un-jam some stuff but it also excarbated 
the autopkgtest issues because a test that is already failing in testing is not 
a blocker for a new version to migrate, but once a package is out of testing 
the autopkgtest will stop it re-entering.

As far as I can tell, right now rust-cbindgen's re-entry to testing seems to be 
blocked by autopkgtest failures in the following source packages

rust-libc ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955997 )
rust-compiler-builtins
rust-atty
rust-unicode-normalization
rust-autocfg
rust-cfg-if (this one has actually previously passed)
rust-no-panic
rust-failure-derive (this one has actually previously passed)
rust-rustc-demangle
rust-uuid
rust-goblin ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947711 )
rust-futures
rust-cc
rust-pkg-config
rust-futures
rust-backtrace-sys


And by uninstallable featureset packages in the following source packages

rust-unicode-width

And by the requirement for source-only uploads in the following packages.

rust-compiler-builtins
rust-goblin
rust-adler32

And by FTBFS bugs in the following source packages

rust-core-arch ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952228 )

And by other RC bugs in the following packages

rust-spin ( Moritz thinks the package should not be in testing because it's 
abandoned upstream https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946921 )

re: git-buildpackage to be autoremoved due to python2 transition

[peter green]

Relevant packages and bugs:
  943107 git-buildpackage: Python2 removal in sid/bullseye

This bug is not marked as rc.

Nevertheless I believe that this bug report is in-fact a false positive. From 
what I can tell git-buildpackage, even in buster, does not (build-)depend on 
python 2 or any python 2 modules.

It does build-depend on python-pydoctor, but according to a recently entry in the 
pydoctor changelog that package "is a Python application and not used as a 
module"

It would make sense to change the build-dependency to pydoctor in the next 
upload, but it's probablly not worth making an upload just for that change.

  937132 nevow: Python2 removal in sid/bullseye

Depended on by pydoctor in testing, but not in unstable. Should stop being a 
problem for git-buildpackage when pydoctor migrates.

  938622 tahoe-lafs: Python2 removal in sid/bullseye

Listed as a "blocker" of the above bug but not currently in testing. Personally I 
advocate ignoring "blockers" that are not in testing, but I'm not sure if consensus has 
been reached on that.


Bugs which you may notice which are now not so relevant any more
because they have been fixed in sid (but not yet migrated):
  950216 [git-buildpackage] missing xsltproc autopkg test dependency
Fixed in sid; migration blocked by FTBFS due to pydoctor
breakage (#949232).  When pydoctor has migrated, reattempting
build (eg by re-upload) should fix this.

Builds happen in unstable, so there is no need to wait for pydoctor to migrate 
to testing before retrying the build. I just requested a retry and the package 
built succesfully. I'd expect it to migrate as soon as dak and britney process 
the binary.

  949232/948831 [pydoctor] needs to depend on cachecontrol
  952546 [pydoctor] d/copyright & DFSG issues
  937421 [pydoctor] Python2 removal in sid/bullseye

Should hopefully be fixed in a few days when pydoctor migrates to testing, i'm 
not seeing any obvious blockers for that right now.

Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition

[peter green]

There's another kind of issue

Yeah, sadly the transition tracker only looks at unstable, so packages that are 
fixed in unstable but haven't migrated to testing for some reason won't show up.

; here is an example :

- sagemath builds only for Python 3.7, so some of this subpackages
don't load under Python 3.8 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949023

- which means that for brial, autopkgtest fails :
https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/3988637/log.gz


Looking at brial, it seems python3-brial should technically have a dependency 
on sagemath, but this dependency is omitted for bootstrapping reasons 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896218 .


I haven't found the time to investigate things further in sagemath ; I
was wondering if I wouldn't disable the Python 3.8 test in brial... not
ideal...

I would think the autopkgtest should probably check somehow what versions of 
python3 sagemath supports and test against those, rather than having a 
hardcoded whitelist/blacklist.


Afaict until sagemath makes it back into testing ( currently blocked by 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944055 ), having a brial 
package in testing is pretty pointless.

Bug#942106: looking at the remaining "bad" packages in the "add python 3.8" transition

[peter green]

I just took a look at the "add python3.8 transition tracker", and split the remaining 
"bad" packages into categories.

Key package, rc bug with patch.
* gpgme1.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944774

Not key package, but not marked for autoremoval from testing
* macs version in unstable FTBFS on most architectures, version in testing 
seems to build fine
  with 3.8 according to reproducible builds, but afaict binnmus are not 
currently possible in testing

Builds only against default python3 version
* libcap-ng https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943627
* fontforge https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948016
* pcp can't find a bug report for this one.
* getfem++ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948016
* uhd https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943636
* stimfit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948020

Marked for autoremoval from testing
* subvertpy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942678
* beancount https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943608
* python-thinc https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947111

Not in testing (and not mentioned already)
* libyang build timesouts on mipsel/mips64el , probablly heavy swap use
* python-tesserocr https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943501
* pyfai https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945411
* veusz https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945467

Re: Bug#948722: qemu-block-extra, (build-)dependencies unsatisfiable on mipsel.

[peter green]

On 14/01/2020 10:24, Michael Tokarev wrote:

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

12.01.2020 18:37, peter green wrote:

Package: qemu-block-extra
Version: 1:4.2-1
Severity: serious

The binary packages built from the ceph source package were recently removed 
from mipsel, because the new version of ceph runs out of address space
during the build. Your package build-depends on libradios-dev and librbd-dev 
and depends on librados2 and librbd1 which are built from the ceph source
package. So qemu-block-extra is now uninstallable and the qemu source package 
is unbuildable on mipsel.

Hm. For the start, I see that new ceph packages are being built on mips/mips64
right now as I write this. So things aren't that simple, at least.


Ceph 14.2.4 was uploaded to unstable in late december, but failed to build on many 
architectures. The maintainer found workarounds for most of them, but could not find any 
soloution to the address space exhaustion issue on mipsel (when a build says "out of 
memory" it nearly always really means out of address space).

With version 14.2.4-8 the maintainer decided it was time to give up on mipsel, 
he removed mipsel from the architecture lists and filed a removal request with 
the ftp masters. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947887

It seems that with version 1.4.2.5-1 mipsel was quietly re-added to the 
achitecture list, I do not know if this was a mistake or if the maintainer was 
deliberately testing if the problem had gone away. Either way ceph has 
continued to fail to build on mipsel.


Next, even if we're now uninstallable on some architecture, it is definitely not
our fault,


It's not about "fault".


so I don't see why this bugreport is of serious severity.

rc policy "Packages must be buildable within the same release."

I'm not going to play severity ping-pong with you, but I am ccing the ceph 
maintainers and the release team in-case they want to give a position on this.

  Also, it has
nothing to do with this particular version of qemu, either.

True enough, afaict normal practice is to file bugs against the current version 
in testing/unstable unless there is reason not to.

   And more, it has
nothing to do with qemu-block-extra package, too, even if that's the only pkg
which actually uses the library in question, -- we _build_-depend on 
librados-dev
too, so it is qemu source which FTBFS on mips.

If you would preffer to reassign to the source package that is fine by me, 
doesn't make much practical difference.


So far I don't quite understand what's going on with ceph on mips, hence adding
a "moreinfo" tag. We shouldn't drop optional features on different architectures
easily,


If I thought this was just some transient issue I wouldn't have bothered filing 
this bug, but I doubt it is.


  or else it would quickly become a mess, not understanding which features
of which packages are enabled on which architecture (I speak here about general
debian, not about this particular (pair of) package).

At some point I think Debian needs to have a hard think about how 32-bit 
architectures are supported, possiblly introducing official support for 
cross-building heavier packages, but so-far there doesn't seem to have been a 
strong will to do so.

Re: possible bug in auto-removals.

[peter green]

On 16/12/2019 21:02, Paul Gevers wrote:

Hi Peter,

On 16-12-2019 01:21, peter green wrote:

I have been observing a number of python cruft packages that are still
in testing recently, and I noticed that there seems to be an issue with
an auto-removal.

cruft has never been supposed to be in testing.


My understanding is that smooth updates is a feature that deliberately allows 
some cruft in testing to make it easier for transitions to complete.

I had assumed that you had expanded smooth-updates from library packages to 
other packages, looks like that assumption was wrong.



  There was a bug in
britney that we believe is fixed. The end of the output.txt has the
packages which shouldn't have been left in testing:
List of old libraries in the target suite (96):
[...] (libraries in smooth update transitions)
  python-colorama: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x

Removal blocked by ceph (fixed in new), hinge (fixed in unstable, but 
struggling to migrate would have been autoremoved, if someone hadn't gone and 
added a blocker to the bug, resetting the timer),polenum (just bumped the bug 
to rc), python-click (this one looks like a problem, it's a key package and 
it's python 2 removal bug in unstable has a bunch of blockers listed), 
python-colormap (fixed in unstable, blocked from migrating by hinge), 
python-easydev (fixed in unstable, blocked from migrating by hinge), flask 
(just upgraded bug to rc) and impackage (just upgraded bug to rc)

  python-colorlog: amd64 arm64 i386 mips64el ppc64el

Basically a subset of the above, python-colormap, python-easydev and hinge. 
Afaict if hinge is removed or fixed then python-colormap and python-easydev 
should be able to migrate and this should be able to be cleaned up.

  python-fonttools: amd64 i386
  python-fs: amd64 i386

I have just uploaded NMUs of nototools and fonts-noto-color-emoji to delayed/5 
to fix these.

  python-terminado: amd64 i386

Waiting for jupyter-notebook to migrate to testing.

  python-waitress: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x


Blocked by ceph (fixed in new), python-pecan (fix blocked by ceph), and webtest. According to the 
bug "blockers", the fix for webtest is blocked by routes, which in turn is blocked by 
calibre, but i'm not sure these "blockers" are entirely accurate, I will follow up to the 
bug on python-routes.

I see, probably a bug somewhere. I think the code that generates the
list for autoremoval is this one:

https://salsa.debian.org/qa/udd/blob/master/udd/testing_autoremovals_gatherer.pl

I'm afraid I don't speak perl.

I wonder if it makes sense to manually remove hinge for the moment.

possible bug in auto-removals.

[peter green]

I have been observing a number of python cruft packages that are still in 
testing recently, and I noticed that there seems to be an issue with an 
auto-removal.

My understanding is that auto-removals is supposed to keep track of reverse 
dependencies and initially delay auto-removal, then later, if the package 
remains rc buggy for long enough, remove the reverse-dependencies as well.

However in the case of python-easydev auto-removals seems to be trying to 
remove python-easydev without also removing it's reverse dependency hinge. Any 
idea why?

astroid2 removal from testing (after removal from unstable)

[peter green]

astroid2 was removed from unstable a couple of weeks ago. However it is still 
in testing, britney claims.


trying: -astroid2
skipped: -astroid2 (424, 28, 295)
 got: 32+0: a-1:a-0:a-0:a-0:i-28:m-2:m-0:p-0:s-1
 * mips64el: python-guiqwt, python3-guiqwt


However neither of those packages seems to have a dependency on anything 
astroid related. Any idea what is going on?

Haskell binnmus is there a problem?

[peter green]

Recently I noticed that haskell binnmus no longer seemed to be happening. For 
example mediawiki2latex has no been BD-Uninstallable since it was uploaded 24 days 
ago and https://buildd.debian.org/status/architecture.php?a=arm64=sid 
doesn't show any haskell binnmus currently being built (there are a handful in 
BD-Uninstallable but they seem to have been scheduled as part of non-haskell 
related transitions).

As I understand it haskell binnmus are normally handled by Joachim Breitner, 
who has a script that outputs what needs binnmuing and feeds output from that 
script into wanna-build. Is there some issue that is blocking this at the 
moment.

Bug#892073: transition: poppler

[peter green]

There's also the libpoppler SONAME bump. All rdeps build fine except for
pdf2djvu and xpdf. I'll file bugs for those.

calligra and ipe-tools are also failing.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911502
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911503

Is the claim in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910869 that
the memcheck stuff can just be patched out applicable there too?

Bug#908980: transition: qrencode (ongoing, apparently uncoordinated)

[peter green]

Package: release.debian.org
Severity: normal
User:release.debian@packages.debian.org
Usertags: transition
Control: forwarded 
-1https://release.debian.org/transitions/html/auto-qrencode.html
Control: block -1 by 908929
X-Debbugs-CC:qrenc...@packages.debian.org

oops, send this to the list instead of the bug submission address, resending.

Hi debian-release,
I thought I would let you know that there appears to be a libqrencode transition
going on and this transition seems to be uncoordinated (at least I can find no
recent mention of it in the debian-release archives). An automated transition
tracker has been set-up at
https://release.debian.org/transitions/html/auto-qrencode.html

It appears that no binnmus have been scheduled in Debian for this transition
yet, the packages listed as "good" either don't depend on the shared library or
had a sourceful upload since the libqrencode upload.

Over in raspbian our auto-binnmuer did schedule binnmus for this transition. All
of them built successfully. However google-authenticator uses libqrencode
through dlopen/dlsym rather than through the headers provided by libqrencode,
so it needs sourceful changes (to both the upstream source and debian/control).
Seehttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908929

transition: qrencode (ongoing, apparently uncoordinated)

[peter green]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-qrencode.html
Control: block -1 by 908929
X-Debbugs-CC: qrenc...@packages.debian.org

Hi debian-release,
I thought I would let you know that there appears to be a libqrencode transition
going on and this transition seems to be uncoordinated (at least I can find no
recent mention of it in the debian-release archives). An automated transition
tracker has been set-up at
https://release.debian.org/transitions/html/auto-qrencode.html

It appears that no binnmus have been scheduled in Debian for this transition
yet, the packages listed as "good" either don't depend on the shared library or
had a sourceful upload since the libqrencode upload.

Over in raspbian our auto-binnmuer did schedule binnmus for this transition. All
of them built successfully. However google-authenticator uses libqrencode
through dlopen/dlsym rather than through the headers provided by libqrencode,
so it needs sourceful changes (to both the upstream source and debian/control).
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908929

Bug#903211: release.debian.org: How to handle unbuildable packages in buster

[peter green]

(note: I am not a member of the release team, just a dd who spots a load of 
build-depency issues in testing as part of running a derivative)


I thought testing with dose-builddebcheck already happened routinely but
can't find it. Any historical perspective on that?


There is

https://qa.debian.org/dose/debcheck/src_testing_main/index.html

Unfortunately it doesn't distinguish between packages that have never built on 
an architecture and packages which have binaries on an architecture but can't 
be built on that architecture in current testing.

A bigger Issue though is that failure to satisfy build-dependencies in testing but not 
unstable is rarely the "fault" of the package that is failing to build, but is 
the fault of build-dependencies that for some reason are not migrating.

If the migration of the build-depencies is something that is "in hand" already 
then filing bugs against the victims is just a waste of everyone's time. On the other 
hand if none of the maintainers of the dependencies are paying attention then the 
maintainer of the victims may well want to be informed.

Re: Fixing Linux getrandom() in stable

[peter green]

I don't see any general solution that is both correct and easy.

I don't think there is one.

In an ideal world all our computers would have a trusted source of true 
randomness. In practice that is not the case. Older computers don't have a 
hardware random number generator at all and newer computers have one hidden 
inside a big chip which the more paranoid think could have been backdoored.

So the Linux kernel must monitor a set of of events that it thinks are probably random 
and for each event add some "entropy" to the pool. Once enough entropy is 
collected the pool is considered ready. This immediately raises two failure modes.

1. If the "random" events don't come then the pool may never be considered 
ready.
2. If the "random" events aren't actually random then the "random" numbers 
returned to user-land may be predictable.

There is no generally "correct" solution here. Every solution is a compromise between the 
risk of "random" data being predictable and the risk of systems failing to operate in a 
timely manner (or even at all) due to unavailability or randomness.

Bug#894049: transition: ncurses

[peter green]

I suspect fpc will also need a sourceful upload for the new ncurses. I would 
recommend not binnmuing it until the maintainers have had chance to take a look.

Is there a full list of differences between the version 5 and 6 ABIs anywhere? 
chtype has already been mentioned, are there any others?

Status of the marble package.

[peter green]

Marble currently FTBFS in unstable due to a couple of missing symbols and this 
is preventing the libgps transition from finishing up. The version in 
experimental fixes the issue but it looks like uploading it to unstable would 
start a transition.

What are the plans here? are the symbols that disappeared just template cruft 
or are they real ABI changes? are there any plans to transition the 
experimental version to unstable in the near future.

Bug#879520: transition: rtmidi

[peter green]

Block 879520 by 880848
Thanks

python-rtmidi still needs attention for this transition to complete. The binnmu 
built succesfully but the resulting package still depends on the old rtmidi.

Re: What is going on with gtkdatabox?

[peter green]

On 24/11/16 09:04, Andreas Tille wrote:

The other problem is that libgtkdatabox-0.9.2-0-dev should not be any
more in the pool at all and I have no idea why this is the case.
   

Binary packages that are no longer built by a source package are not removed 
instantly, they will be cleaned up by the ftpmasters when the 
reverse-dependencies are dealt with.

What is going on with gtkdatabox?

[peter green]

As a derivative maintainer I noticed that there appears to be a 
gtkdatabox transition going on. Looking at the list archives for 
debian-release I see no mention of it on there.


Specifically it seems that the libgtkdatabox source package has renamed 
every binary package it generates.


libgtkdatabox-0.9.2-0 -> libgtkdatabox-0.9.3-0
libgtkdatabox-0.9.2-0-glade -> libgtkdatabox-0.9.3-0-glade
libgtkdatabox-0.9.2-0-libglade -> libgtkdatabox-0.9.3-0-libglade
libgtkdatabox-0.9.2-0-dev -> libgtkdatabox-dev
libgtkdatabox-0.9.2-0-doc -> libgtkdatabox-doc

I see at least the following reverse depdencies that will need sourceful 
changes.


brp-pacu: has a build-dependency on libgtkdatabox-0.9.2-0-dev | 
libgtkdatabox-dev . Unfortunately buildds only look at the first option 
and even if they did they have no way of telling if a package is cruft 
or not.

gtkdataboxmm: build-depends on libgtkdatabox-0.9.2-0-dev explicitly
xoscope: build-depends on libgtkdatabox-0.9.2-0-dev explicitly

I have filed bug reports for gtkdataboxmm and xoscope, for which I have 
received no matainer response. I have not yet filed one for brp-pacu.



I have no idea if changes beyond build-depedency changes are needed.

Bug#836530: nmu: lazarus_1.6+dfsg-4

[peter green]

nmu lazarus_1.6+dfsg-4 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc>  2.23 related issues"

Minor nitpick, the working powerpc fix didn't land until -8


nmu pasdoc_0.14.0-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc>  2.23 related issues"
nmu gearhead2_0.628-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc>  2.23 related issues"
nmu ztex-bmp_20120314-2 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc>  2.23 related issues"
   
I don't think these are needed. I see no evidence of dependencies on c 
libraries.

nmu imapcopy_1.04-2 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc>  2.23 related issues"
nmu mricron_0.20140804.1~dfsg.1-1 . powerpc . unstable . -m "rebuild with fpc 
3.0.0+dfsg-7 to fix glibc>  2.23 related issues"
   
These have unrelated FTBFS bugs, so scheduling a binnmu is pointless. 
Instead the FTBFS bugs need to be fixed.


In addition to the binnmus we will want some give-backs once lazarus is 
rebuilt


gb ddrescueview_0.4~alpha3-1 . powerpc . unstable
gb doublecmd_0.7.3-1 . powerpc . unstable

Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)

[Peter Green]

> Fixed package is in sid (5.0-3) since Fri, 15 Jul

I have installed this on the main raspbian server and I can confirm it 
works for us with wanna-build.


Note1: I had to update wanna-build, the version of wanna-build I had 
(which was not bang up to date but not all that old either) wouldn't 
work with the new dose. Not exactly sure why. The only dose related 
change I see seems to be related to display postprocessing and claims to 
target the jessie-bacports version not the sid version.


Note2: If you want wanna-build to leave the temporary sources file 
arround for inspection afterwards change.


my ($SOURCES, $tmpfile) = tempfile( $tmpfile_pattern, UNLINK => 1 );

to

my ($SOURCES, $tmpfile) = tempfile( $tmpfile_pattern, UNLINK => 0 );

and comment out

unlink( $tmpfile );

in bin/wanna-build

Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

[peter green]

2016-07-02 17:53 GMT+03:00 Otto Kekäläinen:
>  This is modeled after how default-jdk or default-mta works.

Actually default-jdk is a real metapackage, while default-mta is a
pure virtual package. I am not sure which way to pick here now.

https://packages.debian.org/jessie/default-mta
https://packages.debian.org/jessie/default-jdk
   

It depends on what behaviour you want on dist-upgrade.

A real package will stick arround, so if you switch the default then a 
dist-upgrade will pull in the new default. On the other hand a virtual 
package is never installed as such, so existing systems will keep their 
existing implementation.

Re: [Stretch] Status for architecture qualification

[peter green]

On 07/06/16 19:38, Martin Michlmayr wrote:

* Steve McIntyre  [2016-06-06 15:14]:
   

However, I will admit (again) that armel is starting to lose upstream
support in some cases. I'm tempted to suggest that Stretch should be
the last release for armel for that reason.
 

Which upstream problems do you see?
   
A big concern going forward is C++11 atomics. AIUI (unless something has 
changed recently) these are unimplemented on armel causing code that 
uses them to FTBFS. Right now very little code uses them but if a major 
peice of infrastructure starts using them it could put armel in a very 
sticky sitution.


armv4t doesn't really have good atomic instructions (there is "swp" but 
it has to be emulated on later architectures and i'm not sure it's 
enough to support the normal range of operations) . AIUI there are 
kernel helpers available but it would need someone with good knowlage of 
the subject to implement the C++11 atomics in terms of the kernel helpers.

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 23:01, Wookey wrote:

Ok, so a total of 6 shared between the two architectures?
 

Thats what it looks like to me.

And I think we are building armhf on the arm64 build machines too?
   

I don't think so. At least I see no evidence of it on buildd.debian.org .

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 11:01, Niels Thykier wrote:

all arm ports have DSA concerns.
   
Is there a current reference to what these concerns are? Is there still 
a lack of out of band management? (the old mail I found on the topic 
said it was "being worked on", sledge whats the status here?) are there 
other concerns?

- armel has a RT concern about lack of buildds (only 2)
   
I think this is outdated, my understanding is that armel and armhf are 
now using a shared buildd pool. I see arnold, hoiby, henze, hasse, 
antheil and hartmann recently active on the armel buildd page and the 
same on the armhf page.

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 13:00, Holger Levsen wrote:

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
   

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed
 

[...]
   

sparc64:
We are close to 11.000 installed packages.
 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?

   
I presume he is talking about source packages in the "installed" state 
in wana-build. For comparison this is currently 12153 for amd64 and 
10937 for mips.


(this leads to the interesting conclusion that about half the source 
packages in sid are arch-all only)

Bug#765639: Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

[peter green]

The dhparam thing is really about a default that if you generate
DH parameters that it defaults to 2048 instead of 1024.  This
shouldn't break anything itself, nor do I know of any other
software that would get broken by this.
Apparently Java 6 and 7 will fail to handshake if a server tries to use 
DH with larger than 1024 bit parameters (and Java 8 apparently fails 
with anything larger than 2048 bits which is not relavent to the current 
discussion but is sad anyway). This is especially an issue with Java 6 
which does not support ECDH (most configurations put ECDH above DH in 
the ciphersuite preferences so java 7 ends up using ECDH).


Personally I think the security advantages of moving away from 1024 bit 
DH (which is probablly breakable with nsa level resources) outweigh this 
breakage (especially as afaict changing the defaults for parameter 
generation will only impact new installs not upgrades) but it is 
probablly something that should be documented.

Re: ongoing libkdegames transition.

[peter green]

On 17/10/15 10:48, Maximiliano Curia wrote:

Hi,

On 17/10/15 03:55, peter green wrote:
   

There appears to be a transition going on with the libkdegames source
package which seems to require sourceful changes in the rdeps. A
substantial number of rdeps have transitioned but a substantial number have
not and no bug reports seem to have been filed on said rdeps, nor does
there seem to be a transition tracker.
 

The new package names (kf5 versions) don't clash with the old ones and the so
files have different lib names, so a transition is not really needed, at least
not in the way that the release team tracks them. It would have been better if
we had upload the new lib with a different source name.

Agreed.


Is there any other package affected by this?
   

Yes, quite a few.
https://ftp-master.debian.org/cruft-report-daily.txt
* source package libkdegames version 4:15.08.0-1 no longer builds
  binary package(s): kde-games-core-declarative libkdegames-dev 
libkdegames6abi1 libkdegames6abi1-dbg libkdegamesprivate1abi1
  on 
amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x

  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by libkdegames)" -s 
unstable -a 
amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x 
-p -R -b kde-games-core-declarative libkdegames-dev libkdegames6abi1 
libkdegames6abi1-dbg libkdegamesprivate1abi1

  - broken Depends:
kgoldrunner: kgoldrunner
kigo: kigo
klickety: klickety
kmahjongg: kmahjongg
knavalbattle: knavalbattle
knetwalk: knetwalk
knights: knights
kolf: kolf
konquest: konquest
kreversi: kreversi
kshisen: kshisen
ksirk: ksirk
ksnakeduel: ksnakeduel
kspaceduel: kspaceduel
ksudoku: ksudoku
ktuberling: ktuberling
kubrick: kubrick
lskat: lskat
tagua: tagua
  - broken Build-Depends:
bomber: libkdegames-dev (>= 4:4.11)
bovo: libkdegames-dev (>= 4:4.11)
granatier: libkdegames-dev (>= 4:4.11)
kajongg: libkdegames-dev (>= 4:4.11)
kapman: libkdegames-dev (>= 4:4.11)
katomic: libkdegames-dev (>= 4:4.11)
kblackbox: libkdegames-dev (>= 4:4.11)
kblocks: libkdegames-dev (>= 4:4.11)
kbounce: libkdegames-dev (>= 4:4.11)
kbreakout: libkdegames-dev (>= 4:4.11)
kdiamond: libkdegames-dev (>= 4:4.11)
kfourinline: libkdegames-dev (>= 4:4.11)
kgoldrunner: libkdegames-dev (>= 4:14.12.2)
kigo: libkdegames-dev (>= 4:14.12.0)
killbots: libkdegames-dev (>= 4:4.11)
kiriki: libkdegames-dev (>= 4:4.11)
kjumpingcube: libkdegames-dev (>= 4:4.11)
klickety: libkdegames-dev (>= 4:4.11)
klines: libkdegames-dev (>= 4:4.11)
kmahjongg: libkdegames-dev (>= 4:14.12.2)
kmines: libkdegames-dev (>= 4:4.11)
knavalbattle: libkdegames-dev (>= 4:4.11)
knetwalk: libkdegames-dev (>= 4:4.11)
knights: libkdegames-dev (> 4:4.9)
kolf: libkdegames-dev (>= 4:14.12.2)
kollision: libkdegames-dev (>= 4:4.11)
konquest: libkdegames-dev (>= 4:14.12.2)
kpat: libkdegames-dev (>= 4:4.11)
kreversi: libkdegames-dev (>= 4:14.12.2)
kshisen: libkdegames-dev (>= 4:4.11)
ksirk: libkdegames-dev (>= 4:4.11)
ksnakeduel: libkdegames-dev (>= 4.9.0~)
kspaceduel: libkdegames-dev (>= 4:4.11)
ksquares: libkdegames-dev (>= 4:4.11)
ksudoku: libkdegames-dev (>= 4:14.12.2)
ktuberling: libkdegames-dev (>= 4:4.11)
kubrick: libkdegames-dev (>= 4:4.11)
libkmahjongg: libkdegames-dev (>= 4:14.12.2)
lskat: libkdegames-dev (>= 4:14.12.2)
palapeli: libkdegames-dev (>= 4:14.12.2)
picmi: libkdegames-dev (>= 4:4.11)
tagua: libkdegames-dev (>= 4:4.10.0)

I find it curious that there are more significantly more broken 
build-depends than broken depends, maybe some of those build-depends are 
bogus.


   

As a deriviative maintainer I'd like to know what the rough plans and
timescales are here so I can consider the best way to handle this
downstream.
 

Do you have a preferred solution in mind?
   
IMO if it is likely that some packages will take significant time to 
migrate to the new kdegames kf5 then introducing a new

libkdegames-kde4 source package is probablly the way to go.

ongoing libkdegames transition.

[peter green]

There appears to be a transition going on with the libkdegames source 
package which seems to require sourceful changes in the rdeps. A 
substantial number of rdeps have transitioned but a substantial number 
have not and no bug reports seem to have been filed on said rdeps, nor 
does there seem to be a transition tracker.


The new kdegames package has migrated to testing, presumablly under 
"smooth updates" leaving out of data packages in testing.



As a deriviative maintainer I'd like to know what the rough plans and 
timescales are here so I can consider the best way to handle this 
downstream.

Bug#802031: nmu: pytaglib_0.3.6+dfsg-2 (arm64/ppc64el)

[peter green]

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

Libstdc++6 declares a breaks on python3-taglib (<= 0.3.6+dfsg-2+b2), 
presumablly as part of the  big c++ ABI transition. However the binnmu 
versions are out of sync across architectures leaving python3-taglib
uninstallable on arm64 and ppc64el.

This binnmu will bring the binary version back into sync and hence make the
package installable on arm64 and ppc64el again.

nmu 4 pytaglib_0.3.6+dfsg-2 . arm64 ppc64el . -m "version sync for libstdc++ 
breaks"

-- System Information:
Debian Release: 6.0.3
  APT prefers squeeze-lts
  APT policy: (500, 'squeeze-lts'), (500, 'oldstable'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Bug#798198: nmu: psi4_4.0~beta5+dfsg-2

[Peter Green]

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

There were problems with using psi4 built with gcc-4.9 with a gcc-5
libstdc++6. As a result a breaks was added to libstdc++6 and psi4 was 
binnmu'd.


However the binnmus on arm64 and ppc64el were built with a +b1 suffix 
while those on other architectures were built with a +b2 suffix. Since 
the breaks is declared on psi4 (<= 4.0~beta5+dfsg-2+b1) this means that 
the package is uninstallable on arm64 and ppc64el.


I think the neatest solution is to re-binnmu the package on
arm64 and ppc64el and hence bring the binnmu suffix back into sync 
across all release architectures and make the package installable on 
arm64 and ppc64el.


nmu innoextract_1.4-1 . arm64 ppc64el . -m "Rebuild for the gcc5 
transition."


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#791824: nmu: starpu_1.1.4+dfsg-1

[peter green]

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

nmu starpu_1.1.4+dfsg-1 . ALL . -m Rebuild for gcc 4.9.3

starpu seems to have a strict dependency against the version of gcc-4.9 it was
built against. This is blocking the migration of 4.9.3 to testing.

-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'oldoldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150708175539.12957.44536.reportbug@localhost

Bug#789365: Re: Bug#789365: transition: ghc-7.8

[peter green]

This may need a binNMU:

haskell-trifecta (1.4.3-1 to 1.5.1.3-4)
 Maintainer: Debian Haskell Group
 9 days old (needed 5 days)
 libghc-trifecta-dev/ppc64el unsatisfiable Depends: 
libghc-charset-dev-0.3.7.1-1690c
 libghc-trifecta-dev/ppc64el unsatisfiable Depends: 
libghc-comonad-dev-4.2.5-c2e64
 libghc-trifecta-dev/ppc64el unsatisfiable Depends: 
libghc-lens-dev-4.6.0.1-21811
 libghc-trifecta-dev/ppc64el unsatisfiable Depends: 
libghc-reducers-dev-3.10.3.1-db618
 libghc-trifecta-dev/ppc64el unsatisfiable Depends: 
libghc-semigroups-dev-0.15.3-77447
 libghc-trifecta-prof/ppc64el unsatisfiable Depends: 
libghc-charset-prof-0.3.7.1-1690c
 libghc-trifecta-prof/ppc64el unsatisfiable Depends: 
libghc-comonad-prof-4.2.5-c2e64
 libghc-trifecta-prof/ppc64el unsatisfiable Depends: 
libghc-lens-prof-4.6.0.1-21811
 libghc-trifecta-prof/ppc64el unsatisfiable Depends: 
libghc-reducers-prof-3.10.3.1-db618
 libghc-trifecta-prof/ppc64el unsatisfiable Depends: 
libghc-semigroups-prof-0.15.3-77447
It looks like a binnmu for haskell-trifecta has already been scheduled 
on ppc64el but it's in BD-Uninstallable.



haskell-trifecta build-depends on:
- ppc64el:libghc-parsers-dev (= 0.12.1)
ppc64el:libghc-parsers-dev depends on missing:
- ppc64el:libghc-charset-dev-0.3.7.1-1690c


It looks like haskell-parsers was not binnmud on ppc64el when it was 
binnmud on other architectures for a new version of haskell-charset. 
Checking dose.debian.net it appears it's build-depends are also 
uninstallable (though this information may be out of date).


https://qa.debian.org/dose/debcheck/src_unstable_main/1435122003/packages/haskell-parsers.html#8fad47a6199cea33228738dfa0983c1c


src:haskell-parsers (0.12.1.1-3) [PTS] [ctrl]
   ? libghc-charset-dev (= 0.3)
libghc-charset-dev (0.3.7.1-2+b1) [PTS] [ctrl]
   ? libghc-semigroups-dev-0.15.3-77447
MISSING


Checking haskell-charset it appears it has been binnmu'd for the new 
semigroups on all architectures but the ppc64el build was built much 
later than the others.

Re: Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.

[peter green]

Reopen 782976
Thanks.

On 24/04/15 22:49, Jonathan Wiltshire wrote:

On Mon, Apr 20, 2015 at 02:17:25AM +0100, peter green wrote:
   

Release team: can you clarify whether you intend to actually remove kfreebsd
from the jessie suite of the official archive before/during the jessie
release?
 

Yes.
   
Which if my understanding of the code is correct means that 
debian-installer-netboot-images will ftbfs because it will no longer be 
able to retrive the kfreebsd images. It could presumablly be modified to 
look in an unofficial location but as I said in the initial mail of this 
bug I don't belive that complies with the rc policy.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553ac563.8060...@p10link.net

Re: Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.

[peter green]

Release team: theres a question for you at the end of the mail.

On 20/04/15 00:49, Cyril Brulebois wrote:

peter greenplugw...@p10link.net  (2015-04-20):
   

Package: debian-installer-netboot-images
Severity: serious

The RC policy states Packages must be buildable within the same release..
In this context I interpret buildable as buildable from actual sourcecode
(not just package together) and the same release as the collection of
stuff that Debian will be officially releasing as jessie.
 

So you meant to file a bug against debian-installer rather than d-i-n-i?
   
AIUI the overall process goes as follows (please correct me if any of 
this is wrong).


1: various source packages in debian build udebs. Building the source 
package for architecture foo produces debs and udebs for archicture foo.
2: the debian-installer source package uses those udebs to build 
installer images, again building debian-installer for architecture foo 
produces installation images for architecture foo. The installation 
images are placed in a special place in the archive.
3: Building the debian-installer-netboot-images source package 
retrives some of those images from their special place in the archive 
and packs them up into arch all packages.


If an architecture is removed from a release 1 and 2 will still be fine. 
3 OTOH will need manual changes to avoid shipping packages that cannot 
be rebuilt within the same release. AIUI if an architecture for which 
debian-installer-netboot-images packs the installer image in an arch 
all package is removed from the release then 
debian-installer-netboot-images will FTBFS.


I was mistaken on one thing though, despite the release teams mail 
months ago [1] saying that We are dropping it as an official release 
architecture it would appear that kfreebsd has not actually been 
removed from jessie at this point.


Release team: can you clarify whether you intend to actually remove 
kfreebsd from the jessie suite of the official archive before/during the 
jessie release?


[1] https://lists.debian.org/debian-devel-announce/2014/11/msg5.html


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553453a5.7000...@p10link.net

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

[peter green]

Jonathan Wiltshire wrote:

Looks ok to me.
  
Ok, the maintainer has now made an upload which is substantially the 
same* as my proposal. The upload has built successfully on all release 
architectures.


unblock xfce4-notes-plugin/1.7.7-5

* he reworeded the changelog entry, used a non-nmu version number and 
put --with autotools_dev before --parallel rather than after it on the 
command line.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5469d612.50...@p10link.net

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

[peter green]

Control: tag -1 -moreinfo

I think you meant the non-attatched debdiff. ;p
  

Doh, here it is.
diff -Nru xfce4-notes-plugin-1.7.7/debian/changelog 
xfce4-notes-plugin-1.7.7/debian/changelog
--- xfce4-notes-plugin-1.7.7/debian/changelog   2014-10-15 19:19:50.0 
+
+++ xfce4-notes-plugin-1.7.7/debian/changelog   2014-11-10 20:16:01.0 
+
@@ -1,3 +1,13 @@
+xfce4-notes-plugin (1.7.7-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use --with autotools_dev to fix build on arm64 (Really closes: 765272)
++ note: the changelog entry for 1.7.7-4 claims that autoreconf was
+  introduced in that version but it seems that this change did not actually
+  happen.
+
+ -- Peter Michael Green plugw...@debian.org  Mon, 10 Nov 2014 20:13:49 +
+
 xfce4-notes-plugin (1.7.7-4) unstable; urgency=low
 
   [ Evgeni Golov ]
diff -Nru xfce4-notes-plugin-1.7.7/debian/control 
xfce4-notes-plugin-1.7.7/debian/control
--- xfce4-notes-plugin-1.7.7/debian/control 2014-10-15 19:09:15.0 
+
+++ xfce4-notes-plugin-1.7.7/debian/control 2014-11-10 20:13:13.0 
+
@@ -6,7 +6,7 @@
 Build-Depends: autotools-dev, debhelper (= 9), xfce4-panel-dev, libxml2-dev,
  libxml-parser-perl, intltool, libx11-dev, pkg-config, libgtk2.0-dev,
  libxfcegui4-dev, libxfconf-0-dev, libunique-dev, xfce4-dev-tools, automake,
- libtool
+ libtool, autotools-dev
 Standards-Version: 3.9.6
 Homepage: http://goodies.xfce.org/projects/panel-plugins/xfce4-notes-plugin
 Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/xfce4-notes-plugin/
diff -Nru xfce4-notes-plugin-1.7.7/debian/rules 
xfce4-notes-plugin-1.7.7/debian/rules
--- xfce4-notes-plugin-1.7.7/debian/rules   2013-08-19 08:51:00.0 
+
+++ xfce4-notes-plugin-1.7.7/debian/rules   2014-11-10 20:12:49.0 
+
@@ -14,4 +14,4 @@
dh_makeshlibs -n -X /usr/lib/xfce4/panel-plugins
 
 %:
-   dh $@ --parallel
+   dh $@ --parallel --with autotools_dev

Bug#769371: unblock: umockdev/0.8.8-2

[peter green]

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

Please unblock package umockdev

Version 0.8.8-1 of umockdev failed to build on arm64 with a testsuite failure
and as a result we currently have an out of data umockdev in arm64 testing.

The bug was traced to udevadm producing debug output on stderr when the debug
kernel command line parameter is in use (as appears to be the case on the arm64
boxes). Version 0.8.8-2 modifies the test to ignore stderr.

A debdiff is attached.

unblock umockdev/0.8.8-2

-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru umockdev-0.8.8/debian/changelog umockdev-0.8.8/debian/changelog
--- umockdev-0.8.8/debian/changelog	2014-09-22 07:41:46.0 +
+++ umockdev-0.8.8/debian/changelog	2014-11-12 09:21:56.0 +
@@ -1,3 +1,13 @@
+umockdev (0.8.8-2) unstable; urgency=medium
+
+  * Add 00git_ignore_udev_debug.patch: Ignore stderr from udevadm info, to
+avoid udev debug message spew on stderr if udev debugging is enabled. In
+particular, this works around #769228 which causes an FTBFS on ARM.
+(Closes: #767909)
+  * Bump Standards-Version to 3.9.6 (no changes necessary).
+
+ -- Martin Pitt mp...@debian.org  Wed, 12 Nov 2014 10:21:52 +0100
+
 umockdev (0.8.8-1) unstable; urgency=medium
 
   * New upstream bug fix release which fixes test failures.
diff -Nru umockdev-0.8.8/debian/control umockdev-0.8.8/debian/control
--- umockdev-0.8.8/debian/control	2014-09-22 07:41:46.0 +
+++ umockdev-0.8.8/debian/control	2014-11-12 09:21:56.0 +
@@ -23,7 +23,7 @@
 Homepage: https://github.com/martinpitt/umockdev/
 Vcs-Git: git://git.debian.org/git/collab-maint/umockdev.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/umockdev.git
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 
 Package: umockdev
 Architecture: any
diff -Nru umockdev-0.8.8/debian/patches/00git_ignore_udev_debug.patch umockdev-0.8.8/debian/patches/00git_ignore_udev_debug.patch
--- umockdev-0.8.8/debian/patches/00git_ignore_udev_debug.patch	1970-01-01 00:00:00.0 +
+++ umockdev-0.8.8/debian/patches/00git_ignore_udev_debug.patch	2014-11-12 09:21:56.0 +
@@ -0,0 +1,41 @@
+From b6219cd671bb1b7e8f8a48a0547164d4dbaffc41 Mon Sep 17 00:00:00 2001
+From: Martin Pitt martin.p...@ubuntu.com
+Date: Wed, 12 Nov 2014 10:13:06 +0100
+Subject: [PATCH] umockdev-record: Ignore stderr from udevadm info
+
+This avoids udev debug message spew on stderr if udev debugging is enabled.
+
+https://bugs.debian.org/767909
+---
+ src/umockdev-record.vala | 6 +++---
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/umockdev-record.vala b/src/umockdev-record.vala
+index ccb4337..421932e 100644
+--- a/src/umockdev-record.vala
 b/src/umockdev-record.vala
+@@ -222,7 +222,7 @@ record_device(string dev)
+ debug(recording device %s, dev);
+ 
+ // we start with udevadm dump of this device, which will include all udev properties
+-string u_out;
++string u_out, u_err;
+ int exitcode;
+ try {
+ Process.spawn_sync(null,
+@@ -231,10 +231,10 @@ record_device(string dev)
+SpawnFlags.SEARCH_PATH,
+null,
+out u_out,
+-   null,
++   out u_err,
+out exitcode);
+ if (exitcode != 0)
+-throw new SpawnError.FAILED(udevadm exited with code %i.printf(exitcode));
++throw new SpawnError.FAILED(udevadm exited with code %i\n%s.printf(exitcode, u_err));
+ } catch (Error e) {
+ exit_error(Cannot call udevadm: %s, e.message);
+ }
+-- 
+2.1.3
+
diff -Nru umockdev-0.8.8/debian/patches/series umockdev-0.8.8/debian/patches/series
--- umockdev-0.8.8/debian/patches/series	2014-09-22 07:41:46.0 +
+++ umockdev-0.8.8/debian/patches/series	2014-11-12 09:21:56.0 +
@@ -0,0 +1 @@
+00git_ignore_udev_debug.patch

Bug#769044: unblock (pre-approval): xfce4-notes-plugin

[peter green]

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

I'm seeking approval for fixing the arm64 build failure in xfce4-notes-plugin.
The package FTBFS due to outdated config.sub/guess.

The maintainer doesn't have a problem with the changes but wants approval from
the release team before going ahead.

The attatched debdiff uses --with autotools_dev to update config.sub and 
config.guess unconditionally . If you would preffer a different approach to
updating them please tell me.

-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141110231846.9664.1233.reportbug@localhost

Bug#767759: unblock: tightvnc/1.3.9-6.5

[peter green]

Tags 767759 -moreinfo
Thanks

peter green wrote:
The package is now uploaded and built on all release architectures 
except mips. On mips it's currently sitting in needs-build.

The package is now built successfully on all release architectures


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5459359f.7050...@p10link.net

Bug#767895: TPU binnmus for arm64 and ppc64el

[peter green]

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

When looking through the list of packages that are uninstallable in arm64
testing I belive the following TPU binnmus are appropriate towards the goal
of pushing the list of uninstallable arch specific binaries in arm64 testing
to zero. Looking further it seems seed could also do with a TPU binnmu on
ppc64el.

nmu openvpn_2.3.2-9 . arm64 . -m build for testing -d 'testing'
nmu cython_0.20.1+git90-g0e6e38e-1 . arm64 . -m build for testing -d 'testing'
nmu seed_3.2.0-2 . arm64 ppc64el . -m build for testing -d 'testing'

All of the above packages are needed as depedencies for packages already in 
arm64 testing and have newer upstream versions stuck in sid.


-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103110841.12577.53799.reportbug@localhost

Bug#767759: unblock: tightvnc/1.3.9-6.5

[peter green]

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

Please unblock package tightvnc

This upload of tightvnc adds arm64 support to the packages build system. The
code is all behind conditionals so it shouldn't affect other architectures.

This is needed to make tcos-core and a bunch of arch all packages installable
in arm64 testing. Debdiff attatched.

unblock tightvnc/1.3.9-6.5

-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog	2012-06-07 09:59:04.0 +
+++ tightvnc-1.3.9/debian/changelog	2014-11-02 13:00:10.0 +
@@ -1,3 +1,11 @@
+tightvnc (1.3.9-6.5) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainers permission.
+  * Add patch from 1.3.9-6.4ubuntu1 by Colin Watson for arm64 support.
+(Closes: 767311)
+
+ -- Peter Michael Green plugw...@debian.org  Wed, 29 Oct 2014 21:47:46 +
+
 tightvnc (1.3.9-6.4) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru tightvnc-1.3.9/debian/patches/aarch64.patch tightvnc-1.3.9/debian/patches/aarch64.patch
--- tightvnc-1.3.9/debian/patches/aarch64.patch	1970-01-01 00:00:00.0 +
+++ tightvnc-1.3.9/debian/patches/aarch64.patch	2014-10-29 21:46:09.0 +
@@ -0,0 +1,39 @@
+Description: Add aarch64 (arm64) support
+Author: Colin Watson cjwat...@ubuntu.com
+Forwarded: no
+Last-Update: 2014-03-18
+
+Index: b/Xvnc/config/cf/Imake.cf
+===
+--- a/Xvnc/config/cf/Imake.cf
 b/Xvnc/config/cf/Imake.cf
+@@ -700,6 +700,10 @@
+ #   define s390Architecture
+ #  undef __s390__
+ # endif /* s390 */
++# ifdef __aarch64__
++#  define AArch64Architecture
++#  undef __aarch64__
++# endif /* __arch64__ */
+ # ifdef __alpha
+ #  define AlphaArchitecture
+ #  undef __alpha
+Index: b/Xvnc/config/cf/linux.cf
+===
+--- a/Xvnc/config/cf/linux.cf
 b/Xvnc/config/cf/linux.cf
+@@ -305,6 +305,14 @@
+ #define ServerExtraDefines	-DGCCUSESGAS XFree86ServerDefines
+ #endif /* PowerPCArchitecture */
+ 
++#ifdef AArch64Architecture
++#define DefaultCCOptions	-fsigned-char
++#define OptimizedCDebugFlags	-O2
++#define LinuxMachineDefines	-D__aarch64__
++#define ServerOSDefines		XFree86ServerOSDefines -DDDXTIME -DPART_NET
++#define ServerExtraDefines	-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64
++#endif /* AArch64Architecture */
++
+ #ifdef ArmArchitecture
+ #define DefaultCCOptions	-fsigned-char
+ #define OptimizedCDebugFlags	-O2
diff -Nru tightvnc-1.3.9/debian/patches/series tightvnc-1.3.9/debian/patches/series
--- tightvnc-1.3.9/debian/patches/series	2012-06-07 09:54:59.0 +
+++ tightvnc-1.3.9/debian/patches/series	2014-10-29 21:46:09.0 +
@@ -2,3 +2,4 @@
 20-vncviewer--vncviewer.man.patch
 30-ftbfs-mips.patch
 debian-changes-1.3.9-6.1
+aarch64.patch

Bug#767759: unblock: tightvnc/1.3.9-6.5

[peter green]

Jonathan Wiltshire wrote:

Control: tag -1 moreinfo

On Sun, Nov 02, 2014 at 01:55:30PM +, peter green wrote:
  

This upload of tightvnc adds arm64 support to the packages build system. The
code is all behind conditionals so it shouldn't affect other architectures.

This is needed to make tcos-core and a bunch of arch all packages installable
in arm64 testing. Debdiff attatched.

diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog 2012-06-07 09:59:04.0 +
+++ tightvnc-1.3.9/debian/changelog 2014-11-02 13:00:10.0 +
@@ -1,3 +1,11 @@
+tightvnc (1.3.9-6.5) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainers permission.
+  * Add patch from 1.3.9-6.4ubuntu1 by Colin Watson for arm64 support.
+(Closes: 767311)
+
+ -- Peter Michael Green plugw...@debian.org  Wed, 29 Oct 2014 21:47:46 +



This doesn't appear to be in sid yet?
  
Sorry I sent the bugreport as soon as dput had finished uploading to 
incoming which was evidently a bit too early.


The package is now uploaded and built on all release architectures 
except mips. On mips it's currently sitting in needs-build.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5456b72e.3020...@p10link.net

Bug#767714: nmu: lhapdf_5.9.1-3

[peter green]

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

nmu lhapdf_5.9.1-3 . arm64 . -m Rebuild against octave 3.8

The lhapdf package on arm64 was actually built against octave 3.8, unfortunately
it's not installable because octave declares Breaks: octave-lhapdf (= 5.9.1-3).
This binnmu will bring the binary version of the package on arm64 into line
with other architectures and hence avoid the breaks.

I did consider trying to explain this in the binnmu changelog reason but
I decided it was probablly less confusing to users just to use the same
binnmu changelog reason as on the other architectures.

-- System Information:
Debian Release: 6.0.3
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102021958.26742.99114.reportbug@localhost

Re: Debian/ppc64el feasiability to become an official architecture

[peter green]

Breno Leitao wrote:

Hi Peter,

Thank you for your reply.

On 07/24/2014 08:14 PM, peter green wrote:
  

Note: this is the perspective of a dd who is not directly involved with powerc
though I have come across some of your bug reports, nor am I a member of the ftp
or release teams. It's probablly mostly right but i'm sure others will point out
any errors.



I would like to share the ppc64el port's status with you, and check if
it is feasible to consider it as an official port for the next Debian
release, or, what it may be missing for that.
  

quite a bit needs to be done and I personally think it's unlikely any new
architectures will make it in time for the jessie freeze at this point.

The first step is going to be persuading the ftp masters to let you into the
debian archive. You can see the ftpmasters critera at
https://ftp-master.debian.org/archive-criteria.html .


Right, as I understand we are on track to meet all those criteria. We have a 
good
archive coverage, a debian installer, fast machines doing the build, and, 
finally
a DD helping us.

  

It sounds like the main
thing you will need to do to meet them is push your fixes into debian proper so
ppc64el can be built without external patches.


Right?.What do you  mean by built? We have a huge amount of packages building 
for
ppc64el without external patches. At this time, we already built more than 8k8
source architecture-dependent packages (of almost 10K)  for this platform[1]

Also, the debootstrap packages are all BFS on ppc64el, and if you want a
environment that contains git, openjdk, ssh, vim and latex, less than 10 bugs 
need
to be accepted[2]

[1] 
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/Uploaded.html
[2] https://wiki.debian.org/ppc64el/topBugs
  
I intepret the must be built without external patches as it must be 
possible to have a self-contained subset of debian where all packages 
can be built  on your architecture from pure debian source packages and 
where all build-dependencies are satisfiable.



When you are added to testing you will be added as a broken and fucked 
(release
team's terminology not mine) architecture. To get out of this state you will 
need
to get and keep your port in a healthy state in testing. That will mean fixing 
(in
some cases through NMUs) issues that are blocking migration of packages you need
(whether or not those issues are related to your architecture) and fixing any
architecture specific build failures as quickly as possible (since when you are 
in
the broken and fucked state your builds will not be blockers for testing
migration so a new upload that breaks your architecture will be able to 
migrate).


Right. Do you recommend us to start building packages from 'testing' right now?
We can create another buildd instances that only build testing and we can see 
how
healthy it is.
  
There isn't a lot of point IMO.  Your ports health in debian testing  
will be  more related to it's health in debian unstable than to it's 
health in a seperate rebuild of testing since the main way testing is 
updated is through migrations of source and binaries from unstable.


The key thing is that binaries only migrate from unstable to testing 
either alongside source packages or when the source version in testing 
and unstable matches. What this means is that an architecture newly 
added to testing will be missing many packages. To get those packages 
into place generally means getting their version in testing and unstable 
into sync and that can mean fixing bugs that are not only not specific 
to your architecture but don't even directly affect it.


It's technically possible to add binaries to testing for a package where 
testing and unstable are out of sync by binnmuing to TPU but AIUI the 
release team don't like this to be done on a routine basis.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d4300d.7000...@p10link.net

Re: Debian/ppc64el feasiability to become an official architecture

[peter green]

Lennart Sorensen wrote:

On Fri, Jul 25, 2014 at 12:14:08AM +0100, peter green wrote:
  

Another question the ftpmasters will likely have is what is the
relationship between ppc64 and ppc64el. Is there hardware that will
run ppc64 but not ppc64el? is there hardware that will run ppc64el
but not ppc64? is there hardware that will run both? what is the
relative prevalance of each of these. If most hardware that can run
ppc64el can also run ppc64 then are there significant technical
advantages other than compatibility with badly written software of
going little endian?



There is no ppc64 in Debian.
Not in debian proper but it is on debian-ports.org and it appears to be 
pretty healthy.




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d2985d.20...@p10link.net

re: Debian/ppc64el feasiability to become an official architecture

[peter green]

Note: this is the perspective of a dd who is not directly involved with 
powerc though I have come across some of your bug reports, nor am I a 
member of the ftp or release teams. It's probablly mostly right but i'm 
sure others will point out any errors.



I would like to share the ppc64el port's status with you, and check if
it is feasible to consider it as an official port for the next Debian
release, or, what it may be missing for that.
quite a bit needs to be done and I personally think it's unlikely any 
new architectures will make it in time for the jessie freeze at this point.


The first step is going to be persuading the ftp masters to let you into 
the debian archive. You can see the ftpmasters critera at 
https://ftp-master.debian.org/archive-criteria.html . It sounds like the 
main thing you will need to do to meet them is push your fixes into 
debian proper so ppc64el can be built without external patches. Merely 
submitting patches to the BTS for issues specific to your architecture 
is not sufficient. You will almost certainly have to perform 
non-maintainer uploads (NMUs) to deal with unresponsive maintainers. 
While in principle you can ask for sponsorship for NMUs if you want to 
actually get things moving in a reasonable timeframe you will need at 
least one Debian Developer (DD) on your team to upload them.


You will also need at least one DD on the port team to satisfy the 
ftpmaster critera. Ideally you want more.


Another question the ftpmasters will likely have is what is the 
relationship between ppc64 and ppc64el. Is there hardware that will run 
ppc64 but not ppc64el? is there hardware that will run ppc64el but not 
ppc64? is there hardware that will run both? what is the relative 
prevalance of each of these. If most hardware that can run ppc64el can 
also run ppc64 then are there significant technical advantages other 
than compatibility with badly written software of going little endian?


It's not strictly a requirement but it would likely help immensely to 
get the architecture on debian-ports.org so that maintainers can easilly 
see if their packages are failing and porters for other new ports (i've 
been helping out a bit with arm64 myself) can see if ppc64el is also 
failing.


If and when the ftpmasters decide to include your architecture a minimal 
set of packages will be imported and everything (including when possible 
the minimal set) must be rebuilt. This will take time and will likely 
involve more NMUs. It is likely you will need to NMU to fix issues that 
are not strictly related to your port but are nevertheless blocking your 
build.


Once you are in the official archive and have rebuilt (nearly) 
everything you need to convince the release team that you meet the 
release critera. You can find the full details at 
https://release.debian.org/wheezy/arch_policy.html but the main ones are 
you have to have built almost all of debian*, you have to have a working 
installer, you have to actually have users and developers of the debian 
port, you have to be keeping up (which means both having plenty of build 
hardware AND stomping on architecture specific build failures)


When you are added to testing you will be added as a broken and fucked 
(release team's terminology not mine) architecture. To get out of this 
state you will need to get and keep your port in a healthy state in 
testing. That will mean fixing (in some cases through NMUs) issues that 
are blocking migration of packages you need (whether or not those issues 
are related to your architecture) and fixing any architecture specific 
build failures as quickly as possible (since when you are in the broken 
and fucked state your builds will not be blockers for testing migration 
so a new upload that breaks your architecture will be able to migrate).


Once your port reaches a healty state in testing (most packages present, 
virtually no packages outdated, very few architecture specific packages 
uninstallable), the release team will remove the broken and fucked 
status and you will become a release architecture. You then need to 
maintain your port in a healthy condition until release time.


*the release team say 98% but that number excludes certain poorly 
defined categories of package and so there is no easy way to measure it. 
Going by the statss on buildd.debian.org (which include everything 
including packages that are fundamentally architecture specific) the 
lowest release linux architecture according is currently at about 96% 
while kfreebsd is at about 90%. Realistically you probablly need to at 
least match the lowest release linux architecture.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d19340.9020...@p10link.net

p11-kit needs binnmu on kfreebsd-* for new libc0.1

[peter green]

While looking at the buildd pages for liblas I noticed the following 
BD-Uninstallable explanation for kfreebsd-*

liblas build-depends on:
- libgdal-dev (= 1.10.0~)
libgdal-dev depends on:
- libcurl4-gnutls-dev
libcurl4-gnutls-dev depends on:
- libgnutls-dev
libgnutls-dev depends on:
- libgnutls26 (= 2.12.23-12)
libgnutls26 depends on:
- libp11-kit0 (= 0.11)
libp11-kit0 depends on missing:
- libc0.1 ( 2.18)

I would guess that this dependency was caused by use of private glibc symbols. 
The package was already binnmu'd on hurd for the new eglibc (linux does not 
seem to be affected).


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309482f.6040...@p10link.net

Please binnmu numpy to support python 3.4

[peter green]

While looking at build failures in raspbian I noticed that numpy could 
not be imported in python 3.4 ( 
http://buildd.raspbian.org/status/fetch.php?pkg=pandasarch=armhfver=0.13.1-2stamp=1392881756 
) . I confirmed that this was not a raspbian specific issue by testing 
on debian armel.


I brought this up in debian-python and was told a binnmu was probablly 
needed to add support for python3.4. I binnmu'd the package in raspbian 
and confirmed that doing so fixed the issue. Can you binnmu it in debian 
as well.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530661ac.1090...@p10link.net

Bug#731261: transition: Qt5 switching qreal == double for all platforms

[peter green]

Please check qgis, that did FTBFS on arm* with
  deduced conflicting types for parameter 'const T' ('double' and 'qreal {aka 
float}')
  
qgis seems to be using qt4. The qreal==double on all platforms switch 
was only for qt5 (it's way too late to make such a change in qt4 now).



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f328a1.6050...@p10link.net

Bug#731902: nmu: transmission_2.82-1

[peter green]

Julien Cristau wrote:

That'll hopefully fix itself (or at least get better) once qt 5.2 hits
sid, as that's built on many more archs.
  
QT 5.2 has now hit sid but transmission is still in bd-uninstallable on 
four release architectures where it has built in the past.


kfreebsd-*: blocked by build-dependency on libsystemd-daemon-dev
 AIUI systemd is intentionally linux specific
 bug filed against transmission with patch to make systemd stuff linux only
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737366

mipsel: blocked by build-dependency on qttools5-dev-tools. 
qttools-opensource-src is in state needs-build

 Hopefully this one will clear itself with no action needed.

powerpc: blocked by build-dependency on qttools5-dev-tools.
 qttools-opensource-src failed to build with a symbols file error,
 bug failed against qttools-opensource-src
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737358


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ed9ed2.90...@p10link.net

Re: A new metric for source package importance in ports

[peter green]

Johannes Schauer wrote:

Hi,

the following is a report of a successful implementation of what I have been
talking about with Niels Thykier during debconf13. The question was how
important it is for a source package to be compilable or exist in the first
place given an incomplete port which is in the process of being bootstrapped.
This work is solving a different purpose than the identification of key
packages by Lucas Nussbaum [1]. Instead of attaching a binary value to each
source package, this method is associating integer values to them. Once
bootstrapping of the whole archive becomes more important or even possible in
real life through an implementation of build profiles, this heuristic could be
used to further extend the meaning of key packages as well.

One problem with these metrics is that you get source packages whose
importance is artifically inflated because of the way our source
packages work. If anything in a source package needs x then the whole
source package has to build-depend on x.  Even if x is only needed for
some perhipheral functionlity that could easilly be removed in the event
that x was unavailable (either on a particular port or in general). In
the case of libraries there may be a binary dependency too for rarely
used fuctionality.

For example some of the mesa libraries drag in libwayland0 which means
wayland ends up with a very high importance even though afaict hardly
anyone uses it right now.

Another big example is languages. Lots of packages build language
bindings for lots of languages dragging those languages into the
important set.

So these metrics are a good guide to what packages are unimportant
but to determine whether a package is really important or just
psuedo-important still requires human judgement.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52968a89.6050...@p10link.net

Nullmailer can waste massive ammounts of bandwidth and is IMO unfit for release.

[peter green]

I just ran into a particularlly nasty instance of bug 329192

As described in that bug nullmailer ignores permanent errors, has an 
agressive retry policy and never times out messages stuck in the queue.


If a message that is too large for the smarthost to accept gets into the 
queue this can waste MASSIVE ammounts of bandwidth to the extent that I 
would expect mailserver admins to consider it network abuse. I just had 
multiple instances of nullmailer get stuck in this state and between 
them they were chewing up 20 megabits per second of bandwidth. 
Fortunately in this case I was the mailserver admin and the traffic was 
only running over a local vlan so there were no repercussions other than 
my time tracking down where the traffic was coming from but in other 
circumstances this could be far more serious either wasting large 
ammounts of paid bandwith, causing users to get banned from accessing 
their smarthost or both.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526ac89e.9060...@p10link.net

Re: Roll call for porters of architectures in sid and testing

[peter green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have an interest in debian on arm devices. My main interest in such 
devices

is for their ability to act as (relatively) low power gateways between
embedded hardware and networks such as the internet.

I helped with bringing armhf up to release architecture status through 
fixing

build failures and then once testing migration started pushing on
uninstallability and outdated package in testing issues.

Recently my efforts have been focussed on running raspbian which is a 
rebuild

of debian armhf with reduced minimum CPU requirements. I do not know how
much time I can commit to the official arm ports over the next release 
cycle

but would hope to stay involved with them at some level.

While I did manage to port freepascal to armhf I do not have any deep 
knowlege

of toolchain internals and thus can't really help on the toolchain side.

I am a DD

Peter Michael Green (plugwash)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJSKhPZAAoJEAxI6ip6j/174uIP/1wPohqu3zSoD70RIERvxE7g
nyIq/sYkbN/E2Dp2KIrS1YajzsSvVXT9DC75iKmsE7D2W3dx+cGi+AyUR2QzuClO
xmPg29AHNBS8Atd3dI0+OLKHZdy7ykO2XsXpuYGBBQLRa7pxsoWCYMCdZThiPBmj
luW1SLwSZ8gISHRblp4RxG9gMvhSrZtefOtVfusN8LX4BpphY366WBC0X79gVal7
W6oR0pWzfBWYkDEhZcn8JWpfW6ZbnSg5S8itqtuaoPkJEE7KmxA6rWKdOzLSJYTB
S/QbpBlH139eOTthOwboibnJVFG2raUtVFrfn40aX+ZLAETUxxh0/orx74KPel97
HczZ72DEUw0SD6sQ+xl/wWGA/JOd7u00Ry0DhKY/T5dj0/O2ucDGO1z3VDik6Eww
NwyMJ8j6q3Vv66UPzVNCWWxVLhsOa4gM9E4EhScADT9bNBzY9oHfufbRvnZ/UvPH
gfSuCI/uInGbl44XwqMYX9ugBEFCsH2OST/VQqEbEejWhg9J/mKiGB1OLp+8wjmb
RCSuOPv+2uHSu6jY56RdjOC+xjVOb2THJuYgc1IDdRsdP9aUqq/LpgQNPs8px7Ky
NBQ0WqMC/zk5s/VWGRTiBJ8N7k8YfM/8UloZPg1UzaMIpck8Ivb+wYVXQwoF4gT7
TUYASpzKW0Y9k2YiYDEa
=v9ta
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/522a1409.8050...@p10link.net

migration of libgeotiff-dfsg and liblas

[peter green]

I noticed libgeotiff-dfsg was not migrating to testing and discovered 
that the reason was that liblas needed updating to also use 
libtiff5-alt-dev. I prepared such an update and when I got no maintainer 
response I NMUd it. That NMU has now reached migration age but it 
doesn't seem to be getting migrated for some reason.


Can someone take a look at what is going on and either hint britney so 
that it migrates both source packages (they need to go in together) or 
tell me what else needs to be done in unstable.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f17be6.8070...@p10link.net

Bug#706866: transition: libarchive

[peter green]

I am requesting a transition from libarchive12 to libarchive13. libarchive13
is from the latest release of libarchive (3.1.2). A soname bump was done
upstream due to some ABI changes, specifically with HFS support.
  
I notice the most recent experimental upload FTBFS on many architectures 
with testsuite failures. Have you investigated how serious those 
failures are? Do you have plans for fixing them before uploading to sid?



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518842df.1000...@p10link.net

Bug#706866: [Fwd: re: Bug#706866: transition: libarchive]

[peter green]

Forwarding reply to my query to the bug report.

 Original Message 
Subject:re: Bug#706866: transition: libarchive
Date:   Mon, 6 May 2013 20:17:37 -0400
From:   Andres Mejia amejia...@gmail.com
To: peter green plugw...@p10link.net
References: 518842df.1000...@p10link.net



Yes, I plan on disabling lrzip support for now.

On May 6, 2013 7:55 PM, peter green plugw...@p10link.net 
mailto:plugw...@p10link.net wrote:



   I am requesting a transition from libarchive12 to libarchive13.
   libarchive13
   is from the latest release of libarchive (3.1.2). A soname bump
   was done
   upstream due to some ABI changes, specifically with HFS support.



   I notice the most recent experimental upload FTBFS on many
   architectures with testsuite failures. Have you investigated how
   serious those failures are? Do you have plans for fixing them before
   uploading to sid?


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518848be.40...@p10link.net

Bug#704769 Libarchive FTBFS on s390x sid buildds.

[peter green]

Package: libarchive
Version: 3.0.1b-1
Severity: serious

Note: this bug report is a continuation of discussions in the unblock
bug for libarchive (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704080 ).


my personal guess is that there's probably nothing s390x-specific to it,
it's probably broken with 64bit big endian. The d-ports build for
sparc64 fails as well.



Please also note that the current version (available in experimental for now)
seems to build ok on s390x (but fails on other platforms instead)..
Using git bisect should help identify the needed relevant changes.
  

I just noticed that the current s390x build was manually built on the
porterbox.  There hasn't been a successfull s390x sid buildd build for even
longer. See bug 659294

I just tried to build it on the s390x porterbox and it built
successfully :/

So I diffed the logs (- is the log from the buildd + is my log
from the porterbox). Highlights are below.

 65: test_read_disk_directory_traversals
-libarchive/test/test_read_disk_directory_traversals.c:1260: ARCHIVE_EOF != 
archive_read_next_header2(a, ae)
-   Description: There must be no entry
-libarchive/test/test_read_disk_directory_traversals.c:1263: File at has atime 
1364403708.0, expected 886622.0
-   Description: Atime should be restored
-libarchive/test/test_read_disk_directory_traversals.c:1524: Assertion failed: 
strcmp(archive_entry_pathname(ae), quot;nd/f2quot;) != 0
-   Description: File 'nd/f2' should be exclueded
-libarchive/test/test_read_disk_directory_traversals.c:1551: ARCHIVE_EOF != 
archive_read_next_header2(a, ae)
-   Description: There should be no entry
+libarchive/test/test_read_disk_directory_traversals.c:1221: SKIPPING: Can't 
test atime with nodump on this filesystem
+libarchive/test/test_read_disk_directory_traversals.c:1436: SKIPPING: Can't 
test nodump on this filesystem
 66: test_read_disk_entry_from_file


Totals:
  Tests run:  177
-  Tests failed: 1
-  Assertions checked:12819198
-  Assertions failed:4
-  Skips reported:  73
-
-Failing tests:
-  65: test_read_disk_directory_traversals (4 failures)
-
-Details for failing tests: /tmp/libarchive_test.2013-03-27T17.01.30-000
-
-FAIL: libarchive_test
+  Tests failed: 0
+  Assertions checked:12819611
+  Assertions failed:0
+  Skips reported:  34
+177 tests passed, no failures
+PASS: libarchive_test

 13: test_option_b
-tar/test/test_option_b.c:41: File archive1.tar has size 3072, expected 2048
-   Description: bsdtar does not pad archives written directly to regular files
-tar/test/test_option_b.c:63: File archive5.tar has size 3072, expected 2048
 14: test_option_exclude

 20: test_option_nodump
-tar/test/test_option_nodump.c:63: File should not exist: file2
+tar/test/test_option_nodump.c:32: SKIPPING: Can't test nodump on this 
filesystem
 21: test_option_q

Totals:
  Tests run:   32
-  Tests failed: 2
-  Assertions checked:7490
-  Assertions failed:3
-  Skips reported:   1
-
-Failing tests:
-  13: test_option_b (2 failures)
-  20: test_option_nodump (1 failures)
-
-Details for failing tests: /tmp/bsdtar_test.2013-03-27T17.02.00-000
-
-FAIL: bsdtar_test
+  Tests failed: 0
+  Assertions checked:7468
+  Assertions failed:0
+  Skips reported:   2
+32 tests passed, no failures
+PASS: bsdtar_test
.
If tests fail or crash, details will be in:
-   /tmp/bsdcpio_test.2013-03-27T17.02.06-000
+   /tmp/bsdcpio_test.2013-04-05T16.24.48-000

In summary it seems to me like the testsuite failures are filesystem
dependent.

Now questions for various parties

Libarchive maintainers:
does the testsuite have a method for setting expected failures?

s390x porters and buildd admins:
what fileystem setup do the s390x buildds use for the build environments?

Release team:
should I upload the binary I built on the porterbox so that the security fix 
can migrate?




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/515f0979.20...@p10link.net

Bug#704080: unblock: libarchive/3.0.4-3

[peter green]

It seems that Adam D. Barratt unblocked libarchive to fix the security 
bug. Unfortunately that wasn't enough to get the package into testing.


Specifically it seems that s390x has not successfully built this package 
for some time (since before s390x stopped being considered a broken and 
fucked architecture). As a result the s390x package is out of date in 
both testing and unstable. Britney will not migrate the package if there 
are out of date binaries in unstable (even if there are also out of date 
binaries for the same package in testing). The cause of the build 
failures seems to be a testsuite failure. Afaict there are several 
options in this scenario.


1: someone gets to the bottom of the issue and submits a patch which is 
uploaded
2: a version of the package is uploaded where the so that the s390x 
version is either built without running the testsuite or where the 
testsuite is run but it's failure is considered non-fatal

3: the s390x binaries are removed.
4: the package is forced into testing.

Option 1 is clearly the ideal outcome but relies on someone who has the 
time and inclination (and no that won't be me) to get down and debug why 
the testsuite isn't passing on s390x and hope that the resulting fix is 
small enough for the release team to accept it. Given what this package 
does I don't like option 2. Option 3 seems to be blocked by reverse 
dependencies (especially cmake). Option 4 doesn't make the current 
situation any worse but afaict outdated packages in testing are not 
considered acceptable for release.


Thoughts? should I go file a rc bug about this issue?

P.S. I'm just poking through the rc bug list looking at why bugs are 
still open in testing. I have no relationship to this package, i'm not 
part of the relase team and i'm not a 390x porter.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/515e3537.9020...@p10link.net

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

[peter green]

Jonathan Wiltshire wrote:

I'd rather not have the DEP-3 boilerplate in your first patch; with that
removed, please go ahead with an upload to unstable and ping this bug when
it is ready.
  

Done.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5158ba2c.8000...@p10link.net

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

[peter green]

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

Please approve my upload for package clang, this fixes two issues one of which
is filed as a grave bug. The other I also judge to be grave but is not currently
filed as a bug in debian (if you want me to file it as one I will)

The first issue is on armhf. While I fixed the linker invocation some time ago
(and it took ages to get the patch uploaded due to arguments over the broken
3.1 version in sid which was eventually cleared as an epoch upload) I did not
think to test passing of floating point arguments between clang build code and
gcc built code.

It turns out that the CPU default clang was using on armhf was rediculously 
low and this causes clang to silently fail to correctly implement the hard 
float ABI. My patch raises the CPU default.

I have set the CPU default to armv6 because as far as I can tell clang 3.0's
armv7 setting's imply features that debian armhf doesn't have. Ubuntu has
a patch that solves this but I judged that patch too intrusive and hacky for
debian. So setting the default to armv6 appeared to be the least bad 
soloution.

The second change is for powerpc and was picked from ubuntu it stops the
package being built with altivec as the default since debian powerpc does
not require altivec. This patch was pointed out to me by adam conrad while
discussing the armhf issues.

Debdiff is attatched.

-- System Information:
Debian Release: 6.0.3
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130328180059.8695.51236.reportbug@localhost

Bug#704159: unblock (pre-approval) : clang/1:3.0-6.2

[peter green]

peter green wrote:

Debdiff is attatched

Sorry forgot to attatch it, here it is.
diff -Nru clang-3.0/debian/changelog clang-3.0/debian/changelog
--- clang-3.0/debian/changelog  2013-02-10 14:47:29.0 +
+++ clang-3.0/debian/changelog  2013-03-28 18:03:16.0 +
@@ -1,3 +1,16 @@
+clang (1:3.0-6.2) unstable; urgency=low
+
+  * Non-maintainer upload with maintainer's approval.
+  * 29-set-default-cpu-for-armhf.diff increase default cpu for armhf builds.
+Previous absurdly low default did not work correctly with 
+-mfloat-abi=hard leading to broken code. (Closes: #704111)
++ Use armv6 as new default because in clang 3.0 armv7 implies features that
+   we don't require in debian armhf (extra fpu registers and neon)
+  * 30-powerpc-no-altivec.patch disable altivec by default on powerpc because
+debian powerpc does not require altivec (patch cherry picked from ubuntu)
+
+ -- Peter Michael Green plugw...@debian.org  Thu, 28 Mar 2013 09:02:01 +
+
 clang (1:3.0-6.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru clang-3.0/debian/patches/29-set-default-cpu-for-armhf.diff 
clang-3.0/debian/patches/29-set-default-cpu-for-armhf.diff
--- clang-3.0/debian/patches/29-set-default-cpu-for-armhf.diff  1970-01-01 
00:00:00.0 +
+++ clang-3.0/debian/patches/29-set-default-cpu-for-armhf.diff  2013-03-28 
08:47:26.0 +
@@ -0,0 +1,39 @@
+Description: Fix CPU type default for armhf
+  Without this patch clang defaults to a CPU type of arm7tdmi which
+  does not work correctly with -mfloat-abi=hard leading to broken
+  code.
+  
+  Use armv6 because as far as I can tell clang 3.0 does not properly 
+  support an armv7 setting without neon or the extra floating point 
+  registers. It may be possible to patch it to add support but I feel 
+  such a Patch would likely be considered unacceptable at this stage in
+  The release process.
+Author: Peter Michael Green plugw...@debian.org
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: vendor|upstream|other, url of original patch
+Bug: url in upstream bugtracker
+Bug-Debian: http://bugs.debian.org/bugnumber
+Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
+Forwarded: no|not-needed|url proving that it has been forwarded
+Reviewed-By: name and email of someone who approved the patch
+Last-Update: -MM-DD
+
+Index: clang-3.0/tools/clang/lib/Driver/Tools.cpp
+===
+--- clang-3.0.orig/tools/clang/lib/Driver/Tools.cpp2013-03-27 
19:50:18.0 +
 clang-3.0/tools/clang/lib/Driver/Tools.cpp 2013-03-27 19:53:28.0 
+
+@@ -442,6 +442,9 @@
+   if (Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
+ // Otherwise, if we have -march= choose the base CPU for that arch.
+ MArch = A-getValue(Args);
++  } else if (Triple.getEnvironment() == llvm::Triple::GNUEABIHF) {
++// Use armv6 for armhf (raspbian version of patch)
++MArch = armv6;
+   } else {
+ // Otherwise, use the Arch from the triple.
+ MArch = Triple.getArchName();
diff -Nru clang-3.0/debian/patches/30-powerpc-no-altivec.patch 
clang-3.0/debian/patches/30-powerpc-no-altivec.patch
--- clang-3.0/debian/patches/30-powerpc-no-altivec.patch1970-01-01 
00:00:00.0 +
+++ clang-3.0/debian/patches/30-powerpc-no-altivec.patch2013-03-28 
09:00:48.0 +
@@ -0,0 +1,20 @@
+Description: Make sure PowerPC doesn't default to altivec on
+Author: Adam Conrad adcon...@ubuntu.com
+Forwarded: no
+Reviewed-By: Colin Watson cjwat...@ubuntu.com
+Last-Update: 2012-04-24
+
+Index: b/tools/clang/lib/Lex/Makefile
+===
+--- a/tools/clang/lib/Lex/Makefile
 b/tools/clang/lib/Lex/Makefile
+@@ -16,9 +16,5 @@
+ 
+ LIBRARYNAME := clangLex
+ 
+-ifeq ($(ARCH),PowerPC)
+-CXX.Flags += -maltivec
+-endif
+-
+ include $(CLANG_LEVEL)/Makefile
+ 
diff -Nru clang-3.0/debian/patches/series clang-3.0/debian/patches/series
--- clang-3.0/debian/patches/series 2013-02-06 12:53:12.0 +
+++ clang-3.0/debian/patches/series 2013-03-28 09:01:26.0 +
@@ -9,3 +9,5 @@
 26-set-correct-float-abi.diff
 27-dynamic-linker.diff
 28-gcc-4.7.diff
+29-set-default-cpu-for-armhf.diff
+30-powerpc-no-altivec.patch

Re: e2fsprogs_1.42.5-1.1_amd64.changes ACCEPTED into unstable

[peter green]

Ok, I can see how it can be confusing. who-uploads does show that it
was my gpg signature on the upload. It's just this way I sponsor any
other uploads were the code/changes I am not the author of. 

IMO there is a big difference between asking someone to sponsor and
posting a patch to the BTS. In the former case the person asking you
for sponsorship has taken the descision that it is ready for upload 
(of course as a dd it's up to you to check that descision is sane)
and the responsibility for any fallout from the changes. In the 
latter case the person is simply providing a suggestion and leaving

the descision to those more familiar with the package.


How should
I credit the author?
  

There are serveral ways but below is one option

e2fsprogs  (1.42.5-1.1) unstable; urgency=low

 * Non-maintainer upload.
 [Nicolas Boulenguez]
 * e2fsck-static, e2fsprogs: let preinst remove a symbolic link in
   /usr/share/doc, that should have been replaced with a directory since
   1.39+1.40-WIP-2006.10.02+dfsg-1. (Closes: #698879).
-- Dmitrijs Ledkovs x...@debian.org mailto:xnox%40debian.org  Fri, 22 Feb 2013 23:14:59 +0100 




--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514da1ca.6080...@p10link.net

Re: [Raspbian-devel] libpam-ubico and signed char on arm in debian and derivatives

[peter green]

Simon Josefsson wrote:

tor 2013-03-07 klockan 13:51 + skrev peter green:
  
I am a cofounder of a project called raspbian to provide a hard float 
derivative of debian for the raspberry pi. A user reported a bug to us 
about libpam-ubico related (so the reported claims) to char signedness 
and linked to a commit in upstream git.


https://bugs.launchpad.net/raspbian/+bug/1039577
https://github.com/Yubico/yubico-c-client/commit/6fcc3d49d1d9b733c5bd04e4e60d400ed97cda40

If this can be reproduced on an official debian port then IMO it's a 
grave bug. However I don't own a yubikey myself so there is no way I can 
test it and I don't feel comfortable filing a grave bug in debian that I 
can't reproduce myself.



Hi!  If you could build and run the self-test of the ykclient package on
an internet-connected machine, that should hopefully trigger the bug.
If so, please file a bug.  Version 2.9 should fix this problem, and
doesn't contain anything critical, so maybe it could be uploaded if
indeed this is a grave bug.  I don't have access to any armel devices
easily.
  

Ok, the plot thickens.

It seems the signed char bug in the base64 code was made apparent in
debian when they reenabled the testsuite with version 2.8-1 and was
fixed by version 2.8-2. Unfortunately 2.8-1 didn't migrate to testing
because of build failures and 2.8-2 didn't migrate to testing because
of the freeze. Below is a diffstat between the version in testing and
the version in unstable.

plugwash@raspbian:~$ debdiff /home/repo/sourcearchive/main/y/ykclient/ykclient_2.6-1.dsc /home/repo/sourcearchive/main/y/ykclient/ykclient_2.8-2.dsc | diffstat 
COPYING|2 
ChangeLog  |  195 +++
Makefile.am|8 
Makefile.in|   18 
NEWS   |   29 
README |   15 
aclocal.m4 |  256 
b64/cdecode.c  |   15 
config.guess   |  223 ++--

config.sub |  156 +-
configure  | 1767 ++--
configure.ac   |   13 
debian/changelog   |   17 
debian/control |2 
debian/rules   |1 
ltmain.sh  | 2437 ++---

m4/libcurl.m4  |  240 
m4/libtool.m4  | 1078 +--
m4/ltversion.m4|   12 
simple.mk  |2 
tests/Makefile.am  |6 
tests/Makefile.in  |   16 
tests/selftest.c   |   52 
tool.c |   37 
ykclient.c |  641 +++
ykclient.h |   17 
ykclient_server_response.c |   41 
ykclient_server_response.h |2 
28 files changed, 4920 insertions(+), 2378 deletions(-)

plugwash@raspbian:~$

Even with the autohell stuff filtered out the debdiff (filtered debdiff attached) 
still looks pretty intimidating. Release team how should we play this? do you want

to unblock the version in sid or should we look into backporting the base64 fix 
to
the version in wheezy?

diff -Nru ykclient-2.6/aclocal.m4 ykclient-2.8/aclocal.m4
diff -Nru ykclient-2.6/b64/cdecode.c ykclient-2.8/b64/cdecode.c
--- ykclient-2.6/b64/cdecode.c  2011-02-22 14:04:46.0 +
+++ ykclient-2.8/b64/cdecode.c  2013-03-08 01:00:50.0 +
@@ -9,10 +9,11 @@
 
 int base64_decode_value(char value_in)
 {
-   static const char decoding[] = 
{62,-1,-1,-1,63,52,53,54,55,56,57,58,59,60,61,-1,-1,-1,-2,-1,-1,-1,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,-1,-1,-1,-1,-1,-1,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51};
+   static const signed char decoding[] = 
{62,-1,-1,-1,63,52,53,54,55,56,57,58,59,60,61,-1,-1,-1,-2,-1,-1,-1,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,-1,-1,-1,-1,-1,-1,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51};
static const char decoding_size = sizeof(decoding);
+   if (value_in  43) return -1;
value_in -= 43;
-   if (value_in  0 || value_in  decoding_size) return -1;
+   if (value_in  decoding_size) return -1;
return decoding[(int)value_in];
 }
 
@@ -26,7 +27,7 @@
 {
const char* codechar = code_in;
char* plainchar = plaintext_out;
-   char fragment;
+   int fragment;

*plainchar = state_in-plainchar;

@@ -42,7 +43,7 @@
state_in-plainchar = *plainchar;
return plainchar - plaintext_out;
}
-   fragment = 
(char)base64_decode_value(*codechar++);
+   fragment = base64_decode_value(*codechar++);
} while (fragment  0);
*plainchar= (fragment  0x03f)  2;
case step_b:
@@ -53,7 +54,7

Bug#693208: clang unable to link trivial test program on armhf

[peter green]

Package: clang
Version: 3.0-6
Severity: grave
Tags: patch
x-debbugs-cc: debian-release@lists.debian.org

RT in cc because of proposed TPU upload.

Unfortunately it seems that the changes in 3.0-6 fixed clang on armel
but not on armhf.

root@debian:/# clang -v test.c
Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: warning: unknown platform, assuming -mfloat-abi=soft
/usr/bin/clang -cc1 -triple armv4t-unknown-linux-gnueabihf -S
-disable-free -disable-llvm-verifier -main-file-name test.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft
-target-feature +soft-float -target-feature +soft-float-abi
-target-feature -neon -target-linker-version 2.22
-momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /usr/include -ferror-limit 19 -fmessage-length
80 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/test-TUFgUO.s -x c test.c
clang -cc1 version 3.0 based upon llvm 3.0 hosted on
arm-unknown-linux-gnueabihf
ignoring nonexistent directory /usr/bin/../lib/clang/3.0/include
ignoring nonexistent directory /usr/bin/../lib/clang/3.0/include
ignoring duplicate directory /usr/local/include
ignoring duplicate directory /usr/include/arm-linux-gnueabihf
ignoring duplicate directory /usr/include/arm-linux-gnueabihf
ignoring duplicate directory /usr/include/arm-linux-gnueabihf
ignoring duplicate directory /usr/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/include/arm-linux-gnueabihf
/usr/include
/usr/include/clang/3.0/include/
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include/
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed/
End of search list.
/usr/bin/as -o /tmp/test-8d1iPt.o /tmp/test-TUFgUO.s
/usr/bin/ld -X --hash-style=both --build-id --eh-frame-hdr -m
armelf_linux_eabi -dynamic-linker /lib/ld-linux.so.3 -o a.out crt1.o
crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o
-L/usr/lib/gcc/arm-linux-gnueabihf/4.6
-L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib -L/usr/lib
/tmp/test-8d1iPt.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o crtn.o
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
root@debian:/#

I decided to first look at the warning about float abi, this seems to
have been a simple case of a missing condition in the logic that decides
what float ABI to use. While fixing that I also noticed that the code
uses softfp by default on armel when for debian armel it should be
using soft by default (since debian supports hardware without a fpu)
so I changed that too.

Reading that code also gave me a hint on how to fix the code that made
the path descisions which I proceeded to do.

Then I had to fix the dynamic linker path for armhf.

This is sufficient to make clang work with the gold linker on armhf.
Unfortunately the bfd linker fails with an assertion failure. I intend
to file a seperate bug report about this but still I think working with
one or the two linker choices debian offers is better than working with
neither.

While working on the fixes I also found the clean target was not
cleaning up properly and so fixed it.

I have attatched a diff which I would like to upload to TPU are the
maintainer and release team happy with this? I have tested that the
patch does not break linking on armel with either bfd or gold.

P.S. it seems the version in unstable has regressed from the version
in testing and does not link a trivial test app successfully on either
armel or armhf I have not investigated details of that (IMO fixing
wheezy is more important than fixing a package that is in sid and
unlikely to make it for wheezy).



diff -Nru clang-3.0/debian/changelog clang-3.0/debian/changelog
--- clang-3.0/debian/changelog  2012-02-25 13:05:54.0 +
+++ clang-3.0/debian/changelog  2012-11-13 12:15:15.0 +
@@ -1,3 +1,14 @@
+clang (3.0-6.1) wheezy; urgency=low
+
+  * Non-maintainer upload.
+  * 26-set-correct-float-abi.diff: Fix default float abis for armel and armhf
+  * 24-path-multiarch.diff: Fix paths for armhf
+  * 27-dynamic-linker.patch: Fix dynamic linker path for armhf
+  * debian/rules: fix clean target to remove generated file 
+tools/clang/include/clang/Debian/debian_path.h
+
+ -- Peter Michael Green plugw...@debian.org  Mon, 12 Nov 2012 22:04:07 +
+
 clang (3.0-6) unstable; urgency=low
 
   * 

Re: Bug#684437: pre-approval for fpc/2.6.0-7 upload

[peter green]

peter green wrote:

Retitle 684437 pre-approval for fpc/2.6.0-7 upload
Thanks

Since the last post on this bug report a load of updates related to 
localisation have landed. Specifically the package was not previously 
setup to support translations and as such was not translated. The 
package has now been fixed to support translation and translations 
have been added for Danish, Slovak, Portuguese, Russian, German, 
Polish, Czech, French, Italian, Japanese,
Swedish and Spanish. 
There was also a review of the english descriptions as part of the 
process
Which resulted in some minor rewordings and clarifications and 
(unfortunately)

a lot of reformatting.

I have also taken the opertunity to revert the removal of fpc.*dpkg* as
requested in the unblock discussions for 2.6.0-6

I have attached debdiffs against the versions in testing and unstable, 
please

review and ack/nack this upload.
Seems this mail didn't make it to the list, I guess the debdiffs were a 
bit big.


The attatchments can be found at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684437#33



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507c9594.3070...@p10link.net

re: miredo: FTBFS `pkglibdir' is not a legitimate directory for `PROGRAMS'

[peter green]

Le dimanche 29 juillet 2012 23:31:39 Bart Martens, vous avez écrit :
 Hi Rémi,
 
 The patch fixes the bug.  Why not simply use it ? Shall I upload an NMU ?


It does not address the real issue.
It must be pure luck that automake accepts it.
  
I don't know enough about automake internals to comment on whether the 
ubuntu
patch working is pure luck (adding the author of said patch to cc in 
case they

have any comments) but it does indeed  fix the build in current wheezy and
the resulting package looks sane (the file list is identical to the 
package currently
in the archive). Since wheezy is in freeze it is unlikely that  automake 
will change

behaviour between now and the release.

So if someone can test that packages built with ubuntu's patch actually work
correctly (I don't use teredo myself) I think it makes sense to upload 
it for
wheezy. then after wheeezy's release the new upstream release with the 
proper

fix can be uploaded.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503d25cc.4040...@p10link.net

Bug#685036: unblock: scim-anthy/1.2.7-5

[peter green]

Please unblock package scim-anthy version 1.2.7-5

It has been reported to us that the configuration setup
for scim-anthy crashes for some users (bug 682601 and
680988).  This is due to the recent transition in the
package from gtk2 to gtk3.

We've also included build-flag hardening in this upload.


And did so in a sane way; yay.  Unblocked.
Unfortunately it seems you failed to spot that the 
maintainers had added a build-dependency on 
libscim-dev (= 1.4.14-2) while testing only has version
1.4.13-5. Hence scim-anthy is no longer buildable in 
testing.


It looks like the scim maintainer has attempted to 
contact the release team several times asking about 
unblocks for scim but got no response

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680335


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5038ad26.3060...@p10link.net

Bug#684437: unblock: fpc/2.6.0-6

[peter green]

Philipp Kern wrote:

Uhm, is it really required by policy to delete backup files that weren't
created by the package in the first place?

diff -Nru fpc-2.6.0/debian/fp-compiler.postrm.in 
fpc-2.6.0/debian/fp-compiler.postrm.in
--- fpc-2.6.0/debian/fp-compiler.postrm.in  2012-05-06 21:43:32.0 
+
+++ fpc-2.6.0/debian/fp-compiler.postrm.in  2012-08-09 22:55:10.0 
+
@@ -4,12 +4,14 @@
 
 ACTION=$1
 
-CFG_FILE=/etc/fpc-${VERSION}.cfg

+CFG_FILE=/etc/fpc-${VERSION}
 
 # Debhelper code

 #DEBHELPER#
 
 if test ${ACTION} = purge

 then
-   rm -f ${CFG_FILE}
+   rm -f  ${CFG_FILE}.cfg
+   rm -f  ${CFG_FILE}.bak
+   rm -f  ${CFG_FILE}.*dpkg*
 fi

The second part does not make me happy.
  

The .bak file is created by the package under some circumstances
(certain upgrade scenarios I believe).

I don't understand why abou put in the .*dpkg* line though. ccing
him to ask.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50258848.7010...@p10link.net

Bug#684437: unblock: fpc/2.6.0-6

[peter green]

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

Please unblock package fpc

I have just sponsored a fpc upload by Abou Al Montacir to unstable, fixing two
important bugs (note: one of the bugs was initially filed as normal but 
speaking as a co-maintainer of the package I judge it to be important and have
upped the severity accordingly).

unblock fpc/2.6.0-6

-- System Information:
Debian Release: 6.0.3
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120810002409.10807.60937.reportbug@localhost

freeze exception for fpc

[peter green]

I just uploaded a new fpc package to the repositry, there are no code 
changes but there are a couple of fixes to packaging issues that I'd 
like to see in the release.


1: When I added myself to uploaders I only added myself in control not 
in control.in with the result that my changes were blown away by the 
build process.
2: The lists of fpc packages in the descriptions of debian packages 
(there is more than one fpc package per debian package) had an error.


Debdiff is attatched.
diff -Nru fpc-2.6.0/debian/changelog fpc-2.6.0/debian/changelog
--- fpc-2.6.0/debian/changelog  2012-05-06 21:46:11.0 +
+++ fpc-2.6.0/debian/changelog  2012-07-06 20:25:42.0 +
@@ -1,3 +1,14 @@
+fpc (2.6.0-4) unstable; urgency=low
+
+  [ Peter Michael Green ]
+  * Add myself to uploaders in control.in as well as control so that the build
+process doesn't blow my changes away
+  [ Abou Al Montacir ]
+  * Moved mention to openal from fp-units-gfx description to 
fp-untis-multimedia
+description. (Closes: Bug#679138)
+
+ -- Peter Michael Green plugw...@debian.org  Fri, 06 Jul 2012 20:25:10 +
+
 fpc (2.6.0-3) unstable; urgency=low
   * Add myself to uploaders
   * Add support for armhf (Closes: Bug#666264)
@@ -21,7 +32,7 @@
   the upstream build/cleanup process.
 - Cleanup install-source-stamp
 - Cleanup various generated files in debian directory
-  * set CFG_FILE in postrm so that the rm command in purge actually 
+  * set CFG_FILE in postrm so that the rm command in purge actually
 removes the configuration file.
  -- Peter Michael Green plugw...@debian.org  Sat, 21 Apr 2012 13:13:00 +0100
 
diff -Nru fpc-2.6.0/debian/control fpc-2.6.0/debian/control
--- fpc-2.6.0/debian/control2012-05-06 21:45:30.0 +
+++ fpc-2.6.0/debian/control2012-07-06 18:10:42.0 +
@@ -308,7 +308,6 @@
   - libgd
   - libpng
   - graph
-  - openal
   - cairo
 
 Package: fp-units-net-2.6.0
@@ -396,6 +395,7 @@
   - dts
   - mad
   - modplug
+  - openal
 
 Package: fp-units-i386-2.6.0
 Architecture: i386
@@ -675,7 +675,6 @@
   - libgd
   - libpng
   - graph
-  - openal
   - cairo
 
 Package: fp-units-net
@@ -755,6 +754,7 @@
   - dts
   - mad
   - modplug
+  - openal
 
 Package: fp-units-i386
 Architecture: i386
diff -Nru fpc-2.6.0/debian/control.in fpc-2.6.0/debian/control.in
--- fpc-2.6.0/debian/control.in 2012-05-06 21:31:56.0 +
+++ fpc-2.6.0/debian/control.in 2012-07-06 18:05:15.0 +
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Carlos Laviola clavi...@debian.org
-Uploaders: Torsten Werner twer...@debian.org, Abou Al Montacir 
abou.almonta...@sfr.fr
+Uploaders: Torsten Werner twer...@debian.org, Abou Al Montacir 
abou.almonta...@sfr.fr, Peter Michael Green plugw...@debian.org
 DM-Upload-Allowed: yes
 Standards-Version: 3.9.3
 Build-Depends: debhelper (= 7), fp-compiler, fp-units-base, fp-units-fcl, 
fp-utils, mawk | awk, libncurses-dev, binutils, ghostscript
@@ -308,7 +308,6 @@
   - libgd
   - libpng
   - graph
-  - openal
   - cairo
 
 Package: fp-units-net${PACKAGESUFFIX}
@@ -396,6 +395,7 @@
   - dts
   - mad
   - modplug
+  - openal
 
 Package: fp-units-i386${PACKAGESUFFIX}
 Architecture: i386
@@ -675,7 +675,6 @@
   - libgd
   - libpng
   - graph
-  - openal
   - cairo
 
 Package: fp-units-net
@@ -755,6 +754,7 @@
   - dts
   - mad
   - modplug
+  - openal
 
 Package: fp-units-i386
 Architecture: i386

gcc-4.6 gcc-defaults, gcc-mingw and wheezy

[peter green]

gcc-defaults in testing depends on gccgo-4.6 which is no longer built by 
the gcc-4.6 source package in unstable. The new gcc-defaults in unstable 
is blocked from migrating due to the standoff between the release team 
and the gcc maintainers over gcc-4.7. As a result of this gcc-4.6 cannot 
migrate to testing.


This is bad for two reasons

Firstly there are a significant number of bugfixes between the version 
in testing and the version in unstable including a number of fixes for 
internal compiler errors and the fix for 670821 (currently if gcc-4.6 is 
rebuilt in wheezy it's behaviour will change in ways that cause other 
packages to FTBFS).


Secondly gcc-mingw-w64 was built against gcc-4.6 4.6.3-5 and it 
generates it's binary versions from the gcc source versions (plus a 
suffix for it's own version). This means that rebuilding gcc-mingw-w64 
in wheezy (even with a bumped source version) will result in binaries 
with a lower version than those currently in the wheezy archive. It also 
raises potential GPL compliance issues for wheezy CDs.


There may be other packages in a similar state to gcc-mingw-w64, I 
haven't checked (i'm only aware of thise one because I noticed the issue 
while working on a dervitive of debian).



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fe22188.9020...@p10link.net