Re: mpich C++ transition status

2005-10-12 Thread Steve Langasek
On Wed, Oct 12, 2005 at 01:44:22AM -0700, Steve Langasek wrote:

> > >> scalapack failed on powerpc with:

> > >> /usr/bin/ld: 
> > >> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> > >>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> > >> /usr/bin/ld: final link failed: Nonrepresentable section on output

> > >> Does this ring a bell with anyone?  That looks like a gcc issue, not a
> > >> problem with the package.  It's also in dep-wait on arm waiting for
> > >> libf2c2.

> > I've now seen this problem elsewhere, and it's a problem with binutils on
> > powerpc.  krb5 appears to also be affected.  See Bug#329686 for more
> > details.  Rebuilding the affected library from source should fix the
> > problem.

> > I'm not sure the right approach to take here.  A new libf2c2 build on
> > powerpc with the current binutils will fix the problem; should I file a
> > bug against libf2c2 asking for a new sourceful upload to unstable, or is
> > this the place for a porter binary NMU?  I never entirely understood how
> > those are supposed to work and when they are appropriate.

> I've requested a binNMU of libf2c2 for powerpc; scalapack will be retried
> automatically once the libf2c2 update is in the archive, so this should tell
> us pretty quickly if this fixes the bug.  If so, we can get a binNMU of krb5
> the same way.

And the rebuild of scalapack against the binNMU'ed libf2c2 still fails --
now with the same error as on arm.  So this now falls under bug #332955,
which probably would have fixed the powerpc problem anyway by way of
removing libf2c2 from the equation...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: Please allow dhcp3 to enter testing

2005-10-12 Thread Steve Langasek
On Wed, Oct 12, 2005 at 10:07:10PM +1000, Andrew Pollock wrote:

> Can you please allow dhcp3 to enter testing?

Hinted in.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Fwd: news

2005-10-12 Thread Dwight Dyer
Breaking news alert issue - big news coming.

Allixon International Corporation
A X C P . P K

We give it to you again as a gift. This company is doing
incredible things. They have cash and have made great 
strategic aquisitions. Current price is $4.70. 
Short term projection is $8. This company has dropped 
big new's in the past. Who's to say they don't have 
another big one.


Lead me not into temptation; I can find the way myself.  
For certain people after fifty, litigation takes the place of sex.  
So, rather than appear foolish afterward, I renounce seeming clever now.  
People find life entirely too time-consuming.   
As for me, all I know is that I know nothing.  
Human history becomes more and more a race between education and catastrophe. 
Voting for the right is doing nothing for it.
When the water reaches the upper level, follow the rats.   
Patience is the key to content.   
The good man is the friend of all living things.   
The advantage of the emotions is that they lead us astray.  
All paid jobs absorb and degrade the mind. 

Art can't hurt you. 
Things are seldom what they seem, skim milk masquerades as cream.  
I'm a controversial figure: my friends either dislike me or hate me. 
A bully is not reasonable - he is persuaded only by threats. 
To err is human, to blame the next guy even more so. 
[Television is] the triumph of machine over people. 
Be modest! It is the kind of pride least likely to offend. 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: first pass at KDE/JACK hint, openssl disaster, etc.

2005-10-12 Thread Luk Claes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Kurt

Kurt Roeckx wrote:
> On Wed, Oct 12, 2005 at 04:38:29AM -0400, Nathanael Nerode wrote:
> 
>>DO NOT upload packages built against libssl-dev or libssl0.9.8.
>>All packages should be built against libssl0.9.7-dev (libssl0.9.7) at this 
>>time.
> 
> 
> I intend to drop the libssl0.9.7-dev package in the next upload,
> which I hope to do soon.  I don't think it's a good idea to keep
> that -dev package around.  Unless the release team ask me to keep
> it around, I'll remove it.

I would be very surprised if the release team would ask you to keep it
around (due to conversations on IRC).

Cheers

Luk
- --
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDTUti5UTeB5t8Mo0RAgdTAKC5kCcXoLz2ua/n7svUYRsKxLrJwwCgmIBN
Pohej6Qj3nr6pm+BLiJnjUg=
=6cWY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: first pass at KDE/JACK hint, openssl disaster, etc.

2005-10-12 Thread Kurt Roeckx
On Wed, Oct 12, 2005 at 04:38:29AM -0400, Nathanael Nerode wrote:
> DO NOT upload packages built against libssl-dev or libssl0.9.8.
> All packages should be built against libssl0.9.7-dev (libssl0.9.7) at this 
> time.

