Work-needing packages report for Dec 9, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 188 (new: 4)
Total number of packages offered up for adoption: 91 (new: 1)
Total number of packages requested help for: 21 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cpbk (#341724), orphaned 6 days ago
 Description: a mirroring utility for backing up your files
 Installations reported by Popcon: 39

   elvis (#341821), orphaned 5 days ago
 Description: powerful clone of the vi/ex text editor
 Reverse Depends: elvis-tools elvis-console elvis
 Installations reported by Popcon: 136

   gtk-engines-begtk (#342454), orphaned yesterday
 Installations reported by Popcon: 358

   qps (#341907), orphaned 5 days ago
 Description: Qt based process status
 Installations reported by Popcon: 65

184 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   rscheme (#341874), offered 5 days ago
 Description: Threaded, persistent, OO, scheme interpreter and
   compiler
 Installations reported by Popcon: 12

90 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 168 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot
 Installations reported by Popcon: 50

   athcool (#278442), requested 408 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 202

   debtags (#321654), requested 124 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit
 Installations reported by Popcon: 422

   dselect (#282283), requested 383 days ago
 Description: a user tool to manage Debian packages

   fetchmail (#331642), requested 65 days ago
 Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail
 Installations reported by Popcon: 2476

   grub (#248397), requested 577 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
   grub-splashimages
 Installations reported by Popcon: 6379

   gtkpod (#319711), requested 137 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 212

   gutenbrowser (#331203), requested 67 days ago
 Description: Project Gutenberg Etext reader
 Installations reported by Popcon: 53

   lib (#329966), requested 75 days ago
 Description: Perl interfaces to the Gtk and Gnome libraries

   lsdvd (#316922), requested 157 days ago
 Description: read the contents of a DVD
 Installations reported by Popcon: 678

   mwavem (#313369), requested 178 days ago (non-free)
 Description: Mwave/ACP modem support software
 Installations reported by Popcon: 5

   openssl (#332498), requested 63 days ago
 Description: Secure Socket Layer (SSL) binary and related
   cryptographic tools
 Reverse Depends: openssh-server-udeb libaqbanking0c2a
   libopensc-openssl libecpg-compat2 nsd apache-ssl pound webmin
   aqbanking-tool avscan bzflag-server wpasupplicant dsniff libneon24
   fetchmail slapd libnet-ssleay-perl liblasso3 ultrapossum-tls ssmtp
   sqlrelay-sqlite cacti-cactid d4x sylpheed hplip sylpheed-claws-gtk2
   sylpheed-gtk1 libapache-mod-php4 php4-cgi postgresql-contrib-8.1
   libpq3 libaqbanking-ofx0 sylpheed-claws-gtk2-clamav libldap-2.2-7
   lwresd newpki-server hula davfs2 xine-ui heartbeat-2 libaqgeldkarte0
   php5-cli ohphone-basic libecpg-dev racoon postfix cyrus21-common
   t38modem pyca ftpd-ssl fireflier-server siege nagios-plugins-basic
   bibletime libpq4 libyaz sylpheed-claws-spamassassin pantomime-dev
   libzorpll-dev grip usermin libpam-mount python2.3-sqlrelay
   apache2-mpm-prefork mozilla-opensc kannel-extras aria libkeynote0
   sslwrap simph323 libsope-ldap4.4 postgresql-7.4 conserver-client
   libwvstreams4.2-extras xsupplicant xmms-scrobbler proftpd
   newpki-client tellico webauth-utils ca-certificates italc-client
   libopensc1-dev dovecot-pop3d libsnmp9-dev isync nmap dovecot-imapd
   libpam-musclecard proftpd-mysql postgresql-client-8.1
   libc-client-dev libaws-dev ipopd gambas-gb-net-curl libopensc1
 

Re: Need pain pills?please tell me how w/out prescri.

[Adrienne]

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> That's non-sensical. Everything the buildds do is logged pretty much
> immediately onto http://buildd.debian.org/, which also provides long
> running statistics on how effective the buildds are, and even a schedule
> of what the buildds will be working on next.

That tells us what the buildds are doing.  It doesn't tell us anything
about what the buildd admins are doing.

> Well, the question is "are things wrong" ? AFAICS, they aren't -- and
> when I suggested building a webpage tracking the complaints, the only
> response was "ha, what a waste of time".

Can you explain then why my recent request went unanswered for a
month?

> Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
> but I don't really care if volunteers decline to work with people who're
> obnoxious and rude.

I do.  For some positions in Debian, we need people who will work with
everyone in the project.  When we have set things up so that there is
a single point of failure for a task, it is important to make sure
that one of the skills that single-point has is a very thick skin and
a willingness to work with people who are obnoxious and rude.

If we *cannot* find such a person, we might have to settle for second
best.  But let's look for one first.

> That's not a productive attitude. If they don't have time to answer
> questions, they almost certainly don't have time to ask for help,
> either. 

Hogwash.  What seems to be absent from the mind of the people
responsible is that when they don't have time, they can say "I don't
have time to do this job anymore; I'm sorry, but I really would like
to step down."  

We are a mature project, we can find volunteers for these tasks.
Nobody is doing a task in Debian which only they could do.  Nothing
anyone does is so special and magic that nobody else could figure it
out.

What I think we have is *fiefdoms* in which people have tied their ego
together with "doing" certain tasks, and they are desperate to
continue to control those tasks, even if their ability to do them
efficiently has long since left the building.

I had hope that when we elected the current DPL and DPL team that some
of this would change.  Instead, we have the same damn problem.
Fiefdoms, unaccountability, and DPL inaction.

> It may be rational to note that that conclusion is being irrationally
> drawn, and start responding to hysterical complaints by delaying
> activities that'd otherwise be undertaken, of course. I'm idealistic
> enough to dislike that conclusion, but, well *shrug*.

It is clear that some of the fiefdoms are run by people who adopt this
attitude: "If you criticize me publicly, then I will slow-pedal your
requests."  This is an infantile and counterproductive attempt to
maintain control and a sense of superiority.  It has no place in a
project such as ours.

Thomas


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

thank GOD I found you! How do I get them?

[Adrienne]

iih

Re: cvs loginfo configuration for alioth?

[Russ Allbery]

It seems like folks have found good solutions for their problems already,
but just for the hell of it, I thought I'd mention that I maintain a CVS
commit reporting script mostly because the other ones I'd found didn't
seem to do quite enough or were poorly documented.

It's at:



and while I've not used it specifically with Alioth, I'd be happy to
respond to any reports of issues or requests for additional features.  (I
know the option handling needs some improvement; I plan on rewriting it
shortly to use the same approach that my similar svnlog program for
Subversion uses.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: buildd administration

[Anthony Towns]

On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote:
> Petter Reinholdtsen wrote:
> > > Perhaps it is time for a replacement buildd network, and a new
> > > delegation from the DPL for keyring maintenence?
> Anthony Towns wrote:
> > Whatever for, exactly?
> Transparency.

That's non-sensical. Everything the buildds do is logged pretty much
immediately onto http://buildd.debian.org/, which also provides long
running statistics on how effective the buildds are, and even a schedule
of what the buildds will be working on next.

> When things go wrong, there is no useful contact address for the buildd 
> maintainers or admins. 

Well, the question is "are things wrong" ? AFAICS, they aren't -- and
when I suggested building a webpage tracking the complaints, the only
response was "ha, what a waste of time".

I don't really understand the viewpoint that says fixing the problem
isn't a "response" to pointing out a problem.

> >The buildd network's working better today than
> >it has since woody released, IMO.
> Yes.  I wonder why?  

It started working well in the same week we did the etch requalification
process.

> There's no way to tell what's changed, who's done it, or 
> when it will stop being true.

TTBOMK, porters started taking their ports more seriously.

> Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's 

Ingo's burnt a fair number of bridges wrt buildd issues; I'm sorry,
but I don't really care if volunteers decline to work with people who're
obnoxious and rude.

> To respond preemptively to one expected reply: "I don't have time to answer 
> these questions" is not a reasonable excuse, because if they don't have time, 
> they need to ask for help.

That's not a productive attitude. If they don't have time to answer
questions, they almost certainly don't have time to ask for help,
either. When that cirucmstance has arisen, the only way out is for others
to work out what help's actually needed and wanted and to provide it.
That's kinda hard, but no one promised taking over the world would
be easy.

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

No, it doesn't.

> At least, that's the conclusion that a rational outside observer would come 
> to.

No, it's the conclusion a simplistic outside observer would come to,
who failed to consider the possibility that the results may have come
due to independent processes in spite of the hysterical complaints
on debian-devel.

It may be rational to note that that conclusion is being irrationally
drawn, and start responding to hysterical complaints by delaying
activities that'd otherwise be undertaken, of course. I'm idealistic
enough to dislike that conclusion, but, well *shrug*.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Anthony Towns]

Followups set to -vote; can we please keep this on the list that's
designed for these discussions?

On Thu, Dec 08, 2005 at 11:24:52AM -0300, Daniel Ruoso wrote:
> There's a lot of personal information inside debian-private, 

There is? I got 36 of 494 messages (7%) for the month I did, with an
additional 55 odd spam messages (11%). See master:~ajt/d-p.200211 and
d-p.200211.boring.

I'd love to see a second take on that sort of analysis, either for the
same month or different ones.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Intel notebooks for needy developers in developing countries

[Alejandro Bonilla Beeche]

Andreas Schuldei wrote:


* Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> [2005-12-09 00:30:09]:

 


On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote:
   


Intel is so generous to provide Debian with ten notebooks (besides
some server hardware), which we would like to give to developers
in developing countries who 
 


What exacly did you mean writing about 'developing countries'?
   



i meant countries/persons who can not have a hope of buying a
computer (but only use one in the computer room in their
university or their neighbour's for their debian work) and who's
income is so low that they would need many months savings of
their complete income to be able to afford a cheap one. 


i can try to come up with a list of countries if it helps.
 

Is not about the country. Is the fact that some people can't have the 
option to choose from a $1200 to a $100 computer.  Or maybe, not even that.


Don't generalize by saying the name of a country.

.Alejandro


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

Re: cvs loginfo configuration for alioth?

[Junichi Uekawa]

Hi,

> > > I'm looking for a 'loginfo' file configuration that works 
> > > for alioth.
> > > I thought I have found a solution few days ago, but when 
> > > I came back, it no longer seems to work correctly:
> > > 
> 
> The script used in debian-gis repo (pkg-grass) works like a charm. 
> Feel free to use it... I also looked around a bit to have a working program
> after alioth upgrade.

It seems to come with zero documentation, but the required configuration
seems to be


1. copy the file log_accum.pl into CVSROOT/
2. add the following kind of entry to CVSROOT/loginfo

# default behavior: send commit logs to tokyodebian-commits
DEFAULT $CVSROOT/CVSROOT/log_accum.pl -u $USER %s
# log_accum.pl needs to be added, and checkoutlist be updated


3. edit CVSROOT/log_accum.pl so that it has proper mail address
4. mkdir $CVSROOT/commitlogs (in the repository) for commit logs


It looks like it's working.
Thanks for the info.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: master mail problems -- help needed

[Jeroen van Wolffelaar]

On Thu, Dec 08, 2005 at 10:33:54PM +0100, Florian Weimer wrote:
> * Lionel Elie Mamane:
> 
> > On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote:
> >
> >> The fact that my primary MX is only available through IPv6, and that
> >> this is the case for other people who're having problems too might
> >> then be a better chance at being the problem.
> >
> > My primary MX is IPv6-only, too. I don't have detected a problem yet :)
> 
> Do you receive lots of mail from master.debian.org, and would you
> notice the bounces?  Mail from Debian mailing lists come directly from
> murphy.debian.org, which does not seem to have the problem.
> 
> You also have one IPv4-only MX, which might be enough to prevent the
> Exim bug[1] from occurring.
> 
> [1] I'm not sure if it's a Exim's fault, it's only a hunch.

I've filed #342619 on the strong suspicion something fishy is going on
in exim, even though I don't know for sure what's going on exactly.

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

Re: StrongARM tactics

[Steve Langasek]

On Thu, Dec 08, 2005 at 01:52:51PM +0100, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
> >> [EMAIL PROTECTED] (Aaron M. Ucko) writes:

> >> > Thomas Viehmann <[EMAIL PROTECTED]> writes:

> >> >> +pcsx: i386  # 
> >> >> i386 assembly

> >> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
> >> > unconditionally.

> >> Write patch. At a minimum the package should be "i386 amd64". In
> >> general anything with "Arch: i386" should add amd64.

> > And is that certain to give a working 64-bit binary on amd64, or are you
> > suggesting that we ship extra copies of 32-bit binaries for both i386 and
> > amd64?

> The later if the former is not working. Since we have no multiarch yet
> and acceptance of patches leading up to it is going very slowly it
> looks like etch will remain without multiarch. So we need the extra
> copy to have something working.

And for this you want to add hackish patches to console emulator packages?
I think the amd64 port can live for a while without a Playstation emulator
while we sort out how to cope with cross-installing of i386 packages.

> >> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:
> ...
> >> wanna-build already filters the Architecture field of sources.

> Small correction, quinn-diff does the actual filtering (here).

> > No, it does not.  It goes to the buildds with every sourceful upload, and
> > fails when sbuild checks the architecture list.

> Hmm, must be just me then. Here quinn-diff already filters it out so
> it doesn't reaches wanna-build itself. But that might just be one of
> the several small differences to the official buildd suite.

> [EMAIL PROTECTED]:~/t% quinn-diff 2>&1 | grep pcsx
> [quinn-diff]: ignoring: pcsx has an architecture field of "i386" which
> doesn't include amd64.

Right; it is quinn-diff that does the filtering; and the quinn-diff on
buildd.d.o does not filter on the package-provided Architecture: list.

> Makes no sense to include a source not for this arch.

On the contrary, I think it's a bad idea for quinn-diff to look at package
Architecture: fields directly, just like it would be a bad idea for dak to
let maintainers change Section: values directly.  You want porter oversight
of the list of packages that are being excluded on an arch, and having these
show up as build failures gives you that oversight.

-- 
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: Intel notebooks for needy developers in developing countries

[Andreas Schuldei]

* Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> [2005-12-09 00:30:09]:

> On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote:
> > Intel is so generous to provide Debian with ten notebooks (besides
> > some server hardware), which we would like to give to developers
> > in developing countries who 
> 
> What exacly did you mean writing about 'developing countries'?

i meant countries/persons who can not have a hope of buying a
computer (but only use one in the computer room in their
university or their neighbour's for their debian work) and who's
income is so low that they would need many months savings of
their complete income to be able to afford a cheap one. 

i can try to come up with a list of countries if it helps.


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Goswin von Brederlow]

Ryan Schultz <[EMAIL PROTECTED]> writes:

> On Thursday 08 December 2005 04:41 am, you wrote:
>> [EMAIL PROTECTED] (Aaron M. Ucko) writes:
>> > Thomas Viehmann <[EMAIL PROTECTED]> writes:
>> >> +pcsx: i386# 
>> >> i386 assembly
>> >
>> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
>> > unconditionally.
>>
>> Write patch. At a minimum the package should be "i386 amd64". In
>> general anything with "Arch: i386" should add amd64.
>
> PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even 
> on i386. I don't know about amd64, but my other partially-ASM (using NASM 
> like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that 
> the same is true here -- I'll change it if someone can confirm that it will 
> build and work.

They will if you do it right. Look at lilo, grub or that other
bootloader amd64 has.

Basicaly you just have to use "gcc -m32" for the C/asm code you
compile with gcc. nasm should always make 32bit code I think.

You will need any libs you use (apart from libc6, zlib and a few more
X libs that ia32-libs has already) as 32bit version though, if any. It
probably will need some work to get it to build but it would be worth
it. Ask on debian-amd64 for someone to help porting if you are willing
to support this in the future.

MfG
Goswin


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

Re: Intel notebooks for needy developers in developing countries

[Bartosz Fenski aka fEnIo]

On Thu, Dec 08, 2005 at 09:08:58PM +0100, Andreas Schuldei wrote:
> Intel is so generous to provide Debian with ten notebooks (besides
> some server hardware), which we would like to give to developers
> in developing countries who 

What exacly did you mean writing about 'developing countries'?

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: master mail problems -- help needed

[Lionel Elie Mamane]

On Thu, Dec 08, 2005 at 11:57:58PM +0100, Florian Weimer wrote:
> * Lionel Elie Mamane:

>>> You also have one IPv4-only MX,

>> No, I don't.

> But Exim 4 thinks so:

> [EMAIL PROTECTED]
>   router = dnslookup, transport = remote_smtp
>   host capsaicin.mamane.lu [2001:888:19f0::2]   MX=9
>   host capsaicin.mamane.lu [2001:888:19f0:2::2] MX=9
>   host quorn.mamane.lu [213.84.114.29]  MX=10
>   host tofu.mamane.lu  [2001:888:19f0:0:210:5aff:fe45:9b17] MX=11
>   host a.mx.conuropsis.org [2001:838:300:241::2]MX=30
>   host a.mx.conuropsis.org [217.115.192.216]MX=30

I see.

> My local BIND omits a few  records from the answer to
> mamane.lu/IN/MX to bring it below the 512 byte limit (it may do so,
> after all it's just the addtitional section).  I would have thought
> that Exim queried for  records if necessary, but this seems to
> be wrong.

Well, I've dropped tofu from the MX list now, so maybe quorn's 
record will make it back in (after TTL expires)?

-- 
Lionel


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

Re: master mail problems -- help needed

[Florian Weimer]

* Lionel Elie Mamane:

>> You also have one IPv4-only MX,
>
> No, I don't.

But Exim 4 thinks so:

[EMAIL PROTECTED]
  router = dnslookup, transport = remote_smtp
  host capsaicin.mamane.lu [2001:888:19f0::2]   MX=9
  host capsaicin.mamane.lu [2001:888:19f0:2::2] MX=9
  host quorn.mamane.lu [213.84.114.29]  MX=10
  host tofu.mamane.lu  [2001:888:19f0:0:210:5aff:fe45:9b17] MX=11
  host a.mx.conuropsis.org [2001:838:300:241::2]MX=30
  host a.mx.conuropsis.org [217.115.192.216]MX=30

My local BIND omits a few  records from the answer to
mamane.lu/IN/MX to bring it below the 512 byte limit (it may do so,
after all it's just the addtitional section).  I would have thought
that Exim queried for  records if necessary, but this seems to be
wrong.


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

Re: master mail problems -- help needed

[Lionel Elie Mamane]

On Thu, Dec 08, 2005 at 10:33:54PM +0100, Florian Weimer wrote:
> * Lionel Elie Mamane:
>> On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote:

>>> The fact that my primary MX is only available through IPv6, and
>>> that this is the case for other people who're having problems too
>>> might then be a better chance at being the problem.

>> My primary MX is IPv6-only, too. I don't have detected a problem yet :)

> Do you receive lots of mail from master.debian.org,

I don't think so.

> and would you notice the bounces?

I wouldn't get bounces, people sending me mail on [EMAIL PROTECTED]
would.

> You also have one IPv4-only MX,

No, I don't.

-- 
Lionel


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

Re: Intel notebooks for needy developers in developing countries

[Lucas Fernandes]

I can´t belive... this is true...2005/12/8, Andreas Schuldei <[EMAIL PROTECTED]>:
Intel is so generous to provide Debian with ten notebooks (besidessome server hardware), which we would like to give to developersin developing countries who- are technically able,- are dedicated to Debian,
- would be able to contribute more/better to Debian with this  hardware- would not be able to afford a computer, otherwise.If you know such a person, please let me know ASAP. I would liketo have recommendations from others about this person and would
need a list of things that person works on in Debian. Given thethin web of trust in those parts of the world it would not berequired for this person to be a Debian Developer, eventhough itwould help.
The shipment would happen domestically, so no customs would needto be payed. Please provide the full shipping address, along withthe recommendation.If we receive more then ten recommendations (which i hope for)
the Intel representative responsible for Debian would select thereceipients of the notebooks.-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (GNU/Linux)iD8DBQFDmJLa8g+sC3uDV+URAjlvAJ9HYugEki5cp5Nwu5Fa2tCdbnShBgCfQEx4
BUj8jNX7sLnlgEwImLNTxkI==tCBO-END PGP SIGNATURE--- ICQ 156652591lucas souza fernandes

Re: buildd administration

[Nathanael Nerode]

CC:ing you because this is sufficiently important I want to make sure you 
notice that I'm actually answering what may have been a rhetorical question.

>What problems are there today with buildd administration, please?
No clearly-documented contact addresses for buildd administrators (as noted 
upthread).  Mail to any of the apparent contact addresses receives no 
replies.  Accordingly, there is no way to tell whether a message has been 
heard.  If a package is requeued (or whatever) there is no way to tell which 
of the several addresses you sent mail to had an effect, or if it happened on 
its own.  If nothing happens, there is no way to tell whether your mail was 
lost in transit, or whether the buildd administrator retried it and found 
some problem without telling you, or whether the package is in some kind of 
dependency-wait state for reasons you don't know about.  This lack of 
transparency and lack of contact addresses is particularly annoying for 
packages which have built and not been uploaded, which should be trivial to 
deal with, but aren't.

Plus, no useful contact address for buildd.debian.org, and effectively no way 
to get any improved scripts moved onto it.

That enough problems for you?  :-P

Contrast to the incredibly transparent operations of debian-release, or the 
ease of getting patches added to the PTS (packages.qa.debian.org) scripts.  
Or indeed the less-transparent but still fairly responsive BTS maintainers.

It is of course possible that for you, all the correct email addresses are 
known, and all the people at them reply to you.  If so, please know that that 
is not how it is working for most people.  The only replies I've ever 
received from contacting (what I thought was) a buildd admin address were 
"Sorry, I'm not the buildd admin".

Apologies for the thread-breaking, I'm reading on the web pages again.  :-/

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

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


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

Re: buildd administration

[Nathanael Nerode]

Petter Reinholdtsen wrote:
> > Perhaps it is time for a replacement buildd network, and a new
> > delegation from the DPL for keyring maintenence?

Anthony Towns wrote:
> Whatever for, exactly?
Transparency.

You understand transparency, I know, since you practice a great deal of 
transparency in your own Debian work, as is clear from your blog.  Many kudos 
to you for that.  Another developer who practices transparency to a great 
degree is Steve Langasek, who *always* seems to have time to answer a 
question -- or even to respond to a comment, which is actually more than is 
needed.

When things go wrong, there is no useful contact address for the buildd 
maintainers or admins.  There is also no feedback from buildd 
maintainers/admins or keyring maintainers regarding whether a request has 
been receieved.  It's like dropping wishes into a wishing well and then 
waiting to see whether they come true.  The fact that the wishing well 
appears to be working unusually well at the moment is almost beside the 
point.

>The buildd network's working better today than
>it has since woody released, IMO.
Yes.  I wonder why?  There's no way to tell what's changed, who's done it, or 
when it will stop being true.

Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's 
much-much-better buildd.net status scripts.  For no apparent reason.  Certain 
buildd admins aren't cooperating with the buildd status lines on that site 
either.  For no apparent reason.  There's nobody to contact to explain why, 
because the contact points for these things act like wishing wells.

To respond preemptively to one expected reply: "I don't have time to answer 
these questions" is not a reasonable excuse, because if they don't have time, 
they need to ask for help.  If they don't think that anyone is skilled or 
trustworthy enough to help with the work they're already doing, then (a) 
they're probably wrong, and (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 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.  If that's an inaccurate conclusion, it indicates that there's something 
seriously wrong in the transparency of the processes.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

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


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

Re: buildd administration

[Nathanael Nerode]

Michael Banck wrote:
>The main problem of the arm port is *not* the buildd maintenance, but
>rather the lack of people fixing actual bugs, which is *not* the job of
>the buildd admin but of the porters.
Saying it doesn't make it true.

In fact, people who have volunteered to diagnose bugs in the past -- 
specifically Thomas Bushnell BSD -- have stated that they have become 
dispirited and unwilling to do so *because* of the behavior of the buildd 
maintainers; to wit, ignoring their diagnosis work.  So, provide better 
evidence for your claim please.

>Unfortunately, you do not seem to trust James' opinion on this, but why
>do you not trust our beloved Release Manager, either, who said he knew
>of no serious issues with buildd maintenance right now?
Why should either of them know, to be perfectly frank?  This is argument by 
authority, not an actual argument.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

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


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

Re: buildd administration

[Ingo Juergensmann]

On Thu, Dec 08, 2005 at 10:32:40PM +0100, Frank Küster wrote:

> > Feature requests and other things are always welcome! I can't know what you
> > want until you tell it to me. ;)
> Nothing - these the questions I was mainly interested in regarding
> buildd's:
> - is my package already built everywhere, so that it can go into
>   testing? 
> - did it FTBFS, and do the logs give indication why?
> - How can I get information from "inside" a buildd, e.g. temporary files
>   created during a failed build.
> The first two can be answered without buildd.net (and actually I never
> was very much interested in "so when will it be built"?), the latter
> needs, well, a buildd admin must contact me...

A buildd admin doesn't see much more than what you can see in the build
logs. Basically the build logs is all a buildd admin see. 

-- 
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: master mail problems -- help needed

[Florian Weimer]

* Lionel Elie Mamane:

> On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote:
>
>> The fact that my primary MX is only available through IPv6, and that
>> this is the case for other people who're having problems too might
>> then be a better chance at being the problem.
>
> My primary MX is IPv6-only, too. I don't have detected a problem yet :)

Do you receive lots of mail from master.debian.org, and would you
notice the bounces?  Mail from Debian mailing lists come directly from
murphy.debian.org, which does not seem to have the problem.

You also have one IPv4-only MX, which might be enough to prevent the
Exim bug[1] from occurring.

[1] I'm not sure if it's a Exim's fault, it's only a hunch.


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

Re: buildd administration

[Frank Küster]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:

>> > I think that people should choose theirselves what they think is the
>> > best resource for them to find the needed information...  ;)
>> I do think that too, but in order to allow that those resources must be
>> made public.  I haven't found buildd.net useful for me in the past,
>
> Feature requests and other things are always welcome! I can't know what you
> want until you tell it to me. ;)

Nothing - these the questions I was mainly interested in regarding
buildd's:

- is my package already built everywhere, so that it can go into
  testing? 

- did it FTBFS, and do the logs give indication why?

- How can I get information from "inside" a buildd, e.g. temporary files
  created during a failed build.


The first two can be answered without buildd.net (and actually I never
was very much interested in "so when will it be built"?), the latter
needs, well, a buildd admin must contact me...

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

Re: master mail problems -- help needed

[Lionel Elie Mamane]

On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote:

> The fact that my primary MX is only available through IPv6, and that
> this is the case for other people who're having problems too might
> then be a better chance at being the problem.

My primary MX is IPv6-only, too. I don't have detected a problem yet :)

-- 
Lionel


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

Re: master mail problems -- help needed

[Wouter Verhelst]

On Thu, Dec 08, 2005 at 03:00:58PM +0100, Romain Francoise wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > That's on master. I've been watching it for about 5 minutes, and never
> > saw the load drop below 3.80-ish.
> 
> > Could it be that master is simply imploding on the amount of mail
> > received?
> 
> It's always been like that (if not worse).

Not that I recall. But then, I'm not really all that familiar with
master, so let's assume it's indeed something else.

The fact that my primary MX is only available through IPv6, and that
this is the case for other people who're having problems too might then
be a better chance at being the problem.

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


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

circular (source) dependencies!?

[Turbo Fredriksson]

I'm trying to build autoconf/automake on my semi woody...

But that isn't going to well (to say the least). I really
hate these two programs. It's always a mess to build them
if you don't follow the latest and greatest (probably no
faults to the maintainers though!)...

Any idea how to get around this (easily)? Can this be fixed
in the packages?

- s n i p -
Aurora/WOODY# debuild -uc -us -sa
dpkg-buildpackage: source package is automake1.8
dpkg-buildpackage: source version is 1.8.5-3
dpkg-buildpackage: source maintainer is Eric Dorland <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture is sparc
dpkg-checkbuilddeps: Unmet build dependencies: autoconf (>= 2.59), debhelper (>\
= 4.1.0), texinfo (>= 4.2)
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
debuild: fatal error at line 456:
dpkg-buildpackage failed!


Aurora/WOODY# debuild -uc -us -sa
dpkg-buildpackage: source package is autoconf
dpkg-buildpackage: source version is 2.59a-7
dpkg-buildpackage: source maintainer is Ben Pfaff <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture is sparc
dpkg-checkbuilddeps: Unmet build dependencies: texinfo (>= 4.6), automake1.9
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
debuild: fatal error at line 456:
dpkg-buildpackage failed!


Aurora/WOODY# debuild -uc -us -sa
dpkg-buildpackage: source package is automake1.9
dpkg-buildpackage: source version is 1.9.6-1
dpkg-buildpackage: source maintainer is Eric Dorland <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture is sparc
dpkg-checkbuilddeps: Unmet build dependencies: autoconf (>= 2.59), debhelper (>\
= 4.1.0), texinfo (>= 4.2)
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
debuild: fatal error at line 456:
dpkg-buildpackage failed!
- s n i p -
-- 
North Korea 767 explosion Ortega Clinton class struggle attack [Hello
to all my fans in domestic surveillance] Rule Psix kibo security 747
BATF Saddam Hussein CIA
[See http://www.aclu.org/echelonwatch/index.html for more about this]
[Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf]
If neither of these works, try http://www.aclu.org and search for echelon.


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

Re: Mailing list administration - add default Mail-Followup-To automatically

[Glenn Maynard]

On Thu, Dec 08, 2005 at 07:36:34PM +0100, Simon Josefsson wrote:
> >   When using the Debian mailing lists, please follow these rules:
> >   . When replying to messages on the mailing list, do not send a
> > carbon copy (CC) to the original poster unless they explicitly
> > request to be copied.

> Couldn't the list manager add the proper Mail-Followup-To, if it is
> not already present?  I'm reading this mailing list through gmane.org.
> It is not scalable to manually check all the rules of various groups,
> even if doing so would be courteous.

Maybe; I don't know if that would cause any problems.  In case anyone
thinks this is a good idea and wants to implement it (or if anyone less
ambivalent than me wants to push for it), I'll CC to d-devel.

> That rule is problematic if non-members post to the list, either
> directly or accidentally by participating in a cross-posted
> discussion.

I think people tend to give more leeway when a discussion is being cross-
posted and they get unwanted CCs.  (People are usually busy just making
sure the conversation stays on both lists.)

It's a more reasonable default on most lists: usually, most people in a
discussion are subscribed.  It makes more sense to me to require that the
few people posting to a list unsubscribed set a header saying so, than
the majority of people posting subscribed do so.

-- 
Glenn Maynard


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

Re: StrongARM tactics

[Ryan Schultz]

On Thursday 08 December 2005 01:44 pm, Aaron M. Ucko wrote:
> Ryan Schultz <[EMAIL PROTECTED]> writes:
> > PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified,
> > even on i386. I don't know about amd64, but my other partially-ASM (using
> > NASM like PCSX) package (libopenspc) will not build on amd64, so I'm
> > assuming that the same is true here -- I'll change it if someone can
> > confirm that it will build and work.
>
> It built on my AMD64 system with a crude patch (attached, along with
> the resulting log) that drops the CPU setting unconditionally, but I
> haven't actually tested the result -- I built it mainly because I'm a
> packrat. ;-)

I can't get a clean pdebuild[1] on i386 with that setting dropped, which seems 
unusual -- it fails during linking. I'll hack something up for the rules 
file, in any case, and contact my sponsor; I have a new upload ready anyway.

[1]
../PsxMem.o: In function `psxMemWrite8':PsxMem.c:(.text+0x530): undefined 
reference to `psxRecLUT'
../PsxMem.o: In function `psxMemWrite16':PsxMem.c:(.text+0x5b1): undefined 
reference to `psxRecLUT'
../PsxMem.o: In function `psxMemWrite32':PsxMem.c:(.text+0x656): undefined 
reference to `psxRecLUT'
:PsxMem.c:(.text+0x691): undefined reference to `psxRecLUT'
../Misc.o: In function `RecvPcsxInfo':Misc.c:(.text+0x1856): undefined 
reference to `psxRec'
../R3000A.o: In function `psxInit':R3000A.c:(.text+0x1c): undefined reference 
to `psxRec'
Gtk2Gui.o: In function `OnCpu_Ok':Gtk2Gui.c:(.text+0x1af6): undefined 
reference to `psxRec'

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


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

Re: buildd administration

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Er, did you even *read* this thread?  We got on the topic of buildds because
> *someone refused to help diagnose build failures because they consider it the
> buildd admin's job*.  

NO.  We got on the topif of this because I said that I was not
interested in diagnosing build failures, since when I had done so in
the past, my diagnoses seemed to be ignored, and the diagnosing seems
to have been entirely wasted work.


Thomas


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

Re: buildd administration

[Ingo Juergensmann]

On Thu, Dec 08, 2005 at 06:45:09PM +0100, Frank Küster wrote:

> >> http://bugs.debian.org/342548
> >> Why hasn't that been done before?  Where else should this be documented? 
> > Well, Steve wrote lately about the [EMAIL PROTECTED] mails:
> > "AIUI, the @buildd.debian.org addresses have a ridiculously low S:N
> > ratio due to spam; 
> This is a problem, but IMO not a justification for simply saying: No, we
> don't provide any contact address.

Sure, there's always something that is not as well documented as it should
be... ;)

> > moreover, they already receive build logs for each failed
> > package build, and are generally quite capable of figuring out the source of
> > a failure on their own, so receiving a second mail about a failure that's
> > still in their inbox isn't necessarily all that useful."
> That's a problem either of educating the people that want to contact
> buildd admin's (to only do it when necessary), or of having enough
> persons behind that role account [EMAIL PROTECTED]  Remember that we all
> receive superfluos mails as maintainers, like "Hey, I also found out
> that your package cannot be installed, and I'm the 3rd one of them who
> doesn't check whether a bug has already been filed".  I assume if
> appropriate information is available, people caring about buildd
> failures are more likely to understand when it's time to contact the
> buildd admin, then random users when to report a bug.

That's one part I try to achieve with buildd.net: to give as much
information as possible about the buildd process. The main focus is the
buildd itself: is it down, when will be "my" package built, etc... 
When you do a package search on buildd.net there are some links to other
sites to give you easy access to even more information. 
If someone writes a nice paper about buildds, common problems or such (or
sends me a pointer to such things), I'll happily include that on buildd.net. 
 
> Moreover, even if the admins are capable to figure out problems on their
> own, the maintainer and porters also deserve information.  It's
> demotivating to not get any response when you ask for help a couple of
> times, try to reproduce the error in your environment without success,
> and not even be notified how the problem has finally been solved by the
> buildd admin.

True. There is much space for improvements on both sides.

> >> > Another possible resource might be http://www.buildd.net/  ;) - I 
> >> > try
> >> > to keep the information there as uptodate as possible, but it depends on 
> >> > the
> >> > will to cowork with the buildd admins/porters, too. 
> >> Ah, that's even better, there's actual names behind the buildd's.  I'll
> >> add that to the patch.
> > OTOH, some people seem to disagree with you: 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142
> I don't understand - this was about adding a link to buildd net to
> developer.php, I'm talking about documenting buildd admin's contact
> addresses in intro/organization.  

Well, I was aiming towards the point that some persons might dislike me and
therefore refuse to add links to buildd.net. ;)

> > I think that people should choose theirselves what they think is the
> > best resource for them to find the needed information...  ;)
> I do think that too, but in order to allow that those resources must be
> made public.  I haven't found buildd.net useful for me in the past,

Feature requests and other things are always welcome! I can't know what you
want until you tell it to me. ;)

> either, but I didn't know that it's the only place to get the names and
> e-mail of buildd admin's.

I would be happy when I could get updates about buildds, buildd admins and
such from time to time. Information is only good when it is acurate and
uptodate. Take the machines.cgi on db.d.o for example. It is quite often
outdated, which is why I tried to work around that problem by using dynamic
status updates via a small scripts from the buildds. But that's a different
story. The point is: when someone knows the information on buildd.net is
wrong, please let me know!

>  The latter information should be available at
> some other place than buildd.net itself; maybe not only
> intro/organization, but also the developer's reference. 

After a talk with Christoph Berg, we agreed that I'll add (somewhen ;)
a new search page on buildd.net that will be linked on the developer.php
page. 

-- 
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: StrongARM tactics

[Aaron M. Ucko]

Ryan Schultz <[EMAIL PROTECTED]> writes:

> PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even 
> on i386. I don't know about amd64, but my other partially-ASM (using NASM 
> like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that 
> the same is true here -- I'll change it if someone can confirm that it will 
> build and work.

It built on my AMD64 system with a crude patch (attached, along with
the resulting log) that drops the CPU setting unconditionally, but I
haven't actually tested the result -- I built it mainly because I'm a
packrat. ;-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

diff -u pcsx-1.6df/debian/control pcsx-1.6df/debian/control
--- pcsx-1.6df/debian/control
+++ pcsx-1.6df/debian/control
@@ -6,7 +6,7 @@
 Standards-Version: 3.6.2
 
 Package: pcsx
-Architecture: i386
+Architecture: any
 Depends: ${shlibs:Depends}
 Recommends: psemu-sound, psemu-input, psemu-drive, psemu-video
 Description: Sony PlayStation emulator
diff -u pcsx-1.6df/debian/changelog pcsx-1.6df/debian/changelog
--- pcsx-1.6df/debian/changelog
+++ pcsx-1.6df/debian/changelog
@@ -1,3 +1,12 @@
+pcsx (1.6df-1.0) unstable; urgency=low
+
+  * NMU of sorts (though no actual upload intended.)
+  * debian/control: Change architecture from i386 to any.
+  * Linux/Makefile: don't force CPU to ix86 (should be done conditionally
+in debian/rules).
+
+ -- Aaron M. Ucko <[EMAIL PROTECTED]>  Mon, 28 Nov 2005 10:42:36 -0500
+
 pcsx (1.6df-1) unstable; urgency=low
 
   * Initial release Closes: #137355
only in patch2:
unchanged:
--- pcsx-1.6df.orig/Linux/Makefile
+++ pcsx-1.6df/Linux/Makefile
@@ -7,7 +7,7 @@
 
 all: pcsx
 
-CPU = ix86
+# CPU = ix86
 
 OPTIMIZE = -O2 -fomit-frame-pointer -finline-functions -ffast-math
 FLAGS = -D__LINUX__ -DPCSX_VERSION=\"${VERSION}\" -DPACKAGE=\"pcsx\"
dpkg-buildpackage: source package is pcsx
dpkg-buildpackage: source version is 1.6df-1.0
dpkg-buildpackage: source changed by Aaron M. Ucko <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strip... strip
checking for rm... rm
checking for rmdir... rmdir
checking gtk+2... checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2.0 > 2.0.0... yes
checking GTK_CFLAGS... -DXTHREADS -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  
checking GTK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm 
-lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 
-lgmodule-2.0 -ldl -lglib-2.0  
configure: creating ./config.status
config.status: creating Makefile.cfg
touch configure-stamp
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && /usr/bin/make clean
make[1]: Entering directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
rm -f Makefile.cfg
rm -f *.o ../*.o ..//*.o pcsx
rm -f config.*
make[1]: Leaving directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
dh_clean 
 dpkg-source -i -b pcsx-1.6df
dpkg-source: building pcsx using existing pcsx_1.6df.orig.tar.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.diff.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.dsc
 debian/rules build
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking f

Re: StrongARM tactics

[Ryan Schultz]

On Thursday 08 December 2005 04:41 am, you wrote:
> [EMAIL PROTECTED] (Aaron M. Ucko) writes:
> > Thomas Viehmann <[EMAIL PROTECTED]> writes:
> >> +pcsx: i386 # 
> >> i386 assembly
> >
> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
> > unconditionally.
>
> Write patch. At a minimum the package should be "i386 amd64". In
> general anything with "Arch: i386" should add amd64.

PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even 
on i386. I don't know about amd64, but my other partially-ASM (using NASM 
like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that 
the same is true here -- I'll change it if someone can confirm that it will 
build and work.

-- 
Ryan Schultz
YOU RPN LOVE IF THEN HONK


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

Re: buildd administration

[Frank Küster]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 08, 2005 at 04:35:14PM +0100, Frank Küster wrote:
>
>> >> > What problems are there today with buildd administration, please?
>> >> One obvious problem is that there is no documented contact address (just
>> >> search for "buildd" on http://www.debian.org/intro/organization).  One
>> >> has to know by some magic who is responsible for which architecture.
>> > Well, there are mail aliasses for each arch following the
>> > [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside
>> > that sometimes problems seem to just go away silently ;)). 
>> http://bugs.debian.org/342548
>> Why hasn't that been done before?  Where else should this be documented? 
>
> Well, Steve wrote lately about the [EMAIL PROTECTED] mails:
> "AIUI, the @buildd.debian.org addresses have a ridiculously low S:N
> ratio due to spam; 

This is a problem, but IMO not a justification for simply saying: No, we
don't provide any contact address.

> moreover, they already receive build logs for each failed
> package build, and are generally quite capable of figuring out the source of
> a failure on their own, so receiving a second mail about a failure that's
> still in their inbox isn't necessarily all that useful."

That's a problem either of educating the people that want to contact
buildd admin's (to only do it when necessary), or of having enough
persons behind that role account [EMAIL PROTECTED]  Remember that we all
receive superfluos mails as maintainers, like "Hey, I also found out
that your package cannot be installed, and I'm the 3rd one of them who
doesn't check whether a bug has already been filed".  I assume if
appropriate information is available, people caring about buildd
failures are more likely to understand when it's time to contact the
buildd admin, then random users when to report a bug.

Moreover, even if the admins are capable to figure out problems on their
own, the maintainer and porters also deserve information.  It's
demotivating to not get any response when you ask for help a couple of
times, try to reproduce the error in your environment without success,
and not even be notified how the problem has finally been solved by the
buildd admin.

>> > Another possible resource might be http://www.buildd.net/  ;) - I try
>> > to keep the information there as uptodate as possible, but it depends on 
>> > the
>> > will to cowork with the buildd admins/porters, too. 
>> Ah, that's even better, there's actual names behind the buildd's.  I'll
>> add that to the patch.
>
> OTOH, some people seem to disagree with you: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142

I don't understand - this was about adding a link to buildd net to
developer.php, I'm talking about documenting buildd admin's contact
addresses in intro/organization.  

> I think that people should choose theirselves what they think is the
> best resource for them to find the needed information...  ;)

I do think that too, but in order to allow that those resources must be
made public.  I haven't found buildd.net useful for me in the past,
either, but I didn't know that it's the only place to get the names and
e-mail of buildd admin's.  The latter information should be available at
some other place than buildd.net itself; maybe not only
intro/organization, but also the developer's reference. 

Regards, Frank

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

Processed: reassign 342571 to libapache-mod-php4

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 342571 libapache-mod-php4
Bug#342571: general: Apache1.3 and mod-php4: getlastmod() is broken
Bug reassigned from package `general' to `libapache-mod-php4'.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#342571: general: Apache1.3 and mod-php4: getlastmod() is broken

[Thomas Hooge]

Package: general
Severity: normal

getlastmod() returns always the current time, filemtime() works as
expected. php.net says:
>Apache and PHP have been compiled with the same value for 
>-DFILE_OFFSET_BITS
Perhaps this is the reason?

-- System Information:
Debian Release: 3.1
Architecture: i386 (i586)
Kernel: Linux 2.4.27
Locale: LANG=de_DE, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968)


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

Re: buildd administration

[Ingo Juergensmann]

On Thu, Dec 08, 2005 at 04:35:14PM +0100, Frank Küster wrote:

> >> > What problems are there today with buildd administration, please?
> >> One obvious problem is that there is no documented contact address (just
> >> search for "buildd" on http://www.debian.org/intro/organization).  One
> >> has to know by some magic who is responsible for which architecture.
> > Well, there are mail aliasses for each arch following the
> > [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside
> > that sometimes problems seem to just go away silently ;)). 
> http://bugs.debian.org/342548
> Why hasn't that been done before?  Where else should this be documented? 

Well, Steve wrote lately about the [EMAIL PROTECTED] mails:
"AIUI, the @buildd.debian.org addresses have a ridiculously low S:N
ratio due to spam; moreover, they already receive build logs for each failed
package build, and are generally quite capable of figuring out the source of
a failure on their own, so receiving a second mail about a failure that's
still in their inbox isn't necessarily all that useful."
(http://lists.debian.org/debian-release/2005/12/msg00021.html)

> > Another possible resource might be http://www.buildd.net/  ;) - I try
> > to keep the information there as uptodate as possible, but it depends on the
> > will to cowork with the buildd admins/porters, too. 
> Ah, that's even better, there's actual names behind the buildd's.  I'll
> add that to the patch.

OTOH, some people seem to disagree with you: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265142

I think that people should choose theirselves what they think is the
best resource for them to find the needed information...  ;)

-- 
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: StrongARM tactics

[Martijn van Oosterhout]

2005/12/8, Goswin von Brederlow <[EMAIL PROTECTED]>:
Anthony Towns  writes:What is required is abuildd-give-back package_version(or whatever you called the alias for wanna-build --give-back).

Following this train of thought, wouldn't it be reasonable to have a control @ buildd.debian.net that took simple commands like:

give-back  

It could accept any email signed by a debian maintainer. Basic stuff
like this is doesn't need to be restricted to just a few people.

Re: buildd administration

[Frank Küster]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 08, 2005 at 01:39:27PM +0100, Frank Küster wrote:
>
>> > What problems are there today with buildd administration, please?
>> One obvious problem is that there is no documented contact address (just
>> search for "buildd" on http://www.debian.org/intro/organization).  One
>> has to know by some magic who is responsible for which architecture.
>
> Well, there are mail aliasses for each arch following the
> [EMAIL PROTECTED] scheme, but don't expect miracles from it (beside
> that sometimes problems seem to just go away silently ;)). 

http://bugs.debian.org/342548

Why hasn't that been done before?  Where else should this be documented? 

> Another possible resource might be http://www.buildd.net/  ;) - I try
> to keep the information there as uptodate as possible, but it depends on the
> will to cowork with the buildd admins/porters, too. 

Ah, that's even better, there's actual names behind the buildd's.  I'll
add that to the patch.

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

Re: buildd administration [was Re: StrongARM tactics]

[Thomas Viehmann]

Steve Langasek wrote:
> Er, did you even *read* this thread?  We got on the topic of buildds because
> *someone refused to help diagnose build failures because they consider it the
> buildd admin's job*.

Maybe it's not entirely impossible that the other subthread starting at

| Wonderful.  Nice to see that you think P-a-s entries are somebody
| else's problem that should be "handled centrally".

and containing a few reports similar to Thiemo's

| FWIW, I started to send mips patches for P-a-s, following the
| procedure outlined at the top of this file. There was neither a
| response nor any other discernable action.

could have contributed to the "buildd administration" complaints?

The reaction to my (admittedly less than optimal) attempt at an analysis
that followed was not "oh, do check these with porters and maintainers
and then get back to me" from someone who could then change the file,
but half dozen people saying something to the effect "I'm a
porter/maintainer and were utterly unsucessful at my attempts to get
anything done".
I do appreciate your comments of proposed P-a-s additions that you think
problematic but the rest of the thread rather spells "don't bother".

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Bug#342547: ITP: asterisk-prompt-es -- Spanish prompts for the Asterisk PBX

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva <[EMAIL PROTECTED]>


* Package name: asterisk-prompt-es
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : Spanish prompts for the Asterisk PBX

These are Spanish voicemail prompts for use with the Asterisk PBX,
courtesy of Capatres Company.
 
-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (900, 'stable'), (400, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-386
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)


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

Re: buildd administration

[Josselin Mouette]

Le jeudi 08 décembre 2005 à 14:38 +0100, Michael Banck a écrit :
> Unfortunately, you do not seem to trust James' opinion on this, but why
> do you not trust our beloved Release Manager, either, who said he knew
> of no serious issues with buildd maintenance right now?

Maybe because release managers said the same thing just before the
expected sarge release, which was delayed several extra weeks because
the security buildd network wasn't ready?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: buildd administration

[Anthony Towns]

On Thu, Dec 08, 2005 at 01:01:10PM +0100, Petter Reinholdtsen wrote:
> [Josselin Mouette]
> > I started my implication in the project four years ago. For four
> > years, there have been problems with keyring maintenance and buildd
> > administration. For four years, people responsible for these tasks
> > have refused help on these matters. For four years, everything that
> > was suggested on these topics haven't lead to any result, because
> > these same people have simply ignored the suggestions. Can someone
> > tell me when this nightmare is going to end?

Uh, except for arm, m68k and hurd-i386; all the ports have sustained
over 98% up-to-dateness for almost the entirety of the past month -- that was
the major issue that made the Vancouver Nybbles document limit release
architectures to i386, ppc and ia64. 

Steve's recent binNMUs of KDE for library transitions has pushed that
down to 97% for a couple of architectures, and 96% for hppa, but if you
go back just a few months, ia64, sparc, alpha, and s390 were all having
problems staying above 95%, which has been the cut-off for consideration
in testing for years now, with hppa even dropping below 90%.

If you want the nightmare to end, I'd suggest you try opening your eyes.

> Perhaps it is time for a replacement buildd network, and a new
> delegation from the DPL for keyring maintenence?

Whatever for, exactly? The buildd network's working better today than
it has since woody released, IMO. 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.

Cheers,
aj



signature.asc
Description: Digital signature

Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Daniel Ruoso]

Em Qui, 2005-12-08 às 08:07 +0100, Lionel Elie Mamane escreveu:
> On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote:
> > On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> >> The first type of publication could embrace the entire content of
> >> debian-private, but restrictions will be applied for those who want
> >> to read, basically, the need of identification of the reader and
> >> the agreement to a NDA on the same terms applied to every debian
> >> developer about the privacy of the mailing list.
> Well, if we let anybody read it, it has absolutely no point asking for
> an NDA. Your proposal says that anybody can get read it, if he signs
> an NDA. This procedure could be a useful tool if we restricted it to,
> say, people like Biella Coleman that have a "real use", sanctioned by
> Debian and all, out of the_whole_ archive. (This should not keep us
> from opening up nearly everything else.)

Well, I just wanted to keep my hands off judging for who we want to show
it, I'm just saying "hey, if you want to read, you can, as long as you
respect the privacy of the mailing-list as every debian developer".

But I want to remember that there is still the second form of
publication, in which we select which content will be made public, and
this will be available to anonymous readers.

> >> I hope this is closer to a consensus...
> > Afraid not. This proposal basically creates a second class of people
> > -- those who we want to sign NDA's to be able to read stuff.
> > That's even further away from 'openness and transparency' than the
> > status quo. The idea that developers sometimes have private things
> > to say is at least defendable; the idea that Debian is joining the
> > NDA crap is not, IMNSHO.
> NDA's have a bad reputation in our community; sometimes they make
> sense. They are just a formal version of "yes, I understand the
> information I get is confidential; I will treat it as such". I think
> it makes sense for very selected readers that have a good use of the
> whole archive. It is indeed a bit silly if anyone can just sign it and
> get access.

Why? I'm just saying it will be kept private, I mean, not going to be
indexed by google, not appearing in a newspaper and, this way,
protecting the authors.

daniel


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

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Daniel Ruoso]

Em Qui, 2005-12-08 às 01:39 +0100, Wouter Verhelst escreveu:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> > I hope this is closer to a consensus...
> Afraid not. This proposal basically creates a second class of people --
> those who we want to sign NDA's to be able to read stuff.

Well, if you're going to get access to information that if published
could damage people, that's not surprise. There's a lot of personal
information inside debian-private, which can be usefull for someone
doing a research, but even then, should not be available to general
public.

> That's even further away from 'openness and transparency' than the
> status quo. The idea that developers sometimes have private things
> to say is at least defendable; the idea that Debian is joining the NDA
> crap is not, IMNSHO.

Well, Debian Developers today agree to a non-formal NDA about
debian-private. I'm just suggesting that this could be extended for
others who want to get access to the debian-private archive.

daniel


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

Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Daniel Ruoso]

Em Qui, 2005-12-08 às 00:08 +0100, Gaudenz Steinlin escreveu:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> > The first type of publication could embrace the entire content of
> > debian-private, but restrictions will be applied for those who want to
> > read, basically, the need of identification of the reader and the
> > agreement to a NDA on the same terms applied to every debian developer
> > about the privacy of the mailing list.
> One of the main goals of the original GR was to make the archives
> available for research. How will you be able to publish the results 
> of such research if you agreed to an NDA. One of the main principles
> of scientific research is to make your results reproducible by others.  
> This is impossible if you base your research on data which is only
> available under an NDA.

As a Social Scientist, I must say that it's completely normal to make
researchs using confidential resources. This only tells you that you
should respect the privacy, but still lets you understand better the
object of your research.

daniel


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

Re: buildd administration

[Michael Banck]

On Thu, Dec 08, 2005 at 01:01:10PM +0100, Petter Reinholdtsen wrote:
> [Josselin Mouette]
> > I started my implication in the project four years ago. For four
> > years, there have been problems with keyring maintenance and buildd
> > administration. For four years, people responsible for these tasks
> > have refused help on these matters. For four years, everything that
> > was suggested on these topics haven't lead to any result, because
> > these same people have simply ignored the suggestions. Can someone
> > tell me when this nightmare is going to end?
> 
> Perhaps it is time for a replacement buildd network, and a new
> delegation from the DPL for keyring maintenence?

Anything else, while we're at it?

Maybe you have missed something, so let's reiterate:

The main problem of the arm port is *not* the buildd maintenance, but
rather the lack of people fixing actual bugs, which is *not* the job of
the buildd admin but of the porters.

(as Steve pointed out, in some cases those sets overlap, but that just
means the buildd guy gets to fix bugs with his porter hat on)

I guess nobody says the buildd network does not have any issues, but
they wane when compared to the lack of porting. 

Unfortunately, you do not seem to trust James' opinion on this, but why
do you not trust our beloved Release Manager, either, who said he knew
of no serious issues with buildd maintenance right now?


Now, for the keyring stuff, please post to -project, as this is seems to
be off-topic here.


thanks,

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]

Re: buildd administration

[Michael Banck]

On Thu, Dec 08, 2005 at 02:04:28PM +0100, Goswin von Brederlow wrote:
> Rescheduling a job that failed with a missing build-depends is the
> buildd admins job. Only people with wanna-build access can do that.

Correct, and the release managers don't consider this to be a problem at
the moment.

So nothing to see here, please move along.


kthxbye,

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]

Re: master mail problems -- help needed

[Romain Francoise]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> That's on master. I've been watching it for about 5 minutes, and never
> saw the load drop below 3.80-ish.

> Could it be that master is simply imploding on the amount of mail
> received?

It's always been like that (if not worse).

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: master mail problems -- help needed

[Wouter Verhelst]

On Sat, Nov 26, 2005 at 04:39:46PM +0100, Jeroen van Wolffelaar wrote:
> When an exim mailserver is really bogged down under mail load, attempts
> can be made even less often.

It's ben pointed out to me that my mail through master is also bouncing
at times. I also have an IPv6 MX, so it could be related. However,
another datapoint (and relevant to the above):

top - 07:38:12 up 293 days, 15:52,  8 users,  load average: 5.92, 5.39, 5.12
Tasks: 288 total,   6 running, 280 sleeping,   1 stopped,   1 zombie
Cpu(s):  29.9% user,  18.9% system,   0.5% nice,  50.7% idle
Mem:   2069780k total,  1981968k used,87812k free,   268648k buffers
Swap:  284k total,35744k used,  1964340k free,  1132708k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
   
18353 clamav16   0 19560  18m 9672 R 33.9  0.9  12:20.88 clamd  
   
18120 clamav16   0 19560  18m 9672 R 30.9  0.9  55:56.78 clamd  
   
18360 clamav16   0 19560  18m 9672 R 30.9  0.9   2:33.51 clamd  
   
31657 clamav15   0 19560  18m 9672 R 30.9  0.9   8:39.73 clamd  
   
 8251 clamav15   0 19560  18m 9672 R 14.7  0.9   0:02.64 clamd  
   
14004 wouter16   0  1416 1416 1060 R 10.3  0.1   0:00.15 top
   
13930 Debian-e  10   0  3184 3176 2820 S  4.4  0.2   0:00.06 exim4  
   
14010 root  11   0  3184 3176 3036 S  4.4  0.2   0:00.05 exim4  
   
 4562 root   9   0 31148  30m 8564 S  1.5  1.5 279:23.32 named  
   
18357 clamav 9   0 19560  18m 9672 S  1.5  0.9  27:43.19 clamd  
   
12311 www-data   9   0  4936 4160 3968 S  1.5  0.2   0:00.02 apache 
   
12826 www-data   9   0 000 Z  1.5  0.0   0:00.02 apache
   
14030 root  16   0  3164 3156 3036 S  1.5  0.2   0:00.01 exim4  
   
14031 Debian-e  16   0  3232 3224 3052 D  1.5  0.2   0:00.01 exim4  
   
1 root   8   0   472  440  420 S  0.0  0.0 243:01.96 init   
   
2 root   9   0 000 S  0.0  0.0   0:01.57 keventd
   
3 root  19  19 000 S  0.0  0.0   0:13.91 ksoftirqd_CPU0 
   
4 root  19  19 000 S  0.0  0.0   0:14.97 ksoftirqd_CPU1 
   
5 root   9   0 000 S  0.0  0.0   3029:45 kswapd 
   
6 root   9   0 000 S  0.0  0.0  60:08.08 bdflush
   

That's on master. I've been watching it for about 5 minutes, and never
saw the load drop below 3.80-ish.

Could it be that master is simply imploding on the amount of mail
received?

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


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

Re: master.debian.org bounces your mail

[Wouter Verhelst]

On Thu, 8 Dec 2005 08:07:36 +0100, Lionel Elie Mamane wrote:
> On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote:
> > On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> >> I hope this is closer to a consensus...
> 
> > Afraid not. This proposal basically creates a second class of people
> > -- those who we want to sign NDA's to be able to read stuff.
> 
> > That's even further away from 'openness and transparency' than the
> > status quo. The idea that developers sometimes have private things
> > to say is at least defendable; the idea that Debian is joining the
> > NDA crap is not, IMNSHO.
> 
> NDA's have a bad reputation in our community; sometimes they make
> sense.

That's certainly true. However, given the context it would be good to
investigate _why_ they have a bad reputation.

The reason is that an NDA does not promote either transparency or
openness; instead, it promotes obscurity and creates a lot of questions.
In itself, there's nothing wrong with that; indeed, in some cases it
would make sense to ask that some things are not disclosed---after all,
there already is an NDA on -private, and that does make sense. However,
if the intent is to promote openness and transparency, one should aim
for less NDA's, not more; thus, I do not think it will "promote openness
and transparency" if you allow another select group of people to read
the archives, but do not allow them to share the information they have
read.

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


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

Re: buildd administration

[Goswin von Brederlow]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> Setting up a buildd system do not require extra privileges from the
> Debian project, as far as I know.  Any Debian developer with his
> public key in the keyring can sign uploads.  The only privileges

Upload of autobuild packages from inofficial buildds is forbidden and
binary uploads of packages highly deprecated (autobuildability must be
there or security support becomes a nightmare). Ever since the big
flame last year when there was an inofficial network helping with the
backlog for alpha, mips, mipsel, m68k and arm.

> required to join the current buildd network is access to the build
> status database, and this make it hard for people on the outside of
> the current group of buildd maintainers to set up buildd machines in
> the existing buildd system out without help from the current buildd
> admins.  But setting up ones own database is not only possible, it has
> been done in the past.

Two things are restricted:

wanna-build - if you run your own then packages will be doubly build
incoming.debian.org - Packages/Sources files are only available with
  user/pass

That means that if you run your own w-b all of that arch has to
switch. And without incoming access you add another 24h delay to
builds. And you still have convince the same people giving buildd
access that your network is trustworthy and may upload debs.

MfG
Goswin


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

Re: buildd administration

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote:
>> and people aren't skilled enough because they aren't allowed to help.
>
> Er, did you even *read* this thread?  We got on the topic of buildds because
> *someone refused to help diagnose build failures because they consider it the
> buildd admin's job*.  This is a concrete and specific task which needs

Did we? I remeber a maintainer checking his package wasn't build, the
buildd log showing a trivial missing Build-Depends and requesting the
package to be rescheduled for building. Or was that another thread
with the same topic?

> attention, which doesn't require special access in order to work on, and by
> means of which developers can demonstrate their trustworthiness to buildd
> maintainers.  Instead, people are telling me this is the buildd maintainer's
> job, and that no one is going to volunteer to do any porting work unless
> they are given the keys to the buildds in the process.

Rescheduling a job that failed with a missing build-depends is the
buildd admins job. Only people with wanna-build access can do that.

MfG
Goswin


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

Re: buildd administration

[Ingo Juergensmann]

On Thu, Dec 08, 2005 at 01:39:27PM +0100, Frank Küster wrote:

> > What problems are there today with buildd administration, please?
> One obvious problem is that there is no documented contact address (just
> search for "buildd" on http://www.debian.org/intro/organization).  One
> has to know by some magic who is responsible for which architecture.

Well, there are mail aliasses for each arch following the
[EMAIL PROTECTED] scheme, but don't expect miracles from it (beside
that sometimes problems seem to just go away silently ;)). 
Another possible resource might be http://www.buildd.net/  ;) - I try
to keep the information there as uptodate as possible, but it depends on the
will to cowork with the buildd admins/porters, too. 
So, if someone has more information about buildds or other valueable
information that is missed on buildd.net, just drop me a note... 
 
-- 
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: StrongARM tactics

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
>> [EMAIL PROTECTED] (Aaron M. Ucko) writes:
>
>> > Thomas Viehmann <[EMAIL PROTECTED]> writes:
>
>> >> +pcsx: i386# 
>> >> i386 assembly
>
>> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
>> > unconditionally.
>
>> Write patch. At a minimum the package should be "i386 amd64". In
>> general anything with "Arch: i386" should add amd64.
>
> And is that certain to give a working 64-bit binary on amd64, or are you
> suggesting that we ship extra copies of 32-bit binaries for both i386 and
> amd64?

The later if the former is not working. Since we have no multiarch yet
and acceptance of patches leading up to it is going very slowly it
looks like etch will remain without multiarch. So we need the extra
copy to have something working.

>> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:
...
>> wanna-build already filters the Architecture field of sources.

Small correction, quinn-diff does the actual filtering (here).

> No, it does not.  It goes to the buildds with every sourceful upload, and
> fails when sbuild checks the architecture list.

Hmm, must be just me then. Here quinn-diff already filters it out so
it doesn't reaches wanna-build itself. But that might just be one of
the several small differences to the official buildd suite.

[EMAIL PROTECTED]:~/t% quinn-diff 2>&1 | grep pcsx
[quinn-diff]: ignoring: pcsx has an architecture field of "i386" which
doesn't include amd64.

Makes no sense to include a source not for this arch.

MfG
Goswin


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

Re: buildd administration

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote:
>> I started my implication in the project four years ago. For four years,
>> there have been problems with keyring maintenance and buildd
>> administration.
>
> What problems are there today with buildd administration, please?

One obvious problem is that there is no documented contact address (just
search for "buildd" on http://www.debian.org/intro/organization).  One
has to know by some magic who is responsible for which architecture.

One recent example where I had problems with buildd administration is

http://bugs.debian.org/340279 

First mail to [EMAIL PROTECTED] (which is the addres on the buildd
logs) on Nov. 22, mail to debian-admin with Cc to debian-hppa on the
same day, a mail to debian-admin with further information on Nov 25, one
more on Nov 27.  No visible reaction whatsoever, just the problems went
away.  Either someone fixed the buildd.  If this has happened, he should
have told us that we need not wait for the debug info we requested, but
instead can close the RC bug on our package (or not, we don't know what
the reason was).  Or the problem went away by itself.  In the latter
case, I must assume it was a hardware problem, and it's only a question
of time until the next package fails, and of some more time until sarti
becomes unavailable completely.

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

Re: buildd administration [was Re: StrongARM tactics]

[Richard Fojta]

I don't know what's wrong but I think there is on principle, which
shouldn't be forgotten. Try to understand first and then to be
understood. I'd like to help, but may be I can't. Read Stephen Covey
books.

2005/12/8, Steve Langasek <[EMAIL PROTECTED]>:
> On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote:
> > As a result, no one can help with buildd maintenance as the current
> > buildd admins won't let anyone help them, however overloaded they can
> > be. They refuse to delegate any part of their powers because people
> > aren't skilled enough,
>
> How do you know this is true? (Hint: I know it's not.)
>
> > and people aren't skilled enough because they aren't allowed to help.
>
> Er, did you even *read* this thread?  We got on the topic of buildds because
> *someone refused to help diagnose build failures because they consider it the
> buildd admin's job*.  This is a concrete and specific task which needs
> attention, which doesn't require special access in order to work on, and by
> means of which developers can demonstrate their trustworthiness to buildd
> maintainers.  Instead, people are telling me this is the buildd maintainer's
> job, and that no one is going to volunteer to do any porting work unless
> they are given the keys to the buildds in the process.
>
> The buildd maintainers are stopping people from helping?  Like, WTF?
>
> > I started my implication in the project four years ago. For four years,
> > there have been problems with keyring maintenance and buildd
> > administration.
>
> What problems are there today with buildd administration, please?
>
> --
> 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/
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDmB/jKN6ufymYLloRAsn/AKChEi2vi3Kr1GbDEhwZbqVa19kbiACfeZxy
> KAWdD+XhpAEVMfS7G/rfdKU=
> =f1o5
> -END PGP SIGNATURE-
>
>
>

Re: buildd administration

[Petter Reinholdtsen]

[Josselin Mouette]
> I started my implication in the project four years ago. For four
> years, there have been problems with keyring maintenance and buildd
> administration. For four years, people responsible for these tasks
> have refused help on these matters. For four years, everything that
> was suggested on these topics haven't lead to any result, because
> these same people have simply ignored the suggestions. Can someone
> tell me when this nightmare is going to end?

Perhaps it is time for a replacement buildd network, and a new
delegation from the DPL for keyring maintenence?

Setting up a buildd system do not require extra privileges from the
Debian project, as far as I know.  Any Debian developer with his
public key in the keyring can sign uploads.  The only privileges
required to join the current buildd network is access to the build
status database, and this make it hard for people on the outside of
the current group of buildd maintainers to set up buildd machines in
the existing buildd system out without help from the current buildd
admins.  But setting up ones own database is not only possible, it has
been done in the past.

Doing keyring maintenence on the other hand require special privileges
from the Debian project, as there can be only one authorativ source
for DD public keys, and it is not really useful for a separate entity
to maintain another list of public keys.  Because of this, a
delegation from the DPL make sense.


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

Re: buildd administration [was Re: StrongARM tactics]

[Steve Langasek]

On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote:
> As a result, no one can help with buildd maintenance as the current
> buildd admins won't let anyone help them, however overloaded they can
> be. They refuse to delegate any part of their powers because people
> aren't skilled enough,

How do you know this is true? (Hint: I know it's not.)

> and people aren't skilled enough because they aren't allowed to help.

Er, did you even *read* this thread?  We got on the topic of buildds because
*someone refused to help diagnose build failures because they consider it the
buildd admin's job*.  This is a concrete and specific task which needs
attention, which doesn't require special access in order to work on, and by
means of which developers can demonstrate their trustworthiness to buildd
maintainers.  Instead, people are telling me this is the buildd maintainer's
job, and that no one is going to volunteer to do any porting work unless
they are given the keys to the buildds in the process.

The buildd maintainers are stopping people from helping?  Like, WTF?

> I started my implication in the project four years ago. For four years,
> there have been problems with keyring maintenance and buildd
> administration.

What problems are there today with buildd administration, please?

-- 
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: bugs.debian.org refusing mail?

[Jeroen van Wolffelaar]

On Thu, Dec 08, 2005 at 12:24:32PM +0100, Frank Küster wrote:
> Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
> 
> > Weird, 
> 
> fortunately not too weird - I just sent the same mail again, and this
> time it has been accepted.

Right, so transitional probably.
 
> > but why don't you ask the people who are dealing with debian.org
> > mail? Their address in [EMAIL PROTECTED] They have access
> > to things like logs and such, the only thing other people can do is make
> > (educated or not) guesses.
> 
> I would have sent the mail to [EMAIL PROTECTED] - how should I know
> the difference?  And my experience with mail to debian-admin is kind of
> mixed, from prompt action plus answer to nothing at all, and these were
> more specific questions than "Something seems to be wrong".

Well, if you don't try, you're 100% sure to not get an answer, so I
don't see how not mailing them helps :) -- and owner@ probably would've
forwarded if they'd not have found it themselves. You could know the
difference because DSA does email (it requires root), and the BTS
people do the stuff once it leaves the MTA.

> > Anyway, the complete text of your mail seems irrelevant as the bounce
> > seems to imply you get a 550 directly after DATA, before you sent the
> > actual message, right? So you can debug a bit yourself too with telnet
> > easily, to see what part caused this error (the MAIL FROM:, RCPT TO:,
> > the HELO, simply what IP you're sending from, or whether it's maybe
> > transitional...).
> 
> Sorry, I'm a DD, am I required to speak SMTP?

Nope, it's just relatively common for people to know it a bit, but yeah,
you can just mail DSA or so instead if you can't -- or try still try to
debug using your normal mail program (perhaps from different
hosts/accounts/etc).

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

Re: Bug#339658: should not call update-modules for module-init-tools

[Marco d'Itri]

On Dec 05, Joey Hess <[EMAIL PROTECTED]> wrote:

> Anyway, if you add a depmod call to update-modules then debhelper could
> just run it and not worry about needing to run depmod. If OTOH you do
> want to eventually remove update-modules from module-init-tools then
> we will have to live with debhelper running depmod, possibly
> redundantly.
Considering that nobody had better ideas, I'd rather remove the
update-modules debianism in the future.
Running depmod two times will not be a problem if you use -A, which
checks the files timestamps before reading them.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bugs.debian.org refusing mail?

[Frank Küster]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> Weird, 

fortunately not too weird - I just sent the same mail again, and this
time it has been accepted.

> but why don't you ask the people who are dealing with debian.org
> mail? Their address in [EMAIL PROTECTED] They have access
> to things like logs and such, the only thing other people can do is make
> (educated or not) guesses.

I would have sent the mail to [EMAIL PROTECTED] - how should I know
the difference?  And my experience with mail to debian-admin is kind of
mixed, from prompt action plus answer to nothing at all, and these were
more specific questions than "Something seems to be wrong".

> Anyway, the complete text of your mail seems irrelevant as the bounce
> seems to imply you get a 550 directly after DATA, before you sent the
> actual message, right? So you can debug a bit yourself too with telnet
> easily, to see what part caused this error (the MAIL FROM:, RCPT TO:,
> the HELO, simply what IP you're sending from, or whether it's maybe
> transitional...).

Sorry, I'm a DD, am I required to speak SMTP?

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

Re: Installation directory for modules

[Paul TBBle Hampson]

On Fri, Nov 25, 2005 at 07:05:48AM +, John Talbut wrote:
> When I run the Makefile below it installs the module in :

> /lib/modules/$(KERNELRELEASE)/extra

> As far as I can find out, this is the expected behaviour from the kbuild
> Makefiles.

> However, modprobe looks for modules in

> /lib/modules/`uname -r`.

> How can I get the modules to install in this directory?

(Old thread, but I've just started a new job...)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330081

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpdLOxmL4P1Y.pgp
Description: PGP signature

buildd administration [was Re: StrongARM tactics]

[Josselin Mouette]

Le jeudi 08 décembre 2005 à 02:03 -0800, Steve Langasek a écrit :
> > Which translates here to:
> > 1) Buildd admin should be people interested in supporting the port.
> > 2) People that are going to support the port must get the responsibility.
> 
> Which is great as a statement of principle, but it doesn't seem to offer
> much as a practical recommendation; you don't get to be a buildd maintainer
> by telling the current folks "you aren't taking the right amount of pleasure
> in this -- better let me do it", you get there by working with the current
> folks and building a relationship with them and showing that you know what
> you're doing.  Sorry, with a project that's a thousand strong, if they *do*
> care about the task, not too many people are going to turn it over to
> someone they don't know without first assuring themselves that they can
> handle it; and note that I never suggested the current buildd maintainers
> don't *care* about the ports they're helping with, they just don't have
> unlimited amounts of time to spend on single-handedly ensuring that ports
> keep up.

As a result, no one can help with buildd maintenance as the current
buildd admins won't let anyone help them, however overloaded they can
be. They refuse to delegate any part of their powers because people
aren't skilled enough, and people aren't skilled enough because they
aren't allowed to help.

I started my implication in the project four years ago. For four years,
there have been problems with keyring maintenance and buildd
administration. For four years, people responsible for these tasks have
refused help on these matters. For four years, everything that was
suggested on these topics haven't lead to any result, because these same
people have simply ignored the suggestions. Can someone tell me when
this nightmare is going to end?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: bugs.debian.org refusing mail?

[Jeroen van Wolffelaar]

On Thu, Dec 08, 2005 at 10:52:16AM +0100, Frank Küster wrote:
> Hi, 
> 
> I just got a strange response when I sent a mail to two addresses on b.d.o:
> 
> The original message was received at Thu, 8 Dec 2005 10:44:44 +0100
> from [130.60.169.219]
> 
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> (reason: 550 Administrative prohibition)
> <[EMAIL PROTECTED]>
> (reason: 550 Administrative prohibition)
> 
>- Transcript of session follows -
> ... while talking to bugs.debian.org.:
> >>> DATA
> <<< 550 Administrative prohibition
> 554 5.0.0 Service unavailable

Weird, but why don't you ask the people who are dealing with debian.org
mail? Their address in [EMAIL PROTECTED] They have access
to things like logs and such, the only thing other people can do is make
(educated or not) guesses.

Anyway, the complete text of your mail seems irrelevant as the bounce
seems to imply you get a 550 directly after DATA, before you sent the
actual message, right? So you can debug a bit yourself too with telnet
easily, to see what part caused this error (the MAIL FROM:, RCPT TO:,
the HELO, simply what IP you're sending from, or whether it's maybe
transitional...).

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

Re: StrongARM tactics

[Steve Langasek]

On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Aaron M. Ucko) writes:

> > Thomas Viehmann <[EMAIL PROTECTED]> writes:

> >> +pcsx: i386 # 
> >> i386 assembly

> > AFAICT, this is only because its Linux/Makefile forces CPU to ix86
> > unconditionally.

> Write patch. At a minimum the package should be "i386 amd64". In
> general anything with "Arch: i386" should add amd64.

And is that certain to give a working 64-bit binary on amd64, or are you
suggesting that we ship extra copies of 32-bit binaries for both i386 and
amd64?

> Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:

> [EMAIL PROTECTED]:~% zcat
> /mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl
> pcsx
> Package: pcsx
> Binary: pcsx
> Version: 1.6df-1
> Priority: optional
> Section: contrib/games
> Maintainer: Ryan Schultz <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>= 4.0.0), x11proto-core-dev | x-dev,
> libgtk2.0-dev, zlib1g-dev | libz-dev
> Architecture: i386
> Standards-Version: 3.6.2
> Format: 1.0
> Directory: pool/contrib/p/pcsx
> Files:
>  972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc
>  c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz
>  006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz

> wanna-build already filters the Architecture field of sources.

No, it does not.  It goes to the buildds with every sourceful upload, and
fails when sbuild checks the architecture list.

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

bugs.debian.org refusing mail?

[Frank Küster]

Hi, 

I just got a strange response when I sent a mail to two addresses on b.d.o:

The original message was received at Thu, 8 Dec 2005 10:44:44 +0100
from [130.60.169.219]

   - The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 Administrative prohibition)
<[EMAIL PROTECTED]>
(reason: 550 Administrative prohibition)

   - Transcript of session follows -
... while talking to bugs.debian.org.:
>>> DATA
<<< 550 Administrative prohibition
554 5.0.0 Service unavailable

The mail that I tried to send is as follows:

*
Return-Path: <[EMAIL PROTECTED]>
Received: from localhost ([130.60.169.219])
by idmailgate1.unizh.ch (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id 
jB89ifPJ015483;
Thu, 8 Dec 2005 10:44:44 +0100
Received: from localhost
([127.0.0.1] helo=localhost.localdomain ident=frank)
by localhost with esmtp (Exim 4.50)
id 1EkIKx-0006C2-8h; Thu, 08 Dec 2005 10:45:15 +0100
To: Arias Hung <[EMAIL PROTECTED]>;
Cc: [EMAIL PROTECTED], Blars Blarson <[EMAIL PROTECTED]>
Subject: Re: [SPAM?]:  Bug#341827: same problem here
X-Attribution: fant
X-Ehrenamt: http://www.langau.de
In-Reply-To: <[EMAIL PROTECTED]> (Hilmar Preusse's message of
 "Thu, 8 Dec 2005 10:14:14 +0100")
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
From: Frank Küster <[EMAIL PROTECTED]>
Date: Thu, 08 Dec 2005 10:45:14 +0100
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
X-Virus-Scanned: by amavisd-new

tags 341827 moreinfo
tags 341922 moreinfo
thanks

Hilmar Preusse <[EMAIL PROTECTED]> wrote:

> On 08.12.05 Blars Blarson ([EMAIL PROTECTED]) wrote:
>
> Hi,
>
>> I had the same problem.  My /tmp/tetex.postinst.XX* file attached.
>> 
> 1. Thanks for the debug output.
> 2. What makes you believe, you're seeing the same bug? 
[...]
> on your installation only the LaTeX stuff fails. Unfortunately we
> can't investigate further until Arias send his log file.

Ah, I didn't notice.  So perhaps there are two separate issues.  Maybe
what Blars found is a real bug, but I think probably Arias has simply
misconfigured his system badly - he also reported that he is unable to
build the package, while it builds just fine on the buildds.

Arias, without more input we won't be able to sort this out, I'm tagging
the bugs moreinfo.

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

Any ideas what is going on?

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

Re: StrongARM tactics

[Steve Langasek]

On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote:
> On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote:
> > Saying "that's the buildd admin's job" about tasks that don't *need* to be
> > done by the buildd admin is a pretty effective way of encouraging the
> > problems that the Vancouver proposal sought to address, where two or three
> > people end up carrying all the ports, and all their time is eaten up by
> > maintaining the buildds and giving back failed packages with no time for
> > following through on the permanent failures (which, even though they
> > sometimes represent a minority of Maybe-Failed packages usually account for
> > a majority of the actual work needing done).

> This go against the two basic rules for a volunteer organisation.

> 1) Volunteers doing the job should be people interested in doing it.
> 2) Responsibility should go to people that are going to do the job.

> Which translates here to:
> 1) Buildd admin should be people interested in supporting the port.
> 2) People that are going to support the port must get the responsibility.

Which is great as a statement of principle, but it doesn't seem to offer
much as a practical recommendation; you don't get to be a buildd maintainer
by telling the current folks "you aren't taking the right amount of pleasure
in this -- better let me do it", you get there by working with the current
folks and building a relationship with them and showing that you know what
you're doing.  Sorry, with a project that's a thousand strong, if they *do*
care about the task, not too many people are going to turn it over to
someone they don't know without first assuring themselves that they can
handle it; and note that I never suggested the current buildd maintainers
don't *care* about the ports they're helping with, they just don't have
unlimited amounts of time to spend on single-handedly ensuring that ports
keep up.

BTW, I have no reason to believe that buildd maintenance in general is any
more exciting or intrinsically rewarding than filing bugs on failed
packages (and providing fixes for the same); so if people are going to balk
at the latter task even though this is an area of porting that definitely
(in some cases desperately) needs attention, what reason is there to think
they're well-suited to being buildd maintainers either?

> Making "buildd admin" a purely administrative task while porters are
> not even trusted to do a binary upload is not going to work because you
> will never find volunteers accepting to work under theses terms.

It seems like you're assuming that "buildd admins" and "porters" are two
non-overlapping sets.  On 6 of 11 architectures, at least one buildd admin
is also a porter for that arch under the release requalification guidelines;
on 7 of 11 architectures, at least one of the porters has wanna-build access
for that arch.

So it's certainly not the case that no porters are trusted to do binNMUs.
If what you're arguing is that *all* porters should have wanna-build/buildd
access (which is the best way to do binNMUs so that we get log files and
consistent build envs), then I disagree.  There's a heck of a lot of other
work that porters would be better off spending their time on -- like, for
instance, the unresolved build failures of perl on arm.  I mean, it's
possible you're right that porters are going to feel slighted if they don't
have buildd access; but shouldn't porters' primary motivation be to make
sure etch releases with a kick-ass Debian port for their architecture of
choice?  Should this really be about who holds the keys to the buildds?
Isn't being a Debian porter already something to take pride in?

> If the Vancouver proposal is the constatation that the old model did not
> work the solution is to change the model, not to expect that people will
> suddenly accept it. Unless you are just looking at an excuse to remove 
> ports, obviously. Fortunately there are no external organisations forcing
> the old model upon us, so there is no reason not to change it.

All I really see here is that you've asserted that other (unspecified)
porters should be given access to buildds that they don't necessarily want
or need.  Is this the new model you're referring to, or have I missed
something?  To be honest, it doesn't seem like much of a new model to me,
just new people in the same roles.

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


signature.asc
Description: Digital signature

Re: StrongARM tactics

[Goswin von Brederlow]

Bill Allombert <[EMAIL PROTECTED]> writes:

> Making "buildd admin" a purely administrative task while porters are
> not even trusted to do a binary upload is not going to work because you
> will never find volunteers accepting to work under theses terms.

Thanks. My sentiment exactly.

MfG
Goswin


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

Re: StrongARM tactics

[Goswin von Brederlow]

[EMAIL PROTECTED] (Aaron M. Ucko) writes:

> Thomas Viehmann <[EMAIL PROTECTED]> writes:
>
>> +pcsx: i386   # i386 
>> assembly
>
> AFAICT, this is only because its Linux/Makefile forces CPU to ix86
> unconditionally.

Write patch. At a minimum the package should be "i386 amd64". In
general anything with "Arch: i386" should add amd64.

Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because:

[EMAIL PROTECTED]:~% zcat
/mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl
pcsx
Package: pcsx
Binary: pcsx
Version: 1.6df-1
Priority: optional
Section: contrib/games
Maintainer: Ryan Schultz <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), x11proto-core-dev | x-dev,
libgtk2.0-dev, zlib1g-dev | libz-dev
Architecture: i386
Standards-Version: 3.6.2
Format: 1.0
Directory: pool/contrib/p/pcsx
Files:
 972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc
 c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz
 006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz

wanna-build already filters the Architecture field of sources. The
package will automaticaly only appear on i386. When more archs (or
any) appear there wanna-build will pick it up for those archs
automatically.

MfG
Goswin

PS: policy dictates that where possible all archs has to be supported


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

Re: StrongARM tactics

[Goswin von Brederlow]

Anthony Towns  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?
>
> Put them on a webpage so anyone can see them, and if you don't find
> someone who'll give you an immediate response, track the issues over
> time so you can trivially demonstrate how big a benefit there would be
> if people would start paying attention.
>
> If you're using the BTS (by filing, analysing or fixing FTBFS bugs, eg),
> tracking the bugs with a usertag might be convenient and useful.
>
> (I don't know what the actual/perceived problem here is to give more
> detailed suggestions, sorry)
>
> Cheers,
> aj

What is required is a

buildd-give-back package_version

(or whatever you called the alias for wanna-build --give-back).

The buildd admin won't look at a webpage listing packages that need to
be handled any more than he is looking at the list of packages
left dangling without action.


There is a big difference between packages that fail with some error
and packages that fail with missing depends. I realy don't think users
can do anything productive for the later unlike the real FTBFS errors
where one can debug the problem, write a patch, submitt a bugreport
and so on.

MfG
Goswin


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