Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

 I don't know why you're asking me; I've already said that I would consider
 this configuration acceptable for a release architecture, but that I
 wouldn't recommend it to the Sparc porters.

What do you mean wouldn't recommend it to the sparc porters? And what
does your recommendation count for anyway?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

It's also not something that would totally destroy an architecture's
ability to release. Yes, it would be bad, but not the end of the world.

On Sun, Mar 20, 2005 at 02:36:12PM -0800, Thomas Bushnell BSG wrote:
 Ben Collins [EMAIL PROTECTED] writes:
 
  I think they are designed too stringently. Guidelines should describe the
  level of stability an arch is required to meet, and let the implementation
  be whatever is needed, on a per arch basis, to meet those requirements.
 
 I think a reasonable requirement is will not stop entirely due to the
 destruction of any single building by fire.  Remember: this has
 happened to Debian before, it's not some kind of fantasy scenario.
 
 Thomas

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

 For sparc, a second buildd was brought on-line on auric this year because
 (IIRC) vore was not keeping up with the upload volume at the time; this
 required effort on DSA's part to clear enough disk space to be able to run a
 buildd, until which time sparc was holding some RC bugfixes out of testing.
 If sparc had had a buildd in reserve, this would not have affected the flow
 of development for sarge.  Auric is now off-line, as noted.


My point exactly, though. It was a problem with CPU, not a problem with
machine availability. Your alpha example is a case of hardware
availability. I recall that same event, and no one had a spare alpha, or
didn't have a place to host it. Alpha's a dead platform.

If this e3500 dies, I can get another machine within days to replace it.
I'll keep this Ultra2 (2x400mhz, 1gig ram) on standby in the event that
something happens to it, so it can be used in the interim until I get a
suitable replacement.

How's that?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

Why does everyone have a sudden interest in the sparc buildds? It has
always had one buildd until auric was no longer needed for ftp-master.
Things were fine back then, and still fine now. No one complained then,
why is everyone complaining now that I want to put a better single machine
in place?

Is it so bad that it is only one machine? Why does it need to be two
machines? Since when do we want the kind of redundancy that NASA requires
(what if a jet plane crashes into the building, and we lose our data)?

It's not like every port should have to find corporate sponsoring, for
bandwidth and equipment, but now you want them to have double the
sponsorship. Like companies are just giving away these things. Personally,
I don't care if an architecure's buildd is being run off the main
developers DSL line, on one box, so long as it keeps working. Don't
question it until a problem _does_ occur.

Move on folks. Things are not as bad as you'd like everyone to think.
Seems like people want all kinds of excuses to remove ports.

How about this, show me the i386 buildd's, and their specs.

To answer your questions:

1. CPU/mem board failure requires me to call visi.net and ask someone to
   remove the board and power the machine back on. Visi.net is a sparc
   shop, so this isn't beyond their capabilities.

2. The raid array in the box will be setup with LVM, and I'll have one
   spare drive for hotspare. Obviously this is all done software side, so
   only requires remote access.

These are all rather moot points anyway. We don't have that kind of
redundancy for our own list server, or ftp-master for that matter. I
remember when debian.org was virtually shutdown for over a week due to a
break in on all our equipment. Should Debian be allowed to distribute
Linux if it can't handle these kinds of things?

On Sun, Mar 20, 2005 at 12:31:14AM -0800, Steve Langasek wrote:
 Hi Ben,
 
 On Wed, Mar 16, 2005 at 07:32:37PM -0500, Ben Collins wrote:
  On Wed, Mar 16, 2005 at 06:11:39PM -0800, Thomas Bushnell BSG wrote:
   Ben Collins [EMAIL PROTECTED] writes:
 
The requirement sucks, lets leave it at that. If the machine dies, I can
have two to replace it within a day or two.
 
The point being, there's no reason to have two seperate machines when 
one
can do the job. As long as it keeps up, then there should be no cause 
for
concern.
 
   If you have one machine, and it dies, and it takes you a day or two to
   replace it, then it cannot do the job.  If you can guarantee that it
   never dies (somehow), then maybe it could.
 
  Ok, I can guarantee that it never dies. The hardrives are raid 5
  configuration, and the power supplies are redundant, and if any of the
  three cpu/mem boards goes bad, I can just remove it and let the other two
  (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet
  adapters.
 
  It wont die all together, it's an enterprise class system. It's meant to
  keep going, even if it has to limp to do so. Even with 1 cpu/mem board, it
  still would have 2 cpu's and 2gigs of ram.
 
 Is this system going to have one or two RAID5 arrays?  Assuming that both
 buildds would be hosted on a single array, who monitors the RAID status to
 ensure timely replacement of hard drives in the event of a single drive
 failure?  What assurance do we have that a single drive failure would be
 regarded as a matter requiring immediate attention (local, assuming there's
 no hot-standby drive)?  What happens if, God forbid, the facility suffers an
 HVAC failure, resulting in the simultaneous failure of multiple drives in the
 RAID array?
 
 Does a CPU board failure require on-site intervention?
 
 What happens to the Sparc port if Visi.net decides they are no longer
 willing to sponsor hosting for these build daemons?
 
 I certainly appreciate that having two buildds in a single enterprise-class
 chassis can offer as much redundancy as two buildds in adjacent chassis, but
 it can't provide geographic separation.  Finding two independent hosting
 sponsors really ought not be a problem for a viable port, and I don't think
 it's in the best interest of the port for either you to offer to guarantee
 the buildds will never die, or for others involved in the sparc port to
 accept such a guarantee.
 
 I would be grudgingly willing to accept a pair of buildds in this
 configuration as meeting the requirement for release architectures if this
 is the wish of the sparc porting team, but I would strongly encourage
 getting some geographic separation in place for your own benefit so that we
 don't find ourselves forced to drop sparc as a release architecture as a
 result of one of the above-mentioned failure scenarios that you haven't
 mitigated.
 
 -- 
 Steve Langasek
 postmodern programmer



-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


-- 
To UNSUBSCRIBE, email to [EMAIL

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

I think they are designed too stringently. Guidelines should describe the
level of stability an arch is required to meet, and let the implementation
be whatever is needed, on a per arch basis, to meet those requirements.

The guidelines should not say something like needs two buildds minimum,
but instead, needs to remain within 2 days of package building times,
and set repercussions based on stability of build times and turnaround,
rather than number of buildds.

Case in point, mips and arm cannot even cope with only 2 buildds. It isn't
enough. However archs like x86-64, sparc, etc. can keep up with just one,
or two. So the number of buildds isn't what is important. The problem with
architectures not keeping up isn't a matter of buildd stability so much as
speed. I don't recall any architecures falling behind miserably just
because a buildd went down for an extended period, but I do recall some
(m68k) having problems simply because of lack of processing power.

The guidelines are aimed at the wrong thing is my point.

On Sun, Mar 20, 2005 at 12:23:58PM -0800, Thomas Bushnell BSG wrote:
 Ben Collins [EMAIL PROTECTED] writes:
 
  Why does everyone have a sudden interest in the sparc buildds? It has
  always had one buildd until auric was no longer needed for ftp-master.
  Things were fine back then, and still fine now. No one complained then,
  why is everyone complaining now that I want to put a better single machine
  in place?
 
 Nobody is complaining; we are just explaining what the implementation
 of the new guidelines would imply for sparc.  As I read them, the new
 guidelines are designed to give us better reliability for release
 archs than we have had in the past.
 

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

Vore isn't down.

On Thu, Mar 17, 2005 at 10:54:18AM +0100, Andreas Barth wrote:
 * Ben Collins ([EMAIL PROTECTED]) [050317 03:25]:
  On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote:
   Ben Collins [EMAIL PROTECTED] writes:
On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote:
 In article [EMAIL PROTECTED] you write:
 I have an e3500 to replace both auric and vore (and the raid), but I
 haven't gotten an ok from James to do so yet.
 
 That would cut the number of sparc buildds down to one, when two are
 required for RC archtectures under the new proposal.

That's ok because two buildd's can run on the one machine. It has 6 
cpu's.
   
   That cannot be the requirement.  The point has to be an additional and
   independently functioning piece of hardware.  If the disk blows or it
   is compromised or something, the others should be able to continue.
  
  The requirement sucks, lets leave it at that. If the machine dies, I can
  have two to replace it within a day or two.
 
 Ah, so why is vore down now for some time now? If it's so easy to
 replace a broken machine, why don't you just do it? (And, BTW, you might
 be on vacation, sick, ... - we need more than just one machine.)
 
 
 
 Cheers,
 Andi
 -- 
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

Read my previous replies.

On Thu, Mar 17, 2005 at 11:01:07AM +0100, Andreas Barth wrote:
 * Andreas Barth ([EMAIL PROTECTED]) [050317 10:54]:
  Ah, so why is vore down now for some time now? If it's so easy to
 
 that should read as auric of course.
 
 
 Cheers,
 Andi
 -- 
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote:
 In article [EMAIL PROTECTED] you write:
 I have an e3500 to replace both auric and vore (and the raid), but I
 haven't gotten an ok from James to do so yet.
 
 That would cut the number of sparc buildds down to one, when two are
 required for RC archtectures under the new proposal.

That's ok because two buildd's can run on the one machine. It has 6 cpu's.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote:
 Ben Collins [EMAIL PROTECTED] writes:
 
  On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote:
   In article [EMAIL PROTECTED] you write:
   I have an e3500 to replace both auric and vore (and the raid), but I
   haven't gotten an ok from James to do so yet.
   
   That would cut the number of sparc buildds down to one, when two are
   required for RC archtectures under the new proposal.
  
  That's ok because two buildd's can run on the one machine. It has 6 cpu's.
 
 That cannot be the requirement.  The point has to be an additional and
 independently functioning piece of hardware.  If the disk blows or it
 is compromised or something, the others should be able to continue.

The requirement sucks, lets leave it at that. If the machine dies, I can
have two to replace it within a day or two.

The point being, there's no reason to have two seperate machines when one
can do the job. As long as it keeps up, then there should be no cause for
concern.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Wed, Mar 16, 2005 at 06:11:39PM -0800, Thomas Bushnell BSG wrote:
 Ben Collins [EMAIL PROTECTED] writes:
 
  The requirement sucks, lets leave it at that. If the machine dies, I can
  have two to replace it within a day or two.
  
  The point being, there's no reason to have two seperate machines when one
  can do the job. As long as it keeps up, then there should be no cause for
  concern.
 
 If you have one machine, and it dies, and it takes you a day or two to
 replace it, then it cannot do the job.  If you can guarantee that it
 never dies (somehow), then maybe it could.

Ok, I can guarantee that it never dies. The hardrives are raid 5
configuration, and the power supplies are redundant, and if any of the
three cpu/mem boards goes bad, I can just remove it and let the other two
(4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet
adapters.

It wont die all together, it's an enterprise class system. It's meant to
keep going, even if it has to limp to do so. Even with 1 cpu/mem board, it
still would have 2 cpu's and 2gigs of ram.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

Auric is down, because it is a only a U60. I attempted to move some drives
around, and I did put them in the wrong place.

The delay in getting it fixed is, as I said, getting a response from James
to move the new machine there. No reason to fix auric if I can just
replace it.

Stop chasing red herrings, and just get back to work. Sparc has always
been and always will be a maintained architecture.

On Wed, Mar 16, 2005 at 07:17:42PM -0800, Thomas Bushnell BSG wrote:
 Ben Collins [EMAIL PROTECTED] writes:
 
  Ok, I can guarantee that it never dies. The hardrives are raid 5
  configuration, and the power supplies are redundant, and if any of the
  three cpu/mem boards goes bad, I can just remove it and let the other two
  (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet
  adapters.
 
 So why isn't auric running now?  It's down on a RAID failure or
 something like that, right?
 
 If a cpu/mem board goes bad, is just remove it necessary for the
 machine to keep working?  What worries me is not the high-reliability
 enterprise hardware doing it's job, but your day or two delay in
 getting things back.  The point of the N+1 rule, as I understand it,
 is to give a different kind of redundancy, so that we don't have to
 wait a day or two.
 
 Thomas

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Accepted silo 1.4.9-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 15 Mar 2005 09:06:46 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.9-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.9-1) unstable; urgency=low
 .
   * Upgraded to silo 1.4.9
   * Added sparc-utils to build-deps. Closes #278126
   * Set CC to gcc-2.95
Files: 
 9ecf344ac829d6a0646673570d2d05ee 579 base important silo_1.4.9-1.dsc
 2bbe60205f4d71507e38b2b815c4befe 155321 base important silo_1.4.9-1.tar.gz
 6d0973e975fc364dfa67f1bd8233dc57 181660 base important silo_1.4.9-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFCNvEgfNc/ZB4E7C0RAkjBAJsHxuojXIvC9wJ8Qnz7aCX4ku9DwQCeJxY9
UWfxTfBUxDqX67wG0QOrhlg=
=wq9a
-END PGP SIGNATURE-


Accepted:
silo_1.4.9-1.dsc
  to pool/main/s/silo/silo_1.4.9-1.dsc
silo_1.4.9-1.tar.gz
  to pool/main/s/silo/silo_1.4.9-1.tar.gz
silo_1.4.9-1_sparc.deb
  to pool/main/s/silo/silo_1.4.9-1_sparc.deb


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

 As I understand it, the plan was to convert auric into a buildd but
 the RAID needs to be fixed.  Ben Collins was looking into this but I
 don't know about the status.  I've also heard discussions several
 months ago about using one of Ben's really fast machines.
 
 This is based on what I've heard at some point and may not be
 accurate.  I'm CCing Ben so he can comment.
 
 If we do need auric and if we need resources to fix the RAID, Debian
 can make funding available.

I have an e3500 to replace both auric and vore (and the raid), but I
haven't gotten an ok from James to do so yet.

If he says ok, then I'll carry this e3500 up there and let him have fun
with it. It's a 6x366mhz box with 6gigs of ram, and I've pulled all the
raid disks from auric to put into it. VisiNet has already said they don't
mind having it up there (it's about the same size as auric+vore+raid
anyway).

It'll certainly run two buildd's and have enough resources left for ppl to
do local builds.

Also, this will make two ultrasparc machines available for some of our new
sparc developers. I can't pay to ship them, but if Debian foots the bill,
I'll get them to the right ppl.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Tue, Mar 15, 2005 at 11:04:42AM -0500, Stephen Frost wrote:
 * Ben Collins ([EMAIL PROTECTED]) wrote:
  Also, this will make two ultrasparc machines available for some of our new
  sparc developers. I can't pay to ship them, but if Debian foots the bill,
  I'll get them to the right ppl.
 
 I'd be willing to help with the shipping bill, and possibly with the
 hosting as well.  Additionally, I may be able to make some other sparc
 systems available.

We don't need any more systems available publicly. I just want them to get
to devs for personal use, like to do debian-installer work. The e3500 is
all the machine needed for buildd and developer access.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Tue, Mar 15, 2005 at 04:10:49PM +, Martin Michlmayr - Debian Project 
Leader wrote:
 * Stephen Frost [EMAIL PROTECTED] [2005-03-15 11:04]:
   Also, this will make two ultrasparc machines available for some of our new
   sparc developers. I can't pay to ship them, but if Debian foots the bill,
   I'll get them to the right ppl.
  
  I'd be willing to help with the shipping bill, and possibly with the
 
 Debian has enough resources to pay for shipping expenses.
 
  hosting as well.  Additionally, I may be able to make some other sparc
  systems available.
 
 Are any of them 64 bit?  Joshua Kwan might benefit from having a 64
 bit SPARC system (at least he would've benefited in the past; I'm not
 sure how much spare time he has at the moment or in the near future).

Both of them are UltraSPARC's, so yes. One is a U30, and the other is a
U60 with 2x400mhz and 2gigs of ram.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Tue, Mar 15, 2005 at 11:17:54AM -0500, Stephen Frost wrote:
 * Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) wrote:
  * Stephen Frost [EMAIL PROTECTED] [2005-03-15 11:04]:
Also, this will make two ultrasparc machines available for some of our 
new
sparc developers. I can't pay to ship them, but if Debian foots the 
bill,
I'll get them to the right ppl.
   
   I'd be willing to help with the shipping bill, and possibly with the
  
  Debian has enough resources to pay for shipping expenses.
  
   hosting as well.  Additionally, I may be able to make some other sparc
   systems available.
  
  Are any of them 64 bit?  Joshua Kwan might benefit from having a 64
  bit SPARC system (at least he would've benefited in the past; I'm not
  sure how much spare time he has at the moment or in the near future).
 
 Yeah, currently I've got access to 2 64bit ultrasparcs.  The 'may be
 able to' bit above comes from the question of how much access I'd be
 able to give others.  I'll need to investigate that, though a SunFire
 V100 isn't exactly terribly expensive - $995 w/ 256M and an 80G disk.

No need to give access to them. I want to give them out for personal
development use (builds, test installs, whatever).



-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Re: .d.o machines which are down (Re: Questions for the DPL candidates)

[Ben Collins]

On Tue, Mar 15, 2005 at 11:20:07AM -0800, Thomas Bushnell BSG wrote:
 Martin Michlmayr [EMAIL PROTECTED] writes:
 
  We can move services to supported architectures, but there is of
  course one major problem: DSA is only willing to host stable .d.o
  boxes but if many architectures don't have stable releases, they will
  not be able to offer developer accessible porting boxes (which
  obviously won't help getting better support for those architectures).
 
 We would have to adjust this policy, it seems to me.

Let's keep the debate out of a technical discussion.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/


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

Accepted silo 1.4.8-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 14 Jul 2004 10:35:40 -0400
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.8-1
Distribution: unstable
Urgency: high
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.8-1) unstable; urgency=high
 .
   * New upstream, really fixes initrd issues.
Files: 
 fb82592e40af0bb60f9efcb475ddd581 553 base important silo_1.4.8-1.dsc
 acdf15b11ff6ec93ee75e0bb2a58d495 154549 base important silo_1.4.8-1.tar.gz
 01608d6c0b71bc6547996be22e409fae 178738 base important silo_1.4.8-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFA9UWIfNc/ZB4E7C0RAnlbAJ9++lOWJ9KXndZCm/NhcO1ZXCz29gCgsPEC
eqFDuiVtNOwJ7cXe9HPpm9I=
=Jn6G
-END PGP SIGNATURE-


Accepted:
silo_1.4.8-1.dsc
  to pool/main/s/silo/silo_1.4.8-1.dsc
silo_1.4.8-1.tar.gz
  to pool/main/s/silo/silo_1.4.8-1.tar.gz
silo_1.4.8-1_sparc.deb
  to pool/main/s/silo/silo_1.4.8-1_sparc.deb


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

Accepted silo 1.4.6-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 20 Jun 2004 13:11:48 -0400
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.6-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.6-1) unstable; urgency=low
 .
   * New upstream, partially fixes initrd issues.
Files: 
 1d473b7261b9fbb3d4023cc94cdda467 553 base important silo_1.4.6-1.dsc
 2f437ac412987d9b21c3ba9b0e3c50d9 154338 base important silo_1.4.6-1.tar.gz
 71659e817345a66a543336567809d97f 178678 base important silo_1.4.6-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFA1cXufNc/ZB4E7C0RAoIwAJsGe8AUEGcpdkzg7ReBnKJyKU9/0ACeKjLa
DM9lV49vJ4gMtFmwJAynFzI=
=6ClV
-END PGP SIGNATURE-


Accepted:
silo_1.4.6-1.dsc
  to pool/main/s/silo/silo_1.4.6-1.dsc
silo_1.4.6-1.tar.gz
  to pool/main/s/silo/silo_1.4.6-1.tar.gz
silo_1.4.6-1_sparc.deb
  to pool/main/s/silo/silo_1.4.6-1_sparc.deb


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

Accepted silo 1.4.5-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 13 May 2004 09:58:53 -0400
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.5-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Closes: 232009 239479
Changes: 
 silo (1.4.5-1) unstable; urgency=low
 .
   * New upstream fixes illegal instruction on some sparc64 hardware.
   * Fixed ext2fs for SELINUX: Closes: #232009
   * Added bzip2 build-dep. Closes: #239479
Files: 
 ad8a357f664ee9c9516febf9bc248524 553 base important silo_1.4.5-1.dsc
 9c19c1fff6dba044bf59b3afb0eb55ea 153595 base important silo_1.4.5-1.tar.gz
 5b449ffae9c44a5f2e7a01cd40ff7b7b 177066 base important silo_1.4.5-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAo6YVfNc/ZB4E7C0RAvL3AKC3+KnL6Mhd30MJcO/GDXkRRAkBPACgo3kq
3nbh5/HKsNWLL4/fUf8oi74=
=313I
-END PGP SIGNATURE-


Accepted:
silo_1.4.5-1.dsc
  to pool/main/s/silo/silo_1.4.5-1.dsc
silo_1.4.5-1.tar.gz
  to pool/main/s/silo/silo_1.4.5-1.tar.gz
silo_1.4.5-1_sparc.deb
  to pool/main/s/silo/silo_1.4.5-1_sparc.deb


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

Accepted silo-installer 0.0.1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 26 Feb 2004 11:23:18 -0500
Source: silo-installer
Binary: silo-installer
Architecture: source sparc
Version: 0.0.1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo-installer - Install SILO on a hard disk (udeb)
Changes: 
 silo-installer (0.0.1) unstable; urgency=low
 .
   * First release
Files: 
 abb0060b63ea763c77b1af25fc8b889c 579 debian-installer standard 
silo-installer_0.0.1.dsc
 172cbe4b7d91b79ff1e413c06131d75e 2801 debian-installer standard 
silo-installer_0.0.1.tar.gz
 fd6e4b800b0988153fa88e6a55642339 1420 debian-installer standard 
silo-installer_0.0.1_sparc.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAPiokfNc/ZB4E7C0RAifiAJ9U3hB/BHXuaE8svYeStJVRR7puvgCff6R1
CVVV2WJO3WaEVNz/iD7cwuE=
=cP77
-END PGP SIGNATURE-


Accepted:
silo-installer_0.0.1.dsc
  to pool/main/s/silo-installer/silo-installer_0.0.1.dsc
silo-installer_0.0.1.tar.gz
  to pool/main/s/silo-installer/silo-installer_0.0.1.tar.gz
silo-installer_0.0.1_sparc.udeb
  to pool/main/s/silo-installer/silo-installer_0.0.1_sparc.udeb


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

Accepted sxid 4.0.5 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri,  6 Feb 2004 10:12:46 -0500
Source: sxid
Binary: sxid
Architecture: source sparc
Version: 4.0.5
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 sxid   - suid, sgid file and directory checking
Closes: 204979
Changes: 
 sxid (4.0.5) unstable; urgency=low
 .
   * Work around for timestamp skew. Closes: #204979
Files: 
 eaa51fa86814b90754655e0d8b924987 515 admin extra sxid_4.0.5.dsc
 17643d1cf6e7ef9be644cc0fa2ef8c2c 45451 admin extra sxid_4.0.5.tar.gz
 c3be376a8f3c7320a0a21357ace749a7 23292 admin extra sxid_4.0.5_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAI7ESfNc/ZB4E7C0RAmRfAJ0UbaBjhW+fG5SeUHBh0BTM3OxkfQCcDmUl
hVidkKGlr8HRD6DZCTFC3eg=
=s4DZ
-END PGP SIGNATURE-


Accepted:
sxid_4.0.5.dsc
  to pool/main/s/sxid/sxid_4.0.5.dsc
sxid_4.0.5.tar.gz
  to pool/main/s/sxid/sxid_4.0.5.tar.gz
sxid_4.0.5_sparc.deb
  to pool/main/s/sxid/sxid_4.0.5_sparc.deb


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

Accepted kernel-image-sparc-2.4 35 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 29 Nov 2003 10:13:34 -0500
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.24-sparc64 kernel-image-2.4.24-sparc32-smp 
kernel-image-2.4.24-sparc32 kernel-image-2.4.24-sparc64-smp
Architecture: source sparc
Version: 35
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 kernel-image-2.4.24-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.24-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.24-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.24-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
Closes: 162462 166253 176192 205374 218195 223571 223893 225170 225429 225848 227276 
227467 227622 227626 227644 227647 230245
Changes: 
 kernel-image-sparc-2.4 (35) unstable; urgency=low
 .
   * Bump to 2.4.24. Closes: #162462, #230245, #218195, #225170, #225429
   * Remove udeb's. Closes: #227644, #227622
   * Added debhelper to build depends. Finally Closes: #176192
   * check_asm.c fixed in source tarball. Closes: #227467
   * Added kernel-package to build depends. Closes: #227626
   * Updated default configs. Closes: #227276, #205374
   * Includes patches in #223893. Closes: #223893
   * Added APPEND_TO_VERSION for builds. Closes: #227647, #223571
   * Enabled CONFIG_SUN_BPP=m. Closes: #166253
   * Newer SILO available can boot larger images. Added patch to allow these
 kernels to be loaded into higher memory. Closes: #225848
   * Get rid of kernel-headers package. Glibc is now using some other generic
 package.
Files: 
 9c0c1ec8ff607bc6a1cacf70f691b208 737 devel optional kernel-image-sparc-2.4_35.dsc
 a3f4f4323e6c78a7c4f980b4df47cf74 1681423 devel optional 
kernel-image-sparc-2.4_35.tar.gz
 37f7586fabbb907f9509a5d010077006 2979252 base optional 
kernel-image-2.4.24-sparc32_35_sparc.deb
 c8374282c0ccb90374c1c8b7c43dde8b 3135298 base optional 
kernel-image-2.4.24-sparc32-smp_35_sparc.deb
 df0806a3c15734211ff863013607ebd3 6002576 base optional 
kernel-image-2.4.24-sparc64_35_sparc.deb
 be0bd1be04f2547261f04bf646ee768b 6158042 base optional 
kernel-image-2.4.24-sparc64-smp_35_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGxvbfNc/ZB4E7C0RAgPYAJ9ON8iLYh+l1IEbypG/yhq7pITSLgCfWoSs
YypjUc9uCIUUC2yS5ggTbUM=
=b3GD
-END PGP SIGNATURE-


Accepted:
kernel-image-2.4.24-sparc32-smp_35_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.24-sparc32-smp_35_sparc.deb
kernel-image-2.4.24-sparc32_35_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.24-sparc32_35_sparc.deb
kernel-image-2.4.24-sparc64-smp_35_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.24-sparc64-smp_35_sparc.deb
kernel-image-2.4.24-sparc64_35_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.24-sparc64_35_sparc.deb
kernel-image-sparc-2.4_35.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_35.dsc
kernel-image-sparc-2.4_35.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_35.tar.gz


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

Accepted silo 1.4.4-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 30 Jan 2004 15:18:24 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.4-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.4-1) unstable; urgency=low
 .
   * New upstream. Fixes sparc32 boots.
Files: 
 4442e687eff8cdaeedc14f134cb06852 546 base important silo_1.4.4-1.dsc
 8a6d6c9cb98e73eb36911f9e5c405978 153352 base important silo_1.4.4-1.tar.gz
 259d201e07acf93d10d5af48e805fcb8 174836 base important silo_1.4.4-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGryLfNc/ZB4E7C0RAgUeAJ92AgQWxOJ7Y5rkcew5tFHG7UoDwgCfVSEI
4PzH3pwwKo+lVr/iMP1knnA=
=0qM2
-END PGP SIGNATURE-


Accepted:
silo_1.4.4-1.dsc
  to pool/main/s/silo/silo_1.4.4-1.dsc
silo_1.4.4-1.tar.gz
  to pool/main/s/silo/silo_1.4.4-1.tar.gz
silo_1.4.4-1_sparc.deb
  to pool/main/s/silo/silo_1.4.4-1_sparc.deb


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

Accepted silo 1.4.1-2 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 29 Jan 2004 13:31:04 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.1-2
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.1-2) unstable; urgency=low
 .
   * New upstream. Fixes initrd.
Files: 
 c38f7cc7f67fd4d7751ad39f2586496e 546 base important silo_1.4.1-2.dsc
 7efbf8c833a624df9eff308618e9edd9 153254 base important silo_1.4.1-2.tar.gz
 f4092120e1310c2a112096f85c90f094 174640 base important silo_1.4.1-2_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGVHKfNc/ZB4E7C0RAmhJAJ9OrL1GZhMzI+7Qt6Yp71O6LGAYogCfaW4D
lNL3NMCp9MsWf9wSRA/YC5A=
=F+B/
-END PGP SIGNATURE-


Accepted:
silo_1.4.1-2.dsc
  to pool/main/s/silo/silo_1.4.1-2.dsc
silo_1.4.1-2.tar.gz
  to pool/main/s/silo/silo_1.4.1-2.tar.gz
silo_1.4.1-2_sparc.deb
  to pool/main/s/silo/silo_1.4.1-2_sparc.deb


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

Accepted silo 1.4.2-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 29 Jan 2004 13:34:01 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.2-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.2-1) unstable; urgency=low
 .
   * Get the version right this time.
Files: 
 414df93b57c74fbf7311c5a4abf47fae 546 base important silo_1.4.2-1.dsc
 8d5c70ad4d776704910eba7e38fd28ae 153285 base important silo_1.4.2-1.tar.gz
 6db4ba17f80865537dd2fd80717eaf59 174670 base important silo_1.4.2-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGVJ0fNc/ZB4E7C0RAlzTAKCuJGIqwVuKYuLR4Dl/KAKP0m7RJQCfdlMf
PAl4dU5RNPH8JTQTkEc9ww4=
=poYN
-END PGP SIGNATURE-


Accepted:
silo_1.4.2-1.dsc
  to pool/main/s/silo/silo_1.4.2-1.dsc
silo_1.4.2-1.tar.gz
  to pool/main/s/silo/silo_1.4.2-1.tar.gz
silo_1.4.2-1_sparc.deb
  to pool/main/s/silo/silo_1.4.2-1_sparc.deb


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

Accepted silo 1.4.3-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 29 Jan 2004 14:09:59 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.3-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.4.3-1) unstable; urgency=low
 .
   * New upstream resolves one other problem with initrd.
Files: 
 af45eb667d620719548d428071d7c90e 546 base important silo_1.4.3-1.dsc
 cbc47add23d81f04d12e7850cec51d67 153314 base important silo_1.4.3-1.tar.gz
 9f38d0ca4fd1c61f0203142bf3f9146b 174738 base important silo_1.4.3-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGVrmfNc/ZB4E7C0RApHaAKCQdp+yuLabDs5QZe4wCNLA9cMhQgCfaHHh
xbWlUiNoVQZB6R6mMFMnHWM=
=dJNd
-END PGP SIGNATURE-


Accepted:
silo_1.4.3-1.dsc
  to pool/main/s/silo/silo_1.4.3-1.dsc
silo_1.4.3-1.tar.gz
  to pool/main/s/silo/silo_1.4.3-1.tar.gz
silo_1.4.3-1_sparc.deb
  to pool/main/s/silo/silo_1.4.3-1_sparc.deb


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

Accepted silo 1.4.1-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 28 Jan 2004 12:24:28 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.4.1-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Closes: 98314 145267 214005
Changes: 
 silo (1.4.1-1) unstable; urgency=low
 .
   * New upstream. Allows larger kernels to be loaded (kernels must be patched
 to support this).
   * Adds partition-boot config option, which is the same as -t.
 closes: #145267, #98314
   * Silo is no longer essential: closes: #214005
Files: 
 ced6bb514d731d75c0fddb329b71d3c8 546 base important silo_1.4.1-1.dsc
 7eb3f598ef1543836c7a227e24135b59 234692 base important silo_1.4.1-1.tar.gz
 713f6106e474f3d3116984554fe8f31e 174652 base important silo_1.4.1-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQFAGG8MfNc/ZB4E7C0RAjQuAJ9U8OPhCPL4Wh1b1gKzU0oFui25UACggssy
iFF3Y0JknpqWO7JNj4v0e1A=
=il8p
-END PGP SIGNATURE-


Accepted:
silo_1.4.1-1.dsc
  to pool/main/s/silo/silo_1.4.1-1.dsc
silo_1.4.1-1.tar.gz
  to pool/main/s/silo/silo_1.4.1-1.tar.gz
silo_1.4.1-1_sparc.deb
  to pool/main/s/silo/silo_1.4.1-1_sparc.deb


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

Accepted silo 1.3.2-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  3 Dec 2003 21:13:53 -0500
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.3.2-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.3.2-1) unstable; urgency=low
 .
   * New upstream, fixes initrd boots with some larger kernels.
Files: 
 e215e9d5ad3c79d500abd17ac59d7586 546 base important silo_1.3.2-1.dsc
 ff0e6a995a3108fe6175d0e0441f792b 264362 base important silo_1.3.2-1.tar.gz
 d312f719c2df41eb96c9fa3b77879211 286058 base important silo_1.3.2-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/zpmWfNc/ZB4E7C0RAji3AJ0RyQLkOUa3rSDO2l6pG+CdNfyrJACfWmNs
D6JLvZuq7k4j5VrPZm9JqAg=
=7gA/
-END PGP SIGNATURE-


Accepted:
silo_1.3.2-1.dsc
  to pool/main/s/silo/silo_1.3.2-1.dsc
silo_1.3.2-1.tar.gz
  to pool/main/s/silo/silo_1.3.2-1.tar.gz
silo_1.3.2-1_sparc.deb
  to pool/main/s/silo/silo_1.3.2-1_sparc.deb


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

Re: kernel-patch-acl

[Ben Collins]

 This problem has already bitten several skilled Debian developers at various 
 times.  Given the problems that are caused for such skilled people as a 
 result of this I hate to imagine the consequences for typical users!

But typical users wont be building custom kernels with ACL patches, will
they? :)

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Accepted sparc-utils 1.9-2.2 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 13 Nov 2003 22:51:36 -0500
Source: sparc-utils
Binary: sparc-utils
Architecture: source sparc
Version: 1.9-2.2
Distribution: unstable
Urgency: low
Maintainer: Eric Delaunay [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 sparc-utils - Miscellaneous tools useful for sparc systems.
Changes: 
 sparc-utils (1.9-2.2) unstable; urgency=low
 .
   * Look people. If you aren't willing to test shit, don't change it, or
 upload it for that matter.
   * Fix sparc32, which Wilmer broke. This caused us great pain, such as the
 buildd starting to build 64-bit by default. What fun to have things like
 that happen.
Files: 
 d1d2d724ff07864dc6d56e2c59f9dc8f 611 misc extra sparc-utils_1.9-2.2.dsc
 ad8f788a10b2f59c15324da1aace0d03 8455 misc extra sparc-utils_1.9-2.2.diff.gz
 d496d1e91ae503230abcb2e239f39e3f 138036 misc extra sparc-utils_1.9-2.2_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/tFZOfNc/ZB4E7C0RAuttAJwOAJLUqtq26O2DJJwFc+N43brXmwCdEVKm
BlBFIYCYQ7SfjtAYbjLFHxY=
=0kiU
-END PGP SIGNATURE-


Accepted:
sparc-utils_1.9-2.2.diff.gz
  to pool/main/s/sparc-utils/sparc-utils_1.9-2.2.diff.gz
sparc-utils_1.9-2.2.dsc
  to pool/main/s/sparc-utils/sparc-utils_1.9-2.2.dsc
sparc-utils_1.9-2.2_sparc.deb
  to pool/main/s/sparc-utils/sparc-utils_1.9-2.2_sparc.deb


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

Re: Package which uses jam (instead make)

[Ben Collins]

On Fri, Oct 17, 2003 at 05:42:22PM +0200, Bartosz Fenski aka fEnIo wrote:
 Hello.
 
 Could someone tell me which package uses jam instead make for building?
 I am trying to package netpanzer and it uses jam... 
 I'd like to see any examples how to connect debian/rules with jam.
 
 I hope there are any packages builded with jam ;)

You aren't trying to make debian/rules a jam script are you? I would
suggest just using make for debian/rules, and have it calls commands for
building your package using jam. Lots of things already do this. Just
because your package uses jam, doesn't mean debian/rules has to aswell.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: perm of etc/zorp/ is 0700

[Ben Collins]

On Tue, Oct 14, 2003 at 10:51:14PM +0200, Magos?nyi ?rp?d wrote:
 Hi!
 
 I am asking your advice per policy section 10.9. [*]
 
 /etc/zorp is mode 0700 in upstream. In a typical setup, almost
 every single file under this directory contains sensitive information:
 firewall rules, cryptographic keys, etc.
 
 I think it justifies a lintian override.
 
 What do you think?
 
 [*] The rules in this section are guidelines for general use. If
 necessary you may deviate from the details below. However, if you do so
 you must make sure that what is done is secure and you should try to be
 as consistent as possible with the rest of the system. You should
 probably also discuss it on debian-devel first. 

If the directory is justified, then the files should be 600 aswell.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: chroot on debian hosts?

[Ben Collins]

On Tue, Oct 14, 2003 at 06:20:15PM -0700, Marc Singer wrote:
 (I thought I sent this, but now I cannot find it to be sure.)
 
 I'd like to build against sid on a machine (ia64) I don't own but
 which Debian does have available.
 
 I tried the recipe from the developer's manual using fakeroot.  It
 failed because it could not find a package.  Perhaps, this is a bug in
 debootstrap.  Is that method supposed to work?

You need to send email to [EMAIL PROTECTED] to get packages installed
in the chroots for your builds.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Quote: Debian and Democracy at Advocato.org

[Ben Collins]

On Wed, Oct 08, 2003 at 09:42:42PM +0200, Thomas Hood wrote:
 On Wed, 2003-10-08 at 21:25, Daniel Ruoso wrote:
  I think this should be clearly discussed.
 
 Just to prevent any confusion I'll just point out that
 the rant you quoted was authored by Eray Ozkural.

Thanks, you saved me from reading this entire thread.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: libssl0.9.7 restarts services after security update

[Ben Collins]

On Mon, Oct 06, 2003 at 02:29:38PM +0200, Christoph Martin wrote:
 Hi folks,
 
 as of the latest update of libssl0.9.7 the postinst is able to restart
 certain services which use the ssl or crypto library, so that they don't
 use the faulty libraries any longer. I used part of the code from
 libc6.postinst. Currently there is only apache-ssl, ssh and sendmail in
 the list of services to be restarted. Please let me know if you wish
 more services to be included in the list.

apache2-mpm-perchild
apache2-mpm-prefork
apache2-mpm-threadpool
apache2-mpm-worker

They all restart using /etc/init.d/apache2 init script.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: libssl0.9.7 restarts services after security update

[Ben Collins]

On Mon, Oct 06, 2003 at 02:29:38PM +0200, Christoph Martin wrote:
 Hi folks,
 
 as of the latest update of libssl0.9.7 the postinst is able to restart
 certain services which use the ssl or crypto library, so that they don't
 use the faulty libraries any longer. I used part of the code from
 libc6.postinst. Currently there is only apache-ssl, ssh and sendmail in
 the list of services to be restarted. Please let me know if you wish
 more services to be included in the list.

apt-cache rdepends libssl0.9.7

Might give you a little more of a hint :)

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Accepted silo 1.3.1-2 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 29 Sep 2003 10:48:07 -0400
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.3.1-2
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.3.1-2) unstable; urgency=low
 .
   * Force use of gcc-2.95 to fix some problems with illegal instruction.
Files: 
 e10bd7bb3fe7c175d27b30604099aabe 546 base important silo_1.3.1-2.dsc
 899abb145f6696d861343d0818ccde42 263558 base important silo_1.3.1-2.tar.gz
 49130013f9182926cfe99a558f5e1d69 286034 base important silo_1.3.1-2_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/eEcqfNc/ZB4E7C0RAuEHAJ9o7LBscwCP8Sa5L47gcxO2H1Qz6wCbBeFa
sOcQQEYi59LZkHOPexx2coM=
=3oX+
-END PGP SIGNATURE-


Accepted:
silo_1.3.1-2.dsc
  to pool/main/s/silo/silo_1.3.1-2.dsc
silo_1.3.1-2.tar.gz
  to pool/main/s/silo/silo_1.3.1-2.tar.gz
silo_1.3.1-2_sparc.deb
  to pool/main/s/silo/silo_1.3.1-2_sparc.deb


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

Accepted libraw1394 0.10.1-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 26 Sep 2003 09:33:52 -0400
Source: libraw1394
Binary: libraw1394-5 libraw1394-dev
Architecture: source sparc
Version: 0.10.1-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 libraw1394-5 - library for direct access to IEEE 1394 bus (aka FireWire)
 libraw1394-dev - library for direct access to IEEE 1394 bus - development files
Closes: 212394
Changes: 
 libraw1394 (0.10.1-1) unstable; urgency=low
 .
   * New upstream.
   * Fix debconf stuff. Device gets created correctly now. Closes: #212394
Files: 
 54fe22242da1fc0a901b419d030c3a73 729 libs optional libraw1394_0.10.1-1.dsc
 f243011cc20d4b7357a48732ea555e3a 338789 libs optional libraw1394_0.10.1.orig.tar.gz
 2ceea9dabd40f5a44615031b886d4ba2 20 libs optional libraw1394_0.10.1-1.diff.gz
 13d7250ab38d159f606d35efb095f0ee 101304 libdevel optional 
libraw1394-dev_0.10.1-1_sparc.deb
 1fd02a17c0896bd5ed86bd3d89cdad15 10704 libs optional libraw1394-5_0.10.1-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/dEpMfNc/ZB4E7C0RApKaAKDERGuX09bqa3OTzuHZS6JzuqQ0yACdE9VM
xcY6l4ML2alDOEC1iChLbdM=
=KUug
-END PGP SIGNATURE-


Accepted:
libraw1394-5_0.10.1-1_sparc.deb
  to pool/main/libr/libraw1394/libraw1394-5_0.10.1-1_sparc.deb
libraw1394-dev_0.10.1-1_sparc.deb
  to pool/main/libr/libraw1394/libraw1394-dev_0.10.1-1_sparc.deb
libraw1394_0.10.1-1.diff.gz
  to pool/main/libr/libraw1394/libraw1394_0.10.1-1.diff.gz
libraw1394_0.10.1-1.dsc
  to pool/main/libr/libraw1394/libraw1394_0.10.1-1.dsc
libraw1394_0.10.1.orig.tar.gz
  to pool/main/libr/libraw1394/libraw1394_0.10.1.orig.tar.gz


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

Re: Latest gcc-3.3 and kernel compilation

[Ben Collins]

   __u8 short slot_tablelen;

Isn't it just a plain error? Either it's a char, or it's a short. It
can't be both, right?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Accepted kernel-image-sparc-2.4 33 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  2 Aug 2003 11:55:22 -0400
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
scsi-modules-2.4.21-sparc64-udeb ppp-modules-2.4.21-sparc32-udeb 
kernel-image-2.4.21-sparc64-smp kernel-image-2.4.21-sparc32-smp 
kernel-image-2.4.21-sparc32 ieee1394-modules-2.4.21-sparc64-udeb 
kernel-headers-2.4.21-sparc kernel-image-2.4.21-sparc64 
ppp-modules-2.4.21-sparc64-udeb ide-modules-2.4.21-sparc64-udeb
Architecture: source sparc all
Version: 33
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ide-modules-2.4.21-sparc64-udeb - IDE drivers (udeb)
 ieee1394-modules-2.4.21-sparc64-udeb - IEEE1394 drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.21-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.21-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 ppp-modules-2.4.21-sparc32-udeb - PPP drivers (udeb)
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
 scsi-modules-2.4.21-sparc64-udeb - SCSI drivers (udeb)
Changes: 
 kernel-image-sparc-2.4 (33) unstable; urgency=low
 .
   * Add Jalapeno/Tomatillo patches for IIIi systems (Sun Fire v210/v240). The
 tigon3 chips on these system still don't work, but this is a start.
   * Enable NCPfs.
   * Add fixups for tg3 on newer Sun hardware.
   * Build tg3 into the kernel for sparc64.
   * Add patch for sparc32 and gcc-3.3.1.
   * Switch to the tulip built-in for X1's
Files: 
 39134df44a72b95f703ff988ac48c3bd 973 devel optional kernel-image-sparc-2.4_33.dsc
 e690e44c9cedfc70b6270a97c322e7a3 58803 devel optional kernel-image-sparc-2.4_33.tar.gz
 c6a8579ef918f0e638296f6de6bc74f4 1682156 devel optional 
kernel-headers-2.4.21-sparc_33_all.deb
 856ab825af4092c93ced3db4333fae5a 2750746 base optional 
kernel-image-2.4.21-sparc32_33_sparc.deb
 ff3c478796cf954e244b431cfa66a140 1041788 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_33_sparc.udeb
 f20bc463cbb37ba8197b6f8d8844af1c 56504 debian-installer extra 
ppp-modules-2.4.21-sparc32-udeb_33_sparc.udeb
 eefcc87b8aa21bd922861f08ee6aff91 2894556 base optional 
kernel-image-2.4.21-sparc32-smp_33_sparc.deb
 22bddf5c9d4bb93ede4412d7569303c2 5333740 base optional 
kernel-image-2.4.21-sparc64_33_sparc.deb
 6d08848477d44a0e0cea9c3a4b9faeff 1552000 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_33_sparc.udeb
 ee91c9575bec785ecde2fe4b0c604a1d 66682 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_33_sparc.udeb
 14533f811402299aeb03e22ac59f706f 63196 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_33_sparc.udeb
 c433143a0c6faebeb9e1a570e355e647 40090 debian-installer extra 
ide-modules-2.4.21-sparc64-udeb_33_sparc.udeb
 cfcdf0a01c3ecc42bb1e2f71c12ec69c 33654 debian-installer extra 
scsi-modules-2.4.21-sparc64-udeb_33_sparc.udeb
 368d4ecb6c49ece30f3ac559abbe42b2 5473610 base optional 
kernel-image-2.4.21-sparc64-smp_33_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/M9VffNc/ZB4E7C0RAuPgAJ9TPWKpqNWlQicPT7PcecUgAPJPRQCfd08/
myR9oKQ5FJ+pm2mhH9R6p7k=
=hM7a
-END PGP SIGNATURE-


Accepted:
ide-modules-2.4.21-sparc64-udeb_33_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ide-modules-2.4.21-sparc64-udeb_33_sparc.udeb
ieee1394-modules-2.4.21-sparc64-udeb_33_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_33_sparc.udeb
kernel-headers-2.4.21-sparc_33_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_33_all.deb
kernel-image-2.4.21-sparc32-smp_33_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-smp_33_sparc.deb
kernel-image-2.4.21-sparc32-udeb_33_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_33_sparc.udeb
kernel-image-2.4.21-sparc32_33_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32_33_sparc.deb
kernel-image-2.4.21-sparc64-smp_33_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-smp_33_sparc.deb
kernel-image-2.4.21-sparc64-udeb_33_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_33_sparc.udeb
kernel-image-2.4.21-sparc64_33_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64_33_sparc.deb
kernel-image-sparc-2.4_33.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_33.dsc
kernel-image-sparc-2.4_33.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image

Accepted silo 1.3.1-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri,  8 Aug 2003 12:59:38 -0400
Source: silo
Binary: silo
Architecture: source sparc
Version: 1.3.1-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 silo   - Sparc Improved LOader
Changes: 
 silo (1.3.1-1) unstable; urgency=low
 .
   * New upstream.
   * Rename 1440 disk images.
