Re: hwcap supporting architectures?

[Falk Hueffner]

GOTO Masanori <[EMAIL PROTECTED]> schrieb am 13.01.05 02:01:11:

> At Tue, 11 Jan 2005 11:27:28 +0100,
> Falk Hueffner wrote:
> > Marcelo E. Magallon <[EMAIL PROTECTED]> wrote:
> > > IIRC, alpha does not define any hwcaps.
> > 
> > There's a patch for this, which works fine, but wasn't committed yet:
> > http://lists.debian.org/debian-glibc/2004/03/msg00143.html
> >
> > Sensible options are ev56 and ev67; ev5 is not particularly useful, since
> > it has the same instruction set as the baseline ev4, only different 
> > scheduling.
> > -mieee is default anyway on Debian's gcc.
> 
> Yes, we don't support it currently, but I think it should be available
> after sarge.
> 
> BTW, this patch does not enable HWCAP_IMPORTANT - so the answer of
> first question from Marcelo is: alpha does not support library HWCAP
> directory loading even if this patch is applied.

That's right. The reason is that the Alpha architecture doesn't have a set
of capabilities, from which each CPU version picks a random few, but rather
every CPU version is a proper superset of the preceding version. So I did
not use the orthogonal HWCAP model at all.

> If other libraries
> like mesa and libssl want to use /usr/lib/ev67 and so on, we may
> consider to add HWCAP_IMPORTANT. 

This should not be needed, since the library loader also looks in a directory
corresponding to the architecture name. The only problem with this
occurs when you have for example an ev56 library in lib/ev56, and a ev67
CPU. Then the loader looks in lib/ev67 and then falls back to lib. Since
glibc is very carefully undocumented in this area [1], I didn't want to try to
change this, but rather assumed one could add a symlink.

Falk

[1] _dl_important_hwcaps is a great text book example on how not to do
comments, if anybody ever needs one.



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

Re: Is debhelper build-essential?

[Eduard Bloch]

#include 
* Joerg Jaspert [Thu, Jan 13 2005, 08:29:19AM]:

> I think it should be b-e, but with a versioned dep thats high enough to
> get all those versioned dependencies away that are already existing.
> As we try sarge, a version-dep >= {sarge-version} is suggested.
> 
> (Not that all packages are really updated for that before sarge, but
> lets get b-e with such a thing in sarge IMO).

ACK, debhelper should be in b-e for Sarge if we wish to handle it like
other packages in build-essential nowadays.

For regular Sid environment it would change nothing/not much, as Scott
has already pointed out. For backporters, it will make some difference
but since the implicite rule "install at least build-essential package
from Stable" applies, it would become acceptable to remove debhelper
from Build-Depends entries after Sarge has been released.

"Professional" backporters know what to do anyway.

Regards,
Eduard.
-- 
For any stupid thing chosen at random, you'll find at least 5 people on
the Internet who thinks it's a good idea. -- Steve Langasek in debian-devel


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

Re: Proper way to remove a package from both sarge and sid

[Vincent Danjean]

Santiago Vila wrote:
On Wed, 12 Jan 2005, Frank Küster wrote:
 

Then this is a release critical bug in the newer package, ..da-dk. You
should file this bug and prevent the buggy version from entering
sarge. It is not sufficient to remove your old package from the archive,
because user will still have installed it and get in trouble. Instead, a
new revision of the ..da-dk package must be uploaded that has proper
Conflicts. 
   

Instead of that, I would upload a new version of mozilla-firefox-locale-da
which is empty and has a Depends: mozilla-firefox-locale-da-dk, i.e.
a dummy package. Put in section oldlibs and then deborphan
will tell you that you can remove it safely.
Then no conflict would be needed (well, a versioned one perhaps),
and there would not be so much hurry in removing the package, as you
will be helping users of the old package to install the new one.
 

No, it would not be enough. Some people can try to install the new 
-da-dk package with your old -da package already present. Even if people 
upgrade your package at the same time, there is no evidence that dpkg 
will upgrade the -da package before installing the -da-dk package.
A conflict/replace on -da in the new -da-dk package is the (only ?) good 
thing to do

Your dummy package is only useful to force users to switch to the new 
-da-dk package on upgrade. In this case, the conflict/replace in -da-dk 
should be versionned.

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

Bug#290257: ITP: tpg -- Toy Parser Generator - a parser generator for python

[Mike O'Connor]

Package: wnpp
Severity: wishlist


* Package name: tpg
  Version : 3.0.4
  Upstream Author : Christophe Delord <[EMAIL PROTECTED]>
* URL : http://christophe.delord.free.fr/en/tpg/
* License : GPL
  Description : Toy Parser Generator - a parser generator for python

 Toy Parser Generator is a lexical and syntactic parser generator for Python.
 This generator was born from a simple statement: YACC is to complex to use
 in simple cases (calculators, configuration files, small programming
 languages.languages.

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


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Javier Fernández-Sanguino Peña]

On Wed, Jan 12, 2005 at 10:51:16PM -0200, Gustavo Noronha Silva wrote:
> After reading your e-mail, I think that sounds like a sensible proposal.
> I'll wait for some input from the involved maintainers and do the
> change, if noone has a problem with it.

Quick and dirty hacki:

How about having this be configurable through something like 
/etc/gksu.conf and include a wrapper script to read it?
That would introduce a way (since gksu does not seem to have an 
alternative) for average users to have the default behaviour (which is a 
good idea) and for users that need this option to enable it per default.

The gtksu application could either read that or have a wrapper that (if 
that file contained and $OPTIONS):

/etc/gksu.conf
---
#!/bin/sh
# Uncomment this if using a  CJK environment
#OPTIONS="--default-grab"
---

And here's /usr/bin/gksu:

---
#!/bin/sh
program=/usr/bin/gksu-real
config=/etc/gtksu.conf
[ -r "$config" ] && . $config
if [ -x $program ] ; then
if [ -n "$OPTIONS" ]; then
exec $program $OPTIONS $*
else
exec $program $*
fi
else
echo "This script is a wrapper for $program but I can't find it on 
the system" >&2
exit 1
fi
---

Better solution:
- Have gksu source a /etc/gksu.conf file directly
- Have gksu obtain additional configuration from user's Xdefault or through 
the GNOME registry?

IMHO --disable-grab should _not_ be a default option, since it actually
prevents an eavesdropping attack (which can be a remote attack thanks to
X11's networking capabilities). However, there should be a way (and there
is none currently AFAIK) for users that need it to enable it either on a
per user or per system basis.

Notice that Osamu's proposal (having it as default) does not include a way 
for system admins/users to disable it if needed be.


The more Debian will be targeted to desktop environments the more you will
have desktop installations in which the user is also the administrator and
will be using gksu/gnome-sudo/similar stuff a lot. We want to prevent that
extended usage (whenever that happens) of "swithc to root" applications
from introducing new vulnerabilities^Wconcerns because of our insecure
default setup. 

I'm actually quite sympathetic for this kind of applications, since we 
should also strive to have the users avoid running an X environment as 
root user. But please, deploy them in the most secure way possible (or do 
not deploy them and introduce a false sense of security).

I understand that if the user is running malware there is nothing that
prevents the intruder from sidestepping this method and introduce a
different way to capture root's password, but at least you are making it (a
little bit) more difficult than just running an X keylogger.


Regards


Javier


signature.asc
Description: Digital signature

Re: Editing history... (about debian/changelog in experimental)

[Frank Küster]

Jay Berkenbilt <[EMAIL PROTECTED]> wrote:

