[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#855459: marked as done (Handling of libowfat/arm64 (+ rdeps))



Your message dated Sat, 18 Feb 2017 16:18:00 +0000
with message-id <efd651e7-266e-c8a7-abd4-37a76ca4c21f@thykier.net>
and subject line Re: Bug#855459: Handling of libowfat/arm64 (+ rdeps)
has caused the Debian Bug report #855459,
regarding Handling of libowfat/arm64 (+ rdeps)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
855459: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855459
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: tg@mirbsd.de

Dear release team,
(not user-tagging because I'm unsure about the category)

After having fixed the last RC bug in dietlibc, I've gone back and
looked at what packages might need rebuilds (since dietlibc is a
statically linked library).

Luckily none are required, since this only affects packages that
link binaries against -lpthread and dietlibc, of which none exist
in Debian. (This also applies to the other recent RC bugs fixed.)

However, one rdep links against -lpthread for its tests (which
aren't installed): libowfat. An earlier RC bug in dietlibc (fixed
before the freeze, see #850276) caused libowfat to FTBFS on arm64.
However, since no previous binary package of libowfat was built on
arm64 (previously to dietlibc supporting arm64 at all libowfat
was B-D-Uninstallable on that arch) it could migrate to testing
regardless.

(Side note: libowfat is orphaned, but it has one non-orphaned
rdep, gatling, which is both in sid and Stretch.)

With #850276 now fixed in Stretch (for a while now, actually),
libowfat does now build on arm64 (I've verified that on a
porterbox) - it just hasn't yet, as it's in the Build-Attempted
state.

I believe the simplest way of handling this is to simply give
back libowfat on arm64. Otherwise any update to libowfat
(including a security update) will introduce a new binary package
into Stretch on an architecture that previously didn't have it,
and it's probably better to do that before the release then
while doing a security update.

However, since gatling B-D: on libowfat-dev [1], once that
becomes available in arm64, wanna-build will then start building
that and I suspect that will succeed. (Haven't tried it though.)

So what I propose is the following:

gb libowfat_0.30-2 . arm64

And then, after having verified that both libowfat and gatling
build on arm64, unblock the arm64 binaries of these packages so
that they can also migrate to testing.

Regards,
Christian

PS: Side note 2: gatling is not build against dietlibc in Debian,
but against glibc, but since libowfat only builds if both
variants of it succeed, gatling has always been B-D-Uninstallable
on arm64 so far.

--- End Message ---
--- Begin Message ---
Christian Seiler:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: tg@mirbsd.de
> 
> Dear release team,
> (not user-tagging because I'm unsure about the category)
> 
> [...]
> 
> So what I propose is the following:
> 
> gb libowfat_0.30-2 . arm64
> 

Scheduled, thanks.

> And then, after having verified that both libowfat and gatling
> build on arm64, unblock the arm64 binaries of these packages so
> that they can also migrate to testing.
> 
> Regards,
> Christian
> 
> [...]

Won't be needed; the freeze do not apply to binary packages. :)

Thanks,
~Niels

--- End Message ---

Reply to: