Bug#978959: missing cron entries

[Andreas Barth]

Package: mailman3
Version: 3.2.2-1 
Tag: patch

Hi,

according to upstream, the following two cron entries should be run
daily as part of mailman3 but I fail to find them in the Debian
package:

.

mailman digests --periodic
mailman notify

This could be e.g. achived with a mailman file in /etc/cron.d/ with
@daily mailman -C /etc/mailman3/mailman.cfg digests --periodic
@daily mailman -C /etc/mailman3/mailman.cfg notify



Regards,
Andi

Bug#960202: rel2gpx: add ROLE to gpx outfile

[Andreas Barth]

Package: rel2gpx
Tags: patch
Severity: minor
Version: 0.27-2

Hi,

for my usecase I need the role of elements to be present in the gpx,
so I added them as type. Please see the patch below in case it's
usefull for anyone else (and of course, if another gpx tag is more
appropriate, please use that one).


Regards,
Andi


diff --git a/rel2gpx.pl b/rel2gpx.pl
index b4a4fb7..5997554 100755
--- a/rel2gpx.pl
+++ b/rel2gpx.pl
@@ -1373,7 +1373,9 @@ EOF
  if ($way->isOneway){
 $trkName .= "_Oneway";
  }
- print OUTFILE "\n".$trkName."\n\n";
+ print OUTFILE "\n".$trkName."\n";
+ print OUTFILE "".$way->{ROLE}."\n" if $way->{ROLE};
+ print OUTFILE "\n";
  for (my $k = 0; $k < $way->nodes; $k++){
 my $lat = $way->lat($k);
 my $lon = $way->lon($k);

Bug#932010: nsd fails here after upgrade as well, nsd-control-setup works

[Andreas Barth]

Hi together,

for me, after an upgrade I have exactly the same error. However,
running nsd-control-setup (after moving the keys away) resolved it
for me.

@Markus: I assume that an upgrade from oldstable isn't enough,I guess
my current system started -3 releases or so.

So as an suggestion, check in the postinst-file the size of the keys,
and if it is below 2048 bits, move them away and regenerate. My
personal opinionis that this change alone should be fit for a
.-release, but of course please check with the release team first.


Regards,
Andi

Bug#910448: mgetty: CVE-2018-16741

[Andreas Barth]

* Salvatore Bonaccorso (car...@debian.org) [181006 21:21]:
> FTR, I think if feasible best would be to go for unstable (and thus
> buster) directly to 1.2.1, which will adress as well the other CVEs
> (which were no-dsa or unimportant).

That's the plan, yes.


Andi

Bug#829704: Voting for TC Chair

[Andreas Barth]

* Sam Hartman (hartm...@debian.org) [160705 16:21]:
> 
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Andreas Barth 
> B: Don Armstrong 
> C: Keith Packard 
> D: Didier Raboud 
> E: Tollef Fog Heen 
> F: Sam Hartman 
> G: Phil Hands 
> H: Margarita Manterola 
> ===END===
> I vote d > c=e=f=g >h > a=b

Somehow the original mail didn't make it through yet, but I vote as
Sam (reasons: Don and I will leave soon, so not useful to select us,
and I think we should keep the chair and give Marga some time to
get used to the ctte).


Andi

Bug#822803: Call for votes for new TC member

[Andreas Barth]

* Didier 'OdyX' Raboud (o...@debian.org) [160705 10:03]:
> Dear TC members,
> 
> I hereby call for votes on the following ballot to fill the vacancy in 
> the TC. The voting period starts now and lasts for up to one week, or 
> until the outcome is no longer in doubt.
> 
> ===BEGIN
> 
> The Technical Committee recommends that Margarita Manterola  be 
> appointed by the Debian Project Leader to the Technical Committee.
> 
> MM: Recommend to appoint Margarita Manterola 
> FD: Further Discussion
> 
> ===END

I vote for MM.


Andi

Bug#741573: [CTTE #741573] Debian Menu System

[Andreas Barth]

* Keith Packard (kei...@keithp.com) [150904 07:27]:
> Vincent Cheng  writes:
> 
> > Does this mean that packages providing both a .desktop and a Debian
> > menu file are immediately RC-buggy as of now (i.e. is "shall not"
> > equivalent to "must not" or "should not" in Policy-speak)?
> 
> Sam Hartman asked this precise question at the tech-ctte meeting and we
> agreed that that this decision would not cause them to be classified as
> RC-buggy for the stretch release.

Also the decision of which bug reports are RC grade is usually done by
the release team, and nothing in the decision looks to me that we
overruled them.

This is definied in the relevant RC policy, see e.g.
https://release.debian.org/stretch/rc_policy.txt . ("must" in the
policy isn't necessarily the same.)



Andi

Bug#741573: CFV: Debian Menu Systems

[Andreas Barth]

Hi,

I vote D > A > Z > B > C.

(B is below Z because I don't think it ended in consensus. For D
enough had been said by others so I'm not going to repeat it - I think
it's the right decision so I'm voting this way.)


Andi

Bug#796236: pseudo-architectures plus architecture exclusion

[Andreas Barth]

Package: dpkg
Severity: wishlist
Version: 1.18.2

Hi,

we just had the 32bit arches in debian-bof, and two changes to dpkg
would help us:

1. Architectures linux-any-32 and linux-any-64 for the 32 and 64 bit
architectures respectivly.

2. The possibility to exclude architectures, e.g. to write any !i386
instead of listing all other architectures explicitly.

It would be helpful if these two changes could be make to the relevant
dpkg parts. 

Thanks!


Andi

Bug#770925: wanna-build patches to support foreign-arch Build-Depends

[Andreas Barth]

* Dima Kogan (d...@secretsauce.net) [150514 10:55]:
  http://anonscm.debian.org/cgit/users/dkogan-guest/wanna-build.git/

Thanks for the patches.  This contains two distinct set of patches,
some are code-cleanup, some are for foreign-arch build-deps.


Cleanup:

4ef0ff57c54982ea6eeb84fea1eadafdded3ee61
e19894f7c02b7fc5b65cd2d0bba980ff4b19defb
AFAIUI these should be applicable independend of the foreign-arch
things? (Otherwise the first one looks good to me but my perl is a bit
outdated, the second should if the dose documentation is correct.)



Foreign-Arch:

55f2b48a6d58dfb306a71ac4b588833d129563ca
This breaks semantics of merge-v3 with only two sets of package files.
I need to think a bit more if there are other semantic changes (and if
so if we want them or not).

f3221db8f5ec5b063d87b7ef25f45f224821fc71
First hunk, I would prefer if it would be written so it could be run
on an oldstable machine as well (see the one for vercmp two lines
below), perhaps with a reduced function set. Otherwise same comment as
above applies.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769972: New CTTE members

[Andreas Barth]

* Don Armstrong (d...@debian.org) [141118 02:39]:
 On Mon, 17 Nov 2014, Bdale Garbee wrote:
  Works for me. I like the start considering wording, too, as opposed
  to closing the call for nominations. Good thought.

very nice indeed.

 OK. I've written the draft of this here:
 
 http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/769972_new_ctte_members/call_for_nominations.txt
 
 Feel free to make any changes. I'll send out the announcement in 24
 hours unless someone objects.

Thanks. Unfortunatly I have to run a conference the next days, so
please don't expect further answers from me right now. But as long as
you all agree the text is good, it's good for me as well.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769791: wine32 doesn't work after fresh install

[Andreas Barth]

Package: wine32
Version: 1.6.2-16
Severity: serious

Hi,

wine32 doesn't start anymore after upgrade with a clean directory.
This is a duplicate of #739863 which had been closed in wine-unstable
which had been removed from unstable afterwards, so this bug is
present in testing.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [141105 17:39]:
 I am calling for votes on the text below:
   Y (override, swap dependencies, requires 3:1)
   FD

I vote Y, FD (with the remark that Y doesn't make a decision on does
debian want to change the default on upgrades but just
libpam-systemd dependencies is not the appropriate mechanismn to do
it - the other question is not at the ctte, and I hope that we as
Debian manage to find a way to settle this question less painful then
some of the other things we currently have / had).


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)

[Andreas Barth]

* Matthias Klumpp (matth...@tenstral.net) [141112 13:21]:
 2014-11-12 12:28 GMT+01:00 Andreas Barth a...@ayous.org:
  * Ian Jackson (ijack...@chiark.greenend.org.uk) [141105 17:39]:
  I am calling for votes on the text below:
