NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: kamailio_4.2.0-2+deb8u2_i386.changes
  ACCEPT
Processing changes file: kamailio_4.2.0-2+deb8u2_powerpc.changes
  ACCEPT
Processing changes file: kamailio_4.2.0-2+deb8u2_s390x.changes
  ACCEPT

Re: Porter roll call for Debian Stretch

[Aníbal Monsalve Salazar]

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For mips, mipsel. mips64el I or my team at work
- test (most|all) packages on this architecture
- run a Debian testing or unstable system on port that I use regularly
- refer toolchain issues to our toolchain team at work
- refer kernel issues to our kernel team at work
- triage arch-specific bugs
- refer arch-related bugs to my team at work
- refer triage d-i bugs to my team at work
- test d-i regularly
- fix d-i bugs/issues
- test and supply machines for the buildds

I am a DD.

I believe the port is ready to have -fPIE/-pie enabled by default.

Aníbal Monsalve Salazar


signature.asc
Description: Digital signature

Bug#837199: transition: armadillo

[Kumar Appaiah]

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

Dear Release Team,

armadillo has already been uploaded to unstable. While the reverse
dependencies should build with a binNMU, I have not tested them and
will test it in the next couple of days.

Thank you.

Kumar

Ben file:

title = "armadillo";
is_affected = .depends ~ "libarmadillo6" | .depends ~ "libarmadillo7";
is_good = .depends ~ "libarmadillo7";
is_bad = .depends ~ "libarmadillo6";


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Kumar Appaiah

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: inspircd_2.0.17-1+deb8u2_amd64.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_arm64.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_armel.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_armhf.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_i386.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_mips.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_mipsel.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_powerpc.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_ppc64el.changes
  ACCEPT
Processing changes file: inspircd_2.0.17-1+deb8u2_s390x.changes
  ACCEPT
Processing changes file: kamailio_4.2.0-2+deb8u2_amd64.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_amd64.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_armel.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_armhf.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_i386.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_mips.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_mipsel.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_powerpc.changes
  ACCEPT
Processing changes file: util-vserver_0.30.216-pre3054-1+b1_s390x.changes
  ACCEPT
Processing changes file: xen_4.4.1-9+deb8u7_allonly.changes
  ACCEPT
Processing changes file: xen_4.4.1-9+deb8u7_amd64.changes
  ACCEPT
Processing changes file: xen_4.4.1-9+deb8u7_arm64.changes
  ACCEPT
Processing changes file: xen_4.4.1-9+deb8u7_armhf.changes
  ACCEPT
Processing changes file: xen_4.4.1-9+deb8u7_i386.changes
  ACCEPT

Bug#836910: jessie-pu: package kamailio/4.2.0-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2016-09-09 at 01:52 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Wed, 2016-09-07 at 11:48 +0200, Victor Seva wrote:
> > 2016-09-07 9:30 GMT+02:00 Adam D. Barratt :
> > > Thanks for caring about fixing this in jessie.
> > >
> > > In order to okay an upload, however, we'd need to see a source debdiff for
> > > the proposed package, built and tested on a jessie system.
> > 
> > Sure.
> 
> Thanks; please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Processed: Re: Bug#836910: jessie-pu: package kamailio/4.2.0-2+deb8u1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #836910 [release.debian.org] jessie-pu: package kamailio/4.2.0-2+deb8u1
Added tag(s) pending.

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

The (uncalled for) toolchain maintainers roll call for stretch

[Matthias Klose]

While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team.  I'd like to document the status how I do understand it for
some of the toolchains available in Debian.

I appreciate that the release criteria are somehow "reset" for the stretch
release, and not copied from previous release decisions.

GNU toolchain (GCC / binutils)
--

GCC upstream has the notation of primary and secondary platforms, with the
commitment to fix issues on these platforms [1], [2].  Debian architectures
within the set of these platforms are:

 - aarch64-none-linux-gnu (starting with GCC 7)
 - arm-linux-gnueabi
 - i686-pc-linux-gnu
 - powerpc64-unknown-linux-gnu
 - x86_64-unknown-linux-gnu
 - s390x-linux-gnu

