Re: funny outputs of ssh-vulnkey

[Paul Wise]

The -a option attempts to scan all keys on the machine, you need to
run it as root if you want to check every key that the script knows
about.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: ssl security desaster

[Patrik Fimml]

On Wed, May 28, 2008 at 12:00:47AM +0100, Colin Watson wrote:
> On Tue, May 27, 2008 at 05:49:59PM +0200, Patrik Fimml wrote:
> > No, actually, /all/ keys I generated were allegedly weak -- this means, 
> > after
> > executing ssh-keygen and dowkd.pl five times, I stuck to the key.
> 
> This rings all my alarm bells. In similar cases I've had reported to me,
> it always turned out that e.g. somebody had upgraded openssl but not
> libssl0.9.8, or something similar.

Eek, that may indeed have been possible. :-(

> > (ssh-vulnkey thinks it is fine though.)
> 
> While I'm very confident in ssh-vulnkey's accuracy, note that
> ssh-vulnkey has two different states you might interpret as "fine": "Not
> blacklisted" (i.e. definitely fine) and "Unknown (no blacklist
> information)" (i.e. no blacklist file installed for this key type and
> size). In the most recent upload to unstable, I clarified the second
> state to "Unknown (blacklist file not installed)" and added more
> detailed documentation in the manual page.

No, my current key is really fine.

It seems that I really only upgraded openssl when trying dowkd.pl, and
then upgraded everything before trying again. :-/ Sorry for the
confusion.

Patrik

PS: second eek - originally not sent to list accidentally.


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

Re: funny outputs of ssh-vulnkey

[Francesco P. Lovergine]

On Thu, May 29, 2008 at 03:32:27PM +0800, Paul Wise wrote:
> The -a option attempts to scan all keys on the machine, you need to
> run it as root if you want to check every key that the script knows
> about.
> 

I would add that on remote NFS directories root could have not
privileges to read such files, so those 'funny' outputs are
perfectly justified.

-- 
Francesco P. Lovergine


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

Re: Re: Generated changes and patch systems

[Simon McVittie]