> Policy section 4.4 states:
>
>Mistakes in changelogs are usually best rectified by making a new
>changelog entry rather than "rewriting history" by editing old
>changelog entries.
>
> This is the source of my habits on this point.  When I really think
> about it though, it seems much more useful for the latest changelog to
> contain an accurate history than for the old version to equal the new
> version minus new entries as I previously remarked.

I have filed bug #290270 about that, as a reminder for a later change.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#290276: RFA: alevt -- X11 Teletext/Videotext browser

[Andreas Metzler]

Package: wnpp
Severity: normal

I request an adopter for the alevt package. I've got rid of the
necessary hardware to use it. (TV is just not worth the tax/toll.)

alevt is very little work, and upstream is responsive.

-
The package description is:
 AleVT is an X11 program for browsing and searching Teletext/Videotext
 pages received by a compatible decoder (at the moment, bttv).
 .
 Features include:
 .
   * Multiple windows
   * Page cache
   * Regular expression searching
   * Built-in manual
 .
 Additional command line utilities can
 .
   * receive the time from Teletext/Videotext
   * capture pages and write them to disk
 .
 Teletext/Videotext is used by TV channels to transmit textual
 information pages (it's transmitted via non-visible scan lines).
 .
 Homepage: http://www.goron.de/~froese/
-
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


signature.asc
Description: Digital signature

Local Poker Invite

[Saul Rivera]

8283927310378278959
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===AVGMAIL-41E579455696==="

--===AVGMAIL-41E579455696===
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

=




This email i=
s to
inform you that you have been invited by a local poker player in your area=
 to
participate in the first ever Online Texas
Hold 'Em Poker Tour on Sunday nights.

 

To accept this honor and receive more information sim=
ply:

 


 Send an email to: mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]=

 Make sure the subject is: Ace


 

You will be contacted within 24 hours via email with =
more information.
It is an honor to receive an invite, so we hope to see you in the tour.

 

 

If you believe you ha=
ve
received this email in error, please reply with "No Thanks" in t=
he
subject line. We take all reports of spam very seriously and will ban thos=
e
that send it.





8283927310378278959--

--===AVGMAIL-41E579455696===
Content-Type: text/plain; x-avg=cert; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Description: "AVG certification"

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005

--===AVGMAIL-41E579455696===--


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Josselin Mouette]

Le mercredi 12 janvier 2005 à 22:51 -0200, Gustavo Noronha Silva a
écrit :
> > Can you make gksu's default behavior to be "gksu --disable-grub" ?
> 
> s/grub/grab/, FWIW
> 
> After reading your e-mail, I think that sounds like a sensible proposal.
> I'll wait for some input from the involved maintainers and do the
> change, if noone has a problem with it.

I'd like to avoid such things. This way, any X11 client attached to the
session can read the root password. That's true for the "su" in a
terminal too, though.

However, that's not the key point. If we want to avoid such things to
lock the session startup, why not register them with a very low
priority ? There could even be a delay of a few seconds before the
password window appears, in this case only.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: dselect and its help messages

[Domenico Andreoli]

On Wed, Jan 12, 2005 at 02:52:47PM +, Scott James Remnant wrote:
> On Wed, 2005-01-12 at 11:19 +0100, Domenico Andreoli wrote:
> >
> > IMHO people confused by dselect should switch to another dpkg/apt
> > frontend and not break it.
> > 
> Exactly, I agree *entirely*.
> 
> dselect has always used space to dismiss help messages and the current
> stable (woody) version of dselect still uses space to dismiss help
> messages.

yes, i'm aware of this. indeed i suppose you got many more sad users
because of the new behaviour than because of the original one. but this
is not the real problem, since it could be solved allowing both Enter
and Space to dismiss help messages.


> People were confused by this, so dselect was broken in unstable to allow
> Enter to be used.  Rather than breaking dselect, those people should
> switch to another dpkg/apt frontend.

are you saying i should use another frontend? tell me the truth and be
explicit, please :)


> As noted in the changelog, Enter (and 'Q') in dselect are dangerous
> keys, they commit changes.  Encouraging uses to hit Enter to dismiss
> screens they don't know about is therefore encouraging users to commit
> changes without considering them.

if the fact of hitting Enter to dismiss the help message confuses the
user at the point he instead commits changes, it looks like we need
another way to confirm rm -rf because people might be confused and wipe
the disk.

anyway, let me stop here. i don't want to start a flamewar. i wanted
only to cry publicly about the removal of something i found useful,
but apparently i'm alone. so it is really better the old behaviour has
been restored and peace with you all.

thank you for the --expert tip, i should have read it in the manpage
long time ago.

cheers
domenico

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


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

Re: dselect and its help messages

[Colin Watson]

On Thu, Jan 13, 2005 at 11:54:56AM +0100, Domenico Andreoli wrote:
> On Wed, Jan 12, 2005 at 02:52:47PM +, Scott James Remnant wrote:
> > Exactly, I agree *entirely*.
> > 
> > dselect has always used space to dismiss help messages and the current
> > stable (woody) version of dselect still uses space to dismiss help
> > messages.
> 
> yes, i'm aware of this. indeed i suppose you got many more sad users
> because of the new behaviour than because of the original one. but this
> is not the real problem, since it could be solved allowing both Enter
> and Space to dismiss help messages.

True, but that wouldn't address the other problem.

> > As noted in the changelog, Enter (and 'Q') in dselect are dangerous
> > keys, they commit changes.  Encouraging uses to hit Enter to dismiss
> > screens they don't know about is therefore encouraging users to commit
> > changes without considering them.
> 
> if the fact of hitting Enter to dismiss the help message confuses the
> user at the point he instead commits changes, it looks like we need
> another way to confirm rm -rf because people might be confused and wipe
> the disk.

No, it's not that. The point is that it's very easy - trivially easy,
and often done - to hit Enter twice when you only meant to hit it once,
and if you do that at dselect's help screen then you commit all its
suggested changes to new packages without getting a chance to look at
them. That's just terrible UI design.

People often complain about dselect's user interface, but let's not make
gratuitously bad UI decisions! Enter was explicitly avoided at the help
screen when dselect was written for this exact reason, but this decision
was forgotten when making the change.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Is debhelper build-essential?

[Wouter Verhelst]

On Thu, Jan 13, 2005 at 04:07:29AM +, Scott James Remnant wrote:
> The stats:
> 
>   8,920  source packages in Debian unstable main.
>   8,254  declare a build-dependency on debhelper
> 
>   = 92% of packages build-depend on debhelper.
> 
> Is that sufficient to declare it build-essential?

I'd say it is. I've been handling it that way on my buildd hosts since a
looong time, anyway. Additionally, I don't think we need to wait for 92%
of packages before we declare something build-essential; I'm sure there
are far more than 8% of our packages that do not require g++ to build...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: If *-module depends on *-utils, should *-source recommend it?

[Bernhard R. Link]

* Daniel Burrows <[EMAIL PROTECTED]> [050112 22:08]:
>   Well, you're also leaving the package in a broken and unconfigured state.  
> Doing this in order to save the user a little typing later (adding the 
> original package to the second --install line) seems to me like a hack to 
> make some use cases slightly more convenient, not elegance.

The elegance is that dpkg is robust in that it can always install
everything and can get cleanly from one state to another. However broken
the packages are you never end in a sitation you cannot fix again.
The additional checks suggested here add some additional term of
"correctness", that dpkg has to check on the resulting state. Without
some full formalisation or anything else to make sure it cannot get out
of this state, or can get back to that state easily, it is only a hack.
It would also break serialisation, as one would need to give a list of
packages to install to dpkg all at once or in the correct serialisation,
and no longer (with exception of configure cycles) beeing able to give
them in whatever sequence as one is pleased to do.

