Adding a specific unrecognized lib to shlibs using debhelper?
Sorry if that's an FAQ. I searched some on archives and didn't find what I wanted. The next release of ICU may have a library /usr/lib/libicudt20l.so which is not recognized by dh_makeshlibs because it has the wrong naming convention. As a result lintian complains my package contains a lib that is not I shlibs (nor md5sums). How can I add it? I tried having an shlibs.local but this describes properly named libraries, so... I am working upstream (I am one of the developers, but we need consensus for such changes) to fix that but if I can't, what can I do besides always carrying a diff to rename this library in the build? How can I make the package list it? Thanks, YA -- My opinions do not necessarily reflect my company's. The opposite is also true.
Re: sourceforge sucks
Yven Johannes Leist (2001-11-10 18:22:26 +0100) : > On Saturday 10 November 2001 18:13, Yven Johannes Leist wrote: >> das mit dem release könnte noch dauern, suckforge ist gerade grauenhaft >> langsam bis überhaupt nicht mehr responding :-(( > sorry for the inconvenience, this message was not supposed to go > here, I must have hit the wrong button. I don't understand much German, but it sounded like you're not very happy with Sourceforge.net. I can therefore only suggest you install your own Sourceforge, for which there is a package (maintained by yours truly). It's not as current as sf.net, obviously, since the upstream code hasn't been released for a while, but it works rather fine. Of course, if it doesn't, bug reports are welcome :-) Roland. -- Roland Mas Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ? Un sumotori qui a bu trop de saké.
[no subject]
Dear friends, I have written a piece of software that I would like to offer for inclusion into a future release of Debian (it is a lightweight, non-intrusive backup tool targeting standalone/home computers that combines some properties I could not find in previously existing tools that way). I am not a Debian developer, however, I have created the necessary packaging metadata according to the Debian Packaging Manual and the Policy Manual. Lintian v1.10 does not report any problems. How can I proceed further? All information about the tool can be found at http://backup2l.sourceforge.net Gundolf
Re: sourceforge sucks
On Monday 12 November 2001 09:59, Roland Mas wrote: > Yven Johannes Leist (2001-11-10 18:22:26 +0100) : > > On Saturday 10 November 2001 18:13, Yven Johannes Leist wrote: > >> das mit dem release könnte noch dauern, suckforge ist gerade grauenhaft > >> langsam bis überhaupt nicht mehr responding :-(( > > > > sorry for the inconvenience, this message was not supposed to go > > here, I must have hit the wrong button. > > I don't understand much German, but it sounded like you're not very > happy with Sourceforge.net. I can therefore only suggest you install > your own Sourceforge, for which there is a package (maintained by > yours truly). It's not as current as sf.net, obviously, since the > upstream code hasn't been released for a while, but it works rather > fine. Of course, if it doesn't, bug reports are welcome :-) Thanks for the hint, I did so already, (and I think you've done a great job with this package), but my problem with sourceforge.net was simply that I could not upload a new release for our project xnap (for which there is a debian package by the way) for quite a long time due to their servers being totally unresponding; By the way I'm of course not really of the opinion that sourceforge "sucks"; one really has to admit that valinux does an incredible job for the open source commity, hosting I think more than 16000 projects on their servers, which sort of explains why they are a bit slow sometimes. Cheers, Yven P.S. It would be fantastic if anyone on this list had a look at the debian package of xnap, to be found here: http://sourceforge.net/project/showfiles.php?group_id=9285 Warning: you need java 1.3 so that probably severely limits the number of people willing to try it :-( -- Yven Leist - [EMAIL PROTECTED] http://www.yven.beldesign.de
Re: dpkg-source: unrepresentable changes to source
Hello!
On 04-Nov-2001 Steve M. Robbins wrote:
> In your original mail, the question was what to do about symbolic
> links like "missing --> /usr/share/automake/missing". The answer is:
> replace them by the file to which they are linked.
Yes, thanks. I do understand another part of this autoconf
mess now.
I thought the autotools might be able to copy files instead of
making symlinks. But it looks like I have to replace the symlinks
with files by myself. Do you or does anyone here have a Makefile/sh
snippet which I might use for this task?
> the old version is "nonexistent". Normally one would expect the
> source distribution to include these files (INSTALL, install-sh, etc).
No, I am packaging from the official release tar file. These needed
files are not included in upstream source.
Upstream provides an autogen.sh script. The user is supposed
to run that script and a normal "make;make install" works
after that.
> If you are deleting the files yourself, then the fix is simple: don't
> do that. Notwithstanding autotools-dev README, I find the best policy
> for dealing with auto-based packages is to simply drop in the latest
> /usr/share/misc/config.{guess,sub}, if required, and build.
See above, this is not true in my case.
> However, after a number of bug reports, I have changed my mind. It
> doesn't pay to mess around with automake/autoconf/libtool and stuff
> inside debian/rules. All I do now is: make any tweaks to Makefile.am
> or configure.in, re-run the auto-stuff on my local copy, and live with
> the enlarged diff that results.
I do not need to change anything until now. But I need to run these
tools. You say you "re-run the auto-stuff on your local copy". As I understand
you here you run it manually and then you build the diff after that.
I want to reach the same goal, but don't want to do it manually.
Therefore I do "mess around with automake/.. inside debian/rules" and call the
apropriate scripts there. This should lead to the same results, right?
> If you need to run-something like
> autogen.sh that has "automake --add-missing --force", just replace the
> resulting symlinks by the corresponding file. Again, you need only do
> this once.
What do you mean by saying I only need to do this once? I do
replace this files everytime the symlinks get created. That is,
everytime I build a new Debian package including the diff.
I feel I am missing your point here absolutely. ;)
Thanks for your input!
Florian
--
Florian Hinzmann private: [EMAIL PROTECTED]
Debian: [EMAIL PROTECTED]
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F DF1C DF79 A374 B407 1A65
Re: dpkg-source: unrepresentable changes to source
Hi Eduard! On 04-Nov-2001 Eduard Bloch wrote: >#include > Florian Hinzmann wrote on Sun Nov 04, 2001 um 08:18:47PM: > >> I can't do a configure run as there is no configure script! >> I do have to run the autotools scripts. >> >> The question is when to run it. Before or after the Debian >> diff is built. > > Well, if you _need_ the makefile to clean the cruft after the build, you > may run autogen.sh once, then "make clean", then remove the fresh > created symlinks, then dh_clean. IMHO. I do not need to clean the cruft and I cannot remove the symlinks. On the contrary I need to create this files before XFMail will build. >> >> Not an option as far as I understand this issue >> >> up to now. Autobuilders have or might have problems >> >> with this. >> > >> > They should not. If they become trouble, then either your package is >> >> Might be, the should not. But as a matter of fact they do. >> What now? > > Find out what actually breaks on auto-builders and file bug reports. Not possible. There have been many bugreports and the way described in doc/autotools-dev/README.Debian.gz is one solution to this problem. The autobuilders are not the problem by themselves. They fail or may fail because of newer versions of automake/autoconf/etc. are not compatible to older versions at all times. Therefore the autobuilders should not have to run the autotools. Therefore I have to run them before creating the diff and this is what I am trying to do. All this, like my last mails, as far as I understand this. I am not 100% sure about this. That is why I keep posting to this mailing list. ;) > That is why compatibility is a holy grail in Debian development. And I am trying to ensure this compatibility. I am trying to build XFMail a way it does not suffer from weaknesses the autotools seem to have. Regards Florian -- Florian Hinzmann private: [EMAIL PROTECTED] Debian: [EMAIL PROTECTED] PGP Key / ID: 1024D/B4071A65 Fingerprint : F9AB 00C1 3E3A 8125 DD3F DF1C DF79 A374 B407 1A65
Re: dpkg-source: unrepresentable changes to source
On Mon, Nov 12, 2001 at 13:47:04 +0100, Florian Hinzmann wrote: > Hello! > > > On 04-Nov-2001 Steve M. Robbins wrote: > > > In your original mail, the question was what to do about symbolic > > links like "missing --> /usr/share/automake/missing". The answer is: > > replace them by the file to which they are linked. > > Yes, thanks. I do understand another part of this autoconf > mess now. > I thought the autotools might be able to copy files instead of > making symlinks. But it looks like I have to replace the symlinks > with files by myself. Do you or does anyone here have a Makefile/sh > snippet which I might use for this task? At least automake used to have a switch for that... [234]% automake --help|grep copy -c, --copywith -a, copy missing files (default is symlink) Cheers, M/
[OT] sf.net and "free" software (was: Re: sourceforge sucks)
Today, Yven Johannes Leist <[EMAIL PROTECTED]> wrote: > By the way I'm of course not really of the opinion that sourceforge > "sucks"; one really has to admit that valinux does an incredible job > for the open source commity, hosting I think more than 16000 projects > on their servers, which sort of explains why they are a bit slow > sometimes. Until I read http://mailman.fsfeurope.org/pipermail/announce/2001-November/28.html>, I too held that opinion, too. Now, I think one should be more careful about where to place projects (savannah.gnu.org, maybe?). -- Andreas Fuchs, <[EMAIL PROTECTED]>, [EMAIL PROTECTED], antifuchs Hail RMS! Hail Cthulhu! Hail Eris! All hail Discordia! pgpFu4ci3cJy7.pgp Description: PGP signature
Source package merge
Hi folks! I had a 'logical' software package consisting of two physical source packages. Now I have merged them into one source pkg, named after one of the original source pkgs. So, concretly, 'gql' and 'gql-drivers' are becoming 'gql' (with gql containing gql-drivers, of course). Now there are some open bugs against gql-drivers, which I want to close with the upload of the new gql package. Should I reassign them to gql and close them from the changelog? (I guess so) Also: since gql-drivers is no longer needed, I want to get it off the archive. Is the correct way to file a bug against non-us.debian.org (where gql-drivers resides)? Thx for any help, Andy -- Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | [EMAIL PROTECTED] Georg-Rendlweg 28| A-5111 Bürmoos | Austria | Europe http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Re: Source package merge
> > Now there are some open bugs against gql-drivers, which I want to > close with the upload of the new gql package. Should I reassign them > to gql and close them from the changelog? (I guess so) > looks like you have never had someone accidently close a bug of yours (-: Just close the bug as is, because the bug is closed by your upload. > Also: since gql-drivers is no longer needed, I want to get it off the > archive. Is the correct way to file a bug against non-us.debian.org > (where gql-drivers resides)? > usually it is ftp.d.o, but in this case non-us.d.o sounds right.
Re: your mail
On Mon, Nov 12, 2001 at 12:38:46PM +0100, Gundolf Kiefer wrote: > > I have written a piece of software that I would like to offer for inclusion > into a future release of Debian > > I am not a Debian developer, > > How can I proceed further? one of two ways: you can apply to become a debian developer http://www.debian.org/devel/join/newmaint or you can file a Request for Package be sending an email to the Bug Tracking System. http://www.debian.org/devel/wnpp/ describes the proper format. whichever way you decide to go, i wish you luck! -john
Re: Source package merge
On Mon, Nov 12, 2001 at 12:46:16PM -0800, Sean 'Shaleh' Perry wrote: > > Also: since gql-drivers is no longer needed, I want to get it off the > > archive. Is the correct way to file a bug against non-us.debian.org > > (where gql-drivers resides)? > > usually it is ftp.d.o, but in this case non-us.d.o sounds right. BTW that's nonus.debian.org, the pseudo-package doesn't seem to include the hyphen. -- 2. That which causes joy or happiness.
Re: [OT] sf.net and "free" software (was: Re: sourceforge sucks)
On Mon, 12 Nov 2001 21:24, Andreas Fuchs wrote: > Today, Yven Johannes Leist <[EMAIL PROTECTED]> wrote: > > By the way I'm of course not really of the opinion that sourceforge > > "sucks"; one really has to admit that valinux does an incredible job > > for the open source commity, hosting I think more than 16000 projects > > on their servers, which sort of explains why they are a bit slow > > sometimes. > > Until I read > http://mailman.fsfeurope.org/pipermail/announce/2001-November/28.h >tml>, I too held that opinion, too. Now, I think one should be more careful > about where to place projects (savannah.gnu.org, maybe?). OK. I think that we should ideally have a Debian portal providing source-forge like functionality (maybe with this GNU package of software). I am sure that we will soon have many such portals to choose from, but I would prefer to host Portslave, Bonnie++, Postal, and my other projects on a Debian based site. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Adding a specific unrecognized lib to shlibs using debhelper?
Sorry if that's an FAQ. I searched some on archives and didn't find what I wanted. The next release of ICU may have a library /usr/lib/libicudt20l.so which is not recognized by dh_makeshlibs because it has the wrong naming convention. As a result lintian complains my package contains a lib that is not I shlibs (nor md5sums). How can I add it? I tried having an shlibs.local but this describes properly named libraries, so... I am working upstream (I am one of the developers, but we need consensus for such changes) to fix that but if I can't, what can I do besides always carrying a diff to rename this library in the build? How can I make the package list it? Thanks, YA -- My opinions do not necessarily reflect my company's. The opposite is also true. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sourceforge sucks
Yven Johannes Leist (2001-11-10 18:22:26 +0100) : > On Saturday 10 November 2001 18:13, Yven Johannes Leist wrote: >> das mit dem release könnte noch dauern, suckforge ist gerade grauenhaft >> langsam bis überhaupt nicht mehr responding :-(( > sorry for the inconvenience, this message was not supposed to go > here, I must have hit the wrong button. I don't understand much German, but it sounded like you're not very happy with Sourceforge.net. I can therefore only suggest you install your own Sourceforge, for which there is a package (maintained by yours truly). It's not as current as sf.net, obviously, since the upstream code hasn't been released for a while, but it works rather fine. Of course, if it doesn't, bug reports are welcome :-) Roland. -- Roland Mas Qu'est-ce qui est jaune, qui pèse deux cents kilos et qui chante ? Un sumotori qui a bu trop de saké. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
Dear friends, I have written a piece of software that I would like to offer for inclusion into a future release of Debian (it is a lightweight, non-intrusive backup tool targeting standalone/home computers that combines some properties I could not find in previously existing tools that way). I am not a Debian developer, however, I have created the necessary packaging metadata according to the Debian Packaging Manual and the Policy Manual. Lintian v1.10 does not report any problems. How can I proceed further? All information about the tool can be found at http://backup2l.sourceforge.net Gundolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sourceforge sucks
On Monday 12 November 2001 09:59, Roland Mas wrote: > Yven Johannes Leist (2001-11-10 18:22:26 +0100) : > > On Saturday 10 November 2001 18:13, Yven Johannes Leist wrote: > >> das mit dem release könnte noch dauern, suckforge ist gerade grauenhaft > >> langsam bis überhaupt nicht mehr responding :-(( > > > > sorry for the inconvenience, this message was not supposed to go > > here, I must have hit the wrong button. > > I don't understand much German, but it sounded like you're not very > happy with Sourceforge.net. I can therefore only suggest you install > your own Sourceforge, for which there is a package (maintained by > yours truly). It's not as current as sf.net, obviously, since the > upstream code hasn't been released for a while, but it works rather > fine. Of course, if it doesn't, bug reports are welcome :-) Thanks for the hint, I did so already, (and I think you've done a great job with this package), but my problem with sourceforge.net was simply that I could not upload a new release for our project xnap (for which there is a debian package by the way) for quite a long time due to their servers being totally unresponding; By the way I'm of course not really of the opinion that sourceforge "sucks"; one really has to admit that valinux does an incredible job for the open source commity, hosting I think more than 16000 projects on their servers, which sort of explains why they are a bit slow sometimes. Cheers, Yven P.S. It would be fantastic if anyone on this list had a look at the debian package of xnap, to be found here: http://sourceforge.net/project/showfiles.php?group_id=9285 Warning: you need java 1.3 so that probably severely limits the number of people willing to try it :-( -- Yven Leist - [EMAIL PROTECTED] http://www.yven.beldesign.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source: unrepresentable changes to source
Hello!
On 04-Nov-2001 Steve M. Robbins wrote:
> In your original mail, the question was what to do about symbolic
> links like "missing --> /usr/share/automake/missing". The answer is:
> replace them by the file to which they are linked.
Yes, thanks. I do understand another part of this autoconf
mess now.
I thought the autotools might be able to copy files instead of
making symlinks. But it looks like I have to replace the symlinks
with files by myself. Do you or does anyone here have a Makefile/sh
snippet which I might use for this task?
> the old version is "nonexistent". Normally one would expect the
> source distribution to include these files (INSTALL, install-sh, etc).
No, I am packaging from the official release tar file. These needed
files are not included in upstream source.
Upstream provides an autogen.sh script. The user is supposed
to run that script and a normal "make;make install" works
after that.
> If you are deleting the files yourself, then the fix is simple: don't
> do that. Notwithstanding autotools-dev README, I find the best policy
> for dealing with auto-based packages is to simply drop in the latest
> /usr/share/misc/config.{guess,sub}, if required, and build.
See above, this is not true in my case.
> However, after a number of bug reports, I have changed my mind. It
> doesn't pay to mess around with automake/autoconf/libtool and stuff
> inside debian/rules. All I do now is: make any tweaks to Makefile.am
> or configure.in, re-run the auto-stuff on my local copy, and live with
> the enlarged diff that results.
I do not need to change anything until now. But I need to run these
tools. You say you "re-run the auto-stuff on your local copy". As I understand
you here you run it manually and then you build the diff after that.
I want to reach the same goal, but don't want to do it manually.
Therefore I do "mess around with automake/.. inside debian/rules" and call the
apropriate scripts there. This should lead to the same results, right?
> If you need to run-something like
> autogen.sh that has "automake --add-missing --force", just replace the
> resulting symlinks by the corresponding file. Again, you need only do
> this once.
What do you mean by saying I only need to do this once? I do
replace this files everytime the symlinks get created. That is,
everytime I build a new Debian package including the diff.
I feel I am missing your point here absolutely. ;)
Thanks for your input!
Florian
--
Florian Hinzmann private: [EMAIL PROTECTED]
Debian: [EMAIL PROTECTED]
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F DF1C DF79 A374 B407 1A65
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source: unrepresentable changes to source
Hi Eduard! On 04-Nov-2001 Eduard Bloch wrote: >#include > Florian Hinzmann wrote on Sun Nov 04, 2001 um 08:18:47PM: > >> I can't do a configure run as there is no configure script! >> I do have to run the autotools scripts. >> >> The question is when to run it. Before or after the Debian >> diff is built. > > Well, if you _need_ the makefile to clean the cruft after the build, you > may run autogen.sh once, then "make clean", then remove the fresh > created symlinks, then dh_clean. IMHO. I do not need to clean the cruft and I cannot remove the symlinks. On the contrary I need to create this files before XFMail will build. >> >> Not an option as far as I understand this issue >> >> up to now. Autobuilders have or might have problems >> >> with this. >> > >> > They should not. If they become trouble, then either your package is >> >> Might be, the should not. But as a matter of fact they do. >> What now? > > Find out what actually breaks on auto-builders and file bug reports. Not possible. There have been many bugreports and the way described in doc/autotools-dev/README.Debian.gz is one solution to this problem. The autobuilders are not the problem by themselves. They fail or may fail because of newer versions of automake/autoconf/etc. are not compatible to older versions at all times. Therefore the autobuilders should not have to run the autotools. Therefore I have to run them before creating the diff and this is what I am trying to do. All this, like my last mails, as far as I understand this. I am not 100% sure about this. That is why I keep posting to this mailing list. ;) > That is why compatibility is a holy grail in Debian development. And I am trying to ensure this compatibility. I am trying to build XFMail a way it does not suffer from weaknesses the autotools seem to have. Regards Florian -- Florian Hinzmann private: [EMAIL PROTECTED] Debian: [EMAIL PROTECTED] PGP Key / ID: 1024D/B4071A65 Fingerprint : F9AB 00C1 3E3A 8125 DD3F DF1C DF79 A374 B407 1A65 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source: unrepresentable changes to source
On Mon, Nov 12, 2001 at 13:47:04 +0100, Florian Hinzmann wrote: > Hello! > > > On 04-Nov-2001 Steve M. Robbins wrote: > > > In your original mail, the question was what to do about symbolic > > links like "missing --> /usr/share/automake/missing". The answer is: > > replace them by the file to which they are linked. > > Yes, thanks. I do understand another part of this autoconf > mess now. > I thought the autotools might be able to copy files instead of > making symlinks. But it looks like I have to replace the symlinks > with files by myself. Do you or does anyone here have a Makefile/sh > snippet which I might use for this task? At least automake used to have a switch for that... [234]% automake --help|grep copy -c, --copywith -a, copy missing files (default is symlink) Cheers, M/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] sf.net and "free" software (was: Re: sourceforge sucks)
Today, Yven Johannes Leist <[EMAIL PROTECTED]> wrote: > By the way I'm of course not really of the opinion that sourceforge > "sucks"; one really has to admit that valinux does an incredible job > for the open source commity, hosting I think more than 16000 projects > on their servers, which sort of explains why they are a bit slow > sometimes. Until I read http://mailman.fsfeurope.org/pipermail/announce/2001-November/28.html>, I too held that opinion, too. Now, I think one should be more careful about where to place projects (savannah.gnu.org, maybe?). -- Andreas Fuchs, <[EMAIL PROTECTED]>, [EMAIL PROTECTED], antifuchs Hail RMS! Hail Cthulhu! Hail Eris! All hail Discordia! msg04620/pgp0.pgp Description: PGP signature
Source package merge
Hi folks! I had a 'logical' software package consisting of two physical source packages. Now I have merged them into one source pkg, named after one of the original source pkgs. So, concretly, 'gql' and 'gql-drivers' are becoming 'gql' (with gql containing gql-drivers, of course). Now there are some open bugs against gql-drivers, which I want to close with the upload of the new gql package. Should I reassign them to gql and close them from the changelog? (I guess so) Also: since gql-drivers is no longer needed, I want to get it off the archive. Is the correct way to file a bug against non-us.debian.org (where gql-drivers resides)? Thx for any help, Andy -- Andreas Rottmann | Dru@ICQ| 118634484@ICQ | [EMAIL PROTECTED] Georg-Rendlweg 28| A-5111 Bürmoos | Austria | Europe http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package merge
> > Now there are some open bugs against gql-drivers, which I want to > close with the upload of the new gql package. Should I reassign them > to gql and close them from the changelog? (I guess so) > looks like you have never had someone accidently close a bug of yours (-: Just close the bug as is, because the bug is closed by your upload. > Also: since gql-drivers is no longer needed, I want to get it off the > archive. Is the correct way to file a bug against non-us.debian.org > (where gql-drivers resides)? > usually it is ftp.d.o, but in this case non-us.d.o sounds right. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: your mail
On Mon, Nov 12, 2001 at 12:38:46PM +0100, Gundolf Kiefer wrote: > > I have written a piece of software that I would like to offer for inclusion > into a future release of Debian > > I am not a Debian developer, > > How can I proceed further? one of two ways: you can apply to become a debian developer http://www.debian.org/devel/join/newmaint or you can file a Request for Package be sending an email to the Bug Tracking System. http://www.debian.org/devel/wnpp/ describes the proper format. whichever way you decide to go, i wish you luck! -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source package merge
On Mon, Nov 12, 2001 at 12:46:16PM -0800, Sean 'Shaleh' Perry wrote: > > Also: since gql-drivers is no longer needed, I want to get it off the > > archive. Is the correct way to file a bug against non-us.debian.org > > (where gql-drivers resides)? > > usually it is ftp.d.o, but in this case non-us.d.o sounds right. BTW that's nonus.debian.org, the pseudo-package doesn't seem to include the hyphen. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] sf.net and "free" software (was: Re: sourceforge sucks)
On Mon, 12 Nov 2001 21:24, Andreas Fuchs wrote: > Today, Yven Johannes Leist <[EMAIL PROTECTED]> wrote: > > By the way I'm of course not really of the opinion that sourceforge > > "sucks"; one really has to admit that valinux does an incredible job > > for the open source commity, hosting I think more than 16000 projects > > on their servers, which sort of explains why they are a bit slow > > sometimes. > > Until I read > http://mailman.fsfeurope.org/pipermail/announce/2001-November/28.h >tml>, I too held that opinion, too. Now, I think one should be more careful > about where to place projects (savannah.gnu.org, maybe?). OK. I think that we should ideally have a Debian portal providing source-forge like functionality (maybe with this GNU package of software). I am sure that we will soon have many such portals to choose from, but I would prefer to host Portslave, Bonnie++, Postal, and my other projects on a Debian based site. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
