Build-Recommends
I could use a 'build-recommends' dependency, but I understand 'recommends' is only available for the binary package, not the source. Is this correct? The situation: the packaging machine requires 'ocaml' to make binaries from my source package, but if 'ocaml-native-compilers' is also installed it will do so faster, however that package is not available on all architectures. This isn't an essential feature, but here is a case, possibly isolated, where it could be useful. [There is a related problem, see next email please] -- John Skaller, skaller at users.sf.net PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 Download Felix here: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to cope with bad package
How should a package build script cope with a fault in a package used in a build? The situation: there is a fatal bug in the 'ocaml' binary package for the amd64 architecture. This package would contain the native code ocaml compiler for amd64, which has a bug. Native code compilers for x86 works. The debian/rules can detect amd64, and there is a way to force the upstream source to not use the native code compiler. However, the problem will probably be fixed, but I cannot predict in which release of Ocaml. I propose to 'hack' debian/rules to cope. Would that be the proper way? -- John Skaller, skaller at users.sf.net PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 Download Felix here: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with bad package
Le Dim 12 Juin 2005 08:51, John Skaller a écrit : > How should a package build script cope with a fault > in a package used in a build? > > The situation: there is a fatal bug in the 'ocaml' binary > package for the amd64 architecture. This package would > contain the native code ocaml compiler for amd64, which > has a bug. Native code compilers for x86 works. > > The debian/rules can detect amd64, and there is a way > to force the upstream source to not use the native code > compiler. > > However, the problem will probably be fixed, but I cannot > predict in which release of Ocaml. > > I propose to 'hack' debian/rules to cope. Would that > be the proper way? could you bemore specific on the bugs you encounter ? because your explanation lost me a bit. moreover, you may want to ask your question on the ocaml maintainer list (search on lists.debian.org, I don't remember the exact name, but you will meet there a lot of active people with big experience with ocaml apps/libs packaging) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp225OWy2Fao.pgp Description: PGP signature
Re: namespace conflict != package Conflict?
On Sat, Jun 11, 2005 at 11:11:16AM -0600, Sebastian Kuzminsky wrote: > Adam Majer <[EMAIL PROTECTED]> wrote: > > rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard. > > That's true Adam: renaming a file is not hard... But in this case it > has terrible consequences. > > Naming it "cogito-git" makes no sense at all. Cogito uses git, but > git doesnt know or care about cogito. That'd be like naming glibc > "mozilla-glibc", because mozilla uses glibc. Not really. If your package provides git, it's logical to name that binary /usr/bin/cogito-git. > People coming from other systems will correctly percieve this as > debian-induced breakage. Users downloading helper scripts and finding > cookbook recipies on mailing list etc will discover that they are > incompatible with the rest of the universe. > > That seems like too high a price to pay. You need to convince either git or GNU Interactive Tools to change its name upstream then. Since git is the newcomer and its name is already taken (by a GNU project no less!) perhaps you could start there. >From my reading of your package description for cogito, the name GIT (the version control system) doesn't seem to mean anything in particular. So renaming it would not be a big loss. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with bad package
On Sun, 2005-06-12 at 10:30 +0200, Pierre Habouzit wrote: > Le Dim 12 Juin 2005 08:51, John Skaller a écrit : > > How should a package build script cope with a fault > > in a package used in a build? > > > > The situation: there is a fatal bug in the 'ocaml' binary > > package for the amd64 architecture. This package would > > contain the native code ocaml compiler for amd64, which > > has a bug. Native code compilers for x86 works. > > > > The debian/rules can detect amd64, and there is a way > > to force the upstream source to not use the native code > > compiler. > > > > However, the problem will probably be fixed, but I cannot > > predict in which release of Ocaml. > > > > I propose to 'hack' debian/rules to cope. Would that > > be the proper way? > > could you bemore specific on the bugs you encounter ? because your > explanation lost me a bit. 1. The program 'flxg' is an Ocaml program in the Felix system, and is the primary executable of the Felix package. The ITP registration is here: Bug#312734: Acknowledgement (ITP: felix -- a high performance statically typed scripting language) 2. When the source code for 'flxg' is compiled by the Ocaml native code compiler 'ocamlopt' on the amd64 the resulting executable segfaults. 3. When the bytecode compiler 'ocamlc' is used to build 'flxg' the resulting program executes. When the native code compiler is used on the x86, 'flxg' works. 4. The choice between 'ocamlopt' and 'ocamlc' is made by by the upstream build system. 5. There is an override in the configuration script to force the use of the bytecode compiler. 6. I propose to check for 'amd64' in the debian/rules makefile, and call configure like this: ./configure --set-int-NATIVE_CODE_COMPILER=0 if architecture 'amd64' is detected: this will stop the build process using the faulty native code compiler even if it is detected. Unfortunately the condition is not correct: it will exclude all versions of the Ocaml native code compiler for the amd64, even versions in which the bug is fixed (which I'm sure it will be). However (a) I don't know in which version it will be fixed (b) I don't know how to specify a condition on a particular range of versions of a package, particularly when the upper limit of the range is unknown at this time. (c) I cannot simplify the conditions under which the fault occurs, and so can't provide an 'autoconf' style executable test for it: at best I could 'try' the default build and rebuild the whole binary package from scratch using the bytecode compiler if build failed using the native code compiler .. this solution is quite general but extremely ugly .. this is my first attempt to make a Debian package and I suspect people would frown on this technique .. :) -- John Skaller, skaller at users.sf.net PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 Download Felix here: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Sponsor needed for em-panel-applet
Søren Hansen wrote on 09/06/2005 22:20:
>>debian/copyright:
>>
>>- The license is GPL, the copyright is "Copyright 2005 Novell, Inc.",
>> you said the opposite.
>
> Not understood. Miguel wrote it, passed the copyright to Novell and the
> license is GPL. What am I doing wrong then?
The way you filled out the debian/copyright file, it looks as if the GPL
wrote the software while the license is "Copyright 2005 Novell, Inc.".
In other words, you exchanged the values for "license" and "copyright".
>>debian/rules:
>>- You added a line with docbook-to-man to the build-stamp target, but
>> commented it out. Why?
You didn't answer my question here. Is there a reason why you added
docbook-to-man but commented it out?
>>- You should remove, not only comment-out unneeded dh_* calls
>
> I used dh_make to make the debian directory including the rules file,
> and dh_make puts all of those in. That's why they're there. I'll remove
> them.
Right, dh_make always adds all of them. Unless you expect to need and
use one of them in the future, you should remove the unneeded ones as
they only increase the size of the diff and make it more difficult to
see what debian/rules actually does.
>>Did you remove config.sub/config.guess from the upstream tarball or
>>didn't it contain those from the beginning?
>
> They weren't there.
Interesting. The package uses autoconf/automake but those weren't in the
package? Weird (or, at least, unusual).
>>W: em-panel-applet; File /usr/share/doc/em-panel-applet/NEWS.gz in
>>package has zero size.
>> The file above has a size of zero, which probably means it shouldn't
>> be installed.
>>* So you added a NEWS file, but didn't fill it with anything. Either
>>* remove it or add content.
>
> No, actually, the NEWS file was in the upstream, but empty. Just like
> README, AUTHORS and ChangeLog. I'll remove them, no problem.
At least you shouldn't install them with the corresponding dh_* commands
so that they are not included in the package.
>>E: em-panel-applet; Binary /usr/bin/em-panel-applet contains unneeded
>>section .comment.
>> This binary or shared library is not completely stripped. It contains
>> the unneeded section .note, or .comment.
>
> Hmm... I may have compiled it with nostrip and debug options.
> Whoops. :-)
That's one of the reason why it is always a good idea to run linda and
lintian on your final package.
>>E: em-panel-applet; Binary /usr/bin/em-panel-applet is not stripped.
>> The binary shown is not stripped, and is included in a standard
>> package, while Policy shows that it should be stripped.
>>* Forgot to strip the binary ("strip em-panel-applet")
>
> dh_strip does that, right?
It should, IIRC.
>>lintian also finds these additional ones:
>
> Weirdness. When I ran lintian, it was totally quiet..
What file did you run it on? You get the most complete output if you run
it on the .changes file (which causes lintian to check both source and
binary package, if both are included in there).
> Thanks for all you excellent input.
No problem.
cu,
sven
signature.asc
Description: OpenPGP digital signature
co-maintainers sought
OB: cross-posted; please reply privately (Reply-To set). I am looking for co-maintainers for the following of my packages. Most of these packages are also up for adoption in case someone wants to take them over. If interested, please talk to me and I will assess whether I'd bestow ownership to you. I am not trying to be picky, but certain packages are difficult and thus should probably not be taken over by novices. Nevertheless, this is not an RFA as I am happy to continue maintenance of these packages (unless otherwise noted), but would like to have a co-maintainer by my side to help keep bug closing delays short. If you want to help out with any of the packages, please drop me a private line (Reply-To set): - [RFA] bcm4400-source - module source for Broadcom's bcm4400 ethernet driver : http://packages.qa.debian.org/b/bcm4400-source.html - gjay - An automatic and learning DJ for xmms : http://packages.qa.debian.org/g/gjay.html - ipcalc - Parameter calculator for IPv4 addresses : http://packages.qa.debian.org/i/ipcalc.html - iprelay - User-space bandwidth shaping TCP proxy daemon : http://packages.qa.debian.org/i/iprelay.html - kernel-patch-suspend2 - Linux kernel patch for software suspend 2 : http://packages.qa.debian.org/k/kernel-patch-suspend2.html - libfactory++ - C++ template factory framework : http://packages.qa.debian.org/libf/libfactory++.html - libhid - userspace USB HID access library : http://packages.qa.debian.org/libh/libhid.html - libkdtree++ - C++ template container implementation of kd-tree sorting : http://packages.qa.debian.org/libk/libkdtree++.html - libloki - a C++ library of generic design patterns : http://packages.qa.debian.org/libl/libloki.html - libphidgets - Phidgets access library : http://packages.qa.debian.org/libp/libphidgets.html - libs11n - a powerful, extensible C++ serialisation framework : http://packages.qa.debian.org/libs/libs11n.html - libspf - the ANSI C SPF reference library : http://packages.qa.debian.org/libs/libspf.html - libtut - elegant C++ unit test framework : http://packages.qa.debian.org/libt/libtut.html - [RFA] libunit++ - a C++ unit testing framework : http://packages.qa.debian.org/libu/libunit++.html - muttprofile - a utility to choose profiles in Mutt : http://packages.qa.debian.org/m/muttprofile.html - poppass-cgi - a CGI script to interact with a poppassd server : http://packages.qa.debian.org/p/poppass-cgi.html Thanks for your attention. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! if you see an onion ring -- answer it! signature.asc Description: Digital signature
Re: Build-Recommends
[People from debian-ocaml-mail, please keep -mentors CC'ed.] * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: > I could use a 'build-recommends' dependency, > but I understand 'recommends' > is only available for the binary package, not the source. > Is this correct? > The situation: the packaging machine requires 'ocaml' > to make binaries from my source package, but if > 'ocaml-native-compilers' is also installed it will > do so faster, however that package is not available > on all architectures. > This isn't an essential feature, but here is a case, > possibly isolated, where it could be useful. Normally, one resolves this and similar situations like this: Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], ocaml [m68k mips mipsel s390] Where m68k, mips, mipsel and s390 are the architectures that don't have ocaml-native-compilers (I not 100% that the list is correct or complete). This, as you can imagine, instructs the buildds to install one package or the other depending on the architecture the package is being built for. *BUT*, checking build-dependencies of ocaml packages I don't really see that being used, which makes me suspect there's perhaps another mechanism in place to solve this in the Ocaml world in Debian. :) I'm CC'ing debian-ocaml-maint so that somebody there can clear up the issue for us. John, you may want to post there in the future for ocaml-related questions (or search the archives), since there'll be more ocaml-specific knowledge there than in debian-mentors. > [There is a related problem, see next email please] See you there. :) Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The first step on the road to wisdom is the admission of ignorance. The second step is realizing that you don't have to blab it to the world. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: > [People from debian-ocaml-mail, please keep -mentors CC'ed.] > > * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: > > I could use a 'build-recommends' dependency, > > but I understand 'recommends' > > is only available for the binary package, not the source. > > Is this correct? > > > The situation: the packaging machine requires 'ocaml' > > to make binaries from my source package, but if > > 'ocaml-native-compilers' is also installed it will > > do so faster, however that package is not available > > on all architectures. > > > This isn't an essential feature, but here is a case, > > possibly isolated, where it could be useful. > > Normally, one resolves this and similar situations like this: > > Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], >ocaml [m68k mips mipsel s390] > Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? That would look first for ocaml-native-compilers and then if that is not available, for ocaml. Plus, if the ocaml-native-compilers package becomes available for other architectures, it does not require a modification to the Build-Depends to take advantage of it. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpC95LZOnmIX.pgp Description: PGP signature
Re: How to cope with bad package
[debian-ocaml-maint CC'ed again, quoting at full for the benefit of
its subscribers.]
* John Skaller [Sun, 12 Jun 2005 20:40:09 +1000]:
> On Sun, 2005-06-12 at 10:30 +0200, Pierre Habouzit wrote:
> > Le Dim 12 Juin 2005 08:51, John Skaller a écrit :
> > > How should a package build script cope with a fault
> > > in a package used in a build?
> > > The situation: there is a fatal bug in the 'ocaml' binary
> > > package for the amd64 architecture. This package would
> > > contain the native code ocaml compiler for amd64, which
> > > has a bug. Native code compilers for x86 works.
> > > The debian/rules can detect amd64, and there is a way
> > > to force the upstream source to not use the native code
> > > compiler.
> > > However, the problem will probably be fixed, but I cannot
> > > predict in which release of Ocaml.
> > > I propose to 'hack' debian/rules to cope. Would that
> > > be the proper way?
> > could you bemore specific on the bugs you encounter ? because your
> > explanation lost me a bit.
> 1. The program 'flxg' is an Ocaml program in the Felix system,
> and is the primary executable of the Felix package. The ITP
> registration is here:
> Bug#312734: Acknowledgement (ITP: felix -- a high performance
> statically typed scripting language)
> 2. When the source code for 'flxg' is compiled by the Ocaml native code
> compiler 'ocamlopt' on the amd64 the resulting executable segfaults.
> 3. When the bytecode compiler 'ocamlc' is used to build 'flxg'
> the resulting program executes. When the native code
> compiler is used on the x86, 'flxg' works.
> 4. The choice between 'ocamlopt' and 'ocamlc' is made by
> by the upstream build system.
> 5. There is an override in the configuration script
> to force the use of the bytecode compiler.
> 6. I propose to check for 'amd64' in the debian/rules
> makefile, and call configure like this:
> ./configure --set-int-NATIVE_CODE_COMPILER=0
> if architecture 'amd64' is detected: this will stop
> the build process using the faulty native code compiler
> even if it is detected.
> Unfortunately the condition is not correct: it will
> exclude all versions of the Ocaml native code compiler
> for the amd64, even versions in which the bug is
> fixed (which I'm sure it will be). However
> (a) I don't know in which version it will be fixed
> (b) I don't know how to specify a condition on
> a particular range of versions of a package, particularly
> when the upper limit of the range is unknown at this time.
Well, why don't you just put the ./configure option there for amd64
without checking for versions, and when a version of ocaml-native-compilers
that fixes the issue gets uploaded, you re-upload your package with a
versioned build-dependency on it.
There should be a bug about this breakage on amd64, so you should be
able to find out when the issue gets closed. Also, you could submit a
bug against your own package ("ocaml-native-compilers not being used
for amd64 because of Bug#XXX), so that the need of removing that
./configure option is not forgotten.
There'd be also the option of a build-conflicts, but if the configure
option works fine, it seems best.
And yet a third option would be to remove the amd64 ocaml-native-compilers
binaries from the archive, if this breakage is known, affects all
packages, and will take a while to solve. The maintainer would know
more about this.
> (c) I cannot simplify the conditions under which the
> fault occurs, and so can't provide an 'autoconf' style
> executable test for it: at best I could 'try' the default
> build and rebuild the whole binary package from scratch
> using the bytecode compiler if build failed using the
> native code compiler .. this solution is quite general
> but extremely ugly .. this is my first attempt to make
> a Debian package and I suspect people would frown on
> this technique .. :)
Cheers,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
-- Alan Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
John Skaller <[EMAIL PROTECTED]> writes: > I could use a 'build-recommends' dependency, > but I understand 'recommends' > is only available for the binary package, not the source. > Is this correct? > > The situation: the packaging machine requires 'ocaml' > to make binaries from my source package, but if > 'ocaml-native-compilers' is also installed it will > do so faster, however that package is not available > on all architectures. > > This isn't an essential feature, but here is a case, > possibly isolated, where it could be useful. On all archs that have a native ocaml compiler ocaml-native-compiler is available. On all others only bytecode can be build. Any architecture that has ocamlopt also has ocamopt.opt. You can Build-Depend on ocaml-native-compiler [arch, arch, arch] | ocaml [arch, arch]. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with bad package
John Skaller <[EMAIL PROTECTED]> writes: > How should a package build script cope with a fault > in a package used in a build? > > The situation: there is a fatal bug in the 'ocaml' binary > package for the amd64 architecture. This package would > contain the native code ocaml compiler for amd64, which > has a bug. Native code compilers for x86 works. > > The debian/rules can detect amd64, and there is a way > to force the upstream source to not use the native code > compiler. > > However, the problem will probably be fixed, but I cannot > predict in which release of Ocaml. > > I propose to 'hack' debian/rules to cope. Would that > be the proper way? 'Build-Conflict: ocaml (== version) [amd64]' I believe. You just have to hope the next upload fixes the problem. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: co-maintainers sought
> - [RFA] bcm4400-source - module source for Broadcom's bcm4400 ethernet > driver > : http://packages.qa.debian.org/b/bcm4400-source.html What problems do you see with the in-kernel b44 driver that you still need bcm4400? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
* Roberto C. Sanchez [Sun, 12 Jun 2005 09:28:24 -0400]: > Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? Good idea, but it won't work (at least with the version of sbuild in unstable, if buildds are using something more recent and smarter, that's another story). > That would look first for ocaml-native-compilers and then if that is not > available, for ocaml. Plus, if the ocaml-native-compilers package > becomes available for other architectures, it does not require a > modification to the Build-Depends to take advantage of it. As Ian Lynagh pointed me out on IRC, and I later checked on my system, sbuild blindly tries to install the first alternative, and completely fails if it's not available. So you necessarily need to specify arches, modulo my remarks above. Example output from sbuild follows: $ sbuild -d u -v foo_1.dsc ** Using build dependencies supplied by package: Build-Depends: sll | sl, debhelper Checking for already installed source dependencies... sll: missing sl: missing debhelper: already installed Checking for source dependency conflicts... /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install sll Reading Package Lists... Building Dependency Tree... E: Couldn't find package sll Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Under capitalism, man exploits man. Under communism, it's just the opposite. -- J.K. Galbraith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
* Adeodato Simó [Sun, 12 Jun 2005 16:14:00 +0200]: > * Roberto C. Sanchez [Sun, 12 Jun 2005 09:28:24 -0400]: > > Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? > Good idea, but it won't work (at least with the version of sbuild in > unstable, if buildds are using something more recent and smarter, > that's another story). Uhm, I stand corrected: 16:34 Yoe: do you know if the (new?) sbuild used by buildds copes with the situation above? 16:34 dato: yes, it should handle it 16:35 dato: it will install the preferred package, but either fall back if that doesn't exist on the given architecture, 16:35 or not touch whatever is already installed if one is 16:35 ok, sweet 16:35 I will mail -mentors again, sbuild in sid couldn't cope 16:35 for instance, many buildd chroots already have ssmtp installed, so an alternative like 'exim4 | mail-transport-agent' will not do anything 16:35 then sbuild in sid is broken 16:36 but no official autobuilder uses that one anyway; it's been modified so that it's useful to "normal" users as a generic build tool 16:37 Yoe: ok. has this been a recent change in the sbuild used by buildds, or has it been behaving like that for a long time already? 16:37 the latter 16:37 I don't recall it ever behaving differently, in fact Sorry for the false alarm. ;-) -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: co-maintainers sought
On Sun, Jun 12, 2005 at 02:57:38PM +0200, martin f krafft wrote: > - ipcalc - Parameter calculator for IPv4 addresses > : http://packages.qa.debian.org/i/ipcalc.html I would be interested in adoptioning or co-maintaining this package, since I'm using it quite often. So please decide whether you want to stay as co-maintainer or give me its maintainence. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: co-maintainers sought
I am interested in maintaining gjay. I never maintanined any package, so I will need some help, but I am very willing to learn (and contribute). Best regards, Drasko On 6/12/05, martin f krafft <[EMAIL PROTECTED]> wrote: > OB: cross-posted; please reply privately (Reply-To set). > > I am looking for co-maintainers for the following of my packages. > Most of these packages are also up for adoption in case someone > wants to take them over. If interested, please talk to me and I will > assess whether I'd bestow ownership to you. I am not trying to be > picky, but certain packages are difficult and thus should probably > not be taken over by novices. > > Nevertheless, this is not an RFA as I am happy to continue > maintenance of these packages (unless otherwise noted), but would > like to have a co-maintainer by my side to help keep bug closing > delays short. > > If you want to help out with any of the packages, please drop me > a private line (Reply-To set): > > - [RFA] bcm4400-source - module source for Broadcom's bcm4400 ethernet > driver > : http://packages.qa.debian.org/b/bcm4400-source.html > > - gjay - An automatic and learning DJ for xmms > : http://packages.qa.debian.org/g/gjay.html > > - ipcalc - Parameter calculator for IPv4 addresses > : http://packages.qa.debian.org/i/ipcalc.html > > - iprelay - User-space bandwidth shaping TCP proxy daemon > : http://packages.qa.debian.org/i/iprelay.html > > - kernel-patch-suspend2 - Linux kernel patch for software suspend 2 > : http://packages.qa.debian.org/k/kernel-patch-suspend2.html > > - libfactory++ - C++ template factory framework > : http://packages.qa.debian.org/libf/libfactory++.html > > - libhid - userspace USB HID access library > : http://packages.qa.debian.org/libh/libhid.html > > - libkdtree++ - C++ template container implementation of kd-tree sorting > : http://packages.qa.debian.org/libk/libkdtree++.html > > - libloki - a C++ library of generic design patterns > : http://packages.qa.debian.org/libl/libloki.html > > - libphidgets - Phidgets access library > : http://packages.qa.debian.org/libp/libphidgets.html > > - libs11n - a powerful, extensible C++ serialisation framework > : http://packages.qa.debian.org/libs/libs11n.html > > - libspf - the ANSI C SPF reference library > : http://packages.qa.debian.org/libs/libspf.html > > - libtut - elegant C++ unit test framework > : http://packages.qa.debian.org/libt/libtut.html > > - [RFA] libunit++ - a C++ unit testing framework > : http://packages.qa.debian.org/libu/libunit++.html > > - muttprofile - a utility to choose profiles in Mutt > : http://packages.qa.debian.org/m/muttprofile.html > > - poppass-cgi - a CGI script to interact with a poppassd server > : http://packages.qa.debian.org/p/poppass-cgi.html > > Thanks for your attention. > > -- > Please do not send copies of list mail to me; I read the list! > > .''`. martin f. krafft <[EMAIL PROTECTED]> > : :' :proud Debian developer, admin, user, and author > `. `'` > `- Debian - when you have better things to do than fixing a system > > Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! > > if you see an onion ring -- answer it! > > > BodyID:46613293.2.n.logpart (stored separately) > > -- Drasko Draskovic MSc Student in Computer Sciencies School of Electrical Engeneering University of Belgrade
Re: namespace conflict != package Conflict?
Sebastian Kuzminsky wrote: >Adam Majer <[EMAIL PROTECTED]> wrote: > > >>Sebastian Kuzminsky wrote: >> >> >>>Hi folks, I have a noob question for you. I maintain the Cogito package >>>(my first), and it wants to install an executable as /usr/bin/git. The >>>GNU Interactive Tools package (git) also wants to install an executable >>>as /usr/bin/git. To avoid this conflict I made cogito Conflict with git. >>> >>> >>Of course this is *seriously* wrong. Why are you preventing people from >>using git and cogito together? >> >> > >As I see it, it's not _me_ preventing them from being used together, >it's Linus Torvalds, the upstream developer of git-as-in-cogito, who >chose a conflicting name for his project. The problem has been pointed >out to him and he doesnt care: > >http://marc.theaimsgroup.com/?l=git&m=111350397024057&w=2 > > Not a big deal if you ask me. Upstream is not preventing you from renaming git -> cognito-git or similar. >>>I have been told by Jurij Smakov that this is "seriously wrong", and >>>I'm asking for help here. What's the proper way to handle this situation? >>> >>> >>rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard. >> >> > >That's true Adam: renaming a file is not hard... But in this case it >has terrible consequences. > > I don't see them. Debian already has a big mess of stuff like saslpasswd2 instead of saslpasswd. Having cogito-git instead of git makes a lot of sense (see below). >Naming it "cogito-git" makes no sense at all. Cogito uses git, but >git doesnt know or care about cogito. That'd be like naming glibc >"mozilla-glibc", because mozilla uses glibc. > > It is git and comes in the cogito package so it is named cogito-git --- - If mozilla had their own glibc, then they would probably call it mozilla-glibc because it is glibc that is part of mozilla package. >Renaming it something else, like "git.scm" or "git.debian" or >"git.not-gnu-interactive-tools" or something, _might_ make sense, except >then we'd have an incompatible debian-specific fork of git/cogito. > > That's much, much worse. Using period is bad. Using unrelated things like git.debian is not good either because git has little to do with Debian. And the last one, well, kind of looong. Neither of these are "forks". Rename != fork. >People coming from other systems will correctly percieve this as >debian-induced breakage. Users downloading helper scripts and finding >cookbook recipies on mailing list etc will discover that they are >incompatible with the rest of the universe. > >That seems like too high a price to pay. > > An alternative to renaming would be to contact the maintainer of git and try to work something out. If the two commands are compatible, you may want to get them added to alternatives (symlinks) like the alternatives for 'editor' or 'www-browser' or the rest of the things in /etc/alternatives. Then you can rename the file to cognito-git and still have it pointed to as git unless someone installs git or whatever the priorities are set to be. If git's and cognito's git are not compatible, then you really should rename your git -> cognito-git. Conflicting should always be considered *the* last thing to do because it prevents users from using git and cognito on the same system (it is even worse for multi-user systems). Also, users that need to have git pointing to cignoto-git (if /etc/alternatives is not the way to go) can always set up their own symlink in ~/bin or whatever. I hope this makes a little bit of sense. In summary, * conflicts -> bad * renaming binaries -> less bad. Try to rename to - format. could also be the name of the source if that makes more sense. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: > [People from debian-ocaml-mail, please keep -mentors CC'ed.] > > * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: > > I could use a 'build-recommends' dependency, > > but I understand 'recommends' > > is only available for the binary package, not the source. > > Is this correct? > > > The situation: the packaging machine requires 'ocaml' > > to make binaries from my source package, but if > > 'ocaml-native-compilers' is also installed it will > > do so faster, however that package is not available > > on all architectures. > > > This isn't an essential feature, but here is a case, > > possibly isolated, where it could be useful. > > Normally, one resolves this and similar situations like this: > > Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], >ocaml [m68k mips mipsel s390] >From a subsequent posting on the list I got the impression that you have misunderstood the description of the ocaml-native-compilers package. In fact there are two dimensions to consider when you talk about "native code compiler": - does the compiler produce byte code or native code? - is the compiler itself a byte code executable or a native code executable? The package "ocaml-native-compilers" provides ocaml compilers (both to byte code and native code) which are themselves machine code executables. Their advantage over byte code executables is that they are faster, their disadvantage is that they may take longer to load. If you want to say in your package control file to depend on the fastest available compiler on any architecture then your should depend on "ocaml-best-compilers" which is a virtual package provided by "ocaml-best-compilers" on architectures where it exists, and provided by ocaml on the other architectures. If you want to use this then the makefile should be able to call the *.opt executables when they are present on the system. However, if you want to have a finer control over the *target* of the compilation (byte code or machine code) then I guess the only way is to patch the makefile, or do an appropriate test in the debian/rules file. -Ralf. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: terraform 0.9.0-3
Hello.
I'd like to adopt terraform (wnpp bug: #267911). I'm not a DD yet, so
I'll be needing a sponsor for the upload.
Here's the changelog entry for my version:
terraform (0.9.0-3) unstable; urgency=low
* New maintainer. (Closes: #267911)
* Run povray instead of x-povray for rendering.
* Updated standards-version to 3.6.1.1.
* Build-depends on autotools-dev. cp new versions of config.{guess,sub}
on each build.
* Patched data/include/skies/earth_regular_sky.inc. (Closes: #269096)
-- Kari Pahula <[EMAIL PROTECTED]> Mon, 13 Jun 2005 00:47:47 +0300
It's uploaded to mentors.debian.net.
Upstream seems to be inactive. The program is in a bit sorry state.
I couldn't get autotools (even the old versions 2.13 and 1.4) to run
with a moderate effort. Strictly that's not required, but it would've
made my life easier.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: lincity-ng
Hi, I'm searching a sponsor for lincity-ng. Lincity-ng is a fork of the original lincity game with a more user-friendly interface and completely new, polished isometric graphics made in Blender. See http://lincity-ng.berlios.de/wiki/index.php/Image:Liftoff2.png for an example. The 0.9 release is playable with some rough edges. As lincity-ng is more or less an almost new game and more resource demanding than the original lincity, it has been agreed with the lincity maintainer that both should co-exist for now. The packages are lintian/linda clean, all files have been checked for DFSG conformance, the arch-independant game data has been split off into a separate package and the included copy of Bitstream vera has been removed from the binary package. Packages and source can be pulled from http://www.tzi.de/~jmm/debian/ Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lincity-ng
On Sun, Jun 12, 2005 at 11:45:29PM +0200, Moritz Muehlenhoff wrote: > Hi, > I'm searching a sponsor for lincity-ng. Before anybody else looks for this too: this package does have an ITP submitted for it (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311787). Sorry, I'm not a DD and can't sponsor it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
unsubscribe
Re: Build-Recommends
Adeodato Simó <[EMAIL PROTECTED]> writes: > * Adeodato Simó [Sun, 12 Jun 2005 16:14:00 +0200]: >> * Roberto C. Sanchez [Sun, 12 Jun 2005 09:28:24 -0400]: > >> > Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? > >> Good idea, but it won't work (at least with the version of sbuild in >> unstable, if buildds are using something more recent and smarter, >> that's another story). > > Uhm, I stand corrected: > > 16:34 Yoe: do you know if the (new?) sbuild used by buildds copes with > the situation above? > 16:34 dato: yes, it should handle it > 16:35 dato: it will install the preferred package, but either fall back > if that doesn't exist on the given architecture, > 16:35 or not touch whatever is already installed if one is > 16:35 ok, sweet > 16:35 I will mail -mentors again, sbuild in sid couldn't cope > 16:35 for instance, many buildd chroots already have ssmtp installed, so > an alternative like 'exim4 | mail-transport-agent' will not do > anything > 16:35 then sbuild in sid is broken > 16:36 but no official autobuilder uses that one anyway; it's been > modified so that it's useful to "normal" users as a generic build > tool > 16:37 Yoe: ok. has this been a recent change in the sbuild used by > buildds, or has it been behaving like that for a long time > already? > 16:37 the latter > 16:37 I don't recall it ever behaving differently, in fact > > > Sorry for the false alarm. ;-) I think yoe is wrong there. Sbuild should not fall back to alternatives for Build-Depends and afaik does not in any version. With fallback the build becomes undeterministic. What is true is that sbuild only installs Build-Depends that are missing but then always the first. So if ssmtp is preinstalled in the chroot then 'exim4 | mail-transport-agent' is already fullfilled and is skiped by sbuild. In summary: If ocaml is preinstalled in the chroot then 'ocaml-native-compilers | ocaml' will do nothing. Otherwise ocaml-native-compilers will be installed and fails on some archs. Also if ocaml is preinstalled and ocaml-native-compilers exists it still isn't installed and the debian/rules will not find ocamlopt.opt. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: >> [People from debian-ocaml-mail, please keep -mentors CC'ed.] >> >> * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: >> > I could use a 'build-recommends' dependency, >> > but I understand 'recommends' >> > is only available for the binary package, not the source. >> > Is this correct? >> >> > The situation: the packaging machine requires 'ocaml' >> > to make binaries from my source package, but if >> > 'ocaml-native-compilers' is also installed it will >> > do so faster, however that package is not available >> > on all architectures. >> >> > This isn't an essential feature, but here is a case, >> > possibly isolated, where it could be useful. >> >> Normally, one resolves this and similar situations like this: >> >> Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], >>ocaml [m68k mips mipsel s390] >> > > Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? > That would look first for ocaml-native-compilers and then if that is not > available, for ocaml. Plus, if the ocaml-native-compilers package > becomes available for other architectures, it does not require a > modification to the Build-Depends to take advantage of it. > > -Roberto No it wouldn't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