Hochachtungsvoll,
  Bernhard R. Link


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

Re: Is debhelper build-essential?

[Lars Wirzenius]

to, 2005-01-13 kello 04:07 +, Scott James Remnant kirjoitti:
> The stats:
> 
>   8,920  source packages in Debian unstable main.
>   8,254  declare a build-dependency on debhelper
> 
>   = 92% of packages build-depend on debhelper.
> 
> Is that sufficient to declare it build-essential?

Hm, I get slightly different numbers:

$ awk '/^Build-Depends/ { $1 = ""; print }' Sources | tr , '\n' | \
awk '{ print $1 }' | sort | uniq -c | sort -nr | head
   8278 debhelper
895 perl
820 cdbs
752 xlibs-dev
556 autotools-dev
508 dpatch
460 zlib1g-dev
409 gettext
386 libncurses5-dev
379 libgtk2.0-dev

The exact numbers are not, however, important. It is clear that
debhelper is by far the most popular explicit build dependency, by an
order of magnitude. (Incidentally, there seems to be a few packages that
explicitly build-depend on build-essential, which is probably not what
the package was meant for.)

The Policy Manual says this about build essential packages:

It is not necessary to explicitly specify build-time
relationships on a minimal set of packages that are always
needed to compile, link and put in a Debian package a standard
"Hello World!" program written in C or C++.

I don't think debhelper fits into this category. On the other hand,
build-essential (version 10.1) already depends on file, html2text,
debconf-utils, and po-debconf, which I think are also not necessary for
building a "hello, world" program.

I happen to think that explicit dependencies are in general better than
implicit ones. Being explicit tends to simplify things. We invented
build-essential, however, because having to explicitly build-depend on,
say, perl all the time is more error prone than having the dependency be
implicit. perl (not just perl-base) is, in practice, on every Debian
machine used for building packages, and if one had to explicitly
build-depend on it, there would be lots of accidentally missing build
depedencies on it. This would result in needless FTBFS bugs, if nothing
else.

I don't think debhelper is in the same category as perl is: pretty much
all packages that need it already properly build depend on it. (The rest
could be fixed.)

I don't mind debhelper becoming build-essential, but I don't think
that's what build-essential was really meant for. If we expand its
meaning, we should probably clarify its description in the Policy Manual
as well.


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

Re: Is debhelper build-essential?

[Santiago Vila]

On Thu, 13 Jan 2005, Scott James Remnant wrote:

> The stats:
> 
>   8,920  source packages in Debian unstable main.
>   8,254  declare a build-dependency on debhelper
> 
>   = 92% of packages build-depend on debhelper.
> 
> Is that sufficient to declare it build-essential?

No, it's not by definition, as you don't *need* it for a simple
"hello, world" package written in C. The fact that there are policy
compliant packages in the archive not using debhelper is the most
simple proof that it's not build-essential.

Don't confuse build-essential with build-popular.


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

Re: Is debhelper build-essential?

[Josselin Mouette]

Le jeudi 13 janvier 2005 à 12:49 +0100, Santiago Vila a écrit :
> On Thu, 13 Jan 2005, Scott James Remnant wrote:
> 
> > The stats:
> > 
> >   8,920  source packages in Debian unstable main.
> >   8,254  declare a build-dependency on debhelper
> > 
> >   = 92% of packages build-depend on debhelper.
> > 
> > Is that sufficient to declare it build-essential?
> 
> No, it's not by definition, as you don't *need* it for a simple
> "hello, world" package written in C. The fact that there are policy
> compliant packages in the archive not using debhelper is the most
> simple proof that it's not build-essential.

So what? You don't need g++ for a simple hello world package in C,
however g++ is build-essential. You don't even need gcc for a simple
package containing data files. Following your line of reasoning, only
make and dpkg-dev should be build-essential.

> Don't confuse build-essential with build-popular.

Why?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Is debhelper build-essential?

[Michael Koch]

Am Donnerstag, 13. Januar 2005 12:49 schrieb Santiago Vila:
> On Thu, 13 Jan 2005, Scott James Remnant wrote:
> > The stats:
> >
> >   8,920  source packages in Debian unstable main.
> >   8,254  declare a build-dependency on debhelper
> >
> >   = 92% of packages build-depend on debhelper.
> >
> > Is that sufficient to declare it build-essential?
>
> No, it's not by definition, as you don't *need* it for a simple
> "hello, world" package written in C. The fact that there are policy
> compliant packages in the archive not using debhelper is the most
> simple proof that it's not build-essential.
>
> Don't confuse build-essential with build-popular.

There are packages which don't need a C or C++ compiler. So in your 
opinion we should remove both from build-essential ?


Michael
-- 
Homepage: http://www.worldforge.org/


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

Re: Proper way to remove a package from both sarge and sid

[Santiago Vila]

On Thu, 13 Jan 2005, Vincent Danjean wrote:

> Santiago Vila wrote:
> 
> > Instead of that, I would upload a new version of mozilla-firefox-locale-da
> > which is empty and has a Depends: mozilla-firefox-locale-da-dk, i.e.
> > a dummy package. Put in section oldlibs and then deborphan
> > will tell you that you can remove it safely.
> > 
> > Then no conflict would be needed (well, a versioned one perhaps),
> > and there would not be so much hurry in removing the package, as you
> > will be helping users of the old package to install the new one.
>
> No, it would not be enough. Some people can try to install the new
> -da-dk package with your old -da package already present. Even if
> people upgrade your package at the same time, there is no evidence
> that dpkg will upgrade the -da package before installing the -da-dk
> package.  A conflict/replace on -da in the new -da-dk package is the
> (only ?) good thing to do

