Re: why allow broken packages to get all the way to mirrors?

[Tollef Fog Heen]

* Mike Hommey 

| On Tue, Apr 05, 2005 at 08:18:25AM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
|
| > For the first, there are well working mirror scripts that prevent that,
| 
| Why on earth aren't they in place on official mirrors ? I *always* get
| 404 errors for new packages at the time Packages has been updated on
| ftp.fr.debian.org, at least.

Ask the mirror admin.  Most mirrors aren't under Debian's control.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Russell Coker]

On Monday 28 February 2005 14:26, sean finney <[EMAIL PROTECTED]> wrote:
> i came up with the number by totalling the mailbox sizes of a 3000 user
> mail system, and then dividing by the total number of messages in these
> mailboxes.  this generated a number around 13k average message size.
> i had to do this as part of assessing the feasability of migrating
> to maildir without reformatting the filesystem.

A couple of years ago I did the same thing on a system with over a million 
users and got much the same result.

> > I thought it was "illegal" to modify a message.
>
> marking a message as read is one example.  moving a message from one
> mailbox to another is another example.  although it's not modifying the
> message itself, it's moving its location, which with a crappy imap
> server can mean re-writing the contents of two mailboxes.

In most jurisdictions it's legal to do almost anything as long as the users 
are informed in advance.

Anyway this list is about solving technical problems not being bothered with 
laws in some strange part of the world.

On Monday 28 February 2005 19:18, Michelle Konzack <[EMAIL PROTECTED]> 
wrote:
> Mailbox is MUCH slower as Maildir, because it must be scaned entierly,
> but with maildir, most you can spead up the searches while scaning
> only the Headers.

Of course this only applies if there are a significant number of messages 
larger than the file system block size (usually 4K).  If you have a maildir 
in which every message is less than 4K in size you may find that scanning it 
is slower than scanning an mbox with the same data.  The kernel can do 
read-ahead for a large file to improve performance.  Also an application can 
do read-ahead (calling setbuf() with a large buffer would be one way to do 
it).

Usually there are a significant number of messages >4K so this is the case.  
Also Maildir wins on all modifications to the mail store other than adding 
new messages.


Another noteworthy thing about Maildir is that when an application messes up 
it will probably only trash one message.  I use Maildir for my Kmail local 
storage for this reason, I've had problems in the past with Kmail crashing 
and corrupting mbox storage.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: debconf and locale specific characters

[Andrew Suffield]

On Tue, Apr 05, 2005 at 06:50:45AM -0700, Steve Langasek wrote:
> I agree there's a (slim) chance of the charset changing between config and
> postinst, so recoding in the config script itself is best.

More than a slim chance if you're preseeding the debconf database for
use on multiple hosts.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Why do we still have this on the distribution?

[Thijs Kinkhorst]

On Wed, April 6, 2005 01:09, sean finney said:
> - sarge is around the corner, and keeping it in means maintaining
>   it for possibly another 2-4 years!  if it's *already*
>   no longer maintained upstream...

This raises a valid point; maybe the maintainer can comment on this? Since
we already receive no security updates to php3 from upstream, is it
feasible security-wise to keep it in the distribution for some years to
come?


Thijs


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

Bug#272669: ITP: archmbox -- a simple email archiver written in perl

[straluna]

Package: wnpp
Followup-For: Bug #272669
Owner: [EMAIL PROTECTED]


Archmbox is a simple email archiver written in perl; it parses one or
more mailboxes, selects some or all messages and then performs specific
actions on the selected messages.
At this time archmbox supports mbox and mbx mailbox formats.
Messages selection is based upon a date criteria; an absolute date
or a days offset can be specified. It is also possible to refine
the selection using regular expressions on the header fields of the
message.
All archived messages are stored in a new mailbox with the same
name  of the original one plus .archived as extension (this is the
default, but can be changed); the archive mailbox can be saved in gz or
bz2 compressed format as well.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1)


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

Re: init.d script dependencies for etch?

[Pierre THIERRY]

Scribit Humberto Massa dies 04/04/2005 hora 10:46:
> > Cached? As in queried beforehand? As in two-pass algorithm, once
> > iterating init.d with 'depends' as option, then with 'start' ?

There are advantages to call the init.d script to poll its dependencies,
instead of reading them:

- the script can give them according to configuration files or by
  verifying that something is really needed (e.g. if a service is only
  accessed by unix sockets, no need for networking),
- it doesn't force init.d scripts to be really shell scripts (dunno if
  this is really desirable, though).

Dynamically,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: Why do we still have this on the distribution?

[Gürkan Sengün]

Hi
 is I guess is better, but doesn't really help me understand some
 numbers others have posted (notably, that sparc is below the 98% line).
And what about packages that are i386 only, or everything but sparc?
There is quite some packages that are i386 only... packages being only 
sparc, only silo comes to mind. (there sure are some more..)

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

Re: Alternative: Source-Centric Approach [w/code]

[Freddie Unpenstein]

> > Your priority are your users, and if Debian has decided to focus
> > only on some key architectures it would be the best for them to
> > help them switching to Gentoo instead of hacking Debian to become
> > some cheap Gentoo clone for most architectures.

> I don't view this as being a cheap Gentoo clone.  In fact, I view
> srcinst as being the Gentoo idea, done right.  Gentoo has a lot of
> problems, especially relating to difficult upgrades.  Because of 
> our superior packaging system, we are in a great position to hit
> the ground running and, with a little help from something like
> srcinst, come up with something that works -- and works better than
> Gentoo -- in a short amount of time.

I'm wondering, what happens if you want to install MOST of the deps from 
source?  Wouldn't it be better to have apt-build (using the "official apt 
algorithms") ask on a dep-by-dep basis whether you want it compiled from source 
or installed from a binary?

Even better, would be to allow apt's preferences file to state whether a 
specific package should be installed from binary or source, and have the stock 
"apt-get install" do what's appropriate.  With a few options to set the default 
mode (binary or source), and to overide the mode for specific packages.  And of 
course, last but not least, apt should keep the package comming from the same 
source unless specifically changed.


Now, if only apt-get understood that a pacakge may be available from more than 
one mirror at a time...

Fredderic

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


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

Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents

[Carlos Z.F. Liu]

Package: wnpp
Severity: wishlist
Owner: "Carlos Z.F. Liu" <[EMAIL PROTECTED]>

* Package name: vimcdoc
  Version : 0.7.0
  Upstream Author : Simon Liang <[EMAIL PROTECTED]> and some others
* URL : http://vimcdoc.sourceforge.net
* License : vimcdoc license 0.1
  Description : Chinese Translation of Vim Online Help Documents

 Vimcdoc is an attempt to translate the wonderful Vim online
 documentation into Chinese, allowing more people to get to know
 and make use of this great tool. After installing vimcdoc, you
 will be able to do :help and read documentation in Chinese.


License:

The Vimcdoc License, Version 0.1

Copyright (C) 2003 The Vimcdoc team (http://vimcdoc.sf.net,
http://vcd.cosoft.org.cn). All rights reserved.

This software is provided 'as-is', without any expressed or implied
warranty. In no event will the author be held liable for any damages
arising from the use of this software.


Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of software must retain the above copyright
   notice and this list of conditions.

2. No commercial use of this software are allowed without written
   permission from the author. For written permission, please contact
   [EMAIL PROTECTED]

3. The origin of this software must not be misrepresented; you must
   not claim that you wrote the original software.

4. Copyright of the individual documents are retained by the author of
   the document.



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8)


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

Re: Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents

[Pierre Habouzit]

Le Mercredi 6 Avril 2005 13:08, Carlos Z.F. Liu a écrit :
> 2. No commercial use of this software are allowed without written
>    permission from the author. For written permission, please contact
>   [EMAIL PROTECTED]

at least this one means that vimdoc cannot be in main. that's sad.
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpItKpZTkn6h.pgp
Description: PGP signature

Native package with two changelogs

[Benjamin Mesing]

Hello,

I have a package which I develop on my own and which is debian native.
However due to historical reasons, I have a CHANGELOG file which is not
the debian/changelog file. 
How should I handle this case? I am in favour of handling it like an
upstream package, meaning 
 1. debian/changelog -> changelog.Debian
 2. CHANGELOG -> changelog
Is this appropriate?

Greetings Ben

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


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

Re: debconf and locale specific characters

[Torsten Landschoff]

Hi Alban, 

On Wed, Apr 06, 2005 at 05:15:34AM +0200, Alban Browaeys wrote:
> > It is save to assume that the data from debconf is in the charset of the
> > current locale? Then foo=`echo $RET|iconv -t UTF8` after the db_get
> > would suffice. Of course the locale could change between config and
> > postinst so maybe I should convert to UTF-8 and store the result in the
> > debconf db in the config script?
> 
> 
> from slapd debian script source it is told that utf8 would broke the ldi
> output (talking about root dn , though i guess it is just that openldap

That's right, currently UTF8 is not supported. To support it we'll have
to convert the input into UTF8 and base64-encode it and use the binary
syntax for the entry. Which is fully supported by OpenLDAP.

> does not support utf8 out of the box right now).

