date:20031002

On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant wrote:

> > * September 1st

> > HOWTO use debian-installer to install sarge posted to
> > -devel-announce (volunteers appreciated)

> Ah yes, what a wonderful read that was ... no, wait, this never
> happened.

Message-ID: <[EMAIL PROTECTED]>

> > Beta testing of installation with sarge CD images by
> > adventurous users

> There are sarge CD images?  gosh.

http://gluck.debian.org/cdimage/testing/netinst/i386/ (and now
powerpc/, alpha/), as documented in the post to d-d-a. ;)

> > * September 15th

> > Beta testing of the installation (debian-installer, tasksel,
> > base-config, package installs, CD images, everything)

> Is everything even ready for this yet?

Well, on some architectures, it seems so. :)

There are problems with glibc headers on at least (ia64,alpha) which
render debootstrap useless on those architectures; the current plan
seems to be for glibc to kick the dependency on those non-userspaceable
headers in the very near future.  (Hold on to your hats.)

> I think it's fair to say that we're not going to reach the following
> state within 14 days unless a miracle, or a hell of a lot of work
> happens:

Well, let's not dismiss the "hell of a lot of work" option.  I'm happy
to distribute spades to any volunteers.

> So "Where are we now?"  Having played with d-i some and kept a watchful
> eye on the release-critical list, I guess we're currently at the
> "September 15th" dateline which puts us roughly 14 days behind schedule.

I think we're ahead of the September 15th milestone, but not as far
ahead as we might wish.  Which means we're also not as far behind as we
might have feared. :)

> > * October 1st

> > Drop the RC bug list by ~150 bugs to ~100
> > (via removals, fixes and workarounds)

> Current RC bug stats:

> Total number of release-critical bugs: 679
> Number that will disappear after removing packages marked [REMOVE]: 53
> Number that have a patch: 94
> Number that have a fix prepared and waiting to upload: 29
> Number that are being ignored: 15
> Number on packages not in testing: 197

> So with a bit of math, that sounds like 414 RC bugs left, with 123 that
> have either patches (why aren't they applied?) or pending (why aren't
> they uploaded?)

> We're a HELL of a long way north of the target of 100 RC bugs left!

Yes, indeed we are.  Though FWIW, since AJ has clarified that the
timeline was intended to indicate those activities that would take place
*between* the times above and below, we are at present only 164 RC bugs
behind schedule.  Oh, no, wait -- there's a math error in the timeline,
and 500-150-150 != 100... so I'm not sure how many bugs behind that
really puts us. :)

It's been noted several times that the end of the 0-day NMU period was
accompanied by a marked reversal in the RC bug graph.  I think it's time
for a group debriefing of this experience.  I was pleasantly surprised
to have not heard of a single complaint about bad NMUs during this
period, either personally in response to my own NMUs or on the lists.
I found it helped me work more efficiently on packages that needed
attention, and I know it would speed things up while trying to push
large clots of packages into testing at once!  As a result, I think we
should seriously consider retaining this 0-day policy for the remainder
of the present release cycle, even if only for RC bugs; it could give us
the extra boost we need to catch up on our RC list.

Does anyone have a different reaction to the 0-day NMU experiment?
Looking at the graphs, I know I'm not the only one who took advantage of
it.

-- 
Steve Langasek
postmodern programmer

signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Scott James Remnant

On Thu, 2003-10-02 at 06:45, Steve Langasek wrote:

> On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant wrote:
> 
> > >   * September 1st
> 
> > >   HOWTO use debian-installer to install sarge posted to
> > >   -devel-announce (volunteers appreciated)
> 
> > Ah yes, what a wonderful read that was ... no, wait, this never
> > happened.
> 
> Message-ID: <[EMAIL PROTECTED]>
> 
Ya know, I grepped high and low for this just in case I missed it, and
couldn't find it.  And yet, there is it, and it's in my debian mailbox
too.

I'll have to put that down to writing things like this at 6am.

> It's been noted several times that the end of the 0-day NMU period was
> accompanied by a marked reversal in the RC bug graph.  I think it's time
> for a group debriefing of this experience.  I was pleasantly surprised
> to have not heard of a single complaint about bad NMUs during this
> period, either personally in response to my own NMUs or on the lists.
> I found it helped me work more efficiently on packages that needed
> attention, and I know it would speed things up while trying to push
> large clots of packages into testing at once!  As a result, I think we
> should seriously consider retaining this 0-day policy for the remainder
> of the present release cycle, even if only for RC bugs; it could give us
> the extra boost we need to catch up on our RC list.
> 
D'oh ... the entire reason for me writing that mail was because I
noticed the "end of NMUfest debrief" hadn't happened and I forgot to
mention it!

> Does anyone have a different reaction to the 0-day NMU experiment?
> Looking at the graphs, I know I'm not the only one who took advantage of
> it.
> 
Nobody NMUd any of my difficult bugs *wail!* does that count as a
negative reaction? :o)

Seriously, I found that the whole thing worked rather well -- reopening
it again might be just the thing we need to push that bug list graph
downwards again.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Looking for a co-maintainer for adduser

2003-10-02 Thread Roland Bauerschmidt

The number of bugs on the adduser package has constantly increased for
the last few months, though none of them is release critical. Since I
was busy with other stuff (mostly OpenLDAP and related stuff) I didn't
keep up with all the feature requests and non-critical bugs. This is
also partly due to the fact that I don't like the way adduser is
currently written (and also perl) a lot, and was planning to do a
complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml).

Matthew Palmer has done some nice work in abstracting the passwd storage
backend, and adding methods for LDAP storage. The latter, though, still
needs some more work to be useful in different directory structures.

I am thus seeking for one or two co-maintainers, and appreciate it a lot
if Matthew would chose to be one of them. The package is managed in a
Subversion repository on Alioth. The main package is in trunk, Matthew's
LDAP extended version in brances/adduser-ldap (which should eventually
be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser
repository. It'd be particularly useful, if you have NIS experience (and
maybe even a running setup), but not required. There is an adduser-devel
also on Alioth.

If you are interested, drop me a note off-list.

-- Roland

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Sebastian Ley

Am Do, den 02.10.2003 schrieb Martin Michlmayr um 07:42:

>  * Debian-Installer HOWTO Sebastian Ley
> http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200309/msg7.html

During the last debcamp we took the opportunity to introduce some last
major changes which leaves us presently again with unusable images. But
a fix for all the problems is underway, and agter that we will ensure
that there is always a version which has been known to work I'll post
the status on the present showstoppers on debian-boot.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Where are we now? (Was: Bits from the RM)

I still need to get KDE 3.1.4 into sid and stablized. I hope for it to
be ready to migrate into sarge by Oct 20 (including the 10 day wait
time). From what Colin Watson mentioned to me earlier today there are
some other packages that are holding KDE out as well so hopefully they
are resolved by then.

Chris Cheney


signature.asc
Description: Digital signature

Re: libstdc++2.8 wherefor art thou?

On Thu, Oct 02, 2003 at 12:58:51AM -0400, Gregory Stark wrote:
> What happened to libstdc++2.8 ? I have local files installed that
> depend on this library. Is there a solution?

You could always pull it from an old release - I doubt it's changed.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Looking for a co-maintainer for adduser

2003-10-02 Thread Domenico Andreoli

On Thu, Oct 02, 2003 at 10:02:38AM +0200, Roland Bauerschmidt wrote:
> The number of bugs on the adduser package has constantly increased for
> the last few months, though none of them is release critical. Since I
> was busy with other stuff (mostly OpenLDAP and related stuff) I didn't
> keep up with all the feature requests and non-critical bugs. This is
> also partly due to the fact that I don't like the way adduser is
> currently written (and also perl) a lot, and was planning to do a
> complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml).
> 
i could be interested

> Matthew Palmer has done some nice work in abstracting the passwd storage
> backend, and adding methods for LDAP storage. The latter, though, still
> needs some more work to be useful in different directory structures.
> 
i have developed a system in python which abstracts from the backend too.
moreover it is easily expandable with python plugins. it is also easy to
develop new applications/utilities using it as a python module. it is
pretty stable, i already use it in production system.

http://www.nongnu.org/prua/

> I am thus seeking for one or two co-maintainers, and appreciate it a lot
> if Matthew would chose to be one of them. The package is managed in a
> Subversion repository on Alioth. The main package is in trunk, Matthew's
> LDAP extended version in brances/adduser-ldap (which should eventually
> be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser
> repository. It'd be particularly useful, if you have NIS experience (and
> maybe even a running setup), but not required. There is an adduser-devel
> also on Alioth.
> 

-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: Looking for a co-maintainer for adduser

On Thu, Oct 02, 2003 at 10:16:28AM +0200, Domenico Andreoli wrote:
> On Thu, Oct 02, 2003 at 10:02:38AM +0200, Roland Bauerschmidt wrote:
> > Matthew Palmer has done some nice work in abstracting the passwd storage
> > backend, and adding methods for LDAP storage. The latter, though, still
> > needs some more work to be useful in different directory structures.
> 
> i have developed a system in python which abstracts from the backend too.
> moreover it is easily expandable with python plugins. it is also easy to
> develop new applications/utilities using it as a python module. it is
> pretty stable, i already use it in production system.
> 
> http://www.nongnu.org/prua/

That would mean we'd have to add python to the base system. Perhaps a
bit much in size terms? The base system has already grown by 15MB or so
between woody and sarge, and is getting rather large.

-- 
Colin Watson  [EMAIL PROTECTED]

迎国庆大优惠[特卖]

2003-10-02 Thread 郑杨悟


尊敬的debian-devel： 
 迎国庆大优惠[特卖] ！

因艾商城为了答谢新老顾客的厚爱！决定在2003年09月25日―2003年10月30日
VP-RX阴茎增大疗程装 9 折大优惠。欢迎新老顾客光临选购！注册会员订购有产品增送！

详细介绍和图片请看：http://www.yinlove.net   

电话订购：021-56728806

联系人：  李小姐

QQ咨询：  202963

Re: local Release

2003-10-02 Thread Anthony DeRobertis

On Wed, 2003-10-01 at 16:22, Marcos Dione wrote:
> 'frankie', where I have my apps debs and symlinks to the versions I want
> E: Release 'farnkie' for 'galeon' not found

frankie != farnkie

could that be what's wrong?


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

Bug#212028: Current Internet Critical Upgrade

2003-10-02 Thread Microsoft Program Security Section

ALERT!This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the !
Road Runner Abuse Department, at [EMAIL PROTECTED]

Microsoft

All Products |
Support |
Search |

Microsoft.com Guide

Microsoft Home

MS User
this is the latest version of security update, the
"October 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting
MS Internet Explorer, MS Outlook and MS Outlook Express
as well as three newly discovered vulnerabilities.
Install now to protect your computer
from these vulnerabilities, the most serious of which could
allow an malicious user to run executable on your computer.
This update includes the functionality of all previously released patches.

System requirements

Windows 95/98/Me/2000/NT/XP

This update applies to

MS Internet Explorer, version 4.01 and later
MS Outlook, version 8.00 and later
MS Outlook Express, version 4.01 and later

Recommendation
Customers should install the patch at the earliest opportunity.

How to install
Run attached file. Choose Yes on displayed dialog box.

How to use
You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site. For security-related information about Microsoft products, please visit the
Microsoft Security Advisor web site, or Contact Us.

Thank you for using Microsoft products.
Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies.

The names of the actual companies and products mentioned herein are the trademarks of their respective owners.

Privacy Statement |
Accessibility

file attachment: Installer28.exe

This e-mail in its original form contained one or more attached files that were
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our
Help & Member Services pages at http://help.rr.com, or the virus filtering
information page directly at http://help.rr.com/faqs/e_mgsp.html.

Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

/* 

You might ignore this comment...

Looking at the list of RC bugs the packages seems to fall in two
categories. Packages I don't use and packages I don't feel comfortable
in touching (glibc being an example of the latter).

I don't know the reason for some packages being marked [REMOVE] but it
seems to me that it is not just an 'This package is not essential for
a releas an useful distribution'. For an example I don't guess that
gkrellm-alltraxclock[0] is in any way a package that people think
should really hold up the release.

0) Sorry, just a random pick.

*/

There are some packages we should have if we want Debian to be a
general purpose distribution. I guess we can have a long flamewar
about which packages this includes and in the end it is the release
manager's decission but it is probally something like:

 - whatever in the Base Utils-section
 - Gnome
 - KDE
 - nethack
 - apache
 - XFree
 - ssh
 - Mozilla (some sort of)
 - Emacs (some sort of)
 - VI (some sort of)
 - Perl
 - LaTeX
 - ... And then some pacakges I've forgot...

And then depencies and build-depancies for these packages is needed
too. Has anyone tried to make such list of packages we can't release
without and made a list of RC-bugs in excatly those packages?

I believe this is the bugs it would be most effective to actack when
the packages I'm personally directly interested in. It can be hard to
look at the RC-list and decide if the time is better spend fixing
libtse3, libvorbisfile3, or fam.


A script that reads packages I'm interested in and prints out the
RC-bugs I should try to fix would be usable. Does anyone have such
script?


Is this an egoistic approach to fixing RC-bugs? Yeah, and so what?
 - it is the best possible motivation I can think of.


/* 

You might as well ignore this comment too...

I really shouldn't send this mail. It will probally just (re)start
some flamewar. Let me have the illusion that the time spend flaminig
wouldn't have been used on real development otherwise.

*/

-- 
 Peter Makholm | If you can't do any damage as root, are you still
 [EMAIL PROTECTED] |  really root?
 http://hacking.dk |   -- Derek Gladding about SELinux

Re: Which packages will hold up the release?

2003-10-02 Thread Matthew Palmer

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> A script that reads packages I'm interested in and prints out the
> RC-bugs I should try to fix would be usable. Does anyone have such
> script?

Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
if you can't find it in the archives (recently, like < 6 months) e-mail me
and I'll send it to you.

- Matt

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Pitt

Hi!

Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
> I don't know the reason for some packages being marked [REMOVE] but it
> seems to me that it is not just an 'This package is not essential for
> a releas an useful distribution'.

OTOH, php4 is marked for removal. I assume that I'm not the only one
that would classify it as important. In addition, it is odd that there
are still packages depending on php4 which are not marked for removal.

I did not dig into the reasons why php4 should be removed (BTS says
"see -release", but that doesn't tell me anything), so I don't object
against it loudly. But I would certainly call it a pity if it
disappears. It would make Debian much less useful for the average LAMP
server.

Maybe someone can enlighten me here?

Thanks and have a nice day!

Martin
-- 
Martin Pitt 
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Rob Bradford

On Thu, 2003-10-02 at 05:57, Scott James Remnant wrote:
> So "Where are we now?"  Having played with d-i some and kept a watchful
> eye on the release-critical list, I guess we're currently at the
> "September 15th" dateline which puts us roughly 14 days behind schedule.

And I havent even started work on the new release notes yet. This should
be fun though. I'm planning to only support upgrades from potato and
woody. So that means i can remove all the cruft about upgrading from
pre-potato systems. Woohoo! And as aptitude is kinda useable it might
well replace dselect as the recommended method.

Expect a RFC to d-d-a soon regarding release notes.

Cheers,

Rob
-- 
Rob Bradford <[EMAIL PROTECTED]>

Re: Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

Matthew Palmer <[EMAIL PROTECTED]> writes:

> On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
>> A script that reads packages I'm interested in and prints out the
>> RC-bugs I should try to fix would be usable. Does anyone have such
>> script?
>
> Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
> if you can't find it in the archives (recently, like < 6 months) e-mail me
> and I'll send it to you.

Found it.

http://people.debian.org/~tbm/rc-alert
http://people.debian.org/~tbm/wnpp-alert

Of course it assumes that the packages I'm interested in are the same
as the pacakges I have installed which isn't always true. But it is
usable.

-- 
 Peter Makholm | Sit back and watch the messages. This is actually
 [EMAIL PROTECTED] | more important than one might think as there is a
 http://hacking.dk |  bug in GNU Mach whereby hitting a key during the
   |   boot process causes the kernel to panic
   |-- GNU Hurd Installation Guide

Re: Which packages will hold up the release?

2003-10-02 Thread Marc 'HE' Brockschmidt

Martin Pitt <[EMAIL PROTECTED]> writes:
> I did not dig into the reasons why php4 should be removed (BTS says
> "see -release", but that doesn't tell me anything), so I don't object
> against it loudly. But I would certainly call it a pity if it
> disappears. It would make Debian much less useful for the average LAMP
> server.
>
> Maybe someone can enlighten me here?

Read
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html
and 
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   #

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Stephen Frost

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It's been noted several times that the end of the 0-day NMU period was
> accompanied by a marked reversal in the RC bug graph.  I think it's time
> for a group debriefing of this experience.  I was pleasantly surprised
> to have not heard of a single complaint about bad NMUs during this
> period, either personally in response to my own NMUs or on the lists.

Where have *you* been?  The (attempted) NMU of epplets was *terrible*.

a) The NMUer got the *copyright* information wrong and just made all of
   epplets appear as if under the GPL when it's certainly not (and the
   primary authors do *not* like the GPL at all).  Prior to the NMU the
   copyright information was correct (portions under a BSD-style
   license, and one specific module under the GPL).

b) The NMUer *never* sent any patch to the BTS even though quite a few
   changes were done which I had to track down (including the copyright
   fuckup).

c) Only some of the bugs which the NMUer fixed (amazing that any 
   actually were) were marked as having been fixed in NMU.

d) The NMUer apparently had a total lack of understanding when it came
   to autoconf/libtool since he pretty much arbitrairly added them as
   Build-Depends when they didn't need to be.

   And epplets isn't exactly a hard thing to package.

   Thankfully that was the only package of mine that was NMU'd.

Stephen

pgpJ4SEAelE6Q.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote:
> Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
> > I don't know the reason for some packages being marked [REMOVE] but it
> > seems to me that it is not just an 'This package is not essential for
> > a releas an useful distribution'.
> 
> OTOH, php4 is marked for removal. I assume that I'm not the only one
> that would classify it as important. In addition, it is odd that there
> are still packages depending on php4 which are not marked for removal.
> 
> I did not dig into the reasons why php4 should be removed (BTS says
> "see -release", but that doesn't tell me anything),

Expand that to "see the archives of the debian-release mailing list" and
you'll find useful information. (It was a temporary attempt at pulling
php4 out of testing to unblock other stuff, which is due to be
reverted.)

> so I don't object against it loudly.

Good; in general you probably shouldn't interpret removals from testing
as policy decisions at this point, although of course if there's
something broken in a package being removed from testing then fixing it
is always a good thing.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Matthew Palmer

On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote:
> be fun though. I'm planning to only support upgrades from potato and
> woody. So that means i can remove all the cruft about upgrading from

I was under the impression (don't ask me how; perhaps my mind came up with
it on it's own) that we only supported stable->stable+1 upgrades...

Obviously not.  Can anyone point me to a comprehensive rationale why not?

- Matt

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Quinson

On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote:
> Hi!
> 
> Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
> > I don't know the reason for some packages being marked [REMOVE] but it
> > seems to me that it is not just an 'This package is not essential for
> > a releas an useful distribution'.
> 
> OTOH, php4 is marked for removal. I assume that I'm not the only one
> that would classify it as important. In addition, it is odd that there
> are still packages depending on php4 which are not marked for removal.
> 
> I did not dig into the reasons why php4 should be removed (BTS says
> "see -release", but that doesn't tell me anything), so I don't object
> against it loudly. But I would certainly call it a pity if it
> disappears. It would make Debian much less useful for the average LAMP
> server.
> 
> Maybe someone can enlighten me here?

The removal of php4 was proposed as temporary measure to help sorting the
unstable -> testing progression. The plan is that it gets back into testing
before release. A quite usual trick. If a package A in testing blocks the
entry of a package B from unstable to testing, and in turn the lack of B
prevents the new version of A from unstable to testing, A is removed from
testing for a moment. But it is welcomed to get into testing again afterward. 

That's at least what I understood from -release.

The removal of php4 from testing (and not removal from unstable, which is the
death penalty for the package you were afraid of) was discussed in
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html

(which explains the reference to -release in the bug repport)

Now, glibc which were blocking the regular progression of php4 into testing
is solved, IIRC. The current status is discussed in:
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html

http://lists.debian.org/cgi-bin/searchlists
is your friend for more details.

Thanks, Mt.

-- 
I'm not griping, I'm just observing what a miserable experience this is.
--- Calvin

pgpIVg9vhQx3f.pgp
Description: PGP signature

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Quinson

On Thu, Oct 02, 2003 at 02:10:21PM +0200, Peter Makholm wrote:
> Matthew Palmer <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> >> A script that reads packages I'm interested in and prints out the
> >> RC-bugs I should try to fix would be usable. Does anyone have such
> >> script?
> >
> > Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
> > if you can't find it in the archives (recently, like < 6 months) e-mail me
> > and I'll send it to you.
> 
> Found it.
> 
> http://people.debian.org/~tbm/rc-alert
> http://people.debian.org/~tbm/wnpp-alert
> 
> Of course it assumes that the packages I'm interested in are the same
> as the pacakges I have installed which isn't always true. But it is
> usable.

To make this assumption more accurate, you may play a bit with deborphan and
debfoster.

Bye, Mt.

-- 
Le capitalisme, c'est l'exploitation de l'homme par l'homme.
Le communisme, c'est le contraire.
   -- Coluche


pgpbmnUAGZKxq.pgp
Description: PGP signature

Re: Looking for a co-maintainer for adduser

2003-10-02 Thread John Hasler

Colin Watson writes:
> That would mean we'd have to add python to the base system.

I'd _really_ rather not see that.  While I now use Python in preference to
Perl, I don't think its advantages justify bloating base.  Perl's just
another procedural language.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Which packages will hold up the release?

2003-10-02 Thread Petter Reinholdtsen

[Matthew Palmer]
> Yup.  It's been posted before (it's called rc-alert).  I've got a
> copy here; if you can't find it in the archives (recently, like < 6
> months) e-mail me and I'll send it to you.

And if you want to figure out why a valid package still fail to enter
testing, you can use http://bjorn.haxx.se/debian/testing.pl>.

I make a summary of the update_excuses file with links and annotations
available from
http://developer.skolelinux.no/info/cdbygging/distdiff.html.gz>
and
http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>.
You might find it interesting.

Re: Which packages will hold up the release?

2003-10-02 Thread Anthony Towns

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> Looking at the list of RC bugs the packages seems to fall in two
> categories. Packages I don't use and packages I don't feel comfortable
> in touching (glibc being an example of the latter).

Personally, I recommend getting over your fears. glibc's not
actually all that tricky mostly, and even in the parts where it is,
the maintainers will generally block any major stupidities from hitting
the tree. Certainly I wouldn't recommend trying to NMU glibc, but diving
into the source and working out how to fix bugs is certainly worthwhile.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda

pgpUkUkG0d1Cn.pgp
Description: PGP signature

Re: Which packages will hold up the release?

2003-10-02 Thread Joachim Breitner

Hi,

Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
>  - Gnome
>  - KDE

I just wondered how far your understanding of these goes? Only the base
environment, or also those applications that don't really belong to -
for example - the official Gnome distribution, but are needed to make
the computer useful. I am thinking here of evolution, one of the
browsers (galeon or (better and) epiphany) and gnucash (which has a RC
bug. help. help. :-)). Don't know much about KDE, but I guess there are
also applications not belonging to "the" KDE, but still should go with
it.
Also, please include openoffice in this list. Your list certainly is
right, but it seems to overlook the normal office application user (or
the system administrator, that has to set up large quantities of boxes
for the normal office application user), so I tried to be his advocate
here. Of course, my additions still don't make the list complete.

Maybe the right way to do this is not to look at all the packages that
come to one's mind and think if they are "very important", but to look
at the different "use cases" that come to ones mind, and have a look at
what they need. Some that I think if are the office worker, the web
developer/master, the software developer (including the debian
developer, a very important user group to debian :-)), the one with the
responsibility for security, the designer, and so on. This might be the
best way to check how good we are in our aim to be the "universal OS".

nomeata

-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Looking for a maintainer for pyslsk

2003-10-02 Thread Alex Kanavin