I agree that the new -da-dk package needs a versioned Replaces on all
the non-dummy versions of -da (that's why I said "a versioned one perhaps")
but there is not an absolute need to conflict with it.

> Your dummy package is only useful to force users to switch to the
> new -da-dk package on upgrade. In this case, the conflict/replace in
> -da-dk should be versionned.

No, if a dummy package exists then there should not be a Conflicts, only
a Replaces. The upgrade will be smoother if deborphan and section: oldlibs
takes care of removing the old -da package.


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

Re: dselect and its help messages

[Domenico Andreoli]

On Thu, Jan 13, 2005 at 11:00:26AM +, Colin Watson wrote:
> On Thu, Jan 13, 2005 at 11:54:56AM +0100, Domenico Andreoli wrote:
> > 
> > if the fact of hitting Enter to dismiss the help message confuses the
> > user at the point he instead commits changes, it looks like we need
> > another way to confirm rm -rf because people might be confused and wipe
> > the disk.
> 
> No, it's not that. The point is that it's very easy - trivially easy,
> and often done - to hit Enter twice when you only meant to hit it once,
> and if you do that at dselect's help screen then you commit all its
> suggested changes to new packages without getting a chance to look at
> them. That's just terrible UI design.
> 
> People often complain about dselect's user interface, but let's not make
> gratuitously bad UI decisions! Enter was explicitly avoided at the help
> screen when dselect was written for this exact reason, but this decision
> was forgotten when making the change.

now that i know about the expert mode, i agree with you. i was
complaining about a misuse of the interface.

thanks
domenico

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


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

Re: dselect and its help messages

[Domenico Andreoli]

On Thu, Jan 13, 2005 at 02:00:23PM +1100, Hamish Moffatt wrote:
> On Wed, Jan 12, 2005 at 03:20:19PM +, Colin Watson wrote:
> > The change *to* Enter was the thing that broke dselect for those of us
> > who have been using it since woody and earlier. Switching back to the
> > old behaviour unbroke it. As the changelog message states, encouraging
> > people to press Enter in dselect is dangerous.
> > 
> > Use 'dselect --expert' if you don't want to see the help messages at
> > all.
> 
> How about a way to suppress the help screen permanently, such as an
> environment option or dotfile?
> 
> I can't get rid of it quickly enough. What other program shows you its
> help screen every time you run it? And space to dismiss the help screen
> is not very intuitive.

since it is a help message, it could well tell the user how to get rid
of it permanently, couldn't it?

something like:

  If you want to get rid of this help message use the --expert
  command-line switch or set the expert option in file /etc/dpkg/dselect.cfg.

wouldn't it be appropriate in both the opening and conflict resolution
help screens?

my last 2 cents to the topic...

cheers
domenico

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


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

Re: Is debhelper build-essential?

[Antti-Juhani Kaijanaho]

On 20050113T040729+, Scott James Remnant wrote:
> The stats:
> 
>   8,920  source packages in Debian unstable main.
>   8,254  declare a build-dependency on debhelper
> 
>   = 92% of packages build-depend on debhelper.
> 
> Is that sufficient to declare it build-essential?

This issue belongs to debian-policy.

-- 
Antti-Juhani Kaijanaho, Debian developer 

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


signature.asc
Description: Digital signature

Re: Is debhelper build-essential?

[Lars Wirzenius]

to, 2005-01-13 kello 13:35 +0200, Lars Wirzenius kirjoitti:
> I don't think debhelper fits into this category. On the other hand,
> build-essential (version 10.1) already depends on file, html2text,
> debconf-utils, and po-debconf, which I think are also not necessary for
> building a "hello, world" program.

Someone was injecting hallucinogenic gas into my apartment and made me
think build-essential is spelled debconf. Thus, the dependencies I
mentioned are not ones that build-essential already has. Now, please
excuse me while I go find a gas mask.


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

Re: Is debhelper build-essential?

[Anthony Towns]

Scott James Remnant wrote:
The stats:
  8,920  source packages in Debian unstable main.
  8,254  declare a build-dependency on debhelper
  = 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
Also of interest is that some 1300 packages would no longer need to 
declare a Build-Depends: at all with those changes, and another 1200 
wouldn't need to declare a Build-Depends-Indep:.

That's, what, a quarter of build-depends lines disappearing entirely, 
above and 13 of every 15 of the rest being simplified?

OTOH, it'd also mean updating build-essential every now and then to say 
"you can assume debhelper will support this level of features, gcc will 
support these features, etc...".

What say you?
Rename it to "standard-debian-build-environment". :)
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is debhelper build-essential?

[Andreas Barth]

* Anthony Towns (aj@azure.humbug.org.au) [050113 14:20]:
> Scott James Remnant wrote:
> >What say you?

> Rename it to "standard-debian-build-environment". :)

It's more a "default-debian-build-environment" :)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 10:42 +0100, Javier FernÃndez-Sanguino PeÃa
escreveu:
> How about having this be configurable through something like 
> /etc/gksu.conf and include a wrapper script to read it?
> That would introduce a way (since gksu does not seem to have an 
> alternative) for average users to have the default behaviour (which is a 
> good idea) and for users that need this option to enable it per default.
> 
> The gtksu application could either read that or have a wrapper that (if 
> that file contained and $OPTIONS):

Sounds good, too.

> Better solution:
> - Have gksu source a /etc/gksu.conf file directly

I can hack gksu to read the file.

> - Have gksu obtain additional configuration from user's Xdefault or through 
> the GNOME registry?

having it use the GNOME registry would add another dependency to gksu,
which would make non-gnome-using application maintainers unhappy, maybe

Thanks,

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

Re: Is debhelper build-essential?

[Steinar H. Gunderson]

On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote:
> Also of interest is that some 1300 packages would no longer need to 
> declare a Build-Depends: at all with those changes, and another 1200 
> wouldn't need to declare a Build-Depends-Indep:.

Not even versioned depends?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Is debhelper build-essential?

[Matthew Garrett]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
> On 20050113T040729+, Scott James Remnant wrote:
>> Is that sufficient to declare it build-essential?
> 
> This issue belongs to debian-policy.

Remember that policy tends to be shaped by current practice. If there's
sufficient technical justification for something (and consensus that
that decision is correct), then it ought to be enacted regardless of
what policy says. Policy can be fixed up later.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 11:53 +0100, Josselin Mouette escreveu:
> However, that's not the key point. If we want to avoid such things to
> lock the session startup, why not register them with a very low
> priority ? There could even be a delay of a few seconds before the
> password window appears, in this case only.

I think gksu should not enter the session, but I still could not find a
way of doing that without adding a dependency on libgnomeui.

Thanks,

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

Re: soname number in name of dev-package?

[Henning Makholm]

Scripsit Stephen Frost
> * Henning Makholm ([EMAIL PROTECTED]) wrote:

> > In summary: Yes, one could probably work around the lack of versions
> > in the -dev packages name, but the result would be (in my view)
> > significantly less elegant than having it there.

> Trying to support unsupported versions of libraries is decidely worse.

Is anybody advocating that we should try to "support unsupported
versions of libraries"? I'm certainly not.

> If the API changes in an incompatible way then *fix* the things which
> use the library to use the new API.  Users aren't affected- the old,
> already compiled package, works fine against the lib it depends on, the
> new package will fail when trying to build against the new API

Exactly. Ensuring that the new API is not available under the old one's
name will make sure that the new package does fail (because of a
missing build-dependency) rather than trying silently to build against
the new API as if it was the old, and possibly producing bad binaries.

-- 
Henning Makholm"There is a danger that curious users may
  occasionally unplug their fiber connector and look
  directly into it to watch the bits go by at 100 Mbps."


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

Re: copyright vs. license

[Andrew Suffield]

On Wed, Jan 12, 2005 at 09:59:55PM -0600, Matthew Dempsky wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > For a GPLed project, the declaration looks something like this:
> >
> >  *   Copyright (C) Andrew Suffield <[EMAIL PROTECTED]>
> 
> Shouldn't you include a year?

It's not required. And I get bored by updating them.

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


signature.asc
Description: Digital signature

Re: [Fwd: Re: status of the DDTP project?]

[Daniel Macêdo Batista]

Em 9/1/2005, "Jeroen van Wolffelaar" <[EMAIL PROTECTED]> escreveu:
>>
>> ...
>>
>
>It seems there are enough people who want to help, but, which are debian
>developers? Could you, or anybody else, maybe try to find out who are
>interested?
>
>As with any project, it's always better if it's a team effort in stead
>of a personal effort. Once some people are found, some work can be done.
>

The brazilian team of the DDTP wants help. I'm the coordinator of the
brazilian
team, but I'm not debian developer. I'm sending emails to debian-devel
representing the team. Fred Maranhao was the last coordinator of the
brazilian
team.

>Meanwhile, I agree mail is important. What address(es) exactly are
>failing? It looks like [EMAIL PROTECTED] and webmaster@ etc are all
>deliverd to a group of people. A number of other addresses are fed into
>scripts, I could look into that, but don't know what exactly is failing
>or how it is supposed to work.