Y (override, swap dependencies, requires 3:1)
FD
 
  I vote Y, FD (with the remark that Y doesn't make a decision on does
  debian want to change the default on upgrades but just
  libpam-systemd dependencies is not the appropriate mechanismn to do
  it
 For this I want to highlight that the systemd maintainers also
 consider this a bad idea [...]

 So the decision to swap the dependencies would only be to ensure that
 - if there is a broken dependency solver - systemd-sysv is never
 accidentially installed (and sysvinit replaced).

And that's exactly what this decision means, don't swap the init
system by accident. Nothing more but also nothing less. (I had a bit
of bad experience of people reading more in an statement than there
was in, that is why I wrote that. And I also fear that also the
systemd maintainers consider this a bad idea doesn't help too much in
avoiding that, at least at the moment.)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768470: even more info for dgit.1

[Andreas Barth]

Package: dgit
Version: 0.22.1
Severity: wishlist

Hi,

as just discussed a proposal to document clearer some things which I
couldn't read from the current man page.


Andi
From 65638803c5b051d21a373a8690c393d742b34d60 Mon Sep 17 00:00:00 2001
From: Andreas Barth a...@not.so.argh.org
Date: Fri, 7 Nov 2014 16:01:52 +0100
Subject: [PATCH] dgit.1: add information that dgit repros could be normally
 cloned, and no source code access on the signing machine is
 required for rpush.

---
 dgit.1 |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/dgit.1 b/dgit.1
index 1676bb8..576c128 100644
--- a/dgit.1
+++ b/dgit.1
@@ -164,7 +164,9 @@ Pushes the contents of the specified directory on a remote machine.
 This is like running dgit push on build-host with build-dir as the
 current directory; however, signing operations are done on the
 invoking host.  This allows you to do a push when the system which has
-the source code and the build outputs has no access to the key.
+the source code and the build outputs has no access to the key,
+whereas the host with access to the key doesn't need to have the
+source repository cloned to it.
 
 However, the build-host must be able to ssh to the dgit repos.  If
 this is not already the case, you must organise it separately, for
@@ -516,6 +518,10 @@ directory, as with a traditional (non-gitish) dpkg-source workflow.
 You need to retain these tarballs in the parent directory for dgit
 build and dgit push.
 
+dgit repositories could be cloned with standard (git) methods. The
+only exception is that for sourcefull builds / uploads the orig
+tarball(s) need to be present in the parent directory.
+
 To a user looking at the archive, changes pushed using dgit look like
 changes made in an NMU: in a `3.0 (quilt)' package the delta from the
 previous upload is recorded in a new patch constructed by dpkg-source.
-- 
1.5.6.5

From 1afcca57839c0d4cf3dadda5d1495aff0d5b7e24 Mon Sep 17 00:00:00 2001
From: Andreas Barth a...@not.so.argh.org
Date: Fri, 7 Nov 2014 16:03:42 +0100
Subject: [PATCH] dgit.1: dgit clone needs access to mirror.ftp-master for the
 moment.

---
 dgit.1 |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/dgit.1 b/dgit.1
index 576c128..55f93be 100644
--- a/dgit.1
+++ b/dgit.1
@@ -71,6 +71,9 @@ For your convenience, the
 remote will be set up from the package's Vcs-Git field, if there is
 one - but note that in the general case the history found there may be
 different to or even disjoint from dgit's view.
+
+Cloning needs ssh access to mirror.ftp-master.debian.org. (This
+requirement will be dropped in a later version of dgit.)
 .TP
 \fBdgit fetch\fR [\fIsuite\fP]
 Consults the archive and git-repos to update the git view of
-- 
1.5.6.5

Bug#742140: libpam-oath: PAM module does not check whether strdup allocations succeeded

[Andreas Barth]

Hi,

we have the following debian bug report about an security isuse in
libpam-oath (source oath-toolkit, upstream web page
http://www.nongnu.org/oath-toolkit/ ).

What is the appropriate process to get an CVE number on it? This issue
is already public, as it is documented in the debian bug tracking
system.


Andi

* Eero Häkkinen (eer...@bigfoot.com) [141106 14:31]:
 Package: libpam-oath
 Version: 2.0.2-2
 Severity: grave
 Tags: security upstream patch
 
 The OATH Toolkit PAM module does not check whether strdup allocations 
 succeeded. This may result in null pointer dereference and application 
 crash.
 
 Depending on the use of the PAM module, this may be remotely exploitable.

 diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
 index 8379358..e2d3363 100644
 --- a/pam_oath/pam_oath.c
 +++ b/pam_oath/pam_oath.c
 @@ -146,6 +146,12 @@ pam_sm_authenticate (pam_handle_t * pamh,
char *query_prompt = NULL;
char *onlypasswd = strdup ();/* empty passwords never match */
  
 +  if (!onlypasswd)
 +{
 +  retval = PAM_BUF_ERR;
 +  goto done;
 +}
 +
parse_cfg (flags, argc, argv, cfg);
  
retval = pam_get_user (pamh, user, NULL);
 @@ -265,6 +271,11 @@ pam_sm_authenticate (pam_handle_t * pamh,
  {
free (onlypasswd);
onlypasswd = strdup (password);
 +  if (!onlypasswd)
 +{
 +  retval = PAM_BUF_ERR;
 +  goto done;
 +}
  
/* user entered their system password followed by generated OTP? */
  


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766484: FTBFS in a cowbuilder: Error: listen EADDRNOTAVAIL

[Andreas Barth]

Hi,

just trying on an i386 buildd, it fails by:

ln -fs out/Release/node node
/usr/bin/python tools/test.py --arch=ia32 simple
=== release test-crypto-stream ===
Path: simple/test-crypto-stream
assert.js:92
  throw new assert.AssertionError({
^
AssertionError: false == true
at Decipheriv.end (/«PKGBUILDDIR»/test/simple/test-crypto-stream.js:74:5)
at Decipheriv.anonymous (/«PKGBUILDDIR»/test/common.js:198:15)
at Decipheriv.emit (events.js:117:20)
at done (_stream_transform.js:190:19)
at _stream_transform.js:131:9
at Decipheriv.Cipher._flush (crypto.js:269:5)
at Decipheriv.anonymous (_stream_transform.js:130:12)
at Decipheriv.g (events.js:180:16)
at Decipheriv.emit (events.js:117:20)
at finishMaybe (_stream_writable.js:360:12)
Command: out/Release/node /«PKGBUILDDIR»/test/simple/test-crypto-stream.js
[03:34|% 100|+ 607|-   1]: Done
make[1]: *** [test-simple] Error 1
Makefile:114: recipe for target 'test-simple' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [debian/stamp-makefile-check] Error 2
/usr/share/cdbs/1/class/makefile.mk:67: recipe for target 
'debian/stamp-makefile-check' failed



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768353: dose-builddebcheck: cannot cope with multi-arch=no

[Andreas Barth]

Package: dose-builddebcheck
Version: 3.0.2-3

Hi,

the following error happens:
dose-builddebcheck --failures --explain --quiet --deb-native-arch=i386 
Packages.experimental.i386-all Packages.experimental.i386-all
Fatal error: exception Format822.Type_error(Field Multi-Arch has a wrong value 
: no)

However, according to https://wiki.ubuntu.com/MultiarchSpec the value
no is allowed.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762194: Call for Votes (re automatic switching)

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [141102 19:24]:
   Y.  Clarify decison and invite non-auto-switching proposals
   FD. Further discussion

I vote Y, FD.


Thanks.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767743: [jcris...@debian.org: Re: Bug#767743: unblock: blitz++/0.10-3]

[Andreas Barth]

* Andreas Tille (andr...@fam-tille.de) [141102 21:20]:
 could you please follow what was suggested here
 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767291#15
   
   
 
 to ensure building blitz++ at mips?

Blacklisted it on corelli/lucatelli.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

[Andreas Barth]

* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [141005 22:36]:
 That's because the last message from a release team member in this bug  
 said [1]:
 'However (and please note that I'm not a member of the security team
 and just speak for myself here as always when not otherwise marked) if

As I said, I was just speaking for myself. That I might be at other
times speaking as a member of the release team doesn't make it an
opinion of the release team. For the release team opinion on this
topic seen Cyrils mails.

Also, the re-evaluation happened. It however didn't had the outcome
you wanted (basically because the web browser needs so many security
updates which only could be done by backporting all of it that the
embedded copy doesn't make any difference - this is an exceptional
thing which does happen but not very often. I can understand it, and
of course it's the call of the security team how to ensure that Debian
has security updates. I hadn't know that at the time I though about
the possibility, otherwise I would have already achived at that moment
at the conclusion).


Conclusion: Though I'm usually an optimistic person how to get things
achived, I don't see any way left how at this late time it's possible
to ship with ffmpeg in jessie. I'm sorry but we have to face the
facts. Independend if we like them or not (and I can fully understand
that you don't like them, but it's no good pretending facts are
different than they are). Sorry.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764161: yc-el: emacs23 likley to be removed

[Andreas Barth]

Package: yc-el
Version: 5.0.0-5
Severity: serious

Hi,

please see bug #753885, emacs23 is going to be removed. So please
update the dependencies of yc-el accordingly.


Regards,
Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd

[Andreas Barth]

Control: tag -1 + patch

* Andreas Barth (a...@ayous.org) [141003 10:48]:
 Even though the non-working one is longer, it misses -lm -lgmodule-2.0
 -ldl. Of those the -lgmodule-2.0 is the relevant one.


To add this lib I hardcoded the following into configure.in:
GUI_LIBS=$GUI_LIBS $COMMON_LIBS `$pkgconfigpath --libs gmodule-2.0`
(instead of
GUI_LIBS=$GUI_LIBS $COMMON_LIBS
). I'm sure it's not nice, but it at least works. A better solution
would be appreciated though, but for Debian purposes it might even be
good enough already.


(To use that, I run autoreconf by dh_autoreconf with the usual
patches, and to get that working, I needed to add to configure.in
AM_GNU_GETTEXT_VERSION(0.19) (after the AUTOTEXT-macros). But from
here on, that's only regular auto-reconfing.)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd

[Andreas Barth]

Package: xchat
Version: 2.8.8-7.1
Severity: serious

Hi,

xchat FTBFS on three different architectures, one of them being a
release architecture it built before. The error is the same everywhere:
 /usr/bin/ld: plugin-tray.o: undefined reference to symbol 'g_module_symbol'
while linking xchat

That seems to come from linktool not using the right DSOs. If I copy
the linking command from the x86-build and do that by hand, I could
continue to build the binary packages.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [141003 10:35]:
 That seems to come from linktool not using the right DSOs. If I copy
 the linking command from the x86-build and do that by hand, I could
 continue to build the binary packages.

Further investigation shows that replacing GUI_LIBS with the value
from x86 is enough to build correctly.

Working is (... is same on both arches):
... -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 ...

Not working:
... -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig
-lfreetype ...


Even though the non-working one is longer, it misses -lm -lgmodule-2.0
-ldl. Of those the -lgmodule-2.0 is the relevant one.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [141003 10:48]:
 Even though the non-working one is longer, it misses -lm -lgmodule-2.0
 -ldl. Of those the -lgmodule-2.0 is the relevant one.

And the reason for that is that
pkg-config --libs libsexy = 0.1.8

gives different output.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561260: xchat FTBFS on ppc64el, hurd, kfreebsd

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [141003 11:00]:
 * Andreas Barth (a...@ayous.org) [141003 10:48]:
  Even though the non-working one is longer, it misses -lm -lgmodule-2.0
  -ldl. Of those the -lgmodule-2.0 is the relevant one.
 
 And the reason for that is that
 pkg-config --libs libsexy = 0.1.8
 
 gives different output.

And then again, that's 
#561260 [n|  |  ] [libsexy-dev] libsexy-dev: libsexy uses libs and cflags 
directly in pkg-config file


I intend to upload an NMU to libsexy soon which fixes this bug, and
also the following bugs:
#751289 [n|+|  ] [libsexy] libsexy: run dh-autoreconf to update config.{sub, 
guess} and {libtool, aclocal}.m4
#615290 [m| |  ] [libsexy-dev] libsexy-dev: please use Homepage field to point 
to upstream homepage



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages

[Andreas Barth]

Hi,


looking a bit from the outside it looks to me as different questions
discussed in parallel.



The one question is how we came here.

* Bill Allombert (ballo...@debian.org) [141003 12:15]:
 On Fri, Oct 03, 2014 at 01:41:02AM +0200, Emilio Pozuelo Monfort wrote:
  On 30/09/14 11:32, Bill Allombert wrote:
  On Mon, Sep 29, 2014 at 08:55:16PM +0200, Ondřej Surý wrote:
  Bill,
  
  I am very sorry that I have not Cced everything related to the
  libjpeg-transition
  to you. I have honestly believed that you and everyone else involved was
  following the transition plan as mentioned in #717076#225. As for the
  takover
  of the libjpeg62* packages it was discussed in the transition plan bug
  #754988.

 Bad faith ? No I do not think so.
 [...]
 ... and neither of you bothered to ask me.

Ondřej already said he thought while uploading that you were involved,
and notices now that you weren't and is sorry that he didn't CC you to
all mails. 

I can understand that you are angry about the uploaded packages. I'm
not going to argue about what the tech ctte resolution was, and what
could or should be interpreted into it or not, because that is not
helpful. Uploading the package as happend and without proper
discussion before was a mistake, and Ondřej already accepted his
responsibility for it. So while an mistake is never good, mistakes can
happen, and I personally always consider it a good thing if people
stand to their actions and apologize if appropriate.

I hope we could leave it as that for the upload - nobody has a time
machine to undo the upload, but we could try to make it better now and
discuss where we should go.



The other question is: Where from here? What should be the appropriate
state of packages within Debian for the release? It's a pity that we
lost time, but we still could adjust things so they are best for
Debian, based on the (spirit of the) initial decision of the tech ctte
(and in case the relevant people cannot agree, of course another
decision of the tech ctte would be possible, but I really hope we
could avoid that and conclude on something acceptable for all). (And
of course, any question not already decided by the tech ctte could be
discussed and hopefully also answered here - which source package will
build libjpeg62* is part of that.)



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726396: patch for ganglia / autoreconf

[Andreas Barth]

Control: tags -1 + patch

Hi,

though there is already an autoreconf in debian/rules it currently
doesn't work. The line with autoreconf needs --force for both
autoreconfs, it then reads as:
autoreconf --install --force  (cd libmetrics  autoreconf --install 
--force)

Doing so allows to build the package on ppc64el successfully. The same
should be true for arm64.

As this is one of the few remaining packages, I'd be happy to help
fixing this bug, if neccessary by uploading an NMU.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761650: llvm-toolchain-3.5 still FTBFSing on kbsd

[Andreas Barth]

Control: user debian-...@lists.debian.org
Control: usertags -1 kfreebsd

Hi,

this package still FTBFS on kbsd:
llvm[5]: Linking Release Shared Library liblldb.so
g++-4.9 -std=c++0x -g -O2 -Wl,-R -Wl,'$ORIGIN' -Wl,--gc-sections -rdynamic 
-L/«PKGBUILDDIR»/build-llvm/Release/lib -L/«PKGBUILDDIR»/build-llvm/Release/lib 
   -shared -o /«PKGBUILDDIR»/build-llvm/Release/lib/liblldb.so  \
  -Wl,--whole-archive -llldbAPI -llldbBreakpoint -llldbCommands -llldbCore 
-llldbDataFormatters -llldbExpression -llldbHostCommon -llldbInitAndLog 
-llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_arm64 
-llldbPluginABIMacOSX_i386 -llldbPluginABISysV_x86_64 
-llldbPluginABISysV_hexagon -llldbPluginDisassemblerLLVM 
-llldbPluginDynamicLoaderStatic -llldbPluginDynamicLoaderPOSIX 
-llldbPluginDynamicLoaderHexagon -llldbPluginEmulateInstructionARM 
-llldbPluginEmulateInstructionARM64 
-llldbPluginLanguageRuntimeCPlusPlusItaniumABI 
-llldbPluginLanguageRuntimeObjCAppleObjCRuntime 
-llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF 
-llldbPluginObjectFileJIT -llldbPluginSymbolVendorELF 
-llldbPluginObjectFilePECOFF -llldbPluginOperatingSystemPython 
-llldbPluginPlatformGDBServer -llldbPluginProcessGDBRemote 
-llldbPluginSymbolFileDWARF -llldbPluginSymbolFileSymtab 
-llldbPluginUnwindAssemblyInstEmulation -llldbPluginUnwindAssemblyx86 
-llldbPluginUtility -llldbSymbol -llldbTarget -llldbUtility -lclangAnalysis 
-lclangAST -lclangBasic -lclangCodeGen -lclangFrontend -lclangDriver 
-lclangEdit -lclangLex -lclangParse -lclangSema -lclangSerialization 
-lLLVMMCDisassembler -lLLVMObjCARCOpts -lLLVMProfileData 
-llldbPluginPlatformMacOSX -llldbPluginPlatformLinux 
-llldbPluginPlatformWindows -llldbPluginPlatformFreeBSD 
-llldbPluginPlatformPOSIX -llldbPluginPlatformKalimba -llldbHostFreeBSD 
-llldbPluginProcessPOSIX -llldbPluginProcessFreeBSD -llldbPluginProcessElfCore 
-llldbPluginJITLoaderGDB -Wl,--no-whole-archive -lLLVM-3.5 -Wl,--no-undefined 
-L/usr/lib/python2.7/config-x86_64-kfreebsd-gnu -L/usr/lib -lpthread -ldl  
-lutil -lm  -lpython2.7 -Xlinker -export-dynamic -Wl,-O1 
-Wl,-Bsymbolic-functions -lrt -ledit -lncurses -lpanel 
-Wl,--soname,liblldb.so.1 -lz -lpthread -lffi -ledit -ltinfo -ldl -lm 
/«PKGBUILDDIR»/build-llvm/Release/lib/liblldbExpression.a(ClangExpressionParser.o):
 In function 
`lldb_private::ClangExpressionParser::Parse(lldb_private::Stream)':
/«PKGBUILDDIR»/tools/lldb/source/Expression/ClangExpressionParser.cpp:324: 
warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/usr/bin/ld: .eh_frame_hdr refers to overlapping FDEs.
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[5]: *** [/«PKGBUILDDIR»/build-llvm/Release/lib/liblldb.so] Error 1


The error .eh_frame_hdr had already be seen elsewhere and on other
architectures for example llvm-3.4 on s390x so I'm not sure what the
real cause is, and how kbsd specific it is. I assume we will see it
more and more often on more architectures when more chroots are
updated.

The error message had been introduced with
http://permalink.gmane.org/gmane.comp.gnu.binutils/66759 to detect an
error, so we seem to need a fix for the underlying error.



Andi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763801: dico FTBFS on several arches

[Andreas Barth]

Package: dico
Version: 2.2-6
Severity: serious

Hi,

this package fails to build on several architectures.

For arm64, I'd recommend using dh_autoreconf (which would be good for all
arches in future).