Release architectures missing in the primary and secondary platforms:

 - armhf
 - mips*
 - powerpc
 - ppc64el

As you see with arm64, new architectures become primary or secondary platforms
only after a while, so that may explain the absence of
powerpc64le-unknown-linux-gnu.

The arm-linux-gnueabi is not that well defined, so it may include the hard float
variant as well.  However Debian default to armv4t, while the default
configuration for upstream is armv5.  However with the selected defaults
Debian's libstdc++::future module is not complete and causes build failures on
this architecture (same for sparc).

Uncovered by the upstream primary and secondary platforms are the mips*
architectures and powerpc.  For the uncovered archs I would expect somehow more
and pro-active Debian maintenance, however I fail to see this happen.

 - see the history of ftbfs on the buildd page of the gcc-snapshot package
 - see the status of the gcc-6 package for the pre-release uploads
 - see the number of RC issues for binutils which came up with 2.27,
   some still open.
 - Toolchain packages are not watched by porters, and I can't track
   every regression myself, however this is not done well by porters.

On the recent Porter's call I didn't see any toolchain support for the powerpc
architecture.  For the mips* architectures we apparently have five or more
active toolchain maintainers.  I very much doubt that view.  From my point of
view these architecture would be perfect candidates for partial architectures,
and until then should be removed from the set of the release architectures. For
mips* that shouldn't be no news; please see my comments regarding both the
toolchain and buildd status since at least DebConf 12 (release meetings during
DebConfs).

Java/OpenJDK


For the stretch release openjdk-8 will be fine as the default java
implementation.  For buster, gcj (to be removed in GCC 7) won't be available
anymore, and we'll end up with architectures without a java implementation.  At
the same time I'd like to consider to stop providing OpenJDK zero builds,
leaving powerpc and mips* without a java implementation as well (currently not
building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
underway.

Other toolchains


 - clang/llvm not available on armel since 3.8.
 - fpc not available on powerpc anymore (may have changed recently)
 - mono not available more on powerpc


Being demoted as a release architecture certainly is not a nice thing, and
looking at past demotions, these were not done very coordinated, not allowing
builds in the ports archive for some months.  It would be good to find some
middle-ground such that a port's demotion isn't a final thing, and it has a
chance to become a release architecture again, maybe even as a partial
architecture if we can define the meaning of such a thing.

Matthias

[1] https://gcc.gnu.org/gcc-6/criteria.html
[2] https://gcc.gnu.org/gcc-7/criteria.html

Re: FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)

[Matthias Klose]

Hi,

thanks for the work on this.  I'd like to defer the final decision to the
release team, however I'm not keen on having these defaults turned on
architectures which already have enough issues on their own.  In the recent
porters call people claim that turning on these "should not be a problem"
without giving any details why. I don't like this "laissez faire" attitude.
Without doing even a (limited) test rebuild on these architectures.  I don't
think this is the right time to turn on the defaults, that should be better done
when starting the development for the next release cycle.  If people are
confident to turn these on on amd64, fine.  If people are fine to trust Ubuntu's
experience to turn these on on ppc64el and s390x, fine as well.  But for any
other architecture please do a partial test rebuild before turning these on.

Matthias

On 09.09.2016 16:04, Bálint Réczey wrote:
> Hi,
> 
> First of all thanks to Lucas Nussbaum who ran the first test build!
> 
> 2016-08-31 19:21 GMT+02:00 Steve Langasek :
>> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>>> Hello,
 Results are available at
 https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>>
 I did a full rebuild with bindnow and PIE enabled, then rebuilt all
 failed packages with a pristine unstable chroot.
>>
 You can take a look at
 https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
 and grep for "OK Failed" (failed with PIE+bindnow, built fine in
 unstable). (There are 1188 packages failing to build)
>>
 Logs for both builds are available in the respective subdirectories.