Files: 
 77e9763cbac0b1ab640f649ea66e2016 536 base important silo_1.3.1-1.dsc
 f4f42597c225510d3662031fd20d5001 263503 base important silo_1.3.1-1.tar.gz
 b9cacf3c68c9684e0d053c7fa59454b9 286556 base important silo_1.3.1-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/NDEXfNc/ZB4E7C0RAlO0AJ9QCQvR5nTy7cK38OEVogdgbEK8AQCfeqK+
G69SdkXFTBMu1ExBCeMKE+g=
=gs4n
-END PGP SIGNATURE-


Accepted:
silo_1.3.1-1.dsc
  to pool/main/s/silo/silo_1.3.1-1.dsc
silo_1.3.1-1.tar.gz
  to pool/main/s/silo/silo_1.3.1-1.tar.gz
silo_1.3.1-1_sparc.deb
  to pool/main/s/silo/silo_1.3.1-1_sparc.deb


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

Accepted sxid 4.0.4 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 11 Aug 2003 11:36:16 -0400
Source: sxid
Binary: sxid
Architecture: source sparc
Version: 4.0.4
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 sxid   - suid, sgid file and directory checking
Closes: 190533 204938
Changes: 
 sxid (4.0.4) unstable; urgency=low
 .
   * Added build-depends: Closes: #190533
   * User user:group syntax instead of user.group: Closes: #204938
Files: 
 584d03c86a9afb93be6e88308fb94536 515 admin extra sxid_4.0.4.dsc
 f85f1bf18651af14efd2b475b87e55b1 45277 admin extra sxid_4.0.4.tar.gz
 975e7c5354b6f010a3fe7ec477172290 22420 admin extra sxid_4.0.4_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/N7kqfNc/ZB4E7C0RAm1kAJ9thHnxZ1HkCXON3rDUPjk5NQ2HSwCgpe8H
6xAswOwM9Y1Rabo55DIMfWo=
=o8Wg
-END PGP SIGNATURE-


Accepted:
sxid_4.0.4.dsc
  to pool/main/s/sxid/sxid_4.0.4.dsc
sxid_4.0.4.tar.gz
  to pool/main/s/sxid/sxid_4.0.4.tar.gz
sxid_4.0.4_sparc.deb
  to pool/main/s/sxid/sxid_4.0.4_sparc.deb


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

Accepted kernel-image-sparc-2.4 32 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 16 Jul 2003 10:44:28 -0400
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
scsi-modules-2.4.21-sparc64-udeb ppp-modules-2.4.21-sparc32-udeb 
kernel-image-2.4.21-sparc64-smp kernel-image-2.4.21-sparc32-smp 
kernel-image-2.4.21-sparc32 ieee1394-modules-2.4.21-sparc64-udeb 
kernel-headers-2.4.21-sparc kernel-image-2.4.21-sparc64 
ppp-modules-2.4.21-sparc64-udeb ide-modules-2.4.21-sparc64-udeb
Architecture: source sparc all
Version: 32
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ide-modules-2.4.21-sparc64-udeb - IDE drivers (udeb)
 ieee1394-modules-2.4.21-sparc64-udeb - IEEE1394 drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.21-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.21-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 ppp-modules-2.4.21-sparc32-udeb - PPP drivers (udeb)
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
 scsi-modules-2.4.21-sparc64-udeb - SCSI drivers (udeb)
Changes: 
 kernel-image-sparc-2.4 (32) unstable; urgency=low
 .
   * Add patch from DaveM to get gcc-3.3 compiles working on sparc64.
   * Add patch from me to get things booting on newer OBP's.
   * Change de4x5 driver to builtin, instead of module.
Files: 
 25dfaa56412f06309835cf8a53c9960f 974 devel optional kernel-image-sparc-2.4_32.dsc
 6fa041499917ff32a516a9196efaaf8e 359145 devel optional 
kernel-image-sparc-2.4_32.tar.gz
 519097029dc773a0d8311d20b5623627 1659566 devel optional 
kernel-headers-2.4.21-sparc_32_all.deb
 58a600c5cca8f9b21b71b8b4bc56277d 2476542 base optional 
kernel-image-2.4.21-sparc32_32_sparc.deb
 ea9d009383712bf432284d885b2dd70d 911556 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_32_sparc.udeb
 a19aac98a3686ca4ca5bd2ba7c4f9253 57074 debian-installer extra 
ppp-modules-2.4.21-sparc32-udeb_32_sparc.udeb
 ebaa33a6a2c0f9ec74fc7f5a3eb6c5d0 2599552 base optional 
kernel-image-2.4.21-sparc32-smp_32_sparc.deb
 0ed0d4aff7cb8e2165995d5f1e3ecfb9 5104118 base optional 
kernel-image-2.4.21-sparc64_32_sparc.deb
 47593c4f46643c53ba5fec8d4c1f8e97 1385470 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_32_sparc.udeb
 a3453f0fa525b8fa84e664865d9fe078 67114 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_32_sparc.udeb
 036fbfd9fdcc0b97be71dc1f6a603c0b 65094 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_32_sparc.udeb
 6dd3b8c1d6bfc49ca2fe734a6e600e3b 40452 debian-installer extra 
ide-modules-2.4.21-sparc64-udeb_32_sparc.udeb
 adc036856d7f2a19c6662fa937845c27 34382 debian-installer extra 
scsi-modules-2.4.21-sparc64-udeb_32_sparc.udeb
 24308ec25c5e621bc0332d8d417f7147 5241546 base optional 
kernel-image-2.4.21-sparc64-smp_32_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/JLZMfNc/ZB4E7C0RAkKIAJ9jcZ9UnWPnZI4SDklSD7Gv6e5dyACcD/aF
SJ7v05xHB94uwbxZ5JRZUpA=
=/fCk
-END PGP SIGNATURE-


Accepted:
ide-modules-2.4.21-sparc64-udeb_32_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ide-modules-2.4.21-sparc64-udeb_32_sparc.udeb
ieee1394-modules-2.4.21-sparc64-udeb_32_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_32_sparc.udeb
kernel-headers-2.4.21-sparc_32_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_32_all.deb
kernel-image-2.4.21-sparc32-smp_32_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-smp_32_sparc.deb
kernel-image-2.4.21-sparc32-udeb_32_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_32_sparc.udeb
kernel-image-2.4.21-sparc32_32_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32_32_sparc.deb
kernel-image-2.4.21-sparc64-smp_32_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-smp_32_sparc.deb
kernel-image-2.4.21-sparc64-udeb_32_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_32_sparc.udeb
kernel-image-2.4.21-sparc64_32_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64_32_sparc.deb
kernel-image-sparc-2.4_32.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_32.dsc
kernel-image-sparc-2.4_32.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_32.tar.gz
ppp-modules-2.4.21-sparc32-udeb_32_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ppp-modules-2.4.21-sparc32-udeb_32_sparc.udeb
ppp

Accepted libraw1394 0.10.0-1 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 12 Jul 2003 20:39:39 -0400
Source: libraw1394
Binary: libraw1394-5 libraw1394-dev
Architecture: source sparc
Version: 0.10.0-1
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 libraw1394-5 - library for direct access to IEEE 1394 bus (aka FireWire)
 libraw1394-dev - library for direct access to IEEE 1394 bus - development files
Changes: 
 libraw1394 (0.10.0-1) unstable; urgency=low
 .
   * Maintainer changed to me (BenC). Taking over maintainership upstream and
 in Debian.
   * Lots of new stuff, new upstream.
Files: 
 bc5c871d2902d810ee673f6f59178c4d 729 libs optional libraw1394_0.10.0-1.dsc
 95f4e9a6dbd7543b94e2cc70562d9073 239542 libs optional libraw1394_0.10.0.orig.tar.gz
 3a042478f5adc0b182c582a09ac12181 20 libs optional libraw1394_0.10.0-1.diff.gz
 b662a7f3ad4b65f47d5e0492e3c4ba3c 101416 devel optional 
libraw1394-dev_0.10.0-1_sparc.deb
 08eaacf0370193c60bd846236bdb78a5 10726 libs optional libraw1394-5_0.10.0-1_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE/ELlEfNc/ZB4E7C0RAg4+AJ4oeiqmeNRLxlacMWOP4meUrtCkWgCfb/eu
75jisFC7PUMxUEJNoM31Uy0=
=sW5Z
-END PGP SIGNATURE-


Accepted:
libraw1394-5_0.10.0-1_sparc.deb
  to pool/main/libr/libraw1394/libraw1394-5_0.10.0-1_sparc.deb
libraw1394-dev_0.10.0-1_sparc.deb
  to pool/main/libr/libraw1394/libraw1394-dev_0.10.0-1_sparc.deb
libraw1394_0.10.0-1.diff.gz
  to pool/main/libr/libraw1394/libraw1394_0.10.0-1.diff.gz
libraw1394_0.10.0-1.dsc
  to pool/main/libr/libraw1394/libraw1394_0.10.0-1.dsc
libraw1394_0.10.0.orig.tar.gz
  to pool/main/libr/libraw1394/libraw1394_0.10.0.orig.tar.gz


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

Re: Package signatures tools

[Ben Collins]

On Fri, Jul 11, 2003 at 05:47:10PM +0200, J?rgen A.Erhard wrote:
 I'm releasing these things now... have them in development and use for
 a couple weeks/months now.
 
 A Python module for doing debsigs-type package signatures and
 verification thereof.  Uses and included module for GnuPG file
 signatures and verification.
 
 It also includes a miniscript that, given a .changes file, signs the
 .deb, the .dsc and the .changes file (with the md5s in .changes
 adjusted).
 
jerhard.org/files/python-debsigs-snapshot.tar.gz

Is this based on debsigs and debsigs-verify?


-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Package signatures tools

[Ben Collins]

On Fri, Jul 11, 2003 at 05:47:10PM +0200, J?rgen A.Erhard wrote:
 I'm releasing these things now... have them in development and use for
 a couple weeks/months now.
 
 A Python module for doing debsigs-type package signatures and
 verification thereof.  Uses and included module for GnuPG file
 signatures and verification.


Also, I think using any scripted tool to do the verification is asking
for security holes. It pulls in too many variables on which verification
needs to depend. The debsigs-verify tool does the verification and xml
parsing all in one C program.

What did you find wrong with the current tools already available and
documented? The only thing they need is policy to get them going. Dpkg
can already call debsig-verify to validate a package. It just needs to
be turned on.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: gcc on a biarch system

[Ben Collins]

On Sat, Jul 05, 2003 at 01:44:31PM -0400, Bart Trojanowski wrote:
 On amd64, we currently have a biarch-gcc that builds 32bit binaries by
 default, and 64bit ones with a -m64 option.  Coding debian/rules for this
 is pretty trivial but still requires some ugly architecture specific
 hacks in each debian/rules.

Welcome to sparc64's world. This issue may never get resolved. Sparc64
had to deal with it, then ia64. We've never been able to come up with a
decent situation that's supported by dpkg and tools.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Accepted kernel-image-sparc-2.4 30 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun,  8 Jun 2003 16:36:05 -0400
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
scsi-modules-2.4.21-sparc64-udeb ppp-modules-2.4.21-sparc32-udeb 
kernel-image-2.4.21-sparc64-smp kernel-image-2.4.21-sparc32-smp 
kernel-image-2.4.21-sparc32 ieee1394-modules-2.4.21-sparc64-udeb 
kernel-headers-2.4.21-sparc kernel-image-2.4.21-sparc64 
ppp-modules-2.4.21-sparc64-udeb ide-modules-2.4.21-sparc64-udeb
Architecture: source sparc all
Version: 30
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ide-modules-2.4.21-sparc64-udeb - IDE drivers (udeb)
 ieee1394-modules-2.4.21-sparc64-udeb - IEEE1394 drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.21-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.21-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 ppp-modules-2.4.21-sparc32-udeb - PPP drivers (udeb)
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
 scsi-modules-2.4.21-sparc64-udeb - SCSI drivers (udeb)
Closes: 196502
Changes: 
 kernel-image-sparc-2.4 (30) unstable; urgency=low
 .
   * Add all NLS modules. Enable some advanced router options on sparc64.
 Enable sun12x22 font. Change cdrom/ide-cd/sr_mod to modules in sparc64.
 Closes: #196502
   * Make loopback block device compiled into sparc32.
   * Do not compress the udeb kernels.
   * Add new ide/scsi module udeb's for sparc64.
Files: 
 7baa4a461b8a4d5935bf4d9c0f8b 975 devel optional kernel-image-sparc-2.4_30.dsc
 681d7bf661ea082f289a3beb54efe9e5 5093108 devel optional 
kernel-image-sparc-2.4_30.tar.gz
 09500362cb9bfc8575e3f7f76ff66809 1659376 devel optional 
kernel-headers-2.4.21-sparc_30_all.deb
 1d9fe491c339f7407ed6d91c65b14e48 2470118 base optional 
kernel-image-2.4.21-sparc32_30_sparc.deb
 1deb4725076941e38653346d67aeb3e6 909056 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_30_sparc.udeb
 595f88e0401944dd55cbe47ad2f22172 57078 debian-installer extra 
ppp-modules-2.4.21-sparc32-udeb_30_sparc.udeb
 353ad9dda1cecad4d582715ba3819b68 2597284 base optional 
kernel-image-2.4.21-sparc32-smp_30_sparc.deb
 229b8f26547b3c5b2932c855c98f5784 5105150 base optional 
kernel-image-2.4.21-sparc64_30_sparc.deb
 698e7fc6114bbfa37d534b713433231c 1361376 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_30_sparc.udeb
 0697d32d6f1a4e8e09fd67b5013e72bb 67124 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_30_sparc.udeb
 16c6251436cb5d348d1789f5df43ea4e 65100 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_30_sparc.udeb
 549d39f0ef78fbae3aa2a1daa2f4198e 40458 debian-installer extra 
ide-modules-2.4.21-sparc64-udeb_30_sparc.udeb
 139d2eba4e15d52e5421d7894e1a999b 34386 debian-installer extra 
scsi-modules-2.4.21-sparc64-udeb_30_sparc.udeb
 f7a4b3acf77ecb91e04263c806af0332 5242522 base optional 
kernel-image-2.4.21-sparc64-smp_30_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+5czWfNc/ZB4E7C0RAiY2AJ9kAcMKAhNm/sU0N47/wvtWxct27ACgtZ18
7xXOYcleqGxjVMuBoO8ySXg=
=iZlM
-END PGP SIGNATURE-


Accepted:
ide-modules-2.4.21-sparc64-udeb_30_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ide-modules-2.4.21-sparc64-udeb_30_sparc.udeb
ieee1394-modules-2.4.21-sparc64-udeb_30_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_30_sparc.udeb
kernel-headers-2.4.21-sparc_30_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_30_all.deb
kernel-image-2.4.21-sparc32-smp_30_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-smp_30_sparc.deb
kernel-image-2.4.21-sparc32-udeb_30_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_30_sparc.udeb
kernel-image-2.4.21-sparc32_30_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32_30_sparc.deb
kernel-image-2.4.21-sparc64-smp_30_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-smp_30_sparc.deb
kernel-image-2.4.21-sparc64-udeb_30_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_30_sparc.udeb
kernel-image-2.4.21-sparc64_30_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64_30_sparc.deb
kernel-image-sparc-2.4_30.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_30.dsc
kernel-image-sparc-2.4_30.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_30