For s390x and mips*, the build fails with the following errors:
##  ##
## GNU dico 2.2 test suite. ##
##  ##

Match

  1: exact   FAILED (exact.at:19)
  2: prefix  FAILED (prefix.at:19)
  3: suffix  FAILED (suffix.at:19)
  4: Levenshtein FAILED (lev.at:19)

Define

  5: define  FAILED (define.at:19)

Show

  6: show db FAILED (showdb.at:19)
  7: show info   FAILED (showinfo.at:19)
  8: show lang info  FAILED (showlang.at:19)

## - ##
## Test results. ##
## - ##

ERROR: All 8 tests were run,
8 failed unexpectedly.





Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763802: guile-cairo FTBFS on armhf / armel because of broken guile-??-dev

[Andreas Barth]

Package: guile-cairo
Version: 1.4.0-3.1
Severity: serious

Hi,

this package FTBFS on armhf / armel with
guile-snarf -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabi/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12  -I. -Wall -Werror  -pthread 
-I/usr/include/guile/2.0  guile-cairo.c  guile-cairo.x \
|| { rm guile-cairo.x; false; }
/usr/bin/guile-snarf: 54: /usr/bin/guile-snarf: gcc-4.8: not found
make[3]: *** [guile-cairo.x] Error 1


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745969: guile-1.8: FTBFS: conflicting types for 'yyget_leng'

[Andreas Barth]

* Rob Browning (r...@defaultvalue.org) [141002 18:59]:
 Daniel Schepler dschep...@gmail.com writes:
 
  Well, I was actually just pulling it into my bootstrapping process as a 
  build 
  dependency of swig2.0 and autogen.
 
 OK, I've filed migration bugs against both.  I'm guessing that perhaps
 once they migrate, you can migrate?

I'm not sure if this will actually happen in time for jessie, because looking
at the current packages in testing using guile-1.8:

anubis: anubis [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
not yet updated, no explizit patch

dico: dico-module-guile [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390x]
FTBFS on three arches since the update, bug just filed

drgeo: drgeo [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
Bug closed by package still depends on guile-1.8

gnubik: gnubik [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
waiting for migration (3 of 5 days)

guile-cairo: guile-cairo [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390x]
 guile-cairo-dev [amd64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x]
FTBFS on two arches since the update, because guile-snarf depends on gcc-4.8 
without an package dependency
(at least on armhf / armel), bug just filed

guile-lib: guile-library
Still depends on guile-1.8 in spite of the NMU

lilypond: lilypond [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips 
mipsel powerpc s390x]
waiting on upstream

mailutils: mailutils-guile
not fixed

trackballs: trackballs [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390x]
nothing yet


Especially as the freeze is in about a month, I don't think this will
be acomplished unless someone is pushing really hard right now. So I
think it would be helpful to fix the guile-1.8-bug now. Of course,
individual packages could still migrate to guile-2.0 as they consider
fit, until the freeze date.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745332: Please depend on krb5-multidev rather than libkrb5-dev

[Andreas Barth]

Control: reopen -1
Control: severiy -1 serious

* Jelmer Vernooij (jel...@debian.org) [141002 19:45]:
 +  * Depend on krb5-multidev rather than libkrb5-dev.

Unfortunatly the package now depends on libkrb5-multidev instead of
libkrb5-dev or krb5-multidev (i.e. a lib too much in front of the
binary dependency). It would be nice to get this fixed soon.





Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763593: openjpegs binaries are taken over

[Andreas Barth]

Package: openjpeg
Version: 1.5.2-2
Severity: serious

Hi,

the following packages from openjpeg are taken over by another
package:
openjpeg-tools, openjpip-dec-server, openjpip-server, openjpip-viewer

Amongst others that leads to the fact that openjpeg can't be uploaded
anymore because any upload would be rejected because there are too new
packages in the archive. This is also true after openjpeg2 dropped
those packages because they are uploaded to unstable, and new uploads
need a higher version number.

As it is planned to get rid of openjpeg (see #761356 ) I would
recommend to just drop the packages from openjpeg.

As this is required for testing migration of the new architectures I'd
intend to upload this fix to unstable in about a week unless there is
a reason why not.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763593: openjpegs binaries are taken over

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [141001 20:23]:
 As it is planned to get rid of openjpeg (see #761356 ) I would
 recommend to just drop the packages from openjpeg.

We had some discussion on this on #-ftp today. One is that it seems
that jessie will release with openjpeg, not openjpeg2. The other is
that Adam D. Barratt had given the recommendation to upload openjpeg
with an epoch to take back the packages.

As both are connected and fit to each other, this is what I plan to
do.

I'm happy to support you by uploading an appropriate NMU. Please just
indicate if that would help you.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763691: cdo FTBFS on ppc64el

[Andreas Barth]

Package: cdo
Version: 1.6.4+dfsg.1-5
Severity: important

Hi,

this package FTBFS on ppc64el. Looking at details, this seems to be
due to the fact that the _ARCH_PWR6 is set. In libcdi/src/cgribexlib.c
the following register are not liked by gcc:

double register dmin[__UNROLL_DEPTH_1];
double register dmax[__UNROLL_DEPTH_1];


Further on, the build fails with
libtool: link: gcc -std=gnu99 -g -O2 -fPIE -fstack-protector-strong
-Wformat -Werror=format-security -Wall -pedantic -fPIC -pthread -fPIE
-pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cdi cdi.o  -L/usr/lib
-L/usr/lib/powerpc64le-linux-gnu/hdf5/serial/lib -Wl,--as-needed
../src/.libs/libcdi.so -lgrib_api -lnetcdf -lhdf5_hl -lhdf5 -lpng
-ljasper -lm -ljpeg -lz
/usr/lib/powerpc64le-linux-gnu/libcurl-gnutls.so -pthread
../src/.libs/libcdi.so: undefined reference to `__fsel'

A fix for this is still wanted (but the references are also
_ARCH_PWR6-dependend)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763691: cdo FTBFS on ppc64el

[Andreas Barth]

Control: tag -1 patch

* Andreas Barth (a...@ayous.org) [141001 22:54]:
 Further on, the build fails with
 libtool: link: gcc -std=gnu99 -g -O2 -fPIE -fstack-protector-strong
 -Wformat -Werror=format-security -Wall -pedantic -fPIC -pthread -fPIE
 -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cdi cdi.o  -L/usr/lib
 -L/usr/lib/powerpc64le-linux-gnu/hdf5/serial/lib -Wl,--as-needed
 ../src/.libs/libcdi.so -lgrib_api -lnetcdf -lhdf5_hl -lhdf5 -lpng
 -ljasper -lm -ljpeg -lz
 /usr/lib/powerpc64le-linux-gnu/libcurl-gnutls.so -pthread
 ../src/.libs/libcdi.so: undefined reference to `__fsel'
 
 A fix for this is still wanted (but the references are also
 _ARCH_PWR6-dependend)

With Aurelians help, this could be fixed by adding an appropriate
include.


The (working) patch is

diff -ur cdo-1.6.4+dfsg.1~/libcdi/src/cgribexlib.c 
cdo-1.6.4+dfsg.1/libcdi/src/cgribexlib.c
--- cdo-1.6.4+dfsg.1~/libcdi/src/cgribexlib.c   2014-07-05 13:34:19.0 
+
+++ cdo-1.6.4+dfsg.1/libcdi/src/cgribexlib.c2014-10-01 21:08:29.080086839 
+
@@ -5,6 +5,7 @@
 
 #ifdef _ARCH_PWR6
 #pragma options nostrict
+#include ppu_intrinsics.h
 #endif
 
 #if defined (HAVE_CONFIG_H)
@@ -908,8 +909,8 @@
 size_t i, j;
 size_t residual =  datasize % __UNROLL_DEPTH_1;
 size_t ofs = datasize - residual;
-double register dmin[__UNROLL_DEPTH_1];
-double register dmax[__UNROLL_DEPTH_1];
+double dmin[__UNROLL_DEPTH_1];
+double dmax[__UNROLL_DEPTH_1];
 
 for ( j = 0; j  __UNROLL_DEPTH_1; j++) 
   {



I'm happy to help fixing this bug, if useful also by an NMU. As this
is one of the last few remaining uninstallables in testing I intend to
do so next week unless there is a reason why not.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756648: Fwd: Bug#756648: mplayer2: add support for ppc64el

[Andreas Barth]

Hi Reinhard,


* Reinhard Tartler (siret...@gmail.com) [141001 21:14]:
 The proposed patch (attached to this email) makes sense to me for
 inclusion into your mplayer2.git. Can you incorporate it?

this issue is now one of the few remaining uninstallability issues in
testing. For this reason it would be nice if you could upload this fix
to Debian, even in case it's not yet included in upstream. If useful
I'd be happy to help by uploading an NMU. If there is no reason why
not, I'd do so next week.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763718: gcc-defaults is not binNMU-safe

[Andreas Barth]

Package: gcc-defaults
Version: 1.130

Hi,

gcc-defaults is not binNMU-safe, the reason for this is that
libgcj-common is arch=all, and the dependencies on it from other
packages like libgcj-bc contain the binary epoch. The most easiest fix
for this is to change libgcj-common to arch=any as the remaining
packages. Given the small size of the packages this shouldn't hurt
much.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708716: mame: ftbfs with eglibc-2.17

[Andreas Barth]

* Cesare Falco (cesare.fa...@gmail.com) [141002 05:36]:
Hello Jeremy,
I have made a short patch on my git development branch to be committed
ASAP and fowarded the issue upstream. I guess it will be fixed in
0.149.

Would be nice if you could upload the fixed version soon. The freeze
is upcoming.


I tried to build on top of git, it fails with
No package 'gtk+-2.0' found
Package gconf-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gconf-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gconf-2.0' found
In file included from src/osd/sdl/dview.c:2:0:
src/osd/sdl/dview.h:4:21: fatal error: gtk/gtk.h: No such file or directory
 #include gtk/gtk.h
 ^
compilation terminated.

Installing of libgtk2.0-dev and libgconf2-dev helped compiling the
package, so they should be added to build-dependencies (or
configuration options tweaked so that they are no longer needed).


Even git fails to build with
Linking mame...
/usr/bin/ld: obj/sdl64/libocore.a(sdlsync_tc.o): undefined reference to symbol 
'pthread_join@@GLIBC_2.17'
//lib/powerpc64le-linux-gnu/libpthread.so.0: error adding symbols: DSO missing 
from command line
collect2: error: ld returned 1 exit status
makefile:762: recipe for target 'mame' failed




Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

[Andreas Barth]

* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 11:27]:
 On 28.09.2014 10:24, Moritz Muehlenhoff wrote:
 Package: ffmpeg
 Severity: serious

 As written before we can have only libav or ffmpeg in jessie.
 I'm filing this blocker bug to prevent testing migration until
 this is sorted out.

 As I have explained [1], I see no security problem with having FFmpeg  
 and Libav in Jessie, in particular because this is already the case for  
 Wheezy, as chromium embeds a copy of FFmpeg.

First of all, I think it is very good news that we now have FFmpeg
available in Debian. Thank you for your work on it, it's appreciated.

However, the open question is (especially with the upcoming release),
do we want to have it in jessie? (That we probably want FFmpeg in
testing in the long run is something else, but the current discussion
is especially about jessie.)

I also think it's good that you actively raised this discussion, even
if it is perhaps not working as you would have like it. Please
continue this good style.


Another remark, we are already quite late in the cycle. At this point
it is too late to have greater changes to jessie. So even if jessie is
not officially frozen, larger changes are not possible anymore
(without disturbing the time plan).


 So would you please explain why you see a problem?

I hope we end this discussion on an agreement about the jessie plans.

However, to avoid misunderstandings at a later moment, I need to point
out that the final decision of what is part of jessie is taken by the
release team (or ultimatly the release managers). All of RC-bugs,
testing migration scripts etc are very valuable helpers because it
wouldn't be possible to manage it otherwise, but in the end they are
helpers.

The release policy does say Packages must be security-supportable. I
would be surprised if a statement from the security team (assuming
that Moritz raised that bug report with his security team-hat on and
not privately) that they would like to have only one of libav and
ffmpeg in jessie would be overruled by the release team.

Now seeing the statements from the libav maintainers (which of course,
as this is an overlaping jurisdiction, could be escalated to the tech
ctte), that we already have transition freeze and the time planings
for jessie, makes it quite unlikely (or rather: impossible) to switch
from libav to FFmpeg in time for jessie. (Of course, for jessie+1
there is enough time for the transition. And for jessie+1 we will have
enough experience with FFmpeg in Debian to perhaps see things in a
different light.)


So from my experience I assume the final answer would look similar to
It's too late for jessie, sorry. Which might be a pity but, well,
that's how it is.




Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763148: Prevent migration to jessie

[Andreas Barth]

* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 14:36]:
 On 28.09.2014 12:47, Andreas Barth wrote:

 The release policy does say Packages must be security-supportable. I
 would be surprised if a statement from the security team (assuming
 that Moritz raised that bug report with his security team-hat on and
 not privately) that they would like to have only one of libav and
 ffmpeg in jessie would be overruled by the release team.

 Nonetheless both are in wheezy and will be in jessie, unless chromium  
 gets removed from testing.

There is a distinction between an old and a new package.

However (and please note that I'm not a member of the security team
and just speak for myself here as always when not otherwise marked) if
it would be possible to replace the internal code copy in chromium
by a reference to ffmpeg (but it's not possible with libav), that will
probably lead to a re-evalutation. (That doesn't necessarily mean
sucess guranteed, but it looks to me as it will not make things
worse.)

Perhaps you always intended that, but at least I didn't understand it
that way yet.


 I absolutely cannot understand why the security team would prefer to  
 have an embedded code copy instead of a properly packaged library.

I don't think they do that. However, I can understand why one embedded
code copy is better than one embedded code copy plus a library in
addition to it.




Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763058: nmu: doxygen_1.8.7-3

[Andreas Barth]

* Sylvestre Ledru (sylves...@debian.org) [140928 14:15]:
On 27/09/2014 18:54, Andreas Barth wrote:

 See e.g. [3]https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
 | Every time the shared library ABI changes in a way that may break
 | binaries linked against older versions of the shared library, the
 | SONAME of the library and the corresponding name for the binary
 | package containing the runtime shared library should change.
 
 Can you please do that so that we could schedule the binNMUs after
 this is done?


The package name is libclang1-3.5
and the soname is libclang-3.5.so.1
Initially, I uploaded with libclang-3.5.so as soname since the ABI
remains
the same over a version of libclang but dpkg-shlibdeps complained about
the missing .1 even
if it seems valid in the policy
[4]https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
The soname may instead be of the form name-major-version.so, such as
libdb-5.1.so, in which case the name would be libdb and the version
would be 5.1. 
What would you want in term of package naming ? I don't know what would
work best here
libclang-3.5.1 is kind of a bad name.

Basically there is no really nice solution there because the
packagename libclang1-3.5 was already used for the soname libclang.so.1.

The two major options are:

1. Change back the soname (which is of course wrong otherwise)
2. Change the package name to something like libclang1-3.5a.

I also have an idea for an ugly hack but I need to think a bit more
about it. From package POV it might be the niciest, but I'm not sure
if it works (which is a precondition for everything). I'll update this
mail tonight.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763058: nmu: doxygen_1.8.7-3

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [140928 14:32]:
 I also have an idea for an ugly hack but I need to think a bit more
 about it. From package POV it might be the niciest, but I'm not sure
 if it works (which is a precondition for everything). I'll update this
 mail tonight.

What works in practice, and seems to be ok-ish from a theoretical POV
is to create a symlink from libclang-3.5.so.1 to
/usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1
during build time (as part of the deb file). This allows doxygen to
work again.

(Also, all previous packages were broken according to policy because
that symlink was created only at configure time by ldconfig.  However
the symlink needs to be part of the package so that the lib is
available before configure. Just a notice, there doesn't seem to be a
fallout from that, but should be kept in mind for future packages.)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763058: nmu: doxygen_1.8.7-3

[Andreas Barth]

* Sylvestre Ledru (sylves...@debian.org) [140927 16:51]:
 nmu doxygen_1.8.7-3 . ALL . -m binMNU because of the libclang change of 
 soname
 
 I updated the soname as part of the coordination to switch to llvm 3.5.
 https://release.debian.org/transitions/html/llvm-defaults-3.html

Did you also switch the binary package name? For any soname change you
need to have the package name to follow.

See e.g. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
| Every time the shared library ABI changes in a way that may break
| binaries linked against older versions of the shared library, the
| SONAME of the library and the corresponding name for the binary
| package containing the runtime shared library should change.

Can you please do that so that we could schedule the binNMUs after
this is done?


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762959: ABI break: missing libclang.so.1

[Andreas Barth]

Hi,

* Sylvestre Ledru (sylves...@debian.org) [140927 20:10]:
 On 26/09/2014 17:52, Helmut Grohne wrote:
  Package: libclang1-3.5
  Version: 1:3.5-2
  Severity: serious
  Control: affects -1 doxygen
 
  Dear clang maintainers,
 
  I noticed that installing doxygen in a fresh sid chroot results in an
  unusable binary:
 
  $ doxygen
  doxygen: error while loading shared libraries: libclang.so.1: cannot open 
  shared object file: No such file or directory
  $
 I am sorry about that. I have a build running which should fix that.
 I will let you know later today.

Helmut pointed out on IRC that the symlink from
from libclang-3.5.so.1 to /usr/lib/`dpkg-architecture 
-qDEB_BUILD_MULTIARCH`/libclang.so.1
is missing if the package libclang1 is installed.

My investigation pointed to the fact that the file installed in
/usr/lib/(arch)/libclang-3.5.so.1 has now the soname libclang-3.5.so
and not anymore libclang.so.1. So the ldconfig-call in postinst
doesn't create the symlink from libclang.so.1 to libclang-3.5.so.1
anymore.


The probably best fix for that would be to go back to the previous
soname if there is no strong reason against. Otherwise changing soname
means that a new library package should be created, but as we are
already past transition time for the next release, that would be
better early in the next cycle. (If a new library package is created,
binNMUs are possible to replace the binary packages with links to the
new library package. As it is now, any package built against libclang1
will become unusable in testing if it migrates on its own, and has
wrong and broken dependencies.)



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763115: guile-2.0 FTBFS on armhf

[Andreas Barth]

Package: guile-2.0
Version: 2.0.11+1-5
Severity: serious

Hi,

guile-2.0 now FTBFS on armhf:
  CC   libguile_2.0_la-regex-posix.lo
In file included from vm.c:668:0:
vm-engine.c: In function 'vm_regular_engine':
vm-engine.c:168:1: error: r7 cannot be used in asm here
 }
 ^
  CC   guile-guile.o
flex -t ./c-tokenize.lex  c-tokenize.c || { rm c-tokenize.c; false; }
  GEN  c-tokenize.o
  GEN  guile_filter_doc_snarfage
make[4]: *** [libguile_2.0_la-vm.lo] Error 1
make[4]: *** Waiting for unfinished jobs
Makefile:3190: recipe for target 'libguile_2.0_la-vm.lo' failed

(I thought we already had a bit of discussion about that last weekend,
but failing to find the bug report I submit this one now.)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739725: Please support arm64 and ppc64el

[Andreas Barth]

Hi Ian,

* dann frazier (da...@debian.org) [140921 14:44]:
 Please enable the arm64 and ppc64el architectures in debian/control.
 The existing source package is known to build fine on these
 architectures in Ubuntu:

can you please apply that fix in your next upload? Or would you prefer
another NMU of the package? (Please note that we need this fixed to
release with ppc64el / arm64, which are both in testing as of now.)



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761650: closed by Sylvestre Ledru sylves...@debian.org (Bug#761650: fixed in llvm-toolchain-3.5 1:3.5-2~exp1)

[Andreas Barth]

Hi,

* Debian Bug Tracking System (ow...@bugs.debian.org) [140921 20:09]:
 Source: llvm-toolchain-3.5
 Source-Version: 1:3.5-2~exp1
 
 We believe that the bug you reported is fixed in the latest version of
 llvm-toolchain-3.5, which is due to be installed in the Debian FTP archive.

would it be possible to upload that to unstable as well soon?
Currently llvm-toolchain-3.5 blocks the testing-migration of doxygen.



Thanks,
Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761316: printer-driver-splix depends on ghostscript-cups, which is not built anymore by src:ghostscript

[Andreas Barth]

* Luca Niccoli (lultimou...@gmail.com) [140918 08:25]:
Hi, I will look into this in the next few days.
The dependency should be on the gstoraster executable which is now
indeed in cups-filter.

Sorry for pressing on that, but this blocks the testing migration of
ghostscript, which in turn is necessary for getting the number of
uninstallabilities down for the new arches. So there are two options,
either getting this fixed asap, or remove splix from testing. I'd be
happy if I could help getting this fixed, and if it would be useful
I'd be happy to sponsor an upload, or to do an NMU.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761821: Doesn't respect maximum number of parallel threads according to DEB_BUILD_OPTIONS

[Andreas Barth]

Package: qtwebkit
Version: 2.3.2.dfsg-4
Severity: important

Hi,

qtwebkit doesn't respect the parallel=8 from DEB_BUILD_OPTIONS on the
mips autobuilders but builds with more paralle threads. This slows
down the autobuilder, plus the other build running on it in parallel:
| DEB_BUILD_OPTIONS=parallel=6
| [...]
| Calling 'make  -j16 incremental' in /«PKGBUILDDIR»/WebKitBuild/Release


Please take the number of parallel threads from DEB_BUILD_OPTIONS, and
not by guessing how many CPUs should be yours.


Thanks,
Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756908: [Debichem-devel] Bug#756908: ergo: FTBFS on mips, mipsel, powerpc, s390x: test suite failures

[Andreas Barth]

* Michael Banck (mba...@debian.org) [140915 01:49]:
 CCing the powerpc and mipsel buildd maintainers for that.

given back ergo on both architectures.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751504: telepathy-logger-qt: add support for ppc64el symbol set

[Andreas Barth]

* Breno Leitao (bren...@br.ibm.com) [140913 09:32]:
 The package telepathy-logger-qt does not build on ppc64el because the symbol 
 set
 is incorrect, causing the build to fail, as shown in the following log:

I'd be willing to help fixing this bug, if necessary also by
sponsoring an upload / upload an NMU. Unless there is a reason why
not, I intend to upload an NMU within the next days.


I also updated the symbols-patch, the new patch is below.


Andi

--- telepathy-logger-qt-0.8.0~/debian/libtelepathy-logger-qt4-1.symbols 
2014-06-11 21:33:10.0 +
+++ telepathy-logger-qt-0.8.0/debian/libtelepathy-logger-qt4-1.symbols  
2014-09-13 09:03:12.458321561 +
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 0.8.0 alpha amd64 armel armhf hppa hurd-i386 i386 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64 s390x sparc
+# SymbolsHelper-Confirmed: 0.8.0 alpha amd64 armel armhf hppa hurd-i386 i386 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64el ppc64el s390x sparc
 libtelepathy-logger-qt4.so.1 libtelepathy-logger-qt4-1 #MINVER#
  
_ZN3Tpl10LogManager10queryDatesERKN2Tp9SharedPtrINS1_7AccountEEERKN5QGlib10RefPointerINS_6EntityEEENS_13EventTypeMaskE@Base
 0.6.0
  
_ZN3Tpl10LogManager11queryEventsERKN2Tp9SharedPtrINS1_7AccountEEERKN5QGlib10RefPointerINS_6EntityEEENS_13EventTypeMaskERK5QDate@Base
 0.6.0
@@ -213,14 +213,14 @@
  _ZTVN3Tpl9CallEventE@Base 0.6.0
  _ZTVN3Tpl9LogWalkerE@Base 0.8.0
  _ZTVN3Tpl9TextEventE@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
QGlib::Object-in-Tpl::CallEvent@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
QGlib::Object-in-Tpl::Entity@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
QGlib::Object-in-Tpl::Event@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
QGlib::Object-in-Tpl::LogManager@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for QGlib::Object-in-Tpl::CallEvent@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for QGlib::Object-in-Tpl::Entity@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for QGlib::Object-in-Tpl::Event@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for QGlib::Object-in-Tpl::LogManager@Base 0.6.0
  (c++|arch=sparc)construction vtable for 
QGlib::Object-in-Tpl::LogWalker@Base 0.8.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
QGlib::Object-in-Tpl::TextEvent@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
Tpl::Event-in-Tpl::CallEvent@Base 0.6.0
- (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64 !s390x)construction vtable for 
Tpl::Event-in-Tpl::TextEvent@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for QGlib::Object-in-Tpl::TextEvent@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for Tpl::Event-in-Tpl::CallEvent@Base 0.6.0
+ (c++|arch=!alpha !amd64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !powerpc !ppc64el !ppc64 !s390x)construction 
vtable for Tpl::Event-in-Tpl::TextEvent@Base 0.6.0
  (c++)virtual thunk to Tpl::CallEvent::~CallEvent()@Base 0.6.0
  (c++)virtual thunk to Tpl::Entity::~Entity()@Base 0.6.0
  (c++)virtual thunk to Tpl::Event::~Event()@Base 0.6.0


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761466: libkolabxml FTBFS on ppc64el

[Andreas Barth]

Package: libkolabxml
Version: 1.0.2-1
Severity: important

Hi,

libkolabxml FTBFS repeatedly on ppc64el, see
https://buildd.debian.org/status/logs.php?pkg=libkolabxmlver=1.0.2-1arch=ppc64el

FAIL!  : ConversionTest::geoUriTest() Compared doubles are not the same (fuzzy 
compare)
   Actual (lat): 34.056
   Expected (-34.056): -34.056


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746505: [Pkg-lirc-maint] Bug#746505: fix FTBFS on new architectures

[Andreas Barth]

* Stefan Lippers-Hollmann (s@gmx.de) [140911 00:47]:
 Ideally I can get the new version into shape until the end of the 
 weekend, but feel free to push a porter-NMU as needed. The patch 
 attached to this bug should work and there's no need to bother about 
 the pending new version (it's fixed there already in an equivalent way)
 or a formal NMU-diff. I'll take care to acknowledge the NMU and not to 
 conflict with the testing migration then.

Thanks, Uploaded.

Regards,
Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757112: please build using dh-autoreconf

[Andreas Barth]

Hi,

* Matthias Klose (d...@debian.org) [140910 13:52]:
 please build using dh-autoreconf,

as ppc64el is now in Debian, I would be willing to help fixing this
bug, if required also by an NMU. If there is no reason why not, I'd
upload it within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757953: libverto: autoreconf to update config.{sub, guess} and libtool.m4 to fix FTBFS for ppc64el port

[Andreas Barth]

* ravi (r...@linux.vnet.ibm.com) [140910 13:56]:
 We have also successfully verified building libverto source package on  
 ppc64el build machine after applying attached patch.

As ppc64el is now in Debian, I'd be willing to help fixing this bug,
if useful also by an NMU. If there is no reason why not, I intend to
upload an NMU within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752415: mozjs: [ftbfs] add ppc64el symbols and usage of autotools-dev

[Andreas Barth]

* Fernando Seiti Furusato (ferse...@br.ibm.com) [140910 14:00]:
 The package mozjs fails to build from source on ppc64el due to the symbols
 file not containing ppc64el architecture.

As ppc64el is now in sid, I'd be happy to help fixing this bug, if
useful also by an NMU. Unless there is a reason why not I intend to
upload the package within the next days. On that occasion I would also
update the symbols for other architectures pending in the bts as well
as #682771 (respect DEB_BUILD_OPTIONS nocheck). If possible I would
use dh-autoreconf instead of autotools-dev.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757455: please run dh_autoreconf or manually update m4/libtool.m4 for ppc64el

[Andreas Barth]

* Matthias Klose (d...@debian.org) [140910 14:19]:
 trying to use dh_autoreconf:

It works with the following patch:
diff -ur xfsprogs-3.2.1~/debian/control xfsprogs-3.2.1/debian/control
--- xfsprogs-3.2.1~/debian/control  2014-05-02 00:09:15.0 +
+++ xfsprogs-3.2.1/debian/control   2014-09-10 14:14:34.026319172 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: XFS Development Team x...@oss.sgi.com
 Uploaders: Nathan Scott nath...@debian.org, Anibal Monsalve Salazar 
ani...@debian.org
-Build-Depends: uuid-dev, autoconf, debhelper (= 5), gettext, libtool, 
libreadline-gplv2-dev | libreadline5-dev, libblkid-dev (= 2.17), 
linux-libc-dev, autotools-dev
+Build-Depends: uuid-dev, dh-autoreconf, debhelper (= 5), gettext, libtool, 
libreadline-gplv2-dev | libreadline5-dev, libblkid-dev (= 2.17), linux-libc-dev
 Standards-Version: 3.9.1
 Homepage: http://oss.sgi.com/projects/xfs/
 
diff -ur xfsprogs-3.2.1~/debian/rules xfsprogs-3.2.1/debian/rules
--- xfsprogs-3.2.1~/debian/rules2014-05-02 00:09:15.0 +
+++ xfsprogs-3.2.1/debian/rules 2014-09-10 14:13:18.182294515 +
@@ -35,7 +35,7 @@
 .census:
@echo == dpkg-buildpackage: configure 12
$(checkdir)
-   dh_autotools-dev_updateconfig
+   AUTOHEADER=/bin/true dh_autoreconf
$(options) $(MAKE) include/platform_defs.h
touch .census
 
@@ -58,7 +58,7 @@
$(MAKE) distclean
-rm -rf $(dirme) $(dirdev) $(dirdi)
-rm -f debian/*substvars debian/files* debian/*.debhelper
-   dh_autotools-dev_restoreconfig
+   dh_autoreconf_clean
dh_clean
 
 binary-indep:

As this package is required to build ceph, libvirt and redhat-cluster
I'd be willing to help fixing it, if required also by an NMU. Unless
there is a reason why not, I intend to upload the fix within the next
days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757112: [Debian-hebrew-package] Bug#757112: please build using dh-autoreconf

[Andreas Barth]

* Matthias Klose (d...@debian.org) [140910 16:20]:
 please can you NMU all the M-A patches as well? Or just upload the Ubuntu
 package? ;)

Lior, are the m-a-changes for you ok as well? If so, I could include
them in the upload.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746505: [Pkg-lirc-maint] Bug#746505: fix FTBFS on new architectures

[Andreas Barth]

* Stefan Lippers-Hollmann (s@gmx.de) [140910 14:24]:
 On Wednesday 30 April 2014, Breno Leitao wrote:
  Lirc is curretnly failing to build on new architectures, as ppc64el.
  In order to enable this package to be built on new architectures, autoreconf
  needs to be called before the package build. In order to do it, I am 
  providing
  a patch that follows the instructions at

 Thanks for the patch, I was planning to enable autoreconf (following 
 the recent threads on d-devel) anyways, so this patch is very welcome
 and it will be part of the next lirc upload (which may take 1-2 months 
 to finalize, as there is some renewed upstream activity).

As ppc64el is now part of Debian, I'd be willing to help fixing this
bug, including sponsoring an upload or uploading an NMU. Do you have a
package at hand, or would an NMU be more appropriate? If there is no
newer package, and no reason against an NMU, I'll upload a fix
probably end of the week.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751506: libgee: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

[Andreas Barth]

* Breno Leitao (bren...@br.ibm.com) [140910 22:20]:
 Currently libgee fails to build on the new architecture, as shown in the
 following log for ppc64el architecture: 

As ppc64el is now in Debian, I'd be willing to help fixing this bug,
if useful also by uploading an NMU. Unless there is a reason to not do
so, I'd upload the package within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757211: patch for libmediaart FTBFS on ppc64el

[Andreas Barth]

Hi,

this patch fixes the issue.

As this is blocking a couple of other packages I'd like to help fixing
this bug as good as possible, also by uploading an NMU. I'd do so in
the next days unless there is a reason why not. 


Andi


diff -u libmediaart-0.4.0~/debian/control libmediaart-0.4.0/debian/control
--- libmediaart-0.4.0~/debian/control   2014-04-01 18:29:01.0 +
+++ libmediaart-0.4.0/debian/control2014-09-09 09:04:42.290322136 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Michael Biebl bi...@debian.org
 Build-Depends: debhelper (= 9),
-   autotools-dev,
+   dh-autoreconf,
gtk-doc-tools (= 1.8),
libglib2.0-dev (= 2.35.1),
libgdk-pixbuf2.0-dev (= 2.12.0),
diff -u libmediaart-0.4.0~/debian/rules libmediaart-0.4.0/debian/rules
--- libmediaart-0.4.0~/debian/rules 2014-04-01 18:29:01.0 +
+++ libmediaart-0.4.0/debian/rules  2014-09-09 09:05:01.658318003 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh $@ --with autotools_dev
+   dh $@ --with autoreconf
 
 override_dh_auto_configure:
dh_auto_configure -- \


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727518: reuse this issue for the more general solution to use dh-autoreconf

[Andreas Barth]

* Matthias Klose (d...@debian.org) [140909 09:12]:
 Reusing this report for the more general solution to also update
 the libtool.m4 and/or aclocal.m4 files, needed for the port mentioned
 in bug #726404.

As this starts to block packages on ppc64el, I'd like to help fixing
this bug, if useful also by uploading an NMU. Unless there is a reason
why not, I'd do so within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738140: powerpc-utils: please enable build on ppc64el

[Andreas Barth]

* Adam Conrad (adcon...@debian.org) [140908 10:53]:
 On Sun, Feb 09, 2014 at 09:11:28PM +1300, Michael Schmitz wrote:
  
  Thanks for pointing out that powerpc-ibm-utils has already been
  packaged. I'll try to keep that in mind for the next odd wishlist
  request in a few year's time.
  
  Packaged, and orphaned.  I think I'll rescue -ibm-utils while I'm on
  this warpath, and make sure the world's in good shape.
  
  I would have expected better of them. Anyway, if that keeps them off
  our back, it's well worth the effort.
 
 So, I've given things some thought since we had this conversation,
 and I'm thinking the following should happen:
 [...]

Any news on this topic? Also as ppc64el is now in the achive, it would
be good if we could get an upload soon.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749530: libotf: use dh-autoreconf to build on new architectures

[Andreas Barth]

* Fernando Seiti Furusato (ferse...@br.ibm.com) [140908 10:53]:
 Package libotf fails to build from source on ppc64el due to libtool
 configuration files being out of date.
 The usage of dh-autoreconf, included in the patch attached, will
 update the files properly.

I'd be willing to help fixing this bug, if useful also via sponsoring
an upload / an NMU. If there is no reason why not I'd upload an NMU
within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734029: libnetfilter-acct: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

[Andreas Barth]

* Logan Rosen (lo...@ubuntu.com) [140908 10:53]:
 For the ppc64el architecture in Ubuntu, since this package uses libtool, a 
 full
 autoreconf is necessary instead of just config.{sub,guess} updates with
 autotools-dev. This is because we need new libtool macros for ppc64el.

As ppc64el is now in the archive, I'd be willing to help fixinf this
bug, if necessary also via an NMU. If there is no reason why not, I'd
upload an NMU within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749530: libotf: use dh-autoreconf to build on new architectures

[Andreas Barth]

* Harshula (harsh...@debian.org) [140908 14:10]:
 On 08/09/14 20:59, Andreas Barth wrote:

 I'd be willing to help fixing this bug, if useful also via sponsoring
 an upload / an NMU. If there is no reason why not I'd upload an NMU
 within the next days.

 Is this super urgent?

Depends on your definition of superurgent. 

It prevents the build of emacs23 which is part of the standard
installation on DSAed hosts, and therefor useful for setting up a
porter box. But of course there are things more urgent than that.

Also, it's no effort for me to build and upload an NMU if you want
that. It's not a problem if you don't have much time now, and would
prefer if I just fix it for the moment.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760844: git FTBFS on ppc64el

[Andreas Barth]

Package: git
Version: 1:2.1.0-1
Severity: important
User: debian-powe...@lists.debian.org
Usertags: ppc64el

Hi,

git FTBFS on ppc64l due to the following testsuite failure.

not ok 136 - --contains works in a deep repo
#
#   expect 
#   i=1 
#   while test $i -lt 4000
#   do
#   echo commit refs/heads/master
#   committer A U Thor aut...@example.com $((10 + $i * 100)) +0200
#   data EOF
#   commit #$i
#   EOF
#   test $i = 1  echo from refs/heads/master^0
#   i=$(($i + 1))
#   done | git fast-import 
#   git checkout master 
#   git tag far-far-away HEAD^ 
#   run_with_limited_stack git tag --contains HEAD actual 
#   test_cmp expect actual
#
# failed 1 among 136 test(s)
1..136
make[3]: *** [t7004-tag.sh] Error 1
Makefile:44: recipe for target 't7004-tag.sh' failed



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558581: Missing autoreconf to fix 554821 or similar bugs in the future

[Andreas Barth]

Control: severity -1 important
Control: tags -1 + patch

Hi,

* Peter Fritzsche (peter.fritzs...@gmx.de) [140907 11:01]:
 [...]

this topic becomes now more important because it blocks the package from being
built on ppc64el, which in turn block xfce4-panel.

The usual fix of just adding cdbs/autoreconf does not work because autoreconf
adds a couple of -Werror, so the build fails with

| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/libdrm -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/startup-notification-1.0 -I.. -DWNCK_I_KNOW_THIS_IS_UNSTABLE 
-DWNCK_LOCALEDIR=\/usr/share/locale\ -DG_LOG_DOMAIN=\Wnck\ 
-DSN_API_NOT_YET_FROZEN=1 -D_FORTIFY_SOURCE=2 -Wall -Wstrict-prototypes 
-Wnested-externs -Werror=missing-prototypes 
-Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self 
-Werror=format-security -Werror=format=2 -Werror=missing-include-dirs -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -c tasklist.c  
-fPIC -DPIC -o .libs/libwnck_1_la-tasklist.o
| In file included from /usr/include/gtk-2.0/gtk/gtk.h:234:0,
|  from tasklist.h:27,
|  from tasklist.c:34:
| /usr/include/gtk-2.0/gtk/gtkitemfactory.h:47:1: warning: function declaration 
isn't a prototype [-Wstrict-prototypes]
|  typedef void (*GtkItemFactoryCallback)  ();
|  ^
| tasklist.c:990:6: error: no previous prototype for 
'wnck_tasklist_set_orientation' [-Werror=missing-prototypes]
|  void wnck_tasklist_set_orientation(WnckTasklist *tasklist, GtkOrientation 
orient)
|   ^
| tasklist.c: In function 'wnck_task_expose':
| tasklist.c:4179:16: warning: variable 'dgc' set but not used 
[-Wunused-but-set-variable]
|GdkGC *lgc, *dgc;
| ^
| tasklist.c:4179:10: warning: variable 'lgc' set but not used 
[-Wunused-but-set-variable]
|GdkGC *lgc, *dgc;
|   ^
| cc1: some warnings being treated as errors
| Makefile:820: recipe for target 'libwnck_1_la-tasklist.lo' failed


Adding -Wno-error=missing-prototypes to CFLAGS fixes this (and I think
that this is acceptable, because it didn't fail on that before
either, so it's not worse, and we get a bunch of other Werrors for basic
things).

diff -u -r ../libwnck-2.30.7~/debian/rules ../libwnck-2.30.7/debian/rules
--- ../libwnck-2.30.7~/debian/rules 2011-10-15 18:29:11.0 +
+++ ../libwnck-2.30.7/debian/rules  2014-09-08 13:33:02.354108129 +
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+include /usr/share/cdbs/1/rules/autoreconf.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/gnome.mk
@@ -9,6 +10,7 @@
 -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk
 
 LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed
+CFLAGS += -Wno-error=missing-prototypes
 
 DEB_CONFIGURE_EXTRA_FLAGS += \
--disable-gtk-doc \


Does this patch look ok? If so, do you want to upload it, or would an NMU be
helpful?


Andi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#236584: please add a filtering capability to the shell-backend

[Andreas Barth]

* Ryan Tandy (r...@nardis.ca) [140908 19:03]:
 On 07/03/04 03:27 AM, Roland Bauerschmidt wrote:
 Andreas Barth wrote:
 please add a filtering capability to the shell-backend (like the
 perl-backend currently has). The attached patch does this, and I need
 it for the bts2ldap-Gateway.

 Have you proposed your patch to the OpenLDAP list already? If not, I'd
 appreciate it a lot if you would. We're already having a lot of trouble
 maintaining the GNUTLS patch and should try to get stuff like this
 included upstream.

 I searched around a bit but couldn't find an upstream submission of this  
 patch, and current back-shell still lacks this feature.

 The patch you provided (thanks for that!) needs some updating to apply  
 to the current code. However it looks like it should be easy to fix up,  
 and I'd be happy to work on that if it helps someone. Do you still use  
 this feature anywhere?

Not now (I used that to provide the bts2ldap gateway for the list of
RC bugs before we had interfaces to the bts or even udd). However, I
will use it again soon (it's an quite easy way to get ldap connected
to some backend, and avoid that the backend needs to duplicate
something which is more easy to do in ldap).


 An explicit copyright notice or assignment to the public domain will  
 probably be needed. Would you be able to provide that? See  
 http://www.openldap.org/devel/contributing.html.

I'll go with this one:
 Redistribution and use in source and binary forms, with or without
 modification, are permitted only as authorized by the OpenLDAP Public
 License. 

(And just to be clear as this is legal stuff, this patch is derived
from the OpenLDAP-Sourcecode itself (of course, as a patch to it), and
not from any other work.)

If another assignment would be better, please just tell me.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758120: src:meanwhile: update aclocal.m4 and configure to fix FTBFS on ppc64el

[Andreas Barth]

Hi,

* Erwan Prioul (er...@linux.vnet.ibm.com) [140907 11:26]:
 While trying to build the package on ppc64el, it failed, due to missing  
 entry about powerpc64le in aclocal.m4 and configure files.
 Please consider this patch to fulfill that need.

I'm willing to help fixing this bug, if useful by uploading an NMU. As
this bug also blocks pidgin, I'd do so within a few days unless there
is a reason why not.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733185: lttoolbox: use dh-autoreconf instead of autotools-dev for better new-port coverage

[Andreas Barth]

* Colin Watson (cjwat...@ubuntu.com) [140907 17:25]:
 The ppc64el port requires a patch to libtool.m4.  I don't think that's
 in Debian yet, but when it is it will require autoreconfing a bunch of
 packages to pick it up.  libcdio could handle this quite easily by using
 dh-autoreconf rather than just autotools-dev; when automake and libtool
 are in use (as they are here), dh-autoreconf is a superset of
 autotools-dev, and it seems to still build just fine if I do the
 following.

I'd be willing help fixing this bug, if useful also by an NMU. If
there is no reason why not, I'd upload an NMU within the next days.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760626: libxfce4util FTBFS on ppc64el

[Andreas Barth]

Package: libxfce4ui
Version: 4.10.0-5
Severity: important

Hi,

this package FTBFS on ppc64el, see 
https://buildd.debian.org/status/fetch.php?pkg=libxfce4uiarch=ppc64elver=4.10.0-5stamp=1409855066

the final lines of the build contain:
| make[4]: Entering directory '/«PKGBUILDDIR»/libxfce4ui'
| nm: '.libs/libxfce4ui-1.so*': No such file

which indicate that dh-autoreconf would probably be enough to get that
fixed.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760626: libxfce4util FTBFS on ppc64el

[Andreas Barth]

Control: -1 patch 

* Andreas Barth (a...@ayous.org) [140906 09:28]:
 this package FTBFS on ppc64el, see 
 https://buildd.debian.org/status/fetch.php?pkg=libxfce4uiarch=ppc64elver=4.10.0-5stamp=1409855066
 
 the final lines of the build contain:
 | make[4]: Entering directory '/«PKGBUILDDIR»/libxfce4ui'
 | nm: '.libs/libxfce4ui-1.so*': No such file
 
 which indicate that dh-autoreconf would probably be enough to get that
 fixed.

This patch fixes the bug (plus replacing autotools-dev by dh-autoreconf in
debian/control). As this blocks about 50 packages, I'd be willing to
help fixing this bug, if useful also by an NMU.


Andi

diff -ur libxfce4ui-4.10.0~/debian/rules libxfce4ui-4.10.0/debian/rules
--- libxfce4ui-4.10.0~/debian/rules 2013-09-22 18:55:30.0 +
+++ libxfce4ui-4.10.0/debian/rules  2014-09-06 10:07:49.566318002 +
@@ -9,11 +9,10 @@
 endif
 
 %:
-   dh $@ --parallel --with autotools-dev 
+   dh $@ --parallel --with autoreconf
 
-override_dh_auto_configure:
-   dh_auto_configure -- --with-vendor-info=$(XFVENDOR) 
--disable-silent-rules \
-   --disable-gladeui
+override_dh_autoreconf:
+   dh_autoreconf xdt-autogen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752831: gpgme1.0: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4 and support ppc64el

[Andreas Barth]

Hi,

* Daniel Kahn Gillmor (d...@fifthhorseman.net) [140906 09:39]:
 When test building with dh-autoreconf on amd64, i get the following
 error toward the end of the build:
 
 make[3]: Entering directory '/home/dkg/src/pkg-gnupg/gpgme/doc'

It looks to me like the doc-directory is not used before
dh-autoreconf.  Could you verify that?


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752831: gpgme1.0: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4 and support ppc64el

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [140906 12:20]:
 Hi,
 
 * Daniel Kahn Gillmor (d...@fifthhorseman.net) [140906 09:39]:
  When test building with dh-autoreconf on amd64, i get the following
  error toward the end of the build:
  
  make[3]: Entering directory '/home/dkg/src/pkg-gnupg/gpgme/doc'
 
 It looks to me like the doc-directory is not used before
 dh-autoreconf.  Could you verify that?

I now built the package with the patch applied on amd64, and it built
fine (just taking the plain unstable package). Could you please
re-verify?


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752831: gpgme1.0: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4 and support ppc64el

[Andreas Barth]

* Breno Leitao (bren...@br.ibm.com) [140905 21:07]:
 The package gpgme1.0 fails to be built on ppc64el, as on new architecture, due
 to old libtool files, as shown on the link below. The main problem is that the
 new architecture is not identified as having shared libraries.
 
 http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/gpgme1.0_1.5.0-0.1_ppc64el.build
 
 Please consider applying this patch to enable this package to be built on
 the new ppc64el architecture. 

I'd be willing to help fixing this bug, if useful I'd upload an NMU.
Especially as this package prevent ~25 other packages to build, I'd do
so in the next days unless there is a reason why not.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760310: opencl-headers: use __vector for altivec to avoid conflicts

[Andreas Barth]

* Aurelien Jarno (aure...@debian.org) [140904 21:36]:
 Other distribution patches the internal copy of cl_platform.h included
 in opencv by replacing vector with __vector [2]. In Debian it has to
 be done in the opencl-headers package, as the internal copy is not used.
 The patch below fixes the issue. It would be nice if you can include it
 quickly as it currently block the ppc64el bootstrap in Debian. Thanks in
 advance.

I'd be willing to fix this bug by upload an NMU (this package is
required to get opencv built, and via that in turn e.g. kde4libs).

I.e. unless there is a reason why not, I'd upload the package during
the weekend to delayed.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756428: [Pkg-xfce-devel] Bug#756428: xfconf: 4.10.0-2

[Andreas Barth]

* Yves-Alexis Perez (cor...@debian.org) [140902 18:40]:
 On mar., 2014-07-29 at 18:04 -0300, Breno Leitao wrote:
  I just tried to find this explaination at [1], but no luck. Do you
  mind providing
  me the link where you explained why this is low priority?
 
 On all other ppc64el bugs opened (usually by various ibm people but not
 only). They don't even look tagged so it might be a bit hard to check.

ppc64el is now an official architecture, and this bug is blocking a
couple of other packages from being built. So a fix of this bug would
be helpful now.

If it helps I could upload this fix with an NMU. 



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756428: [Pkg-xfce-devel] Bug#756428: xfconf: 4.10.0-2

[Andreas Barth]

* Yves-Alexis Perez (cor...@debian.org) [140902 21:39]:
 On mar., 2014-09-02 at 20:42 +0200, Andreas Barth wrote:
  * Yves-Alexis Perez (cor...@debian.org) [140902 18:40]:
   On mar., 2014-07-29 at 18:04 -0300, Breno Leitao wrote:
I just tried to find this explaination at [1], but no luck. Do you
mind providing
me the link where you explained why this is low priority?
   
   On all other ppc64el bugs opened (usually by various ibm people but not
   only). They don't even look tagged so it might be a bit hard to check.
  
  ppc64el is now an official architecture, and this bug is blocking a
  couple of other packages from being built. So a fix of this bug would
  be helpful now.
  
  If it helps I could upload this fix with an NMU. 
 
 I already NACK'ed the patch touching the files directly, we need to make
 a clean autoreconf.
 
 I've started to investigate but again, that's a bit lower priority than
 the Jessie-related stuff.

So a patch with a normal dh-autoreconf would generally look
acceptable for you? (Just asking to be sure it's worth spending time
on it)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732286: closed by Nicolas Boullis nboul...@debian.org (Bug#732286: fixed in libcdio 0.92-1)

[Andreas Barth]

* Nicolas Boullis (nboul...@debian.org) [140831 01:46]:
 On Sat, Aug 30, 2014 at 11:29:51PM +0200, Andreas Barth wrote:
  
  thanks, could we get a fix of this bug also in unstable, or would it
  help if I upload an NMU? (This package is relevant to get about 50
  packages built, so if there is no reason why not I would upload an NMU
  in a couple of days).
 
 Well, it is my intention to upload libcdio 0.92-3 (or higher) to 
 unstable, but some more work is needed before I can do it: i need to 
 prepare packages for libcdio-paranoia (which was split out of libcdio), 
 and to coordinate with the release team for the library transition.

I'd be thankful if we could get the fix earlier than the transition
(especially as there is something to be done to get the packages
depending on this one to be built).

If it would be ok for you I could upload an NMU just fixing this issue
(which of course would be overwritten as soon as you upload a higher
version into unstable). Would that be possible?



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748131: pstoedit: Fix a FTBFS in new architectures

[Andreas Barth]

* Roland Stigge (sti...@antcom.de) [140831 14:07]:
 On 30/08/14 23:33, Andreas Barth wrote:
  * Breno Leitao (bren...@br.ibm.com) [140830 21:32]:
  pstoedit is failing to build on new architectures due to not 
  autoreconfiging
  before the build.  The recommend way to solve it is using dh-autoreconf
  scripts[1]. I just created a patch that fixes this problem. Find it 
  attached to
  this bug.
  
  I'd be willing to help fixing this bug by uploading an NMU. Actually,
  about 40 other packages depend on this package being fixed, so I would
  do so in the next days unless there is a reason why not.
 
 Thanks for working on this! Just uploaded pstoedit_3.62-2.

Thanks!


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760079: imagemagick FTBFS on ppc64el and/or after autoreconf

[Andreas Barth]

Package: imagemagick
Version: 8:6.7.7.10+dfsg-4
Severity: important

Hi,

after autoreconf (which in turn is required^Wthe usual thing to be
done to fix build errors like the one happening on ppc64l) imagemagick
FTBFS even on amd64 with the following error:

 fakeroot debian/rules binary-arch
dh_testdir
# Only run the testsuite to get more info in the build logs for now,
# but don't make a failing testsuite fail the whole build. Change it
# to a fatal error only once we've got an estimate on how harmful
# that would be.
make[1]: Entering directory '/home/aba/imagemagick-6.7.7.10+dfsg'
/usr/bin/make  check-am
make[2]: Entering directory '/home/aba/imagemagick-6.7.7.10+dfsg'
/usr/bin/make  tests/validate Magick++/demo/analyze Magick++/demo/button 
Magick++/demo/demo Magick++/demo/detrans Magick++/demo/flip 
Magick++/demo/gravity Magick++/demo/piddle Magick++/demo/shapes 
Magick++/demo/zoom Magick++/tests/appendImages Magick++/tests/attributes 
Magick++/tests/averageImages Magick++/tests/coalesceImages 
Magick++/tests/coderInfo Magick++/tests/color Magick++/tests/colorHistogram 
Magick++/tests/exceptions Magick++/tests/montageImages 
Magick++/tests/morphImages Magick++/tests/readWriteBlob 
Magick++/tests/readWriteImages wand/drawtest wand/wandtest
make[3]: Entering directory '/home/aba/imagemagick-6.7.7.10+dfsg'
  CC   tests/tests_validate-validate.o
  CCLD tests/validate
/usr/bin/ld: tests/tests_validate-validate.o: undefined reference to symbol 
'fmod@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
Makefile:6698: recipe for target 'tests/validate' failed
make[3]: *** [tests/validate] Error 1
make[3]: Leaving directory '/home/aba/imagemagick-6.7.7.10+dfsg'
Makefile:10532: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/home/aba/imagemagick-6.7.7.10+dfsg'
Makefile:10535: recipe for target 'check' failed
make[1]: *** [check] Error 2
make[1]: Leaving directory '/home/aba/imagemagick-6.7.7.10+dfsg'
*** Testsuite failed ***
cat: test-suite.log: No such file or directory
debian/rules:98: recipe for target 'check-stamp' failed
make: *** [check-stamp] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2

(Adding -lm to libtools gcc calls links without error, but of course
that's just part of the diagnosis and not a workaround.)



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753532: gtkspell: please run autoreconf to build properly on new architectures

[Andreas Barth]

* Fernando Seiti Furusato (ferse...@br.ibm.com) [140830 09:33]:
 That is due to the linker being incorrectly identified among other things, 
 which
 prevents .so files from being generated and installed.
 
 Including dh-autoreconf to the build fixes that problem so the package 
 installed
 works properly in addition to enabling the package to other new architectures.
 The patch attached contains such modification.

As this bugs blocks inkscape and indirectly cython / python-numpy to
be built (and this in turn another ~200 packages or so), and the
package is on the lowNMU-list, I will upload the fix now.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757585: missing libtool-update on smpeg

[Andreas Barth]

* Manuel A. Fernandez Montecelo (manuel.montez...@gmail.com) [140830 13:22]:
 Hi,
 
 2014-08-29 23:04 GMT+01:00 Andreas Barth a...@ayous.org:
  * Andreas Barth (a...@ayous.org) [140829 23:55]:
  - Remove everything from acinclude.m4 except the entry for socklen_t
(the last one).
 
  According to changelog that change was already done by Branden
  Robinson in 2001, and confirmed by Felix Geyer in 2011.
 
  For that reason I tend to commit that change again on Sunday evening
  unless I get review otherwise.
 
 I am a bit busy right now and will continue to be for a few days, so I
 cannot guarantee that I have time to review this within 10 days at
 least.

Ok. I will wait a bit to give other the chance to review the patches, even
though it looks fine for me.

 For me, it's fine if you want to NMU and do it ASAP, and I want to
 thank you anyway for finding the problem and the solution.

Thanks for allowing the NMU.



 Alas, I was helping to bootstrap the new arches NMUing other packages
 during the past few months, and now it's mine which is blocking
 things... :o)

I'm not saying my own packages never block ;)


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757585: missing libtool-update on smpeg

[Andreas Barth]

* Felix Geyer (fge...@debian.org) [140830 18:51]:
 Why is the AM_PROG_LIBTOOL - AC_PROG_LIBTOOL change needed?

Because autoreconf calls libtool only with AC_ and not with AM_, see
bug #759739 (IMHO an error with autoreconf, but I don't want to wait
for that with this fix). Or at least that was my experience.


 A test build with just the acinclude.m4 changes worked fine on pcc64el.

Hm. I think I'll also re-test it then.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755111: closed by Sebastian Ramacher sramac...@debian.org (Bug#755111: fixed in lame 3.99.5+repack1-4)

[Andreas Barth]

Control: reopen -1

* Debian Bug Tracking System (ow...@bugs.debian.org) [140830 21:19]:
[ Alessio Treglia ]
* Build with dh-autoreconf. (Closes: #755111)

According to the build log it still FTBFS on ppc64el. I will check
what the reason is.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755111: closed by Sebastian Ramacher sramac...@debian.org (Bug#755111: fixed in lame 3.99.5+repack1-4)

[Andreas Barth]

Source: lame

   
Source-Version: 3.99.5+repack1-4

   

* Andreas Barth (a...@ayous.org) [140830 23:20]:
 Control: reopen -1
 
 * Debian Bug Tracking System (ow...@bugs.debian.org) [140830 21:19]:
 [ Alessio Treglia ]
 * Build with dh-autoreconf. (Closes: #755111)
 
 According to the build log it still FTBFS on ppc64el. I will check
 what the reason is.

I was confused, it actually works.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755830: opencore-amr: please use dh-autoreconf (fixes ftbfs on ppc64el)

[Andreas Barth]

* Fernando Seiti Furusato (ferse...@br.ibm.com) [140830 21:30]:
 The package opencore-amr fails to build from source on ppc64el.
 Adding the usage of dh-autoreconf to the build fixes that and the
 packages builds successfully.

I'd be willing to help fixing this bug by uploading an NMU. Actually
as about 50 other packages depend on this one being fixed I'd do so in
the next days unless there is a reason why not.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732286: closed by Nicolas Boullis nboul...@debian.org (Bug#732286: fixed in libcdio 0.92-1)

[Andreas Barth]

Hi,

* Debian Bug Tracking System (ow...@bugs.debian.org) [140830 21:28]:
 #732286: libcdio: use dh-autoreconf instead of autotools-dev for better 
 new-port coverage

thanks, could we get a fix of this bug also in unstable, or would it
help if I upload an NMU? (This package is relevant to get about 50
packages built, so if there is no reason why not I would upload an NMU
in a couple of days).


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748131: pstoedit: Fix a FTBFS in new architectures

[Andreas Barth]

* Breno Leitao (bren...@br.ibm.com) [140830 21:32]:
 pstoedit is failing to build on new architectures due to not autoreconfiging
 before the build.  The recommend way to solve it is using dh-autoreconf
 scripts[1]. I just created a patch that fixes this problem. Find it attached 
 to
 this bug.

I'd be willing to help fixing this bug by uploading an NMU. Actually,
about 40 other packages depend on this package being fixed, so I would
do so in the next days unless there is a reason why not.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752462: ilmbase: use dh-autoreconf instead of autotools_dev to fix ftbfs on new archs

[Andreas Barth]

* Fernando Seiti Furusato (ferse...@br.ibm.com) [140829 08:06]:
 The package ilmbase fails to build from source on ppc64el.
 Although autotools-dev is being used, it is not enough to update configuration
 files properly.

I'd be willing to fix this bug by upload an NMU (this package is
required to get some other packages built, among them kde4libs which
is basis for a whole bunch of other packages).

I.e. unless there is a reason why not, I'd upload the package tonight.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757585: closed by m...@debian.org (Manuel A. Fernandez Montecelo) (Bug#757585: fixed in smpeg 0.4.5+cvs20030824-6)

[Andreas Barth]

Control: reopen -1

* Use dh-autoreconf during build to update for new architectures
  (Closes: #757585)

Unfortunatly this bug still exists on ppc64el, which seems to indicate
that also libtool needs refreshing (or autoreconf didn't work):
| dh_install --fail-missing -Xlibsmpeg.la
| dh_install: libsmpeg0 missing files (usr/lib/*/libsmpeg-0.4.so.0*), aborting
| make[1]: *** [override_dh_install] Error 255


See
https://buildd.debian.org/status/fetch.php?pkg=smpegarch=ppc64elver=0.4.5%2Bcvs20030824-7stamp=1409171354
for details.


As this is blocking the build of sdl-mixer1.2 I'll try to find and if
necessary upload a fix ASAP.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727510: blocking the ppc64el architecture bootstrap

[Andreas Barth]

* László Böszörményi (GCS) (g...@debian.org) [140829 00:28]:
 On Thu, Aug 28, 2014 at 11:25 PM, Andreas Barth a...@ayous.org wrote:
  * Aurelien Jarno (aure...@debian.org) [140828 21:22]:
  The ppc64el architecture has been added to the Debian archive. Your
  package sqlite fails to build as reported in bug #727510 and
  the build log is available on [1].
 
  I'd be willing to fix this bug by upload an NMU (this package is
  required to get qt4-x11 built, and via that e.g. sane-backends or
  kde4libs).

  I'm not 100% sure it's related to aclocal.m4 not updated, but I'm
 going to upload a fix for that.

Thanks, it worked.


Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759719: openexr FTBFS on ppc64el - NMU pending

[Andreas Barth]

Package: openexr
Version: 1.6.1-7
Severity: important


Hi,

this package FTBFS on ppc64el:

| test -z /usr/lib/powerpc64le-linux-gnu/pkgconfig || mkdir -p -- 
/«PKGBUILDDIR»/debian/tmp/usr/lib/powerpc64le-linux-gnu/pkgconfig
|  /usr/bin/install -c -m 644 'OpenEXR.pc' 
'/«PKGBUILDDIR»/debian/tmp/usr/lib/powerpc64le-linux-gnu/pkgconfig/OpenEXR.pc'
| make[4]: Leaving directory '/«PKGBUILDDIR»'
| make[3]: Leaving directory '/«PKGBUILDDIR»'
| make[2]: Leaving directory '/«PKGBUILDDIR»'
| find debian/tmp/usr/lib -name *.la -exec \
| sed -i -e s,^dependency_libs=.*,dependency_libs='', {} +
| make[1]: Leaving directory '/«PKGBUILDDIR»'
|dh_install -a
| dh_install: libopenexr-dev missing files (usr/lib/*/*.so), aborting
| make: *** [binary-arch] Error 255
| debian/rules:53: recipe for target 'binary-arch' failed

Such kind of errors are usually fixed by refreshing config.* by
dh-autoreconf.

As openexr is required to build kde4libs (which is blocker for a bunch
of other packages) I intend to upload a fix for this issue tomorrow
evening unless there is a reason why not.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759739: autoreconf - doesn't recognize AM_PROG_LIBTOOL and makes packages FTBFS on ppc64el

[Andreas Barth]

Package: autoconf
Version: 2.69-7
Severity: important

Hi,

during the getting the main packages ready-campaign for ppc64el I
noticed that dh-autoreconf doesn't work if a package uses
AM_PROG_LIBTOOL but works with AC_PROG_LIBTOOL though both makros
should behave the same (and are both deprecated) according to
http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
A sample package for this is version 0.4.5+cvs20030824-7 of smpeg (I
will upload an NMU now for that package, because it prevents the build
of kde4libs).

The following patch changes this behaviour, and would save quite many
sourceful uploads, so I'd ask you to check the fix and if applicable
upload it soon. That would really be a great help for this / all
future ports of Debian (though of course packages should be fixed to
not use deprecated macros, but that's something else).

Severity set to important because it has some impact on upbringing of
the new architectures, but of course please feel free to change it as
appropriate.


Thanks,
Andi

--- autoconf-2.69~/bin/autoreconf.in2012-04-24 22:00:28.0 +
+++ autoconf-2.69/bin/autoreconf.in 2014-08-29 20:03:37.979437002 +
@@ -472,6 +472,7 @@
 'AC_CONFIG_SUBDIRS',
 'AC_INIT',
 'AC_PROG_LIBTOOL',
+'AM_PROG_LIBTOOL',
 'LT_INIT',
 'LT_CONFIG_LTDL_DIR',
 'AM_GNU_GETTEXT',
@@ -486,6 +487,7 @@
   $uses_autoconf = 1if $macro eq AC_INIT;
   $uses_gettext_via_traces = 1  if $macro eq AM_GNU_GETTEXT;
   $uses_libtool = 1 if $macro eq AC_PROG_LIBTOOL
+   || $macro eq AM_PROG_LIBTOOL
|| $macro eq LT_INIT;
   $uses_libltdl = 1 if $macro eq LT_CONFIG_LTDL_DIR;
   $uses_autoheader = 1  if $macro eq AC_CONFIG_HEADERS;
diff -ur autoconf-2.69~/lib/autom4te.in autoconf-2.69/lib/autom4te.in
--- autoconf-2.69~/lib/autom4te.in  2012-01-21 13:46:39.0 +
+++ autoconf-2.69/lib/autom4te.in   2014-08-29 20:04:05.891437001 +
@@ -93,6 +93,7 @@
 args: --preselect AC_CONFIG_SUBDIRS
 args: --preselect AC_INIT
 args: --preselect AC_PROG_LIBTOOL
+args: --preselect AM_PROG_LIBTOOL
 args: --preselect LT_INIT
 args: --preselect LT_CONFIG_LTDL_DIR
 args: --preselect AM_GNU_GETTEXT


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757585: missing libtool-update on smpeg

[Andreas Barth]

Hi,


* Andreas Barth (a...@ayous.org) [140829 19:06]:
 Control: reopen -1
 
 * Use dh-autoreconf during build to update for new architectures
   (Closes: #757585)
 
 Unfortunatly this bug still exists on ppc64el, which seems to indicate
 that also libtool needs refreshing (or autoreconf didn't work):
 | dh_install --fail-missing -Xlibsmpeg.la
 | dh_install: libsmpeg0 missing files (usr/lib/*/libsmpeg-0.4.so.0*), aborting
 | make[1]: *** [override_dh_install] Error 255
 
 
 See
 https://buildd.debian.org/status/fetch.php?pkg=smpegarch=ppc64elver=0.4.5%2Bcvs20030824-7stamp=1409171354
 for details.
 
 
 As this is blocking the build of sdl-mixer1.2 I'll try to find and if
 necessary upload a fix ASAP.


with some more investigation, the required changes are:

- Replace AM_PROG_LIBTOOL by AC_PROG_LIBTOOL in configure.in (so that
  autoreconf also calls libtool)
- Remove everything from acinclude.m4 except the entry for socklen_t
  (the last one).


For the second change, I'd prefer some review (the package builts fine,
but I'm not sure that this is enough).


Andi
--- smpeg-0.4.5+cvs20030824.orig/acinclude.m4
+++ smpeg-0.4.5+cvs20030824/acinclude.m4
@@ -1,605 +1,3 @@
-# Configure paths for SDL
-# Sam Lantinga 9/21/99
-# stolen from Manish Singh
-# stolen back from Frank Belew
-# stolen from Manish Singh
-# Shamelessly stolen from Owen Taylor
-
-dnl AM_PATH_SDL([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
-dnl Test for SDL, and define SDL_CFLAGS and SDL_LIBS
-dnl
-AC_DEFUN(AM_PATH_SDL,
-[dnl 
-dnl Get the cflags and libraries from the sdl-config script
-dnl
-AC_ARG_WITH(sdl-prefix,[  --with-sdl-prefix=PFX   Prefix where SDL is installed (optional)],
-sdl_prefix=$withval, sdl_prefix=)
-AC_ARG_WITH(sdl-exec-prefix,[  --with-sdl-exec-prefix=PFX Exec prefix where SDL is installed (optional)],
-sdl_exec_prefix=$withval, sdl_exec_prefix=)
-AC_ARG_ENABLE(sdltest, [  --disable-sdltest   Do not try to compile and run a test SDL program],
-		, enable_sdltest=yes)
-
-  if test x$sdl_exec_prefix != x ; then
- sdl_args=$sdl_args --exec-prefix=$sdl_exec_prefix
- if test x${SDL_CONFIG+set} != xset ; then
-SDL_CONFIG=$sdl_exec_prefix/bin/sdl-config
- fi
-  fi
-  if test x$sdl_prefix != x ; then
- sdl_args=$sdl_args --prefix=$sdl_prefix
- if test x${SDL_CONFIG+set} != xset ; then
-SDL_CONFIG=$sdl_prefix/bin/sdl-config
- fi
-  fi
-
-  AC_PATH_PROG(SDL_CONFIG, sdl-config, no)
-  min_sdl_version=ifelse([$1], ,0.11.0,$1)
-  AC_MSG_CHECKING(for SDL - version = $min_sdl_version)
-  no_sdl=
-  if test $SDL_CONFIG = no ; then
-no_sdl=yes
-  else
-SDL_CFLAGS=`$SDL_CONFIG $sdlconf_args --cflags`
-SDL_LIBS=`$SDL_CONFIG $sdlconf_args --libs`
-
-sdl_major_version=`$SDL_CONFIG $sdl_args --version | \
-   sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'`
-sdl_minor_version=`$SDL_CONFIG $sdl_args --version | \
-   sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/'`
-sdl_micro_version=`$SDL_CONFIG $sdl_config_args --version | \
-   sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\3/'`
-if test x$enable_sdltest = xyes ; then
-  ac_save_CFLAGS=$CFLAGS
-  ac_save_LIBS=$LIBS
-  CFLAGS=$CFLAGS $SDL_CFLAGS
-  LIBS=$LIBS $SDL_LIBS
-dnl
-dnl Now check if the installed SDL is sufficiently new. (Also sanity
-dnl checks the results of sdl-config to some extent
-dnl
-  rm -f conf.sdltest
-  AC_TRY_RUN([
-#include stdio.h
-#include stdlib.h
-#include string.h
-#include SDL.h
-
-char*
-my_strdup (char *str)
-{
-  char *new_str;
-  
-  if (str)
-{
-  new_str = (char *)malloc ((strlen (str) + 1) * sizeof(char));
-  strcpy (new_str, str);
-}
-  else
-new_str = NULL;
-  
-  return new_str;
-}
-
-int main (int argc, char *argv[])
-{
-  int major, minor, micro;
-  char *tmp_version;
-
-  /* This hangs on some systems (?)
-  system (touch conf.sdltest);
-  */
-  { FILE *fp = fopen(conf.sdltest, a); if ( fp ) fclose(fp); }
-
-  /* HP/UX 9 (%@#!) writes to sscanf strings */
-  tmp_version = my_strdup($min_sdl_version);
-  if (sscanf(tmp_version, %d.%d.%d, major, minor, micro) != 3) {
- printf(%s, bad version string\n, $min_sdl_version);
- exit(1);
-   }
-
-   if (($sdl_major_version  major) ||
-  (($sdl_major_version == major)  ($sdl_minor_version  minor)) ||
-  (($sdl_major_version == major)  ($sdl_minor_version == minor)  ($sdl_micro_version = micro)))
-{
-  return 0;
-}
-  else
-{
-  printf(\n*** 'sdl-config --version' returned %d.%d.%d, but the minimum version\n, $sdl_major_version, $sdl_minor_version, $sdl_micro_version);
-  printf(*** of SDL required is %d.%d.%d. If sdl-config is correct, then it is\n, major, minor, micro);
-  printf(*** best to upgrade to the required version.\n);
-  printf(*** If sdl-config was wrong, set the environment variable SDL_CONFIG\n);
-  printf(*** to point to the correct copy of sdl-config

Bug#757585: missing libtool-update on smpeg

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [140829 23:55]:
 - Remove everything from acinclude.m4 except the entry for socklen_t
   (the last one).

According to changelog that change was already done by Branden
Robinson in 2001, and confirmed by Felix Geyer in 2011.

For that reason I tend to commit that change again on Sunday evening
unless I get review otherwise.



Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org