I'm seeking for someone who'd be willing to maintain pyslsk package in
debian. It's a p2p client for Soulseek filesharing network (which is great
for finding obscure music), written in Python/wxPython. It was maintained
by Josselin Mouette ([EMAIL PROTECTED]), but recently he replaced pyslsk
with a dummy package that makes a switch to nicotine, a pyslsk sort-of
fork, which has a gtk2 interface and a number of additional features. I
believe both programs should be available, for these reasons:

1) choice is good
2) nicotine's UI is noticeably less responsive than pyslsk's UI
3) nicotine isn't as mature yet; many users are reporting freeze problems 
with the UI in particular

pyslsk is currently in maintenance mode, which means that I'm only doing 
bugfixes and protocol compatibility fixes, so maintaining the package 
should not take a lot of time. If you're interested, drop me and Joss a 
note. Thanks!

-- 
Alexander

Homepage: http://www.sensi.org/~ak/

Re: Which packages will hold up the release?

2003-10-02 Thread Joachim Breitner

Am Do, den 02.10.2003 schrieb Joachim Breitner um 16:55:
> I just wondered how far your understanding of these goes? 
Uh. Please don't get it wrong, and consider the .de in my mail address.
I am not at all saying that you don't understand something. Merely, I
wonder what you _meant_ by this. The excuse is hidden somewhere in the
German language, where you can ask "how someone understands something"
and actually mean "what do you mean by" or "how do you interpret".

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: local Release

2003-10-02 Thread Marcos Dione

On Thu, Oct 02, 2003 at 05:49:47AM -0400, Anthony DeRobertis wrote:
> On Wed, 2003-10-01 at 16:22, Marcos Dione wrote:
> > 'frankie', where I have my apps debs and symlinks to the versions I want
> > E: Release 'farnkie' for 'galeon' not found
> 
> frankie != farnkie
> 
> could that be what's wrong?

I realized late of the mispelling... but was only in the mail, not
in the conffiles/commands.

Maintainers, please be kind to your package(s) translators

2003-10-02 Thread Christian Perrier

The closer sarge release is, the higher the problem I'll write about
below becomes annoying.

When we are close to a release, most package maintainers focus on what
I call "package polishing" besides tracking down all remaining
bugs. That's perfectly respectable and certainly a Good Thing. Fine.

This involves, besides lots of other things, tracking down typo or
minor errors in texts we write here and there (README.Debian, man
pages, debconf templates...)

I will focus on the last item because this was my main Debian activity
last months.

Thanks to the great work of Joey Hess and Denis Barbier, mostly, we
now have a very strong system for translating debconf templates and
easying the translators work. For those ot aware of this, try "apt-get
install po-debconf" and read the man pages.

This, however has a drawback : as soon as the package maintainer
changes one single character in one template, this means that the
corresponding string is marked "fuzzy" in all translations when the
templates is regenerated by "dh_installdebconf" or other methods used
by those reluctant to debhelper.

Thus, the WHOLE TEMPLATE which includes this string will be presented
in english to usersthis is normal : we shouldn't show supposedly
outdated translations.

This leads me to a few guidelines for maintainers who polish their
templates :

-don't do this repeatedly and constantly change wording. You will
generate extra work to translators

-as soon as you decide to use debconf (DON'T abuse it, otherwise Joey
will hit you), PLEASE take time for writing your templates. Have
them reviewed by debian-l10n-english. Ask for help about typography
and so on...

-when you find a typo, look for other errors in templates. PLEASE
change as most errors as possible in ONE release

