Re: Packages-arch-specific (was: Sparc build failure analysis)

[Peter Samuelson]

[Russ Allbery]
> Maybe the right thing to do would be to work out a way for package
> maintainers to provide input to their own P-a-s entries in some sort
> of automated fashion?  It does seem like a package maintainer is
> generally going to know this sort of thing

Could be done, but my understanding is that they explicitly *don't*
trust maintainers.  In other words, p-a-s is separate from the
debian/control Architecture lines for the same reason the ftpmasters'
override file is separate from the debian/control Section and Priority
lines.  Because the buildd admins, and ftpmasters, *want* to maintain
this information manually.

I could be wrong.


signature.asc
Description: Digital signature

Re: Bug#342959: Package explicitely build-depends on g++-3.4

[Steve M. Robbins]

Howdy,

On Mon, Dec 12, 2005 at 02:18:29AM +0100, Matthias Klose wrote:

> We will get rid of g++-3.3 for the etch release and remove the
> g++-3.3 package.

On Mon, Dec 12, 2005 at 12:54:22AM +0100, Matthias Klose wrote:

> We would like to get rid of g++-3.4 for the etch release, although
> currently not a hard release goal.
 

I completely missed the discussion surrounding removal of gcc 3.3 and
gcc 3.4.


For the record, ccmalloc builds a stub library for each C++ compiler
shipped.  So the build-dependency can be easily removed as soon as the
compiler is removed.

Cheers,
-Steve


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

Re: Complaint about #debian operator

[Erinn Clark]

* Erinn Clark <[EMAIL PROTECTED]> [2005:12:11 19:43 -0500]: 
[...]

Oops, this was meant for -project. Apologies for the noise.

-- 
off the chain like a rebellious guanine nucleotide


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

Re: Complaint about #debian operator

[Erinn Clark]

* Paul Johnson <[EMAIL PROTECTED]> [2005:12:11 16:32 -0800]: 
> On Saturday 10 December 2005 12:07 pm, Josh Rehman wrote:
> 
> > As for being warned, I was told that because my discussion was about
> > ubuntu I should stop. Because I felt my discussion was not about
> > ubuntu, I did not feel that I should have to stop.
> 
> So you deliberately show newbie arrogance, get called on it, then complain?  
> Dude, you got what you deserved, now you're just embarrassing yourself with 
> how much you and most 13 year olds on AOL have in common.

Paul,

While it was kind of you to take time out of your busy schedule to
berate Josh (I mean, I know -user needs a lot of attention from you...)
could you please drop it?

And FYI everyone else: Paul is not, to my knowledge, a regular in
#debian, lest you be afraid this kind of behavior is tolerated in there.
:)

-- 
off the chain like a rebellious guanine nucleotide


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

Re: Solving recursive dependency disease in KDE-based packages

[Henrique de Moraes Holschuh]

On Sun, 11 Dec 2005, Nathanael Nerode wrote:
> Regenerating acinclude.m4, aclocal.m4, configure.in, and finally configure,
> can be a pain in the neck.  In some packages, it's done by

autoreconf ?

> In my experience the redefinition of AC_FOREACH sometimes fights with the

Any such redefinitions are a STUPID idea to begin with. Watch as that blows
on KDE's face when upstream auto* changes something...

>   Replace stuff like $(LIBFOO) with -lfoo, and get rid of stuff like

Is not this used to find the correct libfoo in the configure script?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: apt PARALLELISM

[Henrique de Moraes Holschuh]

On Sun, 11 Dec 2005, Marco d'Itri wrote:
> On Dec 11, Charles Fry <[EMAIL PROTECTED]> wrote:
> > But if multiple URLs could satisfactorily serve requests for a single
> > repository, only one of them is currently used.
> Which is fine, because we do not want people to open multiple
> connections to the same server.

We don't want them to open multiple connections even to MULTIPLE servers...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Intel notebooks for needy developers in developing countries

[John Hasler]

Daniel writes:
> Why should it be illegal to re-sell or outreach a piece of US hardware,
> which is already imported into a free country, into another free country?

It would be illegal for Intel to send the hardware to someone it knows is
going to send it somewhere that it would be illegal for Intel to send it
directly.  Otherwise the controls would be even more pointless.

> However, it's not imported yet for breaking onces head about it anyway.

We don't even know that the subject hardware would be subject to export
controls.  There's really no reason for us to concern ourselves about it.

BTW the US is not the only country with such laws.
-- 
John Hasler


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> Then you're not maintaining your packages properly, and you're making
> life more difficult for the rest of the project out of spite.

Notice that in disagreeing with your statement, I have also gone out
of my way to answer the specific questions you asked.

Now, can we expect you to adopt the same policy yourself, and to
expect others in the project, especially those with
single-point-of-failure responsibilities, to do the same?

I have asked this about four times now, and you have neglected to
answer.  I can only guess that the question embarasses you.  But
still, I think you owe an answer.


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns  writes:
>> >   (a) seeing if the FTBFS can be fixed immediately, and finding it can't
>> >   (b) documenting (this is the transparent bit, so pay attention) that
>> >   fact by not having s390 incorrectly listed as a supported arch in
>> >   the source and ensuring it does not incorrectly indicate a known
>> >   broken build is successful as it did in the past
>> >   (c) informing ftpmaster that the build currently in the archive is
>> >   broken by filing a bug requesting the broken build be removed
>> >   (you know, communicating with people)
>> >   (d) downgrading the bug so that it is not incorrectly listed as
>> >   a RC issue that the RM and QA teams have to attend to
>> >   (e) as maintainer, work with upstream and porters to fix the
>> >   downgraded but still open bug we were just talking about
>> I disagree with this.  
>
> Then you're not maintaining your packages properly, and you're making
> life more difficult for the rest of the project out of spite.