Accepted kernel-image-sparc-2.4 31 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 10 Jun 2003 11:22:31 -0400
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
scsi-modules-2.4.21-sparc64-udeb ppp-modules-2.4.21-sparc32-udeb 
kernel-image-2.4.21-sparc64-smp kernel-image-2.4.21-sparc32-smp 
kernel-image-2.4.21-sparc32 ieee1394-modules-2.4.21-sparc64-udeb 
kernel-headers-2.4.21-sparc kernel-image-2.4.21-sparc64 
ppp-modules-2.4.21-sparc64-udeb ide-modules-2.4.21-sparc64-udeb
Architecture: source sparc all
Version: 31
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ide-modules-2.4.21-sparc64-udeb - IDE drivers (udeb)
 ieee1394-modules-2.4.21-sparc64-udeb - IEEE1394 drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.21-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.21-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 ppp-modules-2.4.21-sparc32-udeb - PPP drivers (udeb)
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
 scsi-modules-2.4.21-sparc64-udeb - SCSI drivers (udeb)
Changes: 
 kernel-image-sparc-2.4 (31) unstable; urgency=low
 .
   * *sigh* Debian-installer requires tmpfs in addition to ramfs.
Files: 
 0782787dfb104042451b1af060807c84 975 devel optional kernel-image-sparc-2.4_31.dsc
 c1038daca54a72d248cba16feccf92ee 5093132 devel optional 
kernel-image-sparc-2.4_31.tar.gz
 df8fcd273c5b6b183b2c07c677622730 1659524 devel optional 
kernel-headers-2.4.21-sparc_31_all.deb
 819f97abdb6cf2862fcc915b39b50293 2474844 base optional 
kernel-image-2.4.21-sparc32_31_sparc.deb
 0ddf00ff1a5a04f77857ee8693ca69af 911540 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_31_sparc.udeb
 467c70e6cfc25dbdef24288c58b5ca5d 57078 debian-installer extra 
ppp-modules-2.4.21-sparc32-udeb_31_sparc.udeb
 82b2e5bcf28341f904ea4e06e118f428 2598940 base optional 
kernel-image-2.4.21-sparc32-smp_31_sparc.deb
 3db01cb1e460b1beafe1e3414268868b 5106082 base optional 
kernel-image-2.4.21-sparc64_31_sparc.deb
 143abb9c3a35428eeadb282a16710059 1363328 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_31_sparc.udeb
 666472b8a333cfe03654ed2555f9d690 67116 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_31_sparc.udeb
 a2234e6b6d64706e23842aa9a89b247e 65094 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_31_sparc.udeb
 74e9fae165765f2cc646a512d4002fc9 40458 debian-installer extra 
ide-modules-2.4.21-sparc64-udeb_31_sparc.udeb
 cb3e635a35c6ea20760e777f436549e4 34386 debian-installer extra 
scsi-modules-2.4.21-sparc64-udeb_31_sparc.udeb
 12d93b45132f7c4eb625b3deab00f2b3 5246796 base optional 
kernel-image-2.4.21-sparc64-smp_31_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+6bkGfNc/ZB4E7C0RAruqAJ41+JgmMzP3/rZtsXWvQT59bDpx0gCgkiIt
kl4P8XNggIjfioY57UfpOfk=
=Ll4F
-END PGP SIGNATURE-


Accepted:
ide-modules-2.4.21-sparc64-udeb_31_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ide-modules-2.4.21-sparc64-udeb_31_sparc.udeb
ieee1394-modules-2.4.21-sparc64-udeb_31_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_31_sparc.udeb
kernel-headers-2.4.21-sparc_31_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_31_all.deb
kernel-image-2.4.21-sparc32-smp_31_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-smp_31_sparc.deb
kernel-image-2.4.21-sparc32-udeb_31_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_31_sparc.udeb
kernel-image-2.4.21-sparc32_31_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32_31_sparc.deb
kernel-image-2.4.21-sparc64-smp_31_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-smp_31_sparc.deb
kernel-image-2.4.21-sparc64-udeb_31_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_31_sparc.udeb
kernel-image-2.4.21-sparc64_31_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64_31_sparc.deb
kernel-image-sparc-2.4_31.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_31.dsc
kernel-image-sparc-2.4_31.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_31.tar.gz
ppp-modules-2.4.21-sparc32-udeb_31_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ppp-modules-2.4.21-sparc32-udeb_31_sparc.udeb
ppp-modules-2.4.21-sparc64-udeb_31_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ppp-modules-2.4.21-sparc64

Accepted kernel-image-sparc-2.4 29 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  4 Jun 2003 19:40:14 -0400
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
ppp-modules-2.4.21-sparc32-udeb kernel-image-2.4.21-sparc64-smp 
kernel-image-2.4.21-sparc32-smp kernel-image-2.4.21-sparc32 
ieee1394-modules-2.4.21-sparc64-udeb kernel-headers-2.4.21-sparc 
kernel-image-2.4.21-sparc64 ppp-modules-2.4.21-sparc64-udeb
Architecture: source sparc all
Version: 29
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ieee1394-modules-2.4.21-sparc64-udeb - IEEE1394 drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32 - Linux kernel binary image for sun4c, sun4m and sun4d.
 kernel-image-2.4.21-sparc32-smp - Linux kernel binary image for SMP sun4m and sun4d.
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64 - Linux kernel binary image for UltraSPARC (sparc64) 
systems.
 kernel-image-2.4.21-sparc64-smp - Linux kernel binary image for SMP UltraSPARC 
(sparc64) systems.
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 ppp-modules-2.4.21-sparc32-udeb - PPP drivers (udeb)
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
Changes: 
 kernel-image-sparc-2.4 (29) unstable; urgency=low
 .
   * Fix description of IEEE1394 udeb package.
   * Compress udeb kernels.
   * Fix name and location of udeb kernels.
   * Add sun4cdm and sun4dm-smp builds.
   * Convert everything to the sparc32/sparc64 naming scheme.
   * Fixup options to include forgotten initrd in sparc64, and forgotten
 nfsroot support.
   * Update build-deps:
 - bzip2 uneeded, since kernel-source deps on it.
 - gcc = 4:3.2-6, to get working 64-bit compiler.
 - kernel-source-2.4 - kernel-source-2.4.20: More strict source dep.
 - egcs64: Removed, obsoleted.
   * Patches from Dave:
 [SPARC64]: RAID_AUTORUN is a compatible ioctl.
 [SPARC64]: Fix sys_shmat handling for 64-bit binaries.
Files: 
 e351bee90e2db8e9c687b6942607cae1 908 devel optional kernel-image-sparc-2.4_29.dsc
 938d0c233cb1f13aa0ae25e670dfd73f 4829558 devel optional 
kernel-image-sparc-2.4_29.tar.gz
 0c252c83eb72253e95ce3d47e30a758e 1608784 devel optional 
kernel-headers-2.4.21-sparc_29_all.deb
 b424515b04fa21734a340ad3ca8d0c27 2171220 base optional 
kernel-image-2.4.21-sparc32_29_sparc.deb
 4c499068e64cad61a77d58f0420a056d 896432 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_29_sparc.udeb
 99742fb9e056bcd52364e69850d98fd5 58294 debian-installer extra 
ppp-modules-2.4.21-sparc32-udeb_29_sparc.udeb
 3851fc63de9b432a942049cb201859dc 2296216 base optional 
kernel-image-2.4.21-sparc32-smp_29_sparc.deb
 3ad53e37e248fe1907e937ae1eaba4d8 4759394 base optional 
kernel-image-2.4.21-sparc64_29_sparc.deb
 1f5b648d216d1b82f838b1aeb7d48886 1377364 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_29_sparc.udeb
 bdee0471034b7a97a95a4111a461cc54 67450 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_29_sparc.udeb
 9126b6648d8f3bef01a6ee90fd02ff3b 58836 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_29_sparc.udeb
 54b91a2a6edcb6cffe334e793433a08f 4895862 base optional 
kernel-image-2.4.21-sparc64-smp_29_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+35uzfNc/ZB4E7C0RAi+RAJsFwADYa+/lLaMGGYKxv5XNrXnANwCgmhMK
KhBFU/pnnEXRuMAvrYFbSH0=
=Tx4i
-END PGP SIGNATURE-


Accepted:
ieee1394-modules-2.4.21-sparc64-udeb_29_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_29_sparc.udeb
kernel-headers-2.4.21-sparc_29_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_29_all.deb
kernel-image-2.4.21-sparc32-smp_29_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-smp_29_sparc.deb
kernel-image-2.4.21-sparc32-udeb_29_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_29_sparc.udeb
kernel-image-2.4.21-sparc32_29_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32_29_sparc.deb
kernel-image-2.4.21-sparc64-smp_29_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-smp_29_sparc.deb
kernel-image-2.4.21-sparc64-udeb_29_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_29_sparc.udeb
kernel-image-2.4.21-sparc64_29_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64_29_sparc.deb
kernel-image-sparc-2.4_29.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_29.dsc
kernel-image-sparc-2.4_29.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_29.tar.gz
ppp-modules-2.4.21-sparc32-udeb_29_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ppp-modules-2.4.21-sparc32-udeb_29_sparc.udeb
ppp-modules-2.4.21-sparc64