The address with problems is [EMAIL PROTECTED] The translators and
reviewers of the DDTP sends emails with specifics subjects and the server
sents specific replies to each subject. For example:

If I send an email with the subject "STATUS pt_BR", the reply is an
email with the following message:

Stats for pt_BR from pdesc
descriptions 19666
up-to-date descriptions  11545
translated descriptions   4690
orphan descriptions330
descriptions with 0 reviewer(s)190
descriptions with 1 reviewer(s)818
descriptions with 2 reviewer(s) 66
descriptions with 3 reviewer(s)917
reviewed descriptions 2699
packages sent 1546
translated parts 10643
translated pparts13809
bug reports   9680
open bug reports   366

The problem with the ddtp is that the server isn't sending replies to the
messages and the translators and reviewers haven't feedback about the
work.

In http://ddtp.debian.org/new/how_it_works/ddts.en.html, there are
questions
about DDTP and the available comands.

I already sent messages to [EMAIL PROTECTED] but nobody sent replies to me.

Can you help the DDTP?

>
>--Jeroen
>
>--
>Jeroen van Wolffelaar
>[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
>http://Jeroen.A-Eskwadraat.nl
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>


--
Daniel Macêdo Batista
[EMAIL PROTECTED], http://www.ic.unicamp.br/~ra030022
Mestrando em Ciência da Computação pela Unicamp
   .-.
  .''`./v\G N U / L I N U X
 : :'  :  // \\  >Não tenha medo do pinguim<
 `. `'`  /(   )\
   `- ^^-^^

Re: copyright vs. license

[David Renie]

> > Shouldn't you include a year?
> 
> It's not required. And I get bored by updating them.
> 

The year should be included.  Here is a reference: 
http://www.copyright.gov/circs/circ1.html

An excerpt:

The notice for visually perceptible copies should contain all the
following three elements:

1. The symbol © (the letter C in a circle), or the word "Copyright,"
or the abbreviation "Copr."; and

2. The year of first publication of the work. In the case of
compilations or derivative works incorporating previously published
material, the year date of first publication of the compilation or
derivative work is sufficient. The year date may be omitted where a
pictorial, graphic, or sculptural work, with accompanying textual
matter, if any, is reproduced in or on greeting cards, postcards,
stationery, jewelry, dolls, toys, or any useful article; and

3. The name of the owner of copyright in the work, or an abbreviation
by which the name can be recognized, or a generally known alternative
designation of the owner.

Example: © 2002 John Doe 


David Renie

Re: copyright vs. license

[Thomas Bushnell BSG]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> It's not required. And I get bored by updating them.

Yes, the year is required, and moreover, you need to add a new year
every time there is a new publication in a year not already mentioned
(without removing the old years, since the new publication is a
derived work).

I have a handy-dandy emacs lisp frob that will do this automagically
for you if you like.

Thomas


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

Re: soname number in name of dev-package?

[Thomas Bushnell BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Is anybody advocating that we should try to "support unsupported
> versions of libraries"? I'm certainly not.

Sure!  That's what libc5 is.  

Thomas


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

Re: If *-module depends on *-utils, should *-source recommend it?

[William Ballard]

On Thu, Jan 13, 2005 at 12:26:31PM +0100, Bernhard R. Link wrote:
> It would also break serialisation, as one would need to give a list of
> packages to install to dpkg all at once or in the correct serialisation,
> and no longer (with exception of configure cycles) beeing able to give
> them in whatever sequence as one is pleased to do.

The current behavior should be available as a -force option if it is 
needed, not the default.

I don't value the things you are doing *at all*.  Or else I'd just use 
Redhat.

Again, if this really isn't the right thing for dpkg to do, fine, let 
apt install individual packages, and I'll avoid calling dpkg directly 
like the plague for the exact same reasons I don't want to use Redhat.


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

Re: soname number in name of dev-package?

[Henning Makholm]

Scripsit Thomas Bushnell BSG
> Henning Makholm <[EMAIL PROTECTED]> writes:

> > Is anybody advocating that we should try to "support unsupported
> > versions of libraries"? I'm certainly not.

> Sure!  That's what libc5 is.  

I'm not aware of even having mentioned libc5 in this thread (and I
don't remember anybody else doing it either).

-- 
Henning Makholm  # good fish ...
# goodfish, goodfish ...
 # good-good FISH! #


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

Re: soname number in name of dev-package?

[Thomas Bushnell BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Thomas Bushnell BSG
> > Henning Makholm <[EMAIL PROTECTED]> writes:
> 
> > > Is anybody advocating that we should try to "support unsupported
> > > versions of libraries"? I'm certainly not.
> 
> > Sure!  That's what libc5 is.  
> 
> I'm not aware of even having mentioned libc5 in this thread (and I
> don't remember anybody else doing it either).

Anthony's point, if I understand it right, is that we should only do
this kind of aggressive versioning-in-the-names when we want to
support unsupported versions of libraries, and that doing so is
usually the wrong thing.

But it is *sometimes* the right thing, and the canonical example is
libc5.  Libc5 is the counterexample to your implied assertion that
nobody really cares about "supporting unsupported versions of
libraries."

Thomas


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

Re: copyright vs. license

[John Hasler]

Thomas writes:
> Yes, the year is required, and moreover, you need to add a new year every
> time there is a new publication in a year not already mentioned (without
> removing the old years, since the new publication is a derived work).

No notice is required by law at all.  However, it is a good idea to include
one and to do so correctly.  It's not hard to do.
-- 
John Hasler


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

Re: copyright vs. license

[Ben Pfaff]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

[updating copyright years]
> I have a handy-dandy emacs lisp frob that will do this automagically
> for you if you like.

I would like this.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


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

Re: soname number in name of dev-package?

[Henning Makholm]

Scripsit Thomas Bushnell BSG
> Henning Makholm <[EMAIL PROTECTED]> writes:
> > Scripsit Thomas Bushnell BSG
> > > Henning Makholm <[EMAIL PROTECTED]> writes:

> > > > Is anybody advocating that we should try to "support unsupported
> > > > versions of libraries"? I'm certainly not.

> > > Sure!  That's what libc5 is.  

> > I'm not aware of even having mentioned libc5 in this thread (and I
> > don't remember anybody else doing it either).

> Libc5 is the counterexample to your implied assertion that
> nobody really cares about "supporting unsupported versions of
> libraries."

I'm lost now. As far as I can see, previously you were telling me that
I was wrong for wanting to "support unsupported versions of libraries".
Now you're saying that I'm wrong for claiming that nobody cares about
"supporting unsupported versions of libraries."

I still don't think I have said *anything* in this thread, implied or
otherwise, about supporting unsupported versions of libraries. I have
not said that we should do it, I have not said that we shouldn't, I
have not said that nobody cares about it, and I have not said that
somebody cares about it.

Could you explain in little words exactly where you think I imply
something about supporting unsupported libraries? Otherwise I'm afraid
I'll be unable to reply meaningfully.

-- 
Henning Makholm   "Det er trolddom og terror
 og jeg får en værre
   ballade når jeg kommer hjem!"


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

Re: copyright vs. license

[Andrew Suffield]

On Thu, Jan 13, 2005 at 09:08:37AM -0800, Thomas Bushnell BSG wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > It's not required. And I get bored by updating them.
> 
> Yes, the year is required, and moreover, you need to add a new year
> every time there is a new publication in a year not already mentioned
> (without removing the old years, since the new publication is a
> derived work).

This hasn't been necessary since the 1970s.

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


signature.asc
Description: Digital signature

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

[Osamu Aoki]

On Thu, Jan 13, 2005 at 11:26:04AM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 10:42 +0100, Javier Fernández-Sanguino Peña
> escreveu:
> > Better solution:
> > - Have gksu source a /etc/gksu.conf file directly
> 
> I can hack gksu to read the file.

I think we now have a winer idea here.

I also look at code too and found:
 * gksu and gksudo is just a same program with different invocation
   name.
 * Parsing of GNU long-option and /etc/gksu.conf may share codes.

So may I ask to implement /etc/gksu.conf.  When implementing this to
/etc/gksu.conf, please consider adding following features together:

 * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
 * add new long-option: --force-grab
 * add new long-option: --sudo-mode (Start it with gksudo mode)
 * add new long-option: --limit-uid=UID1:UID2:UID3:...
 * add new long-option: --limit-gid=GID1:GID2:GID3:...
 * add new long-option: --prompt (prompt before locking I/O)
 * add new long-option: --no-prompt (do not prompt before locking I/O: default)

I think the setting in /etc/gksu.conf should have priority over
command-line so super user controls this command's behavior.  Gksu
should check the owner and permission of /etc/gksu.conf being root:root
644 or less.  Those limit-uid and limit-gid are meant to be additional
safeguard for GUI-su (over PAM etc).  I think if a user is not allowed
to use this facility, gksu should display a short message indicating
situation to X.  So people will know they can not use it.  Prompting is
simple trick to prevent freeze for start-up situation.  This is not
fancy trick which works for Gnome or KDE.  Just provide prompt screen
before locking I/O.

sudo-made will let me type only user password using gksudo mode for
synaptic :-) (Or no password, if I chose to set it so.)

Then you can close all the bugs I listed in the previous mail and no one
will complain.  We will add hints to README.Debian for SCIM.

Osamu

PS: I browsed your code to find gksudo binary being the same hardlink as
gksu except filename.  Please also link gksudo.1 to manpage :-)

PS2: Interesting su-to-root story
 http://lists.debian.org/debian-devel/2004/11/msg00728.html
 http://lists.debian.org/debian-devel/2004/11/msg00735.html
 http://lists.debian.org/debian-devel/2004/11/msg00742.html
 

RFA: wmakerconf, wmakerconf-data -- GTK+ based configuration tool for Window Maker

[Kevin B. McCarty]

Hi all,

I am requesting someone to adopt WMakerConf and its friend,
wmakerconf-data (they are separate source packages), and give them some
TLC.  I've moved to using Gnome/Metacity instead of WindowMaker on my
laptop, so I no longer have much incentive or energy to maintain the
packages.

Please note that any adopter will also have to take over as WMakerConf
upstream.  The program should probably be ported to use GTK+ 2 (to fix
problems like http://bugs.debian.org/282807 ) and deal with new features
of WindowMaker 0.90.  Note that a successful port to GTK+ 2 will as a
side effect close http://bugs.debian.org/182586 .

For more information of use to prospective adopters, see the RFAs in the
BTS:

http://bugs.debian.org/290350
http://bugs.debian.org/290352

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: If *-module depends on *-utils, should *-source recommend it?

[Darren Salt]

I demand that Scott James Remnant may or may not have written...

[snip]
> And a far better solution to the "a package on disk needs dependencies"
> solution is for a command-line tool that can grab the dependencies a
> package needs, not just bitch about them not existing.

apt* with an install-from-local-package command or adaptation of the install
command?

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   We've got Shearer, you haven't

I'd like to, but I have to thaw some karate chops for dinner.


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

Re: copyright vs. license

[Jens Peter Secher]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Andrew Suffield <[EMAIL PROTECTED]> writes:
>
>> It's not required. And I get bored by updating them.
>
> Yes, the year is required, and moreover, you need to add a new year
> every time there is a new publication in a year not already mentioned
> (without removing the old years, since the new publication is a
> derived work).

And remember that you need to brush your teeth before you go to bed.
-- 
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher get2net dk_


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

Re: soname number in name of dev-package?

[Thomas Bushnell BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> I'm lost now. As far as I can see, previously you were telling me that
> I was wrong for wanting to "support unsupported versions of libraries".
> Now you're saying that I'm wrong for claiming that nobody cares about
> "supporting unsupported versions of libraries."

No, you should support unsupporting versions of libraries only when
it's the right thing, which is exceedingly rarely, but not never, and,
if I understand Anthony right, pretty much only when you cannot
sensibly just say "fix the damn applications."

Thomas


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

Re: copyright vs. license

[Thomas Bushnell BSG]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Thu, Jan 13, 2005 at 09:08:37AM -0800, Thomas Bushnell BSG wrote:
> > Andrew Suffield <[EMAIL PROTECTED]> writes:
> > 
> > > It's not required. And I get bored by updating them.
> > 
> > Yes, the year is required, and moreover, you need to add a new year
> > every time there is a new publication in a year not already mentioned
> > (without removing the old years, since the new publication is a
> > derived work).
> 
> This hasn't been necessary since the 1970s.

You only get triple damages and other goodies out of the copyright
system if the person who copied it knew they were violating
copyright.  If you have a proper copyright notice (which must have the
date) then they are presumed to know.  If you have an invalid one,
then they are not, and you must now prove their state of mind, which
is not impossible, but still reasonable.


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

Re: copyright vs. license

[Thomas Bushnell BSG]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> 
> [updating copyright years]
> > I have a handy-dandy emacs lisp frob that will do this automagically
> > for you if you like.
> 
> I would like this.

;; When we save a file with a GPL copyright, prompt to suggest
;; modifying the notice to contain the most recent GPL version and
;; include the current year.
(defconst current-year (substring (current-time-string) -4)
  "String representing the current year.")
(defvar current-gpl-version "2"
  "String representing the current version of the GPL.")
(defun update-copyright-with-queries ()
  "My version of update-copyright."
  (save-excursion
(save-restriction
  (widen)
  (goto-char (point-min))
  (and (re-search-forward "[i]s free software"
  nil t)
   (not (eq major-mode 'rmail-mode))
   (let ((limit (point)))
 (goto-char (point-min))
 (re-search-forward 
  "[Cc]opyright[^0-9]*\\(\\([-, \t]*\\([0-9]+\\)\\)\\)+"
  limit t))
   (progn (forward-word -1)
  (not (looking-at current-year)))
   (progn (goto-char (point-min))
  (sit-for 0)
  (y-or-n-p "Update copyright? "))
   (let ((replace (y-or-n-p "Replace year? ")))
 (or (re-search-forward
  "[Cc]opyright[^0-9]*\\(\\([-, \t]*\\([0-9]+\\)\\)\\)+"
  nil t)
 (error "This buffer contains no copyright notice!"))
 (if replace
 (delete-region (match-beginning 1) (match-end 1))
   (insert ", "))
 (insert current-year)
 (message "Copyright updated to %s%s."
  (if replace "" "include ") current-year)
 (if (re-search-forward 
  "; either version \\(.+\\), or (at your option)"
  nil t)
 (progn
   (goto-char (match-beginning 1))
   (delete-region (point) (match-end 1))
   (insert current-gpl-version
(setq write-file-hooks (cons 'update-copyright-with-queries write-file-hooks))


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

Re: copyright vs. license

[Andrew Suffield]

On Thu, Jan 13, 2005 at 11:16:19AM -0800, Thomas Bushnell BSG wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jan 13, 2005 at 09:08:37AM -0800, Thomas Bushnell BSG wrote:
> > > Andrew Suffield <[EMAIL PROTECTED]> writes:
> > > 
> > > > It's not required. And I get bored by updating them.
> > > 
> > > Yes, the year is required, and moreover, you need to add a new year
> > > every time there is a new publication in a year not already mentioned
> > > (without removing the old years, since the new publication is a
> > > derived work).
> > 
> > This hasn't been necessary since the 1970s.
> 
> You only get triple damages and other goodies out of the copyright
> system if the person who copied it knew they were violating
> copyright.

Like I care about that stuff. All I could ever want from copyright on
a GPLed work is an injunction to stop violating it.

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


signature.asc
Description: Digital signature

Re: copyright vs. license

[Thomas Bushnell BSG]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> Like I care about that stuff. All I could ever want from copyright on
> a GPLed work is an injunction to stop violating it.

Actually, you can even fail to get that in practice.  Really, just put
the date; it's not too much trouble.


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

Re: copyright vs. license

[Andrew Suffield]

On Thu, Jan 13, 2005 at 11:27:12AM -0800, Thomas Bushnell BSG wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > Like I care about that stuff. All I could ever want from copyright on
> > a GPLed work is an injunction to stop violating it.
> 
> Actually, you can even fail to get that in practice.

Not in any sane country.

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


signature.asc
Description: Digital signature

Re: soname number in name of dev-package?

[Henning Makholm]

Scripsit Thomas Bushnell BSG

> No, you should support unsupporting versions of libraries only when
> it's the right thing, which is exceedingly rarely, but not never, and,
> if I understand Anthony right, pretty much only when you cannot
> sensibly just say "fix the damn applications."

Do you think I disagree with this? If so, what makes you think that?

-- 
Henning Makholm "However, the fact that the utterance by
   Epimenides of that false sentence could imply the
   existence of some Cretan who is not a liar is rather unsettling."


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

Re: If *-module depends on *-utils, should *-source recommend it?

[Henning Makholm]

Scripsit "Bernhard R. Link" <[EMAIL PROTECTED]>

> The elegance is that dpkg is robust in that it can always install
> everything and can get cleanly from one state to another. However broken
> the packages are you never end in a sitation you cannot fix again.

How would this property be lost if dpkg's default was check for
consistency of the end result before it starts unpacking things?

> Without some full formalisation or anything else to make sure it
> cannot get out of this state, or can get back to that state easily,
> it is only a hack.

Nobody claims what such checking will necessarily solve all of the
world's problems. But it will make life easier for people who only use
dpkg occasionally to install locally-built .debs.

> It would also break serialisation, as one would need to give a list of
> packages to install to dpkg all at once or in the correct serialisation,
> and no longer (with exception of configure cycles) beeing able to give
> them in whatever sequence as one is pleased to do.

Nobody is suggesting that there should not be an option to override
the default check for users (or front ends) who know what they are
doing.

-- 
Henning Makholm "That's okay. I'm hoping to convince the
  millions of open-minded people like Hrunkner Unnerby."


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

Re: copyright vs. license

[Daniel Burrows]

On Thursday 13 January 2005 11:18 am, Thomas Bushnell BSG wrote:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
> > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> >
> > [updating copyright years]
> >
> > > I have a handy-dandy emacs lisp frob that will do this automagically
> > > for you if you like.
> >
> > I would like this.

  Slight modification that works more conveniently for me (this is the only
significant chunk of elisp I've tried to write, so may be buggy; it worked
in tests, though):

=== cut here ===
(defconst current-year (substring (current-time-string) -4)
  "String representing the current year.")
(defconst last-year (int-to-string (- (string-to-int current-year) 1))
  "String representing the current year (presuming that the current year is not 
1 AD, which hopefully will continue to be the case indefinitely).")
(defvar current-gpl-version "2"
  "String representing the current version of the GPL.")
(defvar copyright-regex "[Cc]opyright\\s *\\(([Cc])\\)?\\(\\s *[0-9]+\\s 
*\\(-\\s *[0-9]+\\s *\\)?,\\s *\\)*\\s *\\(\\([0-9]+\\)\\s *-\\)?\\s 
*\\([0-9]+\\)"
  "Regular expression to match common copyright declarations, extracting the 
final year(s).")
;; Note: paren expr. #5 is the first year of the last dashed pair, if
;; any; paren expr. #6 is the last year.

(defun update-copyright-with-queries ()
  "My version of update-copyright."
  (save-excursion
(save-restriction
  (widen)
  (goto-char (point-min))
  (and (re-search-forward "[i]s free software"
  nil t)
   (not (eq major-mode 'rmail-mode))
   (let ((limit (point)))
 (goto-char (point-min))
 (re-search-forward copyright-regex
  limit t))
(let ((final-year (match-string 6))
   (final-range-start (match-string 5)))
  (when (and (not (string= final-year current-year))
   (progn (goto-char (point-min))
  (sit-for 0)
  (y-or-n-p (format "Update copyright (last %s)? " final-year
(if (string= final-year last-year)
 (if final-range-start
 (progn
(goto-char (match-end 6))
(delete-region (match-beginning 6) (match-end 6))
(insert current-year))
   (progn
 (goto-char (match-end 6))
 (insert "-")
 (insert current-year)))
   (progn
 (goto-char (match-end 6))
 (insert ", ")
 (insert current-year))) t))
(message "Copyright updated to include %s." current-year)
(if (re-search-forward 
  "; either version \\(.+\\), or (at your option)"
  nil t)
(progn
   (goto-char (match-beginning 1))
   (delete-region (point) (match-end 1))
   (insert current-gpl-version)))

(setq write-file-hooks (cons 'update-copyright-with-queries write-file-hooks))
== cut here 

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   Whom the gods would destroy, they first teach BASIC.|
\--- News without the $$ -- National Public Radio -- http://www.npr.org ---/


pgpzYAZtDHGeP.pgp
Description: PGP signature

Re: copyright vs. license

[Shaun Jackman]

> > > Shouldn't you include a year?
> >
> > It's not required. And I get bored by updating them.
> 
> The year should be included.  Here is a reference:
> http://www.copyright.gov/circs/circ1.html

If only one year is listed in a source file / copyright file, should
it be the first year the work started or the most recent year the work
was modified?

I am interested in Canadian and American copyright law primarily.

Please cc me in your reply. Cheers,
Shaun


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

Re: copyright vs. license

[Thomas Bushnell BSG]

Shaun Jackman <[EMAIL PROTECTED]> writes:

> > > > Shouldn't you include a year?
> > >
> > > It's not required. And I get bored by updating them.
> > 
> > The year should be included.  Here is a reference:
> > http://www.copyright.gov/circs/circ1.html
> 
> If only one year is listed in a source file / copyright file, should
> it be the first year the work started or the most recent year the work
> was modified?

It should be every year that the work was published.  (If you publish
in year N, then modify and publish the new thing in year M, you should
list both years.)

There is no harm in listing extra years.

Thomas


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

Re: Is debhelper build-essential?

[Hamish Moffatt]

On Thu, Jan 13, 2005 at 02:26:52PM +0100, Steinar H. Gunderson wrote:
> On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote:
> > Also of interest is that some 1300 packages would no longer need to 
> > declare a Build-Depends: at all with those changes, and another 1200 
> > wouldn't need to declare a Build-Depends-Indep:.
> 
> Not even versioned depends?

Not if build-essential included a suitable versioned depends, like
debhelper (>= 4). It already does that for gcc.

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


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

Re: copyright vs. license

[John Hasler]

Thomas writes:
> It should be every year that the work was published.  (If you publish in
> year N, then modify and publish the new thing in year M, you should list
> both years.)

> There is no harm in listing extra years.

There could be if you do so in a way that could be construed as an attempt
to fraudulently extend the life of the copyright.
-- 
John Hasler


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

Re: copyright vs. license

[Thomas Bushnell BSG]

John Hasler <[EMAIL PROTECTED]> writes:

> Thomas writes:
> > It should be every year that the work was published.  (If you publish in
> > year N, then modify and publish the new thing in year M, you should list
> > both years.)
> 
> > There is no harm in listing extra years.
> 
> There could be if you do so in a way that could be construed as an attempt
> to fraudulently extend the life of the copyright.

Yes, but not in the context of the original question.  Since copyright
now inheres from the work's creation, not first publication, and the
question was "should I list the creation date or the most recent
edit", there is no harm in listing the creation date.

But the real point I was trying to make is that listing extra
*intermediate* days is harmless.


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

Re: copyright vs. license

[Ben Pfaff]

John Hasler <[EMAIL PROTECTED]> writes:

> There could be if you do so in a way that could be construed as an attempt
> to fraudulently extend the life of the copyright.

At the moment it seems doubtful that any current copyright will
ever expire.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


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

Bug#290427: ITP: ltsp-utils -- LTSP administration utilities

[Robert Millan]

Package: wnpp
Severity: wishlist

* Package name: ltsp-utils
  Version : 0.10
  Upstream Author : James McQuillan <[EMAIL PROTECTED]>
* URL : http://www.ltsp.org/
* License : GPL
  Description : LTSP administration utilities

 Utilities for installing and managing the LTSP (Linux Terminal Server Project)
 client packages, and for configuring the services on the LTSP server.
 .
 Included in this packages are the administration utility (ltspadmin) and the
 configuration tool (ltspcfg).

Preliminar packages in http://people.debian.org/~rmh/packages/

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-i386 (i386)
Kernel: GNU/kFreeBSD 5.3+1-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


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

Bug#290421: ITP: zeiberbude -- A program for administering internet cafes.

[Robert Millan]

Package: wnpp
Severity: wishlist

* Package name: zeiberbude
  Version : 2.0.4
  Upstream Author : Christian Toepp <[EMAIL PROTECTED]>
* URL : http://zeiberbude.sourceforge.net/
* License : GPL
  Description : A program for administering internet cafes.

The package is made and ready for upload.  You can find a copy at:

  http://people.debian.org/~rmh/zeiberbude/

Btw, I'm looking for a way to integrate zbdesk (the client) as a startup
script.  zbdesk is a simple X client that locks the X server and can be
controlled remotely by zeiberbude.  It relies on an already-running X, and
it doesn't start other X clients whatsoever (just locks and unlocks), so it
can't just be run from an init.d script.  Any suggestion?

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-i386 (i386)
Kernel: GNU/kFreeBSD 5.3+1-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


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

Bug#290404: ITP: opengogear -- free tool for Philips GoGear HDD0xx

[Riccardo Setti]

Package: wnpp
Severity: wishlist

* Package name: opengogear
  Version : 0.01 
  Upstream Author : Stefano Brivio [EMAIL PROTECTED]
* URL : http://opengogear.sarovar.org/
* License : GPL
  Description : free tool for Philips GoGear HDD0xx

openGogear is a free suite of tools to get the Philips GoGear HDD0xx 
mp3 players working with Linux. Those devices can be mounted 
with the usb-storage standard module included in Linux kernel,
but file indexing is needed in order to hear mp3's. 


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)


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

Bug#290396: ITP: lopster2 -- A Napster gtk2 client

[Riccardo Setti]

Package: wnpp
Severity: wishlist

* Package name: lopster2
  Version : cvs pre3.9
  Upstream Author : Sgopsgop at users.sourceforge.net
* URL : lopster.sf.net
* License : GPL
  Description : gtk2 filesharing client that supports many protocols

Gtk2 version of the famous napster client atm it supports only
napster but in the future:
-PLUGIN-
 Plugin Gnutella  
 Plugin FastTrack 
 Plugin Edonkey2000   
 Plugin SoulSeek  
 Plugin DirectConnect 


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)


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

Bug#290364: ITP: svn-arch-mirror -- one-way mirroring from Subversion to Arch revision control

[Eric Wong]

Package: wnpp
Severity: wishlist


* Package name: svn-arch-mirror
  Version : 0.2.6
  Upstream Author : Eric Wong <[EMAIL PROTECTED]>
* URL : http://des.petta-tech.bogomips.org/eric/MusicPD/[EMAIL 
PROTECTED]/svn-arch-mirror/
* License : GPL v2
  Description : one-way mirroring from Subversion to Arch revision control

svn-arch-mirror makes it possible to track upstream Subversion
repositories and replicate full project history from Subversion to Arch.
Features include:
- preserving the date and time of the original commit
- preserving the alias/name of the original committer
- intelligent branch-tracking


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

Bug#290362: www.debian.org: Please add Root to list of programs that cannot be packaged

[Kevin McCarty]

Package: www.debian.org
Severity: wishlist

Hello,

Could someone please add Root (http://root.cern.ch/) to the list of software
that cannot be packaged, http://www.debian.org/devel/wnpp/unable-to-package
?  There have been several attempts at ITPs:

http://lists.debian.org/debian-mentors/1999/12/msg9.html
http://lists.debian.org/debian-legal/2003/01/msg00278.html
http://lists.debian.org/debian-mentors/2004/12/msg00278.html

There are two problems: first, the license [1] forbids redistribution of
modified binaries without permission of the authors, which some have argued
makes it unsuitable even for non-free [2]; second, and worse, the software
contains what appears to be code derived from cernlib (GPL) [3] and Xclass
(LGPL) [4] while having a license incompatible with either.

[1] http://root.cern.ch/root/License.html
[2] http://lists.debian.org/debian-legal/2003/01/msg00297.html
http://lists.debian.org/debian-legal/2003/01/msg00281.html
[3] http://cernlib.web.cern.ch/cernlib/conditions.html
[4] http://xclass.sourceforge.net/

This is most unfortunate, since Root is a very useful tool and a number of
interesting projects are based on it, but I don't see how Debian can
legally package it, even in non-free, until upstream changes their license.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.9-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: rudeness in general

[Zak B. Elep]

Anthony Towns  writes:

> Anyway, this is surely off topic for -devel. Can we go back to talking about
> hot babes or something?

That would be very welcome.

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


pgpRtyuWaU0In.pgp
Description: PGP signature

Re: If *-module depends on *-utils, should *-source recommend it?

[Scott James Remnant]

On Thu, 2005-01-13 at 17:06 +, Darren Salt wrote:

> I demand that Scott James Remnant may or may not have written...
> 
> [snip]
> > And a far better solution to the "a package on disk needs dependencies"
> > solution is for a command-line tool that can grab the dependencies a
> > package needs, not just bitch about them not existing.
> 
> apt* with an install-from-local-package command or adaptation of the install
> command?
> 
Yes.

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


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

Re: Compiling libc4 on Debian unstable

[Peter Samuelson]

[Christoph Berg]
> [0] [EMAIL PROTECTED]:~ $host archive.debian.org
> archive.debian.org has address 208.185.25.38
> [0] [EMAIL PROTECTED]:~ $host 208.185.25.38
> 38.25.185.208.in-addr.arpa domain name pointer raff.debian.org.

google has no trouble finding mirrors for it, though.

Peter


signature.asc
Description: Digital signature