(Please cc me in any replies, I'm not subscribed.)

Neil Williams wrote:
> ??? That simply does not work. The problem is that running gtk-doc not
> only requires tmpl/*.sgml files to exist but it *then modifies them*!

Here's how gtk-doc *used to* work:

* gtk-doc parses source code and writes out skeletal tmpl/*.sgml
* svn ci -m 'initial version of gtkdoc templates' tmpl
* upstream doc author inserts content into tmpl/*.sgml
* svn ci -m 'wrote some docs' tmpl
* gtk-doc parses source code (to pick up any new functions) + tmpl/*.sgml,
  and merges them
* svn ci -m 'yay gtkdoc' tmpl
* ...

This is, as you've noticed, insane. Sane upstreams now write all the
content for the documentation in /** */ comments in the source code, so
the tmpl/*.sgml are purely generated and can safely be omitted from
source-code control. (I have no opinion on whether your upstream is sane
or not - please check.)

However, the "no rule to make tmpl/*.sgml" issue still exists, as a
relic of the old build process.

(This history is also why gtkdoc insists on running in $srcdir, even in an
otherwise out-of-tree build - it goes as far as to chmod +w $srcdir to
subvert automake's attempts to catch writes to $srcdir!)

In Telepathy and Farsight we avoid ridiculous conflicts in tmpl/ in our
source-code control as follows:

* put tmpl/*.sgml in .svnignore, .gitignore, the darcs boringfile, or whatever
* as an exception to that, check in an empty file "tmpl/dummy.sgml"
  which is not referenced by anything else, so that builds from a clean
  checkout will succeed

In theory you could do this to get rid of tmpl/*.sgml in the tarball
too, but gtkdoc.make is in control of "make dist", so you probably can't.

Hope this helps,
Simon


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

Handling of removed packages

[Marc 'HE' Brockschmidt]

Heya,

For some time now, I have been thinking about the problem of packages
which are removed from the archive at some point, without an (enforced)
transition to a new package name. Users of such packages keep them
around, usually never noticing the fact that no security (or other)
support is available anymore.

Our current package management doesn't handle this case at all, so we
might need to fix this - we just need to decide how. The probably
easiest way would be to make apt whine on all packages that are not
available in any version at one of the locations specified in
sources.list. This trivial solution sucks, because locally created
packages [1] also fall in this category. So, has anyone a good idea
solving this problem, without needing to keepr masses of status/diff/bla
files around?

Marc

Footnotes: 
[1]  Such as kernel packages, binary kernel modules built from sources
 available in the archive, local configuration packages, ...
-- 
BOFH #368:
Failure to adjust for daylight savings time.


pgpJlSt6BtcSh.pgp
Description: PGP signature

Re: Handling of removed packages

[Lucas Nussbaum]

On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.
> 
> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category. So, has anyone a good idea
> solving this problem, without needing to keepr masses of status/diff/bla
> files around?

I usually run 'apt-show-versions | grep -v uptodate' to find them. The
remaining list is short enough to be analyzed manually.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Handling of removed packages

[Olivier Berger]

Le jeudi 29 mai 2008 à 13:24 +0200, Marc 'HE' Brockschmidt a écrit :
> Heya,
> 
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.
> 

Just for the records, there's a RSS feed about these :
http://ftp-master.debian.org/~joerg/removals/removals.rss

My 2 cents,

Best regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]> (*NEW ADDRESS*)
http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), 
Evry



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

Re: Handling of removed packages

[Frans Pop]

/me seems to remember a fairly recent discussion about this...
Right: http://lists.debian.org/debian-devel/2008/03/msg00354.html

Marc 'HE' Brockschmidt wrote:
> Our current package management doesn't handle this case at all, so we

That is not entirely true: aptitude (and also dselect) does clearly display 
obsolete and locally built packages in a separate category.
IMHO is any package management _frontend_ that does not do that in some way 
(category, color, flag, ...) buggy [1]. Preferably they should also offer 
some easily accessible help (especially graphical frontends).

Also, the Release Notes pay quite a lot of attention to this issue:
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-obsolete

And there are special tools to find obsolete packages (see link above).

What is true is that the package management _command line tools_ do not 
display any info about such packages.

> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category.

This would for me be unacceptable as it interferes too much with normal 
work.

What could be an option is to have apt and aptitude display the number of 
such packages in their summaries, preferably with an apt.conf option to 
turn that off for people who do check for such packages by other means.

Cheers,
FJP

[1] Maybe we should define a minimum set of features a package management 
_frontend_ must have before it may advertise itself as no longer alpha or 
beta quality?


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

Re: Handling of removed packages

[Stefano Zacchiroli]

On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> The probably easiest way would be to make apt whine on all packages
> that are not available in any version at one of the locations
> specified in sources.list. This trivial solution sucks, because
> locally created packages [1] also fall in this category.

Thinking at why this solutions sucks (it does), it occurred to me that
the reason is we don't have a ready to use easy way to let our users
install packages "properly", that is: only via entries in sources.list.
This is way they^W are using "dpkg -i".

So, instead of looking for an alternative twisted solution, why we don't
fix this problem?

It looks like it would be enough to:

- add a pre-defined entry in the legacy /etc/apt/sources.list pointing
  to file:///some/where/

- (optional) provide a trivial helper script which takes as input a set
  of .deb or .dsc and installs them in /some/where/, invoking
  dpkg-scan{package,source}s as needed (getting

- (even more optional) wrap into a single command the above + an
  invocation of apt-get to install the just installed package(s)

I'm convinced that using apt entries is the way to go for installing
local packages, but out of the box it is just not convenient enough to
do that.

Comments?

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Handling of removed packages

[Marc 'HE' Brockschmidt]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:
>> For some time now, I have been thinking about the problem of packages
>> which are removed from the archive at some point, without an (enforced)
>> transition to a new package name. Users of such packages keep them
>> around, usually never noticing the fact that no security (or other)
>> support is available anymore.
>> 
>> Our current package management doesn't handle this case at all, so we
>> might need to fix this - we just need to decide how. The probably
>> easiest way would be to make apt whine on all packages that are not
>> available in any version at one of the locations specified in
>> sources.list. This trivial solution sucks, because locally created
>> packages [1] also fall in this category. So, has anyone a good idea
>> solving this problem, without needing to keepr masses of status/diff/bla
>> files around?
> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
> remaining list is short enough to be analyzed manually.

I don't think normal users do that - and users shouldn't expect to
install Priority: optional packages to get a list of things that are not
supported anymore by their distribution.

Marc
-- 
BOFH #244:
Your cat tried to eat the mouse.


pgpRV8B2DJ08z.pgp
Description: PGP signature

Re: Handling of removed packages

[Kai Wasserbäch]

Hello,
Marc 'HE' Brockschmidt schrieb:
> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.

I have somewhat of a deja-vù here with that thread. When I remember correctly
just about the beginning of this year there was a discussion about how to
find/remove/manage obsolete packages either here on -devel or on -mentors. The
aptitude-way Frans pointed out was mentioned there too (maybe by Frans, I can't
recall). So the solution then was "the user must check aptitudes obsolete
category". And for me that is enough, though a automatic notification by
aptitude, when a package is added to that category would be nice.

Kind regards,
Kai

P.S.: This e-mail is just a "reminder", that this was already discussed, but I
have right now no time to search the archives. But eventually it helps to avoid
reiterating all pros and cons.



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: [EMAIL PROTECTED]
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: Handling of removed packages

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/08 08:01, Marc 'HE' Brockschmidt wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
>> On 29/05/08 at 13:24 +0200, Marc 'HE' Brockschmidt wrote:
>>> For some time now, I have been thinking about the problem of packages
>>> which are removed from the archive at some point, without an (enforced)
>>> transition to a new package name. Users of such packages keep them
>>> around, usually never noticing the fact that no security (or other)
>>> support is available anymore.
>>>
>>> Our current package management doesn't handle this case at all, so we
>>> might need to fix this - we just need to decide how. The probably
>>> easiest way would be to make apt whine on all packages that are not
>>> available in any version at one of the locations specified in
>>> sources.list. This trivial solution sucks, because locally created
>>> packages [1] also fall in this category. So, has anyone a good idea
>>> solving this problem, without needing to keepr masses of status/diff/bla
>>> files around?
>> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
>> remaining list is short enough to be analyzed manually.
> 
> I don't think normal users do that - and users shouldn't expect to
> install Priority: optional packages to get a list of things that are not
> supported anymore by their distribution.

Why not?  IOW, why shouldn't "normal users" be expected to expend a
little effort to maintain their system?

- --
Ron Johnson, Jr.
Jefferson LA  USA

"I must acknowledge, once and for all, that the purpose of
diplomacy is to prolong a crisis.", Mr. Spock
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPq0ZS9HxQb37XmcRAuN5AKCAzmedJn+wnvFEsUuBwHqbKq71+gCgvZCU
lvZEWU+UH7B/R0hwsVDGjM8=
=tWcw
-END PGP SIGNATURE-


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

Re: Handling of removed packages

[James Vega]

On Thu, May 29, 2008 at 02:40:07PM +0200, Kai Wasserbäch wrote:
> And for me that is enough, though a automatic notification by
> aptitude, when a package is added to that category would be nice.

As of version 0.4.11, this does happen.  From the NEWS file:

  * Command-line updates in aptitude will now list packages that are
newly obsolete.  This doesn't work when a source is removed and
all its packages become obsolete, for technical reasons.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Handling of removed packages

[Marc 'HE' Brockschmidt]

Ron Johnson <[EMAIL PROTECTED]> writes:
> On 05/29/08 08:01, Marc 'HE' Brockschmidt wrote:
>> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
>>> I usually run 'apt-show-versions | grep -v uptodate' to find them. The
>>> remaining list is short enough to be analyzed manually.
>> I don't think normal users do that - and users shouldn't expect to
>> install Priority: optional packages to get a list of things that are not
>> supported anymore by their distribution.
> Why not?  IOW, why shouldn't "normal users" be expected to expend a
> little effort to maintain their system?

Because this task can easily be automated. Forcing people to do things
manually that should be done by the package management sucks.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
35: Hacker
   Randal Schwartz (nach Intel)


pgpZECBscJT1G.pgp
Description: PGP signature

Re: funny outputs of ssh-vulnkey

[Atsuhito Kohda]

Hi all,

On Thu, 29 May 2008 12:40:37 +0200, "Francesco P. Lovergine" wrote:

> On Thu, May 29, 2008 at 03:32:27PM +0800, Paul Wise wrote:
> > The -a option attempts to scan all keys on the machine, you need to
> > run it as root if you want to check every key that the script knows
> > about.
> 
> I would add that on remote NFS directories root could have not
> privileges to read such files, so those 'funny' outputs are
> perfectly justified.

So this behavior is intentional, and ssh-vulnkey searches
keys more thoroughly than previous versions if I understand 
correctly.

In my case, there is no directory /var/spool/lpd/.ssh
so, IMHO, an expected message would be something like
"there is no such file or directory".

Regards,  2008-5-29(Thu)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

Re: Re: Mouse configuration during installation needs improvement

[Stephen Powell]

> With current kernels, if you use /dev/input/mice,
the
> port can be shared
> by gpm and X at the same time, and all mice you
connect
> (no matter what)
> show up in that device.

Thanks for the update on mouse sharing in newer
kernels.  I didn't realize that this support had been
added.  That does take away part of my supporting
argument for configuring X to use gpm.

> Of course PS/2 mice can not be connected while
> the system is on, since the hardware simply is not
> designed for that ...

I realize that PS/2 mice were not intended to be hot
swapped, but "stuff happens".  Sometimes the connector
is loose and falls out, sometimes a mischievous
co-worker unplugs it as a practical joke, sometimes
the mouse fails, sometimes someone trips over the
cord, sometimes the dog chews on it, sometimes an
inquisitive toddler unplugs it, etc.  Being able to
recover from these things without requiring a reboot
(or at least restarting the X server) is a nice
feature, one that gpm provides.

> gpm also leads to a number of complications for some
> users, as seen in the BTS.

Well, as Scotty of Star Trek fame says, "The more they
overtink the plumbing, the easier it is to stop up the
drain."  (Star Trek III: The Search for Spock)  But
then again, you could make that argument for the new
kernel support for mouse sharing too.  Yes, adding
another layer of software also adds another thing that
can go wrong.  The key is to make the benefits greater
than the cost.  I can only say that I have used gpm on
several different machines under several different
releases of Linux, and I have never had a bit of
trouble with it.  In some cases I seem to remember it
allowing the mouse to work when X couldn't drive it
directly (the "fups2" protocol came to the rescue). 
And it has saved my hindquarters when the mouse got
unplugged somehow.

> Given most people don't use the console ever,
> installing a service that
> is only for console use by default is simply wrong.

I'm not sure how one would know that most people don't
use the console.  I, for one, use it a lot.  But even
it it's true, I don't see why a device driver for a
device that is present on the system shouldn't be
installed.  Should you not install serial port support
because most people don't use the serial port?  It
won't HARM people who DON'T use the console, will it? 
We're talking about basic hardware support here,
something that many applications can use -- not an
application.  Please reconsider.



  


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

Re: Mouse configuration during installation needs improvement

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/08 09:35, Stephen Powell wrote:
[snip]
> 
>> Given most people don't use the console ever,
>> installing a service that
>> is only for console use by default is simply wrong.
> 
> I'm not sure how one would know that most people don't
> use the console.  I, for one, use it a lot.  But even

Amen.  This is Debian, not Ubuntu.

- --
Ron Johnson, Jr.
Jefferson LA  USA

"I must acknowledge, once and for all, that the purpose of
diplomacy is to prolong a crisis.", Mr. Spock
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPslcS9HxQb37XmcRAsuYAKCeyvicHUjRnFrLMUjAptBEWAGVFQCbB08Y
SXKM/1VgwXSniUZUGXddY0U=
=WUBA
-END PGP SIGNATURE-


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

Re: Re: Mouse configuration during installation needs improvement

[Julien Cristau]

On Thu, May 29, 2008 at 07:35:20 -0700, Stephen Powell wrote:

> I realize that PS/2 mice were not intended to be hot
> swapped, but "stuff happens".  Sometimes the connector
> is loose and falls out, sometimes a mischievous
> co-worker unplugs it as a practical joke, sometimes
> the mouse fails, sometimes someone trips over the
> cord, sometimes the dog chews on it, sometimes an
> inquisitive toddler unplugs it, etc.  Being able to
> recover from these things without requiring a reboot
> (or at least restarting the X server) is a nice
> feature, one that gpm provides.
> 
If X listens to /dev/input/mice, it doesn't care that you unplugged your
mouse and plugged it again, so I'm not sure what you think gpm provides
here.

Cheers,
Julien


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

Re: Handling of removed packages

[Frans Pop]

James Vega wrote:
> As of version 0.4.11, this does happen.  From the NEWS file:
>   * Command-line updates in aptitude will now list packages that are
> newly obsolete.  This doesn't work when a source is removed and
> all its packages become obsolete, for technical reasons.

Hmm. New Debian release. User uses codenames in sources.list.

# sed -i "s/etch/lenny/" /etc/apt/sources.list
# aptitude update

Does this fit in the exception listed above? I would think yes and in that 
case the only use case we really care about would not be supported.
Maybe I'm reading that wrong though or is "source" defined at a higher level 
than I think it is.


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

Re: Handling of removed packages

[Adeodato Simó]

* Stefano Zacchiroli [Thu, 29 May 2008 14:18:35 +0200]:

> On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> > The probably easiest way would be to make apt whine on all packages
> > that are not available in any version at one of the locations
> > specified in sources.list. This trivial solution sucks, because
> > locally created packages [1] also fall in this category.

> Thinking at why this solutions sucks (it does), it occurred to me that
[snip bit about local packages management]

(In case it isn't obvious, even with dropping local packages from this
category, this solution would still suck, because the admin or user may
want to keep those packages installed, without having to see apt whine
at every invocation.)

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
-- Oscar Hammerstein II


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

Re: Mouse configuration during installation needs improvement

[Frans Pop]

Ron Johnson wrote:
> On 05/29/08 09:35, Stephen Powell wrote:
>> I'm not sure how one would know that most people don't
>> use the console.  I, for one, use it a lot.  But even

I work mainly in consoles too but I have no use at all for gpm as my 
consoles are normally all in a graphical environment (KDE's konsole, either 
local or ssh sessions).

> Amen.  This is Debian, not Ubuntu.

Correct. Which means we have cluefull users who know how to run 'apt-get 
install gpm' if they are heavy VT users. :-D

Cheers,
FJP


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

Re: Handling of removed packages

[Steve Greenland]

On 29-May-08, 07:07 (CDT), Frans Pop <[EMAIL PROTECTED]> wrote: 
> Marc 'HE' Brockschmidt wrote:
> > Our current package management doesn't handle this case at all, so we
> 
> That is not entirely true: aptitude (and also dselect) does clearly display 
> obsolete and locally built packages in a separate category.

Parsing error, I think. 

Aptitude shows a group of "obsolete and locally created packages".
However, it doesn't distinguish between them, as far as I can tell,
which is what Marc (and I) would like.

Steve

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


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

37.5% boot time reduction in Lenny is possible (recipe)

[Petter Reinholdtsen]

Here is a quick report on how I was able to speed up the boot in Lenny
by using the tools available already.  I was able to reduce the boot
time as reported by bootchart from 48 to 30 seconds (37.5%).  I post
it here to make more Debian users aware of the possibilities.

This test was done on a freshly bought Thinkpad X installed with the
Desktop task in Lenny.  I started by installing bootchart and doing a
baseline benchmark to see how much time the default boot used.
Bootchart reported 48 seconds.

Next, I went through these steps to speed up the boot:

 (1) Installed dash, and ran 'dpkg-reconfigure dash' to enable it as
 /bin/sh.

 (2) Installed readahead, and touched /etc/readahead/profile-once to
 get it to profile the boot on the next boot.

 (3) Installed insserv, and ran 'dpkg-reconfigure insserv' to enable
 dependency based boot sequencing and reorder the boot sequence.

 (4) Fixed the typo in /etc/init.d/rc reported in bug #481770 to make
 it possible to enable concurrent boot and shutdown.  Enabled
 concurrent boot and shutdown by doing

   echo CONCURRENCY=startpar >> /etc/default/rcS

 This one depend on dependency based boot being enabled.

 (5) Disabled init.d/hwclock* during boot after verifying that
 "UTC=yes" was active in /etc/default/rcS, and knowing that the
 kernel would set the clock from the BIOS clock during boot on
 this machine.  I disabled it by removing /etc/rcS.d/*hwclock*
 after verifying that there was still stop symlinks left in rc0.d
 and rc6.d.

After these steps were taken, I rebooted the machine once to do the
profile run for readahead, and then did a benchmark run to see the new
boot time.  It was down to 30 seconds, a 37.5% boot time reduction.  I
do not know which of these steps contributed to what amount of
reduction.  Did not have time to do that testing before I had to
return the laptop to its owner. :)

Another second would have been possible to shave off if I had upgraded
to the latest portmap package in unstable which drop a useless 1
second sleep during boot (patch in #412636).  It also give a problem
during shutdown due to #483102/#483172, so I do not recommend
upgrading portmap until those issues are fixed.

I am not quite sure what to do to reduce it even further.  Anyone got
any ideas?

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Mouse configuration during installation needs improvement

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/08 11:25, Frans Pop wrote:
> Ron Johnson wrote:
>> On 05/29/08 09:35, Stephen Powell wrote:
>>> I'm not sure how one would know that most people don't
>>> use the console.  I, for one, use it a lot.  But even
> 
> I work mainly in consoles too but I have no use at all for gpm as my 
> consoles are normally all in a graphical environment (KDE's konsole, either 
> local or ssh sessions).

?  The console is The Console, the keyboard and monitor directly
(or via a KVM switch) connected to the computer.

>> Amen.  This is Debian, not Ubuntu.
> 
> Correct. Which means we have cluefull users who know how to run 'apt-get 
> install gpm' if they are heavy VT users. :-D

Which I did many years ago.  But it would still make it easier for
us dual-use people, and not affect only-gooey users, if gpm were the
default.

- --
Ron Johnson, Jr.
Jefferson LA  USA

"I must acknowledge, once and for all, that the purpose of
diplomacy is to prolong a crisis.", Mr. Spock
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPuZHS9HxQb37XmcRAq3vAJ0YHX9Y/5issNu/EJn0e0l93iLOWgCg4x3l
os1HhbzIndBGN3JCXHaVn9I=
=kiRw
-END PGP SIGNATURE-


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

Re: Handling of removed packages

[John H. Robinson, IV]

Steve Greenland wrote:
> 
> Aptitude shows a group of "obsolete and locally created packages".
> However, it doesn't distinguish between them, as far as I can tell,
> which is what Marc (and I) would like.

There really is no current way to do this. Case in point: if you use
wget and dpkg -i to install a package, it will still be in the Debian
Packages and thusly be tracked by the front ends.

If you create it locally, or via a -src or -installer, then it is the
same as the above but gets obsoleted.  ie: installed by hand, no record
of the package in Packages.

The solution to this that I see is a database similar to Packages, that
lists the package names along with 1) the last released version, 2)
all versions released, or 3) (my preferred) all versions released in the
last release made (ie: all versions in Sarge)

This way the front-ends can compare the installed version to the one(s)
listed in Obsoletes, and if there is a match, warn the user.


This allows the front-ends to ignore locally installed packages, and
those Obsolete packages that have been locally re-built.

It also forces yet another file that has to be downloaded by the back
ends, and parsed by the front ends.

I am willing to work on formats and debugging. I don't really want to
mess with apt* internals.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: 37.5% boot time reduction in Lenny is possible (recipe)

[Henrique de Moraes Holschuh]

On Thu, 29 May 2008, Petter Reinholdtsen wrote:
> I am not quite sure what to do to reduce it even further.  Anyone got
> any ideas?

Yes, but for the kernel.  You want to reduce the time to /sbin/init
being run by removing anything you don't want or need, and you want to
have the udev coldplug run as fast as possible.   And if you can do away
with slowpoke stuff like initrd and driver firmware loading in the
critical path, do so.

Remember that module loading is serialized, and also that way too much
stuff will try to autoload nowadays (the rule in kernel-land is to
provide autoload information to EVERY module you can).

So you might want to look at the udev coldplug pass...

-- 
  "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


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

Re: Mouse configuration during installation needs improvement

[Lennart Sorensen]

On Thu, May 29, 2008 at 08:16:28AM +1000, Ben Finney wrote:
> Where is your data for this assertion?

The number of people that have no idea how to get to the console from X.

Personally I hate dealing with machines that don't have gpm installed,
but I don't want to bloat the base install either.

> This argument would also see the removal of 'login', since that's not
> needed by your putative majority of people who don't log in over
> text-only interfaces.

The default system does not have X.  Not having login prevents you from
working.  Not having gpm is at worst slightly inconvinient.

> This argument fails for the same reason: just because *few* people use
> it is not sufficient reason to drop it from the install. If you don't
> want 'gpm' installed, you need a different argument.

Don't install stuff that is non essential.  gpm certainly is not
essential, so don't install it.  login is essential, so do install it.

-- 
Len Sorensen


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

Re: Re: Mouse configuration during installation needs improvement

[Lennart Sorensen]

On Thu, May 29, 2008 at 07:35:20AM -0700, Stephen Powell wrote:
> Thanks for the update on mouse sharing in newer
> kernels.  I didn't realize that this support had been
> added.  That does take away part of my supporting
> argument for configuring X to use gpm.

It was a very nice improvement.

> I realize that PS/2 mice were not intended to be hot
> swapped, but "stuff happens".  Sometimes the connector
> is loose and falls out, sometimes a mischievous
> co-worker unplugs it as a practical joke, sometimes
> the mouse fails, sometimes someone trips over the
> cord, sometimes the dog chews on it, sometimes an
> inquisitive toddler unplugs it, etc.  Being able to
> recover from these things without requiring a reboot
> (or at least restarting the X server) is a nice
> feature, one that gpm provides.

For a PS/2 port, there is NOTHING software can do to recover.  The
hardware on the majority of PCs requires a reset for the PS/2 port to
come back to life.

gpm is of no help here.  X does mouse handling just as well as gpm does.

> Well, as Scotty of Star Trek fame says, "The more they
> overtink the plumbing, the easier it is to stop up the
> drain."  (Star Trek III: The Search for Spock)  But
> then again, you could make that argument for the new
> kernel support for mouse sharing too.  Yes, adding
> another layer of software also adds another thing that
> can go wrong.  The key is to make the benefits greater
> than the cost.  I can only say that I have used gpm on
> several different machines under several different
> releases of Linux, and I have never had a bit of
> trouble with it.  In some cases I seem to remember it
> allowing the mouse to work when X couldn't drive it
> directly (the "fups2" protocol came to the rescue). 
> And it has saved my hindquarters when the mouse got
> unplugged somehow.

/dev/input/mice actually has the kernel convert all known mouse formats
to one protocol as far as I know, so all those mouse protocol issues are
gone too.

> I'm not sure how one would know that most people don't
> use the console.  I, for one, use it a lot.  But even
> it it's true, I don't see why a device driver for a
> device that is present on the system shouldn't be
> installed.  Should you not install serial port support
> because most people don't use the serial port?  It
> won't HARM people who DON'T use the console, will it? 
> We're talking about basic hardware support here,
> something that many applications can use -- not an
> application.  Please reconsider.

gpm is NOT a driver.  It is a tool that can use the mouse interface in
the kernel and do useful things with the terminal.  Other programs could
do the same if they wanted to.  it is not a driver though.

-- 
Len Sorensen


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

Re: debian.ch: board changes

[Daniel Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

martin f krafft wrote:
> For reasons known to the board, Daniel Baumann stepped down from his
> position as treasurer

Just for the records and to avoid speculations: The reason is simply
lack of time.

- --
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPvuW+C5cwEsrK54RAqb9AJ4kr5ei2FqmnwTcIwWZCuL09KF6xQCgjo0X
0MHUTdqjuR0xAVgFHE0DX14=
=lsrb
-END PGP SIGNATURE-


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

Re: Mouse configuration during installation needs improvement

[Lennart Sorensen]

On Thu, May 29, 2008 at 12:22:15PM -0500, Ron Johnson wrote:
> Which I did many years ago.  But it would still make it easier for
> us dual-use people, and not affect only-gooey users, if gpm were the
> default.

I would like ssh installed by default before gpm, but I don't think we
need to go back to doing that either.  The admin installing the machine
should decide what to add to the base system.

For that matter, gpm is only useful on machines with a mouse, some
machines just have serial consoles.  They have great use of login and
getty, and such, but gpm and X just waste space.

-- 
Len Sorensen


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

Re: Generated changes and patch systems

[Russ Allbery]

Simon McVittie <[EMAIL PROTECTED]> writes:

> Here's how gtk-doc *used to* work:
>
> * gtk-doc parses source code and writes out skeletal tmpl/*.sgml
> * svn ci -m 'initial version of gtkdoc templates' tmpl
> * upstream doc author inserts content into tmpl/*.sgml
> * svn ci -m 'wrote some docs' tmpl
> * gtk-doc parses source code (to pick up any new functions) + tmpl/*.sgml,
>   and merges them
> * svn ci -m 'yay gtkdoc' tmpl
> * ...
>
> This is, as you've noticed, insane. Sane upstreams now write all the
> content for the documentation in /** */ comments in the source code, so
> the tmpl/*.sgml are purely generated and can safely be omitted from
> source-code control. (I have no opinion on whether your upstream is sane
> or not - please check.)
>
> However, the "no rule to make tmpl/*.sgml" issue still exists, as a
> relic of the old build process.

Thank you for the explanation!  This now makes much more sense.

Sounds to me like the first thing to try would be to just regenerate all
of the tmpl/*.sgml files via gtk-doc and delete them in the clean rule and
see if that works properly for this project.  That's what I'd do, at
least; that ensures a clean build without putting artifacts in the
*.diff.gz.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Handling of removed packages

[Franklin PIAT]

CCing debian-dpkg for obvious reasons.

On Thu, 2008-05-29 at 14:18 +0200, Stefano Zacchiroli wrote:
> On Thu, May 29, 2008 at 01:24:59PM +0200, Marc 'HE' Brockschmidt wrote:
> > The probably easiest way would be to make apt whine on all packages
> > that are not available in any version at one of the locations
> > specified in sources.list. This trivial solution sucks, because
> > locally created packages [1] also fall in this category.
> 
> Thinking at why this solutions sucks (it does), it occurred to me that
> the reason is we don't have a ready to use easy way to let our users
> install packages "properly", that is: only via entries in sources.list.
> This is way they^W are using "dpkg -i".

Using `dpkg -i` really is insane as far as security is concerned :
people install Acrobat, Opera, Flashplayer, w32codecs and others
manually, then simply forget about it.

I know that's exactly what people do in some proprietary operating
system but still, that's insane.

I suggest to modify dpkg so it refuse to install package, unless the
option "--insecure" is specified. Such option's manpage description
would be :
> dpkg --install --insecure package_file...
> The option --insecure is now mandatory to install a ".deb" package.
> 
> Installing a ".deb" file manually is considered a bad practice (i.e
> insecure), because the package wouldn't be updated when the maintainer
> release a security update.
> 
> Instead of downloading and installing a .deb file, you should declare
> it's apt repository. This is done by adding the package's repository
> to /etc/apt/sources.list or /etc/apt/sources.list.d/. See
> sources.list(5).

* This option would be an effective solution to educate new users.
* For the same reason, we should remove gdebi's "Install" button.

I suggest Proposed manpage improvement for this option :

Franklin



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

libweather-com-perl useless in Etch

[Christoph Haas]

Fellow earthicans,

I'm maintaining the libweather-com-perl package. Apparently 
(http://rt.cpan.org/Public/Bug/Display.html?id=35681) the package stopped 
working after May 6th 2008. I patched the package so it works again and 
uploaded it into unstable. Just wondering what to do with Etch because the 
version in Etch is effectively not working any more. Is this a matter for 
a security update? I didn't have to deal with such an issue before. Hints 
welcome.

Cheers
 Christoph
-- 
When you do things right people won't be sure you've done anything at all.


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

Re: Handling of removed packages

[Mike Bird]

On Thu May 29 2008 12:37:28 Franklin PIAT wrote:
> Using `dpkg -i` really is insane as far as security is concerned :

The above statement is false.

Many people do extra levels of testing before
rolling out updates with "dpkg -i".  With "apt-get"
you never know when the package lists will be updated.

--Mike Bird


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

Disruptive changes in dhelp

[Esteban Manchado Velázquez]

Hey there,

Some time ago I made disruptive changes to dhelp_parse, part of dhelp. I
assumed that the only one calling it was doc-base (in particular,
install-docs), so I synced the changes with some doc-base release and just
made them.

Now some bug (#482807) was assigned to dhelp, and then I realised that
there might be other people having calls to dhelp_parse in the postinst or
whatever. To make things worse, I forgot to update the manpage, so it still
documented the old behaviour/interface. I just uploaded a new version of
dhelp, fixing that.

So, if you are calling dhelp_parse in your postinst, please use doc-base
instead (if you're not already, and you should), don't call dhelp_parse
yourself. A simple call to install-docs should be enough to make dhelp aware
of your documentation.

Thanks, and sorry for the inconvenience.

-- 
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!


signature.asc
Description: Digital signature

Re: Handling of removed packages

[Wolf Wiegand]

Hi,

Marc 'HE' Brockschmidt wrote:

> For some time now, I have been thinking about the problem of packages
> which are removed from the archive at some point, without an (enforced)
> transition to a new package name. Users of such packages keep them
> around, usually never noticing the fact that no security (or other)
> support is available anymore.

Maybe it should be mandatory to always have a transition package for
packages which are being removed from the archives? For example, when
package X_0.1 is to be removed from the archive, there has to be a
transition to a package X-obsoleted_0.1 (which is in fact the same as
X_0.1).

As addition, some mean of telling the user "There are $NUM installed 
packages on your system that seem to be abandoned: X-obsoleted" could
be established (either in apt, aptitude, or apt-listchanges), with
the option to turn off this message (I wouldn't want to have to read
this every day).

> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category. 

IMHO, packages that are not (and never have been) available from the
Debian archives should be left alone from any 'detect unsupported
packages'-mechanisms. The user decided to install these packages, so
he/she will have to deal with keeping them up to date or uninstall them
once they are not maintained anymore.

Cheers,

Wolf

-- 
I hope that when I die, people say about me, 'Boy, that guy sure owed me
a lot of money.' (Jack Handey)


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

Re: Handling of removed packages

[Raphael Geissert]

Marc 'HE' Brockschmidt wrote:
> 
> Our current package management doesn't handle this case at all, so we
> might need to fix this - we just need to decide how. The probably
> easiest way would be to make apt whine on all packages that are not
> available in any version at one of the locations specified in
> sources.list. This trivial solution sucks, because locally created
> packages [1] also fall in this category. So, has anyone a good idea
> solving this problem, without needing to keepr masses of status/diff/bla
> files around?

Not perfect, but one of the solutions I've found is a script I wrote:

> $ notAptable --help
> notAptable [--version] [--help] [-s/var/lib/dpkg/status] 
[-aptf/path/to/aptavail/equiv/file]  [-aptx'apt-cache dumpavail'] 
[-ipackagename]
> List packages which are installed on the system  but are not known by apt.
> Options:
> -s Path to file to use when grepping for installed packages
> -aptf Path to file to use when grepping for the apt-able packages
> -aptx Same as above but instead of being a file the specified
command is executed
> -i Exclude a package that would otherwise be listed
> When not overriden by an option the default files/data is up to
grep-dctrl's defaults
> This script is said to report packages that were removed from the archive
> (except those listed in /home/raphael/.listNotAptable.ignore)
> 
> Copyright 2008 by Raphael Geissert <[EMAIL PROTECTED]>

> $ wc -l /home/raphael/.listNotAptable.ignore
> 19 /home/raphael/.listNotAptable.ignore

Running that script every now and then in a cronjob or after apt-get update
has resulted very helpful.

More info:
http://my.opera.com/atomo64/blog/2008/03/09/where-to-put-such-a-script

> 
> Marc
> 
> Footnotes:
> [1]  Such as kernel packages, binary kernel modules built from sources
>  available in the archive, local configuration packages, ...

Cheers,
Raphael



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

Re: Handling of removed packages

[Franklin PIAT]

Hello,

On Thu, 2008-05-29 at 14:40 +0200, Kai Wasserbäch wrote:
> Marc 'HE' Brockschmidt schrieb:
> > For some time now, I have been thinking about the problem of packages
> > which are removed from the archive at some point, without an (enforced)
> > transition to a new package name. Users of such packages keep them
> > around, usually never noticing the fact that no security (or other)
> > support is available anymore.
> 
> I have somewhat of a deja-vù here with that thread.
> [..] So the solution then was "the user must check aptitudes obsolete
> category". 

We might assume that Debian is only used in managed environment, where
system admins actually RTFM.

But if we aim world domination (i.e. reach true end-users), we can't
expect system-owners to actually read the fine manuals. (It's a fact,
right ?).

I wouldn't be comfortable telling my [brother|sister|friend], who's
system would have been compromised due to an obsolete packages, that
it's their fault because they should have checked "obsolete" package, as
explained in the fine manual...

Also, any pop-up/warning based solution will merely lead people to
ignore or disable them.


PROPOSAL : Remove obsolete packages on upgrade :

If we remove a package in a release, there is probably good reason for
that (!). So I tend to think that we should automatically remove the
package during systems upgrades (by default).

One could create dummy transition packages that `provides` the removed
package :

 - It could be named like "flashplugin-is-deprecated-in-lenny".
 - It's description should have appropriate comments (why was the
   package removed).
 - It should suggest replacements.
 - Such transition package would only be created for package that were
   actually in the previous release (i.e not for package that appeared
   and disappeared during a given `testing` cycle).
 - Those packages might have their own section.

Pros :
 - The user could still "Hold" the old package to prevent removal (which
   state properly describe the package status).
 - The user could still use another [unofficial] apt source, that
   actually provide the package, so the package isn't removed.
 - Users using lenny that search for a package removed since etch
   would actually find it (and know it is in "removed from archive") !
 - If a package moves from main to contrib or non-free, we could use the
   same transition, so one would know about it
   (package named like "foobar-is-now-in-non-free").
 - Using package-dependencies means that it would "just work" with any
   existing tool.

Cons : 
 - "One" has to create, maintain (and remove) those packages !
 - It uses space in the mirrors.

I gave a try to automatically build such transition package. Currently
that about 460 package (we could merge some of them, like libapache* ).

The source's control would look like :
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/debian/control
Here's the script (very ugly currently).
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/refresh.sh

Any comment ?

Franklin


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

Re: Mouse configuration during installation needs improvement

[Peter Samuelson]

[Stephen Powell]
> I realize that PS/2 mice were not intended to be hot swapped, but
> "stuff happens".

The kernel 'psmouse' module, and the 'serio' layer that actually talks
to the i8042, actually have much more thorough and robust support for
PS/2 hotplugging than gpm ever did.  The kernel even intelligently
handles PS/2 multiplexing, as seen on many laptops where the trackpad
shares the chip with an external port.  (gpm treats that case as a
single mouse, programmed for some protocol they have in common.)

As gpm co-maintainer I will say that the gpm repeater seems to be
entirely obsolete for all use cases.  (Unless your kernel is pre-2.6,
but Debian no longer supports that.)
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: libweather-com-perl useless in Etch

[Peter Samuelson]

[Christoph Haas]
> the package stopped working after May 6th 2008. I patched the package
> so it works again and uploaded it into unstable.

This is why we have volatile - see http://www.debian.org/volatile/.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: Handling of removed packages

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> One could create dummy transition packages that `provides` the removed
> package :

or conflict with them in a "suported-lenny" package.

But I think obsolete packages can be mail-warned in security reports just
like vrms or something. "PAckages needing patches or beeing unsupported".

Gruss
Bernd


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

Re: How to handle Debian patches

[Raphael Geissert]

Stefano Zacchiroli wrote:

> On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote:
>> > You can imagine harvesting alioth.d.o and extracting all debian/control
>> > stored in whatever $VCS you find there, but you can't be sure if this
>> > is the currently used $VCS, if there are other versions of the package
>> > versioned elsewhere, ... Plenty of room for false positives.  Even
>> Why debian/control? debian/changelog provides the source package name and
>> the latest version. Matching data with the latest Sources of unstable
>> should do the trick to know what is up to date in the $VCS, and what
>> isn't.
> 
> Uhm, interesting, you mean testing if the changelog version is greater
> or equal than the latest in unstable, right? This still leaves the room
> to the very same package version, greater than latest unstable, which
> has been moved from one VCS to the other before being uploaded, but I
> guess it is a pretty remote case.

I believe the number of false positives will be very very small, and if one
takes a look at what would be done there's a chance to spot them.

> 
> Cheers.
> 

Cheers,
Raphael


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

Use origin (Handling of removed packages)

[Filipus Klutiero]

Yes, this could be solved by having APT (probably) store the origin of the 
package when installing. Then, for example, if an APT front-end realizes 
while updating package index files that a package coming from Debian is not 
available anymore from Debian sources, the user could be prompted.


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

Re: Handling of removed packages

[Russ Allbery]

Mike Bird <[EMAIL PROTECTED]> writes:

> Many people do extra levels of testing before
> rolling out updates with "dpkg -i".  With "apt-get"
> you never know when the package lists will be updated.

Uh... the package lists are updated when you run apt-get update.  I must
be missing something.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Handling of removed packages

[Guillem Jover]

Hi,

On Thu, 2008-05-29 at 21:37:28 +0200, Franklin PIAT wrote:
> I suggest to modify dpkg so it refuse to install package, unless the
> option "--insecure" is specified. Such option's manpage description
> would be :

That'd be mostly just annoying for no actual benefit. It would break
existing software using 'dpkg -i', and people would end up adding that
option to the config file.

> > dpkg --install --insecure package_file...
> > The option --insecure is now mandatory to install a ".deb" package.
> > 
> > Installing a ".deb" file manually is considered a bad practice (i.e
> > insecure), because the package wouldn't be updated when the maintainer
> > release a security update.

This is not true if the package comes from the repo you've fetched it
from.

> > Instead of downloading and installing a .deb file, you should declare
> > it's apt repository. This is done by adding the package's repository
> > to /etc/apt/sources.list or /etc/apt/sources.list.d/. See
> > sources.list(5).

There's few other ways to upgrade a system than with apt.

> * This option would be an effective solution to educate new users.
> * For the same reason, we should remove gdebi's "Install" button.

I don't think this kind of punishment would educate any users. So I
don't see this being implemented in dpkg, sorry.

regards,
guillem


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

Re: Handling of removed packages

[Mike Bird]

On Thu May 29 2008 16:58:41 Russ Allbery wrote:
> Mike Bird <[EMAIL PROTECTED]> writes:
> > Many people do extra levels of testing before
> > rolling out updates with "dpkg -i".  With "apt-get"
> > you never know when the package lists will be updated.
>
> Uh... the package lists are updated when you run apt-get update.  I must
> be missing something.

ssh test-box
 apt-get update
 apt-get upgrade
 tests
ssh live-server
 apt-get update
 ... sometimes gets a slightly different package list

The only time we use apt-get is as a convenience when testing different
package versions.

All packages on live servers and workstations are installed with
"dpkg -i" to ensure we're using a tested combination.  We could
manually copy the package lists or "apt-get install foo=x.y.z"
but "dpkg -i" is more convenient.

--Mike Bird


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

Re: libweather-com-perl useless in Etch

[Paul Wise]

On Fri, May 30, 2008 at 3:44 AM, Christoph Haas <[EMAIL PROTECTED]> wrote:

> I'm maintaining the libweather-com-perl package. Apparently
> (http://rt.cpan.org/Public/Bug/Display.html?id=35681) the package stopped
> working after May 6th 2008. I patched the package so it works again and
> uploaded it into unstable. Just wondering what to do with Etch because the
> version in Etch is effectively not working any more. Is this a matter for
> a security update? I didn't have to deal with such an issue before. Hints
> welcome.

http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-upload-stable

Since the fix seems to be a one-liner I'd hope that it would be
accepted into stable.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Work-needing packages report for May 30, 2008

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 440 (new: 18)
Total number of packages offered up for adoption: 106 (new: 11)
Total number of packages requested help for: 47 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   grepmail (#483247), orphaned 2 days ago
 Description: search mailboxes for mail matching an expression
 Installations reported by Popcon: 571

   intercal (#483256), orphaned 2 days ago
 Description: an INTERCAL de-obfuscator
 Installations reported by Popcon: 43

   jikes (#483065), orphaned 3 days ago
 Description: Fast Java compiler adhering to language and VM
   specifications
 Reverse Depends: coco-java jikes-classpath jikes-gij jikes-kaffe
   jikes-sablevm jikes-sun
 Installations reported by Popcon: 2965

   jikes-contrib (#483066), orphaned 3 days ago
 Description: Wrapper for jikes using Sun Java classes
 Installations reported by Popcon: 26

   krecordmydesktop (#482976), orphaned 3 days ago
 Description: kde frontend to recordmydesktop
 Installations reported by Popcon: 141

   libaal (#483026), orphaned 3 days ago
 Description: Reiser4's application abstraction library
 Reverse Depends: libreiser4-dev
 Installations reported by Popcon: 71

   libinstrudeo (#482977), orphaned 3 days ago
 Description: Export isd files to other formats
 Reverse Depends: isdexport libinstrudeo-dev screenkast
 Installations reported by Popcon: 85

   longrun (#483251), orphaned 2 days ago
 Description: Transmeta Crusoe LongRun control utility
 Installations reported by Popcon: 28

   procmeter3 (#483255), orphaned 2 days ago
 Description: graphical system status monitor
 Installations reported by Popcon: 294

   reiser4progs (#483027), orphaned 3 days ago
 Description: administration utilities for the Reiser4 filesystem
 Installations reported by Popcon: 521

   screenkast (#482978), orphaned 3 days ago
 Description: Record your activities on the screen
 Installations reported by Popcon: 77

   sitebar (#483011), orphaned 3 days ago
 Description: A web based bookmark manager written in PHP
 Installations reported by Popcon: 56

   sparkline-php (#483252), orphaned 2 days ago
 Description: A sparkline graphing library for php
 Installations reported by Popcon: 6

   sysnews (#483250), orphaned 2 days ago
 Description: display system news
 Installations reported by Popcon: 155

   tkdiff (#483362), orphaned yesterday
 Description: graphical side by side "diff" utility
 Reverse Depends: tkcvs
 Installations reported by Popcon: 1182

   tla (#483064), orphaned 3 days ago
 Description: GNU Arch revision control system
 Reverse Depends: arch-buildpackage arch2darcs archzoom git-arch
   libarch-perl svn-arch-mirror tla-buildpackage tla-load-dirs
   tla-tools xtla
 Installations reported by Popcon: 1116

   xaos (#483249), orphaned 2 days ago
 Description: real-time interactive fractal zoomer
 Reverse Depends: junior-math
 Installations reported by Popcon: 998

   znc (#483248), orphaned 2 days ago
 Description: an advanced IRC bouncer
 Installations reported by Popcon: 50

422 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   ddccontrol (#483479), offered yesterday
 Description: a program to control monitor parameters
 Reverse Depends: ddccontrol gddccontrol libddccontrol-dev
 Installations reported by Popcon: 368

   ddccontrol-db (#483480), offered yesterday
 Description: monitor database for ddccontrol
 Reverse Depends: ddccontrol
 Installations reported by Popcon: 373

   diald (#482953), offered 4 days ago
 Description: dial on demand daemon for PPP and SLIP
 Installations reported by Popcon: 40

   frotz (#483582), offered today
 Description: interpreter of Z-code story-files
 Installations reported by Popcon: 299

   mdk (#482633), offered 6 days ago
 Description: MIX Development Kit
 Installations reported by Popcon: 37

   nyquist (#483581), offered today
 Description: a language for music composition and sound synthesis
 Installations reported by Popcon: 84

   releaseforge (#483483), offered yesterday
 Description: alternative to SourceForge's File Release System (FRS)
 Installations reported by Popcon: 11

   universalindentgui (#483068), offered 3 days ago
 Description: GUI frontend for several code beautifiers
 Installations reported by Popcon: 62

Re: Handling of removed packages

[Franklin PIAT]

Hello,

Make sure I think dpkg is a great tool..

home:/root# echo $(grep -c "dpkg" .bash_history)/$(wc -l .bash_history)
40/502

On Fri, 2008-05-30 at 05:06 +0300, Guillem Jover wrote:
> On Thu, 2008-05-29 at 21:37:28 +0200, Franklin PIAT wrote:
> > I suggest to modify dpkg so it refuse to install package, unless the
> > option "--insecure" is specified. Such option's manpage description
> > would be :
> 
> That'd be mostly just annoying for no actual benefit. It would break
> existing software using 'dpkg -i'

Honestly, that's why I didn't file a bug to actually request it ;)

But I do think that individual .deb files shouldn't be distributed by
developers/vendors. Also, "dpkg -i" should not be over-advertised to
end-users (neither similar tools).

wiki.d.o has 72 pages with "dpkg -i".
google's `"dpkg -i" site:lists.debian.org/debian-user/` has 10900 hits
... That's bad.


Doing :

echo "deb http://foo.com/ stable main" > /etc/apt/sources.list.d/foo
aptitude update
aptitude install foo

Isn't more complex :

cd /tmp
wget http://foo.com/path/to/foo.deb
dpkg -i foo.deb

> > * This option would be an effective solution to educate new users.
> > * For the same reason, we should remove gdebi's "Install" button.
> 
> I don't think this kind of punishment would educate any users. So I
> don't see this being implemented in dpkg, sorry.

It isn't about punishing end-user. It's about doing something the right
way (i.e end-user shouldn't use "dpkg -i" at all)

Franklin


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