Re: Question about kill(1)

[Brian May]

> "Adeodato" == Adeodato Simó <[EMAIL PROTECTED]> writes:

Adeodato> I also have heard (but I'm not sure how often does this
Adeodato> happen, if at all) that it is usefult to have it as a
Adeodato> built-in when your system is in a state when it can't
Adeodato> create more processes.

In practise whenever that happens, and if I am lucky enough to have a
terminal open, and if I am not dumb enough to accidently close the
window, I don't know what the PID is of that CPU hungry/memory hungry
process is in order to kill it.

This happened to me approx a week ago. I wanted to write a wrapper
around subversion that set umask before calling subversion, but
instead the wrapper recursively called itself. I thought subversion
was just being slow. It never considered the possibility it was the
reason my computer subsequently went very slowly until it was
unusable. It took me two reboots of the computer before I finally
realized the DOS attack was from *my* own script! It took me another
reboot to fix the problem properly.

Sometimes it pays to use the full pathname to the executable...
-- 
Brian May <[EMAIL PROTECTED]>

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo David,

* David Pashley <[EMAIL PROTECTED]> [2005-07-09 12:02]:
> On Jul 09, 2005 at 01:14, Nico Golde praised the llamas by saying:
sn 
> beebo root% grep upgrade /var/log/dpkg.log | tail
> 2005-07-09 01:17:02 upgrade eog 2.10.0-0.2 2.10.2-0.1
> 2005-07-09 01:17:09 upgrade gaim 1:1.3.1-2 1:1.4.0-1
> 2005-07-09 01:17:10 upgrade gaim-data 1:1.3.1-2 1:1.4.0-1
> 2005-07-09 01:17:14 upgrade gcj 4:4.0.0-1 4:4.0.0-2
> 2005-07-09 01:17:15 upgrade gij 4:4.0.0-1 4:4.0.0-2
> 2005-07-09 01:17:19 upgrade libasound2 1.0.9-2 1.0.9-3
> 2005-07-09 01:17:19 upgrade libsensors3 1:2.9.1-3 1:2.9.1-4
> 2005-07-09 01:17:20 upgrade ucf 1.18 2.000
> 2005-07-09 01:17:23 upgrade libavc1394-0 0.5.0-2 0.5.1-1
> 2005-07-09 01:17:24 upgrade ssh 1:4.1p1-5 1:4.1p1-6
> 
> What else am I missing? Does apt-history hook into /etc/apt/apt.conf or
> just a wrapper around dpkg.log?

But for example:
apt-history show install
2005-07-09 00:12:03: install  libstdc++6-4.0-dev   4.0.0-12
2005-07-09 00:12:03: install  libaa1   1.4p5-28
2005-07-09 00:12:03: install  libstdc++6   4.0.0-12
2005-07-09 00:12:03: install  g++-4.0  4.0.0-12
2005-07-09 00:12:03: install  gcc-4.0  4.0.0-12
2005-07-09 00:12:03: install  cpp-4.0  4.0.0-12
2005-07-09 10:00:09: install  fireflies2.05-1
2005-07-09 10:00:09: install  aptitude 
0.2.15.9-3
2005-07-09 10:02:28: install  libgtop2-5   2.10.2-1
2005-07-09 10:03:13: install  apt-listchanges  2.59-0.2
[EMAIL PROTECTED]:/home/nion$ grep install /var/log/dpkg.log | tail
2005-07-09 12:02:20 install libgtop2-5  2.10.2-1
2005-07-09 12:02:20 status half-installed libgtop2-5 2.10.2-1
2005-07-09 12:02:26 status installed libgtop2-5 2.10.2-1
2005-07-09 12:02:28 status installed slmon 0.5.13-2
2005-07-09 12:03:07 install apt-listchanges 2.59-0.2 2.59-0.2
2005-07-09 12:03:07 status half-installed apt-listchanges 2.59-0.2
2005-07-09 12:03:12 status installed apt-listchanges 2.59-0.2
2005-07-09 12:04:00 status installed plotutils 2.4.1-12
2005-07-09 12:04:02 status half-installed plotutils 2.4.1-12
2005-07-09 12:04:02 status not-installed plotutils 

I think there is apt-history a better way.
No it isn't a wrapper around the dpkg.log it only uses /var/lib/dpkg/status
regards Nico


-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpWKGt80MkXU.pgp
Description: PGP signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hi,
* Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 12:02]:
> #include 
> * Nico Golde [Sat, Jul 09 2005, 02:14:22AM]:
> 
> > sudo apt-history show upgrade
> > 2005-07-09 00:12:03: upgrade  gstreamer0.8-alsa=0.8.8-3
> > 0.8.10-1
> > 2005-07-09 00:12:03: upgrade  libbonobo2-common=2.8.1-2
> > 2.10.0-1
> > 2005-07-09 00:12:03: upgrade  gnome-desktop-data=2.10.1-2  
> > 2.10.2-1
> > 2005-07-09 00:12:03: upgrade  libgimp2.0=2.2.7-1   
> > 2.2.8-2
> > 2005-07-09 00:12:03: upgrade  findutils=4.2.22-1   
> > 4.2.22-2
> > 2005-07-09 00:12:03: upgrade  e2fslibs=1.37+1.38-WIP-0620-1
> > 1.38-1
> > 2005-07-09 00:12:03: upgrade  dselect=1.13.9   
> > 1.13.10
> > 2005-07-09 00:12:03: upgrade  libgnome-keyring0=0.4.2-1
> > 0.4.3-1
> > 2005-07-09 00:12:03: upgrade  login=1:4.0.3-35 
> > 1:4.0.3-36
> > 2005-07-09 00:12:03: upgrade  zlib1g-dev=1:1.2.2-4 
> > 1:1.2.2-7
> > 2005-07-09 00:12:03: upgrade  libgcrypt11-dev=1.2.0-11.1   
> > 1.2.1-1
> > 2005-07-09 00:12:03: upgrade  telnet=0.17-29   
> > 0.17-30
> > 2005-07-09 00:12:03: upgrade  libqdbm-dev=1.8.30-1 
> > 1.8.30-2
> > 
> > I think it is a nice little tool to furbish the information so I think
> > it would be good to have this in the tool chain.
> > And please correct me if I missed something
> 
> If I understand you correctly, you are going to write a simple little
> logfile parser (few LOC perl code). 

No :)

> I would not create a separate
> package just for this purpose - better pass it over to apt maintainers.

Mhm maybe some others can test it and say what they like
better?
You can find a package on:
http://nion.modprobe.de/debian/apt-history/
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpWmtiBd95i6.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Brian May]

> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:

Santiago> Well, I consider the idea that old bugs deserve more
Santiago> attention than new bugs (or non-old bugs) completely
Santiago> flawed.

I wonder how many old bugs are either fixed (but not marked as fixed)
or irrelevant (if another solution was used).

I suspect that there would be a high percentage of such bugs.

Santiago> Bugs do not increase their severity by age. A wishlist
Santiago> bug which is ten years old is still a wishlist bug. A
Santiago> normal bug which is ten years old is still a normal
Santiago> bug. An important bug which is ten years old is still an
Santiago> important bug (well, modulo the fact that the important
Santiago> severity might not exist ten years ago :-).

True. However, I think it is easy to forget about old bugs and
concentrate only on the new.

After all who wants to spend considerable time gong over old bugs,
attempting to work out if they are still relevant, for situations that
you are never likely to encounter yourself, when you could be fixing
"real" problems (as in problems that effect you)?

Maybe the process of reviewing old bugs could be improved. I find the
current process very clumsy:

1. Review bugs in web browser.

2. Identify questionably bug that you haven't already looked at before
   today.

3. Inspect bug report, in new window, install package, install source,
   inspect as required. Open up new browser windows to find
   information as required.

4. Make changes as required to source code.

5. Enter one/more emails to either forward bug upstream, change tags,
   or close the bug.

6. Go back to step 3.

7. Fix up the all the silly typos made in every BTS email sent so far
   and retransmit. (note: this is after the BTS has decided to
   respond).

8. upload the changes to source code.

9. realize that I forgot to sign the upload due to a bug in by
   pbuilder wrapper script, create a *.commands file to send to the
   upload queue to delete the old upload and reupload again.

It would be good if this process could be simplified and/or made more
error resistant. For example:

1. Client program that lists all bugs and has the ability to mark
   bugs. Ability to sort bugs in order of when you last looked it one.
   This information should be stored on maintainers computer, not the
   BTS.

   Even better, if you could attach a short summary/note to each one
   for your use, e.g. "need to talk to XYZ about this", "this user is
   an idiot", "I think this has been solved but I need to check X
   first", or "as of 1/1/2005 this bug is still waiting on X" that
   you don't want to appear in the BTS. This should be immediately
   visibly without having to select the bug and scrolling to the
   bottom.

   This way you can get a clear picture of which bugs require
   immediate attention, and which bugs you consider "too-hard" or
   "too-time consuming" right now, or are waiting on other outside
   events.

2. Client program with provision for sending updates to the BTS, but
   caching the updates until they finally appear in the BTS. Either
   that or fast response time from the BTS.

3. Environment/scripts to enable better testing, updating, and
   recompiling packages even if it is based on a non-preferred
   distribution, e.g. if you use stable, but the bug report is against
   unstable or vice versa.

   pbuilder is good and building packages against other distributions,
   it is not so good (at the moment anyway) for testing arbitrary
   packages in arbitrary distributions (except via pre-written
   scripts), because it was designed for building not interactive
   testing. There is the "pbuilder login" operation, but it doesn't
   give you access to your newly created package.

4. Make dupload obsolete, and replace with dput. Make dput the default
   in debrelease. I think dput would have prevented me uploading my
   unsigned package.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: configure a program -- debconf abuse?

[Gustavo Noronha Silva]

Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > Keeping the question priority at 'low' make sure most users will not
> > see the question, and that only reconfigure will present it.  I hope
> > you are not setting the debconf priority limit to low. :)
> 
> If we recommend against setting the priority to low, why bother with it?

Enabling debconf pre-seeding for customized installs is a good enough
justification IMO.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: RFS: libssh - SSH and SCP library

[Gustavo Noronha Silva]

Hey,

Em Ter, 2005-07-05 às 10:37 +0900, Junichi Uekawa escreveu:
> --- libssh-0.11.orig/debian/shlibs.local
> +++ libssh-0.11/debian/shlibs.local
> @@ -0,0 +1 @@
> +liblibssh 0.11 libssh (>> 0.11-0), libssh (<< 0.11-99)

I don't get the << 0.11-99. Why would you add this?

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Eduard Bloch]

#include 
* Nico Golde [Sat, Jul 09 2005, 12:06:54PM]:

> But for example:
> apt-history show install
> 2005-07-09 00:12:03: install  libstdc++6-4.0-dev   
> 4.0.0-12
> 2005-07-09 00:12:03: install  libaa1   
> 1.4p5-28
> 2005-07-09 00:12:03: install  libstdc++6   
> 4.0.0-12
> 2005-07-09 00:12:03: install  g++-4.0  
> 4.0.0-12
> 2005-07-09 00:12:03: install  gcc-4.0  
> 4.0.0-12
> 2005-07-09 00:12:03: install  cpp-4.0  
> 4.0.0-12
> 2005-07-09 10:00:09: install  fireflies2.05-1
> 2005-07-09 10:00:09: install  aptitude 
> 0.2.15.9-3
> 2005-07-09 10:02:28: install  libgtop2-5   
> 2.10.2-1
> 2005-07-09 10:03:13: install  apt-listchanges  
> 2.59-0.2
> [EMAIL PROTECTED]:/home/nion$ grep install /var/log/dpkg.log | tail
> 2005-07-09 12:02:20 install libgtop2-5  2.10.2-1
> 2005-07-09 12:02:20 status half-installed libgtop2-5 2.10.2-1
> 2005-07-09 12:02:26 status installed libgtop2-5 2.10.2-1
> 2005-07-09 12:02:28 status installed slmon 0.5.13-2
> 2005-07-09 12:03:07 install apt-listchanges 2.59-0.2 2.59-0.2
> 2005-07-09 12:03:07 status half-installed apt-listchanges 2.59-0.2
> 2005-07-09 12:03:12 status installed apt-listchanges 2.59-0.2
> 2005-07-09 12:04:00 status installed plotutils 2.4.1-12
> 2005-07-09 12:04:02 status half-installed plotutils 2.4.1-12
> 2005-07-09 12:04:02 status not-installed plotutils 

Sounds like an arbitrary constructed example for me and the opposite (of
whatever you tried to demonstrate) can be prooved by using a correct
regexp, eg.

grep " install " /var/log/dpkg.log | tail

2005-07-04 20:43:33 install libslang2-dev  2.0.4-2
2005-07-04 23:51:22 install libneon25  0.25.1.dfsg-1
2005-07-06 19:52:33 install gcc-4.0  4.0.0-12
2005-07-06 19:52:34 install libstdc++6-4.0-dev  4.0.0-12
2005-07-06 19:52:35 install g++-4.0  4.0.0-12
2005-07-07 20:19:35 install python2.3-elementtree  1.2.6-3
2005-07-07 20:19:35 install bzr  0.0.5-2.1
2005-07-07 21:10:16 install scsi-idle  2.4.23-5
2005-07-08 20:57:42 install ethereal  0.10.11-1
2005-07-09 09:36:19 install libaa1  1.4p5-28

> I think there is apt-history a better way.

For doing what exactly?

> No it isn't a wrapper around the dpkg.log it only uses /var/lib/dpkg/status
> regards Nico

No, it is an overengineered solution which reads the whole dpkg database
for no real benefit.

Regards,
Eduard.
-- 
Teamwork ist, wenn fünf Leute für etwas bezahlt werden, was vier
billiger tun können, wenn sie nur zu dritt wären und zwei davon
verhindert.
-- Charles Saunders


signature.asc
Description: Digital signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo Eduard,

* Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 13:02]:
> #include 
> * Nico Golde [Sat, Jul 09 2005, 12:06:54PM]:

[...] 
> > I think there is apt-history a better way.
> 
> For doing what exactly?

For doing this without corebutils.

regards nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpcWZRtwDNaN.pgp
Description: PGP signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Matthew Garrett]

Nico Golde <[EMAIL PROTECTED]> wrote:
> Hallo Eduard,
> * Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 13:02]:
>> #include 
>> * Nico Golde [Sat, Jul 09 2005, 12:06:54PM]:
>> > I think there is apt-history a better way.
>> For doing what exactly?
> 
> For doing this without corebutils.

Coreutils is required. Why is the ability to do something without it an
advantage?

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo Matthew,

* Matthew Garrett <[EMAIL PROTECTED]> [2005-07-09 13:09]:
> Nico Golde <[EMAIL PROTECTED]> wrote:
> > Hallo Eduard,
> > * Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 13:02]:
> >> #include 
> >> * Nico Golde [Sat, Jul 09 2005, 12:06:54PM]:
> >> > I think there is apt-history a better way.
> >> For doing what exactly?
> > 
> > For doing this without corebutils.
> 
> Coreutils is required. Why is the ability to do something without it an
> advantage?

You can do almost every thing with with tools like, grep,
sed, awk etc. but in my opinion this should be so easy as
possible to everyone. Not everybody is familiar with grep
etc. but apt-history show should be no problem.

Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpImwEw1nLn1.pgp
Description: PGP signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[David Pashley]

On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> Hallo Matthew,
> > 
> > Coreutils is required. Why is the ability to do something without it an
> > advantage?
> 
> You can do almost every thing with with tools like, grep,
> sed, awk etc. but in my opinion this should be so easy as
> possible to everyone. Not everybody is familiar with grep
> etc. but apt-history show should be no problem.
> 
> Regards Nico

function apt-history () {
   grep " $1 " /var/log/dpkg.log
}


-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo David,

* David Pashley <[EMAIL PROTECTED]> [2005-07-09 13:20]:
> On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> > > Coreutils is required. Why is the ability to do something without it an
> > > advantage?
> > 
> > You can do almost every thing with with tools like, grep,
> > sed, awk etc. but in my opinion this should be so easy as
> > possible to everyone. Not everybody is familiar with grep
> > etc. but apt-history show should be no problem.
> > 
> > Regards Nico
> 
> function apt-history () {
>grep " $1 " /var/log/dpkg.log
> }

That depends of the knowledge of shell functions.
Please download the package and test it before you judge.
If you then think that the package is overload I close the
bug.
Thanks Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpyOCQVEe04M.pgp
Description: PGP signature

Re: should etch be Debian 4.0 ?

[Nigel Jones]

On 08/07/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 08, 2005 at 11:57:25AM +1000, Drew Parsons wrote:
> > I'm already seeing documentation referring to "Debian 3.2 (etch)".
> 
> Where is this?  It's certainly wrong for documentation to make assumptions
> about the release version number at this point, and is the kind of thing
> that makes it harder to change later.
> 
> And after all, isn't the point of codenames to avoid third-parties
> incorrectly attaching a version number to a not-yet-released version?
> 

http://ru.wikibooks.org/wiki/LOR-FAQ-Debian seems to be saying Etch is 3.2 
Also http://www.computerbase.de/lexikon/Debian seems to be saying the same.
(Got these from a google search of "etch 3.2 debian" (page 8 onwards)).

I suppose if etch does result in been 4.0 the media is going to say
that the project didn't keep to it's word?

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Eduard Bloch]

#include 
* Nico Golde [Sat, Jul 09 2005, 01:04:23PM]:

> > > I think there is apt-history a better way.
> > 
> > For doing what exactly?
> 
> For doing this without corebutils.

a) grep it is not in coreutils but in the grep package
b) you seem to have an allergy to essential packages (you know,
those installed on every system, like grep, bash, ...) or is there any
other reason to justify a PYTHON installation for a tool without extra
features?

Regards,
Eduard.
-- 
Susan Ivanova: An expedition to Coronis space found Sheridan's ship a few days
later, but they never found him. All the airlocks were sealed, but there was no
trace of him inside.  Some of the Minbari believe he will come back some day,
but I never say him again in my lifetime...
 -- Quotes from Babylon 5 --


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo Eduard,

* Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 13:26]:
> #include 
> * Nico Golde [Sat, Jul 09 2005, 01:04:23PM]:
> > > > I think there is apt-history a better way.
> > > 
> > > For doing what exactly?
> > 
> > For doing this without corebutils.
> 
> a) grep it is not in coreutils but in the grep package

I don't talked about the package :) Everybody is using it so
i is core :)

> b) you seem to have an allergy to essential packages (you know,
> those installed on every system, like grep, bash, ...) or is there any
> other reason to justify a PYTHON installation for a tool without extra
> features?

I have no allergy to essential packages, but I don't think
that it is very userfriendly to say oh use these tools
combined with this if you want info if you can use just one
tool. Especially because there are alot of users (maybe new
to linux) wo want to know these infos but are not familiar
with these tools.
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpl4HsxFGqWQ.pgp
Description: PGP signature

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote:
> Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > > Keeping the question priority at 'low' make sure most users will not
> > > see the question, and that only reconfigure will present it.  I hope
> > > you are not setting the debconf priority limit to low. :)
> >
> > If we recommend against setting the priority to low, why bother with it?
> 
> Enabling debconf pre-seeding for customized installs is a good enough
> justification IMO.

Isn't debconf a bit 'expensive' just to allow pre-seeding?

Re: should etch be Debian 4.0 ?

[Santiago Vila]

On Sat, 9 Jul 2005, Nigel Jones wrote:

> On 08/07/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 08, 2005 at 11:57:25AM +1000, Drew Parsons wrote:
> > > I'm already seeing documentation referring to "Debian 3.2 (etch)".
> >
> > Where is this?  It's certainly wrong for documentation to make assumptions
> > about the release version number at this point, and is the kind of thing
> > that makes it harder to change later.
> >
> > And after all, isn't the point of codenames to avoid third-parties
> > incorrectly attaching a version number to a not-yet-released version?
>
> http://ru.wikibooks.org/wiki/LOR-FAQ-Debian seems to be saying Etch is 3.2
> Also http://www.computerbase.de/lexikon/Debian seems to be saying the same.
> (Got these from a google search of "etch 3.2 debian" (page 8 onwards)).

Those references should be changed, then. It's *not* ok to refer to etch
as Debian 3.2, as the version number for etch has not been decided yet.


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Eduard Bloch]

#include 
* Nico Golde [Sat, Jul 09 2005, 01:12:24PM]:

> > Coreutils is required. Why is the ability to do something without it an
> > advantage?
> 
> You can do almost every thing with with tools like, grep,
> sed, awk etc. but in my opinion this should be so easy as
> possible to everyone. Not everybody is familiar with grep
> etc. but apt-history show should be no problem.

a) a system administrator has to be familiar with grep (don't throw in
FUD like "awk, etc.", those are tools for people that like them).
Learning grep's usage for this purpose is not much more complicated than
learning apt-history's usage.
b) it is a problem for _everyone_ if you create a _new_ package, which
eats up disk space with its meta data and kills apt's performance for no
good reason

Regards,
Eduard.

-- 
Schon wieder Telefon... Ein noier Juser... :-)
Aber der tippt so langsam, da kann ich locker bei ircen ]:-)
-- Quelle bekannt

Bug#317522: ITP: libclass-errorhandler-perl -- Base class for error handling

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libclass-errorhandler-perl
  Version : 0.01
  Upstream Author : Benjamin Trott <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Class-ErrorHandler/