Accepted gcc-defaults 1.7 (sparc source)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  4 Jun 2003 11:39:53 -0400
Source: gcc-defaults
Binary: gobjc gij gcj g++ gcc cpp g77 gpc chill
Architecture: source sparc
Version: 1.7
Distribution: unstable
Urgency: low
Maintainer: Debian GCC maintainers [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 chill  - The GNU CHILL compiler.
 cpp- The GNU C preprocessor.
 g++- The GNU C++ compiler.
 g77- The GNU Fortran 77 compiler.
 gcc- The GNU C compiler.
 gcj- The GNU Java compiler.
 gij- The GNU Java bytecode interpreter.
 gobjc  - The GNU Objective-C compiler.
 gpc- The GNU Pascal compiler.
Changes: 
 gcc-defaults (1.7) unstable; urgency=low
 .
   * Add GNU_TYPE-{cpp,gcc,g++,gcj,g77} symlinks.
   * Bump sparc back down to 3.2. Increase our epoch to compensate.
Files: 
 f4f2a5ee62789bd5b340a2443984861d 716 devel standard gcc-defaults_1.7.dsc
 5f3bacfe6645101c39301ba2f8458a30 29366 devel standard gcc-defaults_1.7.tar.gz
 a07202eb02ca6543bc2da1edf39bed4e 25840 interpreters standard cpp_3.2-6_sparc.deb
 043e11499bef1667d1e1d8f3d3b11dbf 5016 devel standard gcc_3.2-6_sparc.deb
 1bae345f67f3e137f8d14011143d2148 1564 devel standard g++_3.2-6_sparc.deb
 859e14923fe465afd9ac192342cd7baa 1100 devel optional gobjc_3.2-6_sparc.deb
 0b4a1997647ecd262a09f6de58d019ec 1428 devel optional g77_3.2-6_sparc.deb
 33880fd812588cd852c123da952b683d 1560 devel optional gpc_2.95.4-22_sparc.deb
 68aa67bbb307097345986bb73844a5cc 1448 devel optional gcj_3.2-6_sparc.deb
 ee4202f71bf5c9475f534df07686a43d 1408 devel optional gij_3.2-6_sparc.deb
 ba52c6303ffe5168e0f74240d7fc2a49 1316 devel extra chill_2.95.4-22_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+3hMzfNc/ZB4E7C0RAnKiAJ0RPIidckpQPOh8H+VyuPZW0G+w9gCdFUr7
b2PvhUQcmC2Hqn5Dyuz+3ik=
=gFK2
-END PGP SIGNATURE-


Accepted:
chill_2.95.4-22_sparc.deb
  to pool/main/g/gcc-defaults/chill_2.95.4-22_sparc.deb
cpp_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/cpp_3.2-6_sparc.deb
g++_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/g++_3.2-6_sparc.deb
g77_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/g77_3.2-6_sparc.deb
gcc-defaults_1.7.dsc
  to pool/main/g/gcc-defaults/gcc-defaults_1.7.dsc
gcc-defaults_1.7.tar.gz
  to pool/main/g/gcc-defaults/gcc-defaults_1.7.tar.gz
gcc_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/gcc_3.2-6_sparc.deb
gcj_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/gcj_3.2-6_sparc.deb
gij_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/gij_3.2-6_sparc.deb
gobjc_3.2-6_sparc.deb
  to pool/main/g/gcc-defaults/gobjc_3.2-6_sparc.deb
gpc_2.95.4-22_sparc.deb
  to pool/main/g/gcc-defaults/gpc_2.95.4-22_sparc.deb


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

Accepted kernel-image-sparc-2.4 28 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 20 Feb 2003 15:49:40 -0500
Source: kernel-image-sparc-2.4
Binary: kernel-image-2.4.21-sparc64-udeb kernel-image-2.4.21-sparc32-udeb 
ieee1394-modules-2.4.21-sparc64-udeb kernel-image-2.4.21-sun4u 
ppp-modules-2.4.21-sparc64-udeb kernel-headers-2.4.21-sparc 
kernel-image-2.4.21-sun4u-smp
Architecture: source sparc all
Version: 28
Distribution: unstable
Urgency: low
Maintainer: Ben Collins [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 ieee1394-modules-2.4.21-sparc64-udeb - IDE drivers (udeb)
 kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures
 kernel-image-2.4.21-sparc32-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sparc64-udeb - Kernel Image (udeb)
 kernel-image-2.4.21-sun4u - Linux kernel binary image for UltraSPARC (sun4u) systems.
 kernel-image-2.4.21-sun4u-smp - Linux kernel binary image for SMP UltraSPARC (sun4u) 
systems.
 ppp-modules-2.4.21-sparc64-udeb - PPP drivers (udeb)
Closes: 107596 122740 158741 183044
Changes: 
 kernel-image-sparc-2.4 (28) unstable; urgency=low
 .
   * 2.4.20 Sources with 2.4.21 patches.
   * Include udeb's for sparc32 and sparc64. Closes: #158741
   * Packet/Filter/Netfilter included in kernel. Closes: #122740, #107596
   * Fix for ALi (Sun Blade 100) DMA corruption.
   * Patch to fix UltraSPARC-1 Happy Meal lockups: Closes: #183044
Files: 
 177ef7c9cd144361dc493d4ed1d348b9 803 base optional kernel-image-sparc-2.4_28.dsc
 47112e870bf5bd22f75acbf36dfc0d38 4835252 base optional 
kernel-image-sparc-2.4_28.tar.gz
 ca027e0ba4395f253fc25f7c43e82195 1606852 devel optional 
kernel-headers-2.4.21-sparc_28_all.deb
 b06882f55a508ab8d985f29a4de4ec97 4732588 base optional 
kernel-image-2.4.21-sun4u_28_sparc.deb
 c77273515eedff114dc2c98c107bedc5 4864944 base optional 
kernel-image-2.4.21-sun4u-smp_28_sparc.deb
 fac187fcb7c10a05f3e771c3821f5765 812494 debian-installer extra 
kernel-image-2.4.21-sparc32-udeb_28_sparc.udeb
 7ea017cbf9d61446e6f6261bfee3de6f 1351348 debian-installer extra 
kernel-image-2.4.21-sparc64-udeb_28_sparc.udeb
 db3d7668e26b1fcb16d6dad43288ebbc 67378 debian-installer extra 
ieee1394-modules-2.4.21-sparc64-udeb_28_sparc.udeb
 7f011586c1b54896d02986b5462bffe1 58668 debian-installer extra 
ppp-modules-2.4.21-sparc64-udeb_28_sparc.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+3l3RfNc/ZB4E7C0RAs3RAJ9GIZ9bf4ouPn3TgeGKNT/GBN8XjgCbBo2A
jyaTaUq22u6Sg2PrToakjbU=
=ofak
-END PGP SIGNATURE-


Accepted:
ieee1394-modules-2.4.21-sparc64-udeb_28_sparc.udeb
  to 
pool/main/k/kernel-image-sparc-2.4/ieee1394-modules-2.4.21-sparc64-udeb_28_sparc.udeb
kernel-headers-2.4.21-sparc_28_all.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-headers-2.4.21-sparc_28_all.deb
kernel-image-2.4.21-sparc32-udeb_28_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc32-udeb_28_sparc.udeb
kernel-image-2.4.21-sparc64-udeb_28_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sparc64-udeb_28_sparc.udeb
kernel-image-2.4.21-sun4u-smp_28_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sun4u-smp_28_sparc.deb
kernel-image-2.4.21-sun4u_28_sparc.deb
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-2.4.21-sun4u_28_sparc.deb
kernel-image-sparc-2.4_28.dsc
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_28.dsc
kernel-image-sparc-2.4_28.tar.gz
  to pool/main/k/kernel-image-sparc-2.4/kernel-image-sparc-2.4_28.tar.gz
ppp-modules-2.4.21-sparc64-udeb_28_sparc.udeb
  to pool/main/k/kernel-image-sparc-2.4/ppp-modules-2.4.21-sparc64-udeb_28_sparc.udeb


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

Accepted gcc-3.2 1:3.2.3ds9-4 (sparc source all)

[Ben Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  2 Jun 2003 23:43:04 +0200
Source: gcc-3.2
Binary: gcc-3.2-base libstdc++5-dev cpp-3.2-doc libgcj3-dev libobjc1 libstdc++5-doc 
libgcc1 libstdc++5 protoize g77-3.2-doc libstdc++5-dbg gobjc-3.2 g++-3.2 gnat-3.2-doc 
gcc-3.2 gpc-2.1-3.2-doc libstdc++5-pic g77-3.2 libgcj3 gpc-2.1-3.2 gcc-3.2-soft-float 
gcj-3.2 libgcj-common libffi libffi-dev libgnat3.15a fastjar gcc-3.2-doc gcc-3.2-nof 
libg2c0 fixincludes gij-3.2 cpp-3.2 gnat-3.2
Architecture: source sparc all
Version: 1:3.2.3ds9-4
Distribution: unstable
Urgency: low
Maintainer: Debian GCC maintainers [EMAIL PROTECTED]
Changed-By: Ben Collins [EMAIL PROTECTED]
Description: 
 cpp-3.2- The GNU C preprocessor
 cpp-3.2-doc - Documentation for the GNU C preprocessor (cpp)
 g++-3.2- The GNU C++ compiler
 g77-3.2- The GNU Fortran 77 compiler
 g77-3.2-doc - Documentation for the GNU Fortran compiler (g77)
 gcc-3.2- The GNU C compiler
 gcc-3.2-base - The GNU Compiler Collection (base package)
 gcc-3.2-doc - Documentation for the GNU compilers (gcc, gobjc, g++)
 gnat-3.2   - The GNU Ada compiler
 gnat-3.2-doc - Documentation for the GNU Ada compiler (gnat)
 gobjc-3.2  - The GNU Objective-C compiler
 libstdc++5-dbg - The GNU Standard C++ Library v3 (debugging files)
 libstdc++5-dev - The GNU Standard C++ Library v3 (development files)
 libstdc++5-doc - The GNU Standard C++ Library v3 (documentation files)
 libstdc++5-pic - The GNU Standard C++ Library v3 (shared library subset kit)
Closes: 189466
Changes: 
 gcc-3.2 (1:3.2.3ds9-4) unstable; urgency=low
 .
   * Add GNU_TYPE-{cpp,gcc,g++,gcj,g77} symlinks (closes: #189466).
   * Make sure not to build using binutils-2.14.90.0.[12].
   * Re-enable 64-bit capable gcc on sparc.
Files: 
 de5c47d97fe2821be874e0512f3e5abd 2246 devel optional gcc-3.2_3.2.3ds9-4.dsc
 11c817e366fe5de410874748c142267b 1854154 devel optional gcc-3.2_3.2.3ds9-4.diff.gz
 4629d661105f1da9a7e546b22fc8e330 84304 doc optional cpp-3.2-doc_3.2.3-4_all.deb
 4a1472adad3e63d185693392ad44554b 1419526 doc optional libstdc++5-doc_3.2.3-4_all.deb
 0866fcce6b0823877d7da2e16519192c 309486 doc optional g77-3.2-doc_3.2.3-4_all.deb
 9a4987f09ca20a37a88b9fe26387523d 346320 doc optional gnat-3.2-doc_3.2.3-4_all.deb
 94609633b2de190568e18efc83a89cd9 631304 doc optional gcc-3.2-doc_3.2.3-4_all.deb
 f0cfe7642ae50a5fff7275791c546935 128772 devel important gcc-3.2-base_3.2.3-4_sparc.deb
 3061472a9bc207da1325931305db8b3d 125982 interpreters optional 
cpp-3.2_3.2.3-4_sparc.deb
 59003901eb5c0c6a79358fc977f4dce2 1305682 devel optional gobjc-3.2_3.2.3-4_sparc.deb
 7e2bda09df8f0832a2c064c154f4bcf2 1570486 devel optional g++-3.2_3.2.3-4_sparc.deb
 40d759d2b786dc41b19d79bd087142f3 764284 libdevel optional 
libstdc++5-dev_3.2.3-4_sparc.deb
 af24d596d4a6af27cb500465cdc0e819 314280 libdevel extra 
libstdc++5-pic_3.2.3-4_sparc.deb
 f7f180a761a6a0068c527300c1a0534b 1524382 libdevel extra 
libstdc++5-dbg_3.2.3-4_sparc.deb
 73137cfa712875e8066da71124ae21cc 1455380 devel optional g77-3.2_3.2.3-4_sparc.deb
 23c8396e2c0a6f5e93979e542eeb35e7 5816064 devel optional gnat-3.2_3.2.3-4_sparc.deb
 c7c13d2a707c20986831392c3ccd2a56 2294574 devel optional gcc-3.2_3.2.3-4_sparc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Ben Collins [EMAIL PROTECTED]

iD8DBQE+3oX6fNc/ZB4E7C0RArE8AJ93yAZvSruHQsuL6tAgpkiuu3ZJJgCeLaKt
U9Iu9TyLI9omEG6BaHjw6Eo=
=tLtj
-END PGP SIGNATURE-


Accepted:
cpp-3.2-doc_3.2.3-4_all.deb
  to pool/main/g/gcc-3.2/cpp-3.2-doc_3.2.3-4_all.deb
cpp-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/cpp-3.2_3.2.3-4_sparc.deb
g++-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/g++-3.2_3.2.3-4_sparc.deb
g77-3.2-doc_3.2.3-4_all.deb
  to pool/main/g/gcc-3.2/g77-3.2-doc_3.2.3-4_all.deb
g77-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/g77-3.2_3.2.3-4_sparc.deb
gcc-3.2-base_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/gcc-3.2-base_3.2.3-4_sparc.deb
gcc-3.2-doc_3.2.3-4_all.deb
  to pool/main/g/gcc-3.2/gcc-3.2-doc_3.2.3-4_all.deb
gcc-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/gcc-3.2_3.2.3-4_sparc.deb
gcc-3.2_3.2.3ds9-4.diff.gz
  to pool/main/g/gcc-3.2/gcc-3.2_3.2.3ds9-4.diff.gz
gcc-3.2_3.2.3ds9-4.dsc
  to pool/main/g/gcc-3.2/gcc-3.2_3.2.3ds9-4.dsc
gnat-3.2-doc_3.2.3-4_all.deb
  to pool/main/g/gcc-3.2/gnat-3.2-doc_3.2.3-4_all.deb
gnat-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/gnat-3.2_3.2.3-4_sparc.deb
gobjc-3.2_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/gobjc-3.2_3.2.3-4_sparc.deb
libstdc++5-dbg_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/libstdc++5-dbg_3.2.3-4_sparc.deb
libstdc++5-dev_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/libstdc++5-dev_3.2.3-4_sparc.deb
libstdc++5-doc_3.2.3-4_all.deb
  to pool/main/g/gcc-3.2/libstdc++5-doc_3.2.3-4_all.deb
libstdc++5-pic_3.2.3-4_sparc.deb
  to pool/main/g/gcc-3.2/libstdc++5-pic_3.2.3-4_sparc.deb


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

Re: appropriate use of /etc/alternatives

[Ben Collins]

On Fri, May 30, 2003 at 02:29:42PM -0400, Noah Meyerhans wrote:
 I intend to package the xplot utility from xplot.org.  This tool is
 useful with the tcptrace package, which I maintain.  However, there's
 already an xplot package that installs /usr/bin/xplot.  It's not
 compatible with xplot.org, but does essentially the same thing (plots
 data in X).
 
 I suggested to the xplot maintainer, Peter Galbraith, that we use
 /etc/alternatives to manage a /usr/bin/xplot symlink.  He doesn't think
 that it's an appropriate use of alternatives, since the tools are not
 compatible.  Do others agree?  On what level do tools need to be
 compatible in order to go into alternatives?  I'm sure there are a
 number of examples of alternatives that are incompatible on at least
 some level (think nvi and vim config files, for example), but they do
 essentially the same thing.

I agree. A user should not have to concern themselves about which one
they are using. If the command name is the same, they better support the
same functionality.

Sounds to me like you don't even want to call the package just xplot, to
avoid confusion. Maybe xplot-ng? :)


-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Cross-compiler for sparc64

[Ben Collins]

On Thu, May 29, 2003 at 02:17:05PM +0200, Martin Pitt wrote:
 Hi to all!
 
 Kernel 2.6 is to be released soon (hopefully), thus I tried to compile
 2.5.69 on sparc64 recently. For those not knowing this arch: kernel is
 64 bit, userland is 32 bit, thus you need a cross-compiler with host
 sparc32 and target sparc64 to compile a kernel.
 
 The problem is that the currently provided cross-compiler in package
 egcs64 is _very_ old (1998) and does not work for 2.5.x any more;
 OTOH, the provided gcc does not support cross-compiling to 64-bit.

Wrong and wrong. egcs64 will build 2.5.x, but it is not supported
anymore. You can comment out the error in init/main.c and get working
kernel.

Also, gcc-3.3 will compile 64bit kernels, but they do not boot.

 Are there any plans to provide a recent version? IMHO the package egcs
 should be dropped completely, since egcs is history for a long time
 now...

You presume too much. egcs64 is still the prefered compiler for 2.4.x
sparc64 kernels, and 2.6 wont be around for awhile.

I do have a gcc-3.2.3 64bit compiler available from
http://www.phunnypharm.org/~bcollins/sparc/ as an interim solution. In
the long run, I hope to have gcc-3.3 building working sparc64 kernels.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Very uneven distribution of packages per maintainer

[Ben Collins]

On Sat, May 24, 2003 at 11:25:03PM +1000, Russell Coker wrote:
 On Sat, 24 May 2003 22:15, Petter Reinholdtsen wrote:
  Because in Debian there is a few people with high load in debian,
  and many with less load.  People with high load are more likely to
  burn out and disappear.  It is thus better to have more people with
  less load.
 
  Of course, the packages per developer is not a perfect indicator of
  load, but it is an indicator.
 
 Sometimes you can have an easy source package that produces several other 
 packages.  Sometimes you can have a difficult source package that only 
 produces one package.
 
 Then there's the issue of upstream maintainers who are also Debian 
 developers, 
 being the active upstream developer can be enough work that developing any 
 other Debian packages would take too much time.
 
 Even if you had a metric for measuring the amount of work a developer was 
 doing, that wouldn't gain you anything.  We can't force people who have a 
 small number of packages to take on more work, and we don't want to 
 discourage them from contributing altogether.

Not to mention those that are paid to work on Debian (Hello HP :) and
those who have full time jobs that are irrelevant to anything they do
for Debian. Then we could get into single/married, kids, hobbies, etc.

Even that is little indicator. I know folks who's job has nothing to do
with Debian, but they do more work than people who are paid to work on
Debian. It's all about motivation, and no person is doing anything
wrong. It's a personal choice how much time and energy you devote to
Debian. As long as that number isn't zero, then you are welcome to stay.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Very uneven distribution of packages per maintainer

[Ben Collins]

On Fri, May 23, 2003 at 11:53:05PM +0200, Petter Reinholdtsen wrote:
 
 I just ran some stats on my APT sources (mostly Woody), and discovered
 that the distribution of number of packages per developer is very
 uneven.  This is the histogram of developers with the specific number
 of packages they maintain:

This is terrible! Wait, I forgot, these numbers mean absolutely nothing.

I'm not sure what you think these numbers represent, but it's like
taking a ratio for each family in a neighborhood of acres/child and
deciding if those kids have too much yard work.

Oh no, the Collins family has 2 acres per child...those poor kids! Uh,
you say that 3.5 acres of your yard is a lake?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: alioth.debian.org down

[Ben Collins]

On Tue, May 20, 2003 at 11:23:51AM +0200, J?r?me Marant wrote:
 En r?ponse ? Stefano Zacchiroli [EMAIL PROTECTED]:
 
  Alioth seems to be down, pings seems to stop at gatekeeper.terena.nl
  ...
  
  Was this expected?
 
 Yes, and no.
 
 No, because it is a connection failure.
 Yes, because the machine is a ia64 ;-)

Connection failure? I saw the machine output a halt message from root
just before I got disconnected and it went down.

Oh, and I've never had problems with the ia64 I am using :)

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Executable /lib/ld-linux.so breaks noexec

[Ben Collins]

 That behavior always struck me as fairly evil -- it's never fun when one
 single bit flip can take down a system, and I'd like to see the number
 of bits that can do so be as small as possible. Now that you point out
 the actual code I wish we could do away with that check. Does it really
 buy anything for elf executables?

It could be as simple as some specification requiring that the INTERP be
executable. Maybe there's some magic in the ELF spec that requires that
behavior.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Debian conference in the US?

[Ben Collins]

 What are other developers' feelings on the matter these days?

If we're doing let's have a conf where we normally don't how about we
have it on the US's east coast aswell. I'd personally argue for the
nothern Virginia are myself.

Too many conferences are held on the US's West coast, and if conferences
do get to the East coast, they are always in New York. That leaves the
south eastern US folks out in the cold.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Ben Collins]

 ==
 
 PROPOSAL
 __
 
  Constitutional amendment: Condorcet/Clone Proof SSD  vote tallying:
 __

I second this resolution.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/


pgpB7NFmay7mo.pgp
Description: PGP signature

Re: Debian MIA check

[Ben Collins]

 On the 12th March I sent out a maintainer ping to 191 possibly
 inactive Debian developers.  The list of developers was generated by
 looking first at all maintainers who didn't have a source package
 signed by (one of) their key(s) in unstable and then excluding from
 that anyone who had been seen (with a signed message) by echelon in
 the last 6 months.

Nice job. It's about time we got this under control.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: i386 compatibility libstdc++

[Ben Collins]

On Fri, Apr 25, 2003 at 12:13:08PM +0300, Lars Wirzenius wrote:
 On pe, 2003-04-25 at 11:09, Martin v. L?wis wrote:
  They just don't support i386 anymore.
  
  http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html
  http://www.redhat.com/software/linux/technical/
  
  You got to have a Pentium+ for these distributions.
  
  This is quite reasonable, IMO: People with older hardware
  can use older versions of these distributions (which they are
  running probably already, anyway).
 
 So using a 386 as a router and firewall, which it is perfectly capable
 of hardwarewise, isn't going to be an option anymore? For such purposes,
 running an older version of Debian (or whatever distribution) isn't an
 option, since you have to be able to get security updates.
 
 I could live with that, but I think it'd be a shame.

I bet someone would rebuild base+some extras using i386 target compiler
and make it available, if Debian did that. They would probably serve a
few hundred users total, at best. I don't think it would be too much to
expect debian-i386 to become a side-project.


-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote:
 Please explain your reasons for removing the credits and attributions 
 from the reiserfs utilities in violation of our copyright.
 
 You'll note that ReiserFS anticipated the GNU GPL V3 by including 
 clauses that forbid removal of credits in its license, and for a long 
 time I have been telling Stallman that he needs to get V3 of the GPL out 
 the door.
 
 By the way, does Debian support as a matter of principle the decrediting 
 of Stallman and KDE by RedHat?  I had really expected this from RedHat, 
 not Debian, when I wrote those clauses.
 
 In the academic world, this is called plagiarism.  In the academic 
 world, knowledge is shared but fairly credited.  The GPL is born of the 
 academic tradition.

I'd hardly call it plagiarism. Your copyright is, by will of our own
policy and to abide by authors wishes, distributed with the tools in
/usr/share/doc/pkg/copyright.

Now, I've never heard of such a copyright clause in your tools and I am
quite sure that the individual maintainer of the package did not
intentionally go against such clauses. Not to mention that the acts of
that single maintainer of the software you wrote is not the will of the
entire Debian project.

Now I hope you stop with your trolling and consider speaking
respectfully to us. I am pretty sure that if you emailed the maintainer
of the package and pointed out the facts to him, he would revert the
change.



-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: plagiarism of reiserfs by Debian

[Ben Collins]

 all that was removed was *code* that gets compiled.  If the maintainer 
 cannot arbitrarily change any code he wants, then it is not clear that 
 the program is DFSG-free.

Amen. Making part of the code immutable is not what I call free
software. What if I want to use parts of the code and I respect the
copyright and license...does that mean I also have to take this part of
the code and output the credits? What if environment doesn't provide a
way to output the credits. What if I am implementing the reiser tools on
an embedded system that will never show any such output?

What about programs that execute the reiserfs tools (like bootup
scripts)...are they not allowed to redirect or filter this output?

If any of this is questionable, then I suspect reiserfs tools isn't DFSG
compliant and belongs in non-free with all it's flakiness.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 08:24:21PM +0100, Matt Ryan wrote:
  Now I hope you stop with your trolling and consider speaking
  respectfully to us. I am pretty sure that if you emailed the maintainer
  of the package and pointed out the facts to him, he would revert the
  change.
 
 Dude,
 
 You really need to calm down. Twice now recently you have opened your
 mouth and stuck your foot in when there really wasn't any need to. Take a
 Valium and do something less stressful.

Are you talking to me?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 11:13:59PM +0200, Anders Widman wrote:
  all that was removed was *code* that gets compiled.  If the maintainer 
  cannot arbitrarily change any code he wants, then it is not clear that 
  the program is DFSG-free.
 
  Amen. Making part of the code immutable is not what I call free
  software. What if I want to use parts of the code and I respect the
  copyright and license...does that mean I also have to take this part of
  the code and output the credits? What if environment doesn't provide a
  way to output the credits. What if I am implementing the reiser tools on
  an embedded system that will never show any such output?
 
  What about programs that execute the reiserfs tools (like bootup
  scripts)...are they not allowed to redirect or filter this output?
 
  If any of this is questionable, then I suspect reiserfs tools isn't DFSG
  compliant and belongs in non-free with all it's flakiness.
 
 
  Wow..  what  an  reaction  :).  Hans's  original message was that the
  credits  were  not included with the distributed files, nothing else.
  Or am I completely mistaken?