You are incorrect.  I disagree with your approach to fixing this
particular problem.  I think it is better to keep the package out of
testing until the problem is resolved one way or the other.

You have failed to detail any particular difficulty that this causes,
nor have you given any reason why the package should be added to
testing in advance of my judgment that it's ready, nor have you given
any explanation of why you think it's ready now.

You have not pointed at any documentation of maintainer policies that
indicates that one must clear an RC bug as soon as possible, for
unreleased packages, to push them into testing before the maintainer
thinks they are ready.

By contrast, your strategy of "maintaining" packages which you simply
ignore, is a direct violation of the standards of the Project.

Thomas


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

Re: Intel notebooks for needy developers in developing countries

[Benjamin Seidenberg]

Daniel Baumann wrote:


Lars Wirzenius wrote:
 


I don't like those laws, but publically urging people to violate them
isn't going to do anyone any good.
   



Hu? Why should it be illegal to re-sell or outreach a piece of US
hardware, which is already imported into a free country, into another
free country?

However, it's not imported yet for breaking onces head about it anyway.

Regards,
Daniel

 

I would assume that it'd be illegal for the US company to export it to 
someone with the knowledge that that person/group/company intends to 
re-export it to an embargoed nation.


signature.asc
Description: OpenPGP digital signature

Re: cdbs borked by new version of make

[Eric Dorland]

* Ken Bloom ([EMAIL PROTECTED]) wrote:
> I just noticed bug #342892 (Incompatible with make 3.80+3.81.b3-1) on
> cdbs, and thought I should bring it to more people's attention that the
> new version of make has broken CDBS, and may potentially break your
> package. Everyone who has CDBS packages should try rebuilding them, and
> if you can patch the brokenness, submit the patch to bug 342892.

Phew. Thanks for dropping this note. The package I was working on
suddenly stopped building yesterday and I'd thought I'd lost my mind. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Intel notebooks for needy developers in developing countries

[Daniel Baumann]

Lars Wirzenius wrote:
> I don't like those laws, but publically urging people to violate them
> isn't going to do anyone any good.

Hu? Why should it be illegal to re-sell or outreach a piece of US
hardware, which is already imported into a free country, into another
free country?

However, it's not imported yet for breaking onces head about it anyway.

Regards,
Daniel

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: apt PARALLELISM

[Marco d'Itri]

On Dec 11, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> True, but that's not what's being asked here. If multiple URLs could
> serve requests for a single repository---i.e., if you've got both 
> deb http://ftp1.CC.debian.org/debian unstable main
> and
> deb http://ftp2.CC.debian.org/debian unstable main
> in your sources.list, then apt will download everything from
> ftp1.CC.debian.org (bar those files it gets an error on at that server;
> in that case, it will download them from the second server).
It's not clear which problem this would solve.
If a single mirror cannot saturate the network link then maybe a
different mirror should be used.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#342951: ITP: qliss3d -- demonstration tool for Lissajous physiques

[Steffen Joeris]

Package: wnpp
Severity: wishlist
Owner: Steffen Joeris <[EMAIL PROTECTED]>

* Package name: qliss3d
  Version : 1.3.2
  Upstream Author : Daniel Gruen <[EMAIL PROTECTED]>
* URL :
* http://www.schule-bw.de/service/foerderprog/ccteam/projekte/qliss3d_html
* License : GPL
  Description : demonstration tool for Lissajous physiques

 Qliss3d is a tool that generates various Lissajous physiques. It is
 possible to rotate the figures and zoom into them. Also changing the
 frequency and replay of the sinus sounds by the same frequency rate
 are implemented.
 .
 Homepage:
 http://www.schule-bw.de/service/foerderprog/ccteam/projekte/qliss3d_html


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

Re: StrongARM tactics

[Wouter Verhelst]

On Fri, Dec 09, 2005 at 04:17:28PM +0100, Goswin von Brederlow wrote:
> I fail to see how downloading the source, extracting the source,
> downloading and installing all Build-Depends, seeing there is nothing
> to do and cleaning it all up again is doing anything but waste
> valuable time. (Or does sbuild fail before the Build-Depends?

Yes. A typical output is something like:

Automatic build of _ on  by sbuild/ 
Build started at -
**
Checking available source versions...
Fetching source files...
Reading Package Lists...
Building Dependency Tree...
Need to get 192kB of source archives.
Get:1 http://incoming.debian.org(dsc) [586B]
Get:2 http://incoming.debian.org(tar) [154kB]
Get:3 http://incoming.debian.org(diff) [37.8kB]
: not in architecture list: i386 -- skipping
**
Finished at -
Build needed 00:00:00, 0k disk space

for a package that has Architecture: i386

That's still a bit of time wasted, but it's not really bad. The really
problematic version is when a package is downloaded, build-deps are
installed, and /then/ sbuild figures out that some version isn't recent
enough.

> Scratch those then.)

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: apt PARALLELISM

[Wouter Verhelst]

On Sun, Dec 11, 2005 at 02:45:50AM +0100, Marco d'Itri wrote:
> On Dec 11, Charles Fry <[EMAIL PROTECTED]> wrote:
> 
> > But if multiple URLs could satisfactorily serve requests for a single
> > repository, only one of them is currently used.
> Which is fine, because we do not want people to open multiple
> connections to the same server.

True, but that's not what's being asked here. If multiple URLs could
serve requests for a single repository---i.e., if you've got both 
deb http://ftp1.CC.debian.org/debian unstable main
and
deb http://ftp2.CC.debian.org/debian unstable main
in your sources.list, then apt will download everything from
ftp1.CC.debian.org (bar those files it gets an error on at that server;
in that case, it will download them from the second server).

Which is, indeed, silly.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
> * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]:
> 
> >   To work out which libraries you're linked to which you don't actually 
need,
> >   ldd -u  is invaluable.
> 
>   This seems like not the case _at all_ to me (the "invaluable" bit):