I intend to drop the libssl0.9.7-dev package in the next upload,
which I hope to do soon.  I don't think it's a good idea to keep
that -dev package around.  Unless the release team ask me to keep
it around, I'll remove it.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: first pass at KDE/JACK hint, openssl disaster, etc.

2005-10-12 Thread Adeodato Simó
* Russ Allbery [Wed, 12 Oct 2005 02:10:06 -0700]:

> Nathanael Nerode <[EMAIL PROTECTED]> writes:

> > And openssh-krb5 needs to be rebuilt for the same reason (kdeutils
> > depends on it).

> Huh?  Where are you seeing that?  That makes no sense and absolutely
> should not be the case.  Are you sure you're not just seeing output
> picking up one of multiple possible sources for the ssh pseudopackage?

  He is. kdessh Depends: openssh-client | ssh-client

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny..."
-- Isaac Asimov


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: clarifications on bjorn.haxx.se (continued)

2005-10-12 Thread Frank Lichtenheld
On Wed, Oct 12, 2005 at 04:45:45PM +0200, Luk Claes wrote:
> Thanks for adding them. Is it ok to keep sending mails about these?

Sure. You can also /msg them to me on IRC which is maybe faster and
certainly less stuff in the list archive which is only of minor
interest...

> Another one:
> 
> easy sylpheed-claws/1.0.5-1 sylpheed-claws-ghostscript-viewer/0.8-7
> sylpheed-claws-maildir-plugin/0.7-5

Added.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: clarifications on bjorn.haxx.se (continued)

2005-10-12 Thread Luk Claes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luk Claes wrote:
> Steve Langasek wrote:
> 
>>>On Thu, Oct 06, 2005 at 04:41:00PM +0200, Luk Claes wrote:
>>>
Luk Claes wrote:

>Frank Lichtenheld wrote:
>
>>>On Wed, Oct 05, 2005 at 04:49:53PM +0200, Luk Claes wrote:
> 
> [...]
> 
> Further investigations lead me to this new cases:
[...]
> easy geda-gattrib/20050820-1 geda-gnetlist/20050820-1
> geda-gschem/20050520-1 geda-gsymcheck/20050520-1 geda-utils/20050820-1
> libgeda/20050820-1

Damn typos, I need a numerical keyboard extension for my laptop :-)

Thanks for adding them. Is it ok to keep sending mails about these?

Another one:

easy sylpheed-claws/1.0.5-1 sylpheed-claws-ghostscript-viewer/0.8-7
sylpheed-claws-maildir-plugin/0.7-5

Cheers

Luk

- --
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDTSGZ5UTeB5t8Mo0RAiQoAJ9zWQs0k4bKL96Dx1Gldd0suplQDACgph3S
z/SRlGY0hGQYGnSevE4mGNQ=
=Ri6w
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Please allow dhcp3 to enter testing

2005-10-12 Thread Andrew Pollock
Hi,

Can you please allow dhcp3 to enter testing?

Thanks

Andrew


signature.asc
Description: Digital signature


Re: mpich C++ transition status

2005-10-12 Thread Steffen Moeller
On Wed, Oct 12, 2005 at 02:08:21AM -0700, Steve Langasek wrote:
> On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> > Here is the current status of the mpich/hdf5/lam migration.
> 
> > Only one package still needs an upload:
> 
> > Source: clustalw-mpi (non-free)
> 
> FWIW, clustalw-mpi has now been removed from testing due to the RC bug you
> filed on it previously.  The package can of course get back into testing
> once it's been rebuilt for the transition, but I don't intend to let the
> transition be held up for a single non-free package.

Dear Russ and dear Steve,

I apologise for not having been more reactive. I am preparing an updated
version at the moment and will place it at
http://bioinformatics.pzr.uni-rostock.de/~moeller/clustalw-mpi
since I understood now that it is urgent. I cannot upload the package
myself since I am not accepted as a developer yet.

The package is non-free and hence the uploading of the new version
implies it being rebuild on several platforms. Popcon knows only about a
disappointing 7 installations, some of which are mine, hence I am
considering to ask to remove the package from the distribution.

No novel upstream version of the package is yet available which IMHO would
justify to bother my sponsor about an upload. I do not want to ask my
sponsor to perform regular maintenance.

Version 1.13-3 will be at the prior mentioned location later today.

