woody CD not bootable with adaptec + scsi-cdrom

[Goswin Brederlow]

Hi,

I just crasht my system working on libsafe and hat to boot from CD.

I the discovered that the woody CD (linuxtag prerelease) doesn't
boot. I heard of similar for the real woody release CDs on irc.

Can anyone boot the CDs, which one of the set and what hardware?
Same if you can't boot.


Also whats different between potato and woody? potato has this
multiboot thing and woody not anymore, right? What was wrong with it?
Seems to be more compatible the old way.

MfG
Goswin

Bug#159037: general: Time Problem

[Goswin Brederlow]

"Matt Filizzi" <[EMAIL PROTECTED]> writes:

> Package: general
> Version: N/A; reported 2002-08-31
> Severity: normal
> Tags: sid
> 
> I don't know what is causing this problem but all I know is that I have
> narrowed it down to being caused either by a package or by the install
> system.  I installed from the woody install disks then upgraded to sid.
> What happenes is that the time jumps ahead then back, eg (this is output
> from "while true; do date;done"
> 
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> 
> The only thing I did differently then previous installs was I told the
> installer that it could set the bios go UTC.  The only time it is really
> noticable is when in X, the screensaver kicks in when it jumps.

ntpdate, ntp, chrony,  installed?

Maybe two of them, one with summer time, one without in its config?

MfG
Goswin

Re: Non-Intel package uploads by maintainer

[Goswin Brederlow]

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> Goswin Brederlow <[EMAIL PROTECTED]> writes:
> 
> > There are several reasons not to do this.
> > Don't upload binaries at all.
> 
> Why?
> 
> > The autobuilder will check the build-process of your package.
> 
> YOU should do that.

To err is human.

> > It will build in a clean chroot with proper build-depends.
> > With proper versions of all tools.
> 
> man pbuilder|sbuild|chroot by hand
> 
> There are enough ways to test your Build-Depends.
> And if you have an up2date chroot the versions of the Depends should be
> alright.

How many maintainer realy bother? And then there are still mistakes.

MfG
Goswin

Re: Non-Intel package uploads by maintainer

[Goswin Brederlow]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Sun, Sep 01, 2002 at 12:17:01AM +0200, Goswin Brederlow wrote:
> > Don't upload binaries at all.
> > 
> > The autobuilder will check the build-process of your package. It will
> > build in a clean chroot with proper build-depends. With proper
> > versions of all tools.
> > 
> > If you upload binaries you get the usual bugs of missing
> > build-depends, wrong versions of tools or libraries and so on. Just
> > because you had them installed.
> 
> In his case, most of these will be noticed by the remaining nine buildds,
> anyway. 

But the uploaded binaries will still be in the archive with broken
sources.

MfG
Goswin

Virus Alert

[abuse]

We have detected a virus (WORM_KLEZ.H) in your mail traffic sent from [EMAIL 
PROTECTED] in the file href.exe on 08/31/2002 21:26:41. We took the action 
delete. If you have questions regarding files or updating/installing Anti-virus 
protection on your PC, please contact your e-mail administrator or help desk.

Re: Request Virtual Package: cl-sql-backend

[Kevin Rosenberg]

On Sat, Aug 31, 2002 at 07:35:08PM -0600, Kevin Rosenberg wrote:
> In violation of policy (sorry!), I've been using a virtual package in

Oops, never mind. I see now in the policy manual:
  "Packages MUST NOT use virtual package names (except privately, amongst
   a cooperating group of packages)"

This virtual package name is only used by the single source package.

-- 
   Kevin Rosenberg|  .''`.  ** Debian GNU/Linux **
  http://b9.com/debian.html   | : :' :  The  universal
  GPG signed and encrypted| `. `'  Operating System
 messages accepted.   |   `-http://www.debian.org/

Re: Debian based CD based distros

[Philip Charles]

On Sat, 31 Aug 2002, Dale Scheetz wrote:

***
> The main reason I mention these two excellent Debian "spin-offs" is that
> they both do a remoarkable "on-the-fly" hardware configuration for X and
> everything is wonderfully integrated and "ready-to-use" to a much greater
> extent that Debian is by itself. Those folks working on installation and
> configuration of the system could learn a lot from studying these CDs, not
> that we need to deliver a CD based release, but that we need a much
> quieter and more user friendly installation.

Don't forget Libranet, http://www.libranet.com, an excelent Debian based
distribution.  Interesting use of the GPL as well.

Phil.
--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Request Virtual Package: cl-sql-backend

[Kevin Rosenberg]

Hello,

In violation of policy (sorry!), I've been using a virtual package in
my source package cl-sql. cl-sql defines a number of binary packages.
The binary package cl-sql depends on the presence of one at least one
cl-sql database backend. Thus, I have each of the binary database
backend packages Provides: the virtual package cl-sql-backend.

I'm filing a wishlist bug agains debian-policy requesting the addition
of the virtual package cl-sql-backend. As per policy, I'll forward the
either the consensus or lack of objections to
[EMAIL PROTECTED]

-- 
   Kevin Rosenberg|  .''`.  ** Debian GNU/Linux **
  http://b9.com/debian.html   | : :' :  The  universal
  GPG signed and encrypted| `. `'  Operating System
 messages accepted.   |   `-http://www.debian.org/

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Richard Braakman]

On Sat, Aug 31, 2002 at 05:15:00PM -0500, Adam Majer wrote:
> > we definitely need an mp3 decoder in debian if we want to fight the
> > patent oppression at all. i think we need another branch for that kind
> > of problems.
> 
> lol, I doubt it would help. Just go to US patent office website and 
> do a search on stuff like on title try "The Wheel". :) I know, it's getting
> ridicules. What need to be done is for someone to sue the patent
> office for stifling innovation and promoting monopolies. ie. something it
> was originally created to fight.

The wheel is patented in Australia, not in the US.  On the other hand,
in the US there is a patent on using a laser pointer to exercise your cat,
and one on swinging sideways on a playground swing.

I do think that discouraging the use of patent-encumbered "standards"
is a useful way to fight patent oppression.  It sends the message
that a patented standard is a dead standard.  Maybe companies will
review their habits in that light.

> > yes, but only non-free in states that impose patent restrictions. if we
> > have such "non-patented" branch it would be free for users outside the 
> > circle.
> 
> I'm not sure, but an app A that incorporates algorithm BOB and BOB is 
> "patented"
> under a non-GPL license, then I don't think that A can be distributed as 
> a GPL program.

Only if the patent holder for BOB is actively trying to enforce the license.
If you're thinking of GPL section 7, then remember that it only applies
to conditions specifically imposed on you, not merely the threat or
possibility of such conditions.

In general, I don't think we can adopt a useful and consistent stance on
what to do with software that uses patented algorithms.  There are just
too many patents, and just about any program infringes on at least one
of them.  Even worse, it is impossible to prove that a program does NOT
infringe on any patent.  We'll have to consider the details of each case
individually.

Richard Braakman

Re: Non-Intel package uploads by maintainer

[Joerg Jaspert]

Goswin Brederlow <[EMAIL PROTECTED]> writes:

> There are several reasons not to do this.
> Don't upload binaries at all.

Why?

> The autobuilder will check the build-process of your package.

YOU should do that.

> It will build in a clean chroot with proper build-depends.
> With proper versions of all tools.

man pbuilder|sbuild|chroot by hand

There are enough ways to test your Build-Depends.
And if you have an up2date chroot the versions of the Depends should be
alright.

-- 
begin  OjE-ist-scheisse.txt
bye, Joerg Encrypted Mail preferred!
Registered Linux User #97793 @ http://counter.li.org
end

pgpvKBuSiGj1J.pgp
Description: PGP signature

Bug#159037: general: Time Problem

[Matt Filizzi]

Package: general
Version: N/A; reported 2002-08-31
Severity: normal
Tags: sid

I don't know what is causing this problem but all I know is that I have
narrowed it down to being caused either by a package or by the install
system.  I installed from the woody install disks then upgraded to sid.
What happenes is that the time jumps ahead then back, eg (this is output
from "while true; do date;done"

Sat Aug 31 19:07:26 EDT 2002
Sat Aug 31 19:07:26 EDT 2002
Sat Aug 31 19:07:26 EDT 2002
Sat Aug 31 19:07:26 EDT 2002
Sat Aug 31 20:19:01 EDT 2002
Sat Aug 31 20:19:01 EDT 2002
Sat Aug 31 20:19:01 EDT 2002
Sat Aug 31 19:07:27 EDT 2002
Sat Aug 31 19:07:27 EDT 2002

The only thing I did differently then previous installs was I told the
installer that it could set the bios go UTC.  The only time it is really
noticable is when in X, the screensaver kicks in when it jumps.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux beyond.hjsoft.com 2.4.18 #1 SMP Sat Aug 31 10:49:35 EDT 2002 i686
Locale: LANG=C, LC_CTYPE=C

-- no debconf information

Re: Non-Intel package uploads by maintainer

[Josip Rodin]

On Sun, Sep 01, 2002 at 12:17:01AM +0200, Goswin Brederlow wrote:
> Don't upload binaries at all.
> 
> The autobuilder will check the build-process of your package. It will
> build in a clean chroot with proper build-depends. With proper
> versions of all tools.
> 
> If you upload binaries you get the usual bugs of missing
> build-depends, wrong versions of tools or libraries and so on. Just
> because you had them installed.

In his case, most of these will be noticed by the remaining nine buildds,
anyway. 

-- 
 2. That which causes joy or happiness.

Re: Non-Intel package uploads by maintainer

[John Goerzen]

On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote:

> Is there any reason not to do this? It seems that it might speed up the

I do that frequently and it seems to work well.  I use Alpha, PowerPC, and
i386 regularly and all three are machines I use to build on for Debian. 
Sometimes I need a package on more than one arch for my own purposes *right
now*, and there's no reason not to upload the version for another arch to
ftp-master while I'm at it.  Especially since it can take days, even weeks,
for packages to appear from the buildd's.

-- John

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Adam Majer]

On Fri, Aug 30, 2002 at 04:55:46PM +0200, Robert Millan wrote:
> On Fri, Aug 30, 2002 at 10:31:23AM -0400, Joe Drew wrote:
> > On Fri, 2002-08-30 at 10:16, Robert Millan wrote:
> > > currently non-US is the only place where it can be without breaking law.
> > 
> > This is incorrect: mp3 patents exist in non-US places too, like Germany.
> 
> we definitely need an mp3 decoder in debian if we want to fight the
> patent oppression at all. i think we need another branch for that kind
> of problems.

lol, I doubt it would help. Just go to US patent office website and 
do a search on stuff like on title try "The Wheel". :) I know, it's getting
ridicules. What need to be done is for someone to sue the patent
office for stifling innovation and promoting monopolies. ie. something it
was originally created to fight.

> > > having mp3 players in non-free would still be illegal. mpg321 is free
> > > software that complies to DFSG and there's no reason to put it in
> > > non-free or non-free/non-US.
> > 
> > If fraunhofer say that you are allowed to distribute mp3 players for
> > free (but not for cost), then they must be put in non-free. And since
> > they have patents all around the world, they can't be put in non-us.
> 
> yes, but only non-free in states that impose patent restrictions. if we
> have such "non-patented" branch it would be free for users outside the circle.

I'm not sure, but an app A that incorporates algorithm BOB and BOB is "patented"
under a non-GPL license, then I don't think that A can be distributed as 
a GPL program.

Re: Non-Intel package uploads by maintainer

[Goswin Brederlow]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> Since I have access to both Intel and Sparc hardware, it would be possible
> for me to upload both the i386 version and the Sparc version of the binary
> packages when I build a new release.
> 
> Is there any reason not to do this? It seems that it might speed up the
> autobuild process, specially when it is a library like libgmp3 which other
> packages depend upon for their builds...

There are several reasons not to do this.

Don't upload binaries at all.

The autobuilder will check the build-process of your package. It will
build in a clean chroot with proper build-depends. With proper
versions of all tools.

If you upload binaries you get the usual bugs of missing
build-depends, wrong versions of tools or libraries and so on. Just
because you had them installed.

Only reason I see for binary uploads would be for archs that are far
behind or packages that need that little extra time to build. (open
office with its 4G space requirement also comes to mind).

MfG
Goswin

PS: I assume dinstall got fixed to not delete sources-only uploads.

Re: lack of libbz2 bindings [Was: Packages.bz2, ...]

[Darren Salt]

I demand that Stefano Zacchiroli may or may not have written...

> On Sat, Aug 31, 2002 at 01:24:51PM +0200, Torsten Landschoff wrote:
>> You misread the mail. .gz will continue to be available, .bz2 will be
>> there as well and the uncompressed files will be dropped.

> 
>Similarly, the Contents-*.gz files for unstable will probably be
>switching to .bz2 in the not too distant future.
> 

> "switching" sound to me like "changing in favour of", but in facts I'm not
> a native english speaker. Sorry.

It looks to me like it's the files themselves which are doing the
switching... applying s/switching/switched/ gives "switched to". Would I be
right in saying that only the filenames will be changed? ;-)

I'd happily settle for "deprecated in favour of" (and dropped after sarge is
released [1]) since this should allow those of us who are running stable [2]
to grab the occasional binary package from testing or, possibly, unstable.


[1] As opposed to "after sarge releases".

[2] On humanbrain-linux, if you're wondering. ;-)

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| Linux PC, Risc PC | Northumberland | youmustbejoking
| No Wodniws here   | Toon Army  | demon co uk
|   We've got Shearer, you haven't

Join the group mind - become a Borg.

Re: why is /usr/sbin/install-info a perl script!!!

[Joey Hess]

>I am trying to get the glibc debian cvs for 2.2.92 to
> package (it builds and passes make check fine on debian
> ppc sid with the new gcc 3.2.1pre). However the buggy
> perl 5.80 in sid has broken install-info. I looked at 
> a Yellow Dog Linux machine and noticed, however, that they
> had a texinfo 4.2 source package that builds an info
> package with a binary /usr/sbin/install-info instead of
> the perl version we have. Why is that and why don't we 
> just NMU texinfo in sid to start building a binary
> install-info until perl 5.80's regex stops leaking 
> memory like a sieve?

Why are you making such a gigantic fuss and dragging in extra-debian
groups (the LSB) and threatening NMU's when the maintainers of packages
involved are actively working on the problem? Why do you not do basic
reasearch before posting? It might help if you took the time to
understand:

1. What debian install-info does.
2. What GNU install-info does.
3. Why blindly replacing one with the other is stupid.
4. Why perl is segfaulting.
5. Why it is not quite clear if this is a perl bug or an install-info
   bug.
6. Who already knows the answer to all of the above and is working on
   a fix.

.. before mouthing off further on this subject.

-- 
see shy jo


pgp3ZO6lhMjDq.pgp
Description: PGP signature

Re: Non-Intel package uploads by maintainer

[Ryan Murray]

On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote:
> Is there any reason not to do this? It seems that it might speed up the

Save you time, and if you aren't actually following the current status of
the extra archs you build for, you might end up uploading it during an
arch-specific transition, and require it to just be binNMU'd later on.

> autobuild process, specially when it is a library like libgmp3 which other
> packages depend upon for their builds...

It won't speed things up much at all.

> The only problem I can see is in the construction of the dsc file. I get
> one built on the Intel and another one built on the Sparc. Must I do two
> uploads or is there a way to merge the two dsc files?

Only a source build generates a dsc file.  You shouldn't be building source
more than once.  The dsc files should also be identical, in any case.

You _do_ need to use mergechanges on your .changes files and upload it as
one, especially if you are on a slowlink.  Otherwise the autobuilder might
already have started building before your upload finishes, wasting the
CPU (and buildd maintainer's) time.

-- 
Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED])
The opinions expressed here are my own.


pgpoWr6bK5j20.pgp
Description: PGP signature

UNSUBSCRIBE

[PathFinder Software]

Re: lack of libbz2 bindings [Was: Packages.bz2, ...]

[Stefano Zacchiroli]

On Sat, Aug 31, 2002 at 01:24:51PM +0200, Torsten Landschoff wrote:
> You misread the mail. .gz will continue to be available, .bz2 will be
> there as well and the uncompressed files will be dropped.


   Similarly, the Contents-*.gz files for unstable will probably be
   switching to .bz2 in the not too distant future.


"switching" sound to me like "changing in favour of", but in facts I'm
not a native english speaker. Sorry.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
[EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney


pgpGOxudcnhzz.pgp
Description: PGP signature

Re: Non-Intel package uploads by maintainer

[Adam Heath]

On Sat, 31 Aug 2002, Dale Scheetz wrote:

> Is there any reason not to do this? It seems that it might speed up the
> autobuild process, specially when it is a library like libgmp3 which other
> packages depend upon for their builds...

Not really.  Once you upload the pkg, and in the next 15 minute time spam, the
package is ACCEPTED, the buildds will start building it at that point.

And, for small packages, this happens very quickly.

The only slowdown is that those builds need to be signed.

Re: Non-Intel package uploads by maintainer

[Josip Rodin]

On Sat, Aug 31, 2002 at 03:09:52PM -0400, Dale Scheetz wrote:
> Since I have access to both Intel and Sparc hardware, it would be possible
> for me to upload both the i386 version and the Sparc version of the binary
> packages when I build a new release.

Several people do this. It's not exactly common, but it's been done.

> Is there any reason not to do this? It seems that it might speed up the
> autobuild process, specially when it is a library like libgmp3 which other
> packages depend upon for their builds...

I don't believe the buildds would care either way...

> The only problem I can see is in the construction of the dsc file. I get
> one built on the Intel and another one built on the Sparc. Must I do two
> uploads or is there a way to merge the two dsc files?

It just takes a bit of manual hackery, and then update the GPG signature.

-- 
 2. That which causes joy or happiness.

Non-Intel package uploads by maintainer

[Dale Scheetz]

Since I have access to both Intel and Sparc hardware, it would be possible
for me to upload both the i386 version and the Sparc version of the binary
packages when I build a new release.

Is there any reason not to do this? It seems that it might speed up the
autobuild process, specially when it is a library like libgmp3 which other
packages depend upon for their builds...

The only problem I can see is in the construction of the dsc file. I get
one built on the Intel and another one built on the Sparc. Must I do two
uploads or is there a way to merge the two dsc files?

TIA,

Dwarf
-- 
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: Debian based CD based distros

[Eduard Bloch]

#include 
* Dale Scheetz [Sat, Aug 31 2002, 01:42:36PM]:

> The main reason I mention these two excellent Debian "spin-offs" is that
> they both do a remoarkable "on-the-fly" hardware configuration for X and
> everything is wonderfully integrated and "ready-to-use" to a much greater

All this on-the-fly hardware detection became only possible because of
the excellent work done by Klaus Knopper and LinuxTag team. They are
working extensively with the users and do required work to make hardware
setup really working. Unfortunately, most of those autosetup is DWIW
software. It does work with dirty tricks, but those tricks are the only
way to make dirty broken hardware work.

I suggested to use the files generated by Knoppix' tools as the default
X config since it provides the most reliable auto-configuration I have
ever seen, though Branden insisted on using his/Progeny's libdetect
stuff.

Dreaming a bit more, I would prefer having a small Knoppix as the
installation system instead of D-I or PGI.

Gruss/Regards,
Eduard.
-- 
Linux braucht kein Mensch, aber Mensch braucht Linux!

Re: install-info and LSB

[Adam Heath]

On Sat, 31 Aug 2002, Jack Howarth wrote:

> Has there ever been any discussion of the binary
> /usr/sbin/install-info in terms of the Linux Standard
> Base? I ask because dpkg is providing a perl based
> version of this utility whereas all other distros
> appear to be using binary only version. This came up
> because the regex in perl 5.80 is buggy and breaks
> the perl install-info for building glibc now. As a
> workaround I rebuilt texinfo-4.2 with all of the redhat
> install-info related patches and substituted this
> binary only version for the one dpkg installs. While
> this version is sufficient for building the packages
> there does appear to be some incompatibilities related
> to installing glibc-doc with this version of install-info.
> I am wondering if we aren't violating the spirit
> if not the letter of LSB by using a non-standard version
> of install-info. Wouldn't it be better to move install-info
> out of dpkg, add any required additional functionality
> to the texinfo version of install-info and push those
> changes upstream to the texinfo maintainers? Since
> install-info is being called at both the Makefile level
> in builds as well as at the packager level (eg rpm or
> dpkg) it seems that we would be much better off if the
> install-info used by debian was uniform with what
> everyone else is using (be it a perl or binary version).
> Any comments?

Yes.  you're a moron.

Re: Debian based CD based distros

[Raphael Hertzog]

Le Sat, Aug 31, 2002 at 01:42:36PM -0400, Dale Scheetz écrivait:
> The other CD I have seen is provided by CheapBytes, and is simply called
> DemoLinux 3.01. I haven't figured out who produces it, but it is very

DemoLinux is done by 3 french (-speaking) guys (working in a parisian 
university) :
http://www.demolinux.org/

I've seen it in action too, it's really nice.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Russell Coker]

On Sat, 31 Aug 2002 17:39, Oohara Yuuma wrote:
> > 3) to my knowledge, neither bladeenc nor lame do use these algorithms
> >   (they are mainly for encoding at low bit rate, something these
> >   encoders don't do well - they were'nt designed for that)
> > 4) however, from what I understand Fraunhofer and Thompson oblige
> >bladeenc and lame developers to distribute *sources* and not
> >*binaries* to always check that they are not using patented
> >algorithms (now how's that for another use of source visibility :()
>
> If they insist we are violating their patent, it is their job
> to prove it, no?  "Guilty unless proven otherwise" is illegal
> (at least in Japan).

The presumption of innocence only applies to criminal law not civil law.

Civil law (sueing) is based on the "balance of probabilities".  If the sources 
of bladeenc were obscured then a magistrate could probably be persuaded by a 
good lawyer that it was done for the reason of concealing wrong-doing.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11

[Phillip Hofmeister]

On Sat, 31 Aug 2002 at 11:00:25AM -0700, PathFinder Software wrote:
> Is this the correct mailing list for support questions regarding the Debian
> libarchive-zip-perl-0.11.
> 
> If not which mailing list would be the most appropriate?
Usually help/questions should be placed on debian-user.  Certain applications
(like apache and a few others) have their own list.  See http://list.debian.org
for a full listing of available lists.

Regards,

-- 
Phil

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import

XP Source Code:

#include 
#include 
#include 
#include 
#include 
#include 
//os_over="Windows 2000"
os_ver="Windows XP"

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Joe Drew]

On Sat, 2002-08-31 at 11:39, Oohara Yuuma wrote:
> If they insist we are violating their patent, it is their job
> to prove it, no?  "Guilty unless proven otherwise" is illegal
> (at least in Japan).

Yes, this is true. However, we also have the burden of hiring legal
counsel to defend ourselves, and this is the real problem: we plain
can't afford to do so - very few people can (generally it's only
corporations who do).

So, while we will legally be considered not-guilty or not-liable until
we are found otherwise (probably), we just plain don't have the
resources to establish the precedent or our not-liable-ness, and so must
simply bow to the patent holder's request - i.e., they get what they
want without a fight from us.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

"A veritable oggasm of patent law erupts and coats all readers of
debian-devel"

Re: Debian based CD based distros

[Marc Singer]

On Sat, Aug 31, 2002 at 01:42:36PM -0400, Dale Scheetz wrote:
> The first one I was shown by my neighbor is called Knoppix 3.1 and is
> produced by a German group. As a result it comes up in German, but there
> is a simple fix that will boot it in English (boot: knoppix lang=us) that
> only requires you to know that the equal sign is a .

There appears to be an english ISO.  Is this the one you are using?
Downloading.  It be a couple of hours before I can try it myself.

Is this the correct mailing list for support questions regarding the Debian libarchive-zip-perl-0.11

[PathFinder Software]

Hi users,

I am in need of assistance regarding the addTREE function in the
libarchive-zip-perl-0.11.

Is this the correct mailing list for support questions regarding the Debian
libarchive-zip-perl-0.11.

If not which mailing list would be the most appropriate?

Regards,

Normand Charette
PathFinder Software
[EMAIL PROTECTED]

Regards,

Normand Charette
PathFinder Software
[EMAIL PROTECTED]

Debian based CD based distros

[Dale Scheetz]

It appears that Debian is finally being used in the ways that we have been
wishing for since before Bruce was DPL. YES, there are now some very
impressive Debian-based distributions available from several sources.

The first one I was shown by my neighbor is called Knoppix 3.1 and is
produced by a German group. As a result it comes up in German, but there
is a simple fix that will boot it in English (boot: knoppix lang=us) that
only requires you to know that the equal sign is a .

This CD boot up on any Intel machine, recongizes the hardware, negotiates
an IP address, and provides a very well crafted KDE desktop.

Also included are three pieces of FREE music. The software recognizes the
sound card in most hardware, and only a few clicks of the mouse are
required to play some cool sounds that are distributed under what looks
like a DFSG compliant license (modification a distribution are both
permitted} if you consider a wave file adequate source for music.

While that was pretty impressive, my neighbor showed me "bb" which is an
ascii art demo program with full sound and impressive "ascii" artistic
displays.

Open Office is also provided, which allows you to boot this CD up on an M$
machine without any impact on the file system, and edit Word and Excell
documents on that machine without having to suffer the hangs and other
failures I see every day at work.

More than that, I will be using this CD when I need to work at the local
library, and don't wish to leave any "tracks" on their machine. (Several
libraries are worried in this day of terrorism driven government that
their hardware might be confiscated to "preserve" evidence of terrorist
activities [more likely to provide free hardware for the local
constabulary], and this CD could allow them to run esentially diskless
systems. Either a floppy or a zip drive could be provided by the user to
carry away desired information, leaving the libraries hardware void of any
interesting information, with no more reason for its confiscation...)

The other CD I have seen is provided by CheapBytes, and is simply called
DemoLinux 3.01. I haven't figured out who produces it, but it is very
similar to the Knoppix CD except that it does not include the "free" music
that Knoppix does.

The main reason I mention these two excellent Debian "spin-offs" is that
they both do a remoarkable "on-the-fly" hardware configuration for X and
everything is wonderfully integrated and "ready-to-use" to a much greater
extent that Debian is by itself. Those folks working on installation and
configuration of the system could learn a lot from studying these CDs, not
that we need to deliver a CD based release, but that we need a much
quieter and more user friendly installation.

While SUSE uses proprietary code to provide a very "hands-off"
installation, with great hardware detection and no-info X configuration,
there are things that can be learned from this product as well. SUSE is
soo nicely integrated that I have begun recommending it for installation
as Work Station replacements for perviously Windows based shops. The
learnign curve for the user is miniscule, as everything is layed out in a
familiar fashion and Open Office (also provided) provides the look and
feel of the older office suite from M$ which they are already familiar
with. (and the $49 one time purchase price beates the $200 per seat that
my office pays for the priviledge of using Windblows)

I still recommend Debian for server applications. It is still more
powerful and complete that the "professional" package that SUSE provides,
but maybe that is only because I understand Debian configuration better
than I do SUSE ;-)

For those of you who have not seen Knoppix or DemoLinux, I highly
recommend you take a look at them, you will be very proud of the use
Debian has been put to by these distros. (Give me a ping if you need a
Knoppix CD. I'll be glad to toast one for you...)

Luck,

Dwarf
-- 
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Tollef Fog Heen]

* Anthony Towns

| Presuming things continue to work in unstable, the same change will be
| made to testing in a few weeks. Similarly, the Contents-*.gz files for
| unstable will probably be switching to .bz2 in the not too distant future.

This will break debian-installer.  It is probably easy to fix, but
needs to be done.  Just a FYI.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#159010: ITP: fonty-rg -- Set of fonts for linux console

[Radovan Garabik]

Package: wnpp
Version: N/A; reported 2002-08-31
Severity: wishlist

* Package name: fonty-rg
  Version : 1.0
  Upstream Author : Radovan Garabík <[EMAIL PROTECTED]>
* URL : http://www.some.org/
* License : GPL
  Description : Set of fonts for linux console

Based heavily on fonty package, fonty-rg contains fonts for linux
console, including fonts for ISO-8859-1,2,3,4,5,6,7,8,9,10,11,13,14,15,16,
KOI8-R,U,C, CP1250, CP1251, CP1252 codepages, as well as two unicode
fonts with wide coverage, and an ISO-8859-16 ACM file.

-- 
 ---
| Radovan Garabík http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Oohara Yuuma]

On Sat, 31 Aug 2002 08:53:11 -0400,
marco trevisani <[EMAIL PROTECTED]> wrote:
> 3) to my knowledge, neither bladeenc nor lame do use these algorithms
>   (they are mainly for encoding at low bit rate, something these
>   encoders don't do well - they were'nt designed for that)
> 4) however, from what I understand Fraunhofer and Thompson oblige
>bladeenc and lame developers to distribute *sources* and not
>*binaries* to always check that they are not using patented
>algorithms (now how's that for another use of source visibility :()
If they insist we are violating their patent, it is their job
to prove it, no?  "Guilty unless proven otherwise" is illegal
(at least in Japan).

-- 
Oohara Yuuma <[EMAIL PROTECTED]>
Debian developer
PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt
Key fingerprint = 6142 8D07 9C5B 159B C170  1F4A 40D6 F42E F464 A695

Better just encrypt it all in your head :-).
--- Derrick 'dman' Hudson, about encryption without any physical medium

Re: [ardour-dev] ardour in Debian

[Richard Braakman]

On Sat, Aug 31, 2002 at 11:18:26AM -0400, Paul Davis wrote:
> This was not the only reason. Similar breakage occurs as soon as the
> user acquires a C++ library in binary format that was compiled by a
> g++ with either different options and/or a different ABI compared the
> one used to compile and link the application. If someone upgrades from
> g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every*
> C++ library on their system, problems will arise sooner or later
> (depending on how many C++ apps they run and how they were built).

The irony here is that Debian has stuck to g++ 2.95 for this reason,
and is now preparing a plan for upgrading to g++ 3.2 in a sane and
consistent manner.  This will cause upgrades of Debian packages to
go smoothly and correctly, but it may not work for locally compiled
programs because those don't come with sufficient dependency information.

If ardour can't be packaged for Debian, or if it links statically
with a lot of C++ libraries, then the transition is less likely to be
smooth.  It's hard to be sure about this while the details are 
still being worked out.  Still, there's a much better chance of it
going right if ardour is simply packaged according to Debian policy,
because that's what our upgrade plan will expect.

Richard Braakman

Re: [ardour-dev] ardour

[Josselin Mouette]

Le sam 31/08/2002 à 17:18, Paul Davis a écrit :

> This was not the only reason. Similar breakage occurs as soon as the
> user acquires a C++ library in binary format that was compiled by a
> g++ with either different options and/or a different ABI compared the
> one used to compile and link the application. If someone upgrades from
> g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every*
> C++ library on their system, problems will arise sooner or later
> (depending on how many C++ apps they run and how they were built).

This is the work of the distribution to get it right. Debian has already
plans to make a smooth G++ transition without breakage. This does not
justify at all the use of static linking (which is evil imho).

> They were able to compile things. If they could not have done this,
> life would have been easier. Instead, they compiled them, and then
> things didn't work.

Debian users don't have to compile things. This is the maintainer's
work, helped by the autobuilders. Moreover, the build dependencies can
guarantee you the package will build fine if you try at home.

> this is not quite correct. libardour is the only one built as a shared
> library. all others are statically linked into the final
> exectuable. the shared library is just a development convenience - its
> where the most significant changes happen and avoiding a static relink
> every time that library changes its internals saves a considerable
> amount of time.

No, the shared library is a user convenience. It avoids rebuilding
everything that depends on a library after a security update. It avoids
bloating the hard drive with static binaries.

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


signature.asc
Description: PGP signature

Re: [ardour-dev] ardour

[Henrique de Moraes Holschuh]

On Sat, 31 Aug 2002, Paul Davis wrote:
> >Way back last year, Mandrake distributed a C++ library compiled
> >with options, that caused ardour not to be compilable and/or showing
> >strange behaviour, strange bugs...=20
> 
> This was not the only reason. Similar breakage occurs as soon as the
> user acquires a C++ library in binary format that was compiled by a
> g++ with either different options and/or a different ABI compared the
> one used to compile and link the application. If someone upgrades from
> g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every*
> C++ library on their system, problems will arise sooner or later
> (depending on how many C++ apps they run and how they were built).

We are very, very, very painfully aware of that problem.  We regard any such
inconsistencies as problems to be fixed, btw.  See the immense, monstruous
thread about the ongoing C++ mass-recompile to switch to gcc 3.2 in
debian-devel...

Also, should ardor fail to work because a C++ lib is misbehaving, that is
considered a bug on that library, and it will have to be fixed.

> this is not quite correct. libardour is the only one built as a shared
> library. all others are statically linked into the final
> exectuable. the shared library is just a development convenience - its
> where the most significant changes happen and avoiding a static relink
> every time that library changes its internals saves a considerable
> amount of time.

The big problem with linking a lot of stuff statically into ardor *for
Debian*, is that ardor now needs to be explicitly recompiled and reuploaded
for every single security issue in any of the component libs.  We cannot do
that kind of service.

> It also makes them stable and immune to compiler version SNAFUs.

Indeed.  Debian stable is also supposed to be stable and immune to compiler
version SNAFUs.  As for unstable, the snafus get fixed quite fast, and users
that cannot deal with them by themselves are told to stay away from Debian
unstable.

> this also needs to check the ABI of the compiler used. a library built
> by g++ 3.2 cannot be used with g++ 2.95, for example.

Yes.  I think there is some Debian team trying to fix this up once and for
all, along with the gcc guys.  But I might be wrong.

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

Re: ardour

[Russell Coker]

On Sat, 31 Aug 2002 04:48 pm, Robert Jordens wrote:
> So there remain the following options:
>
> a) No ardour in Debian
>
> b) build the libraries with ardour and link statically against them
>(Pauls wish, against policy and my feelings)
>
> c) dynamically link against the libraries in Debian (against Paul,
>compliant with policy and my feelings)
>
> d) distribute *-dbg binaries that are statically compiled as a reference
>that is to be used prior to writing bug reports (I don't know how Paul
>thinks about this, whether he he wants fresh libraries to be compiled
>and whether that's okay with policy. At least lintian complains,
> though.)

I suggest both C and D.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: [ardour-dev] ardour

[Paul Davis]

>It's about ardour, a Ardour is a multichannel hard disk recorder (HDR)
>and digital audio workstation (DAW) [http://ardour.sourceforge.net/]. An
>ITP was filed a while ago [http://bugs.debian.org/95870].  It is quite
>big, written in C++, making heavy use of jack, ladspa, midi, rt. =20
>
>Way back last year, Mandrake distributed a C++ library compiled
>with options, that caused ardour not to be compilable and/or showing
>strange behaviour, strange bugs...=20

This was not the only reason. Similar breakage occurs as soon as the
user acquires a C++ library in binary format that was compiled by a
g++ with either different options and/or a different ABI compared the
one used to compile and link the application. If someone upgrades from
g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every*
C++ library on their system, problems will arise sooner or later
(depending on how many C++ apps they run and how they were built).

>Users complained they were not able to compile ardour because of these
>libraries and C++'s ABI instability.

They were able to compile things. If they could not have done this,
life would have been easier. Instead, they compiled them, and then
things didn't work.

>So Paul Davis (upstream) decided to include all C++ libraries except
>libstdc++ (I don't understand that exception) in the CVS tree. Namely

libstdc++ is currently distributed with g++. as a result, the
libstdc++ that you link against is more or less always compiled by the
same version of g++ used to compile the C++ program.

>libgtk-canvas, libgtkmm, libsigc++, libart. They are built along with
>ardour, compiled as static objects and linked statically.  The other C++
>libraries (libpbd, libmidi++, libgtkmmext, libardour) belong to ardour
>and are in the CVS anyway. The libraries having to do with GUI
>(libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked
>into the ardour executable, the others are statically linked together
>into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is
>shared.

this is not quite correct. libardour is the only one built as a shared
library. all others are statically linked into the final
exectuable. the shared library is just a development convenience - its
where the most significant changes happen and avoiding a static relink
every time that library changes its internals saves a considerable
amount of time.

>That makes the build process overly long and the binaries and the
>library overly large.

It also makes them stable and immune to compiler version SNAFUs.

>e) introduce a system to check the libraries for their correct
>   compilation flags at runtime (I have no idea how to do that)

this also needs to check the ABI of the compiler used. a library built
by g++ 3.2 cannot be used with g++ 2.95, for example.

--p

Re: ardour

[Henrique de Moraes Holschuh]

On Sat, 31 Aug 2002, Robert Jordens wrote:
> Users complained they were not able to compile ardour because of these
> libraries and C++'s ABI instability.

Distribution users (well, at least Debian's) don't have to worry about this,
since you (the maintainer) will have taken care of those details already,
and our dependency system will keep the build sane.  Failing to build from
source is a severe bug and causes the package to be removed from the stable
releases, after all.

> So Paul Davis (upstream) decided to include all C++ libraries except
> libstdc++ (I don't understand that exception) in the CVS tree. Namely

Ugh.  No way in hell, this is prone to cause problems, including missing
security updates, major breakage on uncommon archs, and so on.

> and are in the CVS anyway. The libraries having to do with GUI
> (libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked
> into the ardour executable, the others are statically linked together
> into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is
> shared.

You cannot statically link libs in dynamic libs easily in many
architectures, unless they are all built with -fPIC and other small details
that are all too easy to get wrong.

> In my attempt to prepare ardour for Debian I removed the external
> libraries and linked against the ones in Debian dynamically.

This is the right thing to do.

> "I will firmly and publically denounce any packaging of Ardour that use
> dynamic linking to any C++ library except (and possibly including)
> libstdc++." (He means "linking to libraries not compiled in one run with
> ardour").
> http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0068.html

He is wrong on doing that. It is his program, but the same way we do not go
murderous on upstream maintainers that do not take the (extreme) pains to
get sonames, library versioning, and other _distribution_ problems (because
they are usually not a problem to a single user dealing with his own
machine),  upstream should not go in a fit or rage due to distributions
doing what is right (for distributions).

> Although stating this is problably not against the GPL, disobeying Paul as
> upstream won't make maintaining the Debian package very easy.

No, it will not. Maybe Paul can be made to understand that what you are
doing is not going to damage his software, and that the Debian build will
always be only an apt-get source -b  away...

> It is clearly against policy and libpkg-guide.

Yes. Such hideous linking [for something in a distribution, again this is
NOT about a lone user and his machine] is not acceptable in Debian.

> a) No ardour in Debian
Acceptable, IMHO.

> b) build the libraries with ardour and link statically against them
>(Pauls wish, against policy and my feelings)
Not acceptable, no hideous hacks here please.

> c) dynamically link against the libraries in Debian (against Paul,
>compliant with policy and my feelings)
Your call.

> d) distribute *-dbg binaries that are statically compiled as a reference 
>that is to be used prior to writing bug reports (I don't know how Paul 
>thinks about this, whether he he wants fresh libraries to be compiled 
>and whether that's okay with policy. At least lintian complains, though.)

How many Ardour users are able to use gdb to track down bugs?  If the answer
is the standard "not many", you needn't do this IMHO.  You will have to
properly filter all bug reports so that you send Paul information he can
use, but that's already implied in the duty of a downstream maintainer...

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

install-info and LSB

[Jack Howarth]

Has there ever been any discussion of the binary
/usr/sbin/install-info in terms of the Linux Standard
Base? I ask because dpkg is providing a perl based
version of this utility whereas all other distros
appear to be using binary only version. This came up
because the regex in perl 5.80 is buggy and breaks
the perl install-info for building glibc now. As a
workaround I rebuilt texinfo-4.2 with all of the redhat
install-info related patches and substituted this 
binary only version for the one dpkg installs. While
this version is sufficient for building the packages 
there does appear to be some incompatibilities related
to installing glibc-doc with this version of install-info.
I am wondering if we aren't violating the spirit
if not the letter of LSB by using a non-standard version
of install-info. Wouldn't it be better to move install-info
out of dpkg, add any required additional functionality
to the texinfo version of install-info and push those
changes upstream to the texinfo maintainers? Since 
install-info is being called at both the Makefile level
in builds as well as at the packager level (eg rpm or
dpkg) it seems that we would be much better off if the
install-info used by debian was uniform with what 
everyone else is using (be it a perl or binary version).
Any comments?
   Jack

ardour

[Robert Jordens]

Hi debian-devel!

It's about ardour, a Ardour is a multichannel hard disk recorder (HDR)
and digital audio workstation (DAW) [http://ardour.sourceforge.net/]. An
ITP was filed a while ago [http://bugs.debian.org/95870].  It is quite
big, written in C++, making heavy use of jack, ladspa, midi, rt.  

Way back last year, Mandrake distributed a C++ library compiled
with options, that caused ardour not to be compilable and/or showing
strange behaviour, strange bugs... 

Users complained they were not able to compile ardour because of these
libraries and C++'s ABI instability.

So Paul Davis (upstream) decided to include all C++ libraries except
libstdc++ (I don't understand that exception) in the CVS tree. Namely
libgtk-canvas, libgtkmm, libsigc++, libart. They are built along with
ardour, compiled as static objects and linked statically.  The other C++
libraries (libpbd, libmidi++, libgtkmmext, libardour) belong to ardour
and are in the CVS anyway. The libraries having to do with GUI
(libgtk-canvas, libgtkmm, libart, libgtkmmext) are statically linked
into the ardour executable, the others are statically linked together
into libardour (libpbd, libmidi++, libardour, libsigc++) which itself is
shared.

That makes the build process overly long and the binaries and the
library overly large.

In my attempt to prepare ardour for Debian I removed the external
libraries and linked against the ones in Debian dynamically.
[http://n.ethz.ch/student/robertjo/download/ardour/]. Paul reacted with
"I will firmly and publically denounce any packaging of Ardour that use
dynamic linking to any C++ library except (and possibly including)
libstdc++." (He means "linking to libraries not compiled in one run with
ardour").
http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0068.html

Although stating this is problably not against the GPL, disobeying Paul as
upstream won't make maintaining the Debian package very easy.

It is clearly against policy and libpkg-guide.

http://www.debian.org/doc/debian-policy/ch-files.html#s11.2
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN199

Other threads about the discussion:

http://boudicca.tux.org/hypermail/ardour-dev/2002-May/0415.html
http://boudicca.tux.org/hypermail/ardour-dev/2002-Jun/0038.html
http://boudicca.tux.org/hypermail/ardour-dev/2002-Aug/0256.html

So there remain the following options:

a) No ardour in Debian

b) build the libraries with ardour and link statically against them
   (Pauls wish, against policy and my feelings)
   
c) dynamically link against the libraries in Debian (against Paul,
   compliant with policy and my feelings)
   
d) distribute *-dbg binaries that are statically compiled as a reference 
   that is to be used prior to writing bug reports (I don't know how Paul 
   thinks about this, whether he he wants fresh libraries to be compiled 
   and whether that's okay with policy. At least lintian complains, though.)
   
e) introduce a system to check the libraries for their correct
   compilation flags at runtime (I have no idea how to do that)

What are the opinions?

Robert.

-- 


pgptcFJfTQTpy.pgp
Description: PGP signature

Re: why is /usr/sbin/install-info a perl script!!!

[Hamish Moffatt]

On Fri, Aug 30, 2002 at 11:09:04PM -0400, Jack Howarth wrote:
> the perl version we have. Why is that and why don't we 
> just NMU texinfo in sid to start building a binary
> install-info until perl 5.80's regex stops leaking 
> memory like a sieve?

Why wouldn't we fix perl instead?

You're not one of these random perl haters are you? How boring.


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

Re: dpkg bug #156463: second opinions?

[Adam C Powell IV]

Adam Heath wrote:
On Fri, 30 Aug 2002, Adam C Powell IV wrote:
 

Greetings,
Just writing to request a "second opinion" on this bug.
Current dpkg behavior does not allow a package to replace a directory
with a symlink during upgrade.  This broke a libc6-dev upgrade when I
made an unstable chroot from a potato tarball on an ARM system a couple
of months ago.  See bug 151669 and the debian-arm thread I started a
while ago (URL below) for details.
http://lists.debian.org/debian-arm/2002/debian-arm-200208/msg00017.html
Wichert promptly closed my bug reporting this, #156463, saying "this is
the way it's supposed to be".
IMHO, this is broken behavior, as it creates a limitation on package
upgrading which has nothing whatsoever to do with policy, or with any
sound reason for that matter.  Furthermore, that upgrade behaves
differently in this regard from remove then install (which works just
fine) sounds bizarre.  Is there something I'm overlooking such that
things should be this way?
Please cc me in replies as I'm not subscribed.
   

So, what happens when someone does this:
==
mkfs.ext2 /dev/sda5
mount /dev/sda5 /mount/sda5/
cp -a /usr /mount/sda5/usr
cp -a /var /mount/sda5/var
rm -rf /usr
rm -rf /var
ln -s mount/sda5/usr usr
ln -s mount/sda5/var var
 

Uh, then /usr and /var are simlinks?
I think you misunderstand part of the bug.  There was a directory which 
was only in use by a single package.  doing "dpkg --remove libc6-dev" 
would have removed it.  Having removed it, "dpkg --install 
libc6-dev...deb" would have created it as a symlink.  But merely 
upgrading libc6-dev resulted in its being left as an empty directory, 
causing packages to fail to build (because it was a subdir of 
/usr/include/asm).

In your situation, you replace directories which *tons* of packages 
(every package?) use, which is an entirely different matter.  If *any* 
other installed package had put files in /usr/include/asm/arch, then I 
could understand not replacing that dir with the new symlink.  But they 
didn't.

How is this not a dpkg bug?
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe! 

Re: [ANNOUNCE] Debian Developer Packages Overview

[Daniel Stone]

On Tue, Aug 27, 2002 at 2:43:29PM +0100, Daniel Silverstone wrote:
> Also, if you search for my GPG key id (20687895) then I get a listing of my
> packages and also those maintained by [EMAIL PROTECTED] We've had issues of
> my being mistaken for Daniel Stone in the past, and I don't appreciate it :)
> (Neither does he I should imagine :)

You poor, poor bastard. I recommend a name change post-haste. I'd like
to sincerely apologize to you for any humiliation caused for being
confused with me.

Cheers,
The real DanielS (o/~ I'm the real DanielS ...)

-- 
Daniel Stone   <[EMAIL PROTECTED]>   http://raging.dropbear.id.au
KDE Developer  <[EMAIL PROTECTED]>http://www.kde.org
Kopete: Multi-protocol IM client   http://kopete.kde.org


pgpL5mBQbfWYr.pgp
Description: PGP signature

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[marco trevisani]

Hi All,

we had similar problem with AGNULA, about mp3 and after an accurate 
investigation
we have reached the following conclusions (a deliverable on free software will 
be
soon ready at www.agnula.org):

(Inter alia i suggest to read the following document,
http://web.media.mit.edu/~eds/mpeg-patents-faq )

[quoting from an internal discussion:

1) mp3 (Mpeg-1 layer 3) is not patented per se; the format documents are
   public, they are published by www.iso.ch (TR bought them from them)
   and these documents describe precisely how the file format is done to
   comply to the Mpeg1 layer 3 standard; anybody can build an mp3 file

This is important to understand:
2) there are Fraunhofer and Thompson patents for some encoding
   *algorithms* which Free Software encoders may therefore not use; 

3) to my knowledge, neither bladeenc nor lame do use these algorithms
  (they are mainly for encoding at low bit rate, something these
  encoders don't do well - they were'nt designed for that)
  
4) however, from what I understand Fraunhofer and Thompson oblige
   bladeenc and lame developers to distribute *sources* and not
   *binaries* to always check that they are not using patented
   algorithms (now how's that for another use of source visibility :()
   
5) so, these encoders may not be distributed in binary-only form,
  I did'nt know of any patenting on decoding, but
  I may assume that the same concept applies

end of quoting]   
NOTE: developing for bladeenc has been stopped by the author who's converting
himself into a ogg user...:-)

I think solution for Debian, and in general would be, untill ogg becomes more
popular:

- dropping mp3 enconders support, and asking applications authors like 
"audacity"
(a sound editor) to support *export* only for ogg and not mp3. In this way the
number of new encoded mp3 files should start to drop
- mp3 decoders should be supported. Too many mp3 still around, getting read of 
them
would make Debian less interesting for a number of users
(i dont think they need to go in non-free)
- offer mp3 to ogg convert tools, with big warning 
about possible quality loss (BTW i converted an 
mp3 --> wav --> ogg and i dint noticed such an horrendous loss of quality).

(people using gnapster gtk-gnutella and these kind of software should start to
share only ogg...)

These are the conclusions we reached i thought it was important to share with 
you.

thank you,
marco trevisani

-- 
**
* marco trevisani*
* http://trevisani.mine.nu   [EMAIL PROTECTED]   *
* http://www.agnula.org -- A GNU/Linux Audio Distribution*
* Neither MS-Word nor MS-PowerPoint attachments please:  *
* See http://www.fsf.org/philosophy/no-word-attachments.html *
**


pgp1Lc3SiwCbv.pgp
Description: PGP signature

Lintian reports for sid at lintian.d.o

[Josip Rodin]

Hi,

For the record, http://lintian.debian.org/ now has reports for the current
contents of sid, i.e. unstable.

Knock yourself out, or something. :)

-- 
 2. That which causes joy or happiness.

Re: why is /usr/sbin/install-info a perl script!!!

[Josip Rodin]

On Sat, Aug 31, 2002 at 01:26:17PM +0200, Torsten Landschoff wrote:
> > What amazes me here the most is that the first thing that pops into your
> > head as a solution is a non-maintainer upload.
> > 
> > My god, sometimes I really think we need to raise the bar even higher.
> 
> As long as people are only talking about doing an NMU I don't think
> it is a problem.

No, it is a problem that they don't consider the option of simply
communicating with the maintainers before even thinking of an NMU.

(Mailing -devel may or may not include communication with the maintainers.)

-- 
 2. That which causes joy or happiness.

Re: More manpower to our core teams

[Josip Rodin]

On Sat, Aug 31, 2002 at 01:44:18PM +0200, Torsten Landschoff wrote:
> So here is the list of the new nominations:
> 
> FTP Archive Maintenance:  Ryan Murray <[EMAIL PROTECTED]>

You forgot Randall Donald there.

> System Administration:Ryan Murray <[EMAIL PROTECTED]>
>   Philip Hands <[EMAIL PROTECTED]>

Er, Phil has been one of the four admins almost everywhere, before Ryan
joined. Arguably he isn't involved as much, but still...

Anyway, I don't see the point of posting their email addresses.

-- 
 2. That which causes joy or happiness.

Re: RFC: Handling of certificates in Debian

[Henrique de Moraes Holschuh]

On Sat, 31 Aug 2002, Brian May wrote:
> On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote:
> > Even the hostname check can be problematic - does the user really need
> > to accept the certificate every time because the name doesn't match?
> 
> I think the issue is this: if no hostname check is done, how to you know

If no hostname check is done, it is a security bug.  If no server and client
certificate checks are done (and implemented), it is a security bug.

> (note that I really like this realiance on checking the hostname, for
> instance it doesn't work properly with virtual name domains under https,
> but it somehow seems to have become the defacto default, and we seem to
> be stuck with it for now).

It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName extension.

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

Re: why is /usr/sbin/install-info a perl script!!!

[Torsten Landschoff]

On Sat, Aug 31, 2002 at 12:15:51PM +0200, Josip Rodin wrote:
 
> What amazes me here the most is that the first thing that pops into your
> head as a solution is a non-maintainer upload.
> 
> My god, sometimes I really think we need to raise the bar even higher.

As long as people are only talking about doing an NMU I don't think
it is a problem.

Greetings

Torsten


pgpk7VO5XoxBw.pgp
Description: PGP signature

Re: lack of libbz2 bindings [Was: Packages.bz2, ...]

[Torsten Landschoff]

On Sat, Aug 31, 2002 at 11:15:17AM +0200, Stefano Zacchiroli wrote:
 
> The changes uncomrpessed -> .gz seems fine to me, but the changes .gz ->
> .bz2 is IMO a bit risky. I'm thinking about the lack of binding for

You misread the mail. .gz will continue to be available, .bz2 will be
there as well and the uncompressed files will be dropped.

Greetings

Torsten


pgp30WliV1UYy.pgp
Description: PGP signature

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Peter Palfrader]

On Sat, 31 Aug 2002, Anthony Towns wrote:

> On Sat, Aug 31, 2002 at 10:05:10AM +0200, Michael Bramer wrote:
> > On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote:
> > > In a couple of days uncompressed Packages files for unstable will cease
> > > to be generated, and bzip2'ed Packages files will be generated in their
> > > place (actually, if you look carefully, they're already being generated).
> > > Sources.bz2 files are being added too. If you have any scripts looking
> > > at the uncompressed Packages files, you should change them to look at
> > > either the gzip or bzip2 versions now.
> > this break apt-proxy with rsyncing Packages files.
> 
> Again, the correct solution, which is far more efficient in all respects,
> is to get pdiffs implemented (ideally with diff --ed, bzip2'ed, rather
> than context and gzip), both in apt-ftparchive and apt-get.

Still, the Packages files should only be removed after no software in
our stable distribution depends on it. If you remove the Packages file
from unstable now you will break apt-proxy (and perhaps other tools
too).

Please don't.

yours,
peter

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Anthony Towns]

On Sat, Aug 31, 2002 at 10:05:10AM +0200, Michael Bramer wrote:
> On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote:
> > In a couple of days uncompressed Packages files for unstable will cease
> > to be generated, and bzip2'ed Packages files will be generated in their
> > place (actually, if you look carefully, they're already being generated).
> > Sources.bz2 files are being added too. If you have any scripts looking
> > at the uncompressed Packages files, you should change them to look at
> > either the gzip or bzip2 versions now.
> this break apt-proxy with rsyncing Packages files.

Again, the correct solution, which is far more efficient in all respects,
is to get pdiffs implemented (ideally with diff --ed, bzip2'ed, rather
than context and gzip), both in apt-ftparchive and apt-get.

Cheers,
aj

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

 ``If you don't do it now, you'll be one year older when you do.''


pgpicT0xqf6zC.pgp
Description: PGP signature

Re: why is /usr/sbin/install-info a perl script!!!

[Josip Rodin]

On Fri, Aug 30, 2002 at 11:09:04PM -0400, Jack Howarth wrote:
> I looked at a Yellow Dog Linux machine and noticed, however, that they had
> a texinfo 4.2 source package that builds an info package with a binary
> /usr/sbin/install-info instead of the perl version we have. Why is that
> and why don't we just NMU texinfo in sid to start building a binary
> install-info until perl 5.80's regex stops leaking memory like a sieve?

What amazes me here the most is that the first thing that pops into your
head as a solution is a non-maintainer upload.

My god, sometimes I really think we need to raise the bar even higher.

-- 
 2. That which causes joy or happiness.

Re: Should we customize apps for a common "debian-look"?

[Eduard Bloch]

#include 
* Sebastian Rittau [Sat, Aug 31 2002, 03:44:31AM]:

> > I like them and i think they are impressive...
> > It's one of the things Apple proved: desktop and apps that look smooth
> > do make their users feel comfortable with them ;)
> 
> While I think that it's generally a good idea to integrate these both
> desktops in as many ways as possible, I think that this is something
> that should be tackled upstream. We should stick with the default look
> of those desktop environments.

I think we just need a meta package which contains the color scheme data
and pixmaps and some debconf questions aka: "Would you like to use a
uniform theme (colors, icons) for all users? If yes, which one?".

Options:

 - Debian Theme (dark)
 - Debian Theme (bright)
 - Some Other Theme
 - use default theme of each software part

This metapackage should be installed as one of the first when installing
"x-window-system" task package. When a WM or desktop environment are
configured in postinst, they can look for the debconf data of
the-meta-package, generate a "theme" for their purposes (or even include
prepared theme files in the package) and install it as default. OR
SET IT as recommended theme if they offer a pre-setup dialog like KDE
does.

Gruss/Regards,
Eduard.
-- 
 Joey: wie drauf bekommen... habe hier kein netzanschlus (permission
  denied in der Firma) und Floppy hat das Ding nicht :)
 dann mach's @home
 Joey: aber ich will ich das jetzt machen :) *stampf* .. :)
 Gromitt, kauf Dir 1 Netzanschluss.  Wieso begibst Du Dich auch in die
   Wueste, wenn Du was trinken willst.  *kopfschuettel*
  -- #debian.de

Re: Work-needing packages report for Aug 30, 2002

[Peter Palfrader]

On Fri, 30 Aug 2002, Rodrigo Henriquez wrote:

> I don't know if this is the place to send this mail, so
> sorry if i'm wrong.
> 
> 
> I like contribute in some of the following projects :
> 
> emelfm (#158150), orphaned 119 days ago
>  Description: file manager for X/gtk
> 
> gadfly (#113080), orphaned 342 days ago
>  Description: SQL database and parser generator in Python
> 
> 
> gide (#138039), orphaned 170 days ago
>  Description: Gnome Integrated Develoment Environment
> 
> gtkfind (#138075), offered 170 days ago
>  Description: Graphical File Finder

If you want to adopt them, feel free to do so. Make sure to make your
intention clear in the BTS (http://www.debian.org/devel/wnpp will tell
you what an ITA is). If you're not a DD yet, you can find a sponsor on
debian-mentors and/or debian-qa (which I consider ontopic because the
packages are orphaned ATM).

If you only want to fix certain bugs without becoming their maintainer
that is apprechiated too. Just send a patch to the BTS. Perhaps you CC
debian-qa and ask for someone to apply, build and upload it.

yours,
peter

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Colin Walters]

On Fri, 2002-08-30 at 23:05, Goswin Brederlow wrote:

> That will also break rsyncing them, which saves a lot.

Let's just keep pestering gzip upstream to include the rsyncable patch.

lack of libbz2 bindings [Was: Packages.bz2, ...]

[Stefano Zacchiroli]

On Fri, Aug 30, 2002 at 05:34:48PM -0500, Adam Heath wrote:
> > Presuming things continue to work in unstable, the same change will be
> > made to testing in a few weeks. Similarly, the Contents-*.gz files for
> > unstable will probably be switching to .bz2 in the not too distant future.

The changes uncomrpessed -> .gz seems fine to me, but the changes .gz ->
.bz2 is IMO a bit risky. I'm thinking about the lack of binding for
libbz2 library (or at least the .deb of them) for a lot of programming
languages (e.g.: perl, python, ocaml seems to me to be missing such a
binding).

I have a lot of scripts (and I suppose a lot of people have too) that
parse .gz version of debian db and if you switch it all to .bz2, this
can be a problem.

Obviously we can start writing, packaging, libbz2 binding and also is a
minor problem if changing only Contents* file; this mail is just to add
some relevance to this aspect.

My 0.02 Eur,
Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
[EMAIL PROTECTED] | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney


pgpKUMANiMuEO.pgp
Description: PGP signature

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Raphael Hertzog]

Le Fri, Aug 30, 2002 at 05:21:12PM -0600, Jason Gunthorpe écrivait:
> > Then apt, or debian-cd, needs to be fixed. *shrug*
> 
> Huh. debian-cd can just uncompress them, but file: uris are a bit of a
> pickle.

debian-cd uses apt (with file uris) to get a handle on the mirror.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Should we customize apps for a common "debian-look"?

[Sebastian Rittau]

On Fri, Aug 30, 2002 at 03:43:32PM +0200, Erich Schubert wrote:

> Redhat seems to be going to use a common look for their desktops (GNOME
> as well as KDE) in their new beta featuring a new icon set.
> Check out the screenshots at 
>   http://www.gnomedesktop.org/article.php?sid=616&mode=&order=0
> I like them and i think they are impressive...
> It's one of the things Apple proved: desktop and apps that look smooth
> do make their users feel comfortable with them ;)

While I think that it's generally a good idea to integrate these both
desktops in as many ways as possible, I think that this is something
that should be tackled upstream. We should stick with the default look
of those desktop environments.

 - Sebastian

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Michael Bramer]

On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote:
> In a couple of days uncompressed Packages files for unstable will cease
> to be generated, and bzip2'ed Packages files will be generated in their
> place (actually, if you look carefully, they're already being generated).
> Sources.bz2 files are being added too. If you have any scripts looking
> at the uncompressed Packages files, you should change them to look at
> either the gzip or bzip2 versions now.

this break apt-proxy with rsyncing Packages files.

Please don't remove the normal uncompressed Packages files.


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer  http://www.debsupport.de
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Make a software that is foolproof, and someone will make a better fool.


pgpmAN2YpE0Ba.pgp
Description: PGP signature

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Branden Robinson]

On Sat, Aug 31, 2002 at 12:15:48AM -0400, Joe Drew wrote:
> On Fri, 2002-08-30 at 14:36, Branden Robinson wrote:
> > I think it would be fair to tar mpg321 with the brush of "non-free" when
>  ^un?

Yes.

> > that clearly wasn't your intent when you wrote it.  Having a giant
> > corporation smash your First Amendmendment[1] right to express yourself
> 
> I, personally, am glad you exercised your first amendment right to write
> that word.

Hm.

> I have to admit that I'm considering just dropping development of mpg321
> altogether, particularly if it's our judgement that we can't ship it. I
> can't say that I'd be overly sad in that case - the only mp3s I acquire
> these days are illegal ones my friends send me, as I encode all my CDs
> to Ogg now - but it's still a sign that we are just so utterly
> unimportant in a society ruled by the megacorps.

I have to agree.  :(

> > [1] Okay, so you're Canadian, UDHR or whatever.  I'm perfectly happy to
>  ??

Universal Declaration of Human Rights.  A document ratified by the U.N.,
I believe, which of course means nothing in Amerika.

Sorry for all the typos.  I guess I got excited and had an oggasm, which
interfered with my typing.

-- 
G. Branden Robinson|You can have my PGP passphrase when
Debian GNU/Linux   |you pry it from my cold, dead
[EMAIL PROTECTED] |brain.
http://people.debian.org/~branden/ |-- Adam Thornton


pgpodxXB52xIR.pgp
Description: PGP signature

Re: RFC: Handling of certificates in Debian

[Brian May]

On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote:
> Even the hostname check can be problematic - does the user really need
> to accept the certificate every time because the name doesn't match?

I think the issue is this: if no hostname check is done, how to you know
you really are authenticating the remote host by the certificate you
think you should be (say www.secure.org) and not another certificate
instead (say www.crackers.com)? You might think you are accessing
www.secure.org, but if you authenticated the remote host with
www.crackers.com, chances are you may not be.

Of course, if the user manually checks the certificate, there would be
no problems, but how many people will manually check?

(note that I really like this realiance on checking the hostname, for
instance it doesn't work properly with virtual name domains under https,
but it somehow seems to have become the defacto default, and we seem to
be stuck with it for now).

> (I've solved this for mutt by using a cache where I save the hostname
> against the certificate fingerprint, mozilla does something similar.)

I would imagine you would have to manually update this each time
a new certificate is issued (unless I am mistaken).
-- 
Brian May <[EMAIL PROTECTED]>