Yes, it definitely gives lots of false positives.  I haven't seen it give a 
false negative yet though, which makes it a reasonable starting point.

>For now, I
>  plan on sticking to Henning Makholm's "libneeded" lintian check:
Great if you've got it working; I hadn't.


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

Re: question towards "freetype transition; improved library handlingneeded for all C/C++ packages"

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
> I believe my package is affected by the issues stated by Steve,
> depending on libraries which I do not directly use. Most of them are
> probably pulled in through the QT library I am depending on. My package,
> packagesearch, uses qmake as a build tool. The linking command line
> contains loads of other libraries including freetype (collected by
> qmake).

The long-term solution is to fix qmake.  Maybe I'll give it a poke.


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

Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)

[Darren Salt]

I demand that Adeodato Simó may or may not have written...

> * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]:
>> To work out which libraries you're linked to which you don't actually
>> need, ldd -u  is invaluable.

> This seems like not the case _at all_ to me (the "invaluable" bit):

> % ldd -u /usr/lib/amarok/amarokapp
> Unused direct dependencies:
[snip; list contains some libs which _are_ directly used by the binary]

> If this has an explanation (other than bogus ones like "some other
> dependency links against libpq.so.4", which I don't think it's the case,
> but mentioning as an example), please be my guest.

. Doing that for gxine causes libxine and libsmjs (for example) to be
listed, and I don't see anything else which gxine requires which uses them.

> For now, I plan on sticking to Henning Makholm's "libneeded" lintian check:
[snip]

A link would have been nice, although this happens to be trivially findable.
For the record, it's the subject of http://bugs.debian.org/340934>.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

2*1=2. 2/1=2. Therefore, * and / are the same operation.


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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

[Ingo Juergensmann]

On Sun, Dec 11, 2005 at 05:30:24AM -0500, Kevin Mark wrote:

> has anyone every considered a check in the buildd infrastructure to
> alert someone (buildd admin and/or others) if a build is taking too long
> (eg openoffice usually takes between 2-3 hours to build and the current
> build has been building for 10 hours+). Something like a database entry
> or a database of either previous build times or last build time. As a
> way to not have a buildd tied up with an obvious build issue and thus
> allow the issue to be address sooner thus alowing more buildd
> throughput.

You mean something like the stats on http://www.buildd.net/ - for example:
http://buildd.net/cgi/ptracker.cgi?unstable_pkg=aptitude&searchtype=m68k

I intend to give some sort of "build is overdue" warning when I have enough
data to calculate on when a build is overdue ;)

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


signature.asc
Description: Digital signature

Re: question towards "freetype transition; improved library handling needed for all C/C++ packages"

[Darren Salt]

I demand that Benjamin Mesing may or may not have written...

[snip; extra libraries included as parameters at link time]
> I believe my package is affected by the issues stated by Steve, depending
> on libraries which I do not directly use. Most of them are probably pulled
> in through the QT library I am depending on. [...]

> In this scenario how should I proceed? Steve's hints seem to apply mostly
> to library packages, and due to using qmake are not applicable for me
> anyways. Should I go with his last hint to use -Wl,--as-needed?

I'd say so. gxine uses this where supported in order to avoid unnecessary
direct linkage against libatk etc. (pulled in through libgtk2.0-dev's
pkgconfig file), although since I added this after 0.4.8, the current
official .debs have those unnecessary dependencies.

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Retrocomputing: a PC card in a Risc PC

"What? This isn't the Files section?"


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

cdbs borked by new version of make

[Ken Bloom]

I just noticed bug #342892 (Incompatible with make 3.80+3.81.b3-1) on
cdbs, and thought I should bring it to more people's attention that the
new version of make has broken CDBS, and may potentially break your
package. Everyone who has CDBS packages should try rebuilding them, and
if you can patch the brokenness, submit the patch to bug 342892.

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


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

Bug#342907: ITP: libmodule-corelist-perl -- what modules shipped with versions of perl

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libmodule-corelist-perl
  Version : 2.02
  Upstream Author : Richard Clamp <[EMAIL PROTECTED]>
perl 5 porters 
* URL : http://search.cpan.org/~rgarcia/Module-CoreList-2.02/
* License : Perl: Artistic/GPL
  Description : what modules shipped with versions of perl

 Module::CoreList contains the hash of hashes
 %Module::CoreList::version, this is keyed on perl version as indicated
 in $].  The second level hash is module => version pairs.
 .
 Note, it is possible for the version of a module to be unspecified,
 whereby the value is undef, so use exists $version{$foo}{$bar} if
 that's what you're testing for.
 .
 It also contains %Module::CoreList::released hash, which has ISO
 formatted versions of the release dates, as gleaned from perlhist.
 .
 New, in 1.96 is also the %Module::CoreList::families hash, which
 clusters known perl releases by their major versions.
 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Packages-arch-specific (was: Sparc build failure analysis)

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:

>> Again: what can I do with such a list?  See the list below.

> Changes to the P-a-s list should be sent to the contacts listed at the top
> of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific).

I have to admit that this is the one area of the buildds that I've found a
little frustrating and/or confusing due to lack of communication.

I co-maintain openafs, which builds a variety of arch-specific packages
plus an arch-independent package with the kernel module source.  OpenAFS
upstream does not support arm, m68k, mips, or mipsel.  It's highly
unlikely that it will *ever* support those architectures; the kernel
integration is non-trivial to do, and I've never heard from users of those
architectures who are particularly missing AFS.  (AFS is a little
heavy-weight for the sorts of things that people usually do on those
architectures, I think.)

Now, the openafs package does immediately fail with a reasonable error
message on the unsupported architectures and tags all the binary packages
as only being applicable to supported arches, but it feels like a waste,
every time I upload a new openafs package, for it to go into those
architecture queues, make the buildds download and install all the
dependencies, and start trying to build, only to have it fail.  It's
always going to fail, I know it's always going to fail, and while this
isn't a huge waste of resources, it's at least a little waste.

So I followed the instructions at the top of that file and requested a
P-a-s entry, after asking people here what to do.  No response.  Hm.  I
wasn't sure what to make of that -- maybe this request is too trivial to
bother with, it's fine for the builds to fail, and I should just ignore
it?  Or maybe my e-mail wasn't received?  Or maybe I misunderstood
something and this was the wrong channel or the wrong thing to do?

I waited a while (my saved mail says two months) and asked my AM about it.
He said that mailing them again was probably the right thing to do.  So I
went ahead and did that, providing the specific entry that I think should
be used.  No response (that was in August).  However, I notice in the
build report that m68k is now marking openafs as "not for us" (but the
other arches aren't).  Is this because of my mail?  Because the buildd
administrator noticed the error message?

This is a really minor issue in the grand scheme of things.  It's not RC,
it doesn't break anything, it's really mostly cosmetic plus a minor
resource waste.  Now I'm feeling kind of guilty about bothering clearly
busy people with a trivial request, and I probably really shouldn't send
this message to debian-devel either, since certainly it's not any kind of
serious problem that this hasn't been done.

But I really want to learn.  I want to understand what the right thing to
do is.  It kind of bugs my (probably overactive) sense of neatness to see
openafs sit in those build queues and then fail rather than cleanly being
skipped.  If I should just stop bugging people, I'm happy to do that, but
I'd heard from a few other people who seemed experienced that this is what
I should do, so it would be nice to get a message that explicitly says
"stop bugging us."  Or, well, anything.  Certainly I don't expect such a
message even within a month for this sort of low-priority request; it
takes me that long to get to my mail too.  But

Maybe the right thing to do would be to work out a way for package
maintainers to provide input to their own P-a-s entries in some sort of
automated fashion?  It does seem like a package maintainer is generally
going to know this sort of thing, and I hate to bother busy buildd
maintainers with this kind of thing if I could do it myself.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

question towards "freetype transition; improved library handling needed for all C/C++ packages"

[Benjamin Mesing]

Hello,

today I've tried to address the issue raised by Steve Langasek regarding
"inherited" dependencies [1]. 
As I am unexperienced with the whole linking and dependency process I
was not able to deduce the consequences of this announcement for my
packaging. 
As far as I have understood the email, whatever is added to the linker
on the command line (using -l...) is also added to the package as a
dependency. Is this correct (the depends line of my package is: 
Depends: apt, ${shlibs:Depends}, ${misc:Depends}
)? 

I believe my package is affected by the issues stated by Steve,
depending on libraries which I do not directly use. Most of them are
probably pulled in through the QT library I am depending on. My package,
packagesearch, uses qmake as a build tool. The linking command line
contains loads of other libraries including freetype (collected by
qmake).
In this scenario how should I proceed? Steve's hints seem to apply
mostly to library packages, and due to using qmake are not applicable
for me anyways. Should I go with his last hint to use -Wl,--as-needed?

I considered sending this to debian-mentors, but Steve requested to
reply and ask on debian-devel.

Best regards 

Benjamin


[1] http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html


-- 
Please do not send any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)

[Kurt Roeckx]

On Sun, Dec 11, 2005 at 05:02:15PM +0100, Kurt Roeckx wrote:
> On Sun, Dec 11, 2005 at 04:56:08PM +0100, Adeodato Simó wrote:
> > * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]:
> > 
> > >   To work out which libraries you're linked to which you don't actually 
> > > need,
> > >   ldd -u  is invaluable.
> > 
> >   This seems like not the case _at all_ to me (the "invaluable" bit):
> > 
> > % ldd -u /usr/lib/amarok/amarokapp
> > Unused direct dependencies:
> 
> ldd -u /usr/lib/amarok/amarokapp
> ldd: unrecognized option `-u'
> Try `ldd --help' for more information.
> 
> This atleast doesn't even seem to work on all arches either.

So that seems to be caused by having ia32-libs installed, which
still has an older glibc version.


Kurt


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

Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)

[Kurt Roeckx]

On Sun, Dec 11, 2005 at 04:56:08PM +0100, Adeodato Simó wrote:
> * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]:
> 
> >   To work out which libraries you're linked to which you don't actually 
> > need,
> >   ldd -u  is invaluable.
> 
>   This seems like not the case _at all_ to me (the "invaluable" bit):
> 
> % ldd -u /usr/lib/amarok/amarokapp
> Unused direct dependencies:

ldd -u /usr/lib/amarok/amarokapp
ldd: unrecognized option `-u'
Try `ldd --help' for more information.

This atleast doesn't even seem to work on all arches either.


Kurt


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

ldd -u (Re: Solving recursive dependency disease in KDE-based packages)

[Adeodato Simó]

* Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]:

>   To work out which libraries you're linked to which you don't actually need,
>   ldd -u  is invaluable.

  This seems like not the case _at all_ to me (the "invaluable" bit):

% ldd -u /usr/lib/amarok/amarokapp
Unused direct dependencies:

/usr/lib/libkutils.so.1
/usr/lib/libkhtml.so.4
/usr/X11R6/lib/libGL.so.1
/lib/tls/i686/cmov/libpthread.so.0
/usr/lib/libtunepimp.so.2
/usr/lib/libmysqlclient.so.14
/usr/lib/libz.so.1
/lib/tls/i686/cmov/libcrypt.so.1
/lib/tls/i686/cmov/libnsl.so.1
/usr/lib/libpq.so.4
/lib/tls/i686/cmov/libm.so.6
/lib/libgcc_s.so.1

% nm -D  /usr/lib/libpq.so.4 | grep PQconnectdb
9a90 T PQconnectdb

% nm -D /usr/lib/amarok/amarokapp | grep PQconnectdb
 U PQconnectdb

  If this has an explanation (other than bogus ones like "some other
  dependency links against libpq.so.4", which I don't think it's the
  case, but mentioning as an example), please be my guest. For now, I
  plan on sticking to Henning Makholm's "libneeded" lintian check:

% lintian -C libneeded amarok_1.3.7-1_i386.deb | grep 
usr/lib/amarok/amarokapp
W: amarok: unneeded-explicit-linking usr/lib/amarok/amarokapp libz.so.1 
libkutils.so.1

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Acaba de...
Acaba de una vez...
Acaba de una vez conmigo
-- Astrud, Masaje


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

Re: Packages up for adoption: gnokii, coldsync

[George Wright]

* on Sun, Dec 11, 2005 at 12:21:28PM +1000, Bradley Marshall wrote:

> I'm not sure if this is the right process to follow, so please
> let me know if there's something else I should be doing.

ditto for me - shall I fill in an ITA? I'm not a DD and am unsure as to how to 
proceed.


> There's not much there, but the interesting ones are probably
> gnokii

I'll take this, use it a lot and am relatively OK with how upstream works 


> Please copy me on any replies, I'm not on the list.


Done.


George Wright


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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

[Kurt Roeckx]

On Sun, Dec 11, 2005 at 05:55:23AM -0800, Steve Langasek wrote:
> 
> > Indeed, for practical buildd maintainance purposes, the distinction is
> > not that important -- though 'Failed' is known to not benefit of a
> > requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
> > most archs should have enough surplus buildd power that retrying
> > everything once in a while doesn't hurt.
> 
> > The major benefit is though to make it apparant for porters what to look
> > into, without all the 'noise' in between of maybe-transient failures.
> > One could also make sure that the FTBFS bugs are tagged (user-tagged)
> > with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
> > doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
> > nice overview of all the porting bugs. It'd make sense to synchronise
> > this across all architectures, so that it is consistent.
> 
> http://lists.debian.org/debian-alpha/2005/12/msg00028.html

I have a long list of bug affecting amd64, but I haven't started
with usertags for it.

The (FTBFS) bugs I encouter (as buildd admin) are:
- General bugs affecting all arches.
- General bugs affecting 64 bit arches.
- Bugs affecting some arches (like not using -fPIC)
- Bugs only affecting amd64.

And the later really is the minorty of the problems.

Note that this does not cover runtime problems or something like
that, but they're very simular.

Do we need to have a special usertag for the first kind?  This is
basicly something everybody can look at.  The only reason I can think
of that it requires some tag is that it's better then looking at
those that don't have a tag.

So, I'm open for suggestions on how to tag the first 3 of those.


Kurt


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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

[Steve Langasek]

On Sun, Dec 11, 2005 at 02:38:35PM +0100, Jeroen van Wolffelaar wrote:
> On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote:
> > On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> > > FAILED

> > But FAILED is an advisory state anyway; it doesn't directly benefit the
> > port, at all, to have the package listed as "Failed", this is just a
> > convenience for folks sifting through the build failures (like the rarely
> > used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
> > things needs to happen with each of these build failures: the package needs
> > to be added to P-a-s so the arch no longer tries to build it, or the package
> > needs to be fixed -- via porter NMU if necessary.

> > So as you have the list of these packages, as a porter you can proceed with
> > figuring out which of the two categories each falls into, and take the
> > necessary action without worrying about the "Failed" state, yes?

> Indeed, for practical buildd maintainance purposes, the distinction is
> not that important -- though 'Failed' is known to not benefit of a
> requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
> most archs should have enough surplus buildd power that retrying
> everything once in a while doesn't hurt.

> The major benefit is though to make it apparant for porters what to look
> into, without all the 'noise' in between of maybe-transient failures.
> One could also make sure that the FTBFS bugs are tagged (user-tagged)
> with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
> doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
> nice overview of all the porting bugs. It'd make sense to synchronise
> this across all architectures, so that it is consistent.

http://lists.debian.org/debian-alpha/2005/12/msg00028.html

Our porters can beat up your porters.

;)