Kind regards

Steffen MÃller


> 
> >  * pytables needs a build on alpha and rmpi and scalapack need builds on
> >arm.
> 
> pytables is already building on arm (now that there's a python2.3-numarray
> package in the archive which doesn't contain an empty .so).  rmpi and
> scalapack needed to be given back on arm, due to a buildd burp; this has now
> been done.
> 
> >  * octave-gpc needs personal attention to get builds for alpha, ia64, and
> >mips (and m68k) due to being in non-free and having non-free
> >dependencies.
> 
> This will be a candidate for removal from testing if these builds still
> aren't done when the rest of the packages are ready to go in.
> 
> Cheers,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> [EMAIL PROTECTED]   http://www.debian.org/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re[2]: News

2005-10-12 Thread Carrie Carey
Breaking news alert issue - big news coming.

Allixon International Corporation
A X C P . P K

We give it to you again as a gift. This company is doing
incredible things. They have cash and have made great 
strategic aquisitions. Current price is $4.70. 
Short term projection is $8. This company has dropped 
big new's in the past. Who's to say they don't have 
another big one.


Eating without conversation is only stoking.   
Simply pushing harder within the old boundaries will not do.   
Dwelling on the negative simply contributes to its power.
Too many have dispensed with generosity in order to practice charity.  

I don't like principles. I prefer prejudices.  
It's so easy to be wicked without knowing it, isn't it?  
Any fool can criticize, condemn, and complain - and most fools do. 
A cult is a religion with no political power
Men for the sake of getting a living forget to live.  
While you're saving your face you're losing your ass.

It is not enough to aim; you must hit.
I have learned to use the word impossible with the greatest caution. 
If the wind will not serve, take to the oars.   
Delusions of grandeur make me feel a lot better about myself.  
Just trust yourself, then you will know how to live.   
It is not the position, but the disposition. 
Talent develops in tranquillity, character in the full current of human life. 
Imagination is the one weapon in the war against reality.   



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: libsigc++-1.2 hint notes

2005-10-12 Thread Steve Langasek
On Wed, Oct 12, 2005 at 02:44:01AM -0400, Nathanael Nerode wrote:
> I'm trying to get an NMU for glademm uploaded to remove the spurious
> build-dependencies.  After that, I propose that libbonobouimm1.3 and
> libbonobomm1.3 be removed from unstable as they'll be totally unused.  

That would need to be taken up with the ftpmasters and the maintainer.
Unlike other gnome*mm libraries that have been removed from unstable
recently, libbonobouimm1.3 and libbonobomm1.3 are not obsolete -- the
bindings may be useful to some people even if they aren't currently used by
any packages we ship.

> gtkglextmm should be removed from testing (bug #320577).  It has no reverse
> dependencies.  Anyway, the new version won't depend on libsigc++-1.2.

That bug is filed against a version of gtkglextmm that's only present in
unstable, and is not by itself grounds for removing the package from
testing.  gtkglextmm will be removed from testing if necessary to let the
other packages in, but we're not there yet.

> libapt-front needs a new upload to fix its RC bug, and needs to be added
> to the hint (depends on apt, depended on by debtags).

No, it doesn't; this is a new package, not present in testing today and
therefore irrelevant to the hint.

> gtkmm2.0/2.2.12-1.3 needs to be added to the hint; there are still a few
> packages which are not being transitioned away from it at this time, namely
> mysql-admin and mysql-query-browser (both of which are otherwise ready to
> go in).

Added, though I don't know it technically needs to be; britney might have
picked it up on its own, but it doesn't hurt to save a few cycles there if
gtkmm2.0 is going to stay installable.

> sigcperl/0.2.0-3 (producing libsigcperl1c2 binary) needs to be added to the
> hint because sigc (producing the libsigc-perl binary) depends on it.

Also added.

> fireflier and cheesetracker will need to be removed from testing, as both
> depend on KDE as well as on gtkmm2.0.

Again, will be done when we're closer to having a viable hint.  (These
packages are commented in http://ftp-master.debian.org/testing/hints/vorlon,
btw.)

> Similarly, seq24 and freqtweak will need to be removed, as they
> depend on JACK as well as libsigc++-1.2.

Ok, noted.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: mpich C++ transition status

2005-10-12 Thread Russ Allbery
Russ Allbery <[EMAIL PROTECTED]> writes:

> Going through the build problems on that list:

Oh, sorry, and parmetis (non-free) needs a build on mips.  I keep
forgetting that one because it doesn't show up on the buildd report for
some reason, only in the update-excuses output.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: first pass at KDE/JACK hint, openssl disaster, etc.

2005-10-12 Thread Russ Allbery
Nathanael Nerode <[EMAIL PROTECTED]> writes:

> And openssh-krb5 needs to be rebuilt for the same reason (kdeutils
> depends on it).

Huh?  Where are you seeing that?  That makes no sense and absolutely
should not be the case.  Are you sure you're not just seeing output
picking up one of multiple possible sources for the ssh pseudopackage?

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mpich C++ transition status

2005-10-12 Thread Steve Langasek
On Tue, Oct 11, 2005 at 07:22:07PM -0700, Russ Allbery wrote:
> Here is the current status of the mpich/hdf5/lam migration.

> Only one package still needs an upload:

> Source: clustalw-mpi (non-free)

FWIW, clustalw-mpi has now been removed from testing due to the RC bug you
filed on it previously.  The package can of course get back into testing
once it's been rebuilt for the transition, but I don't intend to let the
transition be held up for a single non-free package.

>  * pytables needs a build on alpha and rmpi and scalapack need builds on
>arm.

pytables is already building on arm (now that there's a python2.3-numarray
package in the archive which doesn't contain an empty .so).  rmpi and
scalapack needed to be given back on arm, due to a buildd burp; this has now
been done.

>  * octave-gpc needs personal attention to get builds for alpha, ia64, and
>mips (and m68k) due to being in non-free and having non-free
>dependencies.

This will be a candidate for removal from testing if these builds still
aren't done when the rest of the packages are ready to go in.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: mpich C++ transition status

2005-10-12 Thread Russ Allbery
severity 333462 serious
thanks

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Oct 11, 2005 at 06:55:15PM -0700, Russ Allbery wrote:

>> I've filed a bug against r-base for this.  I'm going to file it at
>> severity: important since I don't want the bug itself to block
>> migration if hppa gets built properly, but if that's not correct and it
>> should be upgraded, please feel free to either do so or ask me to do
>> so.

> This really ought to be severity: serious; the package isn't going to
> get built without someone taking action, so I wouldn't worry about it
> getting fixed without the bug also being cleared.

Sure thing.

A new version of octave2.1 has been uploaded to fix the build dependencies
for m68k, btw.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



[DRAFT] Another update on transition statuses

2005-10-12 Thread Nathanael Nerode
Release team -- please take this, edit it as you see fit, and post it 
to d-d-a if deemed appropriate.  I made some fairly strong recommendations 
regarding the libssl fiasco, but I think they're correct -- and people 
probably ought to be warned about this immediately.

--
We currently still have quite a lot of transitions going on.

*Please don't* upload shlib bumps or lib renamings unless required by one of 
these transitions.  This has not changed since 
http://lists.debian.org/debian-devel-announce/2005/08/msg00014.html,
but some people seem to have forgotten.

Of the transitions listed in Andreas Barth's previous message, glibc 2.3.5, 
X.org, and GNOME 2.10 have entered etch.  Yay!  Since my previous message to 
gcc-release, so have gcc-4.0 and gmp.  Double yay, and congrats to everyone 
involved!

libssl 0.9.8
===
The libssl maintainer went and uploaded a new version.   Its symbols aren't 
versioned yet, and it doesn't have proper Conflicts: with libssl0.9.7, so 
it's likely to cause random breakage on installation if anything gets linked 
to both versions.  We don't want this transition to be happening right now.

We also want to keep this away from the other transitions.  It's already in 
the top 15 stallers.  If libssl0.9.8 gets tied up with the KDE transition, 
people will scream -- and it already is, thanks to openssh-krb5, tellico, and 
php4 (all of which should be reuploaded with built against libssl0.9.7-dev 
ASAP).

Please don't make *any* upload depending on libssl0.9.8.  If your package 
depends on libssl, make it depend on and build against libssl0.9.7, and 
libssl0.9.7-dev.  If your package already depends on libssl0.9.8, please 
upload to *revert* the change, particularly if you want your package to enter 
'testing' in the near future.

To repeat: currently libssl0.9.8 breaks things.  Avoid it.

libpng, imlib, and GNOME 1
==
The removal of libpng10 from the archive has created some unfortunate 
shockwaves.  libpng itself should make it into etch with no trouble in 3
days, so most of its dependencies should not worry.

Packages which link against any GNOME1 core libraries or gdk-imlib1 should 
rebuild with new versioned dependencies.  See the message from the new 
maintainer:
http://lists.debian.org/debian-devel/2005/10/msg00279.html
Since then changes have been made so that you don't *need* to rebuild.  On 
your next upload, however, you will need to fix your build dependencies.

If you were planning to change your package from a GNOME 1 package to a GNOME 
2 package, please just do that instead.  GNOME 2 is already in etch, making 
life a lot easier.

Perl

A lot of things are waiting for a RC-bug-free perl to build on all 
architectures.  No estimate for when that will happen yet, but hopefully 
soon.

The C++ ABI transition
==
This is the main ongoing transition. However, it has several "sub-transitions" 
which have dragged in apparently 
unrelated packages, which are described individually below.

Please see 
http://lists.debian.org/debian-devel-announce/2005/07/msg1.html for 
details about it.  The page at
http://people.debian.org/~mfurr/gxx/ gives some information as to the status 
of particular packages.

If you haven't transitioned your C++-using package, now is most likely the 
time to do so. (The exception is if your package depends on a C++ library 
which has not been transitioned for all architectures yet; this appears to be 
a very short list, but do check before uploading.)

FLTK1.1
===
This is going in in a couple of days, and is only awaiting manual action by 
the release team.
*Warning*:
It's going to involve breaking the openexr binary in testing (but not the 
library), because otherwise it would have to go in at the same time as JACK & 
KDE.

libsigc++-1.2 and APT
==
This is waiting for the removal of obsolete packages and attendant 
cleanup, for a new upload of libapt-front, and for an 
RC-bug-free version of perl which builds everywhere.

Packages which depend on libsigc++-1.2 and are caught up in the KDE/JACK 
transition will be removed from unstable temporarily.

JACK & KDE
===
JACK made a major interface change a while back from libjack0.80.0-0 to 
libjack0.100.0-0.  This change is essentially complete in unstable.  (If your 
package hasn't undergone it, it should do so now, unless it depends on an 
untransitioned C++ library, which I think isn't the case for any such 
package.) Unfortunately, this has gotten caught up in the C++ transition, 
because ARTS depends on JACK, and all of KDE depends on ARTS.

KDE is going from 3.3 to 3.4 in parallel with its C++ ABI transition.  We do 
not yet have an estimate for when transitioned KDE will be ready to enter 
etch.  It will almost certainly be after all of the others listed above 
(except openssl0.9.8, which we are trying to avoid).

If your package is one of the hundreds listed as stalled by 
jack-audio-connection-kit, qt-x11-free, arts,

first pass at KDE/JACK hint, openssl disaster, etc.

2005-10-12 Thread Nathanael Nerode
This is a first pass at working out what needs to go in at once
for KDE to get in.  I think if these are tried together we can
get a more meaningful result from update_output.txt.

These are all roots of fairly substantial dependency trees,
with some additional subtrees which probably need to go in all at once noted.
* jack-audio-connection-kit
* flac
  * libtunepimp
* id3lib3.8.3 (build-dep of flac)
* taglib (for kdemultimedia)
* openexr (for kdelibs, kdebase)
* arts
  * openal
* qt-x11-free
  * qscintilla, python-qt3, sip4-qt3
  * cppunit, gnuradio-core
  * qca
* kdelibs
-- waiting for lm-sensors, which waits for rrdtool, which waits for perl
  * kdesdk, kdevelop3
-- kdesdk waits for subversion, which has RC bugs and waits for way too
   much stuff (perl, andswig1.3 which waits for pike 7.6, which has RC bugs)
-- remove kdesdk, kdevelop3?
  * libkexif
  * kdepim
  * libkipi
  * licq
  * ksimus
  * dbus
-- waiting for monodoc, which waits for nunit, but both should go in
* wireless-tools (for kdenetwork)
-- netapplet needs to be removed or updated
* kdebase
* unixodbc
  * php4 -- built against bad libssl !!
  * gdal, openscenegraph, libgdal-grass
  * freetds
* wv2, imagemagick (for koffice)
-- imagemagick is waiting for perl

Yrgh.  There are of course unbuilt packages, timeouts, and RC bugs
on various of these.

I think we can do some work on the edges:
# ties flac to libmodplug
remove cynthiune.app/0.9.4-2
# ties flac to libmodplug, RC bugs #324978, 332282, 332773
remove vlc/0.8.1.svn20050314-1
# bug #332919
remove xine-lib/1.0.1-1
hint libmodplug/1:0.7-5

This removes one more little tree from the Giant Tangle.

Forcing fltk1.1 in would be a good thing as well.

After those and libsigc++-1.2 and libpng go in, and once perl works,
I'm beginning to think a soft freeze will be desirable (no uploads except
to fix RC bugs or undergo the C++ transition); the vast majority
of other delayed packages are all tied up in this one giant tangle.

