Re: Bug#198158: architecture i386 isn't i386 anymore

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 12:35:53PM -0400, Colin Walters wrote:
> I'm surprised that pthreads apparently doesn't use it.

nptl doesn't support i386 anymore because of that.

Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)

[Adam Majer]

On Wed, Jun 25, 2003 at 12:47:41AM +0100, Andrew Suffield wrote:
> On Tue, Jun 24, 2003 at 11:15:42AM -0700, Keegan Quinn wrote:
> > On Tuesday 24 June 2003 10:59 am, Emile van Bergen wrote:
> > > Hi,
> > >
> > > On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote:
> > > > Tell me when you upload this, so I can file an rc bug against it, for
> > > > modifying other packages conffiles.
> > >
> > > *g*
> > >
> > > 5 serious replies already -- sorry Adam, I'm afraid there are just too
> > > many people that lack even the most basic sense of humour.
> > 
> > Or perhaps not everyone thinks a threat of an RC bug is a laughing matter.
> 
> Sure, people who have sticks up their arses don't. Mocking them is
> great fun.

Are you on crack or you rotated on one of your "arse sticks" one too 
many times when you wrote this? Maybe most people lack some perverted sense of 
humor.
And if that was a joke, thank god he's not going into stand up comedy.

Re: Application files in $HOME

[Adam Majer]

On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote:
> Hi,
> 
> Recently I had a problem of exceeded quota in my home directory, so I
> went cleaning it, and I saw many and many files and directories with
> configurations for applications that I've runned in the past, but that 
> packages were purged from my system a long time ago, so what is the idea
> (that can be a proposal)?
> 
> What if the packages tells to dpkg which files or directories it will
> create on the user's home directory and when a package is purged the
> user could run a program to purge the files of packages that no longer
> exists. This will also help to know what these files means after all, I
> thought about a browser to inspect application's files in my home, so it
> will be easier to decide which files I don't want anymore...
> 
> What is needed?
> 
> The packages should have a control file (like conffiles) that tells
> which files this package will create.
> 
> A repository to store this information so the user can browse it.
> 
> A userconfpurge program that the user runs to remove purged packages
> configuration files
> 
> A browser to associate the files with the packages and manage them (so
> the user can tell: I don't use icewm anymore, please remove it's
> configuration files).
> 
> Is there risk involved?
> 
> I don't know if different packages create conf files with the same name,
> if it does so, it would be necessary to avoid this practice.

This would require a lot of work on the part of each maintainer to see
which files get created where. One would need to change the Policy as well
to require maintainers to actually use such a "registry".

I say it is not worth it. Just do a `ls -la` and delete the really old
stuff that you know you don't need. Or even better, add yourself as 
a new user to the system, copy all the stuff you need from the old
account, and when ready, remove the old account with all the directiries :)

- Adam

Re: Bug#198158: architecture i386 isn't i386 anymore

[Jan-Hendrik Palic]

Morning .. 

On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
>And not only 80386 needs this - There is the Sparc64 port which would
>also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
>had support for subarchtectures, not only would the ix86 mess be able to
>be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
>you fancy). And I am sure this can somehow help maintain the non-Linux
>ports - NetBSD gives us the potential to bring Debian to _many_ new
>platforms. 

In my opinion, this would be the right way. Sure, this is a lot of work,
but we, if we splitt the arches up into suparches, we will be able to
use optimization for eg. 586/686 or on PowerPC altivec for G4 and so on.
And, of course, we can keep the support 80386.

Regards
Jan
-- 
  .''`.Jan-Hendrik Palic |
 : :' : ** Debian GNU/ Linux **  |   ** OpenOffice.org **   ,.. ,..
 `. `'   http://www.debian.org   | http://www.openoffice.org  ,: ..`   `
   `-  [EMAIL PROTECTED] |   '  `  `


pgpQvAYMV2GzT.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> ports - NetBSD gives us the potential to bring Debian to _many_ new
> platforms. 

It's not that many actually.  The only CPU that NetBSD claims to support
but Linux doesn't is the pc532.  Also the (umerged) Linux VAX and arm26
aren't really useable unlike their NetBSD counterparts.

Re: Movie

[errata]

Thank you for your interest in Red Hat's products.

For the latest product errata, please visit these pages on the Red Hat
website:

http://www.redhat.com/apps/support/updates.html

(This page lists all available errata.  If the errata includes updated
software, you can manually download the software from each errata page.)

http://www.redhat.com/network/

(This is the main page for Red Hat Network.  Once registered, you can use
Red Hat Network to download and install updated software in a more
automated fashion.)

Again, thank you for your interest in our products.

  Red Hat, Inc.

apt ignores -o DPkg::Options ?

[Nikita V. Youshchenko]

Hmm...

Seems that apt-get ignores -o DPkg::Options.

[EMAIL PROTECTED]:~> cat /tmp/xxx
#!/bin/sh
echo dpkg $*
exit 1

[EMAIL PROTECTED]:~> LANG=C apt-get -o 'Dir::Bin::dpkg=/tmp/xxx' -o
'DPkg::Options={"--xxx";}' install nvi
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
  nvi
0 packages upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 265kB of archives.
After unpacking 598kB of additional disk space will be used.
Get:1 http://zigzag.lvk.cs.msu.su stable/main nvi 1.79-20 [265kB]
Fetched 265kB in 0s (349kB/s)
dpkg --unpack /var/cache/apt/archives/nvi_1.79-20_i386.deb
E: Sub-process /tmp/xxx returned an error code (1)

So dpkg is called without any options from DPkg::Options ...

Should this be reported as a bug in apt, or I am doing something wrong?

P.S.
While exploring this issue, I looked at apt open bug list. I was surprised
how HUGE it is. Can't believe that apt, possibly the most important Debian
package, is poorly maintained...

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Wouter Verhelst]

On Thu, Jun 26, 2003 at 12:21:22AM +1000, Hamish Moffatt wrote:
> On Sun, Jun 22, 2003 at 10:49:54AM +0200, Bernd Eckenfels wrote:
> > On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> > > Tell me, you seriously think that there is a libc5 program still around
> > > that uses DRI ? Hell, libc5 was abandoned well before DRI even existed.
> > 
> > the only libc5 program I do use is netscape 4.77 because it is compatible to
> > some pages where mozilla/opera/konquerror fails. I would hate to reboot, to
> > just open that page.
> 
> Tried mozilla recently? It's a thousand times better than Netscape 4.7x
> was... Although I've still had it vanish a couple of times recently. It
> doesn't hang like NS though.

There are some sites that still require Netscape 4.77. A good example is
an online banking site here in Belgium, which 'supports' Linux, but you
need to use Netscape to be able to use that site.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.

Re: Open questions of package descriptions (Was: Bug#198665: ITP: pmk...)

[Sven Luther]

On Wed, Jun 25, 2003 at 06:40:45PM +0300, Jarno Elonen wrote:
> > > > * lose the article
> > > Why?
> > >
> > > > * do not capitalize the beginning of the description unless a proper
> > > >   noun, proper adjective, abbreviation, or acronym requires it
> > > Why?
> 
> Argh, we really should decide these two points now and for good. Just today I 
> received through DDTP a description correction that only consisted of 
> capitalization of the first letter. I don't care one bit about which way 
> should become official but we need the consistency.

Let's test the new voting mechanism we just voted to propose a GR about
this ?

Friendly,

Sven Luther

[proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)

[Andreas Barth]

* Michael Banck ([EMAIL PROTECTED]) [030626 08:20]:
> On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> > What does oppose us to make subarchitectures quite more easy than now?
> > (That would also be useful for the AMD Opteron and the like that could
> > use normal i386-code, but can profit from optimized code.)

> Nothing opposes it, we're just missing something: The correct patch.

I would start with a proposal first before writing code. Below is a
draft, comments to it? (I know it doesn't specify every detail. It is
a start, not more nor less, and it should be expanded if acceptable in
general. Also a list of subarchitectures must be created. I'm also
willing to produce code once this or another proposal is accepted.)


DRAFT - Subarchitectures for debian [0.1]

Subarchitectures are an extension to a given architecture that
provides optimized binaries that work only (optimized) on a part of
machines of the whole architecture. For example: Code using the
MMX-extensions can not work on all i386-machines. In this text I will
use architecture_subarchitecture or _subarchitecture in examples if
speaking of a subarchitecture (e.g. i386_i386). This text speaks only
of the debian archive and the user interface at installing packages.
If this proposal is adopted it must be expanded to the packaging tools
of course.


Goal:

The addition of subarchitectures must not break the current archiving
system, but enhance it. On the other hand, it must be easy to use and
most transparent to the users. I assume that most packages need not to
be present in an extra subarchitecture-specified version in the
archive, otherwise it would be useful to make a full new architecture.


control-Files:

The syntax of the control-Files is extended in the following way: The
field "Filename" gives the default file for this package. It must be
able to run on each machine of the given architecture, as tools not
knowing of subarchitectures will use this file. (Of course it might be
neccassary to use the standard emulator provided by debian as
discussed at the moment for i386_i386. And I didn't say "make good
performance". No, it just must run. It might be really very
suboptimal, e.g. using much too much emulation code as in "optimized
for _i686, opcodes from _i586, running on _i386, and opcode emulation
in the default linux kernel by debian".)

It is possible to specify another file for subarchitectures with
"Filename[+-]", e.g. Filename-i486. A '-' says: Use
this file exactly for the given subarchitecture. A '+' means: For this
and any 'higher' subarchitecture, unless there is a closer match. '+'
has the advantage of making the control-files a bit smaller, but might
be too unfocussed. So both alternatives are given, and the package
maintainer can choose which one suits better in his case.



Meta-Subarchitectures:

Sometimes it is usefull to put some subarchitectures together again by
a specific criterium like existence of a MMU. For this 
meta-subarchitectures can be used.



Creating of new subarchitectures (and exceptions to the said):

If a new subarchitecture is created there are usually no specific
files for it at the beginning. But it is usually suboptimal to start
at the very beginning and the lowest common denominator for the whole
architecture. So at selecting the filename of an old package for a new
subarchitecture the selecting tools uses instead a predefined other
subarchitecture. (As a simple example just imagine Debian is running
on _i286, _i386 and _i486 and we just created new _i486. If a system
using _i486 is installing an old package, the selection tools just
behaves as the system is _i386.) "Old" is a package that gives a
Standards-Version where the given subarchitecture was not defined.



Packages only for parts of the architecture:

Sometimes a package is only usable on specific subarchitectures
because of allowing to manipulate specific things, eg microcode
updates, http://packages.debian.org/microcode.ctl. In this case the
package must not specify the filename-field in the control-file. The
package selection tools must show by default these packages exactly on
the subarchitectures where it provide files. Such a package must make
a Pre-Depend on an dpkg-Version knowing of subarchitectures and such a
package must not be uploaded to woody or any older release, including
security or proposed-updates.



Next steps:

I put this list up on http://home.arcor.de/andreas-barth/subarch.html
and will update this file according to the discussion.

The next steps are to get a decision whether to use subarchitectures
or not, and about the above proposal. As soon as this is done the next
steps are to enhance the archive tools. But step after step.


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

Re: Please don't misuse the debian/changelog to close bugs!

[Branden Robinson]

On Wed, Jun 25, 2003 at 02:33:49PM -0400, Matt Zimmerman wrote:
> On Wed, Jun 25, 2003 at 07:34:23PM +1000, Herbert Xu wrote:
> 
> > 2. debian/changelog readers -- No change.  They have lost a slight bit
> > information that is irrelevant for the purpose of documenting Debian
> > changes.
> 
> I am one of these readers.  I do this.  A lot.  Every day.  And I am telling
> you that the method that I have suggested in previous threads is VERY
> HELPFUL to me.  So, while you may disagree, do not misrepresent my
> situation.

Perhaps Herbert means to refer only to debian/changelog readers he cares
about.  :)

-- 
G. Branden Robinson|   The key to being a Southern
Debian GNU/Linux   |   Baptist: It ain't a sin if you
[EMAIL PROTECTED] |   don't get caught.
http://people.debian.org/~branden/ |   -- Anthony Davidson


pgprHCzrFwbfj.pgp
Description: PGP signature

postrm hangs after restart of apache

[Uwe Steinmann]

Hi,

I'm currently trying to write a postrm file for a debian
package containing a php4 web application. During postinst
I did set up apache und PostgreSQL. When I try to purge
or remove the package, the postrm bash script fails quite
early after I had removed the included http.conf file
of my application and tried to restart apache. Actually
it doesn't fail but simply got stuck. I need to Ctrl-C
to get out.

The following code within postrm

  remove)
# Coments include file on the main config of the webserver
if [ -f /usr/share/wwwconfig-common/apache-cominclude_all.sh ]; then
  for server in $webservers; do
. /usr/share/wwwconfig-common/apache-cominclude_all.sh
if [ "$status" = "comment" ]; then
  restart="$restart $server"
 fi
  done
fi

# Restart modified webservers
if [ -f /usr/share/wwwconfig-common/restart.sh ]; then
  servers="apache-ssl apache"
  . /usr/share/wwwconfig-common/restart.sh
  # need some sleep, otherwise this skript hangs
  sleep 5
fi
  ;;


produces

...

++ log=Include of /etc/us-adressdatenbank/apache.conf found in apache
config files, commenting.Commenting import for
/etc/us-adressdatenbank/apache.conf in /etc/apache/httpd.conf.apache
needs to be restarted.
++ '[' -x /etc/init.d/apache ']'
++ /etc/init.d/apache restart
+ sleep 5
+ '[' remove = purge ']'
+ exit 0

It appears like the 'sleep 5' which I added for debugging has improved
the situation. /var/log/apache/error.log contains lines like

[Thu Jun 26 12:05:09 2003] [crit] (98)Address already in use: make_sock:
could not bind to port 80

which sounds like the restart failed. If that is the problem, could
somebody enlighten me on how to fix it. 

Thanks for the help

  Uwe
-- 
  MMK GmbH, Universitaetsstr. 11, 58097 Hagen
  [EMAIL PROTECTED]
  Tel: +2331 840446Fax: +2331 843920


pgphnL4iS9uFF.pgp
Description: PGP signature

Re: Packages: an average 66321 bytes per line of description

[Joey Hess]

Darren Salt wrote:
> I demand that Dan Jacobson may or may not have written...
> 
> > I was hoping that maintainers of multi-megabyte packages would do the
> > package justice by giving an adequate description.
> 
> "I have here a 20K package. Should it have a 1/3-line description?"

I dunno, but I am working on expanding uqm-content's 6 lines to
something more appropriate to its number of files (11.5 thousand). Maybe
.. 600 lines?

Now I'm really glad uqm-voice (100+ mb) is not going into the archive
anytime soon. I have more important books and/or epic poetry to write
than a proper Description for that monster.

> ;-)

-- 
see shy jo


pgpCAAYOlAG7q.pgp
Description: PGP signature

Bug#198911: ITP: python-simpletal -- An independent implementation of the TAL, TALES and METAL languages

[Fredrik Steen]

Package: wnpp
Version: unavailable; reported 2003-06-26
Severity: wishlist

* Package name: python-simpletal
  Version : 3.3
  Upstream Author : Colin Stewart <[EMAIL PROTECTED]>
* URL : http://www.owlfish.com/software/simpleTAL/
* License : BSD(?)
  Description : An independent implementation of the TAL, TALES and METAL 
languages

TAL is the language used in Zope to power ZPT (Zope Page Templates), and
is a nifty template language. TAL is written in Python, and so can be used
by Python programs that wishes to generate HTML or XML.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux monster 2.4.19-xfs #3 Fri Feb 14 17:37:43 CET 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US (ignored: LC_ALL set)

Bug#189329: ITP: gnome-swallow - meta-applet to embed any application in the GNOME panel

[Josselin Mouette]

submitter 189329 [EMAIL PROTECTED]
retitle 189329 ITP: gnome-swallow - meta-applet to embed any application in the 
GNOME panel
thanks

I've prepared packages for gnome-swallow at
http://people.debian.org/~joss/packages/ and
will upload them soon if everything is fine.

* Package name: gnome-swallow
  Version : 1.1
  Upstream Author : Peter Amstutz <[EMAIL PROTECTED]>
* URL : http://www-unix.oit.umass.edu/~tetron/technology/swallow/
* License : GPL
  Description : meta-applet to embed any application in the GNOME panel

The swallow applet can "eat" any X11 window into the GNOME 2 panel. The
application then displays inside the panel instead of being in a window.

Its primary goal is to allow use of dockapps with the GNOME desktop.
-- 
 .''`.   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?=

Announcement: APT Secure

[Isaac Jones]

Greetings :)

"APT Secure" is the working name of a project to add to APT the
ability to verify the authenticity of Debian packages.  It
accomplishes this via a chain of trust which is initiated by the
package maintainers and ends on the installing machine.

This is a call to the community to help test and audit this patch to
APT, and to eventually participate in the policy discussion about the
patch.

Please see http://monk.debian.net/apt-secure/ for more information and
to download Debian packages.

There's also a mirror here:
http://people.debian.org/~walters/monk.debian.net/


peace,

Isaac & Colin

ximiam connector

[Thomas E. Vaughan]

Is there anyone else out there trying to run Connector on
Debian (sid)?

Although Ximian strongly discourages a direct download of
Connector (because Ximian urges the use of Red Carpet), the
binaries are available at
.

Unfortunately, of course, there is no Debian package at the
download site.  I purchased last October a license for
Connector because, at the time, Debian support was
supposedly forthcoming.  Although I never have used it, the
license that I purchased should still work if only I can
figure out how to make one of the RPMs from the Connector
download page install properly onto my Debian sid system.

I've tried alien on a couple of the packages, but so far, no
good.

It would be very cool to make this work.

-- 
Thomas E. Vaughan <[EMAIL PROTECTED]>

Re: Application files in $HOME

[Daniel Ruoso]

Yes, I did it, but I'm not talking about me. I'm talking about a newbie
user who doesn't understand why these files are in his home directory. 

This happens in the company I work... the administrative office works in
debian and this people doesn't even know what is "ls". Imagine if they
can understand which files could be deleted whitout destroying the
entire department.

And anyway, this doesn't need to be made in one day, think about
debconf, there are packages that still doesn't use it and nobody died.


Em Qui, 2003-06-26 às 04:12, Adam Majer escreveu:
> On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote:
> > Hi,
> > 
> > Recently I had a problem of exceeded quota in my home directory, so I
> > went cleaning it, and I saw many and many files and directories with
> > configurations for applications that I've runned in the past, but that 
> > packages were purged from my system a long time ago, so what is the idea
> > (that can be a proposal)?
> > 
> > What if the packages tells to dpkg which files or directories it will
> > create on the user's home directory and when a package is purged the
> > user could run a program to purge the files of packages that no longer
> > exists. This will also help to know what these files means after all, I
> > thought about a browser to inspect application's files in my home, so it
> > will be easier to decide which files I don't want anymore...
> > 
> > What is needed?
> > 
> > The packages should have a control file (like conffiles) that tells
> > which files this package will create.
> > 
> > A repository to store this information so the user can browse it.
> > 
> > A userconfpurge program that the user runs to remove purged packages
> > configuration files
> > 
> > A browser to associate the files with the packages and manage them (so
> > the user can tell: I don't use icewm anymore, please remove it's
> > configuration files).
> > 
> > Is there risk involved?
> > 
> > I don't know if different packages create conf files with the same name,
> > if it does so, it would be necessary to avoid this practice.
> 
> This would require a lot of work on the part of each maintainer to see
> which files get created where. One would need to change the Policy as well
> to require maintainers to actually use such a "registry".
> 
> I say it is not worth it. Just do a `ls -la` and delete the really old
> stuff that you know you don't need. Or even better, add yourself as 
> a new user to the system, copy all the stuff you need from the old
> account, and when ready, remove the old account with all the directiries :)
> 
> - Adam

Re: Bug#198158: architecture i386 isn't i386 anymore

[David B Harris]

On Wed, 25 Jun 2003 14:04:54 -0500
Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> And not only 80386 needs this - There is the Sparc64 port which would
> also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> had support for subarchtectures, not only would the ix86 mess be able to
> be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> you fancy). And I am sure this can somehow help maintain the non-Linux
> ports - NetBSD gives us the potential to bring Debian to _many_ new
> platforms. 

No it doesn't. I've yet to even hear of an architecture that NetBSD runs
on but which Linux doesn't. They just have a different definition of
"architecture" than us. (ie: our "hppa" may be three or four arches to
the NetBSD kernel folk.)


pgpecAblVDzu4.pgp
Description: PGP signature

Bug#198924: ITP: gpe-julia -- Julia/Mandelbrot set generator for GPE

[Moray Allan]

Package: wnpp
Version: unavailable; reported 2003-06-26
Severity: wishlist

* Package name: gpe-julia
  Version : 0.0.5
  Upstream Author : Moray Allan <[EMAIL PROTECTED]>
* URL : http://gpe.handhelds.org/projects/GPE-games.shtml
* License : GPL
  Description : Julia/Mandelbrot set generator for GPE

gpe-julia is a fixed-point fractal drawing program for the GPE Palmtop
Environment. It can draw the Julia set for a particular point, or the
Mandelbrot set. You can zoom in to look more closely at areas of interest.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8

Re: Application files in $HOME

[Drew Scott Daniels]

Is connecting files to packages like this part of cruft? A potential
wishlist item for cruft?

 Drew Daniels

Report to Sender

[L29DSG01]

Incident Information:-

Database:   d:/lotus/domino/data/mail3.box
Originator: 
Recipients: <[EMAIL PROTECTED]>
Subject:Re: Application
Date/Time:  06/26/2003 01:21:10 PM

The file attachment your_details.zip (details.pif) you sent to the
recipients listed above was infected with the W32/[EMAIL PROTECTED] virus and 
was
deleted.

Re: Retirement, etc

[Andrew Lau]

On Wed, Jun 25, 2003 at 02:08:45AM -0700, Joseph Carter wrote:
> Take care everyone!  =)

Best wishes for the future knghtbrd. Your quips in fortunes have
provided me with many chuckles whenever I logon. Too bad I'm too young
to #debian-devel to have ever seen one of your live performances.

Yours sincerely,
Andrew "Netsnipe" Lau

-- 
--
* Andrew "Netsnipe" Lau Computer Science & Student Rep, UNSW *
*   # apt-get into itDebian GNU/Linux Package Maintainer *
*   *
* 1024D/2E8B68BD: 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
--


pgpndL8dEQqsm.pgp
Description: PGP signature

Re: Packages: an average 66321 bytes per line of description

[Daniel Burrows]

On Wed, Jun 25, 2003 at 07:46:19AM +0200, Thomas Viehmann <[EMAIL PROTECTED]> 
was heard to say:
> Daniel Burrows wrote:
> > On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek <[EMAIL 
> > PROTECTED]> was heard to say:
> > 
> >>>Not all of it, but you can't object to duplicating a single sentence saying
> >>>what it is.
> >>
> >>When the sentence in question is the one that goes in the short
> >>description, and already fills the available space without prepending
> >>"runtime files for foo "?  Is the concern here with the short descs (I
> >>don't expect much from short descs of affiliate packages), or with the
> >>long descs?
> >   Long descriptions.  See, eg,
> >   libchipcard20-dev
> So this should read like:
 This packages [sic] contains the development files for libchipcard20.
 .
>  libchipcard20 provides an API for accessing smartcards. Examples are memory
>  cards, as well as HBCI (home banking), German GeldKarte (electronic
 small change), and KVK (health insurance) cards.
 The upstream homepage is .
> ?

  That looks good with a little editing.  (s/packages/package/ is the
main thing I see)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   I used to be indecisive, but now I'm not sure.|
\--- (if (not (understand-this)) (go-to http://www.schemers.org)) /

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Ralf Hildebrandt]

* Wouter Verhelst <[EMAIL PROTECTED]>:

> > Tried mozilla recently? It's a thousand times better than Netscape 4.7x
> > was... Although I've still had it vanish a couple of times recently. It
> > doesn't hang like NS though.
> 
> There are some sites that still require Netscape 4.77. A good example is
> an online banking site here in Belgium, which 'supports' Linux, but you
> need to use Netscape to be able to use that site.

Even if you use konqueror and change the UserAgent it provides?

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   [EMAIL PROTECTED]
Charite Campus MitteTel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Hey, Debian-devel! T e en e jac ulati0n - h ard actl0ns! CTJE ZyqUNtT

[vuhiki]

Title: FE



  Female 
$qulrters
  gu$hlng 
0rga$m$
  publiC 
urlnatl0n
  hldden 
t0lLet cam$
  and m0re, 
m0re, m0re...
  3 CW0dgtERX8tZ5R ! 
  ARE 
Y0U R*E*A*D*Y - lT'$  F R E E 
?!
   V0OBItjiLaT 4Vlc 
tfE
    
  R=E=|V|=0=V=E
  g6Tlod5dbn276NXLfxUpHxqfqcquw

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Wouter Verhelst]

On Thu, Jun 26, 2003 at 08:23:04PM +0200, Ralf Hildebrandt wrote:
> * Wouter Verhelst <[EMAIL PROTECTED]>:
> 
> > > Tried mozilla recently? It's a thousand times better than Netscape 4.7x
> > > was... Although I've still had it vanish a couple of times recently. It
> > > doesn't hang like NS though.
> > 
> > There are some sites that still require Netscape 4.77. A good example is
> > an online banking site here in Belgium, which 'supports' Linux, but you
> > need to use Netscape to be able to use that site.
> 
> Even if you use konqueror and change the UserAgent it provides?

AIUI, yes. They use some bugs in NS as 'features'. However, I'm not a
customer with that bank (mine works almost perfectly with mozilla (at
least to an amount that makes it useful for me)), so I can't give you
any details

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.

Re: apt ignores -o DPkg::Options ?

[Matt Zimmerman]

On Thu, Jun 26, 2003 at 12:11:07PM +0400, Nikita V. Youshchenko wrote:

> Seems that apt-get ignores -o DPkg::Options.

http://lists.debian.org/deity/

> So dpkg is called without any options from DPkg::Options ...
> Should this be reported as a bug in apt, or I am doing something wrong?

It's a quirk.
apt-get -o 'dpkg::options::={...}' will do what you want.

> P.S.
> While exploring this issue, I looked at apt open bug list. I was surprised
> how HUGE it is. Can't believe that apt, possibly the most important Debian
> package, is poorly maintained...

- 263 of the bugs (72%) are minor and wishlist bugs.

- There are 2 release-critical bugs.  One of them, in my opinion, should be
  downgraded.

- There are 6 'important' bugs

- Several of the bugs have many (sometimes 10 or more) duplicates.  apt is a
  very popular package, and most people don't bother to check if their bug
  is already reported.  Even when they do, the long list of minor and
  wishlist bugs makes it hard to find things without a search capability.

- Some people (especially DAN JACOBSON) think that it is very clever to file
  dozens of bugs for features that they would like for apt to have, and
  complain about the documentation without providing patches to improve it.
  This clutters the bug list even more.

- I and others have spent a great deal of time over the past few months
  reviewing, merging, reassigning and otherwise helping to make the bug list
  more manageable.

- apt 0.5.5 closed about 100 bugs.

In summary: stop complaining, and disregarding the efforts of others, and
put forth some effort of your own.  Complaining on debian-devel doesn't get
bugs fixed.

-- 
 - mdz

Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)

[Michael Banck]

On Thu, Jun 26, 2003 at 11:40:21AM +0200, Andreas Barth wrote:
> * Michael Banck ([EMAIL PROTECTED]) [030626 08:20]:
> > On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> > > What does oppose us to make subarchitectures quite more easy than now?
> > > (That would also be useful for the AMD Opteron and the like that could
> > > use normal i386-code, but can profit from optimized code.)
> 
> > Nothing opposes it, we're just missing something: The correct patch.
> 
> I would start with a proposal first before writing code. Below is a
> draft, comments to it?

Sorry, I don't have time right now to look at it. But did you consider
marcus' several years old arch-handling proposal[1]?

Also, please note that at least half of the dpkg-maintainers don't read
-devel, you probably want to post this to -dpkg. Incidently, there is a
proposal and patch by Gerhard Tonn for handling lib64 under
discussion[2].


cheers,

Michael

-- 
[1] http://master.debian.org/~brinkmd/arch-handling.txt
[2] http://lists.debian.org/debian-dpkg/2003/debian-dpkg-200306/msg00032.html

Re: Bug#198158: architecture i386 isn't i386 anymore

[Matt Zimmerman]

On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote:

> On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote:
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms. 
> 
> It's not that many actually.  The only CPU that NetBSD claims to support
> but Linux doesn't is the pc532.  Also the (umerged) Linux VAX and arm26
> aren't really useable unlike their NetBSD counterparts.

However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian
does.

-- 
 - mdz

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Mathieu Roy]

Wouter Verhelst <[EMAIL PROTECTED]> a tapoté :

> On Thu, Jun 26, 2003 at 12:21:22AM +1000, Hamish Moffatt wrote:
> > On Sun, Jun 22, 2003 at 10:49:54AM +0200, Bernd Eckenfels wrote:
> > > On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> > > > Tell me, you seriously think that there is a libc5 program still around
> > > > that uses DRI ? Hell, libc5 was abandoned well before DRI even existed.
> > > 
> > > the only libc5 program I do use is netscape 4.77 because it is compatible 
> > > to
> > > some pages where mozilla/opera/konquerror fails. I would hate to reboot, 
> > > to
> > > just open that page.
> > 
> > Tried mozilla recently? It's a thousand times better than Netscape 4.7x
> > was... Although I've still had it vanish a couple of times recently. It
> > doesn't hang like NS though.
> 
> There are some sites that still require Netscape 4.77. A good example is
> an online banking site here in Belgium, which 'supports' Linux, but you
> need to use Netscape to be able to use that site.


With the current mozilla version, everything that works with a
netscape 4.x works with mozilla.

If not, write them to work on w3c standards compliances.

Regards,



-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Please don't misuse the debian/changelog to close bugs!

[Matt Zimmerman]

On Thu, Jun 26, 2003 at 07:53:39AM +1000, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > On Wed, Jun 25, 2003 at 07:34:23PM +1000, Herbert Xu wrote:
> > 
> >> 2. debian/changelog readers -- No change.  They have lost a slight bit
> >> information that is irrelevant for the purpose of documenting Debian
> >> changes.
> > 
> > I am one of these readers.  I do this.  A lot.  Every day.  And I am telling
> > you that the method that I have suggested in previous threads is VERY
> > HELPFUL to me.  So, while you may disagree, do not misrepresent my
> > situation.
> 
> Please pay more attention to the context.  I was responding to
> John Robinson's suggestion to send a message to [EMAIL PROTECTED]

That's interesting, because your justification sounded exactly the same as
the one that you used when arguing in favor of leaving this information out
of the changelog.

-- 
 - mdz

Free shipping & Dr. consultation

Title: Buy Generic Sildenafil Citrate Online (the active ingredient in V

	
	
 
		
			

	Generic V i a g r a
			


	
		
			.
	


	
		
			
			INTRODUCTORY OFFER
			For the first time ever, a generic version of V i a g r a® is available to you. GSC-100, the generic equivalent of V i a g r a®, gives you the exact performance and power as V i a g r a®, for HALF THE COST.
			
			Act now, or risk missing out on special promotional pricing -- GSC-100 is priced as low as $5.00 per 100mg tablet -- V i a g r a® costs $12.25 per 100mg tablet.
			The doctor consultation and shipping is  F r e e 
of charge, and your GSC-100 will arrive at your door quickly and discretely.  Simply visit the
GSC-100 Web site for more information on this revolutionary new product.
		
		
			
C l i c k Here to Visit Our Website

			
		
	


	
		
			

			





			100% Money Back Guarantee - The First Pharmaceutical to ever be guaranteed
			




	
	

			
		
	

Re: Bug#198158: architecture i386 isn't i386 anymore

["Martin v. Löwis"]

Marcelo E. Magallon wrote:
 The patch has been already written:  http://lwn.net/Articles/8634/  I'm
 sure theere's a better link, but that's the best I could extract out of
 google without resorting to bribery :-)
This patch is insufficient. It does not implement xaddl.
Regards,
Martin

Suffering From Bad Credit-itus?

[Credit Counselor]

Title: comp-a







You are receiving this email from Your-Free-Lunch because one of our 
affiliates has notified us that you want to receive third-party offers. If 
that is not the case, please follow the unsubscribe instructions at the 
bottom of this email.


  
 
   
   
   

 
   
   

 
   
   

 
   
   

 
   
   

  
  



Please click here to opt out of future e-mailings.

Re: Please don't misuse the debian/changelog to close bugs!

[Brian Nelson]

Herbert Xu <[EMAIL PROTECTED]> writes:

> Brian Nelson <[EMAIL PROTECTED]> wrote:
>> 
>> It's pointless to go through this again.  Instead, I'll offer a concrete
>> example of the confusion this can create (the original submitter asks
>> for clarification of how the bug was fixed):
>> 
>> http://bugs.debian.org/188740
>
> That's a documentation issue.  debian/changelog is not the place for
> documenting random features.

Huh?  The bug report was a feature request with a patch.  The bug was
closed with the description of "New Upstream Release".  No indication
was given whether the patch was integrated upstream, or implemented
differently (with a different interface).  I don't consider this
information "documentation of random features".

>>> As I have said before, this is incomplete: only bugs that were reported
>>> and identified are listed, and redundant: these changes should be in
>>> the upstream changelog already.
>> 
>> I don't see anything particularly helpful in the upstream changelog for
>> the above example.
>
> Please do not generalise the practice of individual upstream authors.

Uhh, I didn't.  In fact, *you* are the one trying to dictate what goes
in upstream changelogs, which is utterly pointless.  Every upstream is
different, and Debian has absolutely no control what upstream decides to
put in their changelogs.  That's why we must standardize[1] our changelog
entries, so that the pertinent information will be available regardless
of what upstream does.

If the upstream authors for your packages already include accurate
descriptions of bug fixes in their changelogs, then great.  So you have
to spend a couple extra minutes duplicating the descriptions.  Tough.

[1] By which I mean each separate (i.e. not merged) bug closed in a
Debian changelog must get its own changelog entry with a
description.  Separate bugs must get separate descriptions.
Unrelated bugs should never share a changelog entry.  Or something
like that.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpf12QOZu7Tt.pgp
Description: PGP signature

Order Viagra, Diet Pills & more with NO PRESCRIPTION! US doctors and pharmacies! Overnight Shipping spoceqgbdnc w

[Jarrett Zamora]

Title: robin






HI,Debian-cd-request, Medications Prescribed Online, Get Prescribed Viagra,
Diet Pills 

and much more online! Overnight Shipping!! No
Prescription!! Click Here!




sergeifigurinevexr  yhtdet
i x hdchxkb
pgh uhv qbp
Remove


angiospermdamascusinyhl d pcjtyqlxkrcldkrkgdlx
 n
bsgsxuevm kb
 dcvh l


zcl  l nq

Re: apt ignores -o DPkg::Options ?

[Adam Heath]

On Thu, 26 Jun 2003, Nikita V. Youshchenko wrote:

> Hmm...
>
> Seems that apt-get ignores -o DPkg::Options.
>
> [EMAIL PROTECTED]:~> cat /tmp/xxx
> #!/bin/sh
> echo dpkg $*
> exit 1
>
> [EMAIL PROTECTED]:~> LANG=C apt-get -o 'Dir::Bin::dpkg=/tmp/xxx' -o
> 'DPkg::Options={"--xxx";}' install nvi
> Reading Package Lists... Done
> Building Dependency Tree... Done
> The following NEW packages will be installed:
>   nvi
> 0 packages upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
> Need to get 265kB of archives.
> After unpacking 598kB of additional disk space will be used.
> Get:1 http://zigzag.lvk.cs.msu.su stable/main nvi 1.79-20 [265kB]
> Fetched 265kB in 0s (349kB/s)
> dpkg --unpack /var/cache/apt/archives/nvi_1.79-20_i386.deb
> E: Sub-process /tmp/xxx returned an error code (1)

-o dpkg::options::=foo -o dpkg::optons::=bar

Re: [Stefano =)] Bug#198619: Could not perform configuration on libpam0g

[Esteban Manchado Velázquez]

On Wed, Jun 25, 2003 at 05:39:36PM -0400, Sam Hartman wrote:
> 
> [Please cc me; I'm very behind on -devel]
> 
> 
> I'm very confused by this bug and am sufficiently busy this week that
> I'm not going to be able to diagnose it right now.
> 
> Could anyone who has a chance to do so please look at exactly what is
> failing from a dependency standpoint?  
> I get the feeling I'm missing
> something about the interactions between pre-dependencies and
> dependencies and apt.

   I ran into the very same error some days ago. I have no idea about the
cause, but doing random tests, we (at work) found that upgrading to testing
and then to unstable "fixed" the problem. You only have to upgrade libpam or
libpam0g (I'm not sure which of them; the former doesn't exist in unstable,
IIRC), and then you can upgrade normally to unstable. That is, add testing to
your sources.list, do apt-get install libpam/testing, and then upgrade
normally.

   DEBCONF_DEBUG=developer showed nothing, BTW.

   HTH,

-- 
Esteban Manchado Velázquez  - http://www.demiurgo.org
No software patents in Europe! - eurolinux.org - proinnova.hispalinux.es
Join Amnesty International - http://www.amnesty.org/actnow


pgpQijPIPO7rU.pgp
Description: PGP signature

Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Millis Miller]

Package: wnpp
Version: N/A; reported 2003-06-27
Severity: wishlist

* Package name: email
  Version : 1.9.0
  Upstream Author : Dean Jones <[EMAIL PROTECTED]>
* URL : http://www.cleancode.org/email
* License : Custom
  Description : Send email from command line, either via MTA or SMTP, with 
optional encryption

email is a simple command-line program to send emails. It can be 
configured to use either your sendmail installation or directly via
smtp.
 .
 Also, if gpg is installed, it can digitally sign and encrypt outgoing 
emails.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux ayrton 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586
Locale: LANG=C, LC_CTYPE=C

Counter-Proposal: Architecture Versions and Architecture Features

[Julian Mehnle]

Hi all,

Andreas Barth wrote:
> DRAFT - Subarchitectures for debian [0.1]

First, thanks for creating a prototype proposal.

I understand that the your proposed extensions to the Debian package system
are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
these "pseudo-sub-archs" or "alias-sub-archs", though).  I have already
proposed a more genereal extension based on "arch versions" (essentially
equivalent to sub-archs, except that an order is implicitly defined), and
"features".  I'll explain it in more detail, because I think that a more
general approach would also be more flexible for potential future
requirements in the Debian package system.


Architecture Specifiers
---

An arch specifier may specify the exact base arch, arch version, and arch
features that are supported by a given system, or that are required for a
given binary package to work (with or without an emulating kernel).

Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
one or more explicit versions (as I said, these are equivalent to
sub-archs).  An arch version gets appended to the base arch name as
".", the default version being 0.  Thus, "i386" would be
equivalent to "i386.0", and subsequent versions could be "i386.1",
"i386.1foo", "i386.2", and so on.  Arch versions are ordered
alphabetically, with higher versions including the functionality of all
lower versions, i.e. higher arch versions must be downwards compatible. 
Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".

Independently, every arch can, but isn't required to, have one or more
special features beyond what the base arch version supports.  A feature
gets appended to the arch name/version as "+".  For "i386", there
could be features like "fpu", "mmx", "sse", "sse2", etc.  A single arch
specifier can name any number of features, e.g. "i386+3dnow", or
"i386.6+mmx+sse".


Binary Package Files


Binary package files shall have the full arch specifier in their file names
(see below for examples).  Current packages with simple (traditional) arch
specifiers such as "i386" don't require special features beyond what the
base arch version supports, thus the extension is backward compatible.


"control" and "Packages" Files
--

In "control" files, the "Architecture:" field, as before, lists the
architectures supported by the base arch binary packages.  Additionally,
more specific arch specifiers can be listed here.  Binary packages will be
built for every listed arch specifier.  Example:

  Architecture: alpha i386 i386.6+mmx+sse mips

The special "any" arch specifier in the "control/Architecture:" field would
only build binary packages for the base archs.

The "Packages" file of a given base arch would, for every binary package
based on (but of course not neccessarily supporting) that base arch, list
the packages' exact arch specifiers in the "Architecture:" field.  I.e.
although a binary package compiled for "i386.6+mmx+sse" probably will not
run on a real 80386 or Pentium 1 machine (disregarding any emulating
kernels), it will be part of the "i386" base arch nonetheless.


The Package Pool


Binary packages built for an explicit (non-base) arch version, or requiring
special features, like the fictitious "quake2" package mentioned below,
would be stored in the pool normally.  
base arch's pool.


apt and dpkg


There might be several methods for apt and dpkg how to choose which
packages to download and to install.  Generally, binary packages for the
plain base arch will be downloaded and installed unless specified
otherwise.

The 'APT::Architecture' configuration option would specify the *minimum*
arch version and features that must be required by any package to be
installed.  The *maximum* arch version and features supported by the local
system could be configured either as some 'APT::Architecture-Maximum'
configuration or '--arch' command-line option, or as some generic
'/etc/hwarch' config file, or it might even be possible to query the kernel
for this information.

Apt would then choose the binary package compiled for the highest
compatible arch version and the most matching arch features that fulfills
both the minimum and maximum requirements.

Examples:

  Available packages in the fictitious pool:
  (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
  (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
  (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
  (D) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+mmx.deb
  (E) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+sse.deb
  (F) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse.deb
  (G) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse2.deb

  # uname -a
  Linux gray 2.4.20 #1 Fri Apr 4 14:43:45 CEST 2003 i686 GNU/Linux
  # cat /etc/apt/apt.conf
  APT::Architecture "i386";# minimum arch specifier
  APT::Architecture-Maximum "i386.6+mmx+sse";  # 

Re: versions of -dev packages

[Greg Stark]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:

> Here is a script that finds different versions of installed binary packages
> with the same source package name.
> 
> Running this script on some of my systems gave me lots of interesting
> information ...

Indeed it seems to be finding me lots of packages like these:

bash-2.05b# dpkg -L xserver-svga
Package `xserver-svga' does not contain any files (!)
bash-2.05b# dpkg -L guile1.3
Package `guile1.3' does not contain any files (!)
bash-2.05b# dpkg -L libperl5.6
Package `libperl5.6' does not contain any files (!)