It does.

> Though i am pretty confident that slapd/lbdm or bdb support utf8 i would
> not swear that the ldiff scripts does ...

It's just some other binary data to throw into the database. Why would
it cause any problems?

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Native package with two changelogs

[Torsten Landschoff]

On Wed, Apr 06, 2005 at 02:16:08PM +0200, Benjamin Mesing wrote:
 
> I have a package which I develop on my own and which is debian native.
> However due to historical reasons, I have a CHANGELOG file which is not
> the debian/changelog file. 
> How should I handle this case? I am in favour of handling it like an
> upstream package, meaning 
>  1. debian/changelog -> changelog.Debian
>  2. CHANGELOG -> changelog
> Is this appropriate?

Why not? Use changelog.Debian for packaging changes and changelog for
the application changes.

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Native package with two changelogs

[John Goerzen]

On Wed, Apr 06, 2005 at 02:16:08PM +0200, Benjamin Mesing wrote:
> Hello,
> 
> I have a package which I develop on my own and which is debian native.
> However due to historical reasons, I have a CHANGELOG file which is not
> the debian/changelog file. 
> How should I handle this case? I am in favour of handling it like an
> upstream package, meaning 
>  1. debian/changelog -> changelog.Debian
>  2. CHANGELOG -> changelog
> Is this appropriate?

I do this with quite a few of my packages.  In many cases, the tarball I
release has a file named ChangeLog that is automatically maintained for
me by tla.  It is far more detailed than a debian/changelog file usually
is, and contains details of interest to plenty of people besides Debian
users -- but may also be of interest to Debian users.

-- John


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

Re: Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents

[Carlos Z.F. Liu]

On Wed, Apr 06, 2005 at 01:32:59PM +0200, Pierre Habouzit wrote:
> Le Mercredi 6 Avril 2005 13:08, Carlos Z.F. Liu a écrit :
> > 2. No commercial use of this software are allowed without written
> >    permission from the author. For written permission, please contact
> >   [EMAIL PROTECTED]
> 
> at least this one means that vimdoc cannot be in main. that's sad.
>
The upstream author occasionally told me that he want to switch to
GFDL, another non-free license. :) Is there any DFSG free document
license? ... OK, I knew GPL and BSDL is, but not everyone think
docuemntation is equal to software...

But, as I knew, VIM's user manual is OPL, non-free as well. Please have
a look in /usr/share/vim/vim63/doc/usr_01.txt, *01.4*  Copyright.


-- 
 Best Regards,
 Carlos


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

Re: Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents

[sean finney]

On Thu, Apr 07, 2005 at 01:39:17AM +1200, Carlos Z.F. Liu wrote:
> The upstream author occasionally told me that he want to switch to
> GFDL, another non-free license. :) Is there any DFSG free document
> license? ... OK, I knew GPL and BSDL is, but not everyone think
> docuemntation is equal to software...

i'm a fan of the academic free license v2, which i think does what the
gfdl meant to do.  it allows modifications and redistribution, as long
as the modifications from the original are clearly stated.


sean

-- 


signature.asc
Description: Digital signature

Re: watch files and weird version numbers

[Zak B. Elep]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> I'd go with 1.0rel+1.0c.  Fix it for real with version 1.1.

Okies, thanks. Actually this was what I first considered, but upon
reading the Policy Manual I saw other options, so I needed to ask. =)

-- 
ZAK B. ELEP <[EMAIL PROTECTED]>   -- Registered Linux User #327585
1024D/FA53851D  1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D
 Debian - When you've got better things to do than to fix a borken system


pgpN7ZKjYlajE.pgp
Description: PGP signature

Bug#303405: ITP: libxmlrpc-java -- Java implementation of XML-RPC protocol