---
Finally, one more point.  The openssl 0.9.8 upload was a disaster.

It's vital to get people to rebuild their packages against openssl0.9.7
-- and to kick out of testing packages which are built against new openssl --
because it would be so very wrong to delay KDE for that.

In particular php4 needs to be rebuilt to break the linkage.
(Or kicked out, but that would require kicking out a bunch of other packages.)
Also tellico needs to be kicked or rebuilt for the same reason.
And openssh-krb5 needs to be rebuilt for the same reason (kdeutils depends
on it).

If we don't stop this now, everything depending on openssl will have to
go in at the same time as all of KDE and JACK and flac and unixodbc.

That requires a d-d-a message.  I propose that it say this:
---
DO NOT upload packages built against libssl-dev or libssl0.9.8.
All packages should be built against libssl0.9.7-dev (libssl0.9.7) at this time.
Packages in this list:
http://bjorn.haxx.se/debian/testing.pl?waiting=openssl
have been built against the new openssl and must be rebuilt against the
old one.

The new openssl is not ready for etch and will keep your packages out of it,
possibly for months.  It will probably also cause packages to malfunction at
runtime if they end up linked to both new and old openssl (and there are
no Conflicts: to prevent this at this time).  This was an unauthorized
transition and we are doing our best to stop the bad effects of it.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mpich C++ transition status

