Re: buildd administration

[Ingo Juergensmann]

On Sat, Dec 10, 2005 at 08:22:24AM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > If a package is failing to build or to function on some architecture,
> > your job as that package's maintainer is see if it can be fixed (talking
> > to porters and/or upstream if it's beyond your skills)
> BTW: is there a way to get build failures by mail? especially from the
> architectures which are not visible on buildd.debian.org/PTS like hurd and
> bsd. Took me two days to find a build failure, and I guess it would have
> taken weeks before i would get a FTBFS bug report (asuming those are
> manual).

No, the log receiving addresses are configured in the sbuild/buildd configs.
It's not a per-package config. But you can find a link to the buildd logs of
hurd and such on buildd.net. 

-- 
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: Co-maintainers sought

[Francesco Paolo Lovergine]

On Sat, Dec 10, 2005 at 01:42:25AM +0100, Thomas Hood wrote:
> I seek co-maintainers for:
> 
> mwavem
> thinkpad, tpctl
> resolvconf
> 

I got a couple of thinkpads, so i could be a good candidate for 
thinkpad related things if you agree.

-- 
Francesco P. Lovergine


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

Re: Co-maintainers sought

[Andrew M.A. Cater]

On Sat, Dec 10, 2005 at 10:01:03AM +0100, Francesco Paolo Lovergine wrote:
> On Sat, Dec 10, 2005 at 01:42:25AM +0100, Thomas Hood wrote:
> > I seek co-maintainers for:
> > 
> > mwavem
> > thinkpad, tpctl
> > resolvconf
> > 
> 
> I got a couple of thinkpads, so i could be a good candidate for 
> thinkpad related things if you agree.
> 
Will help as well if feasible. [Running unstable on an R50e :) ]

Andy


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

Re: Co-maintainers sought

[Francesco Paolo Lovergine]

On Sat, Dec 10, 2005 at 09:09:48AM +, Andrew M.A. Cater wrote:
> On Sat, Dec 10, 2005 at 10:01:03AM +0100, Francesco Paolo Lovergine wrote:
> > On Sat, Dec 10, 2005 at 01:42:25AM +0100, Thomas Hood wrote:
> > > I seek co-maintainers for:
> > > 
> > > mwavem
> > > thinkpad, tpctl
> > > resolvconf
> > > 
> > 
> > I got a couple of thinkpads, so i could be a good candidate for 
> > thinkpad related things if you agree.
> > 
> Will help as well if feasible. [Running unstable on an R50e :) ]
> 

X31 and T43p, and some friends with X40 and A series :-P

-- 
Francesco P. Lovergine


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

Re: Intel notebooks for needy developers in developing countries

[Daniel Baumann]

Christian Perrier wrote:
> We (Debian developers and contributors) certainly all agree on this
> (or, at least, the vast majority of us).

Why then being so complicated? If there is a candidate in a country
doomed by US export laws, 'export' the notebook first to someone other
and ship if afterwards to Cuba.

-- 
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: buildd administration

[Brian Nelson]

Anthony Towns  writes:

> On Fri, Dec 09, 2005 at 04:27:10PM +0100, Michael Banck wrote:
>> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
>> > >I also see the keyring's been updated earlier this week, including
>> > >both a replacement key for Horms from late last month, and Chip's
>> > >requested updates.
>> > Indeed, complaining on debian-devel appears to get results, doesn't
>> > it?  At least, that's the conclusion that a rational outside observer
>> > would come to.  
>> Where should I best complain for your NM application to be cancelled?
>
> You can direct concerns about candidates to [EMAIL PROTECTED], which
> will be taken into account when the AM's report is being evaluated. I
> presume it takes quite a few comments from different developers before
> those would override the AM's recommendation though.
>
> Positive comments can also be sent there (as an additional "advocate"
> round, I guess), and are AIUI particularly appreciated, since that gives
> more support to accepting a candidate, which is, after all, what almost
> always happens at that point.

For applicants that are not in the DAM queue (e.g. haven't been approved
by their AM), please send the comments to the AM (and maybe front desk)
instead.  These comments should then be included in the report submitted
by the AM.

-- 
Captain Logic is not steering this tugboat.


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

Re: buildd administration

[Josselin Mouette]

Le samedi 10 décembre 2005 à 11:51 +1000, Anthony Towns a écrit :
> On Fri, Dec 09, 2005 at 05:56:24PM +0100, Josselin Mouette wrote:
> > How many developer resignations will you need to understand inaction
> > from people at key positions sucks the fun out of things in a worse way?
> 
> Yeah, threatening resignations, that sure is fun!

This is no threat, this is a fact. People are resigning because other
people at key positions aren't doing the job they volunteered to do.

> > If the responsibility position isn't fun enough for the work to be done,
> > the person holding that position should resign. It probably required
> > some courage from you do resign from being release manager, and you
> > deserve credits for doing it instead of letting things rot.
> 
> Actually it required complete disinterest in the entire process; I made
> the decision when the "Let's force in amd64 in spite of what anyone
> says" GR got proposed. 

It got proposed because no one was able to give correct explanations
about why it hadn't been included. I still believe it was a mistake to
release without amd64. That doesn't make me think the entire sarge
release process was wrong; in fact it is certainly our best release
ever.

(Actually, I was already told I'm complaining too much about things
going wrong and never telling people when they are doing a great job.
But if I had to shout it loud whenever I think someone does a great job,
it would suck all my time.)

> What required time, skill, planning and energy
> was the process of actually teaching other folks the skills they needed
> to help out; of the five volunteers only two worked out. At least by
> now I'm only amused that your best characterisation of my time as RM is
> "letting things rot".

Why are you intentionally misreading me? "Letting things rot" is what
*could* have happened, had you go on with this position without finding
it interesting enough.

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: buildd administration

[Michael Banck]

On Fri, Dec 09, 2005 at 12:47:59PM -0600, Manoj Srivastava wrote:
> On Fri, 9 Dec 2005 16:27:10 +0100, Michael Banck <[EMAIL PROTECTED]> said: 
> > Where should I best complain for your NM application to be
> > cancelled?
> 
> Err, so if a NM candidate speaks as openly as some DD's do,
>  they get threatened with  having their applications cancelled because
>  of them speaking their minds? 

"I apologize for publically insulting people; I should
have found a better way to deal with their idiocy."
-- Nathanael Nerode

If he thinks he can resolve issues by flaming people publically on
debian-devel, then yes, I think we have different opinions about this
project and I would like to voice my concern.  Obviously, my voice does
not hold any more weight than any other DD's, so I fail to see how this
is threatening in any way, unless no other DDs (or his AM) would support
him either.  That I believe that other DDs should not flame on
debian-devel either is somewhat unrelated to this.

> What is this, a munich beer hall in 1933?

On a historical anecdote, most things in 1933 happenend in Berlin
already.  Unless you consider how I live in Munich, which makes this
comment more appropriate as an ad-hominem attack, I guess.


cheers,

Michael

-- 
 Jeroen: Is that your first big flamewar?


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

Re: buildd administration

[Michael Banck]

On Sat, Dec 10, 2005 at 09:18:28AM +0100, Ingo Juergensmann wrote:
> On Sat, Dec 10, 2005 at 08:22:24AM +0100, Bernd Eckenfels wrote:
> > BTW: is there a way to get build failures by mail? especially from the
> > architectures which are not visible on buildd.debian.org/PTS like hurd and
> > bsd. Took me two days to find a build failure, and I guess it would have
> > taken weeks before i would get a FTBFS bug report (asuming those are
> > manual).
> 
> No, the log receiving addresses are configured in the sbuild/buildd configs.
> It's not a per-package config. But you can find a link to the buildd logs of
> hurd and such on buildd.net. 

There are currently no public build logs for hurd-i386, but we are
working on getting them published on experimentel.ftbfs.de as well.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

${Source-Version} without revision

[Bartosz Fenski aka fEnIo]

Hello.

Is there any variable similar to ${Source-Version} which would allow me to
use version of the upstream sources in control file?

I have packages where program and data are distributed separately and
usually there are no need to change data package, but using:

Depends: foo-data (= ${Source-Version})

leads to the situation when I have to bump version of the -data package.
Would be great to have ${Upstream-Version} for such purposes.

Is there something like that I'm not aware of?

I couldn't find anything like that in `man dpkg-gencontrol`.

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: ${Source-Version} without revision

[Jérôme Marant]

Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:

> Hello.
>
> Is there any variable similar to ${Source-Version} which would allow me to
> use version of the upstream sources in control file?
>
> I have packages where program and data are distributed separately and
> usually there are no need to change data package, but using:
>
> Depends: foo-data (= ${Source-Version})
>
> leads to the situation when I have to bump version of the -data package.
> Would be great to have ${Upstream-Version} for such purposes.
>
> Is there something like that I'm not aware of?
>
> I couldn't find anything like that in `man dpkg-gencontrol`.

Use dpkg-parsechangelog along with sed to get the upstream from
the debian version.
Then use dpkg-gencontrol -VUpstream-Version=$(upstream_version) 

-- 
Jérôme Marant

Re: State of gcc 2.95 use in Debian unstable

[Bill Allombert]

On Fri, Dec 09, 2005 at 04:22:37PM +0100, Goswin von Brederlow wrote:
> Heiko M?ller <[EMAIL PROTECTED]> writes:
> 
> > We found that gcc-2.95 -Os produces object code of acceptable quality 
> > within reasonable compilation times. gcc >=3 is less efficient w.r.t.
> > compilation time and memory consumption and in many cases even fails 
> > to compile our codes due to the very long expressions. The C/C++ codes
> > generated from the computer algebra software are perhaps unusual but 
> > not broken.
> 
> Can you send in a few (hopefully short) examples that fail as
> bugreports?

I cannot speak for Heiko, but my examples are far from short. Indeed
they include a statement that is several megabytes long.
gcc exhaust all the memory available and fail with 
 Internal compiler error:
 virtual memory exhausted
An gcc version that use less memory will be able to complete the
compilation.

> There is probably nothing to do about compile time and memory
> consuption but it should at least work. Maybe the compiled result is
> even faster.

Provide you have enough memory to get it at all.

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: State of gcc 2.95 use in Debian unstable

[Steinar H. Gunderson]

On Fri, Dec 09, 2005 at 09:33:11AM +0100, Heiko Müller wrote:
> We found that gcc-2.95 -Os produces object code of acceptable quality 
> within reasonable compilation times. gcc >=3 is less efficient w.r.t.
> compilation time and memory consumption and in many cases even fails 
> to compile our codes due to the very long expressions.

Note that there were considerable improvements done in gcc 3.4 and gcc 4.0
with regard to compilation speed (in particular in non-optimizing builds);
you might want to re-test with GCC 4.x if you haven't already.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: buildd administration

[Thijs Kinkhorst]

On Sat, 2005-12-10 at 02:40 +, Matthew Garrett wrote:
> Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> 
> > I'm not really convinced that such an approach would have a significant
> > effect as long as you're not measuring existing DD's to the same
> > standards. Which, as far as I can see, does not happen.
> 
> A procedure is in place for developers to be ejected from the project.
> If you feel that anyone is behaving in a way that would not have allowed
> them to get through NM, then please do invoke it.

I'm sorry, but following that procedure, I can't. But that's fine, since
I didn't want to; I just wanted to point out that I'm pretty sure that
the people advocating complaining about NM-candidates have hardly, if
ever, invoked this procedure or any other official mechanism for
adjusting the attitudes of existing developers, and that they might want
to shift their attention.

There's too much emphasis on the NM-process, and nearly no emphasis on
evaluation of your performance after you've passed it. I once spoke with
a maintainer that didn't want to orphan a package he couldn't take good
care of as long as he was in NM, but was willing to orphan it just after
he passed the DAM stage (and did). Complaining about NM-candidates but
no post-graduation evaluation just encourages this kind of behaviour.


Thijs


signature.asc
Description: This is a digitally signed message part

Re: buildd administration

[Marc Haber]

On Fri, 09 Dec 2005 19:24:00 -0800, Thomas Bushnell BSG
<[EMAIL PROTECTED]> wrote:
>An excellent example of this is the publication of the NEW queue.  Now
>that everyone can see the NEW queue, I don't see any of the big public
>criticism about slow processing.

I have to disagree here. Things have improved _greatly_ after Ganneff
was added to the ftp-master team. This might have been a coincidence
with the NEW publication, but the real improvement there is Ganneff.

>> (BTW, I see #335981 and #336371 haven't received a response since late
>> October; or has raptor been down that entire time, so that you haven't been
>> able to diagnose it further -- it certainly seems down now?)
>
>Upstream is working on #335981 and #336371.  In fact, scm has *never*
>supported s390; when I took over maintenance of the package I opened
>the bugs so that it could be more effectively tracked.
>
>And since I am the one who opened #335981, I don't really think a
>reply to myself is all that necessary.

I disagree. The BTS is a public repository, available to the general
public. If there is more information to a bug available, the BTS is
the place where it should be.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: buildd administration

[Marc Haber]

On Sat, 10 Dec 2005 02:40:11 +, Matthew Garrett
<[EMAIL PROTECTED]> wrote:
>Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
>
>> I'm not really convinced that such an approach would have a significant
>> effect as long as you're not measuring existing DD's to the same
>> standards. Which, as far as I can see, does not happen.
>
>A procedure is in place for developers to be ejected from the project.
>If you feel that anyone is behaving in a way that would not have allowed
>them to get through NM, then please do invoke it.

The people deserving to be ejected are planted too firmly in their
seats.

Greetings
Marc, who probably wouldn't pass NM today any more

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: ${Source-Version} without revision

[Henrique de Moraes Holschuh]

On Sat, 10 Dec 2005, Jérôme Marant wrote:
> Use dpkg-parsechangelog along with sed to get the upstream from
> the debian version.
> Then use dpkg-gencontrol -VUpstream-Version=$(upstream_version) 

Yes, something like (makefile syntax):

# Version information
VERSION?=$(shell dpkg-parsechangelog | grep -E "^Version:" | tr -d ' \t' | cut 
-d ':' -f 2-)

UPSTREAM_VERSION:=$(shell echo "$(VERSION)" | sed -e 's/-[^-]\+$$//')

Be my guest to change the first line to a single sed command.

-- 
  "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

[Cosimo Alfarano]

On Tue, Dec 06, 2005 at 09:09:39AM -0200, Henrique de Moraes Holschuh wrote:
> I doubt very much so parallel downloads will be added to apt.

Could be added Release-file based.
Parallelize only unrelated pools, and disabled by default to avoid
conflict wiht apt-proxy (if any).

ie: Debian and Foo vendors can be parallelized without jeopardize any
mirror maintainer effort, since they're completely disjointed.

just my 2 cents,
c.
-- 
Cosimo Alfarano, kalfa at {bononia.it,debian.org,cs.unibo.it}
0DBD 8FCC 4F6B 8D41 8F43  63A1 E43B 153C CB46 7E27
foaf://www.bononia.it/~kalfa/foaf.rdf


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

Re: Intel notebooks for needy developers in developing countries

[Lars Wirzenius]

la, 2005-12-10 kello 10:39 +0100, Daniel Baumann kirjoitti:
> Christian Perrier wrote:
> > We (Debian developers and contributors) certainly all agree on this
> > (or, at least, the vast majority of us).
> 
> Why then being so complicated? If there is a candidate in a country
> doomed by US export laws, 'export' the notebook first to someone other
> and ship if afterwards to Cuba.

If the US law enforcement people learn about it, they will quite
probably interpret it as an attempt to circumvent US laws, and act
accordingly. That's a pretty fair interpretation, of course, since that
is exactly what is going on.

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

-- 
(def (reverse items) (accumulate (fn (so-far x) (cons x so-far)) nil
items))


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

Re: apt PARALLELISM

[Stephen Gran]

This one time, at band camp, Cosimo Alfarano said:
> On Tue, Dec 06, 2005 at 09:09:39AM -0200, Henrique de Moraes Holschuh wrote:
> > I doubt very much so parallel downloads will be added to apt.
> 
> Could be added Release-file based.
> Parallelize only unrelated pools, and disabled by default to avoid
> conflict wiht apt-proxy (if any).

Seperate repositiories are already parallelized, which is what I think
you are asking for here.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: ${Source-Version} without revision

[Andreas Metzler]

Jérôme Marant <[EMAIL PROTECTED]> wrote:
> Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
>> Is there any variable similar to ${Source-Version} which would allow me to
>> use version of the upstream sources in control file?
[...]
> Use dpkg-parsechangelog along with sed to get the upstream from
> the debian version.
> Then use dpkg-gencontrol -VUpstream-Version=$(upstream_version) 

Indeed. This snippet in deian/rules works for me:
UPSTREAMVERSION :=  $(shell dpkg-parsechangelog | sed -n '/^Version: 
/{s/^Version: \(.\+\)-[^-]\+/\1/;p;}')
[...]
dh_gencontrol -i -- -VUpstream-Version=$(UPSTREAMVERSION)
[...]
dh_gencontrol -a -- -VUpstream-Version=$(UPSTREAMVERSION)
 cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
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 Baumann writes:
> Why then being so complicated? If there is a candidate in a country
> doomed by US export laws, 'export' the notebook first to someone other
> and ship if afterwards to Cuba.

This would still violate the export law.  Otherwise the law would be even
more pointless than it already is.

I don't see why we need to concern ourselves about it, though.  Intel has
lawyers.  If they have to disqualify some candidates for legal reasons they
can do so without our help.
-- 
John Hasler


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

Sparc build failure analysis (was Re: StrongARM tactics)

[Blars Blarson]

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.

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.



I've gone through the list of "maybe-failed" packages on sparc again.
The first sections is the packages that shouldn't be attempted on
sparc.  Two packages need requeued now that bugs in other packages are
fixed.  Several packages need to be put in dep-wait, and of course
there is a large list that should be moved to failed.  If nothing
useful is done with this list, don't expect me to repeat the work
again.


NOT-FOR-US

numactl
only supports i386 amd64 ia64
appears to assume intel-style stuff, would need major redesign
for other architectures
vm
only supports all, not any
see bug 342185
wmkbd
gsnes9x
pistachio
needs arch-specific code
acpidump
kexec-tools
bug 338846
redboot
bug 152911
rsbac-admin
hdaps-utils
lcd4linux
bug 336017
vnstat
hotkey-setup
gwp
snes9express
contrib, needs snes9x-x
libaio
adeos
defrag
ree
odyssey
nvidia-cg-toolkit
atokx2
xmms-openspc
lcrash
grub2
php4-maxdb
libpam-encfs
915resolution
pcsx
acpica-unix


REQUEUE
mcvs1.0.13-12   341850
qterm   0.4.0pre3-2+b1  342381


DEP-WAIT
galago-sharplibmono-dev
dmraid  libklibc-dev
motvibzvbi0 (= 0.2.17-3.0.1)
qmailadmin  vpopmail-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
libavg  libavcodeccvs-dev
gnucash slib
memepackr-base-dev
r-cran-bayesm   r-base-dev


FAILED
bazaar  1.4.2-2 334320
palo1.9 320284
raidutils   0.0.4-7 326922
icon9.4.2-2.3   322972
erlang  1:10.b.7-1  326031
ispell-fi   0.7-16  326025
gmpc0.12.0-1333711
cursel  0.2.2-3.1   267900
supercollider   20050624-1  290339
qprof   0.5.1-6 323094
silc-toolkit0.9.12-4.1  326924
libgstreamer-perl   0.04-1  328051
jmagick 6.0.4-0-1   329104
mesa-lagacy 6.2.1-8 327637
xsim0.3.9.4-6   221453
haskell-http0.4.20050430-1  315333
rhyme   0.9-5   269371
ultrapossum-slapd   0.0.4+2.2.20sb3-1   304092
wmtune  1.1-1   269718
siptoolbox  0.3.99rc2alpha3-2   332526
slate   0.3.4.3-2   323126
postgis 1.0.0-1 323120
php4-vpopmail   4.3.4-5.4.4+2   309556
babel   0.10.2-2.1  309272
stalin  0.9+0.10alpha2-2337169
klibc   1.1.1-4 330191
libopenspc  0.3.99a-2   322979
iproute 20041019-4  336675
swish-e 2.4.3-2 339343
rcalc   0.5.0-1 339103
insight 6.3.50+cvs.2005.11.16-1 339723
gpsd2.30-1  340852
glibc

Re: Co-maintainers sought

[Daniel Baumann]

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

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

-- 
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: buildd administration

[Anthony Towns]

On Sat, Dec 10, 2005 at 11:52:22AM +0100, Josselin Mouette wrote:
> It got proposed because no one was able to give correct explanations
> about why it hadn't been included. 

Heh. I'm almost morbidly curious enough to ask what you think the
"correct" explanation of why it hasn't been included is, except that,
well, I'm not.

For those playing along at home, Martin replied to Josselin's query at
the time with his DPL hat on:

http://lists.debian.org/debian-devel/2004/07/msg00253.html

Josselin's reaction to that explanation, which remains completely
correct as far as it goes (though perhaps focussing too much on the
"write a policy") is pretty much why I don't think explanations are a
particularly useful part of addressing these controversies.

> I still believe it was a mistake to release without amd64. 

We didn't release without amd64; the sarge release for amd64 is on
amd64.debian.net.

> (Actually, I was already told I'm complaining too much about things
> going wrong and never telling people when they are doing a great job.
> But if I had to shout it loud whenever I think someone does a great job,
> it would suck all my time.)

A far better idea, in my experience, is to use all the instances of people
doing a good job as support for the proposition "when bad things happen,
there's probably a good reason for it because these are good, honest,
hard working colleagues of mine".

Cheers,
aj



signature.asc
Description: Digital signature

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

[Christoph Hellwig]

On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> numactl
>   only supports i386 amd64 ia64
>   appears to assume intel-style stuff, would need major redesign
>   for other architectures

There's nothing intel-specific in here, rather it assumes NUMA support
in the kernel.  Obviously this is only the case for architectures that
support numa. I've actually tested it on ppc64, although not on debian.

> libaio

this should build on all architectures.  Currently it needs a tiny bit
of architecture-specific code, but that could be avoided by using proper
syscall macros instead of trying to do it's own.


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

Re: State of gcc 2.95 use in Debian unstable

[Thiemo Seufer]

Heiko Müller wrote:
> Dear Thiemo,
> we very much appreciate your work on the gcc-2.95 debian package.
> For us - and probably also for other users in the scientific 
> community - the "old" compiler version is still of great value.
> 
> We use gcc-2.95 to compile C/C++ code with very large mathematical 
> expressions generated by computer algebra software. This involves 
> very long (several thousand lines of code) functions to evaluate 
> multi-variable polynomial expression resulting from perturbation 
> theoretical solutions of physical problems. 
> 
> We found that gcc-2.95 -Os produces object code of acceptable quality 
> within reasonable compilation times. gcc >=3 is less efficient w.r.t.
> compilation time and memory consumption and in many cases even fails 
> to compile our codes due to the very long expressions. The C/C++ codes
> generated from the computer algebra software are perhaps unusual but 
> not broken.

Well, gcc 3.x was somewhat disappointing WRT, but I would expect 4.0
to do better. If 4.x fails for your (valid and standard-conforming)
code, please consider to provide a testcase to the upstream developers.
I'm sure they are interested in it, and long-term it will help you as
well to have a more modern compiler which can handle such cases.

> Since what we are doing is not so unusual in theoretical physics we are
> probably not alone with these kind problems. Please consider that even 
> if no other debian packages would depend on gcc-2.95 many users may 
> very much require it.  

Indeed, I got also one private reply which suggested gcc-2.95 is still
an interesting choice for some numerics code.


Thiemo


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

Re: buildd administration

[Russ Allbery]

Anthony Towns  writes:

> Since this point obviously needs to be made clearer, I guess it's time
> to have some more rounds of removing packages that have long outstanding
> RC bugs. I guess I'll coordinate with the RM team to do this sometime
> over Christmas/New Year.

(The following comment should not in any way be read as referring to
Thomas's packages.)

Please look at orphaning them before just removing them.  In many cases,
other people may be willing to pick up the package had they been aware
that it needed more attention.  There are unfortunately a lot of RC bugs
right now, partly due to the documentation licensing issues, whereas the
list of orphaned packages is much smaller and easier to look over.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: buildd administration

[Russ Allbery]

Michael Banck <[EMAIL PROTECTED]> writes:

> There are currently no public build logs for hurd-i386, but we are
> working on getting them published on experimentel.ftbfs.de as well.

If you can get them into ,
that would be wonderful.  I read that page religiously for my packages and
will investigate and attempt to fix any problem that shows up there.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: buildd administration

[Thiemo Seufer]

Jeroen van Wolffelaar wrote:
[snip]
> A similar issue I noted in the past is the big number of build failures
> that don't get tagged 'Failed'. I tried working on classifying them, but
> got bored so increadibly fast that I gave up, and decided for myself
> this should be something the porters should rather look into. And thus I
> mailed in June about that[2]. I don't believe anyone picked up that, but
> I might be wrong, of course, my mail was hidden in a big thread about
> various stuff, just like this very mail is...

FWIW, I did for mips/mipsel and found your page to be very helpful.


Thiemo


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

Re: Intel notebooks for needy developers in developing countries

[Andreas Tille]

On Sat, 10 Dec 2005, Daniel Baumann wrote:


Why then being so complicated? If there is a candidate in a country
doomed by US export laws, 'export' the notebook first to someone other
and ship if afterwards to Cuba.


Well, this was my first idea as well.  Even if I absolutely not like
the kind of restrictions the company Intel is pressed under in a
non-free country I think we should not try to circumvent the rules
under that a generous offer was given.  So lets assemble a list first.
Wait what happens then.  If some of the top 20 persons would be removed
because of the rules of a non-free country prevent this lets try to
find an alternative in the free world and try to find a solution to
serve people who need a box to work for Debian will finally get a
box to work for Debian.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: buildd administration

[Nathanael Nerode]

This is an omnibus reply.  Sorry about the thread-breaking, but I'm on 
yet *another* computer, and I can't seem
to find a mailer which respects the In-Reply-To headers from the web 
pages or lets me add my own.


==
I would like to note that I have made a practical and *new* suggestion 
for dealing with some of these problems
(contrary to suggestions that I'm just flaming), because nobody's picked 
up on my idea.  From

http://lists.debian.org/debian-devel/2005/12/msg00298.html:

If they don't think that anyone is skilled or 
trustworthy enough to help with the work they're already doing





(b) at any rate there is certainly someone 
skilled and trustworthy enough to act as 'press secretary' for them, 
collecting all the questions from the outside and returning the answers to 
the outside!


I haven't heard this suggested before as a means to assist overworked 
people in key positions with the problem
of  communication.  It would reduce the number of people the overworked 
people have to communicate with to one, removing the need to explain 
anything more than once.  That one secretary could receive status 
reports and use them to generate answers for all outside questions, 
while batching together unanswered questions into groups.  In addition, 
that secretary could provide a contact addresses which is properly 
advertised -- clearly not a task which requires great trust, but one 
which does require close contact with the people actually doing the 
job.  Perhaps it would be more acceptable to the people involved than 
the other suggested alternatives.


It has the virtue of removing some of the need for the people with the 
key technical skills to also be the people with the key social skills.


I'm sure there are people who will volunteer for this role. I will 
volunteer, since I certainly have the motivation, but I don't really 
have the right temperment for it, or all of the right set of social 
skills (though I do have a few skills in that area, believe it or not), 
and I might be an unpopular choice.  The overworked people should 
clearly be allowed to choose their own "press secretaries" from among 
the volunteers.


==
In response to something someone quoted that I wrote a while back: yes, 
I should have found a better way of dealing with people who are behaving 
idiotically than insulting them.  I constantly try to find better ways.  
I would expect that everyone should try to do that (after all, all of us 
behave like idiots sometimes, me certainly included, and I had been 
behaving idiotically by insulting people).  That quote actually 
demonstrates that I do *not* think that insulting people is effective.  
Pity, since I'm so naturally good at insulting people in ways which 
really get under their skin (really useless skill, but there you are ;-/ ).


==
Regarding specific points.

The scripts at www.buildd.net are clearly better at presenting the 
information than the ones at buildd.debian.org (yes, it's mostly the 
same information, but presentation matters).  I agree that their source 
code should be made publicly available, and it's a bad thing that they 
aren't.  :-P  Ingo, could you fix that?


The 'status leds' for the buildds, together with the admin information 
for each buildd, is a valuable addition beyond what's present on 
buildd.debian.org, and if done properly would eliminate lots of "what's 
wrong with the foo-arch buildds?" questions.  It's sort of half-present, 
with occasionally inaccurate admin info, at the moment, which renders it 
less useful, but that would be fixed purely by cooperation.



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

Is Lars Steinke MIA?

[Justin Pryzby]

On 2005-11-14, I filed grave bug #339056: "Library package fails
to include shlibs file" [0] on package tktable-dev [1] , on which my
package saods9 build-depends.  I'm concerned about this bug because 1)
its RC; 2) I haven't heard back in a month, despite pinging the
maintainer last week; 3) My package depends on it [2]; and 4) Only 1
other package, also maintained by Lars, depends on it.

I would have expected some response by now, so I'm alerting -qa and
asking -devel for info. 

Has anyone heard from Lars Steinke <[EMAIL PROTECTED]> in the last month?
A quick google search indicates that he was active early this year, at
least, and his bug page indicates that he has probably been inactive
for ~6 months.

Please Cc: me with relevant info if you are not also mailing QA.

-- 
Clear skies,
Justin

References

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339056

[1] Now serious, reassigned, and retitled.

[2] Though it would be easy to link against the copy of tktable
distributed in the DS9 sources by SAO upstream.


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> FTBFS issues are the most common though, as well as the easiest to
> resolve; your point would carry more weight if you took the time to fix
> yours first. (Looking through -private, I saw someone remark that 1000
> bugs was too many -- we have got 1400 _RC_ bugs at the moment...)

"Took the time"?  It's not trivial to resolve; it requires working on
the stack-copying code in SCM, which is non-trivial, highly
machine-dependent, and difficult to debug.

Thomas


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

Re: buildd administration

[Thomas Bushnell BSG]

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.  It is an RC issue, because it is an issue that
I, as the package maintainer, believe is sufficiently important that
it should block the package from entry into testing until resolved.

>> (Actually, you have six open RC bugs, because you "maintain" packages
>> by ignoring them and relying on others to fix your bugs for you, and
>> then not acknowleding the NMUs.  I fail to see how this is better.)
>
> There is nothing wrong with NMUs. Honestly, if you fail to see how a
> bug fixed in an NMU is better than an open RC bug and a package in the
> archive that doesn't work at all, I don't understand how you passed n-m.

scm does, in fact, work.  What makes you think the contrary?

You simply don't have the facts.


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

Re: buildd administration

[Thomas Bushnell BSG]

Marc Haber <[EMAIL PROTECTED]> writes:

>>> (BTW, I see #335981 and #336371 haven't received a response since late
>>> October; or has raptor been down that entire time, so that you haven't been
>>> able to diagnose it further -- it certainly seems down now?)
>>
>>Upstream is working on #335981 and #336371.  In fact, scm has *never*
>>supported s390; when I took over maintenance of the package I opened
>>the bugs so that it could be more effectively tracked.
>>
>>And since I am the one who opened #335981, I don't really think a
>>reply to myself is all that necessary.
>
> I disagree. The BTS is a public repository, available to the general
> public. If there is more information to a bug available, the BTS is
> the place where it should be.

So why has nobody asked about the bug?  There is *always* more
information available, for every bug.  For every bug, there is always
some question I could ask about the bug.  The maintainer should be
willing to anticipate the question, but need not spend gobs of energy
*anticipating* every possible question and logging the answers in the
BTS.

However, since people have invented a wholly fictitious interest in
this particular bug, I have tagged it with the relevant information.

Now, let's review the show so far.

People have been upset and critical about the miserable nonperformance
of the keyring and the buildd maintainers.  Especially they have been
upset and critical about nonresponsiveness, about an unwillingness to
answer questions and detail approaches, about an unwillingness to
admit when things are too much work.