I thought when a package's last file was replaced the package was marked
purged. These are all marked "rc", ie, indicating that config files are
present.

-- 
greg

SMT贴片机 YM100VP

[SMT]

YAMAHA: YM100VP；
YV100XG
YV112-3
,

PANASONIC:  MSH2,
MV2C


FUJI CP6系列全新FEEDER




电话：  0755-26364081
E-mail: [EMAIL PROTECTED]

inews path question

[Joey Hess]

I maintain slrn, which can run inews to post news. We apparently have
three inews programs in debian; inewsinn puts it in /usr/bin/inews,
while inews and cnews put it in /usr/lib/news/inews. My question is how
is a program like slrn supposed to find an inews program to run? If it
searches PATH it will only find inewsinn's inews. Of course the user can
configure it (via inews_program in the rc file) to use any inews
program, but this is an extra step to get working news posting. Would an
alternative make sense for inews?

-- 
see shy jo


pgpSOurYoUYYC.pgp
Description: PGP signature

Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)

[Adam Heath]

On Thu, 26 Jun 2003, Michael Banck wrote:

> Also, please note that at least half of the dpkg-maintainers don't read
> -devel, you probably want to post this to -dpkg. Incidently, there is a
> proposal and patch by Gerhard Tonn for handling lib64 under
> discussion[2].