2005-10-12 Thread Steve Langasek
On Tue, Oct 11, 2005 at 06:55:15PM -0700, Russ Allbery wrote:
> Following up on the issues from my previous note that still exist.  Sorry
> that I hadn't given this attention sooner; I've been a bit buried
> preparing for vacation.

No worries. :)

> Steve Langasek <[EMAIL PROTECTED]> writes:
> > If the package previously built without trouble on hppa, it tends to
> > suggest the package has gotten itself into an infinite loop of some
> > kind, or else that a new version is substantially slower than previous
> > versions for some unknown reason.  It will almost certainly require
> > coordination between the maintainer and the buildd admin to figure out.

> I've filed a bug against r-base for this.  I'm going to file it at
> severity: important since I don't want the bug itself to block migration
> if hppa gets built properly, but if that's not correct and it should be
> upgraded, please feel free to either do so or ask me to do so.

This really ought to be severity: serious; the package isn't going to get
built without someone taking action, so I wouldn't worry about it getting
fixed without the bug also being cleared.

> >> scalapack failed on powerpc with:

> >> /usr/bin/ld: 
> >> /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc):
> >>  unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
> >> /usr/bin/ld: final link failed: Nonrepresentable section on output

> >> Does this ring a bell with anyone?  That looks like a gcc issue, not a
> >> problem with the package.  It's also in dep-wait on arm waiting for
> >> libf2c2.

> I've now seen this problem elsewhere, and it's a problem with binutils on
> powerpc.  krb5 appears to also be affected.  See Bug#329686 for more
> details.  Rebuilding the affected library from source should fix the
> problem.

> I'm not sure the right approach to take here.  A new libf2c2 build on
> powerpc with the current binutils will fix the problem; should I file a
> bug against libf2c2 asking for a new sourceful upload to unstable, or is
> this the place for a porter binary NMU?  I never entirely understood how
> those are supposed to work and when they are appropriate.

I've requested a binNMU of libf2c2 for powerpc; scalapack will be retried
automatically once the libf2c2 update is in the archive, so this should tell
us pretty quickly if this fixes the bug.  If so, we can get a binNMU of krb5
the same way.

> > The removal will be semi-automatic once plplot has built on m68k, but
> > that won't happen until octave2.1 is also available on m68k.  But
> > octave2.1 build-depends on gfortran, which is not available on m68k --
> > and not because the package hasn't built, because the package source is
> > gcc-defaults.  That looks like someone should file a bug against
> > octave2.1, asking it to build-depend again on fort77 on m68k as previous
> > versions did.

> Bug filed.

Looks good, thanks.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature