Things people need for erection dysfunctions

[Carrie]

Buy cheap Viagra through us.
http://vzqRPugw.h64.net/pharm/sevy/sonic.html

Carrie


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

Media + smarthome solution for UPNP users

[ionut . f]

Pluto is a new, open source smart home solution that seamlessly integrates:  1)
media with a server for music, movies and tv shows, plus a PVR and DVD Player,
2) a home automation system with touch-screen tablet and Bluetooth mobile phone
controllers, 3) a phone system with video conferencing, 4) a security system
that feeds you live video on your mobile phone when there are interruptions,
and lets you speak to visitors through your stereos, and 5) a home PC solution.
 Check it out at www.plutohome.com.

We also posted a page at www.plutohome.com/dce.php explaining how we can help
promote the established standards, like UPNP, while we focus on delivering a
consumer-friendly experience.  If you’re working on UPNP devices and would like
a freely distributable whole house solution to showcase your device, we have
forums, or you can send an email to aaron.b [at] plutohome.com.

The support site sums up Pluto for techies and open source developers:
www.plutohome.com/support





This message was sent using IMP, the Internet Messaging Program.


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

Get rid of premature orgasms

[Antoinette]

Viagra - very low price
http://zrafFNst.nlav.com/pharm/sevy/baroque.htm

Antoinette


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Gaudenz Steinlin]

On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:
> Long version:
> The current version of the release notes tells users to (simplified):
> 1. apt-get install aptitude
> 2. change the /etc/apt/sources.list to point to "stable"
> 3. aptitude update
In my test a few days ago I had to use apt-get update because of a bug
in aptitude which refused to update the files from the new source. I'm
not sure if this was only because I also changed to an other mirror. 

I'd change the release notes to tell users to do apt-get update to work
around this bug in woodys aptitude.

> 4. aptitude -f --with-recommends dist-upgrade
> 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpz7yLOlXpFm.pgp
Description: PGP signature

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Gaudenz Steinlin]

On Tue, May 17, 2005 at 07:28:05AM -0500, Bill Allombert wrote:
> retitle 309357 woody aptitude update can fail
> quit
> On Tue, May 17, 2005 at 01:45:14PM +0200, Gaudenz Steinlin wrote:
> > On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:
> > > Long version:
> > > The current version of the release notes tells users to (simplified):
> > > 1. apt-get install aptitude
> > > 2. change the /etc/apt/sources.list to point to "stable"
> > > 3. aptitude update
> > In my test a few days ago I had to use apt-get update because of a bug
> > in aptitude which refused to update the files from the new source. I'm
> > not sure if this was only because I also changed to an other mirror. 
> > 
> > I'd change the release notes to tell users to do apt-get update to work
> > around this bug in woodys aptitude.
> 
> This is bug #309357, though I cannot reproduce the problem with my
> setup (with neither aptitude 0.2.11.1-3 nor 0.2.11.1-4).

I just downgraded to aptitude 0.2.11.1-4 and apt 0.5.4 (on the upgraded
sarge system) and can reproduce this bug. If I change the lines back to
woody in sources.list aptitude update fails while apt-get update succeeds.

aptitude 0.2.15.9-2 and apt 0.5.28.6 from sarge don't have this bug. 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgp1QFjmY4O1B.pgp
Description: PGP signature

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Bill Allombert]

retitle 309357 woody aptitude update can fail
quit
On Tue, May 17, 2005 at 01:45:14PM +0200, Gaudenz Steinlin wrote:
> On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:
> > Long version:
> > The current version of the release notes tells users to (simplified):
> > 1. apt-get install aptitude
> > 2. change the /etc/apt/sources.list to point to "stable"
> > 3. aptitude update
> In my test a few days ago I had to use apt-get update because of a bug
> in aptitude which refused to update the files from the new source. I'm
> not sure if this was only because I also changed to an other mirror. 
> 
> I'd change the release notes to tell users to do apt-get update to work
> around this bug in woodys aptitude.

This is bug #309357, though I cannot reproduce the problem with my
setup (with neither aptitude 0.2.11.1-3 nor 0.2.11.1-4).

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

Imagine a large red swirl here.


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

Re: Debian Woody -> Sarge upgrade report

[Jonathan McDowell]