Anthony decided that the best way to demonstrate what's so awful about
those upset critical complaints was to invent a fictitious interest in
a bug in a package that isn't even released, which I only began
maintaining recently, and which I've been working seriously on getting
fixed.

Moreover, in response to the critical email, I have demonstrated a
willingness to engage the issue.  I have not maintained utter silence,
I have not said it is unfair to ask questions, I have not, in fact,
done any of the things that the keyring/buildd maintainers do.

So now, I think I have demonstrated that I am ready and willing to do
what I expect of other developers, especially those in
single-point-of-failure positions.  Will Anthony and others now pony
up, and instead of stamping their feet and crying about how everyone
doesn't kowtow to them, start aggressively *solving* problems,
starting with *their own* problems?

Thomas


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

Re: apt PARALLELISM

[Charles Fry]

> Seperate repositiories are already parallelized, which is what I think
> you are asking for here.

But if multiple URLs could satisfactorily serve requests for a single
repository, only one of them is currently used.

Ideally, the amount of parallelism could match the number of redundant
URLs provided for a single type of source.

Charles

-- 
Substitutes
Resemble
Tail-chasing pup
Follow and follow
But never catch up
Burma-Shave
http://burma-shave.org/jingles/1941/substitutes


signature.asc
Description: Digital signature

Re: apt PARALLELISM

[Marco d'Itri]

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.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

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.
Congratulations.

Cheers,
aj



signature.asc
Description: Digital signature

Packages up for adoption: gnokii, coldsync

[Bradley Marshall]

Hi all,

I've not had as much time to devote to Debian as I'd like,
so in all fairness I'm offering my packages up for adoption
so they can be looked after better than I've got time for.
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.

There's not much there, but the interesting ones are probably
gnokii, and coldsync.  I'd much prefer that coldsync and
libpalm-perl went together, too.

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

Thanks,
Brad
-- 
Brad Marshall
[EMAIL PROTECTED]
http://quark.humbug.org.au/


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

Re: buildd administration

[Ingo Juergensmann]

On Sat, Dec 10, 2005 at 06:29:03PM -0500, Nathanael Nerode wrote:

> I would like to note that I have made a practical and *new* suggestion 
> for dealing with some of these problems
> (contrary to suggestions that I'm just flaming), because nobody's picked 
> up on my idea.

Well, it's hard to suggest something when you're not reachable:
 
~~~
Your message cannot be delivered to the following recipients:

  Recipient address: [EMAIL PROTECTED]
  Original address: [EMAIL PROTECTED]
  Reason: Over quota
~~~

For some things I prefer private mail, especially when I try to avoid flame
wars on d-d, so this was a private mail in reply to your mail below:

> http://lists.debian.org/debian-devel/2005/12/msg00298.html

I tried to sent you my answer to the posting twice now and got it back twice
due to over quota.

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

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


signature.asc
Description: Digital signature