-- 
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: Sparc build failure analysis (was Re: StrongARM tactics)

[Jeroen van Wolffelaar]

On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote:
> On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> > FAILED
> 
> But FAILED is an advisory state anyway; it doesn't directly benefit the
> port, at all, to have the package listed as "Failed", this is just a
> convenience for folks sifting through the build failures (like the rarely
> used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
> things needs to happen with each of these build failures: the package needs
> to be added to P-a-s so the arch no longer tries to build it, or the package
> needs to be fixed -- via porter NMU if necessary.
> 
> So as you have the list of these packages, as a porter you can proceed with
> figuring out which of the two categories each falls into, and take the
> necessary action without worrying about the "Failed" state, yes?

Indeed, for practical buildd maintainance purposes, the distinction is
not that important -- though 'Failed' is known to not benefit of a
requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
most archs should have enough surplus buildd power that retrying
everything once in a while doesn't hurt.

The major benefit is though to make it apparant for porters what to look
into, without all the 'noise' in between of maybe-transient failures.
One could also make sure that the FTBFS bugs are tagged (user-tagged)
with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There
doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a
nice overview of all the porting bugs. It'd make sense to synchronise
this across all architectures, so that it is consistent.

If that is done, and there would be some way for porters to easily tag
the build failures themselves on what bug they correspond with, or not,
and especially, what failures are new and are yet to be tagged, there'd
be an easy and clear workflow for porters to work on failures. I don't
think there has really been such a defined porter workflow for build
failures, and nobody so far has built/defined one to the best of my
knowledge. And this touches one of the core points Vancouver is intended
to solve: *porters* need to work on *porting*, and help actively and
actually fixing porting issues in the archive. If creating a better
interface for people to work on this is a part of achieving it, so be
it. I'll see whether I can hack up something together for this,
extending buildd.d.o/~jeroen/status.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Solving recursive dependency disease in KDE-based packages

[Nathanael Nerode]

Most KDE and KDE-dependent packages have an 'admin' directory with various
evil and unnecessary files in it.  I think I've found a recipe for
removing the recursive dependencies from such KDE packages.

(1) Relibtoolizing.  This is much trickier than normal.  First install
Debian's libtool and autotools-dev.  Run all these commands from the top level
directory.

  libtoolize --copy --force

Make sure that ltmain.sh, config.guess, and config.sub have been replaced
in admin.

KDE likes to use its own copy of libtool.m4, so appease it by copying your
version into place.

  cp /usr/share/aclocal/libtool.m4 admin/libtool.m4.in

Regenerating acinclude.m4, aclocal.m4, configure.in, and finally configure,
can be a pain in the neck.  In some packages, it's done by

  admin/cvs.sh

But if that fails you have to work out the individual steps involved.
Sometimes the code is in admin/Makefile.common, so you can run

  make -f admin/Makefile.common configure.in

Check that the right version of libtool.m4 got copied into acinclude.m4
and aclocal.m4.  You may have to do stuff like

  make -f admin/Makefile.common acinclude.m4

(2) Possibly fixing acinclude.m4.in

In my experience the redefinition of AC_FOREACH sometimes fights with the
new libtool.  It's just an optimization, so if autoconf crashes building
configure, delete that section from admin/acinclude.m4.in and rebuild
everything up to and including configure, as noted under (1).

(3) Fixing *_LDADD, *_LIBADD, *_LDFLAGS in the Makefile.am files.

  Replace stuff like $(LIBFOO) with -lfoo, and get rid of stuff like
  $(all_libraries).  $(LIBPTHREAD) is never needed on Linux and should
  be removed; there will be other libraries like that, where you should
  just remove the $(LIBFOO) entry entirely.  This takes some trial and error.
  The configure script may dump stuff into LDFLAGS, in which case your best
  bet is to delete that and replace it with an explicit list of libraries.
  It's OK to do these changes unconditionally because KDE never builds
  static libraries.

  To work out which libraries you're linked to which you don't actually need,
  ldd -u  is invaluable.

  Rebuild your Makefile.in by running the correct version of automake,
  and then -- this is very important -- running

   admin/am_edit

  All the KDE packages edit the Makefile.in generated by automake with
  this script before actually using them.  If you've managed to get
  a working Makefile, you may be able do this rebuild with
  'make (subdir)/Makefile.in'

  The configure script will be figuring out a lot of useless stuff, but it's
  easiest to let it waste its time.  admin/acinclude.m4.in has a lot of
  'foo-config' type code for working out recursive dependencies, and we
  want to ignore most of it, but it's rather hard to delete it without
  deleting code we actually want.  In the long run, it might be advisable
  to make a Debian-specific version of it with all the hideous cruft
  removed, and then all KDE-based packages could be fixed just by updating it;
  but that's a lot of work.

(4) Remove any cruft generated during the rebuild.
  Sometimes this process leaves extra files hanging around which weren't
  there before.  :-P

I license this message as if it were public domain; please copy it anywhere
it might help and edit it as needed.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

A thousand reasons. http://www.thousandreasons.org/
Lies, theft, war, kidnapping, torture, rape, murder...
Get me out of this fascist nightmare!


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

Re: eidviewer menu entry

[Bill Allombert]

On Sat, Nov 12, 2005 at 11:44:50AM +0100, Wouter Verhelst wrote:
> Hi,
> 
> Since eidviewer is an interactive application, I want to add it to the
> Debian menu, but I'm having problems finding the right place to put it;
> none of the categories really fit. The 'Apps/Viewers' category is listed
> in the menu sub-policy as being for 'image viewers', which eidviewer
> isn't. There's a category 'Apps/Tools', but the description of that
> category suggests small things like dockapps or so, which eidviewer
> isn't. There's 'Apps/Technical', which claims to be for 'technical
> stuff', a nice and vague term that officially applies to every piece of
> software patented in the EU, but really rather unhelpful.
> 
> IOW, there's a long list of categories, but I don't feel like any of
> them is really appropriate.
> 
> Suggestions?

There is an ongoing discussion on debian-policy to extend and improve the 
list of menu sections. It is the right time to propose a new section.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

[Kevin Mark]

On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
> >> I can do the analyzing, but what should I do with the results?
> >> [EMAIL PROTECTED] seems to be a black hole.  You'll need to find
> >> someone willing to communicate with access to the buildd queues before
> >> the porters can do anything.
> >
> >I said that deciding which packages should belong in P-a-s is porter work;
> >as is filing bugs on failed packages that shouldn't, providing patches, and
> >doing porter NMUs if necessary.
> 
> Again: what can I do with such a list?  See the list below.
> 
> >If the porters do this effectively, there's really not much need at all for
> >telling the buildd maintainers about transient build failures, because
> >they'll be pretty obvious (and account for the majority of failures, as it
> >should be).
> 
> Just because it is obvious does not mean that the buildd adminstrator
> does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
> "uploaded" 25 days ago, neither is in the archive.
> 
> openoffice.org has been "building" for 8 days, it only took 57 hours
> on my slower than any current sparc buildd pbuilder.  kexi has been
> "building" for 6 days, it took less than 2 hours.
Hi Blars et al.,
has anyone every considered a check in the buildd infrastructure to
alert someone (buildd admin and/or others) if a build is taking too long
(eg openoffice usually takes between 2-3 hours to build and the current
build has been building for 10 hours+). Something like a database entry
or a database of either previous build times or last build time. As a
way to not have a buildd tied up with an obvious build issue and thus
allow the issue to be address sooner thus alowing more buildd
throughput. I'd help but I have neither the skill nor the access to
buildd infrastrure (as I'm not a DD or a buildd admin) but try to give
ideas that I feel are helpful.
Anyway, hope those buildd (and thier admins) are humming along smoothly!
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Co-maintainers sought

[Peter 'p2' De Schrijver]

On Sat, Dec 10, 2005 at 04:00:14PM +0100, Daniel Baumann wrote:
> Francesco Paolo Lovergine wrote:
> > X31 and T43p, and some friends with X40 and A series :-P
> 
> I can even top that one: r40, r50, x31, x40, x41, t42p, t43p and a30 :PP
> 

You want a beowulf of thinkpads ? :)