On Mon, May 16, 2005 at 11:21:12AM -0400, Roberto C. Sanchez wrote:
> Quoting Jonathan McDowell <[EMAIL PROTECTED]>:
> >On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote:
> >>Jonathan McDowell wrote:
> >>> H. I run with my own CA signed cert and had no problems with a
> >>> Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your
> >>> /etc/sslwrap/debian_conf and the output of
> >>> "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)?
> >>Did you want to see what they looked like before or after the upgrade?
> >
> >Both, if possible. Whatever you've got easily would be a good start
> >though.
[both the same and as follows:] 
> # grep sslwrap inetd.conf
> ssmtp   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
> /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25
> imaps   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
> /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143
> 
> /etc/sslwrap/debian_config:
> run_mode="inetd"
> used_addr="127.0.0.1"
> with_certificate="true"
> certfile="/etc/ssl/server_key_and_cert.pem"
> overwrite_corrupted_certfile="false"
> check_cert="true"
> ports="imaps, ssmtp"

> I no longer have sslwrap installed since postfix-tls now properly grabs port
> 465 without dying and cyrus21 supports imaps (though last night I switched
> to courier, which also natively does imaps). 

Yes, these days sslwrap is thankfully not so necessary as applications
are now able to link against the crypto code themselves.

> The problem, if you refer to my original mail, is that something about
> the CA was confusing sslwrap, which I believe tried to generate its
> own cert.
 
Is your root cert installed into the openssl framework (ie plumbed into
/etc/ssl/certs)? I think if that's not the case then as you have
"check_cert" set to true it'll fail to be able to validate the cert. I'm
surprised you haven't seen errors about this before on boot however.

J.

-- 
/-\ | "Bother", said Pooh, "Who put sand
|@/  Debian GNU/Linux Developer |in the Vaseline?!?".
\-  |


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

Re: Debian Woody -> Sarge upgrade report

[Roberto C. Sanchez]

Quoting Jonathan McDowell <[EMAIL PROTECTED]>:
On Mon, May 16, 2005 at 11:21:12AM -0400, Roberto C. Sanchez wrote:
The problem, if you refer to my original mail, is that something about
the CA was confusing sslwrap, which I believe tried to generate its
own cert.
Is your root cert installed into the openssl framework (ie plumbed into
/etc/ssl/certs)? I think if that's not the case then as you have
"check_cert" set to true it'll fail to be able to validate the cert. I'm
surprised you haven't seen errors about this before on boot however.
No errors that I can see.  My root cert is in /etc/ssl/demoCA.  Everything
seems to find it just fine.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309497: ITP: md5deep -- a cross-platform set of programs to compute MD5, SHA-1, SHA-256, or Whirlpool message digests on an arbitrary number of files

[Niall Sheridan]

Package: wnpp
Severity: wishlist
Owner: Niall Sheridan <[EMAIL PROTECTED]>


* Package name: md5deep
  Version : 1.6
  Upstream Author : Jesse Kornblum <[EMAIL PROTECTED]>
* URL : http://md5deep.sourceforge.net
* License : GPL
  Description : a cross-platform set of programs to compute MD5, SHA-1, 
SHA-256, or Whirlpool message digests on an arbitrary number of files

md5deep is similar to the md5sum program found in the GNU Coreutils 
package, but has the following additional features:

* Recursive operation - md5deep is able to recursive examine an entire 
  directory tree. That is, compute the MD5 for every file in a 
  directory and for every file in every subdirectory.
* Time estimation - md5deep can produce a time estimate when it's
  processing very large files.
* Comparison mode - md5deep can accept a list of known hashes and 
  compare them to a set of input files. The program can display either
  those input files that match the list of known hashes or those that 
  do not match. Hashes sets can be drawn from the National Software
  Reference Library, iLook Investigator, Hashkeeper, or md5sum.
* File type mode - md5deep can process only files of a certain type,
  such as regular files, block devices, etc. 

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-2um
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8)


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