[Martin Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martin Ferrari <[EMAIL PROTECTED]>


* Package name: libxmlrpc-java
  Version : 1.2b2-cvs
  Upstream Author : Apache XML-RPC team <[EMAIL PROTECTED]>
* URL : http://ws.apache.org/xmlrpc/
* License : Apache
  Description : Java implementation of XML-RPC protocol

The Apache XmlRpc package is an implementation of the XML-RPC specification
(http://www.xml-rpc.com) with optional Servlet and SSL extensions.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (900, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=es_AR, LC_CTYPE=es_AR (charmap=ISO-8859-1)


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

Re: intend-to-implement: script to obtain Debian Source

[Pierre THIERRY]

Scribit Steve Greenland dies 04/04/2005 hora 07:15:
> > - what problems do thsi random order could weed?
> Unnoted dependencies that just happen to be fulfilled due to a
> consistent (though arbitrary) application order. By applying in a
> different order each time, you should trigger an error fairly quickly.

I don't find it very sane to be forced to deliberately trigger problems
on the user's system to find bugs.

Wouldn't it be more appropriate in a package testing tool? Maybe
lintian, with a test of all combinations of independant patches (or a
more intelligent subset) to see if something fails.

When I unpack a source, I don't want it to fail to help a careless
maintainer to find the flaws in one's packaging...

> > - won't it be more difficult to trakcs bugs if it isn't predictable?
> If you get an error during the patching process, it should be fairly
> easy to determine that it's an un-marked dependency, and then find it
> by hand.

That's what you think. I'm not so sure.

> You can also impose arbitrary dependencies among your supposedly
> "independent" patches until you find the troublesome combination.

Urgh. Are you doing computer science or cooking? Couldn't the
application write somewhere the order of the patch that it just used?!

Easily,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

subject

[Denis Brandl]

On Apr 6, 2005 11:39 AM, Luk Claes <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> This is a cunning plot to increase interest in Quality Assurance among
> Debian contributors.
> 
> There will be a QA Hacking event preceding Debconf5 [1] in Helsinki.
> 
> Those who want to participate, please sign up here:
> http://wiki.debian.net/?DebianQAHacking
> 
> Don't forget to mention the date when you expect to arrive and what you
> will be working on (everything QA [2] related is fine).
> 
> See you in HEL!
> 
> Luk
> 
> PS: For all those who might not be able to attend the QA Hacking in HEL,
> please keep in mind that there will also be a mini-QADebconf in
> Darmstadt, Germany[3].
> PS2: More information about the event will be available at the wiki page
> [4].
> 
> [1] http://www.debconf.org/debconf5
> [2] http://qa.debian.org
> [3] http://lists.debian.org/debian-qa/2005/03/msg00102.html
> [4] http://wiki.debian.net/?DebianQAHacking
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.0 (GNU/Linux)
> 
> iD8DBQFCU/Sc5UTeB5t8Mo0RAoTPAJ9a+edVx65506VxrulztrLeqR/uZQCeKHBM
> SmLQHmYCOp2tC1leXAdYNFk=
> =fZ9o
> -END PGP SIGNATURE-
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 


-- 
Denis Brandl
[EMAIL PROTECTED]
Massaranduba - SC
-
Nunca tenha medo de tentar algo novo. Lembre-se de que um amador
solitário construiu a Arca. Um grande grupo de profissionais o
Titanic.
(Luiz Fernando Verissimo)

Re: intend-to-implement: script to obtain Debian Source

[Lars Wirzenius]

ke, 2005-04-06 kello 19:31 +0200, Pierre THIERRY kirjoitti:
> Scribit Steve Greenland dies 04/04/2005 hora 07:15:
> > > - what problems do thsi random order could weed?
> > Unnoted dependencies that just happen to be fulfilled due to a
> > consistent (though arbitrary) application order. By applying in a
> > different order each time, you should trigger an error fairly quickly.
> 
> I don't find it very sane to be forced to deliberately trigger problems
> on the user's system to find bugs.

I assume the goal is to make it fail on the developer's system, on
build daemons, whenever random developers unpack the package (to, for
examples, fix bugs in it), and only at the last phase on the user's
system. The point is to make it as likely as possible to make it 
break, if it breaks at all, so that when the user sees the package,
it is already non-broken.


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

Bug#302309: ITP: bcron -- Bruce's cron system

[Gerrit Pape]

This is bcron, a new cron system designed with secure operations in mind.
To do this, the system is divided into several separate programs, each
responsible for a separate task, with strictly controlled communications
between them.  The user interface is a drop-in replacement for similar
systems (such as vixie-cron), but the internals differ greatly.

 http://untroubled.org/bcron/

License is GPL2.

There'll be two binary packages: bcron, containing the bcron programs
and documentation, and bcron-run, setting up the bcron services, and
providing, replacing, and conflicting with the default cron package.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.


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

Re: init.d script dependencies for etch?

[Thomas Hood]

Apparently Gentoo is using simpleinit.  Anyone know what the
other distros are using?

-- 
Thomas Hood


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

Bug#303475: ITP: hrd -- the puzzle game of HuaRongDao

[Qingning Huo]

Package: wnpp
Severity: wishlist
Owner: Qingning Huo <[EMAIL PROTECTED]>


* Package name: hrd
  Version : 0.1
  Upstream Author : Qingning Huo <[EMAIL PROTECTED]> 
* URL : http://www.example.org/
* License : GPL
  Description : the puzzle game of HuaRongDao

HuaRongDao (hrd) is an ancient Chinese puzzle game.  Its aim is to move
pieces on the board in order to move the largest one to the center of
the bottom.  It is a very small game, and it is very challenging.  This
implementation is based on the curses library.  The game is controlled
by keyboard only.  Its features include undo, redo and bookmarks.
Custom starting patterns are also supported.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: intend-to-implement: script to obtain Debian Source

[Steve Greenland]

On 06-Apr-05, 12:31 (CDT), Pierre THIERRY <[EMAIL PROTECTED]> wrote: 
> 
> Urgh. Are you doing computer science or cooking? Couldn't the
> application write somewhere the order of the patch that it just used?!

*I'm* not doing anything except postulating the reasoning behind a
deliberately random patching order. Mr. Heath is the one doing the work.

Given even basic testing on the developer's system, plus the
autobuilders, I doubt a bug like this would make it through unstable.
OTOH, I can see a lot of people being bit the day Mr. Heath fixes
something that just happens to re-order the "independent" patches.

There's a long history of people relying on explicitly unspecified
behaviour, and then bitching when that behaviour changes. 

Steve





-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Bug#302309: ITP: bcron -- Bruce's cron system

[Steve Greenland]

On 06-Apr-05, 14:45 (CDT), Gerrit Pape <[EMAIL PROTECTED]> wrote: 
> 
> There'll be two binary packages: bcron, containing the bcron programs
> and documentation, and bcron-run, setting up the bcron services, and
> providing, replacing, and conflicting with the default cron package.

It looks like bcron messes with the permissions and structures of
/var/spool/cron/crontabs. Are you going to handling conversion between
the two (cron and bcron)? In particular, are you going to convert
*back* on removal of bcron-run? Or do you expect cron to clean it up on
re-install? (I can handle that, but I'd like to know the plan.)

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

acenic firmware rewrite

[Peter 'p2' De Schrijver]

Hi,

Reading http://lists.debian.org/debian-legal/2004/12/msg00078.html I
wondered if people would be willing to work on a free firmware for
the Tigon II chip.  I didn't look at the existing code yet, but looking
at the datasheet
(http://alteon.shareable.org/firmware-source/12.4.13/tigonbk.pdf.bz2) it
doesn't seem to be a very complicated chip to code for. I'm not sure
however, how to handle the development in such a way the resulting
firmware can be released under a free license without any legal risks.
I have 2 PCI boards with the Tigon II chip and a 1000BaseSX PHY. I also
have an Ace Director III loadbalancer which consist of 10 Tigon II
chips. 8 of those are used for 100BaseT interfaces, 1 has a 1000BaseSX
PHY and the 10th is used as a system controller.

Comments or ideas welcome.

Cheers,

Peter (p2).



signature.asc
Description: Digital signature

Bug#303488: ITP: openhackware -- OpenFirmware emulator

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover <[EMAIL PROTECTED]>

* Package name: openhackware
  Version : 0.4
  Upstream Author : Jocelyn Mayer <[EMAIL PROTECTED]>
* URL : 
* License : GPL
  Description : OpenFirmware emulator

 OpenHackWare is an OpenFirmware emulator intended to be used on PowerPC
 machines. It is not a real OpenFirmware as it knows nothing about Forth.
 It emulates the OpenFirmare boot time interface as well as the RTAS
 interface. It also emulates some known "interpret" strings, to make it
 able to launch known OSes.

regards,
guillem


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

Bug#303489: ITP: proll -- JavaStation PROM 2.x compatible replacement

[Guillem Jover]

Package: wnpp
Owner: Guillem Jover <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: proll
  Version : 18
  Upstream Author : Pete A. Zaitcev <[EMAIL PROTECTED]>
* URL : 
* License : GPL
  Description : JavaStation PROM 2.x compatible replacement

 Proll is a 2.x PROM compatible replacement for JavaStations, that can
 be used on emulators such as Qemu or to make possible booting Linux, as
 later 3.x series of the PROMs are unable to boot it.
 .
 JavaStations came with two different PROMs installed in them. Version 2.30
 shipped with the earliest Mr. Coffee models, and was updated by latter
 versions of the Sun Netra J software environment to 3.11. Krups and
 Espresso came with 3.x versions of the PROM by default.

regards,
guillem


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

Re: Thoughts about changing Debian's release process

[Andrew Pollock]

On Wed, Apr 06, 2005 at 06:32:02AM +0200, Martin Schulze wrote:
> Andrew Pollock wrote:
> > On Tue, Apr 05, 2005 at 08:38:17PM +0200, Martin Schulze wrote:
> > > Andreas Tille wrote:
> > > > >My point: We need the possibility to recreate the current Debian
> > > > >infrastructure for proposing changes to the current situation.
> > > > Not only this, we need the possibility to setup an alternate machine 
> > > > quickly
> > > > in case of hardware problems.  And we even have the solution inside 
> > > > Debian:
> > > > 
> > > >   FAI
> > > > 
> > > > Why not setting up important machines with FAI?
> > > 
> > > Because that's not the solution.
> > > 
> > > Installing a machine with Debian is not the problem.
> > > 
> > > Installing and/or recreating the services on them is.
> > > This requires manual work, either during the recreation
> > > phase or during the development.
> > 
> > That's not true. If you can script it, FAI can do it. It just becomes a
> > post-installation task. Using packages.d.o as an example, it's just going to
> > be a predominantly an Apache configuration and some scripts, right? So you
> > restore the scripts from backup, and dump the Apache config into the
> > appropriate directory, all from within FAI.
> 
> ... and adding users
> ... and adding groups
> ... and permissions
> ... fixing/checking paths
> ... and adding links
> ... and initialising
> ... and fixing scripts
> ... and fixing the installation
> ... and adding more permissions
> ... and monitoring the initialisation

All doable.
 
> Feel free to package package.debian.org, or qa.debian.org, or
> planet.debian.org, or $whatever for/with FAI.  Then come back.
 
I'm certainly up for the challenge. I may need to hit you up for information
that isn't obvious.
 
> > FAI can be a total disaster recovery solution when you couple it with your
> > backups, however I will freely admit that it takes a lot of time (and
> > testing) to get it such that you can punch out an identical box,
> > sausage-machine style. Then of course you need to keep it up to date as
> > well.
> 
> Feel free to do so.
> 

I'll have a go...

regards

Andrew


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

Re: Why do we still have this on the distribution?

[Andrew Pollock]

On Wed, Apr 06, 2005 at 10:18:23AM +0200, Thijs Kinkhorst wrote:
> On Wed, April 6, 2005 01:09, sean finney said:
> > - sarge is around the corner, and keeping it in means maintaining
> >   it for possibly another 2-4 years!  if it's *already*
> >   no longer maintained upstream...
> 
> This raises a valid point; maybe the maintainer can comment on this? Since
> we already receive no security updates to php3 from upstream, is it
> feasible security-wise to keep it in the distribution for some years to
> come?
> 

I think the opinion of the stable release manager and security team should
rank higher than the maintainer also.

(i.e. if they don't want the overhead of having to support the unsupported
for the next $LENGTH_OF_ETCH_RELEASE_PERIOD then they should be able to veto
it being in the release of Sarge.

regards

Andrew


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

Re: Why do we still have this on the distribution?

[Marcelo E. Magallon]

On Tue, Apr 05, 2005 at 04:43:06PM -0500, Gunnar Wolf wrote:

 > Out of those, they are all either available for php4 as well (php3-*)
 > or depend on either php3 or php4. 

 Just to make the point more explicit:

$ grep-available -n -s Package -F Depends php3 -a ! -F Depends php4 | sort -u
php3-cgi-gd
php3-cgi-imap
php3-cgi-ldap
php3-cgi-magick
php3-cgi-mhash
php3-cgi-mysql
php3-cgi-pgsql
php3-cgi-snmp
php3-cgi-xml
php3-gd
php3-imap
php3-ldap
php3-magick
php3-mhash
php3-mysql
php3-pgsql
php3-snmp
php3-xml

$ grep-available -n -s Package -F Depends php3 -a -F Depends php4 | sort -u
acidlab
acidlab-mysql
acidlab-pgsql
dacode
dcl
eskuel
hawxy
htcheck-php
libphp-hawhaw
libphp-phplot
nagat
phpgroupware-napster
spip
spip-eva
twig

 > Is there a real reason to keep carrying this cruft? I understand the
 > packages are not (or don't appear to be) buggy... However, their bits
 > are rotting. They are not widely used anymore, and they might have
 > all sorts of problems that do not get detected. I don't know if
 > patches for the php4 modules are backported (if the problem exists,
 > of course) for older php3 modules.

 Recently yet another PHP4 vulnerability was reported.  Each time you
 have to wonder if it really doesn't apply to PHP3 or if noone bothered
 to look.

-- 
Marcelo


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

Re: docbook-mathml (or w3-dtd-mathml) don't leave to install gnumexp: possible bug

[Mark Johnson]

Hi Xan,
(BTW, this should really be filed as a bug and probably not posted to devel.)
I somehow missed this message b/c it got filtered to the wrong place. Sorry bout 
that.

I'll look into updating the MathML DTD (& registering it, of course), as well as 
a number of other packages - mostly docbook stuff.

As part of the process, I'll look into compatibility/conflicts with the 
xhtml-mathml-svg-dtd-2 package.

And, to anyone else that reads this: I've hesitated to update docbook-xsl, as 
doing so will break the docbook-website package. Fortunately, we're looking into 
releasing a new (upstream) docbook-website package real soon, so the 
inconvenience should be short-lived.

I'll upload a new docbook-xsl in the next few days and take care of the rest of 
my packages in the next week or so.

Cheers,
Mark
Xan wrote:
Hi,
Recently I installed numexp 0.9.0 with checkinstall (./configure, make, su, 
checkinstall make install) in my Debian Sid. No problems. But when I tried to 
install gnumexp 0.8.0 I received an error with DTD:

gnumexp-0.8.0$./configure
[...]
checking for perl5... no
checking for perl... perl
checking for gconftool-2... /usr/bin/gconftool-2
Using config source xml::/etc/gconf/gconf.xml.defaults for schema installation
Using $(sysconfdir)/gconf/schemas/ as install directory for schema files
checking for public "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"... found.
checking for system "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd";... 
not found!
configure: error: The XHTML plus MathML system identifier is not registered. 
Please install the MathML DTD.
$

The problem is solved if I install the xhtml-mathml-svg-dtd-2 package (another 
time with checkinstall (su, checkinstall make install)). See 
http://numexp.sourceforge.net/downloads.html page.

I commented it to Gustavo (gustavo AT users.sourceforge.net) in a previous 
time, and he said me that it could be a possible bug but that the Debian 
bugzilla is too complex. So I mail you for that.

I think that it's useful that anyone fix this bug (the code of numexp DTD 
package could help you) if it's.

Regards,
Xan.
PS: My versions of packages are:
ii  w3-dtd-mathml  2.0.0.0-1  Mathematical Markup Language 
V2.0 DTD
ii  docbook-mathml 1.0.0-2Extension to DocBook XML for 
using MathML markup

--

Mark Johnson  <[EMAIL PROTECTED]>
Debian XML/SGML:  
Home Page:
GPG fp: DBEA FA3C C46A 70B5 F120  568B 89D5 4F61 C07D E242
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thoughts about changing Debian's release process

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> FAI can be a total disaster recovery solution when you couple it with your
> backups

However mindi/mondo is easier :)

Gruss
Bernd


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

How to superceed one package with another?

[Oliver M. Bolzer]

Hi!

I've been the maintainer of tuxracer, a codebase that has been dead upstream
for quite some time, after upstream went proprietary. PlanetPenguin
Racer (ppracer), a tuxracer-derivat based on the last GPL version of tuxracer,
has recently been packaged and uploaded into the archive by  Alexander Schmehl.
As ppracer is actively maintained and superceeds tuxracer, I wish to
remove tuxracer from the archive, including sarge (i know, it's short),
and provide users with a transition path to a same-but-superiour game.

I am not sure on the necerssary requirement, but are the following steps 
correct for a smooth transition?

tuxracer, tuxracer-data=> planetpenguin-racer, planetpenguin-racer-data

1. Upload new ppracer packages with
   planetpenguin-racer Conflicts/Replaces:  tuxracer
   planetpenguin-racer-data Conflicts/Replaces: tuxracer-data

2. After above has been accepted into the archive,
   upload empty,transitional tuxracer(-data) packages with
   tuxracer Depends: planetpenguin-racer
   tuxracer-data Depends: planetpenguin-racer-data

3. post-sarge, ask for removal of tuxracer packages

Thanks for your advice.
-- 
Oliver M. Bolzer
[EMAIL PROTECTED]

GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761  018F 8786 87AD EF50 D1FF


signature.asc
Description: Digital signature

Re: Why do we still have this on the distribution?

[Don Armstrong]

On Thu, 07 Apr 2005, Andrew Pollock wrote:
> On Wed, Apr 06, 2005 at 10:18:23AM +0200, Thijs Kinkhorst wrote:
> > This raises a valid point; maybe the maintainer can comment on
> > this? Since we already receive no security updates to php3 from
> > upstream, is it feasible security-wise to keep it in the
> > distribution for some years to come?
> 
> I think the opinion of the stable release manager and security team
> should rank higher than the maintainer also.

If the RM and or security team feel that a package is likely to be the
cause of too much grief for them to support security fixes for, they
should explain that fact to the maintainer(s) (if at all possible) and
let the maintainer(s) determine if they will take on the burden of
supporting the package in stable as well. If the maintainer doesn't
want that burden,[1] the maintainer should file a severity serious bug
against the package to keep it from being released in stable.

In the case of this particular package, the codebase isn't going to
rapidly diverge from stable, so any fix that needs to be made in sarge
or etch or $release will have to be made in sid as well. Ideally (heh)
the security team will just be able to apply the patch the
maintainer(s) apply in sid.

Whatever the case, if anyone feels that this (or *ANY*) package is a
security risk, audit it and file bugs against it. Claiming that there
may be security bugs that will possibly be swept under the rug at some
future date when sarge releases[2] just isn't going to do anything for
me.


Don Armstrong

1: I'd argue that anyone who doesn't actually want to support (or at
least help support) their package with security fixes, etc. in stable
probably should already have such a bug filed in the BTS or should be
making sure that they've kept the security team well stocked with
alchohol or whatever tasty bribe the security team prefers. [Or make
users of the package aware of the fact that they'll need to bribe the
security team. ;-)]

2: Vigorously beating a sledgehammer into a tree

-- 
The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot
possibly go wrong goes wrong it usually turns out to be impossible to
get at or repair.
 -- Douglas Adams  _Mostly Harmless_

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Why do we still have this on the distribution?

[Adam Conrad]

Gunnar Wolf said:
>
> Adam: Is there a reason for keeping PHP3 in the archive?

It has users.  One of those users recently let me know that he continues
to use it, because it "just works".  For the curious, that user also
happens to be a member of the security team.  I won't reveal his name, in
case he prefers not to deal with the embarassment of running something as
unhip as an old version of PHP.

> Is there a real reason to keep carrying this cruft? I understand the
> packages are not (or don't appear to be) buggy... However, their bits are
> rotting. They are not widely used anymore, and they might have all sorts
> of problems that do not get detected. I don't know if patches for the php4
> modules are backported (if the problem exists, of course) for older php3
> modules.

It will certainly suffer bitrot, as many (MANY) packages in Debian do.  I
do, however, still attend to bug reports about the packages, and backport
security fixes for vulnerabilities found in php4 that are also present in
php3.  Heck, I even occasioanlly look at non-security bugs and toss those
around a bit.  This is probably more than one can so for maintainers of
many packages with active upstreams.

Someone in this thread mentioned that "upstream doesn't send us patches
for php3, so how will we know how to fix stuff?!".  Well, guess what? 
They often don't send us patches for php4 either (and wouldn't/won't for
php5).  The argument that "upstream doesn't deliver us neat and tidy
security updates for our source packages" would probably invalidate 95% of
our archive.  Maybe not a bad idea. ;)

At any rate.  I will petition for php3's removal when I'm bored with it,
when someone else backs me into a corner to do so, or when I'm convinced
no one uses it or cares about it anymore.

... Adam



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

Re: Bug#302138: incorrect Description line wrapping with bullet lists

[Branden Robinson]

On Wed, Mar 30, 2005 at 03:54:36AM -0600, Peter Samuelson wrote:
> [Peter Samuelson]
> > I'd like to file a mass bug for these, but it's on the order of 583
> > binary packages in 430 source packages, so I obviously want to get
> > some feedback first.
> 
> Jeroen van Wolffelaar pointed out to me that 430 source packages is a
> bit much for a mass bug, especially if lintian/linda could flag this
> stuff automatically, which is probably the case.
> 
> Lars Wirzenius also suggested that I name names so people will know if
> they're affected.  So here are source packages grouped by maintainer.
> Data is from /var/lib/apt/lists/*_Packages on an i386 sid box.
[...]
> Branden Robinson <[EMAIL PROTECTED]>:
>   twofish

Go ahead and file a bug for this one, please -- twofish sees so little
activity that I'm likely to forget to fix this, and having an open bug
report against it will remind me to start maintaining the package from a
Subversion repository.

Thanks for helping to make our package descriptions something we can be
proud of!

-- 
G. Branden Robinson|
Debian GNU/Linux   |Yeah, that's what Jesus would do.
[EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Thoughts about changing Debian's release process

[Andreas Tille]

On Thu, 7 Apr 2005, Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
FAI can be a total disaster recovery solution when you couple it with your
backups
However mindi/mondo is easier :)
For the recovery issue perhaps (I never managed it to work BTW), but not for
the documentation issue.
Kind regards
   Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]