> (and, just for the records, a 730c..)
> 

A30 and 860 here.

L & L,

p2.

-- 
goa is a state of mind


signature.asc
Description: Digital signature

Re: buildd administration

[Hamish Moffatt]

On Fri, Dec 09, 2005 at 06:50:26PM +0100, Goswin von Brederlow wrote:
> And when you try you get screamed at and flamed as witnessed in the
> huge buildd flame fest the last time. Iirc some 3000 packages were
> build outside the official buildd network across the involved archs at
> that time.

And for the Nth time, this had to change not because of the actual
people involved but because those people were not in our web of trust.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Bug#342859: ITP: fluxus -- Scheme script interpreter that creates graphics live with audio and OSC input data

[Guillaume Pellerin]

Package: wnpp
Severity: wishlist
Owner: Guillaume Pellerin <[EMAIL PROTECTED]>


* Package name: fluxus
  Version : 0.8.0
  Upstream Author : Dave Griffiths <[EMAIL PROTECTED]>
* URL : http://www.pawfal.org/Software/fluxus/
* License : GPL
  Description : Scheme script interpreter that creates graphics live with 
audio and OSC input data

Fluxus also uses a fully featured physics library, which means you can script
physical properties into objects and simulate them in realtime. Released
for Linux under the GPL licence.

The built in scheme code editor runs on top of the renderer (see
screenshots), which means you can edit the scripts while they are
running. This allows Fluxus to be used for livecoding performances, or
simply as a fast feedback way of experimenting or learning about
graphics and animation.

Fluxus lends itself to procedural modelling and animation. There is an
expermental procedural modelling tool, and full support for texturing
and basic material properties.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: buildd administration

[Frank Küster]