Re: RES: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> I don't personally care on /usr/lib vs. /usr/libexec, except that the idea
> of going through and changing all the packages in Debian really doesn't
> appeal to me (and however easily spread that cost, it's a lot of work --
> it's more work than the /usr/doc migration, and that was a PITA).  I do
> care a *lot* about consistency.  Having a mix of /usr/lib and /usr/libexec
> is, in my opinion, significantly worse than either one or the other.

Most packages had files in /usr/doc.  Most packages do not have files
in /usr/lib at all, and most of those that do, wouldn't need to be
changed.


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

Re: Bug#309241: ITP: dguitar -- Guitar Pro 3/4 tabs viewer and player

[Adrian von Bidder]

On Sunday 15 May 2005 23.24, Grzegorz Bizon wrote:

>   Description : Guitar Pro 3/4 tabs viewer and player

Somebody should file a wishlist bug against all guitar related software 
packages to include a certain song as example data.

I won't name it.  If you're new on this list, google for "self-perpetuating 
google flop".

-- vbi

-- 
Beware of the FUD - know your enemies. This week
* The Alexis de Toqueville Institue *
http://fortytwo.ch/opinion/adti


pgpbe71xQBgnF.pgp
Description: PGP signature

Re: removing ipfwadm

[Adrian von Bidder]

On Monday 16 May 2005 23.27, Marco d'Itri wrote:
> On May 16, Adam McKenna <[EMAIL PROTECTED]> wrote:
> > I am not sure whether the ipfwadm package should be removed.  Kernels
> > up to 2.4 still have support for ipfwadm filtering rules, so
> > theoretically people could still be using it with current kernels.
>
> Wait until sarge has been released and then kill it.

Is it orphaned?  If not, why kill it?  Some people have invested many hours 
writing their firewall scripts, and if they can continue to use them 
they're happy.

(Not me - ipfwadm hasn't done enough for my taste in a long time.)

cheers
-- vbi

-- 
Kallisti!


pgpZJAdMpXCBK.pgp
Description: PGP signature

Re: updated cogito package - now with docs!

[Adrian von Bidder]

[cc:ed as I don't know if you read both -devel and -mentors]

On Wednesday 11 May 2005 22.05, Sebastian Kuzminsky wrote:
[cogito]

Sebastian, can I humbly request that you don't announce cogito package 
updates on (at least the -devel) mailing list?  While I - and, I guess, 
many others - are thrilled to see cogito packaged, I'd hate it if everybody 
now started to announce every new package version on -devel...

thanks
-- vbi

-- 
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion


pgpgNKSZ1IIUd.pgp
Description: PGP signature

Re: updated cogito package - now with docs!

[Sebastian Kuzminsky]

Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> Sebastian, can I humbly request that you don't announce cogito package
> updates on (at least the -devel) mailing list?


Yeah that was a little excessive, sorry.  I'm a noob and I got excited,
I'll pipe down.  :-}




-- 
Sebastian Kuzminsky


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

Sarge Release Notes - Architecture specific news?

[Frans Pop]

If there is any architecture specific news that you'd like to have 
included in the Release Notes (like new subarchs supported or dropped), 
please send a proposed text to the d-doc mailing list (CC the list for 
the architecture) before the end of this week.

Cheers,
Frans Pop


pgpJSfW0bTfFl.pgp
Description: PGP signature

Re: RES: /usr/lib vs /usr/libexec

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> you wrote:
>> I do believe you've missed the point.  Splitting /usr from / helps in
>> a teeny percentage of cases, and most of the cases where it "helps"
>> that have been mentioned here, it actually doesn't.  Yet, splitting
>> /usr/lib, which is grotesquely huge and hard to deal with, is treated
>> as an impossible thing, needing a great level of proof before it can
>> be considered.  This is very foolish.
>
> Thats why we need proof that it helps. Nobody  has provided any numbers,
> here.

IMHO the performance benefits are a red herring.  For myself at least,
the general increase in tidiness would be far more beneficial.

> You missed the point. It is not about getting rid of directories it is about
> creating a new one.

Not really; it's already in common use.  However, all packages
committing the sin of using it have to be specially patched or
configured to remove the taint.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCik77VcFcaSW/uEgRAgySAJ45AQx5BOfCZsQOeJi6vOzDrFNHqgCeLOxs
9suFJefavjQNSlcxG5HXj28=
=eNR8
-END PGP SIGNATURE-


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

Re: Bug#309241: ITP: dguitar -- Guitar Pro 3/4 tabs viewer and player

[David Schleef]

On Tue, May 17, 2005 at 08:08:05PM +0200, Adrian von Bidder wrote:
> On Sunday 15 May 2005 23.24, Grzegorz Bizon wrote:
> 
> >   Description : Guitar Pro 3/4 tabs viewer and player
> 
> Somebody should file a wishlist bug against all guitar related software 
> packages to include a certain song as example data.
> 
> I won't name it.  If you're new on this list, google for "self-perpetuating 
> google flop".

It does not appear to be available under a DFSG-compatible license. ;)
Even though the Song That Shall Not Be Named seems ancient, it's really
only about 50 years old and still under copyright.



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux


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

Re: RES: /usr/lib vs /usr/libexec

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
>> I do believe you've missed the point.  Splitting /usr from / helps in a
>> teeny percentage of cases, and most of the cases where it "helps" that
>> have been mentioned here, it actually doesn't.  Yet, splitting /usr/lib,
>> which is grotesquely huge and hard to deal with, is treated as an
>> impossible thing, needing a great level of proof before it can be
>> considered.  This is very foolish.
>
> The difference being that Debian has already split /usr from / and
> therefore is only paying the marginal cost of maintaining it, whereas
> Debian has not split /usr/lib from /usr/libexec and would have to pay the
> (far larger) initial cost of moving everything around.

Not really, since in many cases libexec was /already the default/.  In
these cases we are deliberately diverging from upstream, and so we
would be removing extra patches and customisations from our diffs.

Additionally, the migration is not difficult, and can be done over an
extended period.  It's not like I want a flag day when we must all
convert, I just want the option of using it.

The only reason we don't have it is FHS infighting, otherwise we would
have been using it eight years ago.  I don't consider that a good
reason to ignore it.

> I think it's quite reasonable for that far larger initial cost to require
> substantial justification, far more justification than is required for
> preserving a property that Debian has already paid the cost to establish
> and is just maintaining.

We've paid the price by shoving every bit of uncategorised junk into
one big festering sore: /usr/lib.  Making it a little tidier by
categorising some of its contents slightly differently is not a bad
thing.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCilCxVcFcaSW/uEgRAhC/AJ4gdjPtblrEzDRYZiydvm4hoiPtVACg8zSW
SGl0MKKQNHEHjNXhd5BrptQ=
=xMFl
-END PGP SIGNATURE-


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Frans Pop]

On Monday 16 May 2005 17:58, Frans Pop wrote:
> Should users first upgrade dpkg and aptitude before upgrading the rest
> of the system or can the upgrade safely be done using Woody's version
> of the package tools?

From the reactions to this thread and a thread on #309340 [1], the 
consensus seems to be that the upgrade method least likely to have 
problems is:

1. Check that /etc/apt/sources.list points to "woody"
2. apt-get update
3. apt-get install aptitude
4. change the /etc/apt/sources.list to point to "sarge"
5. apt-get update
6. aptitude install aptitude dpkg
7. aptitude -f --with-recommends dist-upgrade

Comments
1. If the sources.list pointed to stable the user should check if
   he has already updated anything; he will be largely on his own
   if that should produce problems.
3. Woody's aptitude is installed because using that to install/upgrade
   to Sarge's aptitude produces less problems than using apt-get.
4. The consensus seems to be that using "sarge" instead of "stable" is
   more secure as it will prevent premature upgrades for a next release.
5. apt-get is used to work around #309357.


The main open question now is step 6. There are two options:
- upgrade both aptitude and dpkg _before_ the dist-upgrade;
- upgrade _only_ aptitude and leave the upgrade of dpkg to be done as
  part of the dist-upgrade.

From my own experiences [2] it seems it could be wise to advise a bit more 
flexible method. For me 'aptitude install aptitude dpkg perl' (i.e. with 
"perl" added) produced the best results for step 6.


Cheers,
FJP

[1] http://lists.debian.org/debian-testing/2005/05/msg00060.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309548


pgpUlcyROdGLg.pgp
Description: PGP signature

Prods to the ftpmasters

[martin f krafft]

I just wanted to say a big thank you to the ftpmasters for improving
the NEW queue situation in such a noticable manner. Despite all the
stress that sarge must be causing on y'all, I was very happy (and
joyfully surprised) to find two of my NEW packages being approved
within just three days.

Thanks a lot for your work, and for making Debian a more pleasurable
place for developers!

:)

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
gentoo: the performance placebo.


signature.asc
Description: Digital signature

Re: NFSv4 support absent from mount

[Jerome Warnier]

Le vendredi 13 mai 2005 à 13:00 +0200, Steinar H. Gunderson a écrit :
> On Fri, May 13, 2005 at 12:52:14PM +0200, Jerome Warnier wrote:
> > As #302420 says, NFSv4 is not supported by current "mount" (part of
> > util-linux) in Sarge/Sid while support is present for the server part.
> > It would be great to have it in Sarge, if still possible, or at least in
> > Sid soon.
> > Please see the bugreport (still unanswered now) for the patch.
> 
> Note that as soon mount gets NFSv4 support, #294959 becomes RC.
> 
> You should also perhaps merge the bug with #236435/#254775.
Bugs #290873 and #239611 are also related directly.


> /* Steinar */
-- 
Jerome Warnier <[EMAIL PROTECTED]>
BeezNest

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 1. Check that /etc/apt/sources.list points to "woody"
> 2. apt-get update
> 3. apt-get install aptitude

perhaps use "--reinstall"  or "aptitude/woody" to force downgrade?

> 4. change the /etc/apt/sources.list to point to "sarge"
> 5. apt-get update

> 6. aptitude install aptitude dpkg

and here we could use "aptitude install aptitude dpkg/sarge" just to be sure

> 7. aptitude -f --with-recommends dist-upgrade

> 1. If the sources.list pointed to stable the user should check if
>   he has already updated anything; he will be largely on his own
>   if that should produce problems.

Yes, I wonder if we should force downgrade?

> 4. The consensus seems to be that using "sarge" instead of "stable" is
>   more secure as it will prevent premature upgrades for a next release.

and it works pre-release (aka now)

Greetings
Bernd


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

Debian as living system

[Bluefuture]

Actually debian has three distro "level": unstable testing and stable.
There are some policy for packages entering in testing but for stable we
must to go "on freeze when ready" and fix all remain rc bugs before
release. With this proposal i want to remove the release concept but we
need some infrastructural changes.

- We must improve and doesn't trash tests made in unstable:

A new upstream package could enter in unstable only if the actual package 
in unstable isn't old more than "testing waiting time"/2 or if the upstream 
release fix some rc bug in the actual package in testing.

- We must to use this same policy adding the normal unstable to testing
policy from testing to stable using a "stable waiting time" that could
be fixed to 30/60/90 days according to the priority (and eventually
section) of the packages.

So we cannot have entering two different packages in stable less than 30
days in the optimal case when also dependency are old enough and rc bugs
free. If a security bugs comes out when a packages is in testing will be
opened an rc bugs in testing or also in unstable if needed. If we have a
security bugs when the package land in stable we fix trough
stable/updates. 

So we will have a very slowly stable release moving without the needs of
formal freeze and releases: a "living" system.

Official cd are daily (or weekly) rebuilded snapshots of the stable
distro or net installable cd images.

The wiki of to improve the proposal could be find here[1].

Cheers,
Stefano

[1] http://wiki.debian.net/?LivingSystem


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Steve Langasek]

Hi Frans,

On Wed, May 18, 2005 at 12:31:29AM +0200, Frans Pop wrote:
> On Monday 16 May 2005 17:58, Frans Pop wrote:
> > Should users first upgrade dpkg and aptitude before upgrading the rest
> > of the system or can the upgrade safely be done using Woody's version
> > of the package tools?

> From the reactions to this thread and a thread on #309340 [1], the 
> consensus seems to be that the upgrade method least likely to have 
> problems is:

> 1. Check that /etc/apt/sources.list points to "woody"
> 2. apt-get update
> 3. apt-get install aptitude
> 4. change the /etc/apt/sources.list to point to "sarge"
> 5. apt-get update
> 6. aptitude install aptitude dpkg
> 7. aptitude -f --with-recommends dist-upgrade

> Comments
> 1. If the sources.list pointed to stable the user should check if
>he has already updated anything; he will be largely on his own
>if that should produce problems.
> 3. Woody's aptitude is installed because using that to install/upgrade
>to Sarge's aptitude produces less problems than using apt-get.
> 4. The consensus seems to be that using "sarge" instead of "stable" is
>more secure as it will prevent premature upgrades for a next release.
> 5. apt-get is used to work around #309357.

> The main open question now is step 6. There are two options:
> - upgrade both aptitude and dpkg _before_ the dist-upgrade;
> - upgrade _only_ aptitude and leave the upgrade of dpkg to be done as
>   part of the dist-upgrade.

> From my own experiences [2] it seems it could be wise to advise a bit more 
> flexible method. For me 'aptitude install aptitude dpkg perl' (i.e. with 
> "perl" added) produced the best results for step 6.

Is there a difference in packages removed if you run "aptitude install
aptitude" instead of "aptitude install aptitude dpkg"?  I don't see any
reason why dpkg needs to be upgraded first, unlike aptitude.

If perl needs to be added to the list, I say to just add it.  People who
have Prio: standard packages missing from their systems probably won't want
to follow our advise to use aptitude, either.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Debian as living system

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> - We must improve and doesn't trash tests made in unstable:

Why do we need to do that? A package which is clearly  improved or outdated
does not need any testing.

> - We must to use this same policy adding the normal unstable to testing
> policy from testing to stable using a "stable waiting time" that could
> be fixed to 30/60/90 days according to the priority (and eventually
> section) of the packages.

We dont change stable, this does not work you can only test the system as a
whole.

> So we cannot have entering two different packages in stable less than 30
> days

sure we can.

> So we will have a very slowly stable release moving without the needs of
> formal freeze and releases: a "living" system.

Kind of cancer?

> Official cd are daily (or weekly) rebuilded snapshots of the stable
> distro or net installable cd images.

And you cant do QA nur security update, create additional mirror load on
stable and kill cd distributors.

I think you can do that for non-core packages like bsd packages, but the
base system must be released as a whole.

Greetings
Bernd


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

Re: Prods to the ftpmasters

[Daniel Jacobowitz]

On Wed, May 18, 2005 at 12:32:54AM +0200, martin f krafft wrote:
> I just wanted to say a big thank you to the ftpmasters for improving
> the NEW queue situation in such a noticable manner. Despite all the
> stress that sarge must be causing on y'all, I was very happy (and
> joyfully surprised) to find two of my NEW packages being approved
> within just three days.
> 
> Thanks a lot for your work, and for making Debian a more pleasurable
> place for developers!

That sounds like props, not like prods...

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: Re: Debian as living system

[Bluefuture]

> > - We must improve and doesn't trash tests made in unstable:
> 
> Why do we need to do that? A package which is clearly  improved or outdated
> does not need any testing.

Because, for example if i release three revision of a package in a month and i 
upload in unstable,
it is in a good status with no rc bugs, still must waiting two days for 
entering in testing, but i override
it uploading the new upstream version package then i must restart to testing 
the new upstream version in unstable without
having the old version entering in testing and probably maintaing an old one in 
testing untill the new upstream packaged
version is in a good shape and is old enought for land in testing.

> > - We must to use this same policy adding the normal unstable to testing
> > policy from testing to stable using a "stable waiting time" that could
> > be fixed to 30/60/90 days according to the priority (and eventually
> > section) of the packages.
> 
> We dont change stable, this does not work you can only test the system as a
> whole.
> 

Actually we doesn't change stable, but with the new infrastructure we can start.
I think that a system could be tested with a group of packages an its 
dependencies.
Big infrastructural changes (as a new install system) could be done of the 
stable system and land in stable when done.
Stable, testing and unstable could has different infrastructures and cd 
snapshot so that infrastructural changes land 
one by one in stable only when ready.

> > So we cannot have entering two different packages in stable less than 30
> > days
> 
> sure we can.
This was an assumption of not to have too many frequent software changes in 
stable.
Probably if i have Inkscape installed and i'm running stable also if upstream 
release a new version every week
in the optimistic use cases i cannot must to use a new version of it less then 
30/60/90 days following the testing to 
stable policy.

> 
> > So we will have a very slowly stable release moving without the needs of
> > formal freeze and releases: a "living" system.
> 
> Kind of cancer?
Not only to do thinks slowly with little changes without having a total 
different os and applications after one/two 
or three year of upstreams work impact to the distro users.
> 
> > Official cd are daily (or weekly) rebuilded snapshots of the stable
> > distro or net installable cd images.
> 
> And you cant do QA nur security update, create additional mirror load on
> stable and kill cd distributors.
Security updates are done through security/updates if u done daily cd rebuild u 
have the last security updates 
on the cd every day if u want to do a new install. After installing a day X 
snapshot you can follow
day x+n security updates through security.debian.org.
> 
> I think you can do that for non-core packages like bsd packages, but the
> base system must be released as a whole.
For base system we could create something like a group or branching levels 
using some dependencies info 
so it can land to stable only as a whole. 

