Re: Depending on both runtime and dev packages?
Kevin B. McCarty wrote:
>
> So in Davide's case, foo-bin is going to have a dependency on both the
> runtime lib in libfoo0 (from ${shlibs:Depends}) as well as on the
> development package libfoo-dev (which the packager includes in the
> Depends list manually). You could argue that the dependency on libfoo0
> is redundant; but it would be hard to leave it out since it gets added
> through the shlibs mechanism.
I don't think it should be considered redundant. I'd rather have package
always depend on everything they use directly rather than rely on some
other package's dependency (even libfoo-dev -> libfoo0)...
Cheers,
Nicolas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uscan, get-orig-source, and making upstream tarball DFSG-free
On Thu, Sep 15, 2005 at 09:56:13AM +1000, Ben Finney wrote: > On 15-Sep-2005, Nicolas Boullis wrote: > > For a package of mine, I need to remove a non-free file from every > > upstream tarball. Doing it by hand is certainly suboptimal, and I > > might forget to do it. > > > > I thought about using uscan, with a hand-made script instead of the > > common uupdate. But that script would be local to the package, and > > kept in the diff.gz part of the source package. Hence, it is not > > executable in a freshly-unpacked source package, which means I > > probably can't use this solution. Am I missing something? Is there a > > workaround? > > ISTM that the right place to be making automated changes to the > upstream source that you want reflected in the Debian source is at the > point when you do that conversion. What process are you currently > using to convert a new upstream source into a Debian source tree? That > would be the point for such an automated file-removal step. I'm currently using uscan with a simple debian/watch file that calls uupdate to do the "conversion". That's why I thought about using a han-made script instead of using uupdate; it seems to work quite fine, except that I have to change its permission by hand... Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uscan, get-orig-source, and making upstream tarball DFSG-free
Hi, [ Hmmm, looks like my mailer ate my message... :-( ] For a package of mine, I need to remove a non-free file from every upstream tarball. Doing it by hand is certainly suboptimal, and I might forget to do it. I thought about using uscan, with a hand-made script instead of the common uupdate. But that script would be local to the package, and kept in the diff.gz part of the source package. Hence, it is not executable in a freshly-unpacked source package, which means I probably can't use this solution. Am I missing something? Is there a workaround? I also thought about using the get-orig-source target of debian/rules to get the newest upstream tarball and cut it down. But as far as I can see, this target looks quite redundant with debian/watch. Are they supposed to interoperate in some way? Is there anyone who actually uses this target? Thanks in advance, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uscan, get-orig-source, and making upstream tarball DFSG-free
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Thu, Jul 28, 2005 at 08:17:16AM +0200, Thomas Viehmann wrote: > Hi. > > Nicolas Boullis wrote: > > I'd rather set no recommendation at all, or conflict with old > > udev... > The former, by the way, makes perfect sense for something that isn't > absolutely required and will be a complete non-issue when the package is > released (even in a few weeks time) along with the rest of Debian > (because that will likely contain a newer udev). That's what I'll do, but I'd be happy to se a batter solution emerge, as such a feature might be useful in other situations... Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Thu, Jul 28, 2005 at 07:12:16AM +1000, skaller wrote: > > Two methods, one is not tenable: > > (a) X conflicts with no-X implicitly > (b) When Y depends on no-X, if Y is installed, no-X is > synthesised and installed too if it doesn't exist, > (and conflicting with X to prevent X being installed). > > The dummy installation is mandatory because here > is the alternative, which is not tenable: > > When installing X, scan all installed packages > to see if there is a dependency on no-X, if so > there is a conflict. > > This is untenable because it requires scanning all > packages in your local database, whereas installation > of a package should only require looking up the > listed dependencies. > > The reason a logical 'X isn't installed' does not > work is that you could install Y, which depends > on no X, and then just install X. Now Y is silently > broken by a package that knows nothing about Y. As far as I know, such things already happen with conflicts: let foo conflict with bar. If you install foo first, everything is fine. Later, if you install bar, foo is broken by bar, while bar knows nothing about foo... Where's the difference? Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Wed, Jul 27, 2005 at 11:22:44AM -0600, Bruce Sass wrote: > On Wed, 27 Jul 2005, Frank Küster wrote: > > Nicolas Boullis <[EMAIL PROTECTED]> wrote: > > > > > Oh, and I just thought there could be a workaround. I could make a new > > > no-udev empty package that conflicts with udev, and then write > > > "Recommends: no-udev | udev (>= 0.060-1)". > > > > An elegant solution ;-) > > > > > I guess this would behave as expected, but I think that having one more > > > package only for this would be quite insane! > > > > Especially because others would pick up the idea... > > Can dpkg/apt/etc. be tweaked to automatically Provides: no-* ? If they were to be tweaked, I'd rather like them to understand something like "Recommends: !udev || udeb (>= 0.060-1)" rather than give a special meaning to a prefix that would be perfectly legal in a package name. Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Wed, Jul 27, 2005 at 09:57:35AM +0200, Thomas Viehmann wrote: > Hi. > > Nicolas Boullis wrote: > > If there's currently no way to set up such things, it might be worth > > suggesting to add such a feature to next-generation .deb format. Don't > > you think so? > To be honest, no. > If you do a Recommends: udev (>= ...), most people will just install the > recommended udev and be fine. People who have reason to not like to use > udev will just not. > Most people won't want to make a decision, so it's of no use giving them > the choice. Those who want to choose will read the README.Debian to see > what's going on. For the others: Do venture a single recommondation. I have to disagree. For people who don't want to make a choice, tools like aptitude in its default configuration will install recommended packages. So it would install udev, even for someone who uses a 2.4 kernel... I'd rather set no recommendation at all, or conflict with old udev... > > Oh, and I just thought there could be a workaround. I could make a new > > no-udev empty package that conflicts with udev, and then write > > "Recommends: no-udev | udev (>= 0.060-1)". > > I guess this would behave as expected, but I think that having one more > > package only for this would be quite insane! > Let's not. Don't worry, I won't. Let's not bloat the packages file once again! ;-) Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Wed, Jul 27, 2005 at 09:46:42AM +1000, Ben Finney wrote: > > Yes, I think I understand what you want. > > You want something that is a non-imperative equivalent to > > "Conflicts: udev (<< 0.060-1)" > > i.e. one that wouldn't force the result, but would recommend it. That's it. > > And conflicting with udev (<< 0.060-1) isn't satisfactory either > > In that case, I think you'll have to compromise on one of the two > options you don't like, since I'm pretty sure you can't > "anti-recommends" something with current deb format. If there's currently no way to set up such things, it might be worth suggesting to add such a feature to next-generation .deb format. Don't you think so? Oh, and I just thought there could be a workaround. I could make a new no-udev empty package that conflicts with udev, and then write "Recommends: no-udev | udev (>= 0.060-1)". I guess this would behave as expected, but I think that having one more package only for this would be quite insane! Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
Hi, On Tue, Jul 26, 2005 at 11:03:51AM +1000, Ben Finney wrote: > On 26-Jul-2005, Nicolas Boullis wrote: > > I'd like my em8300 package's dependencies to say something like "If you > > use udev, I'd recommend you use at least 0.060-1." > > [...] > > I would translate it to "I'd recommend you have either no udev > > installed, or at least version 0.060-1.". > > [...] > > "Recommends: udev (>= 0.060-1)". > > How does this not express what you want to say? It recommends a > minimum version of the package, and allows for no installation of the > package. While it allows for no installation of udev, I'd understand it as "for most users, have no udev is equivalent to having an old one, and both are worse than having a new udev", while I want to mean "for most users, having no udev is equivalent to having a new one, and both are better than having an old udev". I pseudo-mathematic verbiage, I want udev (>= 0.060-1) = no udev > udev (<< 0.060-1) while the recommends line means udev (>= 0.060-1) > no udev = udev (<< 0.060-1) Am I clear enough about the difference? > > But none of these 2 solution satisfy me. Can anyone think of a way I > > can express what I want? > > Perhaps if you express it more clearly to us first :-) Is it better now? And conflicting with udev (<< 0.060-1) isn't satisfactory either, since some people may be happy with an old udev. (They only would have devices files attributed to the root group rather than the video group, unless they are able to configure udev themselves...) Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can I simulate a weak conflict?
Hi, I'd like my em8300 package's dependencies to say something like "If you use udev, I'd recommend you use at least 0.060-1." (since specific rules for the em8300 drivers were added in that release, tahnks to Marco d'Itri). Unfortunately, the package system certainly can't guess whether udev is used. So I would translate it to "I'd recommend you have either no udev installed, or at least version 0.060-1.". But I don't think I can express that either. If it was a strong dependency rather that a weak one, I could cheat and express it as a conclict: "Conflicts: udev (<< 0.060-1)". I could also decide to recommend udev anyway: "Recommends: udev (>= 0.060-1)". But none of these 2 solution satisfy me. Can anyone think of a way I can express what I want? Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Complex Depends
Hi, On Tue, Mar 29, 2005 at 08:21:35PM +0200, Shachar Shemesh wrote: > An idea I have been harboring for quite some time, and which bears some > (though not very much) relevance to this thread, is a reverse > dependency. The idea is this: > Package "wine" has wine. > Package "kde" has kde. > Package "wine-kde" has the wine integration into kde. This package > reverse depends on "kde" and "wine", which means that if both "kde" and > "Wine" are installed, then "wine-kde" is automatically installed too. > The idea is that it is installing kde and wine that triggers the > installation of "wine-kde". > > To understand why this is useful, consider webmin. If we could make > webmin-samba reverse depend on samba and webmin, no one would ever have > to figure out whether there are any more useful webmin modules they can > install for their system. It would all be automatically done by > aptitude. Merely installing samba on a system where webmin is installed > will bring webmin-samba in as well, without making samba depend on > webmin or vice versa. I don't think reverse-depends would be fine in such cases. One may want to use webmin to configure something but not to configure samba. Hence, I think reverse-recommends would be much better. Fortunately, reverse-recommends already "exist"; they are implemented with the "enhances:" header. Unfortunately, as far as I know, no tool implements them yet... Cheers, Nicolas PS: please respect my MFT header: I read this list and need no CC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Complex Depends
Hi, On Mon, Mar 28, 2005 at 09:37:07AM -0700, David Everly wrote: >Depends: (package-a,package-1,package-2) | (package-b,package-3) As far as I remember boolean algebra, (a and b and c) or (d and e) is equivalent to (a or d) and (a or e) and (b or d) and (b or e) and (c or d) and (c or e). Than makes awfull dependencies, but it should work... (And no need to duplicate the package.) Wow... It would really be nice to enhance the syntax for dependencies... Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: looking for a sponsor
Hi, On Thu, Oct 21, 2004 at 03:49:56PM +0200, Alejandro Exojo wrote: > > About Outlook: it's propietary software. For me it's not a matter of taste or > technichal reasons (mutt vs. kmail vs. evolution vs. thunderbird...), it's a > matter of commitment with free software. Hmmm? Do you really think free software is about forcing people to use only free software? I thought it was about freedom (including freedom of choice)... If that's really your definition then I don't buy it... Nicolas
Re: looking for a sponsor
Hi, On Thu, Oct 21, 2004 at 03:49:56PM +0200, Alejandro Exojo wrote: > > About Outlook: it's propietary software. For me it's not a matter of taste or > technichal reasons (mutt vs. kmail vs. evolution vs. thunderbird...), it's a > matter of commitment with free software. Hmmm? Do you really think free software is about forcing people to use only free software? I thought it was about freedom (including freedom of choice)... If that's really your definition then I don't buy it... Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 11:00:47PM +0200, Michael Schiansky wrote: > Hi > > On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? > It was never and hopefully will never be. > > I simply like dpatch. I also like dpatch, but I would not try to force Kevin to use it... Nicolas
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 11:00:47PM +0200, Michael Schiansky wrote: > Hi > > On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? > It was never and hopefully will never be. > > I simply like dpatch. I also like dpatch, but I would not try to force Kevin to use it... Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 03:08:28PM +0200, Michael Schiansky wrote: > Remarks: > > - diff.gz >please use dpatch to manage paches on upstream source Since when is the use of dpatch mandatory? Nicolas
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 03:08:28PM +0200, Michael Schiansky wrote: > Remarks: > > - diff.gz >please use dpatch to manage paches on upstream source Since when is the use of dpatch mandatory? Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [[:digit:]] - bashism?
Hi, On Wed, May 26, 2004 at 06:25:41PM -0400, Stephen Gran wrote: > Hello all, > > Looking for some advice. Recently a bug was filed on one of my packages > that really had me pulling my hair out - it turned out to be that the > test to make sure debconf input was numeric was failing because I use > [[:digit:]]* and the user's shell was dash. I've checked the scripts > with checkbashisms, and it doesn't think that that's a bash specific > thing, but perhaps they missed it. > > Looking here: > http://www.opengroup.org/onlinepubs/009695399/toc.htm , it looks like > this is a POSIX expression, so I think I'm right, but I want to be sure > before I just reassign the bug to dash. > > Does anyone know the POSIX standard well enough to know if this is a > bug in dash, or a bashism? Since POSIX = SUSv3, and since SUSv3 specifies http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_13_01 I think this is a bug in dash. Regards, Nicolas
Re: [[:digit:]] - bashism?
Hi, On Wed, May 26, 2004 at 06:25:41PM -0400, Stephen Gran wrote: > Hello all, > > Looking for some advice. Recently a bug was filed on one of my packages > that really had me pulling my hair out - it turned out to be that the > test to make sure debconf input was numeric was failing because I use > [[:digit:]]* and the user's shell was dash. I've checked the scripts > with checkbashisms, and it doesn't think that that's a bash specific > thing, but perhaps they missed it. > > Looking here: > http://www.opengroup.org/onlinepubs/009695399/toc.htm , it looks like > this is a POSIX expression, so I think I'm right, but I want to be sure > before I just reassign the bug to dash. > > Does anyone know the POSIX standard well enough to know if this is a > bug in dash, or a bashism? Since POSIX = SUSv3, and since SUSv3 specifies http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_13_01 I think this is a bug in dash. Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can someone please check my package? (no need for a sponsor, I'm a DD)
Hi, I've spent quite some time recently trying to generate correct packages for em8300. These are quite complex packages with source for a kernel module, a library, quite complex maintainer scripts, complex upgrade from previous versions, etc... I don't feel self-confident enough to upload this to unstable, so this upload will be targetted for experimental. Anyway, I'd be very happy if someone could check them beforehand... The source package is available at http://people.debian.org/~nboullis/em8300-experimental . I know I still have a few things to do: * check if it complies with the latest policy and bump standards-version, * switch to po-debconf. Anyway, I will probably upload the package to experimental next week-end. Thanks in advance, Nicolas pgp0.pgp Description: PGP signature
Can someone please check my package? (no need for a sponsor, I'm a DD)
Hi, I've spent quite some time recently trying to generate correct packages for em8300. These are quite complex packages with source for a kernel module, a library, quite complex maintainer scripts, complex upgrade from previous versions, etc... I don't feel self-confident enough to upload this to unstable, so this upload will be targetted for experimental. Anyway, I'd be very happy if someone could check them beforehand... The source package is available at http://people.debian.org/~nboullis/em8300-experimental . I know I still have a few things to do: * check if it complies with the latest policy and bump standards-version, * switch to po-debconf. Anyway, I will probably upload the package to experimental next week-end. Thanks in advance, Nicolas pgppBWfi3hEGO.pgp Description: PGP signature
Re: duplicate-conffile error ???
Hi! On Tue, Feb 25, 2003 at 09:31:10PM +0100, Sven Luther wrote: > Hello, ... > > I am preparing a new version of one of my packages, and lintian claims > that : > > $ lintian ocaml-base-3.06-1_3.06-16_i386.deb > E: ocaml-base-3.06-1: duplicate-conffile /etc/ocaml/ld.conf > > And effectively, if i open the .deb, i see that /etc/ocaml/ld.conf is > listed two times as conffile. > > Now, i have debian/ocaml-base-3.06-1.conffiles which contains only one > copy of /etc/ocaml/ld.conf, not two, so i have no idea where this second > copy does come from. > > I am using debhelper, and i guess one of the debhelpers is responsible > for this. Does anyone have an idea of where this is coming from ? That's because of dh_installdeb. According to the manpage: In V3 compatability mode and higher, all files in the etc/ directory in a package will automatically be flagged as conffiles by this program, so there is no need to list them manually in package.conffiles. So you should not list the files in /tmp in ocaml-base-3.06-1.conffiles; your ocaml-base-3.06-1.conffiles should most probably be empty... Regards, Nicolas
Re: duplicate-conffile error ???
Hi! On Tue, Feb 25, 2003 at 09:31:10PM +0100, Sven Luther wrote: > Hello, ... > > I am preparing a new version of one of my packages, and lintian claims > that : > > $ lintian ocaml-base-3.06-1_3.06-16_i386.deb > E: ocaml-base-3.06-1: duplicate-conffile /etc/ocaml/ld.conf > > And effectively, if i open the .deb, i see that /etc/ocaml/ld.conf is > listed two times as conffile. > > Now, i have debian/ocaml-base-3.06-1.conffiles which contains only one > copy of /etc/ocaml/ld.conf, not two, so i have no idea where this second > copy does come from. > > I am using debhelper, and i guess one of the debhelpers is responsible > for this. Does anyone have an idea of where this is coming from ? That's because of dh_installdeb. According to the manpage: In V3 compatability mode and higher, all files in the etc/ directory in a package will automatically be flagged as conffiles by this program, so there is no need to list them manually in package.conffiles. So you should not list the files in /tmp in ocaml-base-3.06-1.conffiles; your ocaml-base-3.06-1.conffiles should most probably be empty... Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nvrec
Hi ! I'd be interrested to sponsor nvrec, but I fear there is a problem: On Tue, Jun 11, 2002 at 03:23:30PM +0200, Marc Leeman wrote: > Package: nvrec > Version: 20020530-3 > Priority: extra > Section: x11 > Maintainer: Marc Leeman <[EMAIL PROTECTED]> > Depends: libc6 (>= 2.2.4-4), liblame0 (>= 3.91-0.1) As far as I know, lame is not in Debian, and can't be because of a patent... :-( So I guess nvrec will at best belong to contrib. Were you aware of this issue? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nvrec
Hi ! I'd be interrested to sponsor nvrec, but I fear there is a problem: On Tue, Jun 11, 2002 at 03:23:30PM +0200, Marc Leeman wrote: > Package: nvrec > Version: 20020530-3 > Priority: extra > Section: x11 > Maintainer: Marc Leeman <[EMAIL PROTECTED]> > Depends: libc6 (>= 2.2.4-4), liblame0 (>= 3.91-0.1) As far as I know, lame is not in Debian, and can't be because of a patent... :-( So I guess nvrec will at best belong to contrib. Were you aware of this issue? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pre-depending
Hi! On Thu, Apr 04, 2002 at 03:55:29PM -0600, Gunnar Wolf wrote: > I need debconf and wwwconfig-common for the package I am building. They > need to be correctly installed by the time I run the postinst - I think > that they should be mentioned as pre-depends... Now, as I read, before > including somehting as pre-depends, I should check this with debian-devel. I think that a simple Depends: is enough if you only need the depended package in the postinst. (Checking in policy...) In 7.2: The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. So, a Depends: would be enough. Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pre-depending
Hi! On Thu, Apr 04, 2002 at 03:55:29PM -0600, Gunnar Wolf wrote: > I need debconf and wwwconfig-common for the package I am building. They > need to be correctly installed by the time I run the postinst - I think > that they should be mentioned as pre-depends... Now, as I read, before > including somehting as pre-depends, I should check this with debian-devel. I think that a simple Depends: is enough if you only need the depended package in the postinst. (Checking in policy...) In 7.2: The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. So, a Depends: would be enough. Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 05:10:24PM -0800, Sean 'Shaleh' Perry wrote: > if he compiled with debhelper from potato there is a good chance he would be > lying about his standards version. The standards-version should match the > standards you were compiled against. OK! That's right. I forgot that debhelper may have changed since potato... ;-) Regards, Nicolas PS: please respect the Mail-Followup-To header. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 05:10:24PM -0800, Sean 'Shaleh' Perry wrote: > if he compiled with debhelper from potato there is a good chance he would be > lying about his standards version. The standards-version should match the > standards you were compiled against. OK! That's right. I forgot that debhelper may have changed since potato... ;-) Regards, Nicolas PS: please respect the Mail-Followup-To header. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote: > Hi, > > I have been working on a particular package on my workstation, which runs > Sid. Now, I was some days away from my office, and had only my laptop > (Potato). As my package is not too complicated, I decided to modify it to > be built with Potato successfully - As I guessed, it was fairly easy... > The first question of this message is if you notice anything wrong. I am > working with debhelper... The changes I did were: > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 My question may be stupid, but is it really useful to decrease the stardards-version ? I know that potato's lintian issues a warning for "newer-standards-version", but it sounds rather pointless when backporting a package from unstable. Am I wrong ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote: > Hi, > > I have been working on a particular package on my workstation, which runs > Sid. Now, I was some days away from my office, and had only my laptop > (Potato). As my package is not too complicated, I decided to modify it to > be built with Potato successfully - As I guessed, it was fairly easy... > The first question of this message is if you notice anything wrong. I am > working with debhelper... The changes I did were: > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 My question may be stupid, but is it really useful to decrease the stardards-version ? I know that potato's lintian issues a warning for "newer-standards-version", but it sounds rather pointless when backporting a package from unstable. Am I wrong ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "Easy" Packaging?
Hi! On Wed, Mar 20, 2002 at 11:38:43PM +0100, Martin Eitzenberger wrote: > I want to make a simple debian package (I never made one before) > Only startup-script, docu and depends. But I don't understand how. > > Could anyone help me? First of all, you should read the New Maintainers' Guide (at http://www.debian.org/doc/maint-guide/), if you've not already read it. You might also have a look at the source package for hello or hello-debhelper. Is that what you needed ? Regards, Nicolas
Re: "Easy" Packaging?
Hi! On Wed, Mar 20, 2002 at 11:38:43PM +0100, Martin Eitzenberger wrote: > I want to make a simple debian package (I never made one before) > Only startup-script, docu and depends. But I don't understand how. > > Could anyone help me? First of all, you should read the New Maintainers' Guide (at http://www.debian.org/doc/maint-guide/), if you've not already read it. You might also have a look at the source package for hello or hello-debhelper. Is that what you needed ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: no changes file
Hi! I think this thread belongs to -mentors... On Mon, Mar 18, 2002 at 06:51:01PM +, David H. Askew wrote: > dh_clean > dpkg-source -b jedit-4.0 > dpkg-source: building jedit using existing jedit_4.0.orig.tar.gz > dpkg-source: building jedit in jedit_4.0-1.diff.gz > dpkg-source: cannot represent change to jedit.jar: binary file contents > changed ^^^ > dpkg-source: building jedit in jedit_4.0-1.dsc > dpkg-source: unrepresentable changes to source ^ Here's your answer! Where does this jedit.jar file come from? If it is generated by the build target, you should delete it in the clean target. And if it is really a part of your modifications, you may try to uuencode it... Regards, Nicolas
Re: no changes file
Hi! I think this thread belongs to -mentors... On Mon, Mar 18, 2002 at 06:51:01PM +, David H. Askew wrote: > dh_clean > dpkg-source -b jedit-4.0 > dpkg-source: building jedit using existing jedit_4.0.orig.tar.gz > dpkg-source: building jedit in jedit_4.0-1.diff.gz > dpkg-source: cannot represent change to jedit.jar: binary file contents changed ^^^ > dpkg-source: building jedit in jedit_4.0-1.dsc > dpkg-source: unrepresentable changes to source ^ Here's your answer! Where does this jedit.jar file come from? If it is generated by the build target, you should delete it in the clean target. And if it is really a part of your modifications, you may try to uuencode it... Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: including full source code in upload
On Thu, Jan 17, 2002 at 06:01:21PM -0500, christophe barbé wrote: > On Thu, Jan 17, 2002 at 09:55:56PM +0100, Gergely Nagy wrote: > > > But the original one untar the source in gphoto_2.0beta3. > > > > It doesn't matter where the original untars. dpkg-source (which > > extracts the tar and applies the Debian diff) can cope with it. Just > > rename the tarball, and you'll be set. > > > > > You mean I should only rename it ? > > > > Yep. > > It seems to be not enough : Did you remove gphoto2_2.0beta3-0.1.tar.gz before you retry ? Regards, Nicolas
Re: including full source code in upload
On Thu, Jan 17, 2002 at 06:01:21PM -0500, christophe barbé wrote: > On Thu, Jan 17, 2002 at 09:55:56PM +0100, Gergely Nagy wrote: > > > But the original one untar the source in gphoto_2.0beta3. > > > > It doesn't matter where the original untars. dpkg-source (which > > extracts the tar and applies the Debian diff) can cope with it. Just > > rename the tarball, and you'll be set. > > > > > You mean I should only rename it ? > > > > Yep. > > It seems to be not enough : Did you remove gphoto2_2.0beta3-0.1.tar.gz before you retry ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
need some advice: upstream has several changelogs
Hi ! I'm currently packaging a Mah-Jong game (see ITP #123146), but I have a problem since upstream has several changelogs... The first one is in a file called CHANGES, and contains stuff like that: -- 1.2.3 2001-09-06 Bugfix. Gui: fix stupid bug introduced in last release causing crash after about five hands. 1.2.2 2001-09-04 Feature enhancements. Graphical client: add Tileset and Tileset search path options. Allow display option changes to take immediate effect. -- The second one is in a file called ChangeLog, and contains stuff like that: -- 2001-09-06 Julian Bradfield <[EMAIL PROTECTED]> * CHANGES: 1.2.3 * gui.c: Aaargh! Was clearing discard_history in the wrong place! So it wasn't getting cleared at all. 2001-09-04 Julian Bradfield <[EMAIL PROTECTED]> * ChangeLog: This really is release 1.2.2, unless something else goes wrong. * gui.c: Copy pref_showwall from --[no-]show-wall option. * xmj.man: Show-wall display option now has immediate effect. * CHANGES: 1.2.2 really: includes display option changing. -- The debian package should contain the upstream changelog, but I don't know which one to use. What I currently did is set the CHANGES file as changelog, and include ChangeLog without changing its name. Hence, I have to changelog files (with different capitalization); this might not be good. Could someone please give me some advice ? Thanks, Nicolas
need some advice: upstream has several changelogs
Hi ! I'm currently packaging a Mah-Jong game (see ITP #123146), but I have a problem since upstream has several changelogs... The first one is in a file called CHANGES, and contains stuff like that: -- 1.2.3 2001-09-06 Bugfix. Gui: fix stupid bug introduced in last release causing crash after about five hands. 1.2.2 2001-09-04 Feature enhancements. Graphical client: add Tileset and Tileset search path options. Allow display option changes to take immediate effect. -- The second one is in a file called ChangeLog, and contains stuff like that: -- 2001-09-06 Julian Bradfield <[EMAIL PROTECTED]> * CHANGES: 1.2.3 * gui.c: Aaargh! Was clearing discard_history in the wrong place! So it wasn't getting cleared at all. 2001-09-04 Julian Bradfield <[EMAIL PROTECTED]> * ChangeLog: This really is release 1.2.2, unless something else goes wrong. * gui.c: Copy pref_showwall from --[no-]show-wall option. * xmj.man: Show-wall display option now has immediate effect. * CHANGES: 1.2.2 really: includes display option changing. -- The debian package should contain the upstream changelog, but I don't know which one to use. What I currently did is set the CHANGES file as changelog, and include ChangeLog without changing its name. Hence, I have to changelog files (with different capitalization); this might not be good. Could someone please give me some advice ? Thanks, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Semi-contrib packages
On Sun, Nov 25, 2001 at 08:49:30AM -0500, Adam C Powell IV wrote: > > Right, but it seems policy does not allow a contrib source package to > put binaries in both contrib and main. It's a policy issue, not a > technical one: if a package is "tainted" with a non-free build-dep or > dep for a single binary package on a single arch, then the whole thing > is thrown into contrib. > > And I've decided it's not worth duplicating the source package for > faster performance on this one arch, I've put enough work into the > package so that it's trivial for a user to build his/her own .debs with > the non-free compilers/libs. (Haven't tested gcc-3.0 yet, it's very > possible the performance difference bet ccc/cfal and gcc/g77-3.0 will be > a lot narrower than vs. gcc/g77-2.95.) I'm sorry, I think I was tired and I misunderstood your question. You should better forget everything I wrote, it was only crap... Regards, Nicolas pgpfTkr0VHyZA.pgp Description: PGP signature
Re: Semi-contrib packages
On Sun, Nov 25, 2001 at 08:49:30AM -0500, Adam C Powell IV wrote: > > Right, but it seems policy does not allow a contrib source package to > put binaries in both contrib and main. It's a policy issue, not a > technical one: if a package is "tainted" with a non-free build-dep or > dep for a single binary package on a single arch, then the whole thing > is thrown into contrib. > > And I've decided it's not worth duplicating the source package for > faster performance on this one arch, I've put enough work into the > package so that it's trivial for a user to build his/her own .debs with > the non-free compilers/libs. (Haven't tested gcc-3.0 yet, it's very > possible the performance difference bet ccc/cfal and gcc/g77-3.0 will be > a lot narrower than vs. gcc/g77-2.95.) I'm sorry, I think I was tired and I misunderstood your question. You should better forget everything I wrote, it was only crap... Regards, Nicolas msg04710/pgp0.pgp Description: PGP signature
Re: Semi-contrib packages
On Sat, Nov 24, 2001 at 09:49:29PM -0500, Adam C Powell IV wrote: > >>Can I "Build-Depends: ccc [alpha], cfal [alpha]" and still have the > >>source package in main? > >> > >No, that would violate policy (2.1.2). > > > Right, thanks for pointing this out (I need to RTFP :-). So the source > would become contrib, because some of the binaries would need contrib > software to build on one platform. But then, can I put the > gcc/g77-built binaries in main? Hmm, doubtful. Of course you can. gcc/g77 does not require any non-free software. They require a C compiler, but any C compiler, including gcc itself (for example a previous version). And for the bootsatraping problem on a given architecture, it's still possible to use a cross-compiler on another architecture. AFAICT, only the very first free C compiler may have needed a non-free compiler to build it. But then it was possible to recompile it with itself to have it compiled on a free compiler... Regards, Nicolas pgpyyoEmdhSv9.pgp Description: PGP signature
Re: Semi-contrib packages
On Sat, Nov 24, 2001 at 09:49:29PM -0500, Adam C Powell IV wrote: > >>Can I "Build-Depends: ccc [alpha], cfal [alpha]" and still have the > >>source package in main? > >> > >No, that would violate policy (2.1.2). > > > Right, thanks for pointing this out (I need to RTFP :-). So the source > would become contrib, because some of the binaries would need contrib > software to build on one platform. But then, can I put the > gcc/g77-built binaries in main? Hmm, doubtful. Of course you can. gcc/g77 does not require any non-free software. They require a C compiler, but any C compiler, including gcc itself (for example a previous version). And for the bootsatraping problem on a given architecture, it's still possible to use a cross-compiler on another architecture. AFAICT, only the very first free C compiler may have needed a non-free compiler to build it. But then it was possible to recompile it with itself to have it compiled on a free compiler... Regards, Nicolas msg04695/pgp0.pgp Description: PGP signature
Re: Fwd: Packages
Hi ! On Tue, Nov 20, 2001 at 11:21:58PM +0100, Speed Blue wrote: > > I look for some debian packages to adopt (I am not Advocated, and I > want to > become a debian developper...). > What packages are orphan ??? You shouls have a look at http://www.debian.org/devel/wnpp/ there are lots of RFA (requests for adoption), O (orphaned) and RFP (request for package)... Bye, Nicolas
Re: Fwd: Packages
Hi ! On Tue, Nov 20, 2001 at 11:21:58PM +0100, Speed Blue wrote: > > I look for some debian packages to adopt (I am not Advocated, and I want to > become a debian developper...). > What packages are orphan ??? You shouls have a look at http://www.debian.org/devel/wnpp/ there are lots of RFA (requests for adoption), O (orphaned) and RFP (request for package)... Bye, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_maninstall isn't finding control
Hi !
On Fri, Nov 09, 2001 at 08:15:40AM -0800, Peter Jay Salzman wrote:
> hello all,
>
> when running dh_installman in
>
> /home/p/debian/pdamaze/pdamaze-0.0.20011005/debian
>
> which is where the man page is, i get the error:
>
> [EMAIL PROTECTED] dh_installman ./pdamaze.6
> dh_installman: cannot read debian/control: No such file or directory
>
> the control file _is_ there, right in between copyright and conffiles.ex.
> the error itself makes it sound like you need to be in the upstream source
> directory, so i changed directories to:
>
> /home/p/debian/pdamaze/pdamaze-0.0.20011005
>
> and now the error is:
>
> [EMAIL PROTECTED] dh_installman pdamaze.6
> pdamaze.6: No such file or directory at /usr/bin/dh_installman line 98.
Well, I think that you have to run dh_installman from the upstream
source directory. But then, you have to tell it where the pdamaze.6 file
is.
Hence, you should try "dh_installman debian/pdamaze.6" from the upstream
source directory.
You may also want to set the DH_COMPAT environement variable, if you are
using a compatibility level higher than 1. ("man debhelper" for more
info)
Regards,
Nicolas
Re: dh_maninstall isn't finding control
Hi !
On Fri, Nov 09, 2001 at 08:15:40AM -0800, Peter Jay Salzman wrote:
> hello all,
>
> when running dh_installman in
>
> /home/p/debian/pdamaze/pdamaze-0.0.20011005/debian
>
> which is where the man page is, i get the error:
>
> p@satan% dh_installman ./pdamaze.6
> dh_installman: cannot read debian/control: No such file or directory
>
> the control file _is_ there, right in between copyright and conffiles.ex.
> the error itself makes it sound like you need to be in the upstream source
> directory, so i changed directories to:
>
> /home/p/debian/pdamaze/pdamaze-0.0.20011005
>
> and now the error is:
>
> p@satan% dh_installman pdamaze.6
> pdamaze.6: No such file or directory at /usr/bin/dh_installman line 98.
Well, I think that you have to run dh_installman from the upstream
source directory. But then, you have to tell it where the pdamaze.6 file
is.
Hence, you should try "dh_installman debian/pdamaze.6" from the upstream
source directory.
You may also want to set the DH_COMPAT environement variable, if you are
using a compatibility level higher than 1. ("man debhelper" for more
info)
Regards,
Nicolas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian + man page question
On Thu, Nov 08, 2001 at 05:31:15PM -0600, Warren Turkal wrote: > Is there any kind of documentation that comes with it. If the program > has a --help, you may want to include its output. For the package I > did, I converted the docbook xml to manpage format. I'm not sure to see your point. The defendguin-0.0.6/debian/rules file is used tu build the package. In fact it is a Makefile that call the dh_installmanpages in the binary-arch target (which is, I think, the target that builds the package). The dh_installmanpages is part of debhelper. You can look at the debhelper manpage to have an overview on what it provides. You can also have a look at the dh_installmanpages to understand what this programs exactly does. (Basically, it searches for any file that looks like a man page, and installs it.) However, I'm not really aware on everything about building packages (I'm not a debian developper), so my explanations may be wrong. We should continue this discussion in the debian-mentors mailing-list so that other people can correct what I say wrong. Greetings, Nicolas
Re: lintian + man page question
On Thu, Nov 08, 2001 at 02:11:46PM -0800, Peter Jay Salzman wrote: > > another question though -- i took a look at the deb package for defendguin > (another game written by the same author). the debian maintainer wrote the > manpage for defendguin (bill kendrick knows how to write games, but doesn't > know how to write man pages ;) ). > > for the life of me, i can't figure out how the manpage gets "in there". his > manpage is located in > > defendguin-0.0.6/debian/defendguin.6 > > but it doesn't get installed by anything. i looked in the upstream makefile, > the rules file, the docs file. well, let's just say that i greped for > 'defendguin.6' in all the files residing in debian/. i can't figure out how > that manpage gets installed. Well, I guess it is done by the dh_installmanpages in debian/rules... A little "man dh_installmanpages" may help you to understand. CU Nicolas
Re: lintian + man page question
On Thu, Nov 08, 2001 at 05:31:15PM -0600, Warren Turkal wrote: > Is there any kind of documentation that comes with it. If the program > has a --help, you may want to include its output. For the package I > did, I converted the docbook xml to manpage format. I'm not sure to see your point. The defendguin-0.0.6/debian/rules file is used tu build the package. In fact it is a Makefile that call the dh_installmanpages in the binary-arch target (which is, I think, the target that builds the package). The dh_installmanpages is part of debhelper. You can look at the debhelper manpage to have an overview on what it provides. You can also have a look at the dh_installmanpages to understand what this programs exactly does. (Basically, it searches for any file that looks like a man page, and installs it.) However, I'm not really aware on everything about building packages (I'm not a debian developper), so my explanations may be wrong. We should continue this discussion in the debian-mentors mailing-list so that other people can correct what I say wrong. Greetings, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian + man page question
On Thu, Nov 08, 2001 at 02:11:46PM -0800, Peter Jay Salzman wrote: > > another question though -- i took a look at the deb package for defendguin > (another game written by the same author). the debian maintainer wrote the > manpage for defendguin (bill kendrick knows how to write games, but doesn't > know how to write man pages ;) ). > > for the life of me, i can't figure out how the manpage gets "in there". his > manpage is located in > > defendguin-0.0.6/debian/defendguin.6 > > but it doesn't get installed by anything. i looked in the upstream makefile, > the rules file, the docs file. well, let's just say that i greped for > 'defendguin.6' in all the files residing in debian/. i can't figure out how > that manpage gets installed. Well, I guess it is done by the dh_installmanpages in debian/rules... A little "man dh_installmanpages" may help you to understand. CU Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