>>
>>> Are you sure these are correct? The numbers for PIE+bindnow are a lot
>>> higher than what we see in Ubuntu, for same unmodified packages.
>>
>>> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>>
>>> amd64/ppc64el/s390x have PIE+bindnow enabled, and
>>> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
>>> range. There might be a dozen packages with PIE+bindnow fixes in
>>> ubuntu, that's not in debian, but that amount cannot be more than a
>>> dozen or two.
> 
> Is there a list available or an easy way of collecting them?
> 
>>
>> Note that enabling PIE by default is going to cause build failures for a
>> number of packages which link against static libraries, if those static
>> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
>> this transition, so a direct comparison would require a rebootstrap test in
>> Debian instead of just a rebuild test (i.e.: test rebuild packages in
>> dependency order, and build later packages against the output of the earlier
>> rebuilds).
> 
> True. Full rebootstrapping of the archive is not available
> automatically and this
> was really useful as a first test.
> 
> I have added more dpkg patches [1] to make -pie hardening flag a noop since 
> GCC
> upstream is not interested in making -no-pie easily usable [2].
> 
> I tested the packages failing to build with the previous patches and
> many of them
> could be built.
> The logs of the remaining failures can be found here:
> https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/
> 
> If we ignore the packages having "haskell" in their name the failures are down
> to 295 packages.
> 
> I'm starting ot file bugs for the FTBFS-s.
> 
> Patched dpkg and gcc is still available for those who would like to reproduce
> the issues.
> 
> Cheers,
> Balint
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
> [3] https://people.debian.org/~rbalint/ppa/pie-bindnow/
> 

Re: Uncoordinated transition: armadillo

[Sebastiaan Couwenberg]

On 09/09/2016 06:14 PM, Kumar Appaiah wrote:
> I have erroneously uploaded armadillo to unstable to close #837152. I
> wish to apologize and get advice on whether I can do something to
> prevent further trouble.

The transition workflow is documented on the wiki:

 https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Most of that still applies, you just didn't wait for the ACK from the
Release Team before moving the package from experimental to unstable.

You should file a transition bugreport which the Release Team uses to
track transitions, it should be marked forwarded with the URL to the
transition tracker:

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

To assess the impact of the transition, you need to rebuild all reverse
dependencies with the new packages, and report which build OK and which
failed. Bug reports need to be filed for the packages that FTBFS, and
marked to block the transition bugreport.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Adam D. Barratt]

On Fri, 2016-09-09 at 17:08 +0200, Gert Wollny wrote:
> > As far as I can tell, the problem isn't the documentation, it's:
> >
> > make[3]: *** No rule to make target
> > '/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so', needed by
> > 'bin/libvtkgdcmJava.so'.  Stop.
> >
> >
> Agreed, I didn't see this because I was scanning for "error:".
> 
> The compilation failure is still unrelated to the patches though, 
> because the patches only touch the C++ code, the compilation error is a 
> result of some problem on the part that cmake does.
> 
> At the beginning of the build log one can even see that the library is 
> correctly detected in the JRE ppc64el sub-directory, but later it wants 
> ppc64 only and I can't find the according code in the gdcm VTK java 
> module definition.

I was wondering if this might be a similar issue to javatool's #833572
(now fixed in p-u), but I don't know either gdcm or Java packaging in
general well enough to immediately point to a solution I'm afraid.

Regards,

Adam

Uncoordinated transition: armadillo

[Kumar Appaiah]

Dear Release Team,

I have erroneously uploaded armadillo to unstable to close #837152. I
wish to apologize and get advice on whether I can do something to
prevent further trouble.

Thanks, and sorry.

Kumar
-- 
One tree to rule them all,
One tree to find them,
One tree to bring them all,
and to itself bind them.
-- Gavin Koch 

Bug#836917: transition: openmpi

[Kumar Appaiah]