Well, considering there are most likely only 2 dpkg maintainers(of which I am
one), and I read your mail, does that mean the other isn't on this list?

Re: Application files in $HOME

[Richard Braakman]

On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote:
> What if the packages tells to dpkg which files or directories it will
> create on the user's home directory and when a package is purged the
> user could run a program to purge the files of packages that no longer
> exists.

I have a better idea :)  What if packages don't leave droppings in my
home directory in the first place?  I have all sorts of dotfiles (and
even dot-directories) that I never asked for.  It's reasonable for a
program to install a dotfile when I configure it differently from the
default, but there's no reason to create a dotfile that's identical
to the default.

In addition to being annoying in themselves, such useless dotfiles
get in the way when a newer version has different defaults or
incompatible configuration fields.

When I do configure a program (if it doesn't have an interactive
configuration interface), I want to do it by creating a small,
human-editable file that contains the _differences_ from the defaults.
So even then I have no use for a copy of the default configuration.
(If I want an example, I can look in /usr/doc/$foo/examples, which is
a better place for it than $HOME.)

Richard Braakman

Don't let your computer crash

  

  
  
  Norton Antivirus 2003 Deluxe Package
  
  Downloadable Version
   
  
  


  
  Sale 59.95  only $ 29.99 
   Limited Time>>>CLICK
  HERE TO PROTECT YOUR COMPUTER<<<
  Features - Norton
  AntiVirus 2003Norton AntiVirus is the world's
  most trusted anti-virus solution. Now it repairs common virus
  infections automatically, without interrupting your work. 
  
  NEW! Automatic removal of many
  viruses lets you work without interruption. 
  
  NEW! Script Blocking detects
  script-based threats such as the "I Love You" and "Anna Kournikova"
  viruses, even before new virus definitions are created for them. 
  
  NEW! Scans and cleans outgoing
  e-mail messages to prevent sending infected files from your PC. 
  
  NEW! Built-in links take you
  directly to the Symantec Security Response Web site (formerly known as
  Symantec AntiVirus Research Center) for additional information on
  specific viruses just when you need it most. 
  
  Automatically scans e-mail messages and attachments in standard POP3
  clients, including Microsoft Outlook, Eudora, and Netscape Mail.
  
  
  Protects against viruses, Trojan horses, and malicious ActiveX code
  and Java applets, even in compressed files.   
  
  >>>CLICK
  HERE TO PROTECT YOUR COMPUTER<<<


  
  
  We are strongly against sending
unsolicited emails to those who do not wish to receive our special mailings.
You have opted in to one or more of our affiliate sites requesting to be
notified of any special offers we may run from time to time. We also have
attained the services of an independent 3rd party to overlook list
management and removal services. This is NOT unsolicited email. If you do
not wish to receive further mailings, please 
  
  
  CLICK
HERE to be removed from the list. Please
accept our apologies if you have been sent this email in error. We honor all
removal requests.

  

How to Avoid GPL Issue

[G. C.]

Dear Sir or Madam,
Currently we are trying to port some third party code to Linux kernel. Some 
modules of third party code need to be ported into Linux kernel and some 
drivers need to be ported from Vxworks to Linux drivers. The problem we have 
is that this third party does not allow us to publicize its code as Linux 
GPL requires.

Is there any approach that we can avoid publicizing the third party code 
while porting to Linux? Do we need to write some shim layer code in Linux 
kernel to interface the third party code? How can we do that? Is there any 
document or samples?

Your assistance is deeply appreciated,
Thanks,
A Linux Lover
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus