Re: your eyes?
Thank you for your response. Please don't reply to this message - it is an automated response and your reply will not be received. If you have a question for eBay Customer Support, please visit the following eBay Help page. This page will help you locate the answer to your question, or assist you in contacting us: http://pages.ebay.com/help/index.html If you would like to change your notification preferences, which determine what type of email you receive from eBay, please follow the steps below: 1. Click "My eBay" located at the top of all eBay pages. You may be asked to sign in. 2. Click the "eBay Preferences" link located under the "My Account" heading. 3. Click the "view/change" link to the right of "Notification Preferences." You may be asked to sign in once more. 4. On the "Change Your Notification Preferences" page, check the boxes to indicate the types of messages you'd like to receive from eBay. Then, uncheck the boxes to indicate the types of messages you don't want to receive from us. 5. Once you're done, be sure to click the "Save Changes" button at the top or bottom of the page. Again, thanks for writing eBay. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling libc4 on Debian unstable
On Thu, 13 Jan 2005, Christoph Berg wrote: > [0] [EMAIL PROTECTED]:~ $host archive.debian.org > archive.debian.org has address 208.185.25.38 > [0] [EMAIL PROTECTED]:~ $host 208.185.25.38 > 38.25.185.208.in-addr.arpa domain name pointer raff.debian.org. > > http://db.debian.org/machines.cgi?host=raff lists raff as "down"... See http://www.debian.org/distrib/archive with the additional caveat of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265175 Don Armstrong -- This space for rent. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
* Hamish Moffatt ([EMAIL PROTECTED]) [050114 00:45]: > On Thu, Jan 13, 2005 at 02:26:52PM +0100, Steinar H. Gunderson wrote: > > On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote: > > > Also of interest is that some 1300 packages would no longer need to > > > declare a Build-Depends: at all with those changes, and another 1200 > > > wouldn't need to declare a Build-Depends-Indep:. > > Not even versioned depends? > Not if build-essential included a suitable versioned depends, like > debhelper (>= 4). It already does that for gcc. That would still mean a versioned dependency on build-essential. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
Andreas Barth wrote: * Hamish Moffatt ([EMAIL PROTECTED]) [050114 00:45]: On Thu, Jan 13, 2005 at 02:26:52PM +0100, Steinar H. Gunderson wrote: On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote: Also of interest is that some 1300 packages would no longer need to declare a Build-Depends: at all with those changes, and another 1200 wouldn't need to declare a Build-Depends-Indep:. Not even versioned depends? Not if build-essential included a suitable versioned depends, like debhelper (>= 4). It already does that for gcc. That would still mean a versioned dependency on build-essential. Build dependencies on build-essential are always redundant. Build-Essential is, by definition, the set of packages you don't need to Build-Depend on. A dependency >= an old version is similarly redundant, and a dependency >= a future version is fairly useless -- it's not satisfiable after all. I guess a <= dependency might have a worthwhile meaning, though it'll certainly cause more trouble than it's worth. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#290421: ITP: zeiberbude -- A program for administering internet cafes.
Le vendredi 14 janvier 2005 à 01:55 +0100, Robert Millan a écrit : > Package: wnpp > Severity: wishlist > > * Package name: zeiberbude > Version : 2.0.4 > Upstream Author : Christian Toepp <[EMAIL PROTECTED]> > * URL : http://zeiberbude.sourceforge.net/ > * License : GPL > Description : A program for administering internet cafes. > > The package is made and ready for upload. You can find a copy at: > > http://people.debian.org/~rmh/zeiberbude/ > > Btw, I'm looking for a way to integrate zbdesk (the client) as a startup > script. zbdesk is a simple X client that locks the X server and can be > controlled remotely by zeiberbude. It relies on an already-running X, and > it doesn't start other X clients whatsoever (just locks and unlocks), so it > can't just be run from an init.d script. Any suggestion? >From a script in /etc/X11/Xsession.d, maybe? Try to create a new script there.
Lintian-induced changes in changelog, hardlinks? (Was: Re: Please consider bzip2 1.0.2-3 for sarge)
(moved to -devel, as this is offtopic for -release)
On Fri, Jan 14, 2005 at 08:48:38PM +1100, Anibal Monsalve Salazar wrote:
>* Fixed lintian warning "bzip2 libbz2-1.0 libbz2-dev binaries:
> postinst-should-not-set-usr-doc-link".
>* Fixed lintian warning "bzip2 binary: package-contains-hardlink
> usr/bin/{bunzip2,bzcat,bzcmp,bzegrep,bzfgrep,bzless}".
It is not interesting to know that you fixed lintian warnings, what _is_
interesting to know is what changes you made to the package, this is a
changelog after all. That lintian prompted you to do the changes is
irrelevant.
Does bzip2 now install multiple instances of all those binaries? Are
they all but one now symlinks to one particular version?
Also, eh, I'm not convinced lintian is correct here in complaining,
I'm a bit unsure. Lintian has warned for any hardlinks for a long time,
but is it really bad to have them? Having them across different
directories might cause problems when the user has those on different
filesystems, but in the same directory? Opinions?
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: Re: dselect and its help messages
Use 'dselect --expert' if you don't want to see the help messages at all. Thanks that was just what I was looking for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
Anthony Towns wrote: > Andreas Barth wrote: >> * Hamish Moffatt ([EMAIL PROTECTED]) [050114 00:45]: >>>Not if build-essential included a suitable versioned depends, like >>>debhelper (>= 4). It already does that for gcc. >> That would still mean a versioned dependency on build-essential. > [...] > A dependency >= an old version is > similarly redundant That's correct from the point of view of a buildd, or of a developer running a sid machine. But it is not correct for backporters: Imagine that packages are added to build-essential, or versioned dependencies in it are bumped to a higher version number. Then a package without Build-Dependencies, or with Build-Dependencies that can be fulfilled in stable, might still not build in a stable environment. The solution, of course, is to first backport build-essential. For the sake of users making their own backports, we should document this. And we should try hard to make sure that all packages in build essential can be backported without problems. I hope that debhelper won't ever need a versionened dependency on perl; this would make life really hard for backporters, with or without being it build-essential. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Is debhelper build-essential?
Anthony Towns wrote: Scott James Remnant wrote: The stats: 8,920 source packages in Debian unstable main. 8,254 declare a build-dependency on debhelper = 92% of packages build-depend on debhelper. Is that sufficient to declare it build-essential? Also of interest is that some 1300 packages would no longer need to declare a Build-Depends: at all with those changes, and another 1200 wouldn't need to declare a Build-Depends-Indep:. Oh, also: http://lintian.debian.org/reports/Tpackage-lacks-versioned-build-depends-on-debhelper.html Having the current debhelper be build-essential would fix the ~237 bugs lintian finds for build-deps on debhelper that should be versioned, but aren't. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks? (Was: Re: Please consider bzip2 1.0.2-3 for sarge)
On Fri, Jan 14, 2005 at 01:43:12PM +0100, Jeroen van Wolffelaar wrote:
>(moved to -devel, as this is offtopic for -release)
>
>On Fri, Jan 14, 2005 at 08:48:38PM +1100, Anibal Monsalve Salazar wrote:
>> * Fixed lintian warning "bzip2 libbz2-1.0 libbz2-dev binaries:
>> postinst-should-not-set-usr-doc-link".
>> * Fixed lintian warning "bzip2 binary: package-contains-hardlink
>> usr/bin/{bunzip2,bzcat,bzcmp,bzegrep,bzfgrep,bzless}".
>
>It is not interesting to know that you fixed lintian warnings, what _is_
>interesting to know is what changes you made to the package, this is a
>changelog after all. That lintian prompted you to do the changes is
>irrelevant.
Actual changes are trivial.
>Does bzip2 now install multiple instances of all those binaries?
No.
>Are they all but one now symlinks to one particular version?
-rwxr-xr-x root/root 26776 2005-01-09 22:24:40 ./usr/bin/bzip2
-rwxr-xr-x root/root 1713 2005-01-09 22:24:33 ./usr/bin/bzgrep
-rwxr-xr-x root/root 1297 2005-01-09 22:24:33 ./usr/bin/bzmore
-rwxr-xr-x root/root 2105 2005-01-09 22:24:33 ./usr/bin/bzdiff
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bunzip2 -> bzip2
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bzcat -> bzip2
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bzegrep -> bzgrep
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bzfgrep -> bzgrep
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bzless -> bzmore
lrwxr-xr-x root/root 0 2005-01-09 22:24:33 ./usr/bin/bzcmp -> bzdiff
>Also, eh, I'm not convinced lintian is correct here in complaining,
>I'm a bit unsure. Lintian has warned for any hardlinks for a long time,
>but is it really bad to have them? Having them across different
>directories might cause problems when the user has those on different
>filesystems, but in the same directory? Opinions?
>
>--Jeroen
>
>--
>Jeroen van Wolffelaar
>[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
>http://Jeroen.A-Eskwadraat.nl
Kind regards,
Anibal Monsalve Salazar
--
.''`. Debian GNU/Linux
: :' : Free Operating System
`. `' http://debian.org/
`- http://v7w.com/anibal
signature.asc
Description: Digital signature
Re: Lintian-induced changes in changelog, hardlinks? (Was: Re: Please consider bzip2 1.0.2-3 for sarge)
On Fri, 14 Jan 2005, Jeroen van Wolffelaar wrote: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems when the user has those on different > filesystems, but in the same directory? Opinions? I don't see what harm they can make if they are in the same directory. That's why I keep unzip and zipinfo hardlinked, for example. If upstream does that way, and there is not a real need to change it, I prefer to keep the upstream way of linking them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks? (Was: Re: Please consider bzip2 1.0.2-3 for sarge)
On Jan 14, Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems when the user has those on different > filesystems, but in the same directory? Opinions? I see no reason to complain. -- ciao, Marco signature.asc Description: Digital signature
Re: Proper way to remove a package from both sarge and sid
* Frederik Dannemare | Package in question is mozilla-firefox-locale-da which is to be replaced | by mozilla-firefox-locale-da-dk (not maintained by me) from source | package mozilla-firefox-locale-all. AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want a m-f-l-da-dk rather than just a m-f-l-da ? (To ask a different question and not answering the one you had. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
* Frank Küster | That's correct from the point of view of a buildd, or of a developer | running a sid machine. But it is not correct for backporters: Imagine | that packages are added to build-essential, or versioned dependencies in | it are bumped to a higher version number. Then a package without | Build-Dependencies, or with Build-Dependencies that can be fulfilled in | stable, might still not build in a stable environment. Which is why build-essential in sarge would be updated to depend on debhelper now, so packages in etch could get rid of debhelper build-deps. People backporting from unstable to oldstable are on their own, but I think that's ok and not a very interesting use-case. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290489: ITP: Mosaic -- Lightweight World Wide Web browser for the X Window System.
Package: wnpp Severity: wishlist * Package name: Mosaic Version : 3.0.0b1 Upstream Author : Riccardo Mottola <[EMAIL PROTECTED]> * URL : http://carduus.chanet.de/software/mosaic/index.html * License : (GPL + NCSA) Description : Lightweight World Wide Web browser for the X Window System. I want to develop a new updated version of Mosaic, basing on mMosaic sources. Both original Mosaic (XMosaic) from ncsa and mMosaic at ENST are no longer actively developed by the original authors and I am not affiliated with them. The name and version proposed by me are indicative only. Check the URL for more information and source code. The package is working as it is now, but I think help both to clarify the copyright situation and for further coding help in fixing bug, packaging and evolving the program. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: m68k Kernel: Linux 2.2.25 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
On Fri, 2005-01-14 at 17:21 +0100, Tollef Fog Heen wrote: > * Frank KÃster > > | That's correct from the point of view of a buildd, or of a developer > | running a sid machine. But it is not correct for backporters: Imagine > | that packages are added to build-essential, or versioned dependencies in > | it are bumped to a higher version number. Then a package without > | Build-Dependencies, or with Build-Dependencies that can be fulfilled in > | stable, might still not build in a stable environment. > > Which is why build-essential in sarge would be updated to depend on > debhelper now, so packages in etch could get rid of debhelper > build-deps. People backporting from unstable to oldstable are on > their own, but I think that's ok and not a very interesting use-case. > I don't believe build-essential has this +1 requirement ... if you're building a package from any distribution, you need to meet the build-essential requirements of *that* distribution; not the distribution you're currently running. In effect, if you're building unstable packages on stable, the first thing you should build is unstable's build-essential. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Proper way to remove a package from both sarge and sid
Scripsit Tollef Fog Heen <[EMAIL PROTECTED]> > * Frederik Dannemare > | Package in question is mozilla-firefox-locale-da which is to be replaced > | by mozilla-firefox-locale-da-dk (not maintained by me) from source > | package mozilla-firefox-locale-all. > AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want > a m-f-l-da-dk rather than just a m-f-l-da ? Hey, I speak Danish and I'm in Scotland. But seriously, I can see benefits of sticking to a common convention for naming localization packages; for example that might make it easier later to add some front end that would automatically add "all localization packages for the current locale where I have the underlying software installed". -- Henning Makholm"Ligger Öresund stadig i Middelfart?"
Re: Is debhelper build-essential?
On Fri, Jan 14, 2005 at 05:06:21PM +, Scott James Remnant wrote: > On Fri, 2005-01-14 at 17:21 +0100, Tollef Fog Heen wrote: > > * Frank Küster > > | That's correct from the point of view of a buildd, or of a developer > > | running a sid machine. But it is not correct for backporters: Imagine > > | that packages are added to build-essential, or versioned dependencies in > > | it are bumped to a higher version number. Then a package without > > | Build-Dependencies, or with Build-Dependencies that can be fulfilled in > > | stable, might still not build in a stable environment. > > Which is why build-essential in sarge would be updated to depend on > > debhelper now, so packages in etch could get rid of debhelper > > build-deps. People backporting from unstable to oldstable are on > > their own, but I think that's ok and not a very interesting use-case. > I don't believe build-essential has this +1 requirement ... if you're > building a package from any distribution, you need to meet the > build-essential requirements of *that* distribution; not the > distribution you're currently running. > In effect, if you're building unstable packages on stable, the first > thing you should build is unstable's build-essential. Well, this has interesting consequences if you're building a C++ package that also build-depends on random-c++-lib-dev, given that unstable's build-essential depends on g++ (>= 3:3.3) and no C++ libraries in stable could have been built against that ABI. I'm not sure there's a good answer for this, really; many of the transitions Debian makes are decidedly one-way in nature. -- Steve Langasek postmodern programmer
Re: Is debhelper build-essential?
Scott James Remnant <[EMAIL PROTECTED]> wrote: > In effect, if you're building unstable packages on stable, the first > thing you should build is unstable's build-essential. Are you kidding? Well, this is okay if we're talking only about added packages or higher versioned depends. But you can't mean "backport all packages in build-essential in the versions in unstable" - that would mean backporting libc6, and then it wouldn't be a backport any more. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: soname number in name of dev-package?
* Henning Makholm ([EMAIL PROTECTED]) wrote: > Scripsit Stephen Frost > > If the API changes in an incompatible way then *fix* the things which > > use the library to use the new API. Users aren't affected- the old, > > already compiled package, works fine against the lib it depends on, the > > new package will fail when trying to build against the new API > > Exactly. Ensuring that the new API is not available under the old one's > name will make sure that the new package does fail (because of a > missing build-dependency) rather than trying silently to build against > the new API as if it was the old, and possibly producing bad binaries. bad binaries which, one would hope, would be tested and found out to be bad. Of course, the other thing is that it'd be better for the depended-upon library maintainer to just notify people when the API changes in a silent-but-deadly way, or when the API changes in a non-backwards-compatible way at all. Also, the build-depend wouldn't be missing necessairly, aiui it requires a bit of manual intervention, and it'd still be available on people's machines. Stephen signature.asc Description: Digital signature
Bug#290536: ITP: acedb -- Object-oriented genome database system
Package: wnpp Severity: wishlist Package name: acedb Version : 4.9t Upstream Author : Ed Griffiths <[EMAIL PROTECTED]> URL : http://www.acedb.org License : GPL, portions are LGPL Description : Object-oriented genome database system ACeDB (originally standing for "A C. elegans Database") is an unusual database system originally designed for the sequencing of the genome of the nematode worm, C. elegans. It is still in production use for the annotation of genome sequence data. It can be used for other kinds of data too, especially if those data lend themselves to a tree-based representation. For example, ACeDB has been used for storing chip-test data. There are X Window System and command line interfaces to the database, and various supporting applications used for more detailed inspection of certain types of genomic data. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.8-1-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ultimate business of the year!
Hi, Just give me 5 minutes,and I will show you how to make an incredible income from home... Just send me an email with "Please Send Info" in the subject line. In the Body of the email, please include your Name,Country and I will send you all of the details immediately. You WILL thank me for this -- just like the others have! Sincerely, Imelda J. Manuel If this e-mail has reached you in error, or should you wish to be permanently removed from my mailing list, please reply with the subject "REMOVE ME" -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 1/12/2005 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
Frank Küster wrote: Scott James Remnant <[EMAIL PROTECTED]> wrote: In effect, if you're building unstable packages on stable, the first thing you should build is unstable's build-essential. Are you kidding? Well, this is okay if we're talking only about added packages or higher versioned depends. But you can't mean "backport all packages in build-essential in the versions in unstable" - that would mean backporting libc6, and then it wouldn't be a backport any more. No, he means backport the packages referenced by build-essential so you can satisfy its dependencies. So if build-essential depends: dephelper >= 3, and debhelper 4's in unstable, you should only need to make sure you've got a version >= 3. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
On Fri, 2005-01-14 at 18:44 +0100, Frank KÃster wrote: > Scott James Remnant <[EMAIL PROTECTED]> wrote: > > > In effect, if you're building unstable packages on stable, the first > > thing you should build is unstable's build-essential. > > Are you kidding? Well, this is okay if we're talking only about added > packages or higher versioned depends. But you can't mean "backport all > packages in build-essential in the versions in unstable" - that would > mean backporting libc6, and then it wouldn't be a backport any more. > This would only be true if build-essential declared a versioned dependency on libc6 higher than that satisfied in stable. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Lintian-induced changes in changelog, hardlinks? (Was: Re: Please consider bzip2 1.0.2-3 for sarge)
Marco d'Itri wrote: I see no reason to complain. *Woah*. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks?
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems when the user has those on different > filesystems, but in the same directory? Opinions? Some file systems don't support hardlinks, such as AFS, which causes a lot of trouble if you want to mount a Debian system via AFS. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks?
On Fri, Jan 14, 2005 at 08:33:00PM +0100, Falk Hueffner wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > > Also, eh, I'm not convinced lintian is correct here in complaining, > > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > > but is it really bad to have them? Having them across different > > directories might cause problems when the user has those on different > > filesystems, but in the same directory? Opinions? > > Some file systems don't support hardlinks, such as AFS, which causes > a lot of trouble if you want to mount a Debian system via AFS. %mount ... AFS on /afs type afs (rw) %pwd /afs/umich.edu/user/b/f/bfields %touch TMP %ln TMP TMP2 %ls -li TMP* 1788936372 -rw-r--r--2 bfields user0 Jan 14 14:54 TMP 1788936372 -rw-r--r--2 bfields user0 Jan 14 14:54 TMP2 It's just cross-directory hardlinks that AFS doesn't like: %mkdir TMP3 %ln TMP TMP3/FOO ln: creating hard link `TMP3/FOO' to `TMP': Invalid cross-device link --Bruce Fields -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Remember to make sure the Packages.gz files appear on the mirrors _after_ the packages they refer to are in place. Bug #217957. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debhelper build-essential?
On Fri, Jan 14, 2005 at 09:46:45AM -0800, Steve Langasek wrote: > On Fri, Jan 14, 2005 at 05:06:21PM +, Scott James Remnant wrote: > > On Fri, 2005-01-14 at 17:21 +0100, Tollef Fog Heen wrote: > > > > * Frank Küster > > > > | That's correct from the point of view of a buildd, or of a developer > > > | running a sid machine. But it is not correct for backporters: Imagine > > > | that packages are added to build-essential, or versioned dependencies in > > > | it are bumped to a higher version number. Then a package without > > > | Build-Dependencies, or with Build-Dependencies that can be fulfilled in > > > | stable, might still not build in a stable environment. > > > > Which is why build-essential in sarge would be updated to depend on > > > debhelper now, so packages in etch could get rid of debhelper > > > build-deps. People backporting from unstable to oldstable are on > > > their own, but I think that's ok and not a very interesting use-case. > > > I don't believe build-essential has this +1 requirement ... if you're > > building a package from any distribution, you need to meet the > > build-essential requirements of *that* distribution; not the > > distribution you're currently running. > > > In effect, if you're building unstable packages on stable, the first > > thing you should build is unstable's build-essential. > > Well, this has interesting consequences if you're building a C++ package > that also build-depends on random-c++-lib-dev, given that unstable's > build-essential depends on g++ (>= 3:3.3) This is a fairly good example of why. Lots of stuff in unstable just won't build correctly with the versions of g++ in woody. > and no C++ libraries in stable > could have been built against that ABI. Yeah, that part pretty much sucks. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Proper way to remove a package from both sarge and sid
On Friday 14 January 2005 17:08, Tollef Fog Heen wrote: > * Frederik Dannemare > > | Package in question is mozilla-firefox-locale-da which is to be > | replaced by mozilla-firefox-locale-da-dk (not maintained by me) > | from source package mozilla-firefox-locale-all. > > AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want > a m-f-l-da-dk rather than just a m-f-l-da ? [ ... ] Well, I don't know. You'd have to ask the maintainer of ..-da-dk. I only did the ..-dk package before mozilla-firefox-locale-all arrived. -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks?
On Fri, Jan 14, 2005 at 01:43:12PM +0100, Jeroen van Wolffelaar wrote: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems when the user has those on different > filesystems, but in the same directory? Opinions? I don't want to speak for past lintian maintainers but I seem to remember that the lintian philosophy that support this check is that hard-links in packages should be exceptional and deserve an lintian-override. (The same hold for e.g. suid/sgid binary.) My personnal opinion is that hard-links inside /usr/bin are OK. Thanks for maintaining lintian by the way! Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. PS: speaking of lintian, I feel the new check description-synopsis-starts-with-a-capital-letter has too many false positive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks?
On Sat, Jan 15, 2005 at 12:15:11AM +0100, Bill Allombert wrote: > I don't want to speak for past lintian maintainers but I seem to remember > that the lintian philosophy that support this check is that hard-links > in packages should be exceptional and deserve an lintian-override. > (The same hold for e.g. suid/sgid binary.) > > My personnal opinion is that hard-links inside /usr/bin are OK. > > Thanks for maintaining lintian by the way! Thank you all for your replies. FYI, lintian trunk currently warns for hardlinks across directories (AFS is mentioned in the rationale) and in /etc only. The latter is in policy (breaks conffiles, breaks with some editors). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290595: ITP: xwine -- a graphical user interface for the WINE emulator
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: xwine Version : 1.0 Upstream Author : Philippe Bousquet <[EMAIL PROTECTED]> * URL : http://darken33.free.fr * License : GPL Description : a graphical user interface for the WINE emulator XWine is a graphical user interface for the WINE emulator. It provides an interface for configuring and running MS-Windows applications (MS-DOS, Windows 3.x, or Win32). - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-ac1-nc6k Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB6IkrcCqFswWbUPcRAgfHAJ9pO+1bqF2E15Ona/UUYB+RwfXSVQCcDOWh f3GdfytaKAsIP9A2oMccmOM= =tM6G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to ensure packages generated from -source are installable?
William Ballard <[EMAIL PROTECTED]> writes: > On Mon, Jan 03, 2005 at 11:33:21AM +0100, Thomas Hood wrote: >> Right. Do you regard this as a problem? > > It would be a lot smarter to check if the install would succeed > before unpacking it. If you were replacing a previous alsa-modules > package, the old one will be uninstalled and non-functional (please > correct me me if I'm wrong) and you won't have any sound until you get > around to fixing it. If you were replacing a previous > ndiswrapper-modules, now your network card is hosed and you *can't* use > apt -f to fix the problem unless you connect to the network the other > way. Yes, it would be smarter for dpkg to know that it will fail. But you can always do dpkg --unpack foobar.deb to get to the same situation. dpkg -i foobar.deb is just simpler to type and just maybe it works. > Transactions should be atomic, consistent, isolated, and durable. This > fails the "atomic" and "isolated" tests. > > Don't sweat it, I can very easily write my own wrapper around dpkg -i > that first dumps the depends and refuses to install if they aren't met. Don't forget Pre-Depends, Depends, Conflicts, Replaces, the actual files in each deb (do they overlap?), Provides, cycles and combinations of those, different orders of when packages get unpacked (relevant to file overlaps) or configured. All this is a nice application of graph theory and pretty much what apt does already. So your wraper is quite a waste of time. What you should do is port the "apt-get -i foobar.deb" support from the rpm capable apt back to debian. With a relatively simple and small patch you gain all the already achieved work of apt, your wish to install local debs with dependency checking and you make a lot of people happy on top of it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ignoring the truth or Hiding problems?
Joel Aelwyn <[EMAIL PROTECTED]> writes: > On Wed, Jan 05, 2005 at 10:18:21AM -, Adam D. Barratt wrote: >> On Wednesday, January 05, 2005 10:05 AM, Ingo Juergensmann >> <[EMAIL PROTECTED]> wrote: >> >> [...] >> > When Joerg Jaspert is already doing the dirty daily work, why does >> > James still needs in place then? (Except he just stays in that >> > position for a transitional period until Joerg is taking over that >> > task and job completely. I would recommend that transitional period >> > for other positions as well.) >> >> aiui, because James - or presumably some other member of -admin - needs to >> create the accounts once an nm has been approved (newsamosa, aka db.d.o is >> restricted). >> >> The most time-consuming part of DAM work is approving applicatants, which is >> what Joerg is now doing. afaics, once an applicant is approved, accounts are >> being created relatively quickly; so far it appears to be working well. > > Speaking as someone who has railed (more than once) against the > six-to-twelve-month waiting period between "AM approval" and "DAM review > complete" (as noted, once DAM approval was had, accounts happened > without perceptible delay), all I will say is the following: > > 1) Time will tell if this helps enough > > 2) So far, it looks promising > > 3) So long as James is considered valuble and useful by the people doing >the work (presumably including himself), *and the work is getting >done*, I don't much care how many positions he holds. > > It's the whole "getting done" thing that seemed to be suffering from his > state as a multiple-path single point of failure, and "small teams" is, in > my opinion, a vastly better answer than "multiple single-path single points > of failure", even if the latter is still better than the situation as it > appeared to be in the past. Very well put. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#60810: contents.gz package
Justin Pryzby <[EMAIL PROTECTED]> writes: > Could we have a package which provides /usr/share/.../Contents.gz? > Not sure that share/ is the right place. And as Matt said, versioning > is a potential problem. But lintian (and others: apt-file) could > depend on this package (say, debian-dist-contents). > > Justin First of all how do you plan to update the testing package every day? They should reflect the testing Contents, right? You also have to release a new version every day. That is an 8MB deb per arch and a source containing all 13 archs. That is 208MB updates per day and suite. ~400MB for testing and unstable every day. Ok, you can probably use the Contents-i386.gz and diffs for other archs bringing it down to maybe 200MB a day. Then use a different compression and maybe get it to 100Mb. Still way way to much data on a daily basis. I think the only sensible and simple thing to do is to provide a zsync file for the Contents files (zsync can 'look into' gz to rsync just the changes). Then every user can use a cron job to zsync the file to his system on a daily, weekly, monthly, whatever basis. zsync uses the http protocol so any http mirror carrying the Contents files will do as source. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build problem on mips{,el}
Steve Langasek <[EMAIL PROTECTED]> writes: > On Wed, Jan 05, 2005 at 11:40:14AM +0100, Martin Waitz wrote: >> my package tspc could not be build on mips and I don't know why: > >> /usr/bin/ld: cannot open output file ../../bin/tspc: Permission denied > >> The package builds correctly on all other architectures. >> Any ideas? > > mips* do not use fakeroot as the root command when building, because > fakeroot does not work on these architectures. Instead they must use sudo, > which means that directories or files created in the clean target will not > be writable by the build target. > > -- > Steve Langasek > postmodern programmer The clean target should not need to be run as root and I think that is a bug in sbuild and a handfull of sources. Policy only says clean might need to be run as root if the source has been build as root previously, which is not the case on buildds. sbuild should not run clean as (fake)root if it just unpacked a clean source package. There is also a bug in patch (violating POSIX) to replace existing files with files owned by root.root but preserving the access rights of the old file. Patch should truncate and overwrite the old file preserving both ownership and permissions instead of replacing it with a new file. (I have a patch for preserving the owner but the author wanted a cleaner patch which is on my todo.) Both together means that if you unpatch in clean and your files are read-only then you can't even patch the files anymore in configure. And other similar effects. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
William Ballard <[EMAIL PROTECTED]> writes: > On Fri, Jan 07, 2005 at 12:30:10AM +0100, Jose Carlos Garcia Sogo wrote: >> including insulting you when you type stupid commands. But you don't >> have the right to insult people because you are pissed for not being >> clever enough of looking for dependencies before installing a package by >> hand using dpkg, which is a low level aimed for admins util, and for not >> keeping a backup of old package. > > There is no way to use -source packages without using dpkg. Of cause there is, about a million of them. Check out man dpkg-scanpackages man apt-ftparchive dak on cvs.debian.org mirrorer project on alioth apt-cache show mini-dinstall debpool from experimental the debian-amd64 archive tools sourcerer-kernel-builder for some starting points. The way to go is not to use dpkg -i blindly but to put your build debs somwhere so you can use a proper frontent like apt-get or aptitude. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Andres Salomon <[EMAIL PROTECTED]> writes: > On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote: > >> On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: >>> Apparently the dickhead maintainer of ndiswrapper-source has just gone >>> into his shell and refuses to discuss this problem. >> >> Btw, could anyone explain why ndiswrapper is in main? It's only use >> is to run propritary windows drivers inside the linux kernel, so it's >> a clear fit for contrib. > > I believe we had this discussion on IRC; basically, there *are* free > (as in speech) ndis drivers out there. Whether they're able to be built > and packaged on a debian system; I don't know. Didn't we also say on irc that as long as no free ndis driver is in main it is the same as having no free driver? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Sebastian Ley <[EMAIL PROTECTED]> writes: > * Adam Heath wrote: > >> It *may* require a versioned depends on a newer version, but that's just a >> normal bug. > > ...and no reason to introduce this dependency in the -source package. And a Depends in the -source package would change nothing: 1. install -source 2. build -module 3. remove source + depends 4. install -module blindly with dpkg -i same problem or build the -module on system A and install on system B. I'm not going to build kernel and -module packages on my P200 if I can just as well, but far faster, build them on my 2Ghz amd64. > Btw: Leaving old packages build from -source packages around would quite well > do the trick. But I suppose W.B. wants to call more people assholes before > invoking brain functions... > > *sigh* > > Sebastian MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Op ma, 10-01-2005 te 22:43 +0200, schreef George Danchev: >> On Monday 10 January 2005 22:25, Wouter Verhelst wrote: >> > Op ma, 10-01-2005 te 15:12 -0500, schreef William Ballard: >> > > On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: >> > > > dpkg -I on the resulting package and looking at the depends? >> > > >> > > But you don't expect to do that for other packages. >> > >> > You can also just run 'apt-get -f install' once the dependency breakage >> > occurs. That's what it's for. >> >> This should be the last one should try, e.g. break the things with dpkg -i >> and >> then try to fix them with apt-get install -f, what if you have just broke >> apt ... yes I know one can handle that, but why spending extra time in a-la >> rpm hell [tm] situations, which could be avoided easily... The right way >> [tm] >> is to place the resulting deb in a local apt repo and install & whatever >> from >> there exploring the advantages of apt. > > That's a possibility, but it's hardly 'the right way', IMO. Setting up a > local package repository is a bit overkill IMHO. > > If installing a package with dpkg -i breaks apt, that means there's > something fishy going on, and would warrant a bug report IMO, with its > severity being at least 'important'. Apart from that... Unless you dpkg -i apt or one of its depends. But they are so few that you should know what you get yourself into if you mess with any of them. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290603: ITP: rnc-mode -- editing mode for compact Relax NG syntax
Package: wnpp Severity: wishlist * Package name: rnc-mode Version : 1.0b3 Upstream Author : David Rosenborg <[EMAIL PROTECTED]> * URL : http://www.pantor.com/download.html * License : BSD Description : Emacs editing mode for RELAX NG Compact syntax This package provides a major mode in Emacs for editing RELAX NG Compact syntax, a schema language for XML. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get should be able to install packages "directly"
Roberto Sanchez <[EMAIL PROTECTED]> writes: > Greg Folkert wrote: >> On Thu, 2005-01-06 at 23:54 +0100, Blade wrote: >> >>>That's the normal way. This way allows me to install dozens of >>>module-source packages and build module packages from them for Debian >>>kernels, without having to install a half GiB of additional software >>>that I really do not need. >>> >>>What we really need is the apt-get extension mentioned here a while ago >>>that would allow you to run apt-get on local packages (without >>>generating a local repository as described by Michel here). >> >> >> Exceptional, supercalifragilisticexpealidocious, Uber ultra, massively, >> extra special, like duh already SECONDED! > > What about having a pseudo-repository set up whenever a system is > installed. It can be placed in /var/repository and addressd in > sources.list as file:///var/repository ./ That is what sourcerer-archive is supposed to do (package under developement). I recently discovered mirrorer (alioth project) and sourcerer-archive is now a frontent for it to handle the configuration and some extra maintainance scripts and might get merged into mirrorer at some point. I hope mirrorer gets released soon. > You drop a .deb file in there, run apt-update-repository to regenerate > the Packages file, and then the package is now apt-getable. > > -Roberto Sanchez Even more complex setup: sourcerer-watcher [1] installs hooks for apt-get that watch out for new packages getting installed, e.g. zaptel-source. Whenever apt-get (dist-)upgrade installs zaptel-source a rebuild of the kernel modules gets triggered in the background (e.g. in cron.daily). The resulting deb(s) get installed in the local archive and the next apt-get update and apt-get (dist-)upgarde will update the module packages. So for any package sourcerer-watcher knows already or that you add to the 'watch for' list a simple "apt-get install foobar" will give you the respective build debs and provide automatic updates transparently a day later each. MfG Goswin [1] sourcerer-watcher is a generalization of sourcerer-kernel-builder. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT Repository HOWTO
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Hello > > Instead of doing all this by hand I can recommend my own package > debarchiver. The latest versions of it do this pretty good in > an automatic way. > > Just wanted to let you know. > > Regards, > Hi, I know I tried debarchiver for the amd64 archive and found it wanting in some way. Could you summarise the strong and weak points of it for the FAQ? Same goes for the other suggestions made here like the DAK. The DAK is hellishly complicated to setup compared to mini-dinstall for example. But using mini-dinstall for something like 15K debs is insane. All the tools have pros and cons and a comparison would be nice. Personally my favourite currently is mirrorer because it is very simple to setup, has basicaly no depends (like no db server needed) and copes well even with 15K debs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Cameron Hutchison <[EMAIL PROTECTED]> writes: > Once upon a time Steve Langasek said... >> >> There is nothing in the -source package that actually requires (or should >> recommend) the -utils package. A much better fix here is for people to get >> over the fact that dpkg isn't apt. > > Apologies for continuing this but having read through the thread I still > dont think I understand the issue with dpkg in this situation. > > Is the following scenario the issue here with dpkg? : > > foo-modules_1.0 is installed. It is standalone and does not require any > other packages to be installed. > > foo-modules_2.0 is built from foo-source. > > foo-modules_2.0 depends on foo-utils. > > User runs "dpkg -i foo-modules_2.0_arch.deb" > > dpkg first removes foo-modules_1.0 > dpkg then check dependencies of foo-modules_2.0 > dpkg complains that foo-utils is not installed and aborts the > installation of foo-modules_2.0 dpkg unpacks foo-modules_2.0 overwriting foo-modules_1.0 in the process. dpkg fails to configure foo-modules_2.0 > foo-modules is now in a broken state unable to be used. > > Networking depends on foo-modules so it is not possible to install > foo-utils unless it is locally available. Unless you reboot networking will still work since the old module will still be loaded. Of cause thats of little help if you have a power failure just then. :) > Is this the scenario being argued over? If so, why does dpkg not first > check the dependencies of foo-modules_2.0 before removing > foo-modules_1.0? If not, could someone explain to me (or point me to a > resource) what the issue is? That is pretty much the issue. dpkg -i does an dpkg --unpack (which succeeds) and then dpkg --configure (which fails). It could check beforehand if the --configure can possibly succeed or not but IT DOESN'T. The most prominent opinion about this is LIVE WITH IT. dpkg is a low-level tool and if you use it you are responsible to use it right. If you can't or don't want to use a higher level tool like apt or module-assistant. > Thanks MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Scott James Remnant <[EMAIL PROTECTED]> writes: > On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote: > >> On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote: >> > dpkg doesn't remove foo-modules_1.0 at all. >> > Note that I said "remove", the old files are replaced during the unpack > phase rather than removed. > > It's generally assumed that if you're unpacking a package, you actually > want it installed. > > > 1) No banana or icecream: > > descent tmp# dpkg -s banana > Package: banana > Status: purge ok not-installed > Architecture: all > > descent tmp# dpkg -s icecream > Package: icecream > Status: purge ok not-installed > Architecture: all > > > 2) Install banana 1.0: > > descent tmp# dpkg -i banana_1.0.all.deb > Selecting previously deselected package banana. > (Reading database ... 140490 files and directories currently installed.) > Unpacking banana (from banana_1.0.all.deb) ... > Setting up banana (1.0) ... > > descent tmp# cat /banana > This is banana 1.0. > > descent tmp# dpkg -s banana > Package: banana > Status: install ok installed > Maintainer: Scott James Remnant <[EMAIL PROTECTED]> > Architecture: all > Version: 1.0 > Description: yellow fruit > > > 3) Upgrade to banana 2.0 (which needs icecream): > > descent tmp# dpkg -i banana_2.0.all.deb > (Reading database ... 140492 files and directories currently installed.) > Preparing to replace banana 1.0 (using banana_2.0.all.deb) ... > Unpacking replacement banana ... > dpkg: dependency problems prevent configuration of banana: >banana depends on icecream; however: > Package icecream is not installed. > dpkg: error processing banana (--install): >dependency problems - leaving unconfigured > Errors were encountered while processing: >banana > > >As you point out, banana 2.0 has been unpacked: > > descent tmp# cat /banana > This is banana 2.0. > >And is left in an "unpacked" state, rather than installed: > > descent tmp# dpkg -s banana > Package: banana > Status: install ok unpacked > Maintainer: Scott James Remnant <[EMAIL PROTECTED]> > Architecture: all > Version: 2.0 > Config-Version: 1.0 > Depends: icecream > Description: yellow fruit > > > 4) We need icecream, so install it: > > descent tmp# dpkg -i icecream_1.0.all.deb > Selecting previously deselected package icecream. > (Reading database ... 140491 files and directories currently installed.) > Unpacking icecream (from icecream_1.0.all.deb) ... > Setting up icecream (1.0) ... > > > 5) And complete configuration of banana: > > descent tmp# dpkg --configure -a > Setting up banana (2.0) ... > > descent tmp# dpkg -s banana > Package: banana > Status: install ok installed > Maintainer: Scott James Remnant <[EMAIL PROTECTED]> > Architecture: all > Version: 2.0 > Depends: icecream > Description: yellow fruit > > Scott To make it clearer say banana 1.0 also contains /banana-without-icecream while banana 2.0 contains /banana-with-icecream. At what point would /banana-without-icecream be removed by dpkg? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > What would be the impact on (c)debootstrap of changing the operation > of dpkg? I haven't looked at the exact sequence in a while, but IIRC > those partially-installed states have valid uses in a debootstrap run. > For instance, an unconfigured package may not be ready for normal > use, but may get some files into the right places so that another > package installation can complete, and then another run of dpkg can > fix the first package. Afaik neither debootstrap, cdebootstrap nor rootstrap use dpkg -i to partially install packages. They explicitly use --unpack and --configure and use --force-* options to exactly say what they need. If at any point dpkg returns an error (as dpkg -i would for partial installs) then (c)debootstrap/rootstrap will stop. > I think I'm of the "it's a low-level tool, you can shoot yourself in > the foot if you insist on it" school. That's what the --force-* flags > are there for -- knowingly, carefully, shooting yourself in the foot > because that's where the anaconda has started to eat you. However, > there might be a case for defaulting to peeking inside the new package > to check dependencies before unpacking. One could then add a new > --force-unpack flag to get the current behavior in scenarios like > debootstrap. > > Cheers, > - Michael dpkg -i checking configurability before unpacking should not impact the previously mentioned tools at all afaik. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#290396: ITP: lopster2 -- A Napster gtk2 client
On Thu, Jan 13, 2005 at 11:25:39PM +0100, Riccardo Setti wrote: > Package: wnpp > Severity: wishlist > > * Package name: lopster2 > Version : cvs pre3.9 > Upstream Author : Sgopsgop at users.sourceforge.net Hi, Why don't you let the maintainer of the existing 'lopster' package maintain lopster2? Have you discussed it with him? I have been the victim of new-version-package-hijacking in the past and I find it quite rude. However it's OK if you have discussed it with the current maintainer and have their permission. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Scott James Remnant <[EMAIL PROTECTED]> writes: > On Tue, 2005-01-11 at 21:57 -0800, Michael K. Edwards wrote: > >> What would be the impact on (c)debootstrap of changing the operation >> of dpkg? >> > Forget the impact on debootstrap, the impact on APT and dselect is > pretty huge. dpkg is designed to be able to unpack packages while their > dependencies are not yet fulfilled. > > What's interesting is nobody has jumped in on this thread to point out > that dpkg *has* a dependency field for forcing checking of dependencies > before the package is unpacked. > > Pre-Depends > > What William Ballard, Cameron Hutchinson and Eduard Bloch are asking for > is to remove the difference between Depends and Pre-Depends and make all > Depends behave like Pre-Depends. But only for the "dpkg -i" operation. And they are not asking to remove the difference but to move the depends check to be simulated before the unpacking is done and prevent the unpacking if the later configure will fail. They ask for the following: - take current state - check if unpacking will work (pre-depends check) - simulate unpacking (update internal states but don't unpack or change status file) - check if configure would work (depends/conflicts check) - unpack - maybe recheck if configure will work in case the simulation is unreliable - configure Would that be so hard to do? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Scott James Remnant <[EMAIL PROTECTED]> writes: > On Wed, 2005-01-12 at 18:28 +, Henning Makholm wrote: > >> Scripsit Scott James Remnant <[EMAIL PROTECTED]> >> >> > What's interesting is nobody has jumped in on this thread to point out >> > that dpkg *has* a dependency field for forcing checking of dependencies >> > before the package is unpacked. >> >Pre-Depends >> >> As far as I read the thread, this is not exactly what is being asked. >> >> My immediate thought, too, is that it would be sensible for dpkg to >> start by checking whether all dependencies of the packages it is being >> asked to install *will* be available after everything is finished, >> > dpkg is designed so you don't need to do this. > >> I can certainly accept and anticipate the objection that "that would >> be difficult to implement, and nobody has cared to", but I still don't >> see why such a behavior would be *wrong*, per se. >> > It's breaking elegance to fix something I'm not convinced is a problem. > All of the examples given so far are bogus, there simply isn't a > situation I can see where upgrading a package would prevent you from > being able to get its dependencies and install them afterwards. Lets construct a case: foo 1.0 does *not* depend bar foo 2.0 depends bar bar pre-depends foo and update it: foo 1.0 is installed dpkg -i foo_2.0.deb foo_2.0 is unpacked but unconfigurable bar is uninstallable Ok, it is a constructed case and bar is uninstallable unless you are updateing but there are more complex cases to the same effect. > And a far better solution to the "a package on disk needs dependencies" > solution is for a command-line tool that can grab the dependencies a > package needs, not just bitch about them not existing. Both can be done. > Scott > -- > Have you ever, ever felt like this? > Had strange things happen? Are you going round the twist? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
"Bernhard R. Link" <[EMAIL PROTECTED]> writes: > * Daniel Burrows <[EMAIL PROTECTED]> [050112 22:08]: >> Well, you're also leaving the package in a broken and unconfigured state. >> Doing this in order to save the user a little typing later (adding the >> original package to the second --install line) seems to me like a hack to >> make some use cases slightly more convenient, not elegance. > > The elegance is that dpkg is robust in that it can always install > everything and can get cleanly from one state to another. However broken > the packages are you never end in a sitation you cannot fix again. > The additional checks suggested here add some additional term of > "correctness", that dpkg has to check on the resulting state. Without > some full formalisation or anything else to make sure it cannot get out > of this state, or can get back to that state easily, it is only a hack. > It would also break serialisation, as one would need to give a list of > packages to install to dpkg all at once or in the correct serialisation, > and no longer (with exception of configure cycles) beeing able to give > them in whatever sequence as one is pleased to do. All that is asked is for dpkg -i to do a simulation of unpack, then check the configure checks and report errors before doing the actual unpack and configure. That doesn't change the serialisation or argument reordering dpkg might do internally. > Hochachtungsvoll, > Bernhard R. Link MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