Greetings,
Stefano


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

Bug#309574: ITP: libmath-combinatorics-perl -- Perform combinations and permutations on lists

[Carlo Segre]

Package: wnpp
Severity: wishlist
Owner: Carlo Segre <[EMAIL PROTECTED]>


* Package name: libmath-combinatorics-perl
  Version : 0.04
  Upstream Author : Allen Day <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Math/
* License : GPL / Artistic
  Description : Perform combinations and permutations on lists

Combinatorics is the branch of mathematics studying the enumeration,
combination, and permutation of sets of elements and the mathematical
relations that characterize their properties. As a jumping off point,
refer to:

http://mathworld.wolfram.com/Combinatorics.html

This module provides a pure-perl implementation of nCk, nPk, and n!
(combination, permutation, and factorial, respectively).


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: packages missing from sarge

[Steve Langasek]

On Mon, May 16, 2005 at 05:39:42PM -0400, Anthony DeRobertis wrote:
> On May 15, 2005, at 22:16, Steve Langasek wrote:

> >Still, the concerns about re-adding this software version (which  
> >has been
> >out of testing for months) via t-p-u remain.

> Its hard to see it being any worse than freeswan, which has been  
> abandoned for a while by its upstream. And if it turns out to be a  
> problem, it could just be removed again, right?

It could be removed again, but only if someone finds out that it's broken
*before* we release.  There is a very small window for this to happen,
because packages don't get widespread testing while they're in
testing-proposed-updates, so the only testing that will happen will be
between the time the package is pushed into testing (once it's built
everywhere it needs to be) and the release date.  With the delays in getting
t-p-u built across architectures, that's not long enough for me to be
comfortable.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#309575: ITP: libtime-stopwatch-perl -- Use tied scalars as timers

[Carlo Segre]

Package: wnpp
Severity: wishlist
Owner: Carlo Segre <[EMAIL PROTECTED]>


* Package name: libtime-stopwatch-perl
  Version : 1.00
  Upstream Author : Ilmari Karonen <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/Time
* License : GPL / Artistic
  Description : Use tied scalars as timers

The Time::Stopwatch module provides a convenient interface to timing
functions through tied scalars.  From the point of view of the user, 
scalars tied to the module simply increase their value by one every 
second.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

ePills

[Vivian]

Same Medication - Low Price
http://sfs.ixltm10tfa084j0.tallddeid.com

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

Re: RES: /usr/lib vs /usr/libexec

[Glenn Maynard]

On Tue, May 17, 2005 at 11:00:09AM -0700, Thomas Bushnell BSG wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
> 
> > I don't personally care on /usr/lib vs. /usr/libexec, except that the idea
> > of going through and changing all the packages in Debian really doesn't
> > appeal to me (and however easily spread that cost, it's a lot of work --
> > it's more work than the /usr/doc migration, and that was a PITA).  I do
> > care a *lot* about consistency.  Having a mix of /usr/lib and /usr/libexec
> > is, in my opinion, significantly worse than either one or the other.
> 
> Most packages had files in /usr/doc.  Most packages do not have files
> in /usr/lib at all, and most of those that do, wouldn't need to be
> changed.

I'm not quite understanding the benefit: some theoretical speed benefit
from reduced library searching (that would go away with the much more
general fix of making sure Debian configures filesystems with better-
than-O(n) searching by default; that is, making sure we're not in the
stone age), in exchange for cluttering /usr with another second-level
directory.

(I'd expect the dynamic linker to mostly deal with the soname symlinks,
anyway; moving them somewhere else, to get the searches away from the
shared and static libraries themselves, would probably would probably be
more effective.  It even seems, intuitively, like the Right Thing, though
probably not worth the bother.)

Most applications I've seen that use libexec make it entirely trivial
to move it to /usr/lib: "./configure --libexecdir=/usr/lib".  (I don't
think apps that don't do this, or something like it, should be a major
consideration here--take apps out of the stone age, don't clutter my
/usr ...)

I'm just not seeing any benefits that are worth bloating /usr.

-- 
Glenn Maynard