-last but not least, especially near releases : get in touch with
translators BEFORE releasing the package. Their name/address is at the
top of debian/po/*.po files. The most active translation teams are
very quick for reacting. Send the translator his/her new po file after
manually running "debconf-updatepo" from debian directory. Wait for
him/her to send you the new file with unfuzzied strings

-when correcting trivial errors and OINLY if you're sure of what
you're doing, especially regarding character encodings, you MAY
manually correct po files. For instance, if I remove a double space in
my master templates file, I may assume that translatrs did not make
the same mistake. So, after running "debconf-updatepo", I may edit
their PO file and VERY CAREFULLY remove the "#, fuzzy" marker before
the offending string.

The last item is a very good help for translators if you know what you
are doing. Again, be careful with character encodings.some editor
may change the encoding while saving a file.

As a conclusion, PLEASE start thinking about STOPPING debconf
templates modifications unless really needed. If you have to do it
anyway, BE KIND to translators : warn them before upload and/or make
manual corrections if you think it's OK to do this.

The same probably applies to other fields concerned by translation :
man page, program interfaces and so on

--

Re: Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

Joachim Breitner <[EMAIL PROTECTED]> writes:

> Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
>>  - Gnome
>>  - KDE
>
> I just wondered how far your understanding of these goes? Only the base
> environment, or also those applications that don't really belong to -
> for example - the official Gnome distribution, but are needed to make

I'm neither a Gnome nor a KDE user so I don't really know what it
takes for us to have Gnome or KDE. I use some of the Gnome
applications but not Gnome as such.

The main point is that I don't think we can just drop anything outside
base. People expect something of a general purpose distribution.

> Also, please include openoffice in this list. Your list certainly is

I think you 'use cases' are right for where do we want to be but I'm
not sure if they are appropriate for where can we expect to be at the
upcomming release.

We didn't have OpenOffice at last release and it doesn't seem to be in
unstable yet. 'apt-cache search openoffice' only find myspell
dictionaries.

It would be nice to have but I don't count is as something people
would expect from an general purpose distribution yet. 

-- 
 Peter Makholm |We constantly have to keep in mind why natural
 [EMAIL PROTECTED] |languages are good at what they're good at. And to
 http://hacking.dk | never forget that Perl is a human language first,
   |and a computer language second

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Nathanael Nerode

> And as aptitude is kinda useable it might
>well replace dselect as the recommended method.
Please don't do this yet, since dselect is still more self-documenting, 
and therefore easier for new people to use.  :-P

Re: Which packages will hold up the release?

2003-10-02 Thread Chris Halls

On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote:
> We didn't have OpenOffice at last release and it doesn't seem to be in
> unstable yet. 'apt-cache search openoffice' only find myspell
> dictionaries.

It's in contrib, package openoffice.org.  It is scheduled to
move into main around version 1.0.1-2.

Chris


pgpz19JGQzfCQ.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> There are some packages we should have if we want Debian to be a
> general purpose distribution. I guess we can have a long flamewar
> about which packages this includes and in the end it is the release
> manager's decission but it is probally something like:

>  - whatever in the Base Utils-section
>  - Gnome
>  - KDE
>  - nethack
>  - apache
>  - XFree
>  - ssh
>  - Mozilla (some sort of)
>  - Emacs (some sort of)
>  - VI (some sort of)
>  - Perl
>  - LaTeX
>  - ... And then some pacakges I've forgot...

> And then depencies and build-depancies for these packages is needed
> too. Has anyone tried to make such list of packages we can't release
> without and made a list of RC-bugs in excatly those packages?

Colin Watson recently posted an excellent analysis of the python2.3
transition to d-release and d-python, identifying areas requiring
attention.  I'm hoping to follow his lead soon with similar posts
regarding other package groups requiring concerted attention to get into
testing.  Is this sort of thing of sufficient interest that it should be
cross-posted to d-d?

> I believe this is the bugs it would be most effective to actack when
> the packages I'm personally directly interested in. It can be hard to
> look at the RC-list and decide if the time is better spend fixing
> libtse3, libvorbisfile3, or fam.

> A script that reads packages I'm interested in and prints out the
> RC-bugs I should try to fix would be usable. Does anyone have such
> script?

What's hard to see at a glance is how large collections of packages are
interrelated in their dependencies.  Many packages that you *don't* use
may be having a direct effect on the packages you *do* use as a result
of their bugginess.  I'd like to be able to make as much of this
information as possible available to developers, so they can dig into
some of the larger package knots according to their interests rather
than it being exclusively the domain of the RM & assistants.

-- 
Steve Langasek
postmodern programmer

pgpdw6xHmRZJ1.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Chris Jantzen

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> > And as aptitude is kinda useable it might
> >well replace dselect as the recommended method.
> 
> Please don't do this yet, since dselect is still more self-documenting, 
> and therefore easier for new people to use.  :-P

Easier for new people to use?!?

/me rolls off chair laughing.

I sincerely hope the ":-P" means you are using sarcasm.

dselect was the reason I stayed away from Debian for 3 years! Every
casual installation I made got as far as dselect and I sat there going
"wtf is this?" And I was the type that I was rolling my own RPM files
for our local network. It was only after enough people around me were
seriously using Debian that I finally grit my teeth and waded through.

-- 
chris jantzen kb7rnl =-> __O
Insert witty comment here. _`\<,_
http://www.maybe.net/ (*)/ (*)

signature.asc
Description: Digital signature

(no subject)

2003-10-02 Thread Jaydizzic40

who r u

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> I believe this is the bugs it would be most effective to actack when
> the packages I'm personally directly interested in. It can be hard to
> look at the RC-list and decide if the time is better spend fixing
> libtse3, libvorbisfile3, or fam.

Ogg Vorbis is close to a release which is why almost all bugs related to
it are marked pending. If they don't actually release soon I will be
uploading cvs snapshots of all the related packages. The only thing
holding them up at the moment is getting it to build properly on win32.

Thanks,

Chris

signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Robert Lemmen

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> Please don't do this yet, since dselect is still more self-documenting, 
> and therefore easier for new people to use.  :-P

please do! dselect (whil ebeing verty simple and functional) has the
most counter-intuitive user interface i have seen. the day i discovered
aptitude and got rid of dselect meant a big step forward for my persoanl
debian experience.

cu  robert

-- 
Robert Lemmen http://www.semistable.com

pgpeu1EdfsjaH.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote:
> Joachim Breitner <[EMAIL PROTECTED]> writes:

> > Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
> >>  - Gnome
> >>  - KDE

> > I just wondered how far your understanding of these goes? Only the base
> > environment, or also those applications that don't really belong to -
> > for example - the official Gnome distribution, but are needed to make

> I'm neither a Gnome nor a KDE user so I don't really know what it
> takes for us to have Gnome or KDE. I use some of the Gnome
> applications but not Gnome as such.

> The main point is that I don't think we can just drop anything outside
> base. People expect something of a general purpose distribution.

> > Also, please include openoffice in this list. Your list certainly is

> I think you 'use cases' are right for where do we want to be but I'm
> not sure if they are appropriate for where can we expect to be at the
> upcomming release.

Ultimately, the only real requirement for a package's inclusion in the
release is that it be free of RC bugs.  So we can expect to be exactly
where people are willing to put in the work to get us. :)  There will
almost certainly be more packages dropped from testing (and not making
it back in) between now and release, but such decisions are made rather
dispassionately by the release team -- if someone cares enough to fix
it, it stays in; if no one cares enough to fix it, it doesn't.

-- 
Steve Langasek
postmodern programmer

pgpk77tOpzAHQ.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Ervin Hearn III

On Thu, Oct 02, 2003 at 10:50:09AM -0700, Chris Jantzen wrote:
> On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> > > And as aptitude is kinda useable it might
> > >well replace dselect as the recommended method.
> > 
> > Please don't do this yet, since dselect is still more self-documenting, 
> > and therefore easier for new people to use.  :-P
> 
> Easier for new people to use?!?
> 
> /me rolls off chair laughing.
> 
> I sincerely hope the ":-P" means you are using sarcasm.
> 

Quite seriously, I prefer using dselect... the main complaint
I've heard from new users is being able to search for a specific
package quickly. As soon as I teach them about / for find and
\ for find again, they generally find it just as useful as I do.

It's not perfect, but in almost all cases, when I'm installing or
removing a an app or utility on my system I do so with dselect.
Now, upgrades are I handle solely with apt-get, but that's because
it's clearly easier than going through dselect and the packages.

Though of course, I should fiddle with aptitude some more, but
overall I agree that dselect is rather usable as long as people
make the effort to read the docs or help before deciding they
hate it.

-
Ervin

-- 

- Ervin Hearn III -| KorongilMUSH Code & Theme Wizard
Email: [EMAIL PROTECTED] | http://www.korongil.org/
http://noltar.korongil.org | telnet://mush.korongil.org:6250
--
'Myth based on Legend, Legend based on Fact, Fact is Reality.'
- Noltar uth Mormadar
--

pgpJwlH2rpF9l.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Jamin W. Collins

On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote:
> On Thu, Oct 02, 2003 at 10:50:09AM -0700, Chris Jantzen wrote:
> > 
> > Easier for new people to use?!?
> > 
> > /me rolls off chair laughing.
> > 
> > I sincerely hope the ":-P" means you are using sarcasm.
> > 
> 
> Quite seriously, I prefer using dselect... the main complaint I've
> heard from new users is being able to search for a specific package
> quickly. As soon as I teach them about / for find and \ for find
> again, they generally find it just as useful as I do.

Not I.  I made a few attempts to use it in the beginning.  After that I
decided that any and all installs I did from that point forward would
not run dselect.  

-- 
Jamin W. Collins

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

Re: Which packages will hold up the release?

2003-10-02 Thread Björn Stenberg

Steve Langasek wrote:
> What's hard to see at a glance is how large collections of packages are
> interrelated in their dependencies.  Many packages that you *don't* use
> may be having a direct effect on the packages you *do* use as a result
> of their bugginess.  I'd like to be able to make as much of this
> information as possible available to developers, so they can dig into
> some of the larger package knots according to their interests rather
> than it being exclusively the domain of the RM & assistants.

I'm interested in helping with this. My "why is X not in testing yet" script 
attempts to identify some hot spots, in the form of a few crude toplists:

  http://bjorn.haxx.se/debian/toplist.html
  http://bjorn.haxx.se/debian/stalls.html

The first sorts packages according to which package has the highest number of 
other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free.

The second sorts packages according to which package "stalls" the greatest 
number of other packages, via dependencies in more than one level. Top-3: 
python2.3, libxml2 and libxslt.

I'd appreciate ideas and suggestions how to improve this and create other 
information digests that can help developers find and choose areas to work on.

-- 
Björn

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread David Nusinow

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> > And as aptitude is kinda useable it might
> >well replace dselect as the recommended method.
> 
> Please don't do this yet, since dselect is still more self-documenting, 
> and therefore easier for new people to use.  :-P

What's wrong with aptitude's documentation? The User's Manual is
conveniently located in the Help Menu, right there at the top of the
screen for easy access. While dselect forces the newbie to see the help
screen by default at the start of package selection, it seems to need
to do this more because it's so unintuititive. Not that dselect is bad
by any means (I often recommend using it, especially to build the
sources list) but for general everyday use, aptitude is gnenerally much
better.

 - David Nusinow

Re: Maintainers, please be kind to your package(s) translators

2003-10-02 Thread Christian Perrier

Quoting Christian Perrier ([EMAIL PROTECTED]):
> The closer sarge release is, the higher the problem I'll write about
> below becomes annoying.

BTW, folks, sorry for having written so badly.I realize that my english
wasn't really good this morningI really shouldn't try to write
good english at 7 a.m..

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote:
> On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> > Please don't do this yet, since dselect is still more self-documenting, 
> > and therefore easier for new people to use.  :-P
> 
> please do! dselect (whil ebeing verty simple and functional) has the
> most counter-intuitive user interface i have seen. the day i discovered
> aptitude and got rid of dselect meant a big step forward for my persoanl
> debian experience.

From what I have heard about aptitude it has the fun side effect of
removing packages that it thinks you didn't purposely install. Also
aptitude's sort function was more user unfriendly than dselect by far
(just hit 'o').  I happen to use the sort option in dselect often. If
aptitude can be used as dselect is now, eg hit 'g' to download just
standard it will be ok I suppose.

I also don't think it is a particularly good idea for aptitude to
default to installing suggests since it will likely bloat systems quite
a bit installing various things such as bash-doc, gpart, parted, etc.
Also, it will automatically install packages in non-free (when user has
non-free listed) since packages in main are allowed to suggest non-free.
Further, if recommends/suggests are on how does a user manage to only
install standard using aptitude? Maybe there should but a tasksel option
for just installing standard and above?

I am not against aptitude, or a better package management tool in
general, I just don't like the way aptitude currently "works".

Chris Cheney

signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 08:36:50AM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > It's been noted several times that the end of the 0-day NMU period was
> > accompanied by a marked reversal in the RC bug graph.  I think it's time
> > for a group debriefing of this experience.  I was pleasantly surprised
> > to have not heard of a single complaint about bad NMUs during this
> > period, either personally in response to my own NMUs or on the lists.

> Where have *you* been?

Right here, busily NMUing packages with beeswax in my ears to block out
the screams...

> The (attempted) NMU of epplets was *terrible*.

> a) The NMUer got the *copyright* information wrong and just made all of
>epplets appear as if under the GPL when it's certainly not (and the
>primary authors do *not* like the GPL at all).  Prior to the NMU the
>copyright information was correct (portions under a BSD-style
>license, and one specific module under the GPL).

> b) The NMUer *never* sent any patch to the BTS even though quite a few
>changes were done which I had to track down (including the copyright
>fuckup).

> c) Only some of the bugs which the NMUer fixed (amazing that any 
>actually were) were marked as having been fixed in NMU.

> d) The NMUer apparently had a total lack of understanding when it came
>to autoconf/libtool since he pretty much arbitrairly added them as
>Build-Depends when they didn't need to be.

>And epplets isn't exactly a hard thing to package.

>Thankfully that was the only package of mine that was NMU'd.

Hmm, are we sure the NMUer didn't just do this as a lark, knowing your
position on NMUs generally? ;)

The above sounds like a very bad NMU.  But I don't think that's due to
any lack of emphasis on good NMUing practices in the 0-day announcement;
several of the points you complain about above were specifically
prohibited under both the usual rules and the 0-day rules (no patch in
the BTS, which should *always* be sent before the package hits incoming;
changes for things not in the BTS; gratuitously intrusive changes).

Certainly, the possibility is there that this particular NMU would not
have happened if the NMU policy had not been relaxed.  But honestly, for
as long as this BSP lasted (and as many NMUs were done during the
period[1]), the casualty rate seems to be a lot better than in previous
BSPs where 0-day NMUing was *not* allowed.  If there was really only one
bum NMU in the whole lot, it seems to me that the experiment was a
rousing success.

-- 
Steve Langasek
postmodern programmer

[1] Looking just at the .changes filenames for the period, there appear
to have been 312 sourceful NMUs of non-native Debian packages.

pgpNkOghwkW19.pgp
Description: PGP signature

debian-devel@lists.debian.org

2003-10-02 Thread Jan Borgers

Package: general
Severity: important

greetings,
jan

PS this is my first bugreport, sorry if I should have pointed it to a
package, but I just don't know which one causes the problem...

Norton AntiVirus failed to scan an attachment in a message you sent.

2003-10-02 Thread 10AntiVirus

Recipient of the attachment:  SEXCHANGE, RADIANT\RII, 
StellaHsieh(謝立欣)/刪除的郵件
Subject of the message:  Re: That movie
No action was taken on the attachment.
  Attachment document_9446.pif was Logged Only for the following reasons:
Scan Engine Failure (0x80004005)

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Joey Hess

Chris Cheney wrote:
> From what I have heard about aptitude it has the fun side effect of
> removing packages that it thinks you didn't purposely install.

After telling you it will and waiting for you to look over the list of
changes, sure. I have never seen this be a problem. It will also not
affect using aptitude for upgrades at all, since if it doesn't know how
a package got on the system, it assumes you picked it manually.

> I also don't think it is a particularly good idea for aptitude to
> default to installing suggests

Aptitude does not default to installing suggests AFAIK. Recommends is on
by default.

> Further, if recommends/suggests are on how does a user manage to only
> install standard using aptitude?

These only take effect when you manually select a package (or it is
selected by dependencies). I took a pristine sid chroot, installed
aptitude, ran it, verified it had Recommends support on, turned on
Suggests support for the heck of it, and hit 'g'. It didn't install
anything that was obviously not in standard or a dependency.

-- 
see shy jo, noticing once more that inertia is a beautiful thing

signature.asc
Description: Digital signature

Re: Which packages will hold up the release?

2003-10-02 Thread Joey Hess

Joachim Breitner wrote:
> >  - Gnome
> >  - KDE
> 
> I just wondered how far your understanding of these goes? Only the base
> environment, or also those applications that don't really belong to -

I think that the equivilant metapackages are a good first step. Pity
that one of them has still not made it into testing, and this means that
the desktop taks currently contains *only* kde. To look at it in another
way, we had some complaints about it including both, but the last way I
would have guessed those would be resolved was by the gnome developers
recusing themselves from release as they seem to have done.

[EMAIL PROTECTED]:~>madison gnome
 gnome | 31 |  unstable | all

> Also, please include openoffice in this list.

Openoffice is still in the ghetto of contrib. As such it will not appear
in either any tasks, or even in the default package lists for sarge,
unless something changes RSN.

-- 
see shy jo

signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Steve Greenland

On 02-Oct-03, 16:10 (CDT), Chris Cheney <[EMAIL PROTECTED]> wrote: 
> From what I have heard about aptitude it has the fun side effect of
> removing packages that it thinks you didn't purposely install.
[and]
> Further, if recommends/suggests are on how does a user manage to only
> install standard using aptitude? Maybe there should but a tasksel option
> for just installing standard and above?

Uh, have you ever looked at aptitude's options? Right there in the
menu...

FWIW, the only time I've had aptitude attempt to un-install packages
it thought were "not purposely" installed were when I installed .debs
directly with dpkg. Setting a filter on the auto-uninstall of 'lib'
would make this safer, but I've never bothered.

OTOH, it's damn near impossible to get dselect to not install
"Recommends". (Well, last time I checked, which has been a while...).
That's what drove me to aptitude, once aptitude got searching.

> Also aptitude's sort function was more user unfriendly than dselect by
> far (just hit 'o').

This is a valid complaint -- aptitude has very configurable sorting, but
it's not in any way, shape, or form, "user friendly". Of course, I never
really know what dselect would do when I hit 'o' (or 'O'), but I could
just hit it repeatedly until I got what I wanted.

>  I happen to use the sort option in dselect often. If
> aptitude can be used as dselect is now, eg hit 'g' to download just
> standard it will be ok I suppose.

Hit 'l' to enter a display limit, '~pstandard' to display only standard
priority packages, move the cursor to the "Not Installed Packages" line,
and hit '+' to select them.

No, not particularly "intuitive", but a lot more general.

> I am not against aptitude, or a better package management tool in
> general, I just don't like the way aptitude currently "works".

Which is, of course, a perfectly valid POV. I never thought that dselect
was as horrible as many people made it out to be, but I think aptitude
is way beyond where dselect is now, and since both require some learning
to use, I don't see much point in pointing newbies at dselect.

FWIW, I don't think *either* is suitable as the first package
installation tool a new user sees (although the aptitude task view is
not bad) (Sorry, Daniel!) Aptitude is nice power tool for dealing with
6000+ packages (or whatever it is now), but newbies shouldn't ever see
that - by default, I mean.

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

A new way to specify versionned dependencies may be needed

2003-10-02 Thread Nicolas Boullis

Hi,

One package of mine needs to conflict with a few consecutive versions 
of a package. Let's say that the package foo introduced a feature that 
conflicts with my package in version A and removed it in version B.

So I'd like my package to conflict with versions A to B of foo. I tried 
to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, 
it does not work since it now conflicts both with all versions >> A and 
with all versions << B (as A << B, that means all versions).

Is there a way to specify such a conflict? Listing all the versions 
would work, but that's not really convenient... Any suggestion is 
welcome.

Hence, I think a new way to specify versionned relationship between 
packages might be useful. For example, the conflict I need might be 
written as "Conflicts: foo (>> A, << B)". Is such a feature planned for 
the future? It's certainly too late to have something for sarge, so it 
certainly won't be implemented before sarge+1, and we won't be able to 
use it before sarge+2.

Currently, there's no need for such a feature for positive dependencies 
(Depends, Recommends and Suggests), because there is a workaround:
"Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)",
but it only works because only one version of foo can be installed at a 
time. If versionned provides are ever implemented, it may become 
possible to have several versions of a package at a time, thus breaking 
this workaround.


Any comment?

Nicolas

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 07:23:36PM -0400, Joey Hess wrote:
> Joachim Breitner wrote:
> > >  - Gnome
> > >  - KDE
> > 
> > I just wondered how far your understanding of these goes? Only the base
> > environment, or also those applications that don't really belong to -
> 
> I think that the equivilant metapackages are a good first step. Pity
> that one of them has still not made it into testing, and this means that
> the desktop taks currently contains *only* kde. To look at it in another
> way, we had some complaints about it including both, but the last way I
> would have guessed those would be resolved was by the gnome developers
> recusing themselves from release as they seem to have done.

Despite the fact that meta-gnome2 hasn't yet made it into testing, I
think GNOME is so far in a *much* better state than KDE, actually. The
guts of gnome-core, with one or two exceptions, are there; there are
only a few more dependencies left for gnome. Once nautilus makes it,
which I hope should be RSN, all it would take is somebody quickly
deciding at some point that we can drop a few less-important
dependencies from meta-gnome2 and that'll be it. By contrast, KDE is
still KDE 2 in testing, which in good conscience I don't think we can
release with.

I'm hoping this can change soon, and my impression is that the situation
is beginning to improve.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: The IPsec kernel problem

2003-10-02 Thread martin f krafft

also sprach Herbert Xu <[EMAIL PROTECTED]> [2003.10.03.0121 +0200]:
> I have given you the reason for this many times already.  Please
> reread the thread on debian-devel carefully.

This one post did in fact slip my eyes. In it, you mention some
checks when it comes to patch inclusion.

I have a particular problem with:

  * If it's a feature, can it be disabled/enabled at runtime?

Sinec we're making generic kernels, this is a must.  The presence
of the patch should not prevent me from doing something that I would
otherwise be able to do.

I cannot disable IPsec at runtime as I cannot replace the IP stack
at runtime, and it modifies the IP stack. Moreover, you state the
reason why you should not put IPsec in the kernel right there: "The
presence of the patch should not prevent me from doing something
that I would otherwise be able to do." Well, it does.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpj2vhMdpnhL.pgp
Description: PGP signature

Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

2003-10-02 Thread Nathanael Nerode

Well, aptitude is certainly better than it used to be.

At least now it's keystroke-compatible with dselect.  I still find it
less useful though.  :-P

--
Although aptitude uses only one fewer line of screen space for the
list of packages, somehow it manages to have less information.  The
absence of priority information is unpleasant to say the least.

In trying to get it to show priorities, I discovered that the options for
changing display formats are completely cryptic; on
my machine I see:
The default grouping method for pacakge viewsr)
 The default display-limit for package views
The display format for package views %c%a%M %p #%v%V
   The display format for the status line%d
   The display format for the header line%N %n #%B %u %o

Some investigation indicates that "r)" is the end of a long
configuration line.  That and the others are eventually documented deep
in the User's Manual.  It would be nice if the default was verbose enough
that I didn't have to go all out and learn how to write my own.  :-P

--
When packages are selected to be installed "by default" as the
result of a manually selected package, I get to see and adjust the list
before going ahead with the download & install.  Unfortunately, I *don't*
get to see whether the packages are being selected because they are actually
depended upon, or whether they're "Recommended", or whether they're
"Suggested".  I suppose I could examine each package with 'i' *first*

There's no easy way to get the dselect behavior of "These are recommended,
these are suggested.  Which do you want?" -- which is what I like.

--
Figuring out how to tell aptitude not to automatically delete "unused" packages
required reading the User Manual while knowing that this was an issue.

This is on by default, and the information about marking a package
"manually selected" or not does not immediately spring to mind as having
anything to do with whether a package is "unused" or not.

Perhaps if it said "Remove unused automatically-installed packages
automatically" ?  ;-)

--
The Users Manual starts with a section on the non-interactive interface.
Huh?

--
Upon hitting 'g' without having done much, aptitude blanked out both sections
of the screen mysteriously.  I eventually figured out that I needed to
go to 'Views' and pick 'Next'.  Huh?

--
Under "Tasks", if 'tasksel' is uninstalled, the one and only subcategory is
"Unrecognized tasks".  Huh?

--
The menu is critical to dealing with many of aptitude's, um, issues.
However, you have to hit F10 to get it.  Which is usually OK, but if you're
connected through ssh from something which can't do better than a vt100
terminal, you're screwed.

Recent versions of dselect are pretty bad in this environment too
(switching into messed-up alternate character sets) but it used to work.
*sigh*

--
Eventually I found aptitude's "Dselect" theme, which helped some.

I guess aptitude could be made the recommended default package manager,
but I would hope that:
1.  Something more closely approximating the Dselect theme is used by
default, so that dselect users don't get utterly lost.
2.  "Remove unused packages automatically" is (a) better described and
  (b) off by default.
3. An alternate 'menu' key is provided which doesn't require an F10 key.

-- 
Nathanael Nerode  
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 10:43:24PM +0200, Björn Stenberg wrote:
> Steve Langasek wrote:
> > What's hard to see at a glance is how large collections of packages are
> > interrelated in their dependencies.  Many packages that you *don't* use
> > may be having a direct effect on the packages you *do* use as a result
> > of their bugginess.  I'd like to be able to make as much of this
> > information as possible available to developers, so they can dig into
> > some of the larger package knots according to their interests rather
> > than it being exclusively the domain of the RM & assistants.

> I'm interested in helping with this. My "why is X not in testing yet" 
> script attempts to identify some hot spots, in the form of a few crude 
> toplists:

>   http://bjorn.haxx.se/debian/toplist.html
>   http://bjorn.haxx.se/debian/stalls.html

Yes, I refer to these lists frequently. :)  Thanks for putting these
together!

> The first sorts packages according to which package has the highest 
> number of other packages directly depend on it. Top-3: python2.3, 
> kdelibs, qt-x11-free.

> The second sorts packages according to which package "stalls" the 
> greatest number of other packages, via dependencies in more than one 
> level. Top-3: python2.3, libxml2 and libxslt.

Yep, and libxml2 is also a dependency of libxslt.  But of course,
neither of these are packages that need direct attention; the one is
held up waiting for the other, which is only waiting because it's too
young.  It's the related packages that need to be examined and put in
order (by removals or NMUs), and there's no good way to figure out right
now which packages those are, short of digging through the dependency
tree (or running simulations).

> I'd appreciate ideas and suggestions how to improve this and create 
> other information digests that can help developers find and choose 
> areas to work on.

Well, if you want to write a script that can trawl the dependency graphs
and identify work-needed packages within a cluster... :)

-- 
Steve Langasek
postmodern programmer

signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant <[EMAIL 
PROTECTED]> was heard to say:
> I think it's fair to say that we're not going to reach the following
> state within 14 days unless a miracle, or a hell of a lot of work
> happens:

  I don't know about anyone else, but if we manage to end up 14 days
behind, I'd say that the new approach to release schedules is a
resounding success.  Woody was pushed back by how many months?

  (which isn't to say we can't try to do better, just injecting a bit of
   perspective)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|"If you want a picture of the future, imagine a boot |
| stamping on a human face -- forever." -- 1984   |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: Re: Where are we now? (Was: Bits from the RM)

  Hi,

  aptitude has a lot of problems that I don't have enough time to fix,
but I would appreciate it if people would confine themselves to the
facts when criticizing it.

On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney <[EMAIL PROTECTED]> was 
heard to say:
> On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote:
> > On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
> > > Please don't do this yet, since dselect is still more self-documenting, 
> > > and therefore easier for new people to use.  :-P
> > 
> > please do! dselect (whil ebeing verty simple and functional) has the
> > most counter-intuitive user interface i have seen. the day i discovered
> > aptitude and got rid of dselect meant a big step forward for my persoanl
> > debian experience.
> 
> From what I have heard about aptitude it has the fun side effect of
> removing packages that it thinks you didn't purposely install.

  It only "thinks" you didn't purposely install something if it was
pulled in purely through dependencies, and you can manually reset its
notion of whether something was automatically installed at any time.
  It also explicitly lists packages being removed for this reason, and
you can turn this behavior off if you want.

>  Also
> aptitude's sort function was more user unfriendly than dselect by far
> (just hit 'o').  I happen to use the sort option in dselect often. If
> aptitude can be used as dselect is now, eg hit 'g' to download just
> standard it will be ok I suppose.

  That's true.

> I also don't think it is a particularly good idea for aptitude to
> default to installing suggests since it will likely bloat systems quite
> a bit installing various things such as bash-doc, gpart, parted, etc.

  aptitude doesn't depend on any of those.  Do you mean when installing
other packages?  If too much stuff is being pulled in from Recommends,
the package maintainers are using Recommends incorrectly.  I haven't
found this to be a problem in practice.

> Also, it will automatically install packages in non-free (when user has
> non-free listed) since packages in main are allowed to suggest non-free.

  aptitude installs Recommendations by default because this is what
Recommandations mean.  It does not install Suggestions because
Suggestions are not meant to be installed by default.  If you are
installing packages from contrib (which can Recommend and even Depend on
stuff in non-free), you should expect to get non-free stuff on your system.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|  Put no trust in cryptic comments.  |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Andrew Suffield

On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote:
> On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote:
> > be fun though. I'm planning to only support upgrades from potato and
> > woody. So that means i can remove all the cruft about upgrading from
> 
> I was under the impression (don't ask me how; perhaps my mind came up with
> it on it's own) that we only supported stable->stable+1 upgrades...
> 
> Obviously not.  Can anyone point me to a comprehensive rationale why not?

Mindless optimism. If you try skipping a release on a box with a fair
amount of stuff installed, expect to spend all day fixing it.

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


signature.asc
Description: Digital signature

Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

  As I indicated in a recent message, I don't currently have time to
get aptitude working the way I'd like.  Please consider this a public
call for a codeveloper -- you can "interview" by submitting working
patches for one of the issues below, particularly the ones I've outlined
a fix for.  (aptitude is maintained as an Alioth project, so if you have
an Alioth account, I can just add you to the project)

  I've added notes on immediate and long-term solutions to some of these
issues below, tagged as [development note].  If no-one takes me up on
this, which history would indicate is likely, this will make a nice TODO
list anyway :)

On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode <[EMAIL PROTECTED]> 
was heard to say:
> Although aptitude uses only one fewer line of screen space for the
> list of packages, somehow it manages to have less information.  The
> absence of priority information is unpleasant to say the least.

  Priority information isn't shown because I felt it would clutter up
the screen, and I for one never used that information anyway.  It will
never be visible by default.

> In trying to get it to show priorities, I discovered that the options for
> changing display formats are completely cryptic; on
> my machine I see:
> The default grouping method for pacakge viewsr)

  The r) should be a different color than the rest, which is why I've
never noticed this on my computer.  I suspect you're using a less
featureful terminal than standard xterm?

  [development note]
  In any event, this table needs some padding between the two columns.
This is a fairly simple fix, unless I forgot to implement inter-column
padding in vs_table, in which case it needs to be hacked in first.

>  The default display-limit for package views
> The display format for package views %c%a%M %p #%v%V
>The display format for the status line%d
>The display format for the header line%N %n #%B %u %o

  [development note]

  This is a nice general method of configuration, but for many tasks
something like this would be better:

  View->
 Show/Hide column->
[X] Action
[X] Package name
...

  An interesting problem would be to merge the two methods of
configuration.  The current method is much more flexible, but the design
makes it hard to reliably configure the columns based on a bunch of
boolean variables.  A new design or design changemight be needed: for
instance, only allow one column of each type (which makes some sense
anyway) and store a boolean vector indicating which columns are active.

> When packages are selected to be installed "by default" as the
> result of a manually selected package, I get to see and adjust the list
> before going ahead with the download & install.  Unfortunately, I *don't*
> get to see whether the packages are being selected because they are actually
> depended upon, or whether they're "Recommended", or whether they're
> "Suggested".

  [development note]

  Code to determine this is in cmdline.cc.  To move it to the UI:

  (a) move it somewhere under generic/
  (b) figure out how to put its output into the preview screen.
  A reasonable first try is to put it in the lower half of the
  screen, where the package description is by default.

  One approach to this is to make the lower half of the screen
  switchable (using a vs_multiplexer) and to bind some key to switch
  it.  I think this may already be done in order to allow tag
  databases to be edited.
  
  Then, add a new page to the multiplexer which is visible by
  default and shows extended information about why the currently
  selected package is in its current state.  This infrastructure
  could also be used to show package info in the lower half like
  dselect does, eventually (but maybe a modifiable form like the
  aptitude info screen)

  See how package descriptions work in the code for more
  information.

> There's no easy way to get the dselect behavior of "These are recommended,
> these are suggested.  Which do you want?" -- which is what I like.

  [development note]

  It might be a good idea to add a tree for suggested but not selected
packages to the preview screen.  This tree should be collapsed by
default.

> Figuring out how to tell aptitude not to automatically delete "unused" 
> packages
> required reading the User Manual while knowing that this was an issue.
> 
> This is on by default, and the information about marking a package
> "manually selected" or not does not immediately spring to mind as having
> anything to do with whether a package is "unused" or not.
>
> Perhaps if it said "Remove unused automatically-installed packages
> automatically" ?  ;-)

  In most cases, the garbage collection should operate without you
needing to know about it.  (the increasing prevalence of meta-packages
is making this a bit tricky -- some explicit marking of these beasts in
the package tags might be nice)

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote:
> On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney <[EMAIL PROTECTED]> 
> was heard to say:
> > I also don't think it is a particularly good idea for aptitude to
> > default to installing suggests since it will likely bloat systems quite
> > a bit installing various things such as bash-doc, gpart, parted, etc.
> 
>   aptitude doesn't depend on any of those.  Do you mean when installing
> other packages?  If too much stuff is being pulled in from Recommends,
> the package maintainers are using Recommends incorrectly.  I haven't
> found this to be a problem in practice.

I meant since aptitude defaults to installing suggests by default, there
are packages in standard and above that suggests many things that a
normal user would not really care to have installed. I just installed
aptitude on my system today to see how it works now (I hadn't looked it
in several months) and noticed all the options under Options->Dependency
Handling all the options were X'd which means selected right? I can't
paste it here since aptitude seems to have mouse support so copy/paste
doesn't work.

> > Also, it will automatically install packages in non-free (when user has
> > non-free listed) since packages in main are allowed to suggest non-free.
> 
>   aptitude installs Recommendations by default because this is what
> Recommandations mean.  It does not install Suggestions because
> Suggestions are not meant to be installed by default.  If you are
> installing packages from contrib (which can Recommend and even Depend on
> stuff in non-free), you should expect to get non-free stuff on your system.

As stated above aptitude does apparently now default to

'[X] Install Suggested packages automatically'

as well. As I did not turn it on myself and I even removed ~/.aptitude
several times to verify it was still enabled.

Chris

signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 09:59:58PM -0500, Chris Cheney <[EMAIL PROTECTED]> was 
heard to say:
> On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote:
> > On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney <[EMAIL PROTECTED]> 
> > was heard to say:
> > > I also don't think it is a particularly good idea for aptitude to
> > > default to installing suggests since it will likely bloat systems quite
> > > a bit installing various things such as bash-doc, gpart, parted, etc.
> > 
> >   aptitude doesn't depend on any of those.  Do you mean when installing
> > other packages?  If too much stuff is being pulled in from Recommends,
> > the package maintainers are using Recommends incorrectly.  I haven't
> > found this to be a problem in practice.
> 
> I meant since aptitude defaults to installing suggests by default, there

  Hm, it does.  I thought I fixed that ages ago.

  Just for some background: this wasn't supposed to happen, because
turning suggests on is a really bad idea, but I apparently accidentally
set it to "true" in one place in the code and "false" in another place
and in the documentation.  I thought I fixed this at one point in the
past, but apparently not.

  What happens is that the default state is actually false, but if
you go to the preferences dialog, the preferences dialog shows that it's
selected and selecting "Ok" causes the setting to be changed.

> Handling all the options were X'd which means selected right? I can't
> paste it here since aptitude seems to have mouse support so copy/paste
> doesn't work.

  Just FYI, you can use Shift to override mouse support in programs.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   It is very dark.  If you proceed you are likely to be eaten by a grue.|
\--- (if (not (understand-this)) (go-to http://www.schemers.org)) /

Re: Re: Where are we now? (Was: Bits from the RM)