Blars Blarson <[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
>>- How can I get information from "inside" a buildd, e.g. temporary files
>>  created during a failed build.
>
> First pass answer: you can't.  sbuild (tries to) clean up after builds.
>
> Alternate: try to get a porter to redo the build and give you the desired
> info.
>
> Best: rewrite your build script to put the desired info into the build log.
> Instead of:
>   foo >/tmp/foo 2>&1
> use:
>   if foo >/tmp/foo 2>&1 ; then : ; else cat /tmp/foo ; exit 1 ; fi

Thanks, but I knew that. I should have specified the context:  What I
really meant was that during building of packages foo and bar, tetex-bin
was installed as a build-dep, and failed to configure.  The postinst
leaves a temporary file in /tmp if it fails, and this is the file I wanted.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

ITP: dict-xdict -- An English to Chinese Dictionary

[Emfox Zhou]

Package: wnpp
Severity: wishlist

* Package name: dict-xdict
 Version : 0.1
 Upstream Author : Fu Jianjun
* URL or Web page : (none)
* License : GNU GPL
 Description : An English to Chinese Dictionary

 This package contains the XDict, the Free English to Chinese
 Dictionary, which originally developed by Fu Jianjun, formatted
 for use by the dictionary server in the dictd package.
 .
 This package will be of limited use without the server found
 in the dictd package.

there are very few free dictionary concerning chinese, either en2cn or cn2en.
i'd try to push this, one of the widely used free chinese dictionary,
into Debian.
--
Emfox Zhou

GnuPG Public Key: 0xF7142EC2

Re: Sparc build failure analysis (was Re: StrongARM tactics)

[Steve Langasek]

On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> >I said that deciding which packages should belong in P-a-s is porter work;
> >as is filing bugs on failed packages that shouldn't, providing patches, and
> >doing porter NMUs if necessary.

> Again: what can I do with such a list?  See the list below.

Changes to the P-a-s list should be sent to the contacts listed at the top
of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific).

> >If the porters do this effectively, there's really not much need at all for
> >telling the buildd maintainers about transient build failures, because
> >they'll be pretty obvious (and account for the majority of failures, as it
> >should be).

> Just because it is obvious does not mean that the buildd adminstrator
> does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
> "uploaded" 25 days ago, neither is in the archive.

Well, release-wise, the practical impact here is quite small; for packages
that aren't needed in order to fix RC bugs, for my part I'm quite content to
have the buildd admins manage such give-backs on their own schedule.  Being
more responsive to give-back requests may generally make people happier, but
there's also a context-switch cost associated with such status polling; in
the non-RC cases, does it really hurt anything to *not* have these packages
given back quickly?  If not, isn't a better solution for people to be
understanding of this?

kq and pointless given back now, btw (not trustedqsl, which is "Failed"
rather than "Uploaded").

> openoffice.org has been "building" for 8 days, it only took 57 hours
> on my slower than any current sparc buildd pbuilder.  kexi has been
> "building" for 6 days, it took less than 2 hours.

openoffice.org is listed as "building" because the buildd crashed mid-build.
Ryan Murray and the package maintainer discussed this on IRC when it
happened; it was not immediately given back because of concerns over whether
the build might take down a *second* buildd while there was still a
significant backlog due to the c2a transition.  No, this isn't perfectly
transparent; but yes, it should be acceptable.  There's almost never a
reason to fret over builds-gone-missing for at least, say, a week and a
half, which is about how long it would take for the package to be eligible
for testing.  In OOo's case, try adding another couple of weeks to that for
the current c2a transition that it blocks on...

> The sparc buildd mainainter has in the past left transient build
> failures lie for over 6 months.  For the past year he's been requeuing
> all maybe-failed packages every 1-3 months.

Well, a) we now have auto-dep-wait, so this is even less of a problem now
than it might have been before; b) in the general case, it's not much of a
problem.

> REQUEUE
> qterm   0.4.0pre3-2+b1  342381

Consider that this was a bug in a *toolchain* package, so more than a simple
give-back is required:  gcc-4.0 needs to be upgraded on the buildds for this
to work.  Given that this was caused by a stray \ in the source that didn't
belong, it would be advisable for the package maintainer to defensively
correct this as well.

> DEP-WAIT
> galago-sharp  libmono-dev
> dmraidlibklibc-dev
> motv  ibzvbi0 (= 0.2.17-3.0.1)
> qmailadminvpopmail-bin
> wvstreams libxplc0.3.13-dev
> sylpheed-claws-gtk2   libclamv-dev
> digikam   libartsl-dev (>=1.4.2)
> tulip mesa-common-dev (= 6.2.1-7)
> liferea   libdbus-glib-1-dev
> kwave kdemultimedia-dev
> ivtools   libace-dev
> fwbuilder libfwbuilder-dev
> gtksharp2 libmono-dev
> libavglibavcodeccvs-dev
> gnucash   slib
> memepack  r-base-dev
> r-cran-bayesm r-base-dev

Um, at least some of these dep-waits are completely wrong; r-base-dev and
slib are arch: all packages, and it's not useful to set a dep-wait on a
package that *is* available.  Could you please revise this list accordingly?

Also, setting an (= $version) dep-wait isn't particularly helpful, sometimes
newer source versions will be uploaded before binaries are uploaded for the
current version.  So please clarify whether these are meant to be >= or
something else.

> FAILED

But FAILED is an advisory state anyway; it doesn't directly benefit the
port, at all, to have the package listed as "Failed", this is just a
convenience for folks sifting through the build failures (like the rarely
used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
things needs to happen with each of these build failures: the package needs
to be added to P-a-s so the arch no longer tries to build it, or the package
needs to be fixed -- via porter NMU if necessary.

So as you have the list of these packages, as a porter you can proceed with
figuring out which of the two