Re: APT 0.1.6 is released!
Dale Scheetz writes: You can't ever remove A. Systems pre-split must always be upgradable to systems after the split. They would still be upgradable: they'd just revert to what I understand to be the present behavior: A vanishes. But, ok. Doesn't necessarily mean that this isn't a workable idea, just that it will always have this baggage. Doesn't seem like very objectionable baggage. The packages would have descriptions that makes it clear what they are, and there would never be very many. When I think about it more, I guess I would want to keep them around. B and C were together in A because someone once thought they belonged together. It is likely that others will think similarly, or just remember 'A' from bo and go looking for it in emperor. This scheme gives them what they expect. Think of these as a type of 'superpackage'. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Perl policy for managing modules ?
On Wed, 7 Oct 1998, Raphael Hertzog wrote: rhertzI propose to make package install the modules in /usr/lib/perl5/debian rhertzand /usr/lib/perl5/debian/$arch. And the /usr/lib/perl5/$version would rhertzbe a link to debian, and /usr/lib/perl5/$arch/$version a link to rhertz../debian/$arch. So the current perl will always find the modules rhertzinstalled. And we'll have no problem for the transition to perl5.006 ... rhertz rhertzHow to manage this in the source package for a CPAN module ? Here's rhertzwhat I would have to do for my own package (I tested it) : rhertz rhertz- use this line for creating the Makefile : rhertz perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian rhertz- and use make pure_install for installing files Thats how I build my perl modules as well (and I guess others), so it shouldn't be too much of a problem. (Acutally some of the more complicated packages will need more changes.) I can't think of a better solution. Re: packages with only perl source, many will probably not be affected by an upgrade, and it seems silly to require that they be rebuilt. I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
perl version depends
-BEGIN PGP SIGNED MESSAGE- Is it possible for dpkg to have a depends line similar to: Depends: perl (=5.005) and have that include 5.005-\d+? Or will I need to put a Provides: perl5.005 in so that packages can depend on that? (Note that I did say that this would break *all* debian installed packages in the change release.) Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNhv+B7QuaHP6LBjxAQHJHgP9F0dtrDOi/qOpkVPzSKq/EKius7A5r1Yu seL2beyGI31U6DRm+/2gSlABRme+GnVPoMQTKHA+8dZgh3O3I+DoAqPEAn5DUz2j SEsGqkS1Y2x7Ooa95DKAC+6pPNg8qy0omkhXqh9Z7ABUXPcVRLS6JqqAPs/rAHT6 I9OClbm5WzQ= =dMOQ -END PGP SIGNATURE-
1st unpacking, 2nd dependency checking
This might be an faq. But occasionally I notices that dpkg first unpacks and installs the files in a particular package and checks dependencies afterwards. This means that wrong dependencies are discovered when it is too late since the old version of the package is already overwritten. I'm sure there is a rationale for this, but what is it? At least I would have expected that dpkg tests the dependency of new packages and refuses to unpack them - unless one told it to ignore dependencies. Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
Darren Stalder wrote: Is it possible for dpkg to have a depends line similar to: Depends: perl (=5.005) and have that include 5.005-\d+? Or will I need to put a = means equal. I guess it's logical that 5.005 != 5.005-1 Thus I believe it would need to use (= 5.005-0) Provides: perl5.005 in so that packages can depend on that? (Note that I did say that this would break *all* debian installed packages in the change release.) (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Martin Schulze writes: I'd like to make it optional so it does not have to be used but only should. Each pkg. maintainer could negotiate with the upstream author about this feature and not use it if the author doesn't like that. The policy should emphasize that it not be used without consulting the author. If it is not used mail to the author should go to the maintainer instead of bouncing. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: korganizer debian package (OT: licence interpretation)
On Wed, 07 Oct 1998, Dan Jacobowitz wrote: On Mon, Oct 05, 1998 at 05:27:23PM +0200, Moritz Moeller-Herrmann wrote: I study law. And I can tell you that there´s not a problem with the GPL licence in the KDE project. Even if the GPL (read very narrowly and literally) prohibited the use of QT, every judge/lawyer would reinterpret this licence to allow the use of QT , if the author of kpackage used it to distribute his program. What I am trying to say is, a licence can be interpreted in many ways and one very important issue in the interpretation of any legal document is the intent of the author or the user of this document. As the author of kpackage didn´t want to ban anyone from using qt, his licences (the GPL) must be read to allow the use qt. No problem so far. Problems could only arise if another copyright holder´s rights were violated, for example if a second GPLd program were merged into kpackage, and the author of this program read the GPL in a much more strict way than the author(s) of kpackage. Then we´d have two licences (both of identical wording: GPL), which could be interpreted differently, because the people who use the licence have opposing intentions with their licence. Since you distribute a binary DEB file, the problem can´t come up. Hope to clarify the issue a bit! I have one question to that - in what way does distributing a binary suddenly resolve a licence conflict? According to the GPL, GPL'd code can not be linked to QT; _only_ the author of a given piece of code has the right to make an exception to that rule. Because the original in many cases was not written for QT, no such exception is present. I believe that what Moritz is saying is that the main KDE packages (kdesupport, kdelibs, kdebase, kdenetwork, and koffice) are all quite legal because the authors expressly wrote them for use with QT. The only issue is the status of other programs that have been K'ised. So we can just distribute the main KDE packages as part of Debian. I've started making Debian packages of the development releases of the base KDE packages. Is there anyone who's got some space on a fast FTP server where I can store them? -- Got no future, got no past. Here today, built to last.
Re: korganizer debian package (OT: licence interpretation)
Russell Coker wrote: I have one question to that - in what way does distributing a binary suddenly resolve a licence conflict? According to the GPL, GPL'd code can not be linked to QT; _only_ the author of a given piece of code has the right to make an exception to that rule. Because the original in many cases was not written for QT, no such exception is present. I believe that what Moritz is saying is that the main KDE packages (kdesupport, kdelibs, kdebase, kdenetwork, and koffice) are all quite legal because the authors expressly wrote them for use with QT. The only issue is Is this written down in the license? If they're released with plain GPL and without this important notice - which Debian has requested several times - we can't distribute them. I've started making Debian packages of the development releases of the base KDE packages. Is there anyone who's got some space on a fast FTP server where I can store them? Please contact [EMAIL PROTECTED],kde}.org. He has shown interest in keeping maintenance of .deb files for KDE and putting them on ftp.kde.org. Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
On Thu, 8 Oct 1998, Martin Schulze wrote: joey(I thought that debian-devel had reached a consensous that it's not joeya good idea to change the perl version less than 14 days before joeythe code freeze.) Well perl 5.005 is now installed in slink, and when it is installed, alot of stuff breaks (anything for which perl has to include non-standard modules (there are some heavily used non-standard modules (web stuff, perl-tk perl-gtk, ... ). It was supposed to just be a scramble to recompile several things. But now its worse than that-- many more modules need to be repackaged. The worst thing is that we are facing a policy decision on how to handle the change in installation directories. It must be decided before people can begin to fix the 80 odd broken packages. And policy issues tend to get resolved slowly. Raphael suggested modules installing to /usr/lib/perl5/debian and then having the perl package include a symlink to the current version number. Raphael offered to do some NMU's if people asked. I could help too, once the policy is set. We could also force a rebuild (developers) and upgrade (users) every time x changes in 5.00x . Another option is to put the old perl back into slink until the issue can be resolved. Yet another is to configure perl to install stuff according to the old format (the perl configuration scripts can handle this easily ), since we will not have multiple version of perl in the distribution at one time, and this is what the new system is meant to handle. I wrote to perl5-porters asking for some possible tips, but have not heard back yet. I think we need to make a decision rather quickly. If there are some debian developers who know something about the perl development strategy, it would be good to hear from them. I don't know if the perl people really expect everyone to redo the 'perl Makefile.PL ... ' process for every perl package evertime perl is upgraded, but it certainly looks that way. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: exim really does need to be the standard MTA in slink
On Mon, Oct 05, 1998 at 08:31:24PM -0700, Robert Woodcock wrote: [...] so if there seems to be a concensus this time around, I'll file bugs against ftp.debian.org. Filed. It's bug #27642. -- Robert Woodcock - [EMAIL PROTECTED] Unix and C are the ultimate computer viruses -- Richard Gabriel
Re: exim really does need to be the standard MTA in slink
[EMAIL PROTECTED] (Paul Slootman) wrote on 07.10.98 in [EMAIL PROTECTED]: On Tue 06 Oct 1998, Robert Woodcock wrote: Just out of curiosity, what's the security track record on smail vs exim for the last two years? The standard MTA should have a chance of being secure from remote attacks for at least a year after release. Demon (a large ISP in the UK and the Netherlands, www.demon.net) uses Exim as its customer-facing smtp interface, so I guess that they're convinced as well. I'm currently migrating westfalen.de (a small volunteer-run ISP) from smail to exim, partially because the smail anti-relaying stuff is too immature in my eyes, partially because I hate it how smail has more ways to produce bang paths instead of RFC 822 addresses than you can shake a stick at, and partially because exim configuration is just a whole lot saner. (We have a fairly complicated mail configuration for such a small ISP: POP3, UUCP w/rmail and w/bsmtp, some people get mail with SMTP, various different versions of forwarding. Oh, and at least one domain per account.) With that migration, every Linux system I admin will be Debian with Exim. MfG Kai
Re: what's after slink
[EMAIL PROTECTED] (Justin Maurer) wrote on 04.10.98 in [EMAIL PROTECTED]: On a related note, do we want to continue using names from pixar movies now that Bruce is gone? i see no reason not to. they are nice names, the only problem is that we may be running out of good ones (i admit, rc was a stretch) Nice? Hmmm ... just about nobody seems to recognize them, so I hardly think they are particularly nice. More like silly and annoying. MfG Kai
Intent to package: magicpoint
Sorry for so late, I'll upload magicpoint soon. At the present, mgp_1.04a.deb depends vflib, which is in Debian JP Packages and maintained by [EMAIL PROTECTED] He is not an official maintainer now, so current mgp package can not be uploaded. After discussion in Debian JP Projects, I'll upload magicpoint without vflib or I'll take vflib and upload it also. Please wait for a while. Regards, Fumitoshi UKAI / Debian JP Project
Intent to package: libwcsmbs and wcsmbs-locale
As we discussed before, current glibc 2.0.x does not supports major multibyte encodings such as EUC-JP, ShiftJIS, ISO-2022-JP and so on. These encodings are necessary for Japanese processing. So we, Debian JP Projects, developed packages to supports these encodings, libwcsmbs and wcsmbs-locale. The pacakge libwcsmbs will be preloaded and replace wcs-mbs functions to load wcsmbs.so dynamically according to current LC_CTYPE settins. The package wcsmbs-locale provides wcsmbs.so which contains encodings specific conversion routines. wcsmbs-locale also provides some Korean encodings. With these packages, we can use Japanese without major problems. Regards, Fumitoshi UKAI
Intent to package: smtpfeed and sendmail-wide
SMTPfeed is the mail transport agent invoked as LMTP mailer. SMTPfeed requires WIDE patch for sendmail, so I'll upload sendmail-wide package too. The pacakge sendmail-wide is same as sendmail except /usr/sbin/sendmail, so I'd like to build sendmail-wide pacakge depending on sendmail and diverting /usr/sbin/sendmail. About smtpfeed and sendmail WIDE patch, see http://www.wide.ad.jp/~monotori/sendmail.html Regards, Fumitoshi UKAI
Intent to package: fml
FML is GPL'ed the mailing-list management tools, developed by Ken'ichi Fukamachi. This is one of the most popular mailing-list management tools. For more information, see http://www.fml.org/ Regards, Fumitoshi UKAI
Re: Contacting authors
On Thu, 8 October 1998 00:07:26 +0200, Martin Schulze wrote: Re spam: I'd like to make it optional so it does not have to be used but only should. Each pkg. maintainer could negotiate with the upstream author about this feature and not use it if the author doesn't like that. That's what I meant yesterday evening. If we ask and the author gives an ack, this is ok, but some will think of just spam and the like and deny this. We would have an incomplete package-base at authors.debian.org, then... Alexander -- In einem Meer von Schmerz ertrinken die einen, die anderen lernen darin schwimmen (Kyrilla Spiecker) Alexander Koch - - aka Efraim - PGP - 0xE7694969 - Hannover - Germany
Re: Uploaded jadetex 2.2-0.1 (source all) to master
AF == Anthony Fok [EMAIL PROTECTED] writes: AF Hello Adam! :-) * jadetex.dtx: remove T3 since it causes confusing errors w/o the proper font being installed. If someone want's to package 'tipa' from CTAN, then we could bring it back AF You probably know this already: tipa has already been packaged and a copy AF is sitting in experimental. The package works great! I wonder why tipa's AF maintainer Rafael Laboissiere [EMAIL PROTECTED] uploaded it to AF experimental though. :-) AF Rafael, if you have time, maybe you could re-upload tipa into unstable AF (slink)? :-) It works wonderfully here! :-) The tipa package is in experimental for the simple reason that I could not get the author to modify the copyright to be DFSG-compliant. It is not because he does not want to do it in principle, but because he reacts very slowly to my requests. As slink will be frozen soon, I will try to get this issue solved ASAP. I hope that Adam will be able to repackage jadetex with T3 inclusion, as soon as I succeed to upload tipa to slink. -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael
Intent to package LEIM
Is there any technical reason why LEIM (Emacs input methods) is not available as a Debian package? If not, I'll package it. Milan Zamazal -- Having GNU Emacs is like having a dragon's cave of treasures. Robert J. Chassell
Re: what's after slink
Hello, just my two cents to this topic: - Names should be short (= 6 signs) - I don't know The Toystory and I'm sure that it isn't kind of I film I should really watch, but it is a practical naming sheme (short names which everybody can speak and write) - The only case where I would accept longer names would be the Hitchhikers idea. (In contrast to other opinions mentioned here I think there are as many common things between Debian and Toystory and Debian and Hitchhiker -- and one common thing has the Hitchhiker more: IT IS TRUE REALLITY (with ;-) and without ;-) ... see at the people near you and look at yourself with the eyes of an Hitchhiker) - Another naming scheme without any background would be A, B, C... There where programming languages doing this for only three stages to get *very* popular... We would have time for 26 releases to find a better naming scheme. - Names are not importand for the thing itself. When we spend more time to find a good name than to make a good package then we are lost. That's my humble opinion. Kind regards Andreas. PS: My wife's name is Katrin and my son's Alexander, called Alex ... in case you need some further names :-).
Re: what's after slink
Names after Slink is very simple. They should just be named after userfriendly characters. Check out http://www.userfriendly.org
Re: what's after slink
On Thu, 8 Oct 1998 20:09:51 +1300, theone wrote: Names after Slink is very simple. They should just be named after userfriendly characters. Check out http://www.userfriendly.org Dust Bunny!!! Dust Bunny!!! And not Crud Bunny :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. ---+-
Re: what's after slink
On Thu 08 Oct 1998, Kai Henningsen wrote: [EMAIL PROTECTED] (Justin Maurer) wrote on 04.10.98 in [EMAIL PROTECTED]: On a related note, do we want to continue using names from pixar movies now that Bruce is gone? i see no reason not to. they are nice names, the only problem is that we may be running out of good ones (i admit, rc was a stretch) Nice? Hmmm ... just about nobody seems to recognize them, so I hardly think they are particularly nice. More like silly and annoying. I remember when I got my first debian cdrom (1.3.1); looking in the directory gave amongst other bo and boot. My first impression was that someone had screwed up when creating the boot directory the first time. It took a _long_ time for me to realize that bo was in fact the code name for the distribution (around the time I was in the process of becoming a developer, in fact; when I was just a user I never really understood what this bo was doing on my cd. Using something that is more clearly a codename (like Red Hat's Hurricane, for example) would be an advantage there. Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Re: exim really does need to be the standard MTA in slink
On Wed 07 Oct 1998, Steve Lamb wrote:
On Wed, 7 Oct 1998 13:00:51 +0200, Paul Slootman wrote:
I personally have confidence in Exim's quality in this regard.
Demon (a large ISP in the UK and the Netherlands, www.demon.net)
uses Exim as its customer-facing smtp interface, so I guess that they're
convinced as well.
Just curious how you know this since when I telnet to their relay hosts
they are very non-descript about what they run.
[EMAIL PROTECTED]:/home/morpheus}telnet relay-1.mail.demon.net 25
Trying 194.217.242.51...
Connected to relay-1.mail.demon.net.
Escape character is '^]'.
220 relay-1.mail.demon.net Server SMTP (Complaints/bugs to:
Hmm. At least the NL people use Exim (haven't checked what the SMTP
banner says). But when I send mail from my demon account, a line like
the following is in the received headers:
Received: from [194.159.224.75] (helo=wurtel.demon.nl)
by post.mail.nl.demon.net with smtp (Exim 2.02 #1)
id 0zQaxA-0003Hh-00; Tue, 6 Oct 1998 17:31:16 +
The SMTP banner is trivial to customize, of course... The default is
smtp_banner = ${primary_hostname} ESMTP Exim ${version_number} \
#${compile_number} ${tod_full}
Paul Slootman
--
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Re: what's after slink
Debian 2.4 (Erwin/Ix86!) Debian 2.5 (Erwin/iWhack!) I'm sure that Erwin will be on other platforms by the time we get to 2.6.. (=:] Zephaniah E, Hull, --- A big fan of Erwin.. On Thu, Oct 08, 1998 at 12:19:59AM -0700, Steve Lamb wrote: On Thu, 8 Oct 1998 20:09:51 +1300, theone wrote: Names after Slink is very simple. They should just be named after userfriendly characters. Check out http://www.userfriendly.org Dust Bunny!!! Dust Bunny!!! And not Crud Bunny :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your ICQ: 5107343 | main connection to the switchboard of souls. ---+- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpKg1HFp22K1.pgp Description: PGP signature
Slink's boot kernel
Well, kernel 2.0.35 does not support some series of 2940UW (not Ultra and not Wide both are supported). There is some solution for use it but i think some ppl who want to use slink wont know it, so i think we have to write a little README. If i'm right and you want, letme write that readme oldw -- Virtual welcome : Tibor Kolesza'r =[ IntegraNET ]===[ Internet Service Provider Corporation ]= [ Koleszar Tibor - System engineer ] [ E-mail : [EMAIL PROTECTED]] pgpmsCGumDdDY.pgp Description: PGP signature
Re: Perl policy for managing modules ?
Le Wed, Oct 07, 1998 at 04:16:09PM -0700, John Lapeyre écrivait: Thats how I build my perl modules as well (and I guess others), so it shouldn't be too much of a problem. (Acutally some of the more complicated packages will need more changes.) Yes I've looked over source for packages that need to work on my own machine and it was really not hard for upgrading. I had some problems for installing file where I wanted but in fact this should work on most cases : - perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian - but for installing the PREFIX variable is also needed : make pure_install PREFIX=`pwd`/debian/tmp/usr = adapt it for your own package Darren, if you agree, can you modify the perl package in order to install modules in /usr/lib/perl5/debian and make these symlinks ? - /usr/lib/perl5/$arch/$version = /usr/lib/perl5/debian/$arch - /usr/lib/perl5/$version = /usr/lib/perl5/debian I can't think of a better solution. Re: packages with only perl source, many will probably not be affected by an upgrade, and it seems silly to require that they be rebuilt. Yes. I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) Yes, and I wondered why I was the only one who worried about that. :) And it's difficult to move backward since some packages has already been upgraded for perl5.005. Summary: - all packages installing perl modules are broken, they need to be updated using the directory proposed before. (/usr/lib/perl5/debian) There will be NO perl5.005 package using /usr/lib/perl5 for searching modules. - the perl package need to be updated in order to make it work - In fact I don't know if I really should list packages installing modules right now and fill bug report because there are too many (80), I'll wait a few days I think. Richard Braakman asked me for updating lintian so maybe he will be able to fill the bugreports automatically in a few days. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
wheres in.talkd? Also perl5 update error...
Hi all, Just updated my slink machine, and now I've lost in.talkd. Anyone know where it's gone??? Also, I got an error with perl5.004-04-2 overwriting a manual page owned by data-dumper2.09-1. Thanks all, Chris -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Re: perl version depends
Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait: Thus I believe it would need to use (= 5.005-0) (= 5.005) should work too, no ? (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I don't know what debian-devel reached, but in fact it seems to me that just a few people are interested by perl. :-) Some asked to wait, other wanted to switch right now in order to avoid making perl conflict with 35 packages with precise version. In fact perl5.005 uses also new directories for installing modules and that's the current problem. I proposed a little perl policy for managing it. John Lapeyre has made a good summary of solutions available. In fact Perl5.005 is in unstable and some packages (like eperl) have already been updated and uploaded for using perl5.005. If we are able to decide if this perl policy is ok, then we can start to work and it can be done quickly since the only thing to do is to add a litlle LIB=.../perl5/debian in source package and rebuild it. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: Darren, if you agree, can you modify the perl package in order to install modules in /usr/lib/perl5/debian and make these symlinks ? - /usr/lib/perl5/$arch/$version = /usr/lib/perl5/debian/$arch - /usr/lib/perl5/$version = /usr/lib/perl5/debian Okay. That's relatively easy. I can just change privlib and archlib to the directories and put in symlinks. I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. Please lets have a decision on this soon. I've uploaded a new version of Perl right now to fix the data-dumper problem. BTW, the reason that this doesn't affect many people on p5p is that non-core modules are usually installed someplace outside of the Perl tree. INSTALLDIRS=perl is usually only used for the core. John Lapeyre, in an immanent manifestation of deity, wrote: I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) Sorry about that. It is called unstable because things break sometimes. Even on my development box, I watch debian-bugs to see if disastrous things happen. I'm still worried about libc6 2.0.7u-1. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNhyGe44wrq++1Ls5AQETHwP/ZyKbtc/4W4AHh+m/7P63wbr2HiJ5Uivq FtHCkJO7oeMKiDgMTw79PYtkUnKdxj8wsVr8busVav07QXOd7KYA36hfS3A80mi0 i4O9PVv2Akt/h9byFNU31jEMHLe73O00szpCuS28nRkG5wsngMskNtZWJGJOa1/t FpvwZiTv7go= =++nM -END PGP SIGNATURE-
Re: what's after slink
Steve Lamb wrote: Dust Bunny!!! Dust Bunny!!! And not Crud Bunny :) Better not be Bugs Bunny! -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 Let no man say when he is tempted, I am tempted of God; for God cannot be tempted with evil, neither tempteth he any man; But every man is tempted, when he is drawn away of his own lust, and enticed. James 1:13,14
suggestion - AntiVir for Linux
Dear Sirs, we know you as a distributor of program packages for Linux. We, the H+BEDV Datentechnik GmbH, are developer and distributor of the virus protection program AntiVir for Linux. Since 1988, when the number of computer viruses in Germany could be counted on one hand, we deal with the subject virus protection. In the last 11 years we won a lot of awards for our anti-virus products in Germany. Our main market is currently Germany and the german speaking market. Now we are going to expand our distribution area. We would like to make you following suggestion, for our both advantage. We offer you a free version from AntiVir for Linux, so that you will deliver our program with your next distribution CD-ROM. So your customers are able to use a virus protection program under Linux and you add value to your program package. If you want to try AntiVir for Linux, please feel free to download the newest version of AntiVir for Linux from our Internet-Server www.hbedv.com. We offer AntiVir for Linux free of charge for private use. For commercial use, our customers are asked to purchase AntiVir for Linux. We hope our offer meets with your approval and will be pleased to answer any queries you may have. Yours sincerely H+BEDV Datentechnik GmbHLindauer Strasse 21, D-88069 Tettnang Birgitt Simon Tel.: +49 (0) 7542-93040 Fax.: +49 (0) 7542-52510 BBS.: +49 (0) 7542-52110 [EMAIL PROTECTED] http://www.antivir.de
more trouble with deleted root partition please help !!!!! (fwd)
Really sorry for any dupplication but I am desperate. Te broken machine is critical. Thr next two email give more info I would really appreciate any help. For people in and around London if this doesn't work out I am willing to pay to restore my machine George --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html --- -- Forwarded message -- Date: Wed, 7 Oct 1998 22:38:01 +0100 (BST) From: G. Kapetanios [EMAIL PROTECTED] To: debian-user@lists.debian.org Subject: more trouble with deleted root partition please help ! I have manage to salvage a minimal system after accidentally deleting my root partitioon. I tried to install debian stable but it did not work. I did floppy disk installation butfloppy relaiobility does not seem to be the problem. Let me explain why I have the debian disks on an unharmed partiotin which I can access. However the file base2.0_... produces an errror on my system it goes away too fast to read it. Obviously the same error appear with floppies even when I re-downloaded the floppies from the net. I am using july 21 1998 floppies is there a problem with thith those ? Anyway I installed a debian 1.0 ( yes !!) from some old floppies The installation went ok. I have the distribution in a another partiton and I tried to use dselect but the Package file had a problem and dpkg does not work. I can solve the problem only if I could run program from my /usr partiton which I can access This is the second problem I can see the binary I can cat the binary but I can't run it # /usr/bin/less /usr/bin/less: No such file or dicrectory Any ideas ? George --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html ---
HELP!! binaries not executed (fwd)
--- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html --- -- Forwarded message -- Date: Thu, 8 Oct 1998 09:30:25 +0100 (BST) From: G. Kapetanios [EMAIL PROTECTED] To: debian-user@lists.debian.org Subject: HELP!! binaries not executed My question is a result of problems explained in another email. They concer a deleded root partition. My question has to do with binaries which are there can be seen can be read but cannot be executed. for example # /usr/bin/less /usr/bin/less : No such file o directory The same happens to all binaries in /usr which is a mounted partition Tosummarise the setup I have installed an old debian 1.0 system in / and I have all my hamm stuff in /usr Is this a libc5 / libc6 problem --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html ---
boot floppies (july 21 1998) error ? (fwd)
--- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html --- -- Forwarded message -- Date: Thu, 8 Oct 1998 09:35:56 +0100 (BST) From: G. Kapetanios [EMAIL PROTECTED] To: debian-user@lists.debian.org Subject: boot floppies (july 21 1998) error ? I am wondering whether the boot floppies in curent are ok. the rescue disk and drivers isk is working fine but when the base system gets installed and after all the floppies have been read (so no floppy eliability issue) the installation exits with an error. The same happens when installation from hard disk is carried out. Has something drastic chnged in those boot floppies Is there any other set of floppies which are reliable and I can try? I am trying to install a current system because after root partition was deleted I have installed a Debian 1.0 system from old disks Any help would be really, really appreciated George --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html ---
Re: perl version depends
RH == Raphael Hertzog [EMAIL PROTECTED] writes: RH I don't know what debian-devel reached, but in fact it seems to me RH that just a few people are interested by perl. :-) If you want other voices, then count me to the 5.004 for Debian 2.1 party. I agree to Joey's arguments. Ciao, Martin
Re: perl version depends
Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait: Thus I believe it would need to use (= 5.005-0) (= 5.005) should work too, no ? Check out what dpkg thinks about it: finlandia!joey(tty5):/tmp dpkg --compare-versions 5.005 lt 5.005-1; echo $? 0 So, yes, it's also ok. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I don't know what debian-devel reached, but in fact it seems to me that just a few people are interested by perl. :-) Yes, but more people are interested in a broken perl subsystem. John Lapeyre has made a good summary of solutions available. In fact Perl5.005 is in unstable and some packages (like eperl) have already been updated and uploaded for using perl5.005. Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Darren/Torin/Who Ever... wrote: Thus I believe it would need to use (= 5.005-0) But it would also have to use ( 5.006-0). I don't think this is a problem. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I didn't realize this. I saw the comment from Manoj but I also saw several others that said they wanted to see it. We can back out the release if need be. This should be done soon though. I'll still upload a new version tonight. Since the freeze is in 7 days and I don't believe that we can fix all incompatibilities wrt the new version of perl as well as re-compiling all perl packages *after* the main perl package has stabilized, I would like to go back to the old version of perl. My proposal with this version of perl was 7 more days ago. Read: we lost 7 days of integrating perl. Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. Yes it should work too. Please lets have a decision on this soon. Both solutions are OK for me, choose the best (at your opinion, of course). :) BTW, the reason that this doesn't affect many people on p5p is that non-core modules are usually installed someplace outside of the Perl tree. INSTALLDIRS=perl is usually only used for the core. Yes, but it's better leaving site_perl empty. It can be used for manually (modules not in a .deb file) installing modules. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: suggestion - AntiVir for Linux
On Thu, 8 Oct 1998, Birgitt Simon wrote: We offer you a free version from AntiVir for Linux, so that you will deliver our program with your next distribution CD-ROM. When we (Debian) speak of free software, we are referring to freedom, not price. To be included in our CD-ROM, every program must meet a set of conditions, please see our Free Software Guidelines: http://www.debian.org/social_contract#guidelines Thanks. -- 1ece6d42b31c11e4f54ab8fc60c79638 (a truly random sig)
Re: suggestion - AntiVir for Linux
On Thu, Oct 08, 1998 at 10:36:24AM +0100, Birgitt Simon wrote: Dear Sirs, we know you as a distributor of program packages for Linux. We, the H+BEDV Datentechnik GmbH, are developer and distributor of the virus protection program AntiVir for Linux. Since 1988, when the number of computer viruses in Germany could be counted on one hand, we deal with the subject virus protection. In the last 11 years we won a lot of awards for our anti-virus products in Germany. Our main market is currently Germany and the german speaking market. Now we are going to expand our distribution area. snip Since when did linux get virus's You'd only get them on a really bad system - which debian is not (or if you did EVERYTHING as root). Weird Chris -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Squid2, how to handle incompatible upgrade
I'm currently maintaining squid, and squid-2.0 has been released. We have been running the beta versions on our own machines for quite some time and it's much better/faster than the 1.2 versions. However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. How do I handle this? Should I just make a new package squid2 that conflicts with squid-1.2? If I do that, I have the problem that the squid source package creates 4 binary packages. Should I do a new upload of the latest squid-1.2 with only the squid .deb, and upload the rest with squid2? Hmm I've formulated the above as questions, but I plan to do this soon (before the freeze) if nobody objects. Or has a better idea, ofcourse! Mike. -- Did I ever tell you about the illusion of free will? -- Sheriff Lucas Buck, ultimate BOFH.
Re: suggestion - AntiVir for Linux
Before I say anything let me state that I am, currently, not even a registered Debian developer, just a user, however.. I'd suggest that you take a look at the debian web page (www.debian.org), specificly the Social Contract (http://www.debian.org/social_contract), including the DFSG (Debian Free Software Guidelines)... The specific licensing on your software will have to be reviewed to decide if we can include said software in Debian, and if we can what section it will go in.. Well I am sure we would like to include your software in main I suspect, from your message, that due to the license, if we are able to include it at all, it will have to be in non-free.. Thank you for your interest.. Zephaniah E, Hull... On Thu, Oct 08, 1998 at 10:36:24AM +0100, Birgitt Simon wrote: Dear Sirs, we know you as a distributor of program packages for Linux. We, the H+BEDV Datentechnik GmbH, are developer and distributor of the virus protection program AntiVir for Linux. Since 1988, when the number of computer viruses in Germany could be counted on one hand, we deal with the subject virus protection. In the last 11 years we won a lot of awards for our anti-virus products in Germany. Our main market is currently Germany and the german speaking market. Now we are going to expand our distribution area. We would like to make you following suggestion, for our both advantage. We offer you a free version from AntiVir for Linux, so that you will deliver our program with your next distribution CD-ROM. So your customers are able to use a virus protection program under Linux and you add value to your program package. If you want to try AntiVir for Linux, please feel free to download the newest version of AntiVir for Linux from our Internet-Server www.hbedv.com. We offer AntiVir for Linux free of charge for private use. For commercial use, our customers are asked to purchase AntiVir for Linux. We hope our offer meets with your approval and will be pleased to answer any queries you may have. Yours sincerely H+BEDV Datentechnik GmbH Lindauer Strasse 21, D-88069 Tettnang Birgitt Simon Tel.: +49 (0) 7542-93040 Fax.: +49 (0) 7542-52510 BBS.: +49 (0) 7542-52110 [EMAIL PROTECTED] http://www.antivir.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpOKiWtOqZA7.pgp Description: PGP signature
Re: How about using bzip2 as the standard *.deb compression format?
dpkg remains the primary bottleneck in the setup, and apt calls dpkg anyway, so the different is not really significant, and apt-get update is slow too. Joseph Carter [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] On Tue, Oct 06, 1998 at 03:50:01PM -0500, John Goerzen wrote: This is silly. dpkg/dselect are already insanely slow, even on my P166 with 128 meg of RAM -- especially when reading database, etc. If we slow down the installation so much more by using bzip2, then people will simply stop upgrading, or switch to other distributions because it is so slow. That is not acceptable. Um, not all of us are using dselect/dpkg. Most of us refuse to because it's insanely slow and generally braindead if you have a serious conflict. I use dselect/apt myself. [2 application/pgp-signature] -- John Goerzen Linux, Unix consulting programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: Contacting authors
Alexander Koch wrote: On Thu, 8 October 1998 00:07:26 +0200, Martin Schulze wrote: Re spam: I'd like to make it optional so it does not have to be used but only should. Each pkg. maintainer could negotiate with the upstream author about this feature and not use it if the author doesn't like that. That's what I meant yesterday evening. If we ask and the author gives an ack, this is ok, but some will think of just spam and the like and deny this. We would have an incomplete package-base at authors.debian.org, then... Maybe make it different. I'd like get a way to contact the upstream authors without having to dig into the copyright file or even worse (when the maintainer forgot to mention his name plus email there) to dig into the source. Mainly I have the problem that I lose track of all the upstream authors of my own packges. I guess Joey has the same problem just by factor three. I could implement a local registry and implement it on my local system(s) so I'll have [EMAIL PROTECTED] but I thought more globally so other Debian maintainers could benefit from it, too. I'm open to good ideas. Regards, Joey -- The only stupid question is the unasked one. pgpzHrASJRKdO.pgp Description: PGP signature
Re: HELP!! binaries not executed (fwd)
On Thu, Oct 08, 1998 at 11:02:51AM +0100, G. Kapetanios wrote: My question is a result of problems explained in another email. They concer a deleded root partition. My question has to do with binaries which are there can be seen can be read but cannot be executed. for example # /usr/bin/less /usr/bin/less : No such file o directory The same happens to all binaries in /usr which is a mounted partition Tosummarise the setup I have installed an old debian 1.0 system in / and I have all my hamm stuff in /usr Is this a libc5 / libc6 problem Is this an nfs share? Have you tried using exec option when mounting? Chris
Re: Squid2, how to handle incompatible upgrade
In article [EMAIL PROTECTED], Miquel van Smoorenburg [EMAIL PROTECTED] wrote: However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. Never mind - I forgot how I handled it the last time, from the 1.0 to the 1.1 upgrade. Just test in the preinst for the previous version and show a warning, upgrade instructions and a prompt there. Seemed to work the last time .. so it will probably work this time as well. Mike. -- Did I ever tell you about the illusion of free will? -- Sheriff Lucas Buck, ultimate BOFH.
Re: HELP!! binaries not executed (fwd)
On Thu, 8 Oct 1998, Chris wrote: On Thu, Oct 08, 1998 at 11:02:51AM +0100, G. Kapetanios wrote: My question is a result of problems explained in another email. They concer a deleded root partition. My question has to do with binaries which are there can be seen can be read but cannot be executed. for example # /usr/bin/less /usr/bin/less : No such file o directory The same happens to all binaries in /usr which is a mounted partition Tosummarise the setup I have installed an old debian 1.0 system in / and I have all my hamm stuff in /usr Is this a libc5 / libc6 problem Is this an nfs share? Have you tried using exec option when mounting? Chris I mount the /usr partition by mount -t ext2 /dev/hda4 /usr IT is not nfs it is not mounted automatically on boot through /etc/fstab --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html ---
Re: Et toujours dans la langue de chat qui meurt ...
Neale Pickett [EMAIL PROTECTED] writes: Translation: What a bad idea to have made only one page in French! I am getting very fed up with English. (Maybe I (Neale) will try to translate some of the other Debian pages.) But you didn't translate Jacques' translation of `Shakespear'. He referred to English as the language of Shakespear, and then rendered `Shakespear' into french as dying cat (chat qui expire). pjm. jacques siorat writes: La langue de Sheackspear (chat qui expire) Quelle malheureuse idée d'avoir fait une seule et unique page en Français ! Moi qui suit très faché avec l'anglais
Re: perl version depends
Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: HELP!! binaries not executed (fwd)
On Thu, 8 Oct 1998, G. Kapetanios wrote: I have installed an old debian 1.0 system in / and I have all my hamm stuff in /usr Is this a libc5 / libc6 problem? An old Debian 1.0 system? Does your kernel support ELF binaries? ( BTW: Debian 1.0 never existed, could you clarify this? See /etc/debian_version ). -- cbfbaab3704dc2dd44638a38f111d0b3 (a truly random sig)
Re: suggestion - AntiVir for Linux
On Thu, 8 Oct 1998, Chris wrote: Since when did linux get virus's A linux antivirus is a linux program which detects virus in your DOS partition. (At least this is what I understood from the post). -- 59c014d91ae9e30e1552dd2a66f4f4a5 (a truly random sig)
Re: more trouble with deleted root partition please help !!!!! (fwd)
On Thu, Oct 08, 1998 at 11:02:35AM +0100, G. Kapetanios wrote: Really sorry for any dupplication but I am desperate. Te broken machine is critical. Thr next two email give more info I would really appreciate any help. For people in and around London if this doesn't work out I am willing to pay to restore my machine George Hmmlove to help but I'm not in london. I suppose an airfare from down under is out of the question? (lol!) :) Chris -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Re: suggestion - AntiVir for Linux
On Thu, 8 Oct 1998, Chris wrote:
On Thu, Oct 08, 1998 at 10:36:24AM +0100, Birgitt Simon wrote:
Dear Sirs,
we know you as a distributor of program packages for Linux. We, the H+BEDV
Datentechnik GmbH, are developer and distributor of the virus protection
program AntiVir for Linux. Since 1988, when the number of computer viruses
in Germany could be counted on one hand, we deal with the subject virus
protection. In the last 11 years we won a lot of awards for our anti-virus
products in Germany. Our main market is currently Germany and the german
speaking market. Now we are going to expand our distribution area.
snip
Since when did linux get virus's You'd only get them on a really
bad system - which debian is not (or if you did EVERYTHING as root).
On a linux system exporting disk space to Windows machines, it is indeed
practical to have an anti-virus able to report if your shares contains
virii.
Cordialement,
--
- Vincent RENARDIAS[EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:Open Hardware: WAW: -
- http://www.fr.debian.org http://www.openhardware.org http://www.waw.com -
---
-Depuis que ma voiture et mon ordinateur tournent au GPL, les 2 marchent -
- beaucoup mieux et pour moins cher... (Linux: Le seul OS non-polluant!) -
Re: HELP!! binaries not executed (fwd)
On Thu, 8 Oct 1998, Santiago Vila wrote: On Thu, 8 Oct 1998, G. Kapetanios wrote: I have installed an old debian 1.0 system in / and I have all my hamm stuff in /usr Is this a libc5 / libc6 problem? An old Debian 1.0 system? Does your kernel support ELF binaries? sorry 1.1. the kernel is 2.0.0 thanks for your help ( BTW: Debian 1.0 never existed, could you clarify this? See /etc/debian_version ). -- cbfbaab3704dc2dd44638a38f111d0b3 (a truly random sig) --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html ---
Re: perl version depends
Quoting Martin Schulze ([EMAIL PROTECTED]): Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? Mike Stone
Re: perl version depends
Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. That only is a large source of packaging bugs. In fact, the (IMO) most annoying upgrade problem in hamm was a pathname problem: two packages had moved to a different directory at the last minute, and the auto upgrade script hadn't been modified to match. I think we should fall back on perl 5.004, and only move to 5.005 when there's a real plan for upgrading cleanly. Many core utilities rely on perl, as do many maintainerscripts. This problem will *not* go away when the perl packages have been rebuilt -- the upgrade process itself will break. People will be upgrading from hamm to slink when we release it, and they will run into problems like update-inetd breaking halfway through a mass upgrade. Richard Braakman
Re: suggestion - AntiVir for Linux
On Thu, Oct 08, 1998 at 10:36:24AM +0100, Birgitt Simon wrote: Dear Sirs, we know you as a distributor of program packages for Linux. We, the H+BEDV Datentechnik GmbH, are developer and distributor of the virus protection program AntiVir for Linux. Since 1988, when the number of computer viruses in Germany could be counted on one hand, we deal with the subject virus protection. In the last 11 years we won a lot of awards for our anti-virus products in Germany. Our main market is currently Germany and the german speaking market. Now we are going to expand our distribution area. We would like to make you following suggestion, for our both advantage. We offer you a free version from AntiVir for Linux, so that you will deliver our program with your next distribution CD-ROM. So your customers are able to use a virus protection program under Linux and you add value to your program package. I'm sure someone would be happy to package it in .deb format, but by the sounds of your message neither source is included and only non-commercial use is permitted. Either one of these would cause Debian to place your product in its non-free section as it fails the Debian Free Software Guidelines (http://www.debian.org/social_contract). The package would be on the FTP mirrors and people could download and even distribute on CD-ROM that package, but the non-free section would never be distributed by Debian. Many vendors do though, so it's probably not a major worry. pgp2wqc3sxjEO.pgp Description: PGP signature
Re: Squid2, how to handle incompatible upgrade
[EMAIL PROTECTED] (Miquel van Smoorenburg) writes: Never mind - I forgot how I handled it the last time, from the 1.0 to the 1.1 upgrade. Just test in the preinst for the previous version and show a warning, upgrade instructions and a prompt there. Seemed to work the last time .. so it will probably work this time as well. This sounds fine to me. I'm looking forward to squid2. I did notice a reference on the mailing list (no specifics), on a way you could keep your existing cache hierarchy with squid2. Mike.
Re: HELP!! binaries not executed (fwd)
Previously G. Kapetanios wrote: My question is a result of problems explained in another email. They concer a deleded root partition. My question has to do with binaries which are there can be seen can be read but cannot be executed. Check if the binaries are still marked as executable. If not you can make them executable again using chmod. An example: chmod a+x /usr/bin/less If that does not work you can check if all libraries still exist. You can check that using ldd. Another example: [pc135a;~]-6 ldd /usr/bin/less /lib/nfslock.so.0 = /lib/nfslock.so.0 (0x4000d000) libncurses.so.3.4 = /lib/libncurses.so.3.4 (0x40012000) libc.so.6 = /lib/libc.so.6 (0x40057000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) (The specific output can differ). If one or more libraries are missing you will have to reinstall those (and optionally run ldconfig). Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp12Vb4lWpUa.pgp Description: PGP signature
Re: Squid2, how to handle incompatible upgrade
On 8 Oct 1998, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Miquel van Smoorenburg [EMAIL PROTECTED] wrote: However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. Never mind - I forgot how I handled it the last time, from the 1.0 to the 1.1 upgrade. Just test in the preinst for the previous version and show a warning, upgrade instructions and a prompt there. Seemed to work the last time .. so it will probably work this time as well. sounds good to me. btw, i'm already using your squid 1.2-beta23-1 package on several machines. works well. craig -- craig sanders
Re: perl version depends
Michael Stone wrote: Quoting Martin Schulze ([EMAIL PROTECTED]): Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because That's the main cause of this thread... it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? I can't but s/o said that PERL5LIB=/usr/lib/perl5 would help. I haven't tried. I have copied the missing modules into /usr/lib/perl5/5.005 since I had to put the machine back online *quick*. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Richard Braakman wrote: Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. That only is a large source of packaging bugs. In fact, the (IMO) most annoying upgrade problem in hamm was a pathname problem: two packages had moved to a different directory at the last minute, and the auto upgrade script hadn't been modified to match. Speaking of the upgrade script, is there *any* reason why /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh since Sep 5th? I think we should fall back on perl 5.004, and only move to 5.005 when there's a real plan for upgrading cleanly. Many core utilities rely When slink is released it's time to break sid. No problem with this. That's the usual way to switch to newer versions of programs. Regards, Joey -- The only stupid question is the unasked one.
Re: How about using bzip2 as the standard *.deb compression format?
On Thu, Oct 08, 1998 at 06:40:09AM -0500, John Goerzen wrote: dpkg remains the primary bottleneck in the setup, and apt calls dpkg anyway, so the different is not really significant, and apt-get update is slow too. The update phase seems to be slow because of translating the package files to dselect's format on my system. (pending apt's GUI, I'm using dselect) If dselect could use apt's native format, that would be faster. If package files were made by section, apt would not have to download main's pacakages.gz everytime one little package in one little section was updated. dpkg too would benefit from using a hashed database for lookups too, though I think a text database that could be rehased would be nice too. If others think that's not necessary, I'll live without it. After all, dpkg is quite stable despite a couple buglets. If the new database code were also stable (read: simplistic enough that it would just work) I'd not worry about dpkg losing its database or anything. I'm curious as to what enhancements Ian has planned for dpkg whenever he finds time to return to working on it. pgpwMhJmr2xQ6.pgp Description: PGP signature
Re: Squid2, how to handle incompatible upgrade
Miquel van Smoorenburg wrote: I'm currently maintaining squid, and squid-2.0 has been released. We have been running the beta versions on our own machines for quite some time and it's much better/faster than the 1.2 versions. However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. How do I handle this? Should I just make a new package squid2 that conflicts with squid-1.2? I would'n't like to introduce a new set of packages. You should however ensure that the old configuration file is saved. Wrt. spool file: I believe that it is acceptable to blow the old spool away if the new squid gains more speed. If I do that, I have the problem that the squid source package creates 4 binary packages. Should I do a new upload of the latest squid-1.2 with only the squid .deb, and upload the rest with squid2? Depends on the purpose of the other packages... Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Previously Martin Schulze wrote: Speaking of the upgrade script, is there *any* reason why /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh since Sep 5th? Possibly the same reason nothing has moved from proposed-updates to stable for a long time now I guess... When slink is released it's time to break sid. No problem with this. That's the usual way to switch to newer versions of programs. unstable rather then sid.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpp8X3SUN0Dv.pgp Description: PGP signature
HELP!! binaries not executed (fwd)
This email explains the problems I had with my deleted root partition George --- George Kapetanios Churchill College Cambridge, CB3 0DSE-Mail: [EMAIL PROTECTED] U.K. WWW: http://garfield.chu.cam.ac.uk/~gk205/work_info.html --- -- Forwarded message -- Date: Thu, 8 Oct 1998 14:04:46 +0100 (BST) From: G. Kapetanios [EMAIL PROTECTED] To: Chris [EMAIL PROTECTED] Subject: Re: HELP!! binaries not executed (fwd) On Thu, 8 Oct 1998, Chris wrote: On Thu, Oct 08, 1998 at 01:12:30PM +0100, G. Kapetanios wrote: What kernel are you running? it is debian 1.0 kernel 2.0.0 (the only disks that would work) What shell are you using (and from what dist)? the initial shell of debian i think ash and then bash from debian 1.0 Have you run e2fsck on the partition? yes no errors reported i was thinking it may help if i check the hidden characteristics of the files in /usr. As i remember (i am at work now ) if i copy the file to / it still does not work if i copy a file from / to /usr it works BTW, I've had no problems with current boot dists, is that the only thing stopping you reinstalling the entire system? yes i tried the final bo disks but the disks were not reliable and i cant find them on the net any more. i tried the hamm july 21 1998 both from floppies and hard disk there seems to a problem in base2_0 for my system. error goes by too quickly to see i think it has something to do with a file not found could be connected to the other problem, i guess. thanks very much for your help hope you can give me some advice. george Sorry for the delay, was on the phone to the gf (geez she can talk!) Now, from my guess I'd say that the kernel you are using does not support ELF binaries (I haven't verified this, it's just a guess - I'll check later). I think this especially as you can copy a file into usr and still execute it, which means a problem with the file type (The only other possiblity is if the binaries in /usr/ are ALL corrupted - very unlikely. If you want to check this send me a binary (say less) with your next mail). I would suggest updating the kernel. Now, there are two ways of going... you can try to update the system by install 2.0, which means we'll have to deal with the error mentioned above, or you can try to install a new kernel. To install a new kernel, try downloading a precompiled kernel, putting this on your root partition, and pointing lilo to it (I assume you know how to do that? If not let me know). I think you can get a debian package containing a precompiled kernel (but it's a new package format, you'd have to extract the image from it) or I can send you one if you like. An even better solution is to use another machine to compile one. Id say to use kernel 2.0.3x (although it doesn't really matter). Otherwise we can try and fix that error, in which case you'll need to tell me *exactly* what steps you went through during your attempted install. (ie. where got the files from, what installation media your using, where you put the base2_0.tgz file, what options you use in the installation tool, etc, etc). Thanks very much for your help. Now I would rather go for the debian 2.0 installation so that I can avoid the problematic libc5-libc6 upgrade. The story is as follows Two days ago I had installed the bo disks ok. But I made a stupid (yet another ) mistake I had the system installed on /dev/hda4 which should be /usr and not on /dev/hda3 which is normally my / Then i had a lilo.con pointing to /dev/hda3 and therefore I could boot from the floppy but not from the disk. I tried installing the hamm disks from the second hard disk. (I have the debian hamm disks and distribution in /dev/hdc2 and /dev/hdc3 The critical stuff I do not want to lose re in /dev/hdc1 All these partitions seem ok I don't want to access them too often in case something goes wrong.) The installation broke down at the base2_0.tgz stage with an error similar to that I have now (but not the saem I think) This was probably becasue of the / /usr mixup When i realised the e / /usr mixup I decided to reinstall from scratch rather than copy the files because i thought the t the system.map e.t.c. would have to chnage But the bo disks would not work now (disks corrupted) (very unluckI could download them because I can't find them on the net. Then I installed the debian 1.1 stuff. with 2.0.0 kernel. Now I don't think i have tried the hard disk install method for the 2.0.0 kernel I downloaded yestrday the hamm disks from a mirror and tried it. Rescue is ok the problem comes with the install base system. The disks are read stored and unpaked the program starts running but stops pretty soon and saya it can't find something I do't
Re: perl version depends
Le Thu, Oct 08, 1998 at 02:42:59PM +0200, Richard Braakman écrivait: itself will break. People will be upgrading from hamm to slink when we release it, and they will run into problems like update-inetd breaking halfway through a mass upgrade. This would not be the case when packages will be updated. If you take slink at the present state, this sort of things will happen. But when package will be updated (including netbase for installing DebianNet.pm into /usr/lib/perl5/debian) those problem should not remain. Well I don't know how apt would do a dist-upgrade but I think, it will start with installing base/* packages. So update-inetd should work. If you think that the problem can arise before perl5.005 is installed but after netbase then the netbase package should depend or pre-depend on perl-base_5.005. And in fact such problem are only possible with DebianNet.pm, Debian::DpkgFtp or libnet modules. They are in base and other package may depend on it. We have to pay attention how they are installed. In order: 1 perl-base (here no package using DebianNet.pm/libnet/dpkg-ftp should be installed) 2 netbase 3 libnet 4 dpkg-ftp So libnet must (pre-)depend on perl-base5.005 and netbase too. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Support for multiple CD's
I guess that we all have realized that slink doesn't fit on one CD anymore. Slink's total size for binary-i386 e.g. is 749 MB. Thus slink has to be splitted over two official cd roms. Currently slink doesn't contain an access method that can handle multiple cd roms if not all cd-roms are available at the same time. How are we going to handle this? I know that Heiko Schlittermann has developed a multi-cd package that provides a new access method for dselect but needs a patch for dpkg-scanpackages. Regards, Joey -- The only stupid question is the unasked one.
Re: suggestion - AntiVir for Linux
On Thu, Oct 08, 1998 at 06:00:00AM -0700, Joseph Carter wrote: On Thu, Oct 08, 1998 at 10:36:24AM +0100, Birgitt Simon wrote: Dear Sirs, we know you as a distributor of program packages for Linux. We, the H+BEDV Datentechnik GmbH, are developer and distributor of the virus protection program AntiVir for Linux. Since 1988, when the number of computer viruses in Germany could be counted on one hand, we deal with the subject virus protection. In the last 11 years we won a lot of awards for our anti-virus products in Germany. Our main market is currently Germany and the german speaking market. Now we are going to expand our distribution area. We would like to make you following suggestion, for our both advantage. We offer you a free version from AntiVir for Linux, so that you will deliver our program with your next distribution CD-ROM. So your customers are able to use a virus protection program under Linux and you add value to your program package. I'm sure someone would be happy to package it in .deb format, but by the sounds of your message neither source is included and only non-commercial use is permitted. Either one of these would cause Debian to place your product in its non-free section as it fails the Debian Free Software Guidelines (http://www.debian.org/social_contract). The package would be on the FTP mirrors and people could download and even distribute on CD-ROM that package, but the non-free section would never be distributed by Debian. Many vendors do though, so it's probably not a major worry. I didn't catch the begining of this thead but... if noone else has stepped up I would be happy to work on this. (from the first statement of I'm sure someone would be happy to package it in .deb format it sounds like noone has yet) I can't make out from the snippit of the original message if this would be distributable via FTP site like this or not...seems like it... but if not I would be happy to package it in deb format so that it could be distributed by others that way. -Steve -- /* -- Stephen Carpenter [EMAIL PROTECTED] --- [EMAIL PROTECTED] */ E-mail Bumper Stickers: A FREE America or a Drug-Free America: You can't have both! honk if you Love Linux
Bug#27663: project: installing linuxconf on my maschine running Debian slink
Package: project Version: N/A Farris: ~/install# dpkg -i linuxconf_1.10r34-1_i386.deb (Reading database ... 62852 files and directories currently installed.) Unpacking linuxconf (from linuxconf_1.10r34-1_i386.deb) ... dpkg: error processing linuxconf_1.10r34-1_i386.deb (--install): trying to overwrite `/etc/init.d/rc', which is also in package sysvinit dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: linuxconf_1.10r34-1_i386.deb -- System Information Debian Release: slink Kernel Version: Linux Farris 2.0.35 #6 Tue Sep 22 00:07:45 CEST 1998 i586 unknown
problems with dselect/apt
hello, since i installed debian some weeks ago i encounter problems when trying to update the system, or want to install new packages, further i wanted to pass on to apt, but this doesn't work due to the dpkg problems i still have: on dselect-config i get the following messages:i running dpkg --pending --configure ... Setting up auto-pgp (1.04-1) ... install-info: unrecognized option `--description=PGP tools for command-line and Emacs use.' Try `install-info --help' for a complete list of options. dpkg: error processing auto-pgp (--configure): subprocess post-installation script returned error exit status 1 Setting up gmp2 (2.0.2-6) ... install-info: No such file or directory for Development dpkg: error processing gmp2 (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of gmp2-dev: gmp2-dev depends on gmp2; however: Package gmp2 is not configured yet. dpkg: error processing gmp2-dev (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of ssh: ssh depends on gmp2 (= 2.0.2); however: Package gmp2 is not configured yet. dpkg: error processing ssh (--configure): dependency problems - leaving unconfigured Setting up netscape4 (4.0-12) ... ERROR: The Netscape archive must be in /tmp, owned by root, and under a name matching one of the following: communicator-v4*.x86-*-linux*.tar* navigator-v4*.x86-*-linux*.tar* Archive files can be found on ftp.netscape.com and its mirrors. dpkg: error processing netscape4 (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of ssh-askpass: ssh-askpass depends on ssh (= 1.2.26-1); however: Package ssh is not configured yet. dpkg: error processing ssh-askpass (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: auto-pgp gmp2 gmp2-dev ssh netscape4 ssh-askpass dpkg --configure returned error exit status 1. Press RETURN to continue. now netscape isntalled successfully and is up and running, but for some reason it is tagged as unconfigured but more annoying are the other packages that don't install the problem with e.g. the gmp2 package is that it reports too bad state to be removed, necessiting a reinstallation, which isn't possible trying to use apt doesn't solve the problem: fiddling around make it even worse, now i have from the apt-get update: Checking system integrity...dependency error You might want to run `apt-get -f install' to correct these. Sorry, but the following packages are broken - this means they have unmet dependencies: libc6-doc: Depends:libc6 what can i do to get again a clean system? BTW i didn't managed to get onto the devel mailing list, so please enclose a CC to me when replying. ciao bboett == acount at earthling net http://erm6.u-strasbg.fr/~bboett === Unsolicited commercial email is NOT welcome at this email address To contact me replace acount by bboett in above addresses
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Dan
Re: HELP!! binaries not executed (fwd)
On Thu, Oct 08, 1998 at 02:04:46PM +0100, G. Kapetanios wrote: snip I do't know what because the ncurses prompt is on top. I press ok it saya something too fast for me to read and goes back to the main menu I was thiing of downloading the base2_0.tgz stuff putting them in the /dev/hda1 (dos) partiton and rerunning the install in case it minds that the stuff is in /dev/hdc2 I really appreciate your help That's ok :) Allrighty thenfirst off, if you do have a problem then you can hit ALT-3 (or any other number from 2-6) to get to a virtual terminal. Now, I think I've seen the kind of error you were talking about. One solution to this is to actually mount the drive by hand. Try the following: Open a virtual terminal (see above), then run the following: # cd / # mkdir mnt2 # mount -t vfat /dev/hdc2 /mnt2 (maybe use -t msdos) # ls /mnt2 (you should see base2_0.tgz in here) Switch back to the curses screen (ALT-1?) Now try specifying the base location as an allready mounted partition, /mnt2/. Let me know how that goes. Chris BTW, Does anyone know why this happens sometimes??? -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Re: more trouble with deleted root partition please help !!!!! (fwd)
G. Kapetanios wrote: I would really appreciate any help. For people in and around London if this doesn't work out I am willing to pay to restore my machine Are you in London or in Cambridge? Surely there's someone in Cambridge who can help? If I needed to, I could get to London in 2 hours; Cambridge would take longer. I have manage to salvage a minimal system after accidentally deleting my root partitioon. I tried to install debian stable but it did not work. I did floppy disk installation butfloppy relaiobility does not seem to be the problem. Let me explain why I have the debian disks on an unharmed partiotin which I can access. However the file base2.0_... produces an errror This is one area where the installation process falls down: if there are any errors they are all too likely to get overwritten by the next bit of fancy screen stuff; there should be an option for a pure dumb screen install, so that anything that appears on the screen is left there until it scrolls off the top. on my system it goes away too fast to read it. Obviously the same error appear with floppies even when I re-downloaded the floppies from the net. I am using july 21 1998 floppies is there a problem with thith those ? Anyway I installed a debian 1.0 ( yes !!) from some old floppies The installation went ok. I have the distribution in a another partiton and I tried to use dselect but the Package file had a problem and dpkg does not work. I can solve the problem only if I could run program from my /usr partiton which I can access This is the second problem I can see the binary I can cat the binary but I can't run it # /usr/bin/less /usr/bin/less: No such file or dicrectory This is not what you get for a missing file: $ /usr/bin/junk bash: /usr/bin/junk: No such file or directory I wonder if it is looking for a shared library that you haven't loaded? That isn't the message I see for a missing shared library, but things may have been different for that version. If you were running version 2.0 before you lost your root partition, all your standard commands will be compiled against libc6. Now you have installed 1.1, you don't have libc6, so the newer commands cannot run. This is a double bind: you cannot run dpkg (libc6) until you have installed libc6, but you cannot install libc6 without dpkg. It sounds as if you have got to reinstall with 2.0 or later. I cannot make out from your message whether your problem with 2.0 is during the installation process. Can you boot from a CD? or put your hard disk into a machine that can? If you cannot install 2.0 at all, you will need to get hold of the shared libraries that are needed by all the programs you want to run. For dpkg, these are: $ ldd /usr/bin/dpkg libdpkg.so.0 = /usr/lib/libdpkg.so.0 (0x4000c000) libc.so.6 = /lib/libc.so.6 (0x40027000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) You will need someone else with a working 2.0 system to copy these from, or else extract them from the appropriate .deb files onto some working machine (remember that a .deb file is an ar archive that contains a tar archive of the software.) -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 Let no man say when he is tempted, I am tempted of God; for God cannot be tempted with evil, neither tempteth he any man; But every man is tempted, when he is drawn away of his own lust, and enticed. James 1:13,14
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. What about also adding /usr/lib/perl5(/$arch)? at the end of @INC ? Is it possible ? In that way, recent packages that are installed in /usr/lib/perl5/debian are used first and only if no package is found in the standard path then perl will search for modules in /usr/lib/perl5. If we can do it, I think that's the best solution in order no to break non architecture dependent packages that already exists. That way there will never be any problem with DebianNet.pm and other modules. And we also can move slowly to a unified directory tree. Otherwise the transition seems to be too difficult. I hope this can solve our current problem (and by the way make it include in slink). Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Contacting authors
Martin Schulze wrote: An easy way to implement this would be to simply add a line to the source section of debian/control of each package like Source: gtkfind Section: x11 Priority: optional Maintainer: Martin Schulze [EMAIL PROTECTED] Author: Matt Grossman [EMAIL PROTECTED] this one Standards-Version: 2.4.0.0 I've always found it funny that the upstream author's name doesn't appear anywhere during package selection (except in /usr/doc/PACKAGE/ after a package is installed). The author should get the credit, and more exposition... Or are we afraid that they might get bug reports that should go the the Debian bug tracking system? Peter
Re: Intent to package: smtpfeed and sendmail-wide
hrm... The requested URL /~monotori/sendmail.html was not found on this server. Is there somewhere else I can look? am I correct in assuming that WIDE is support for DBCS? -- Rick Nelson On Thu, 8 Oct 1998, Fumitoshi UKAI wrote: Date: Thu, 08 Oct 1998 14:34:14 +0900 (JST) From: Fumitoshi UKAI [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Intent to package: smtpfeed and sendmail-wide Resent-Date: 8 Oct 1998 05:34:24 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; SMTPfeed is the mail transport agent invoked as LMTP mailer. SMTPfeed requires WIDE patch for sendmail, so I'll upload sendmail-wide package too. The pacakge sendmail-wide is same as sendmail except /usr/sbin/sendmail, so I'd like to build sendmail-wide pacakge depending on sendmail and diverting /usr/sbin/sendmail. About smtpfeed and sendmail WIDE patch, see http://www.wide.ad.jp/~monotori/sendmail.html Regards, Fumitoshi UKAI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz écrivait: My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand Because most of the perl modules will work with all coming version of perl. Because Debian doesn't allow different version of the same package to be on the same machine. Because we don't want to have to update the packages that contains modules each time a new perl version comes out. that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Explain more here, how would you manage a versioned directory without changing the modules packages each time a new perl version comes out ? Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
dpkg config files in /etc ?
Hi, the configuration files of all debian packages are located in /etc. That's really fine. But the package manager stores its configuration (access method, list of selected packages, ...) somewhere in /var/lib/dpkg. Why? If these items would be stored in /etc, one could rebuild the system from scratch solely from a backup copy of /etc and a debian mirror. BTW: /etc/debian_version is not a configurable item (it would be fine to upgrade the system by editing /etc/debian_version :-) Cheers, Thomas -- Th. Gebhardt ([EMAIL PROTECTED]) --- HRZ, Hans Meerwein Strasse,Phone: +49-6421/28-3572 D-35032 Marburg, Germany Fax :-6994
Re: dpkg config files in /etc ?
Thomas Gebhardt [EMAIL PROTECTED] writes: Hi, the configuration files of all debian packages are located in /etc. That's really fine. But the package manager stores its configuration (access method, list of selected packages, ...) somewhere in /var/lib/dpkg. Why? Configuration goes in /etc, state goes in /var. Steve [EMAIL PROTECTED]
Re: dpkg config files in /etc ?
Thomas Gebhardt [EMAIL PROTECTED] writes: the configuration files of all debian packages are located in /etc. That's really fine. But the package manager stores its configuration (access method, list of selected packages, ...) somewhere in /var/lib/dpkg. Why? Steve Dunham wrote: Configuration goes in /etc, state goes in /var. But the access method is not a state, it's a configuration. One could also argue that the list of selected packages is also a configuration since it results directly from user _selection_ (almost a synonym for configuration).
Re: dpkg config files in /etc ?
Hi, But the package manager stores its configuration (access method, list of selected packages, ...) somewhere in /var/lib/dpkg. Why? Configuration goes in /etc, state goes in /var. Ok. So the information about the configured access method and the list of selected packages should be stored in /etc. The information about the packages that are actually installed/available should be found in /var. And debian_version should go to /var. Am I right? Thomas
Freeze in 7 days??? (was Re: perl version depends)
Hi. 1) Don't we have to recompile all our ncurses-based apps against 4.2? 2) Are we really going to freeze slink in 7 days? I see that 1) and 2) don't mix very well. -- 76975153d9e889b854dd4ae6c231f5e9 (a truly random sig)
Re: perl version depends
On Thu, 8 Oct 1998, Martin Schulze wrote: When slink is released it's time to break sid. I guess you mean here it's time to break [codename for 2.2 (or 3.0)]. (By definition, sid will never be released). -- ad283d11c8d64562db7796279c3f4be8 (a truly random sig)
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, Oct 08, 1998 at 05:53:19PM +0200, Santiago Vila wrote: 1) Don't we have to recompile all our ncurses-based apps against 4.2? If we want all the ncurses-based apps to use the same version of ncurses, yes. I'm not sure if we have to, though if I were the release manager, I wouldn't release 2.1 before all ncurses-based apps used the same version. 2) Are we really going to freeze slink in 7 days? Yes. I see that 1) and 2) don't mix very well. That depends on what type of changes the release manager will accept into frozen. Brian, could you please state what your plans in this regard are? Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: How can Debian accomodate new installation ?
John == John Lapeyre [EMAIL PROTECTED] writes: John Hi, I have packaged several modules for Debian Linux. John We are currently discussing how to handle your new John installation hierarchy. I'd appreciate comments. We John currently have about 80 packages that would need to be John recompiled or repackaged every time the x in 5.00x changes. John We are also considered installing everything in, for John instance, /usr/lib/perl5/debian and making a symlink to the John current perl version number. Here's one debian developer on both lists. :) The site_arch component of @INC was specifically designed for this, to save recompiling perl modules everytime there's a new perl version. Site_arch does require, however, that binary compatibility be maintained between perl releases and 5.005 broke that compatibility. So no matter what you do, any XS module will need re-compiling (and if you start altering the contents of @INC, non-XS modules will need reinstalling too). Should 5.006 again break binary compatibility, you will again face this problem. Generally, though, p5p and the pumpking in particular do not break binary compatibility without an incredibly good reason (for 5.005 that reasons was threads, PERL_OBJECT and the move to ansi-ness). It's not clear to me why debian began installing modules in perl_arch by default. Perhaps Darren knows. One other thing. None of perl's paths are cast in stone, they are all changable at build time. Darren could simply choose to build perl with a debian specific set of paths, rather than following the possibly changeable perl default paths. -- Stephen --- Perl is really designed more for the guys that will hack Perl at least 20 minutes a day for the rest of their career. TCL/Python is more a 20 minutes a week, and VB is probably in that 20 minutes a month group. :) -- Randal Schwartz
Re: 1st unpacking, 2nd dependency checking
On Thu, 8 Oct 1998, Martin Schulze wrote: This might be an faq. But occasionally I notices that dpkg first unpacks and installs the files in a particular package and checks dependencies afterwards. This means that wrong dependencies are discovered when it is too late since the old version of the package is already overwritten. I'm sure there is a rationale for this, but what is it? The rationale is that this would make package installing too much troublesome, if not impossible in some cases. In particular, if A depends on B and B depends on A, you would be unable to install A and B at all. With the current design, you can. At least I would have expected that dpkg tests the dependency of new packages and refuses to unpack them - unless one told it to ignore dependencies. This is exactly the case for Pre-Dependencies, and that's the reason why essential packages need Pre-Dependencies as a general rule (we can not afford to have them broken at *any* time). For non-essential packages, the user is supposed to be able to use the packaging system (dselect, dpkg, etc.), which is supposed not to be broken thanks to the Pre-dependencies, to satisfy any remaining broken (not Pre-)dependencies. -- f1d425529e79e6faba09bd7e97315457 (a truly random sig)
Re: dpkg config files in /etc ?
Thomas Gebhardt wrote: And debian_version should go to /var. debian_version is static. It should not go to /var. The fact that it changes every time you upgrade the entire system does not make it to be less static. Otherwise we would have to move /usr to /var as well, since it does also change most of the time on upgrades (I don't know of any case of package in Debian 1.3.1 for which there was not a newer version available in Debian 2.0). -- dcb085e5045286a9c51c91fd1609fc9d (a truly random sig)
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, 8 Oct 1998, Brian White wrote: The general guideline for frozen is: no new code A recompile with a new package is fine. Fixes to make something work with a change in another package is also fine. Does this mean also no new documentation? For slink, I plan to provide the texi2html-converted HTML for all my GNU packages, which means a new package foo-doc for every GNU foo package. Do I absolutely have to do this before the freeze? Will all my foo-doc packages be rejected because no new packages? -- 35068fe90da2260a88a96e33ee9316af (a truly random sig)
Re: Freeze in 7 days??? (was Re: perl version depends)
Does this mean also no new documentation? No. For slink, I plan to provide the texi2html-converted HTML for all my GNU packages, which means a new package foo-doc for every GNU foo package. Do I absolutely have to do this before the freeze? Will all my foo-doc packages be rejected because no new packages? There should be no problem with that. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.04. For this and more, visit http://www.verisim.com/
yagirc bugs - new maintainer or not?
I recall someone wanting to take over yagirc after I offered it up. Is this person still interested? They ought to upload a new, up to date version with someo of these bugs fixed. Otherwise, I'll try and do it. - To: [EMAIL PROTECTED] X-Mailer: bug 3.1.6.1 Message-Id: [EMAIL PROTECTED] Date: Fri, 9 Oct 1998 00:20:06 +1000 Package: yagirc Version: 0.63-1 /bin/yagirc doesn't seem to be the appropriate place for the binary, perhaps in /usr/X11R6/bin or even /usr/bin ? -- System Information Debian Release: slink Kernel Version: Linux gumby 2.1.115 #1 SMP Tue Aug 18 13:59:45 EST 1998 i586 unknown Versions of the packages yagirc depends on: ii libc6 2.0.7u-2 The GNU C library version 2 (run-time files) ii libgtk1 1.0.6-2The GIMP Toolkit set of widgets for X ii xlib6g 3.3.2.3a-1 shared libraries required by X clients -End of forwarded message- -- David Welton http://www.efn.org/~davidw --Debian GNU/Linux--
Re: How can Debian accomodate new installation ?
On Thu, 8 Oct 1998, Stephen Zander wrote: It's not clear to me why debian began installing modules in perl_arch by default. Perhaps Darren knows. Debian (sensibly, in my opinion) puts $sitelib and $sitearch in /usr/local and leaves them for the individual end user to use to install local extensions. The problem arises, then, what to do with modules such as Tk, which Debian supplies in precompiled form. Darren's solution of putting all Debian-supplied extensions (be they part of the perl core, such as POSIX.so or optional extensions, such as Tk.so) in the Debian-controlled /usr/lib/perl5 hierarchy makes good sense to me. The problem then arises what to do when perl undergoes a minor maintenance revision (e.g. 5.004_02 - 5.004_03). Since these minor maintenance revisions are supposed to maintain binary compatibility, there is no need to recompile all the add-on extensions right away. However, the default perl installation directory would have changed from 5.00402 to 5.00403, and suddenly the modules would have apparently disappeared. Darren neatly solved _that_ problem by omitting the subversion number on maintenance releases so that all of 5.004_0x modules go into the /usr/lib/perl5/i386-linux/5.004/ directory. Upgrades between compatible perl maintenance subversions then don't break other modules. One of the primary purposes of perl's installation directory structure (and recent reorganization) was to allow users to have more than one version of perl installed at a time. Debian users generally don't do that -- perl5.005 will replace 5.004 -- so the installation hierarchy probably doesn't help all that much. Once 5.004 is replaced, all the compiled modules that were built under it will become immediately non-working, and they will need to be replaced too. (I suppose one could draw upon the a.out-ELF or libc5-libc6 experience to try to make a smooth transition, but I'm not sure it'd be worth it.) Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: How can Debian accomodate new installation ?
Andy == Andy Dougherty [EMAIL PROTECTED] writes: [snip] That's what I hate about you, Andy. You always have such clear and rational explanations for things :) -- Stephen --- Perl is really designed more for the guys that will hack Perl at least 20 minutes a day for the rest of their career. TCL/Python is more a 20 minutes a week, and VB is probably in that 20 minutes a month group. :) -- Randal Schwartz
Re: File renamer
David Welton writes (File renamer):
Hi, a friend of mine wrote a thing to rename a bunch of files, say
*.jpg to *.gif. Yes, he realizes you can do the same thing with a
shell script, but he wrote this thing just the same, because it's
convenient.
Does anyone know of anything similiar? That is not a .deb ?
Otherwise I'll package it just for fun:-
A whole .deb for such a simple problem seems overkill. The
file/manpage below is what I use. It was in the Perl4 distribution.
Presumably perl5 comes with it too in the source. I have it as
/usr/local/bin/rename.
Ian.
#!/usr/bin/perl
'di';
'ig00';
#
# $Header: rename,v 3.0.1.2 90/08/09 03:17:57 lwall Locked $
#
# $Log: rename,v $
# Revision 3.0.1.2 90/08/09 03:17:57 lwall
# patch19: added man page for relink and rename
#
if ($ARGV[0] eq '-i') {
shift;
if (open(TTYIN, /dev/tty) open(TTYOUT,/dev/tty)) {
$inspect++;
select((select(TTYOUT),$|=1)[0]);
}
}
($op = shift) || die Usage: rename [-i] perlexpr [filenames]\n;
if ([EMAIL PROTECTED]) {
@ARGV = STDIN;
chop(@ARGV);
}
for (@ARGV) {
unless (-e) {
print STDERR $0: $_: $!\n;
$status = 1;
next;
}
$was = $_;
eval $op;
die $@ if $@;
if ($was ne $_) {
if ($inspect -e) {
print TTYOUT remove $_? ;
next unless TTYIN =~ /^y/i;
}
unless (rename($was, $_)) {
print STDERR $0: can't rename $was to $_: $!\n;
$status = 1;
}
}
}
exit $status;
##
# These next few lines are legal in both Perl and nroff.
.00;# finish .ig
'di \ finish diversion--previous line must be blank
.nr nl 0-1 \ fake up transition to first page again
.nr % 0 \ start at page 1
';'.ex'; #__END__ # From here on it's a standard manual page
.TH RENAME 1 July 30, 1990
.AT 3
.SH NAME
rename \- renames multiple files
.SH SYNOPSIS
.B rename [-i] perlexpr [files]
.SH DESCRIPTION
.I Rename
renames the filenames supplied according to the rule specified as the
first argument.
The argument is a Perl expression which is expected to modify the $_
string in Perl for at least some of the filenames specified.
If a given filename is not modified by the expression, it will not be
renamed.
If no filenames are given on the command line, filenames will be read
via standard input.
.PP
The
.B \-i
flag will prompt to remove the old file first if it exists. This
flag will be ignored if there is no tty.
.PP
For example, to rename all files matching *.bak to strip the extension,
you might say
.nf
rename 's/\e.bak$//' *.bak
.fi
To translate uppercase names to lower, you'd use
.nf
rename 'y/A-Z/a-z/' *
.fi
To do the same thing but leave Makefiles unharmed:
.nf
rename 'y/A-Z/a-z/ unless /^Make/' *
.fi
To rename all the *.f files to *.BAD, you'd use
.nf
rename 's/\e.f$/.BAD/' *.f
.SH ENVIRONMENT
.fi
No environment variables are used.
.SH FILES
.SH AUTHOR
Larry Wall
.SH SEE ALSO
mv(1)
.br
perl(1)
.SH DIAGNOSTICS
If you give an invalid Perl expression, you'll get a syntax error.
.SH BUGS
.I Rename
does not check for the existence of target filenames (without
the -i switch), so use with care.
.ex
Re: File renamer
*- Ian Jackson wrote about Re: File renamer | David Welton writes (File renamer): | Hi, a friend of mine wrote a thing to rename a bunch of files, say | *.jpg to *.gif. Yes, he realizes you can do the same thing with a | shell script, but he wrote this thing just the same, because it's | convenient. | | Does anyone know of anything similiar? That is not a .deb ? | Otherwise I'll package it just for fun:- | | A whole .deb for such a simple problem seems overkill. The | file/manpage below is what I use. It was in the Perl4 distribution. | Presumably perl5 comes with it too in the source. I have it as | /usr/local/bin/rename. | There is also the mmv package Package: mmv Status: install ok installed Priority: optional Section: utils Installed-Size: 43 Maintainer: Michael Meskes [EMAIL PROTECTED] Version: 1.01b-6 Depends: libc6 Description: Move/Copy/Append/Link multiple files mmv is a program to move/copy/append/link multiple files according to a set of wildcard patterns. This multiple action is performed safely, i.e. without any unexpected deletion of files due to collisions of target names with existing filenames or with other target names. -- Brian - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. - unknown Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: Yes, but it's better leaving site_perl empty. It can be used for manually (modules not in a .deb file) installing modules. Yes, I realize this. But most people using Perl manually install modules. That was the point of what I was saying. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNhz7NY4wrq++1Ls5AQEGkwP/fL8Qmkw8difM4+UxPDZFLyuKggeUsuvW 1zj+Lffqbn7V2pRehIAgl62QLKbyOvJt0kVe/aOfoymnlI0GQzhqrjRS66sm3Ajo mS644As0/MBqueUzHuEBDrVnhcaAowuGoWEJ4IAWeuF8pwLAHyetr7pKYvC3Twrw 2LmKZ4HTygM= =Y8PI -END PGP SIGNATURE-
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: What about also adding /usr/lib/perl5(/$arch)? at the end of @INC ? Is it possible ? In that way, recent packages that are installed in /usr/lib/perl5/debian are used first and only if no package is found in the standard path then perl will search for modules in /usr/lib/perl5. Yes, this should be possible. I haven't actually checked but it shouldn't be a problem. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNhz79I4wrq++1Ls5AQHJFwP/Z4lf/cj28nFyY5kseLjDtLJman/aZEHN q46AHFLMpuU3ce4mw9q+9nNZKDbwV6jLfXSftkZyiBY7brb1YW8+7vyRE5/u/cGu mSB+Q3UhbnnyLa/9dYJk9HY3U4+i8EUgLxKxln7Om8TKWvLwBaK3NSjjruQx4Vdy 3Bqwm1rhrPQ= =zHQR -END PGP SIGNATURE-
Taking over binutils package
After some discussion with Galen, I'm taking over the binutils package altogether. Hopefully, I can resolve some of the long-outstanding bugs (already think I can knock a few of them out of existance). Thanks... Chris [EMAIL PROTECTED]
Re: Squid2, how to handle incompatible upgrade
In article [EMAIL PROTECTED], Michael Alan Dorman [EMAIL PROTECTED] wrote: I did notice a reference on the mailing list (no specifics), on a way you could keep your existing cache hierarchy with squid2. Yes, by running the old and the new server at the same time and requesting all stored data from the old cache .. something that's pretty much impossible for our situation. Besides it only works if you have plenty of free space, and it would probably take hours if not days for a big cache . Hey it's just cached data .. Mike. -- Did I ever tell you about the illusion of free will? -- Sheriff Lucas Buck, ultimate BOFH.