* License : Dual GPL/Artistic
  Description : Base class for error handling

Class::ErrorHandler provides an error-handling mechanism that's generic
enough to be used as the base class for a variety of OO classes.
Subclasses inherit its two error-handling methods, error and errstr, to
communicate error messages back to the calling program.


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

Re: configure a program -- debconf abuse?

[Petter Reinholdtsen]

[Olaf van der Spek]
> Isn't debconf a bit 'expensive' just to allow pre-seeding?

No, it is amazingly cheap and simple.  Did you have any cheaper
suggestions?

Having one consistent way to provide install time configuration is
important to be able to share configuration settings across custom
debian distributions, and also to reduce the complexity in the
individual custom debian distributions.


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Nico Golde]

Hallo Eduard,

* Eduard Bloch <[EMAIL PROTECTED]> [2005-07-09 13:44]:
> #include 
> * Nico Golde [Sat, Jul 09 2005, 01:12:24PM]:
> 
> > > Coreutils is required. Why is the ability to do something without it an
> > > advantage?
> > 
> > You can do almost every thing with with tools like, grep,
> > sed, awk etc. but in my opinion this should be so easy as
> > possible to everyone. Not everybody is familiar with grep
> > etc. but apt-history show should be no problem.
> 
> a) a system administrator has to be familiar with grep (don't throw in
> FUD like "awk, etc.", those are tools for people that like them).
> Learning grep's usage for this purpose is not much more complicated than
> learning apt-history's usage.

I don't talk about real administrators, I talk about users
with su permissions.

> b) it is a problem for _everyone_ if you create a _new_ package, which
> eats up disk space with its meta data and kills apt's performance for no
> good reason

Ok it seems that I am the only one interrested in this
package. I will close the bug.
Thanks for your help!
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpMBBR4xiFVf.pgp
Description: PGP signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[David Pashley]

On Jul 09, 2005 at 12:22, Nico Golde praised the llamas by saying:
> Hallo David,
> 
> * David Pashley <[EMAIL PROTECTED]> [2005-07-09 13:20]:
> > On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> > > > Coreutils is required. Why is the ability to do something without it an
> > > > advantage?
> > > 
> > > You can do almost every thing with with tools like, grep,
> > > sed, awk etc. but in my opinion this should be so easy as
> > > possible to everyone. Not everybody is familiar with grep
> > > etc. but apt-history show should be no problem.
> > > 
> > > Regards Nico
> > 
> > function apt-history () {
> >grep " $1 " /var/log/dpkg.log
> > }
> 
> That depends of the knowledge of shell functions.
> Please download the package and test it before you judge.
> If you then think that the package is overload I close the
> bug.
> Thanks Nico

The script hooks into DPkg::Post-Invoke and parses the status database
and records the same information that the dpkg.log stores. Basically you
end up with the information twice. You would be better off parsing
dpkg.log. I think you should file a wishlist bug against dpkg to include
it in that package. It isn't worth creating a package just for a 178
line python script.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Olaf van der Spek]
> > Isn't debconf a bit 'expensive' just to allow pre-seeding?
> 
> No, it is amazingly cheap and simple.  

Don't debconf questions need to be translated?

> Did you have any cheaper
> suggestions?

Nothing concrete at the moment.

> Having one consistent way to provide install time configuration is
> important to be able to share configuration settings across custom
> debian distributions, and also to reduce the complexity in the
> individual custom debian distributions.

Re: configure a program -- debconf abuse?

[Petter Reinholdtsen]

[Olaf van der Spek]
> Don't debconf questions need to be translated?

Non-hidden questions should normally be translated, but the package
maintainer can choose if the question should be translated or not (by
not using _Description in the template).

Hidden questions (the prefered way to allow preseeding for options not
ment for normal installations) will never be shown to users, and do
not need translations.


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

Do not have money , get software cds from here!

[Eve]

We guarantee 100% authentic software.
http://nejzj.1q5gmijcgbj8g21.lhotacg.com




Fear of a name increases fear of the thing itself.   
Courage is fear holding on a minute longer. 




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

Re: RFS: libssh - SSH and SCP library

[Jean-Philippe Garcia Ballester]

On Fri, Jul 08, 2005 at 02:32:27PM +0200, Jean-Philippe Garcia Ballester wrote :
> On Thu, Jul 07, 2005 at 11:56:51PM +0200, Josselin Mouette wrote :
> > Le vendredi 08 juillet 2005 ? 06:46 +0900, Junichi Uekawa a ?crit :
> > > > > 1. It's linking with openssl, and claiming to be LGPL, which 
> > > > >   I understand to be incompatible.
> > > > 
> > > > It is compatible.
> > > 
> > > Are you sure?
> > > People were running around GPL is not compatible with 
> > > openssl license; and LGPL has a option to make the 
> > > code GPL.
> > 
> > The point of the LGPL is to avoid such incompatibilities. If you can
> > link it with proprietary code, you can also link it to code under the
> > OpenSSL license.
> > 
> > That said, I think too we should favor libgcrypt, because it has a
> > lighter security record.
> 
>   I mailed him about that and SONAME versionning.

I got his reply. As Junichi thought, he doesn't know about SONAME
versionning. I pointed to him chapter 6 of the libtool manual.
He said he's only using "basic cryptographic stuff from libcrypto,
which are less likely to have security problems." As he has been
approved by google's "Summer of Code", the next two months' work will
only be functionnality adds. Changing cryptographic library is not a
priority, but at queue of the TODO.

Regards,

-- 
Jean-Philippe Garcia Ballester


signature.asc
Description: Digital signature

Re: configure a program -- debconf abuse?

[Hamish Moffatt]

On Sat, Jul 09, 2005 at 10:00:16AM +0300, Gustavo Noronha Silva wrote:
> Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > > Keeping the question priority at 'low' make sure most users will not
> > > see the question, and that only reconfigure will present it.  I hope
> > > you are not setting the debconf priority limit to low. :)
> > 
> > If we recommend against setting the priority to low, why bother with it?
> 
> Enabling debconf pre-seeding for customized installs is a good enough
> justification IMO.

That sounds like a good use for hidden questions. But I think we ask way
too many questions on the whole.

In the last two days I helped a friend with a sarge install who is new
to linux. We installed the base system with the desktop task.

Does the new Debian user really care if their fonts are managed with
defoma, a technology they have never heard of? (And when did defomized 
become a verb?) There should be a sensible default. Why shouldn't fonts
always be managed with defoma?

Is it important at system install time to ask whether cdrecord should be
installed SUID or not? There should be a sensible default there too.

The post-reboot (debootstrap) stage asks way too many questions. 
This is a pity because the pre-reboot (d-i) stage is excellent.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 09, 2005 at 10:00:16AM +0300, Gustavo Noronha Silva wrote:
> > Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > > > Keeping the question priority at 'low' make sure most users will not
> > > > see the question, and that only reconfigure will present it.  I hope
> > > > you are not setting the debconf priority limit to low. :)
> > >
> > > If we recommend against setting the priority to low, why bother with it?
> >
> > Enabling debconf pre-seeding for customized installs is a good enough
> > justification IMO.
> 
> That sounds like a good use for hidden questions. But I think we ask way
> too many questions on the whole.
> 
> In the last two days I helped a friend with a sarge install who is new
> to linux. We installed the base system with the desktop task.
> 
> Does the new Debian user really care if their fonts are managed with
> defoma, a technology they have never heard of? (And when did defomized
> become a verb?) There should be a sensible default. Why shouldn't fonts
> always be managed with defoma?
> 
> Is it important at system install time to ask whether cdrecord should be
> installed SUID or not? There should be a sensible default there too.
> 
> The post-reboot (debootstrap) stage asks way too many questions.
> This is a pity because the pre-reboot (d-i) stage is excellent.

I've been wondering the same about questions on updates. Why are
(many) questions being asked on updates (first update after system
install)? Sounds like a weird time to me.

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

Hi,

This is a huge list, with probably 0 chances of getting
 accomplished.  How about this: remove every single item from the
 list, and only add items when there are people who sign up to be
 responsible for the work involved in actually seeing that item come
 to fruition?

Mere wishlists by random bystanders are no help to anyone.

manoj
-- 
A gift of flower will soon be made to you.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 09 Jul 2005 20:13:57 +1000, Brian May <[EMAIL PROTECTED]> said: 

> 1. Review bugs in web browser.
> 2. Identify questionably bug that you haven't already looked at
>before today.

Hint: have a local notebook that you mark bugs you look at.

> 3. Inspect bug report, in new window, install package, install
>source, inspect as required. Open up new browser windows to find
>information as required.

There is a download bug reports as mailbox feature.

> 4. Make changes as required to source code.
> 5. Enter one/more emails to either forward bug upstream, change
>tags, or close the bug.
> 6. Go back to step 3.

> 7. Fix up the all the silly typos made in every BTS email sent so
>far and retransmit. (note: this is after the BTS has decided to
>respond).

! [1]

> 8. upload the changes to source code.

> 9. realize that I forgot to sign the upload due to a bug in by
>pbuilder wrapper script, create a *.commands file to send to the
>upload queue to delete the old upload and reupload again.

! [2]

Are we sure we want someone who is routinely this incompetent
 to help with bug triage? Seems to me we would be bette off without
 such substandard help; anyone this incompetent is probably creating
 more problems than they are solving.

> 4. Make dupload obsolete, and replace with dput. Make dput the
>default in debrelease. I think dput would have prevented me
>uploading my unsigned package.

 ~/.dupload.conf:
$preupload{'changes'} = 'gpg --verify %1';
$preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify 
"$j.dsc"';
$preupload{'deb'} = 'lintian -v -i %1';


Just this point (not knowing ones tools) makes this message
 highly suspect.

manoj
-- 
Only the hypocrite is really rotten to the core. Hannah Arendt
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Documentation of alioth?

[Michael Bramer]

Hello

Maybe I miss something, but have we some Documentation about
alioth/gforge?

And is there some alioth mailinglist (or is debian-devel ok for more
alioth questions?)

Gruss
Grisu
-- 
Michael Bramer  -- http://www.feuerwehr.kreuzau.de/wiki/
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"it was hard to write, so it should be hard to read"


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Christian Perrier]

Dunno which section of your list this should pertain but "Enforce the
use of po-debconf for debconf templates" is in my mind.

This probably needs a few s/SHOULD/MUST in the policy so that we can
file RC bugs on packages which still use the "old style" debconf l10n
system.

There are few of these and, IIRC, none of them are really critical
packages. Some work was done a few months ago, including NMUs, but the
release priorities have stopped it.

I also think think about enforcing the use of debconf for packages
during config step so that NO package prompts users outside debconf
and interrupts installs/upgrades (wvdial comes to my mind).



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

Re: should etch be Debian 4.0 ?

[Antti-Juhani Kaijanaho]

On 20050708T181259-0400, Johan Kullstam wrote:
> I've never understood the .X distinction anyway.  
> 
> What signal is meant by 3.1 versus 4.0?  Does your intended audience
> have any concept of the distinction?

The usual distinction, when it is made, is that bumping the major number
indicates a disruptive upgrade (changing how things work, not just
adding new things).

I suppose I should advertise my version number rant here:
 http://antti-juhani.kaijanaho.info/blog/en/programming/version-numbering.html

-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: multiarch?

[Bob Proulx]

Goswin von Brederlow wrote:
> Bob Proulx writes:
> > Sure, native code is always better.  But that still won't help when
> > sharing binaries from other distros to and from Debian.  Because those
> > other commonly available binaries of which people think are so
> > critical will be 32-bit.  (I am referring to those evil flash plugins,
> > acrobat, etc. in addition to the Quake mentioned by the previous
> > poster.  But UT and Starcraft are more my style.)
> 
> They rarely come as deb and then having multiarch support in apt/dpkg
> makes no difference at all.

I was referring needing to maintain an ia32 chroot.  (Because
ia32-libs can never be completely satisfactory.)

Having multiarch would obviate the need for separate 32-bit package
management.  It would all become mainstream at that point.  This would
make it very easy for users and casual administrators to natively run
32-bit programs on the 64-bit system.

Bob


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

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Roberto C. Sanchez]

I posted this to debian-release yesterday, but have received no replies.
I would like to know if it is possible to get httperf back into Sarge
(for the reasons stated below), or if I should simply not worry about
it.

-Roberto

On Fri, Jul 08, 2005 at 09:18:16AM +0200, Martin Schulze wrote:
> 
> The requirements for packages to get updated in stable are:
> 
>  1. The package fixes a security problem.  An advisory by our own
> Security Team is required.  Updates need to be approved by the
> Security Team.
> 
>  2. The package fixes a critical bug which can lead into data loss,
> data corruption, or an overly broken system, or the package is
> broken or not usable (anymore).
> 
>  3. The stable version of the package is not installable at all due to
> broken or unmet dependencies or broken installation scripts.
> 
>  4. All released architectures have to be in sync.
> 
>  5. The package gets all released architectures back in sync.
> 
> It is (or (and (or 1 2 3) 4) 5)
> 

I am adopting the httperf package.  It was in Woody and was removed from
Sarge/Sid because of licensing issues with linking to OpenSSL.  The
issue has been resolved [0] by the current upstream maintainer.   Since
the package was in Woody and not in Sarge [1], there is the potential
for someone to have had it installed prior to upgrading and now have it
still installed.  This could be a problem since if the package is only
allowed back into Sid/Etch, then Sarge users with the "obsolete" httperf
would not receive any future security updates (if they become necessary)
for the package.  Is this sufficient justification to have the package
added back in to Sarge?

Here is a summary of the changes from the Woody version:

* Move from non-US to main
* Recompile against libssl0.9.7
* Update license and copyright file.
* Corrected some minor lintian warnings against the man page.
* Added a watch file.

The last two changes can be backed out if it is necessary to get the
package into Sarge.  If this is sufficient, I can have a new package
done and uploaded (by my sponsor) by tomorrow.

Comments would be appreciated.

-Roberto

[0] http://lists.debian.org/debian-legal/2005/07/msg00040.html
[1] http://packages.debian.org/httperf

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


pgpg9SAiOq73D.pgp
Description: PGP signature

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Frank Lichtenheld]

On Sat, Jul 09, 2005 at 01:33:14PM -0400, Roberto C. Sanchez wrote:
> I posted this to debian-release yesterday, but have received no replies.

So you decided to post it to debian-devel? Seems odd to me...
but anyway, here my completly non-authorative answer (since I'm
neither the SRM nor an ftp-master): Don't bother to try that. I
see no point in the criteria for updates in a stable
release that would justify such a step.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Preparation of the next stable Debian GNU/Linux update (I)

[Roberto C. Sanchez]

On Sat, Jul 09, 2005 at 07:56:55PM +0200, Frank Lichtenheld wrote:
> On Sat, Jul 09, 2005 at 01:33:14PM -0400, Roberto C. Sanchez wrote:
> > I posted this to debian-release yesterday, but have received no replies.
> 
> So you decided to post it to debian-devel? Seems odd to me...
> but anyway, here my completly non-authorative answer (since I'm
> neither the SRM nor an ftp-master): Don't bother to try that. I
> see no point in the criteria for updates in a stable
> release that would justify such a step.

OK.  I was just looking for comments on whether it was justified and/or
feasible.  Since it is neither, I will cease and desist.  Thanks.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


pgp8TqAAEPKtZ.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 9 Jul 2005 07:28:47 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

> Dunno which section of your list this should pertain but "Enforce
> the use of po-debconf for debconf templates" is in my mind.

> This probably needs a few s/SHOULD/MUST in the policy so that we can
> file RC bugs on packages which still use the "old style" debconf
> l10n system.

Why do we need to beat peope on the head with policy before
 they do this?  Could we have a list of people who are resisting this
 change? 

> There are few of these and, IIRC, none of them are really critical
> packages. Some work was done a few months ago, including NMUs, but
> the release priorities have stopped it.

Do you have a (perhaps partial) list f packages still using
 the old mechanism? An idea of the magnitude of the impact of this
 policy change would be helpful in deciding whether or not to change
 policy.

> I also think think about enforcing the use of debconf for packages
> during config step so that NO package prompts users outside debconf
> and interrupts installs/upgrades (wvdial comes to my mind).

It is not possible in all cases to ask all the questions
 before a package is unpacked.

manoj
-- 
"Mr. Spock succumbs to a powerful mating urge and nearly kills Captain
Kirk." TV Guide, describing the Star Trek episode _Amok_Time_
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Callwave Uninstall

[KATHRYN CHRISTENSEN]

Please uninstall my callwave 
feature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Adam Heath]

On Sat, 9 Jul 2005, David Pashley wrote:

> On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> > Hallo Matthew,
> > >
> > > Coreutils is required. Why is the ability to do something without it an
> > > advantage?
> >
> > You can do almost every thing with with tools like, grep,
> > sed, awk etc. but in my opinion this should be so easy as
> > possible to everyone. Not everybody is familiar with grep
> > etc. but apt-history show should be no problem.
> >
> > Regards Nico
>
> function apt-history () {
>grep " $1 " /var/log/dpkg.log
> }

Actually, apt-history would be prefered.

dpkg logs everything that is actually installed.  However, apt installs
dependencies based on install requests.  Those dependencies aren't actually
important when recreating an install list.


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

Re: Question about kill(1)

[Goswin von Brederlow]

Brian May <[EMAIL PROTECTED]> writes:

>> "Adeodato" == Adeodato Simó <[EMAIL PROTECTED]> writes:
>
> Adeodato> I also have heard (but I'm not sure how often does this
> Adeodato> happen, if at all) that it is usefult to have it as a
> Adeodato> built-in when your system is in a state when it can't
> Adeodato> create more processes.
>
> In practise whenever that happens, and if I am lucky enough to have a
> terminal open, and if I am not dumb enough to accidently close the
> window, I don't know what the PID is of that CPU hungry/memory hungry
> process is in order to kill it.

Try ctrl/atl/shift + print/scroll/pause combinations on the
console. Or alt+sysrq+h if thats enabled in your kernel. You get a
process listing with one of the first and the second can do a lot
more.

MfG
Goswin


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

Re: configure a program -- debconf abuse?

[Gustavo Noronha Silva]

Em Sáb, 2005-07-09 às 13:54 +0200, Olaf van der Spek escreveu:
> On 7/9/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> > [Olaf van der Spek]
> > > Isn't debconf a bit 'expensive' just to allow pre-seeding?
> > 
> > No, it is amazingly cheap and simple.  
> 
> Don't debconf questions need to be translated?

s/Don't// s/need to/can/ s/\?/\!/

It's possible to translate debconf questions and it's great that we who
have languages !english as first language have this possibility, but
we'd probably set a low priority for this template in particular.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Goswin von Brederlow]

Nico Golde <[EMAIL PROTECTED]> writes:

> Ok it seems that I am the only one interrested in this
> package. I will close the bug.
> Thanks for your help!
> Regards Nico

Please don't. Rather do what people suggested:

1.) adapt the script to use the dpkg.log

The dpkg log is overly detailed and probably confusing to normal
users. Your output seems to be much pretier. Read in the logfile and
extract the relevant information. Can't be much harder than parsing
the status file.

This has also the advantage that usage of dpkg directly will show up
in your output.

2.) contact the apt or dpkg maintainers

Talk to them about inclusion of apt-history (or dpkg-history in dpkg)
in their package. People are against creating yet another package when
the functionality clearly belongs inside an existing one.

MfG
Goswin


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

Re: configure a program -- debconf abuse?

[Gustavo Noronha Silva]

Em Sáb, 2005-07-09 às 22:58 +1000, Hamish Moffatt escreveu:
> That sounds like a good use for hidden questions. But I think we ask way
> too many questions on the whole.

Agreed.

> Does the new Debian user really care if their fonts are managed with
> defoma, a technology they have never heard of? (And when did defomized 
> become a verb?) There should be a sensible default. Why shouldn't fonts
> always be managed with defoma?

Agreed, again. Undoing this "abuse" of debconf priorities is one of the
stated goals of the Debian Desktop sub-project, you know:

http://www.debian.org/devel/debian-desktop/

> The post-reboot (debootstrap) stage asks way too many questions. 
> This is a pity because the pre-reboot (d-i) stage is excellent.

So let's make it better!

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: Bug#301527: ITP: mazeofgalious -- The Maze of Galious

[Henrique de Moraes Holschuh]

On Mon, 04 Jul 2005, Gürkan Sengün wrote:
> >* Package name: mazeofgalious
> >  Version : 0.62
> >  Upstream Authors: Santi Ontanon <[EMAIL PROTECTED]>
> >* URL : http://www.braingames.getput.com/mog/
> >* License : Not defined yet (will try to work this out with 
> >upstream)
> >  Description : The Maze of Galious
> 
> It's now GPL, the missing License file was added as of yesterday.

It is still using a copyrighted/trademarked (don't know which) name, and a
lot of copyrighted IP.  It meets the DFSG, and it can go in main, but it is
very dubious if the upstream author has the right to call his game "Maze of
gallious" and even distribute it at all...

I wouldn't upload it to Debian, but I am just repeating myself here.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Goswin von Brederlow]

Adam Heath <[EMAIL PROTECTED]> writes:

> On Sat, 9 Jul 2005, David Pashley wrote:
>
>> On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
>> > Hallo Matthew,
>> > >
>> > > Coreutils is required. Why is the ability to do something without it an
>> > > advantage?
>> >
>> > You can do almost every thing with with tools like, grep,
>> > sed, awk etc. but in my opinion this should be so easy as
>> > possible to everyone. Not everybody is familiar with grep
>> > etc. but apt-history show should be no problem.
>> >
>> > Regards Nico
>>
>> function apt-history () {
>>grep " $1 " /var/log/dpkg.log
>> }
>
> Actually, apt-history would be prefered.
>
> dpkg logs everything that is actually installed.  However, apt installs
> dependencies based on install requests.  Those dependencies aren't actually
> important when recreating an install list.

The author mentioned it would use one of the apt hooks and then parse
the status file. That wouldn't get the apt commandline (i.e. what you
asked to install), but just the overall changes to the system (what
dpkg documents too).

I guess you would have to divert apt-get and aptitude for that and log
the invocations.

Actualy with aptitude taking the list of non automatic packages should
give you exactly the install list.

MfG
Goswin


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

Bug#317569: ITP: drbdlinks -- Manages links into a shared DRBD partition

[Cyril Bouthors]

Package: wnpp
Severity: wishlist

* Package name: drbdlinks
  Version : 1.03
  Upstream Author : Sean Reifschneider <[EMAIL PROTECTED]>
* URL or Web page : http://www.tummy.com/Community/software/drbdlinks/
* License : GNU GENERAL PUBLIC LICENSE version 2
  Description : Manages links into a shared DRBD partition
-- 
Cyril Bouthors


pgpxsj6fqXkB0.pgp
Description: PGP signature

Re: Bug#301527: ITP: mazeofgalious -- The Maze of Galious

[John Hasler]

> It is still using a copyrighted/trademarked (don't know which) name

There is no such thing as a copyrighted name.  The name does appear to have
been a trademark at one time, but if enough time has gone by without a
product being marketed under that name the trademark will have lapsed.
-- 
John Hasler


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Petter Reinholdtsen]

[Manoj Srivastava]
>> 4. Make dupload obsolete, and replace with dput. Make dput the
>>default in debrelease. I think dput would have prevented me
>>uploading my unsigned package.
> 
>  ~/.dupload.conf:
> $preupload{'changes'} = 'gpg --verify %1';
> $preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify 
> "$j.dsc"';
> $preupload{'deb'} = 'lintian -v -i %1';
> 
> 
> Just this point (not knowing ones tools) makes this message
>  highly suspect.

If these are good settings for dupload, why is it not included in the
package as the default configuration for dupload?


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> If these are good settings for dupload, why is it not included in
> the package as the default configuration for dupload?

Good by whose criteria? Yours? Mine? Joe random Developer's?
 What is more important -- speed, not seeing garbage on the screen
 when uploading, or ensuring one always signs stuff? What if I use
 pbuilder and it always signs stuff for me, so the check is just a
 waste of time? What if I wanna upload even when linda crashes (as it
 does periodically for me)?


Why are people so darned allergic to looking up the
 documentation and configuring packages to suit their needs?  Why must
 one always be spoon fed pap from the maintainer, straight out of the
 box, so one does not ever have to think an iota for one self?

What if there is no One True Way To Configure Everything?

The settings I provided suited the needs of the parent
 poster -- but may or may not suit the needs of everyone else (the
 linda afficianados would not like the settings, nor would people who
 always ensure their packages are signed by other means).

manoj
-- 
The bureaucracy is expanding to meet the needs of an expanding
bureaucracy.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Olaf van der Spek]

On 7/9/05, Manoj Srivastava va, manoj <[EMAIL PROTECTED]> wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
> said:
> 
> > If these are good settings for dupload, why is it not included in
> > the package as the default configuration for dupload?
> 
>Good by whose criteria? Yours? Mine? Joe random Developer's?
>  What is more important -- speed, not seeing garbage on the screen
>  when uploading, or ensuring one always signs stuff? What if I use
>  pbuilder and it always signs stuff for me, so the check is just a
>  waste of time? What if I wanna upload even when linda crashes (as it
>  does periodically for me)?

Wouldn't it be better to have a 'safe' default then a fast one?

You need only 15 minutes to prepare for the night of love.

[Rupert]

Why are online drugs popular
http://anarchism.greatmedzsh0p.info/?Kalamazooxtvuybraeszctvillager


If you obey all the rules, you miss all the fun.  
Gratitude is a sickness, suffered by dogs.  
Study the past if you would define the future.
I exist as I am, that is enough. 





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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Guillem Jover]

On Sat, Jul 09, 2005 at 09:00:19PM +0200, Goswin von Brederlow wrote:
> I guess you would have to divert apt-get and aptitude for that and log
> the invocations.
> 
> Actualy with aptitude taking the list of non automatic packages should
> give you exactly the install list.

aptitude has had such kind of log for a long time:

/var/log/aptitude

regards,
guillem


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

Re: multiarch?

[Nigel Jones]

On 08/07/05, Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> 
> 
> > On Thu, Jul 07, 2005 at 10:03:09PM +0200, Pierre Habouzit wrote:
> >> Le Jeu 7 Juillet 2005 21:17, Josselin Mouette a ?crit :
> >> > If we don't start the multiarch effort now, it won't be good for
> >> > etch. Are we postponing this to the next release?
> >>
> >> I hope not ... I'm a quite happy owner of amd64 machines, so happy that
> >> I've only amd64 machines for my desktops, and maintaining a chroot to
> >> use openoffice is quite annoying (same is true for quake/et but I
> >> assume it won't bother debian that much ;p)
> >
> > Wouldn't you be better off with a native Oo.org rather than multiarch
> > in this case?
> 
> World is not pure 64.
> There exists software - and will exist in forseable future - which (a) is
> needed for users, and (b) is not available 64bit.
> 
> Although some hacks are possible to make it run - such as 32bit chroot or
> putting stuff in /emul - hacks have never been the Debian way. Debian was
> known for years for it's technical quality, and it's a suicide solution to
> make this no longer true.
> 
> Multiarch, although being some technical challenge, is an elegant solution
> for this situation. And it is useful for all archs which have hardware
> capability to run both 64 bit and 32 bit binaries (and also for those who
> wish to run non-native binaries with emulation techniques such as qemu)
> 
> 
> What real reasons (other than "it's cool") are there to run 64bit software?
> 
> - in some cases, it gives real (greater than 1%) performance gain.
> - in some cases, address space wider than 32bit is useful.
I have also noticed that some applications when built, are smaller.
> 

Also, why not lobby some of these non pure software makers to also
create pure-amd64/pure-*64 builds of their software.

However, in the end, I see no problem with pure 64bit distributions,
the one i'm on currently works better than great.  Personally, I'd
sooner see a chroot-32 package that will let install a working 32bit
chroot, and then let me apt-get install openoffice... to that
location.  That way, we are still talking about been user friendly and
we are affecting only the applications that won't run on pure 64bit
distributions.

My 2 cents,

-- 
N Jones
Blogging @ http://nigelj.blogspot.com
Proud Debian & FOSS User
Debian Maintainer of: html2ps & ipkungfu

Bug#317602: ITP: xmms-openspc -- SPC file player plugin for XMMS

[Ryan Schultz]

Package: wnpp
Owner: Ryan Schultz <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: xmms-openspc
  Version : 0.0.3
  Upstream Author : Zinx Verituse <[EMAIL PROTECTED]>
* URL : http://staff.xmms.org/zinx/misc/tmp
* License : GPL
  Description : SPC file player plugin for XMMS

 XMMS-OpenSPC is an XMMS plugin that allows you to play SNES audio
 files in the .spc format. This plugin can also read the id666 tags
 used by SPC files.

Note: upstream doesn't compile with gcc-4.0, and also segfaults XMMS --
the segfault is fixed in CVS but it won't autoconf for me, so I've fixed
both problems myself. CVS hasn't been touched for over a year, as well.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-ck3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


pgpHuCd8DwFzT.pgp
Description: PGP signature

Re: RFS: libssh - SSH and SCP library

[Peter Samuelson]

[Gustavo Noronha Silva]
> > +liblibssh 0.11 libssh (>> 0.11-0), libssh (<< 0.11-99)
> 
> I don't get the << 0.11-99. Why would you add this?

I imagine he meant (<< 0.12).  On the theory that since upstream is
using 0.11 as the soname, upstream 0.12 will probably be incompatible.


signature.asc
Description: Digital signature

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[David Pashley]

On Jul 09, 2005 at 19:36, Goswin von Brederlow praised the llamas by saying:
> Nico Golde <[EMAIL PROTECTED]> writes:
> 
> > Ok it seems that I am the only one interrested in this
> > package. I will close the bug.
> > Thanks for your help!
> > Regards Nico
> 
> Please don't. Rather do what people suggested:
> 
> 1.) adapt the script to use the dpkg.log
> 
> The dpkg log is overly detailed and probably confusing to normal
> users. Your output seems to be much pretier. Read in the logfile and
> extract the relevant information. Can't be much harder than parsing
> the status file.
> 
> This has also the advantage that usage of dpkg directly will show up
> in your output.
> 
> 2.) contact the apt or dpkg maintainers
> 
> Talk to them about inclusion of apt-history (or dpkg-history in dpkg)
> in their package. People are against creating yet another package when
> the functionality clearly belongs inside an existing one.
> 
I'm wondering if this wouldn't be better added as a feature to
aptitude/synaptic, as people who would use apt-get or dpkg would
probably know grep. The people he was targetting are more likely to use
one of the package selection tools.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: RFS: libssh - SSH and SCP library

[Junichi Uekawa]

Hi,

> > Are you sure?
> > People were running around GPL is not compatible with 
> > openssl license; and LGPL has a option to make the 
> > code GPL.
> 
> The point of the LGPL is to avoid such incompatibilities. If you can
> link it with proprietary code, you can also link it to code under the
> OpenSSL license.

Hmm... you can use a LGPL library, but a LGPL library cannot use 
a non-compliant library. That's how LGPL exception works.



regards,
junichi


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

Re: RFS: libssh - SSH and SCP library

[Junichi Uekawa]

> > > That said, I think too we should favor libgcrypt, because it has a
> > > lighter security record.
> > 
> >   I mailed him about that and SONAME versionning.
> 
> I got his reply. As Junichi thought, he doesn't know about SONAME
> versionning. I pointed to him chapter 6 of the libtool manual.
> He said he's only using "basic cryptographic stuff from libcrypto,
> which are less likely to have security problems." As he has been
> approved by google's "Summer of Code", the next two months' work will
> only be functionnality adds. Changing cryptographic library is not a
> priority, but at queue of the TODO.

You could do that kind of dirty work for him;
I think that's essential for inclusion into Debian archive.
Here's a link to a related work I've done before, which might
be helpful:

http://kerneltrap.org/mailarchive/15/message/53065/thread



regards,
junichi






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

Re: Package priorities: optional vs extra

[Nathanael Nerode]

Peter Samuelson wrote:
>In practice, 'extra' is mainly used when Policy forces you to use it:
>that is, if your package conflicts with another package which has
>priority optional or higher
The really sad part is that *this* isn't enforced; there are lots of 
"optional" packages which conflict with each other.

>Probably the best solution is to change Policy to say that 'optional'
>and 'extra' mean exactly the same thing, and remove the requirement
>that all 'optional' packages be able to coexist.

Unless someone is willing to actually enforce the requirement that all 
optional packages can coexist, this will be necessary to make Policy conform 
with reality.

Personally, I rather like the idea that all optional packages can coexist, but 
it isn't anywhere near true right now.


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Goswin von Brederlow]

David Pashley <[EMAIL PROTECTED]> writes:

> I'm wondering if this wouldn't be better added as a feature to
> aptitude/synaptic, as people who would use apt-get or dpkg would
> probably know grep. The people he was targetting are more likely to use
> one of the package selection tools.

Why not have it in dpkg and have aptitude or synaptic use it in turn?
Why limit it to higher level frontends when the backend can do it for
everything?

MfG
Goswin


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

Re: [Debian-uk] Sun have (probably) patented apt-get

[Nathanael Nerode]

On 4 Jul 2005, at 11:44 am, Wookey wrote:
> Take a look at this patent (granted this week in europe)
>
> http://gauss.ffii.org/PatentView/EP1170667
>
> I'm fairly sure that apt-get and associated package-integratity  
> checking tools could be considered infringing. (Does dpkg/apt have
> a modular structure?)

Clearly not patentable; there's surely gobs of prior art before the filing 
year of 2000.  This attempts to patent a generic package testing framework!  
It looks to me like dejagnu would "infringe" some of these claims, if they 
were valid, which they aren't.

The only claims which might be even slightly tricky to find prior art for are 
the claims about assigning a "priority" to each test.

It's currently in a nine-month opposition period.  Anyone want to do the work 
to find and send in the opposition material?

Gee, patent quality is at an all-time low.  :-(


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

Re: should etch be Debian 4.0 ?

[Nathanael Nerode]

I suggested "Debian IV", to *really* get rid of minor version numbers, 
permanently.  Initial release would be Debian IV r0.  Point releases would be 
Debian IV r1, etc.  Next release, Debian V, etc.


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

Re: Drop the minor release number

[Andreas Barth]

* Eduard Bloch ([EMAIL PROTECTED]) [050708 17:10]:
> Debian 4.0 for etch, 4.1 for etch stable release 1, 4.2 for etch stable
> release 2, 4.2a for etch stable release 2 with a minor CD mastering fix
> (for example), etc.pp.

Well, Woody was 3.0, Sarge was 3.1, so the logical next number would be
3.11 for Workgroups.


> Does the release team agree with this change or do we need another
> consensus (or even a GR)?

Threatening with a GR is BTW not the best way to get something working
smoothly - and also debian-release is not a discussion list, so please
don't CC it for discussion threads.


Cheers,
Andi


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

Re: Drop the minor release number

[Andreas Tille]

On Sun, 10 Jul 2005, Andreas Barth wrote:


Well, Woody was 3.0, Sarge was 3.1, so the logical next number would be
3.11 for Workgroups.

GREAT!
I'd vote for this! ;-)

Kind regards

 Andreas, who really loves such things like finding version numbers
  and names because it is so important compared to the
  technical stuff.

--
http://fam-tille.de


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