On Fri, Sep 09, 2016 at 05:30:34PM +0200, Sebastiaan Couwenberg wrote:
> On 09/09/2016 05:24 PM, Kumar Appaiah wrote:
> > On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
> >> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  >> l.nl> wrote:
> >> ...
>   
>  It looks like armadillo will require a transition before it will
> >> support
>  superlu >= 5.2.
> >>>  
> >>> To deal with the armadillo/superlu situation, I've disabled armadillo
> >>> support in gdal and will upload a new revision with that change after
> >>> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
> >> be
> >>> fixed in unstable soon.
> >>
> >>
> >> No need to disable gdal. The armadillo upgrade is ready. 
> >>
> >> Kumar, can you upload the new armadillo as soon as possible?  An
> >> accidental openmpi upgrade has complicated everyone's dependencies.
> > 
> > Should I go ahead with the upload or request a transition formally
> > with the release team or go ahead with the upload?
> > 
> > I'll prepare the upload right away but wait for your go ahead.
> 
> As requested in #837152 please coordinate the armadillo transition with
> the Release Team, we've had far too many uncoordinated transition recently.

Sorry, I just uploaded it! I'll e-mail Debian release right away.

Kumar
-- 
Kumar Appaiah

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/09/2016 05:24 PM, Kumar Appaiah wrote:
> On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
>> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg > l.nl> wrote:
>> ...
  
 It looks like armadillo will require a transition before it will
>> support
 superlu >= 5.2.
>>>  
>>> To deal with the armadillo/superlu situation, I've disabled armadillo
>>> support in gdal and will upload a new revision with that change after
>>> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
>> be
>>> fixed in unstable soon.
>>
>>
>> No need to disable gdal. The armadillo upgrade is ready. 
>>
>> Kumar, can you upload the new armadillo as soon as possible?  An
>> accidental openmpi upgrade has complicated everyone's dependencies.
> 
> Should I go ahead with the upload or request a transition formally
> with the release team or go ahead with the upload?
> 
> I'll prepare the upload right away but wait for your go ahead.

As requested in #837152 please coordinate the armadillo transition with
the Release Team, we've had far too many uncoordinated transition recently.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836917: transition: openmpi

[Kumar Appaiah]

On Fri, Sep 09, 2016 at 09:19:39PM +0800, Drew Parsons wrote:
> On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  l.nl> wrote:
> ...
> > > 
> > > It looks like armadillo will require a transition before it will
> support
> > > superlu >= 5.2.
> > 
> > To deal with the armadillo/superlu situation, I've disabled armadillo
> > support in gdal and will upload a new revision with that change after
> > 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
> be
> > fixed in unstable soon.
> 
> 
> No need to disable gdal. The armadillo upgrade is ready. 
> 
> Kumar, can you upload the new armadillo as soon as possible?  An
> accidental openmpi upgrade has complicated everyone's dependencies.

Should I go ahead with the upload or request a transition formally
with the release team or go ahead with the upload?

I'll prepare the upload right away but wait for your go ahead.

Thanks.

Kumar
-- 
Kumar Appaiah

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Gert Wollny]

As far as I can tell, the problem isn't the documentation, it's:

make[3]: *** No rule to make target
'/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so', needed by
'bin/libvtkgdcmJava.so'.  Stop.



Agreed, I didn't see this because I was scanning for "error:".

The compilation failure is still unrelated to the patches though, 
because the patches only touch the C++ code, the compilation error is a 
result of some problem on the part that cmake does.


At the beginning of the build log one can even see that the library is 
correctly detected in the JRE ppc64el sub-directory, but later it wants 
ppc64 only and I can't find the according code in the gdcm VTK java 
module definition.


My suspect is SWIG_ADD_MODULE, but the according UseSWIG.cmake  this is 
part of cmake-data and there was no change in stable.  Swig2.0 might 
also be related, I saw it got two binary rebuilds on arm64 and one on 
ppc64el.


Best,
Gert

FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)

[Bálint Réczey]

Hi,

First of all thanks to Lucas Nussbaum who ran the first test build!

2016-08-31 19:21 GMT+02:00 Steve Langasek :
> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>> Hello,
>> > Results are available at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>
>> > I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> > failed packages with a pristine unstable chroot.
>
>> > You can take a look at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> > and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> > unstable). (There are 1188 packages failing to build)
>
>> > Logs for both builds are available in the respective subdirectories.
>
>> Are you sure these are correct? The numbers for PIE+bindnow are a lot
>> higher than what we see in Ubuntu, for same unmodified packages.
>
>> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
>> amd64/ppc64el/s390x have PIE+bindnow enabled, and
>> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
>> range. There might be a dozen packages with PIE+bindnow fixes in
>> ubuntu, that's not in debian, but that amount cannot be more than a
>> dozen or two.

Is there a list available or an easy way of collecting them?

>
> Note that enabling PIE by default is going to cause build failures for a
> number of packages which link against static libraries, if those static
> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
> this transition, so a direct comparison would require a rebootstrap test in
> Debian instead of just a rebuild test (i.e.: test rebuild packages in
> dependency order, and build later packages against the output of the earlier
> rebuilds).

True. Full rebootstrapping of the archive is not available
automatically and this
was really useful as a first test.

I have added more dpkg patches [1] to make -pie hardening flag a noop since GCC
upstream is not interested in making -no-pie easily usable [2].

I tested the packages failing to build with the previous patches and
many of them
could be built.
The logs of the remaining failures can be found here:
https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/

If we ignore the packages having "haskell" in their name the failures are down
to 295 packages.

I'm starting ot file bugs for the FTBFS-s.

Patched dpkg and gcc is still available for those who would like to reproduce
the issues.

Cheers,
Balint

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
[3] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Bug#836917: transition: openmpi

[Drew Parsons]

On Fri, 9 Sep 2016 14:05:25 +0200 Sebastiaan Couwenberg  wrote:
...
> > 
> > It looks like armadillo will require a transition before it will
support
> > superlu >= 5.2.
> 
> To deal with the armadillo/superlu situation, I've disabled armadillo
> support in gdal and will upload a new revision with that change after
> 2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't
be
> fixed in unstable soon.


No need to disable gdal. The armadillo upgrade is ready. 

Kumar, can you upload the new armadillo as soon as possible?  An
accidental openmpi upgrade has complicated everyone's dependencies.

Drew

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

>>> Is anybody else interested in helping? Thoughts/comments?
>>
>>Sorry to bump an old thread
>>
>>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>>the platform.
>>
>>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>>discovering and reporting are being closed as "invalid" and "won't
>>fix" because Clang is outside its freshness date.
>>
>>Also pick up this for glibc:
>>http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
>>. Though it was first seen in Clang 3.3, its still a problem today.
>
> ACK, thanks for thinking about this still.
>
> Progress to date has been quiet, but work is ongoing. KiBi has a good
> set of patches ready for d-i already, and I'm working on debian-cd to
> add useful backports support. My first quick-hack attempt failed
> dismally, so I'm midway down a more disruptive but thorough set of
> changes now.

Another pothole for Clang... '-march=native' does not perform as
expected at least about one third of the time. I have not narrowed it
down, but it affects at least MacPorts and Ubuntu. Apple Clang appears
to be OK. I don't recall the results of Debian testing.

When we added code generation tests to our test script, we found Clang
was not generating SSE3, SSSE3, SSE4, AVX, BMI, etc. The work around
in the field is to cat /proc/cpuinfo, and then do something like the
following based on the CPU flags (from
http://github.com/weidai11/cryptopp/blob/master/cryptest.sh):

X86_CPU_FLAGS=$(cat /proc/cpuinfo 2>&1 | "$AWK" '{IGNORECASE=1}{if ($1
== "flags"){print;exit}}' | cut -f 2 -d ':')

if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "ssse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mssse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.1") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.1"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "aes") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-maes"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "pclmulqdq") -ne "0")
]]; then PLATFORM_CXXFLAGS+=("-mpclmul"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdrand") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdrnd"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdseed") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdseed"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "adx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-madx"); fi

Most users don't realize the silent failure is occurring. Ideally,
this would be fixed in the compiler front end.

Also see Clang {3.4|3.5|3.6|3.7} only advertises SSE2:
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616723,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616729,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616731,
etc.

Jeff

Processed: block 835397 with 837152

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 835397 with 837152
Bug #835397 [release.debian.org] transition: superlu
835397 was blocked by: 835556 835557 836677
835397 was not blocking any bugs.
Added blocking bug(s) of 835397: 837152
> thanks
Stopping processing here.

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

Processed: bug 835397 is forwarded to https://release.debian.org/transitions/html/auto-superlu.html

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 835397 https://release.debian.org/transitions/html/auto-superlu.html
Bug #835397 [release.debian.org] transition: superlu
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/auto-superlu.html'.
> thanks
Stopping processing here.

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

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Adam D. Barratt]

On Fri, 2016-09-09 at 13:11 +0200, Gert Wollny wrote:
> 
> On 09.09.2016 03:03, Adam D. Barratt wrote:
> > On Mon, 2016-09-05 at 22:32 +0100, Adam D. Barratt wrote:
> 
> > Unfortunately it FTBFS on ppc64el; see
> > https://buildd.debian.org/status/fetch.php?pkg=gdcm=ppc64el=2.4.4-3%2Bdeb8u1=1473373168
> >
> >
> Hmm, this bug seem to be completely unrelated to the patch, and on the 
> other archs I see the same errors related to the missing 'dot' and latex 
> programs, and nothing else that would explain the build failure.

As far as I can tell, the problem isn't the documentation, it's:

make[3]: *** No rule to make target
'/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so', needed by
'bin/libvtkgdcmJava.so'.  Stop.

Regards,

Adam

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/09/2016 11:25 AM, Sebastiaan Couwenberg wrote:
> On 09/08/2016 01:07 PM, Sebastiaan Couwenberg wrote:
>> I've done a round of rebuilds to assess the impact of this transition.
>> The results are summarized below. Several package suffer from
>> uninstallable build dependencies by having libopenmpi1.10 pulled in by
>> dependencies that failed to rebuild.
> 
> Quite a few packages require vtk6 to be rebuilt before their
> dependencies can be satisfied.
> 
> Unfortunately vtk6 has a large dependency chain, which is prone to issues.
> 
> mpi4py is one of the vtk6 build dependencies that needs to be fixed
> (#830440).
> 
> Another is the recent update of superlu in unstable which has made the
> armadillo packages and their reverse dependencies uninstallable
> (#837152). This includes gdal and by extension vtk6.
> 
> It looks like armadillo will require a transition before it will support
> superlu >= 5.2.

To deal with the armadillo/superlu situation, I've disabled armadillo
support in gdal and will upload a new revision with that change after
2.1.1+dfsg-4 migrates to testing. This assumes that armadillo won't be
fixed in unstable soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Gert Wollny]

On 09.09.2016 03:03, Adam D. Barratt wrote:

On Mon, 2016-09-05 at 22:32 +0100, Adam D. Barratt wrote:



Unfortunately it FTBFS on ppc64el; see
https://buildd.debian.org/status/fetch.php?pkg=gdcm=ppc64el=2.4.4-3%2Bdeb8u1=1473373168


Hmm, this bug seem to be completely unrelated to the patch, and on the 
other archs I see the same errors related to the missing 'dot' and latex 
programs, and nothing else that would explain the build failure.


I should be able to fix these by adding doxygen-latex and graphviz to 
the build dependencies and do a new upload.


Best,
Gert

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/08/2016 01:07 PM, Sebastiaan Couwenberg wrote:
> I've done a round of rebuilds to assess the impact of this transition.
> The results are summarized below. Several package suffer from
> uninstallable build dependencies by having libopenmpi1.10 pulled in by
> dependencies that failed to rebuild.

Quite a few packages require vtk6 to be rebuilt before their
dependencies can be satisfied.

Unfortunately vtk6 has a large dependency chain, which is prone to issues.

mpi4py is one of the vtk6 build dependencies that needs to be fixed
(#830440).

Another is the recent update of superlu in unstable which has made the
armadillo packages and their reverse dependencies uninstallable
(#837152). This includes gdal and by extension vtk6.

It looks like armadillo will require a transition before it will support
superlu >= 5.2.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1