Sorry, I had read into some other peoples comments and made a bad
assumption about what this was refering to. So this is just about a file
that is in /usr/share/doc/...? If so, I can't see what all the fuss is
about. Just put the file back in.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: bill gates linux

[Ben Collins]

  1/ we don't want to have to know the technical
  details of how to get to the step4/ above (in the
  given table above).
  2/we want one of the following:-
  A/ to be able to insert a floppy disk into
  our a drive , turn on the computer,
 the computer then loads DOS or whatever
  and eventually after enough time and floppys
  have been fead into the drive we see an
   up and running version of Linux.
  or:.. B/ turn on the computer with a floppy
   disk a which then prompts for a cd-rom
which then loads a version of Linux.
  or:..c/ option 3 would be to allow Windows to
   to boot up and click on a cd-rom drive.
and then the program on the cd would modify
 my computer so that Windows and Linux

Damn you are a troll. Did you not believe everyone when they told you
this already exists today? Download the Debian install CD, insert it,
and do the install. If you want super ease of install, get a commerical
dist. It will install along side of Windows and you can boot either one.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: bug#152736 X doesn't start due to no cursor font!

[Ben Collins]

 But I do have a cursor font, even though I don't have xfonts-gimpers 1.8
 installed (it refuses to install anyway). But I do have xfonts-artwiz
 installed. I purged xfonts-gimpers from my system and now X has a brain
 tumor. This is a critical bug and should have been fixed by now.

apt-get install xfonts-artwiz- xfonts-gimpers

That will deinstall xfonts-artwiz, so you can install xfonts-gimpers.
You should file a bug on both of these packages since they need to
conflict, or make use of alternatives instead of diversions for the
common file.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Are libtool .la files in non-dev library packages bugs?

[Ben Collins]

On Tue, Aug 20, 2002 at 01:50:22AM +0200, Luca Barbieri wrote:
 According to Junichi's manual they should be in -dev packages (that
 makes sense, since they are only used by libtool builds).

Yes, it's a bug. Consider that the .la file is usually without soname
(e.g. libfoo.la) it will clash when the next so version of the same lib
is added to the dist.

Not only that, it's only useful for linking, so has no reason being in
the primary runtime.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Are libtool .la files in non-dev library packages bugs?

[Ben Collins]

On Mon, Aug 19, 2002 at 07:29:23PM -0500, Adam Heath wrote:
 On Mon, 19 Aug 2002, Ben Collins wrote:
 
  Not only that, it's only useful for linking, so has no reason being in
  the primary runtime.
 
 ltdl needs them at runtime.

Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
and only have libfoo.la, and ltdl expect to work?

Broken...

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Why XFree86 4.2 Isn't in Woody

[Ben Collins]

On Tue, Apr 16, 2002 at 07:01:06AM -0500, Branden Robinson wrote:
 A couple of people on a recent thread in debian-devel linked to a
 message I recently posted on Slashdot on this subject.  I had thought
 about posting this information to Debian's lists as well, but at the
 time, didn't see a need.
 
 Thanks to that recent thread, now I see a need.  :)

What the fuck is going on! When in this insane world did Branden become
the polite well mannered one, and I become the asshole!

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/


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

Re: XFree 4.2.0 - again

[Ben Collins]

On Tue, Apr 16, 2002 at 05:14:51AM +0300, Lasse Karkkainen wrote:
 Hi!   (it's my first post here)

Fucking idiot. Yes, I can say that now. I'll only be DPL for another ~20
hours. Here, let me say it again. Fucking idiot.

Man that felt good.




Ben (not the DPL for much longer) Collins

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/


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

Re: Faster Release Cycle = More Up to date Packages...

[Ben Collins]

On Thu, Apr 11, 2002 at 11:44:36PM +0200, Rune B. Broberg wrote:
 On Thu, Apr 11, 2002 at 11:13:49PM +0200, Johnny Ernst Nielsen wrote:
  Thank you Joey for being so obliging to a constructive proposal, and 
  thank you for your polite way of replying to my proposal.
  
  Do you think you could put your 6 year old attitude aside for a few 
  moments and take this as a contructive proposal as other normal 
  grownups would do?
 
 This gets you right about nowhere, fighting flame with fire.
 
 I think Torsten has a much, much better point here - get rid of the
 current RC-bugs now, and find out how woody+1 is going to be done in the
 weeks following the Woody-release - with the new DPL.

You just hit the nail on the head. Fixing the bugs is the only way to
get releases out faster. If the bugs aren't getting fixed properly, no
sort of mechanisms will help. Laziness[1] cannot be overcome by scripts
and policies.

As for the DPL comment, you should note that there is nothing the DPL
can do directly to affect the release cycle. Sure, he can delegate
duties, and try to pin-point efforts. However, if no one does the work,
what's the DPL going to do?


[1] That's not directed at any group of people. Yes, I can be accused of
being lazy at times too. Yes, we are all volunteers, which is the whole
point of the matter. Volunteers cannot be forced into doing anything,
and asking a small group to come up with some magic strategy that will
somehow overcome The Volunteer Mindset, is like trying to redesign a 22
caliber gun to fight off a 4-mile-wide asteroid headed towards earth.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Ben Collins]

On Tue, Apr 09, 2002 at 04:27:04PM -0500, Adam Heath wrote:
 On Tue, 9 Apr 2002, Colin Watson wrote:
 
   This problem is very common for non-free software.
 
  ... which really doesn't seem all that relevant apart from sounding
  good; hell, the change in nice()'s return value appears to be a problem
  for start-stop-daemon in dpkg, see #141500, and a minor problem with X,
  see #140012. The nice() interface *did* change without versioning - it's
  true that programs that relied on the old behaviour were buggy, but
  there are plenty of such programs in Debian main and that is something
  Debian developers should be aware of. Patting ourselves on the back is
  great when it's justified, but I think it's somewhat counterproductive
  when it isn't.
 
 So, the change should be backed out.  Why was glibc changed during this
 freeze?

...to bring in other fixes that aren't so easy to seperate from smaller
ones.

Lose the tone, it wont get you what you want. Nice is being fixed. I've
said this in several of the bug reports. This whole thread just needs to
die.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Ben Collins]

On Tue, Apr 09, 2002 at 04:43:32PM -0500, Adam Heath wrote:
 On Tue, 9 Apr 2002, Ben Collins wrote:
 
  ...to bring in other fixes that aren't so easy to seperate from smaller
  ones.
 
  Lose the tone, it wont get you what you want. Nice is being fixed. I've
  said this in several of the bug reports. This whole thread just needs to
  die.
 
 You haven't said it here, until now.  You can't honestly expect everyone in
 the world to read all bugs, to find out what you have said in a few of them.

I can expect people who want to rant on a public list to know what the
hell that are talking about before raising a big stink. If you want to
argue about vmware breaking in libc6, go to the libc6 bug package and
search for vmware. You'll find the bug reports, and my reponses.

I'm not asking too much at all. The BTS is there for this exact reason.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: xfree86 unbuildable on ppc

[Ben Collins]

On Thu, Apr 04, 2002 at 12:22:00AM -0500, Branden Robinson wrote:
 
 It's because of this that I continue to feel that kernel interfaces are
 best defined by the kernel.
 
 If the kernel headers aren't an interface, why do they exist?  There
 appears to be a very large philosophical gulf here.  The fact that the
 Linux kernel guys may long for nice low-level C libraries that
 encapsulate such things doesn't mean they exist.  Is this a side-effect
 of some sort of real men don't program in userspace dogma?
 

This is a problem of the subsystem designed, not the kernel itself, IMO.
For example, in the ieee1394 subsystem, we have several headers that are
shared between userspace and kernel. The header is clean for both cases.
That is the way it was designed.



Ben

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: xfree86 unbuildable on ppc

[Ben Collins]

 
 What we really should have is a nice low-level C library that encapsulates
 such things and lets anyone use it...
 

All we really need is a master ioctl header that defines the numbers. It
would be Debian specific, but what the hell.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: ccache for the autobuilders?

[Ben Collins]

On Tue, Apr 02, 2002 at 03:17:45AM -0500, Anthony DeRobertis wrote:
 On Mon, 2002-04-01 at 23:17, Ben Collins wrote:
 
   Looking at my testing PPC box with grep-available, we have only about
   8GB total Installed-Size.
  
  glibc packages total installed size is only a few dozen megs. However,
  the source builds takes up about 600megs. XFree86, about 1.6gigs.
 
 glibc's build requirements sound like about 20-30 times installed size,
 then. Assuming this holds, and trusting the 8GB figure, gives
 160--240GB.
 
 That's all of three 100GB IDE disks running in RAID 0. Four disks if for
 some reason you want redundancy on your cache.

Surely you don't presume that a) All of our autobuilders have enough
bays for 3 IDE disks and b) Can take IDE at all (vore, the sparc buildd,
doesn't have any IDE).


Ben

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: ccache for the autobuilders?

[Ben Collins]

On Tue, Apr 02, 2002 at 02:30:03PM -0500, Anthony DeRobertis wrote:
   That's all of three 100GB IDE disks running in RAID 0. Four disks if for
   some reason you want redundancy on your cache.
  
  Surely you don't presume that a) All of our autobuilders have enough
  bays for 3 IDE disks and b) Can take IDE at all (vore, the sparc buildd,
  doesn't have any IDE).
 
 Of course not. But for those that are slow and can take the IDE disks,
 it would work.

The ones that could use it, are the ones that can't take it :) I
seriously doubt the m68k can hold 4 disks. I'm pretty sure the m68k's
run scsi too.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: ccache for the autobuilders?

[Ben Collins]

On Tue, Apr 02, 2002 at 03:48:49AM +0200, Paul Russell wrote:
 On Monday 01 April 2002 18:23, Junichi Uekawa wrote:
  Martin Schulze [EMAIL PROTECTED] cum veritate scripsit:
   The same package: almost never
   the same file: often, with every new compile.
  
   Just take into account that a package contains 50 .c files that need
   to be compiled.  An updated package often only changes packaging or
   10% of .c files, leaving 45 remaining the same.  These 45 files would
   benefit of ccache.
 
  I'm pretty doubtful if ccache is able to cache so much
  data. We have 5000 source packages.
 
 Looking at my testing PPC box with grep-available, we have only about
 8GB total Installed-Size.  So I would expect a ccache of 1GB (the default) to
 be a net gain, given that not all packages are built with the same
 regularity.  10GB should definitely do it, well within ccache's capability.

glibc packages total installed size is only a few dozen megs. However,
the source builds takes up about 600megs. XFree86, about 1.6gigs.

There's no way to sanely cache our builds.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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

Re: Build problem on sparc [ogle, assembler error]

[Ben Collins]

On Tue, Jan 15, 2002 at 02:14:07PM +0100, Mikael Hedin wrote:
 Hi again!
 
 [Thanks for the help, ia64 now builds fine] 
 
 This time it's sparc that don't build.  See the build log for details,
 http://buildd.debian.org/fetch.php?pkg=oglever=0.8.2-4arch=sparcstamp=1011076373file=logas=raw,
  
 
 And a snip:
 
 gcc -DPACKAGE=\ogle\ -DVERSION=\0.8.2\ -DSTDC_HEADERS=1 
 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DWORDS_BIGENDIAN=1 -DHAVE_BYTESWAP_H=1 
 -DHAVE_XSHM=1 -DHAVE_XV=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_MADVISE=1 
 -DLIBAO_OSS= -DHAVE_XML=1 -DHAVE_XF86VIDMODE=1 
 -DCONFIG_FILE=\/usr/share/ogle/oglerc\ -DUSE_SPARCASM=1 -I. -I. -I. -I.. 
 -I../include -g -O2 -Wall -mcpu=ultrasparc -mvis -c msgevents.c 
 -Wp,-MD,.deps/msgevents.TPlo  -fPIC -DPIC -o .libs/msgevents.o
 /tmp/ccMkcRE8.s: Assembler messages:
 /tmp/ccMkcRE8.s:605: Error: Architecture mismatch on bne,pt %icc,.LL130.
 /tmp/ccMkcRE8.s:605:  (Requires v9|v9a|v9b; requested architecture is 
 sparclite.)
 /tmp/ccMkc

I'll repeat this many times over. DO NOT USE cpu optimizations in Debian
packages! IOW, remove the -mcpu=ultrasparc line. It is not fully
supported in gcc, and not to mention that if it did work, it would break
the package on sparc32 platforms.


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: mindi fails on Linux Debian system

[Ben Collins]

On Tue, Jan 15, 2002 at 05:20:14PM +0100, Wichert Akkerman wrote:
 Lets take [EMAIL PROTECTED] of the cc list, this is not an abuse
 complaint. Lets add debian-devel since this actually is a normal
 technical question.
 
 
 Previously Kenneth H. Carpenter wrote:
  I have been using the Debian distribution since it first came out, and
  I appreciate the effort that has been made to make it robust and keep it
  free.  But I think it would be helpful if Debian did not change the
  entry points for standard utilities so that ones wanting to add software
  not in Debian would not have to be aware of these changes.
 
 In this case it seems a wrapper was added to work around some devfs
 issues, but it calls the actual lilo with the exact options you gave
 it. Can you explain how exactly that broke mindi? Once we know
 exactly what the problems is we can look at fixing it.

The problem is that it creates a rootfs (I believe) and copies
/sbin/lilo blindly to the new rootfs. Thus, you just have a broken shell
script.

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: 232432-B22

[Ben Collins]

On Sat, Jan 12, 2002 at 09:16:37PM -0800, sales wrote:
 Hello,
 
 Are you still looking to buy a large qty of 232432-b22's?  We have a large 
 qty of all of Compaq drives.  Please let me know what you need and want to 
 pay.
 
 I look forward to hearing from you.

We need 100, and I'll pay $1/unit. When can we expect shipment?

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Bug#126441: [security] What's being done?

[Ben Collins]

 
 Ben is merely behind with updating the BTS, by the looks of it...
 

Can't close it till I fix woody/sid too. Which will be when 2.2.5 is
released (days).

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Build dependencies, libs and buildd

[Ben Collins]

On Fri, Jan 11, 2002 at 09:38:00PM +0100, Torsten Landschoff wrote:
 Hi *, 
 
 I got a bug report on python-gnome because a) I did not yet conform to the
 new python policy (missed the dep, thanks Matthias), and b) I did not 
 depend on at least 1.0.0 of libgtkhtml-dev. 
 
 Now I am wondering if I have to make all dependencies of shared libraries 
 more strict... I would expect that the buildd ensures that it has the 
 binary of the newest package of each build dep available in unstable 
 before building the package. If that is not the case I would have to 
 depend on at least the library version installed on my system it seems.

If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to
build), then you have a problem.

The only way to control proper build-deps is to specify them. If your
package requires features in a newer version of a library, well you have
to build-depend on it. That's the whole reason for having them there.


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Build dependencies, libs and buildd

[Ben Collins]

On Fri, Jan 11, 2002 at 11:15:07PM +0100, Torsten Landschoff wrote:
 On Fri, Jan 11, 2002 at 04:05:02PM -0500, Ben Collins wrote:
   binary of the newest package of each build dep available in unstable 
   before building the package. If that is not the case I would have to 
   depend on at least the library version installed on my system it seems.
  
  If the buildd for $arch only has 0.9.9 built (maybe 1.0.0 failed to
  build), then you have a problem.
  
  The only way to control proper build-deps is to specify them. If your
  package requires features in a newer version of a library, well you have
  to build-depend on it. That's the whole reason for having them there.
 
 That's obvious. What I fear could happen is that
 
 a) autobuilder takes my package (which works with older libgtkhtml)
and builds a binary
 b) the new libgtkhtml hits the autobuilder
 c) the resulting library is installed and the old one used by my 
package is removed so that is it uninstallable
 
 IOW: My package works which whatever is the available version of that
 package. But should I always add 
 libfoo-dev (= `dpkg -s libfoo-dev|awk /^Ver/ {print $2}`)
 to my build dependencies? Of should libfoo-dev suffice under normal
 conditions?

Under normal conditions, libfoo-dev should work. If say your package
gets built with libfoo1 by the autobuilders, and then libfoo2 is
released and the maintainer says libfoo1 is going away, rebuild your
packages, then you may need to do something.

Most people feel that not keeping older soname libs around for a certain
period is a bad idea, just for this reason. You as the package builder
shouldn't have to worry about it.


Ben


-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Bug#122342: directory-administrator: Not installable

[Ben Collins]

On Fri, Jan 11, 2002 at 10:20:59PM +0100, Turbo Fredriksson wrote:
 Quoting Damyan Ivanov [EMAIL PROTECTED]:
 
  On Fri, Dec 07, 2001 at 04:14:05PM +0100
  Turbo Fredriksson [EMAIL PROTECTED] wrote:
   This was fixed in 1.1.1-9, uploaded 2001 - Nov 27.
   
   Please do a 'apt-get update'...
  
  But directory-administrator 1.1.1-9 depends on libldap2 (= 2.0.18-1),
  which is not available. The last available version is 2.0.14-1.1.
 
 I'm running home-made packages of OpenLDAP2...

Uh, don't hardcode deps, and more importantly, don't compile against
packages that aren't available. I seriously doubt that everything in
2.0.18's API works with 2.0.14.


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Call for translation for locales package

[Ben Collins]

I'm getting ready for 2.2.5-1 of glibc for upload. I have added a new
template to the locales package. Just so I don't have to make another
upload to get the translations for this template in sync with the one
that is already there, here is the text:

Description: Which locale should be the default in the system environment?
 Many packages in Debian use locales to display text in the correct
 language for users. The default is C but you can change this if you're not
 a native English speaker.
 .
 Note: This will reflect the language for your whole system. If you're
 running a multi-user system where not all of your users speak the language
 of your choice, then they will run into difficulties and you might want to
 leave C as the default locale.
 .
 These choices are based on which locales you have chosen to generate.


Currently I have translations for locales/locales_to_be_generated in
ko, ru, pt_BR, es and de. If I can match those, then I'll be happy. If
anyone wants to add new translations for both templates, I'll take them
too. Here's the old template that is already translated:

Template: locales/locales_to_be_generated
Description: Select locales to be generated.
 You can choose locales to be generated by selecting locales you want.
 Selected locales will be saved to `/etc/locale.gen' file. You can also
 manually edit this file. You need to run `locale-gen' after edit the file.



Thanks,
  Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Mon, Dec 24, 2001 at 04:01:25AM +, Adam Olsen wrote:
 
 On Sun, Dec 23, 2001 at 10:49:33PM -0500, Ben Collins wrote:
  On Sun, Dec 23, 2001 at 06:57:45PM -0800, Thomas Bushnell, BSG wrote:
   
   Ben Collins [EMAIL PROTECTED] writes:
   
But quake2-engine does not depend on anything to fulfill it's purpose.
It is a gaming engine, not a game. This is the same logic that applies
to libraries and interpreters.
   
   Huh?  The purpose of quake2 is not to run quake levels and be a
   playable game?
  
  The purpose of the sources released is a gaming engine. They did not
  release quale2 the game, which is what the data files consist of.
  Notice that lots of games from Id are based on the quake3 engine. They
  aren't quake3, but they use the same engine, and different data files.
  
  Do not confuse a game engine (the source released) with the game itself
  (the data files that they didn't release).
 
 But you do agree that it requires having *some* data, no matter what
 game it's for?  Which means having a Depends: quake2-data?
 
 And if you wish to argue that it can be used to develop the data, then
 you should have no problem in providing such a package of it.

Does python Depend: some-python-script? No, it doesn't. Python is an
interpreter. Same logic applies for the quake2 engine. Other things will
depend on it, not the other way around.

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 06:32:16PM +1000, Anthony Towns wrote:
   Ben Collins [EMAIL PROTECTED] writes:
I think that's rediculous. Education is not a smokescreen, and you can't
argue that there will never be free data available for quake2 (or know
for sure that there isn't already).
 
 It doesn't matter whether there will be free date, or even whether there
 *is* free data: it matters whether it's packaged for Debian.
 
 On Sun, Dec 23, 2001 at 03:01:02AM -0500, Ben Collins wrote:
  Ok, I'm going to upload libgaming. Nothing yet has been created for it,
  but it is possible. Should I upload it to contrib?
 
 If nothing's been created for it, why would you want to upload it to the
 distribution at all?
 
 The Deb in Debian does stand for Deborah, not Debating Society,
 right?

And I thought Debian stood for promoting free software creation. Putting
quake2 in contrib and tacking on that purchase the non-free datafiles
message is just crap.


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Mon, Dec 24, 2001 at 04:45:14PM +0100, Marcus Brinkmann wrote:
 
 On Mon, Dec 24, 2001 at 01:42:45AM -0500, Ben Collins wrote:
   But you do agree that it requires having *some* data, no matter what
   game it's for?  Which means having a Depends: quake2-data?
   
   And if you wish to argue that it can be used to develop the data, then
   you should have no problem in providing such a package of it.
  
  Does python Depend: some-python-script? No, it doesn't. Python is an
  interpreter. Same logic applies for the quake2 engine. Other things will
  depend on it, not the other way around.
 
 You are trying to duck a fundamental issue: that a quake-engine binary
 package will be utterly useless to about everyone.
 
 First: Python is immediately useful without any scripts.
 You can run it with the -c option to run python commands without any script
 coming into the game.

Just because it is easier to write scripts for Python than it is
quake2-engine, doesn't change the fundemental issue that the sources are
for an engine, not a game.

 Second: It is easy to write scripts.  People do write them.
 The challenge here is: Show me a single useful way to invoke the quake
 engine with only free software or data.  Even if it is just an empty room
 without any monsters, weapons.  Just a wall.  Something.

Again, it is not easy to write C code, but gcc is useless without it.
Complexity means nothing.

 Third: Python scripts exist.  There are plenty in Debian.
 Show me a quake-data package that requires the engine.

I'm giving up. Let's just dump it into contrib and tell everyone to
either warez the data files or buy them. Screw trying to promote free
stuff. Screw trying to promote people to create free datafiles for a
free game engine.



Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sat, Dec 22, 2001 at 11:50:00PM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
  I think that's rediculous. Education is not a smokescreen, and you can't
  argue that there will never be free data available for quake2 (or know
  for sure that there isn't already).
 
 Um, can you give me an example of a package in contrib that this
 argument does not apply to?  If what you are saying is a good way to
 think, then we should indeed not bother having contrib at all, right?
 
 If there *are* playable levels available for quake2 (which need
 nothing in the way of non-free game data) then of course it belongs
 (along with those levels) in main.


Ok, I'm going to upload libgaming. Nothing yet has been created for it,
but it is possible. Should I upload it to contrib?

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 12:22:27AM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
  Ok, I'm going to upload libgaming. Nothing yet has been created for it,
  but it is possible. Should I upload it to contrib?
 
 Can you give me an example of *anything* you think belongs in contrib?

PC emulators that require a BIOS rom. Mol requires the MacOS ROM file
from MacOS itself. Things that Depend: ... packages in non-free (we
can distribute quake2-engine as depending on nothing, since it is just
the engine, not a game...the games would depend on quake2-engine for
operation.

Lots of things go in contrib, but a gaming engine that just happens to
have non-free data files that use it, does not need to go into main. The
engine is a development platform.


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 03:44:16AM -0500, Zephaniah E. Hull wrote:
 On Sat, Dec 22, 2001 at 11:50:00PM -0800, Thomas Bushnell, BSG wrote:
 snip
  If there *are* playable levels available for quake2 (which need
  nothing in the way of non-free game data) then of course it belongs
  (along with those levels) in main.
 
 Uhm, guys.
 
 You need much more then just free maps, you also need replacement fonts
 and other graphics. (Stuff used for the console, the menu, the in game
 HUD, and a few other things.)
 
 Replacements for those are unlikely to exist now, and will take a while
 to generate.

As I said. The engine is meant to develop games for. Just because no one
has developed games for a development system (the engine), doesn't make
it contrib.

You people need to think of it as an interpreter of the data files. Do
not judge the engine based on the data files that are available for it
(else we'll have to start judging script interpreters and libraries the
same way).

Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 04:08:30PM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
  On Sun, Dec 23, 2001 at 12:22:27AM -0800, Thomas Bushnell, BSG wrote:
   
   Ben Collins [EMAIL PROTECTED] writes:
   
Ok, I'm going to upload libgaming. Nothing yet has been created for it,
but it is possible. Should I upload it to contrib?
   
   Can you give me an example of *anything* you think belongs in contrib?
  
  PC emulators that require a BIOS rom. Mol requires the MacOS ROM file
  from MacOS itself. Things that Depend: ... packages in non-free (we
  can distribute quake2-engine as depending on nothing, since it is just
  the engine, not a game...the games would depend on quake2-engine for
  operation.
 
 But, by your logic, none of those belong in contrib.
 
 All of them have potientally useful educational value.  And all could,
 in theory, become useful if someone wrote a free alternative for the
 non-free thing they depend on.

But quake2-engine does not depend on anything to fulfill it's purpose.
It is a gaming engine, not a game. This is the same logic that applies
to libraries and interpreters.

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 06:57:45PM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
  But quake2-engine does not depend on anything to fulfill it's purpose.
  It is a gaming engine, not a game. This is the same logic that applies
  to libraries and interpreters.
 
 Huh?  The purpose of quake2 is not to run quake levels and be a
 playable game?

The purpose of the sources released is a gaming engine. They did not
release quale2 the game, which is what the data files consist of.
Notice that lots of games from Id are based on the quake3 engine. They
aren't quake3, but they use the same engine, and different data files.

Do not confuse a game engine (the source released) with the game itself
(the data files that they didn't release).


Ben

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 07:56:26PM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
  The purpose of the sources released is a gaming engine. They did not
  release quale2 the game, which is what the data files consist of.
  Notice that lots of games from Id are based on the quake3 engine. They
  aren't quake3, but they use the same engine, and different data files.
  
  Do not confuse a game engine (the source released) with the game itself
  (the data files that they didn't release).
 
 So there are two things that bug me here.
 
 First, a user who sees quake listed in main should reasonably expect
 to get Quake, and they don't, they get an engine which is essentially
 useless to them, and which is extremely likely to *remain* useless to
 them *forever* unless they go out and purchase the proprietary data
 files.

As I said, call it quake2-engine and describe it as _the engine_ minus
the game. The thing is just as useless in contrib, except that if we
label it what it is, and not what people expect, then someone might say
Oh shit, you mean we can write our own games with this thing?!?
instead of Ok, I need to go download the datafiles from a warez pup to
use this thing...why did they even include it?

 Second, your example seems totally fabricated.  If there were a
 plausible enterprise--ANYONE--who was seriously planning on using this
 engine to make free levels that don't depend on id's nonfree stuff,
 then I'd buy your argument.  But there really is no credible effort
 out there to do this; not because there is no package in Debian, but
 because it's a considerable venture and hasn't garnered interest.

Fabricated!? You really want to underestimate the free software
community? We have a whole freaking OS free, and you don't think anyone
will put in the effort to make one a game?

 I'm entirely happy with putting it in contrib, but I'm entirely
 baffled by your position: what exactly do you think would be gained by
 putting it in main?

Well I'm not. It's taking the easy route. Dropping it into contrib and
saying you need to buy the data files from Id to use this is a cop
out, IMNSHO. Put it out there as a game development platform, which is
_what it is_ and get the correct movement going.

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Quake 2 sources GPL'd

[Ben Collins]

On Sun, Dec 23, 2001 at 08:08:56PM -0800, Thomas Bushnell, BSG wrote:
 
 Ben Collins [EMAIL PROTECTED] writes:
 
   Second, your example seems totally fabricated.  If there were a
   plausible enterprise--ANYONE--who was seriously planning on using this
   engine to make free levels that don't depend on id's nonfree stuff,
   then I'd buy your argument.  But there really is no credible effort
   out there to do this; not because there is no package in Debian, but
   because it's a considerable venture and hasn't garnered interest.
  
  Fabricated!? You really want to underestimate the free software
  community? We have a whole freaking OS free, and you don't think anyone
  will put in the effort to make one a game?
 
 Maybe they will!  That would be great.  But I just don't see any
 actual effort out there, and it's been possible for a long time now.

What good is wasting the effort for a free set of datafiles for
something that was binary-only? Having the source means they can
understand the game better, and that it will be ported to more
platforms and will be _free_. This only recently happened.

  Well I'm not. It's taking the easy route. Dropping it into contrib and
  saying you need to buy the data files from Id to use this is a cop
  out, IMNSHO. Put it out there as a game development platform, which is
  _what it is_ and get the correct movement going.
 
 Hrm.

Are those gears I hear turning? :)

-- 
 .--===-=-==-=---==-=-.
/   Ben Collins--Debian GNU/Linux  \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'