Re: Managing Debian packages with Subversion
#include hallo.h * Jamin W. Collins [Fri, Aug 29 2003, 03:13:44PM]: What _stupidness_ are you refering to? I've always just used something like: svn merge http://pkg/upstream/a.b http://pkg/upstream/current trunk Always? Nice to see that it can work with three arguments and apply the changes to the working direcotry. That is something _not_ documented in the book and is easy to be overseen in the --help message. Where http://pkg/upstream/current always contains the latest version of the upstream source and http://pkg/upstream/a.b is a tag of it (svn cp) at some time in the past. I maintain http://pkg/upstream/current with svn_load_dirs. Another example of bad documented crap, without useful help messages... svn_load_dirs file:///home/user/rep-svn/svn-testing/lilo-x lilo-22.2 lilo-22.5.7.2 /usr/bin/svn_load_dirs: import_dir `lilo-22.2' is a directory. AARGH, of course it is one, I want to specify it as the current upstream dir. Enough for today, I am kinda pissed after having to deal with the way of managing svn. I think I should write all the needed commands together in the survival-guide-for-new-svn-users. MfG, Eduard. -- Solange es Haare gibt, liegen sich die Menschen in denselben. -- Heinz Erhardt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing Debian packages with Subversion
Eduard Bloch wrote: However, a possible implementation failed completely because of stupideness of svn merge. So we have to find an alternative solution with diffpatchcp. OTOH it is not possible to keep the version history of every file. I think you're looking for svn_load_dirs. -- see shy jo pgp0.pgp Description: PGP signature
Re: Managing Debian packages with Subversion
On Sat, Aug 30, 2003 at 12:33:29AM +0200, Eduard Bloch wrote: #include hallo.h * Jamin W. Collins [Fri, Aug 29 2003, 03:13:44PM]: What _stupidness_ are you refering to? I've always just used something like: svn merge http://pkg/upstream/a.b http://pkg/upstream/current trunk Always? Nice to see that it can work with three arguments and apply the changes to the working direcotry. That is something _not_ documented in the book and is easy to be overseen in the --help message. It is documented in the book, that's where I learned how to use it. http://svnbook.red-bean.com/html-chunk/ch06s04.html#svn-ch-6-sect-4.1 svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \ http://svn.example.com/repos/vendor/libcomplex/current \ libcomplex Where http://pkg/upstream/current always contains the latest version of the upstream source and http://pkg/upstream/a.b is a tag of it (svn cp) at some time in the past. I maintain http://pkg/upstream/current with svn_load_dirs. Another example of bad documented crap, without useful help messages... svn_load_dirs file:///home/user/rep-svn/svn-testing/lilo-x lilo-22.2 lilo-22.5.7.2 /usr/bin/svn_load_dirs: import_dir `lilo-22.2' is a directory. The second command line option must be a path relative to the first in the repository, not your working copy or a new directory of upstream sources. The third command line option is the first of the new upstream source directories. Again, documented fairly clearly in the book: svn_load_dirs.pl takes three mandatory arguments. The first argument is the URL to the base Subversion directory to work in. This argument is followed by the URL--relative the first argument--into which the current vendor drop will be imported. Finally, the third argument is the local directory to import. -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xemacs specific .el
On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
versions of packages no longer in any distribution
Where can I get versions of packages that are not in any distribution? E.g., I want a copy of the package opensp-1.5release-0.1, which appeared between the stable version (opensp-1.5pre5-5) and the testing version (opensp-1.5release-3). The source (.dsc and .diff.gz) is fine, I don't need the binary. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versions of packages no longer in any distribution
On Fri, Aug 29, 2003 at 08:34:41PM -0400, Neil Roeth wrote: Where can I get versions of packages that are not in any distribution? E.g., I want a copy of the package opensp-1.5release-0.1, which appeared between the stable version (opensp-1.5pre5-5) and the testing version (opensp-1.5release-3). The source (.dsc and .diff.gz) is fine, I don't need the binary. Have you tried snapshot.debian.net? All you have to know is when that version was updated, so long as that version was ever in the archive. -- Joshua Kwan pgp0.pgp Description: PGP signature
RFS: popfile -- Email classification tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I'm looking for a sponsor for the [1]popfile package I made. POPFile is an email classification tool with a Naive Bayes classifier, a POP3 proxy and a web interface. The package and source can be downloaded from my [2]site, or from [3]mentors package repository. The package is lintian clean and closes WNPP bug #203349. [1] http://popfile.sourceforge.net [2] http://www.kadath.com.ar/popfile/ [3] http://mentors.debian.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) iD8DBQE/UEuSaPMPuwG2iykRAotDAKCQSO2/fBLS5CQl1/o5dTebO5YDDQCfSCvf OCtLPvCakDxX8xy9JRsu4GM= =anss -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versions of packages no longer in any distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 30 August 2003 01:34, Neil Roeth [EMAIL PROTECTED] wrote: Where can I get versions of packages that are not in any distribution? E.g., I want a copy of the package opensp-1.5release-0.1, which appeared between the stable version (opensp-1.5pre5-5) and the testing version (opensp-1.5release-3). The source (.dsc and .diff.gz) is fine, I don't need the binary. http://snapshot.debian.net/debian/pool/main/o/opensp/ Regards, Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj9QaEMACgkQIzuKV+SHX/mn/QCfY6pyNVNH8Fig8Ofi0qTTvpNF UVMAnA54aA9s0UqNWQt2KBc4xZvTdoJB =4jui -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xemacs specific .el
On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xemacs specific .el
On Aug 30, Sven Luther ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. The install script gets called once for each flavor, and since you write that, you have total control over what it does. If foo.el is your xemacs specific script, then some test like for f in *.el; do if [ $f != foo.el ] || [ $FLAVOR != xemacs ] ... done should do it. [ No need to CC me, I'm on the list. ] -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versions of packages no longer in any distribution
On Aug 29, Joshua Kwan ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 08:34:41PM -0400, Neil Roeth wrote: Where can I get versions of packages that are not in any distribution? E.g., I want a copy of the package opensp-1.5release-0.1, which appeared between the stable version (opensp-1.5pre5-5) and the testing version (opensp-1.5release-3). The source (.dsc and .diff.gz) is fine, I don't need the binary. Have you tried snapshot.debian.net? All you have to know is when that version was updated, so long as that version was ever in the archive. Thanks! Just what I was looking for. -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xemacs specific .el
On Sat, Aug 30, 2003 at 08:57:36AM -0400, Neil Roeth wrote: On Aug 30, Sven Luther ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. The install script gets called once for each flavor, and since you write that, you have total control over what it does. If foo.el is your xemacs specific script, then some test like for f in *.el; do if [ $f != foo.el ] || [ $FLAVOR != xemacs ] ... done should do it. Ok, thanks, i will do it then. [ No need to CC me, I'm on the list. ] Then set your mail-followup-to or somethign such header correctly ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pizza-business
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 30 August 2003 15:32, Christian Surchi [EMAIL PROTECTED] wrote: Build-Depends: debhelper ( 4.0.0), libwxgtk2.4-dev (= 2.4.0.8) libstdc++3, g++, libwxbase2.4-dev libstdc++3 in build-dep? :o And of course g++ is build-essential - it should not be Build-Depended on. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj9QvXwACgkQIzuKV+SHX/n7BQCfQOzRmYnpQ/o+8pnIPaPp214x prYAmwS0Cg5RRye4WGmV2dCmAGWa8KUn =X8MG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versions of packages no longer in any distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 30 August 2003 01:34, Neil Roeth [EMAIL PROTECTED] wrote: Where can I get versions of packages that are not in any distribution? E.g., I want a copy of the package opensp-1.5release-0.1, which appeared between the stable version (opensp-1.5pre5-5) and the testing version (opensp-1.5release-3). The source (.dsc and .diff.gz) is fine, I don't need the binary. http://snapshot.debian.net/debian/pool/main/o/opensp/ Regards, Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj9QaEMACgkQIzuKV+SHX/mn/QCfY6pyNVNH8Fig8Ofi0qTTvpNF UVMAnA54aA9s0UqNWQt2KBc4xZvTdoJB =4jui -END PGP SIGNATURE-
Re: xemacs specific .el
On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. Friendly, Sven Luther
Re: xemacs specific .el
On Aug 30, Sven Luther ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. The install script gets called once for each flavor, and since you write that, you have total control over what it does. If foo.el is your xemacs specific script, then some test like for f in *.el; do if [ $f != foo.el ] || [ $FLAVOR != xemacs ] ... done should do it. [ No need to CC me, I'm on the list. ] -- Neil Roeth
Re: xemacs specific .el
On Sat, Aug 30, 2003 at 08:57:36AM -0400, Neil Roeth wrote: On Aug 30, Sven Luther ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Yes, check the Emacs policy doc. The install scripts get passed the flavor (emacs20, emacs21, xemacs21) as the first argument, so the script can check it and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el package source if you want an example. It only works with xemacs21, and I have both xemacs21 and emacs21 installed on my machines, so I know it's working properly :-) Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. The install script gets called once for each flavor, and since you write that, you have total control over what it does. If foo.el is your xemacs specific script, then some test like for f in *.el; do if [ $f != foo.el ] || [ $FLAVOR != xemacs ] ... done should do it. Ok, thanks, i will do it then. [ No need to CC me, I'm on the list. ] Then set your mail-followup-to or somethign such header correctly ? Friendly, Sven Luther
Re: RFS: pizza-business
Il mar, 2003-08-26 alle 20:43, Laurent Fousse ha scritto: I'm seeking a sponsor for pizza-business, a pizza restaurant simulation game. This closes #180789. The package is lintian clean except for: W: pizza-business: menu-item-creates-new-section Games/Simulation /usr/lib/menu/pizza-business:2 which I think is a lintian bug (being out of sync with menu policy, correct me if I'm wrong). The package can be found here: http://www.komite.net/laurent/debian/pizza-business/ I see... Build-Depends: debhelper ( 4.0.0), libwxgtk2.4-dev (= 2.4.0.8) libstdc++3, g++, libwxbase2.4-dev libstdc++3 in build-dep? :o bye christian
Re: RFS: pizza-business
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 30 August 2003 15:32, Christian Surchi [EMAIL PROTECTED] wrote: Build-Depends: debhelper ( 4.0.0), libwxgtk2.4-dev (= 2.4.0.8) libstdc++3, g++, libwxbase2.4-dev libstdc++3 in build-dep? :o And of course g++ is build-essential - it should not be Build-Depended on. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj9QvXwACgkQIzuKV+SHX/n7BQCfQOzRmYnpQ/o+8pnIPaPp214x prYAmwS0Cg5RRye4WGmV2dCmAGWa8KUn =X8MG -END PGP SIGNATURE-
Re: RFS: pizza-business
Hi, Le Sat, Aug 30, 2003 at 04:06:24PM +0100, Paul Cupis écrivait: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 30 August 2003 15:32, Christian Surchi [EMAIL PROTECTED] wrote: Build-Depends: debhelper ( 4.0.0), libwxgtk2.4-dev (= 2.4.0.8) libstdc++3, g++, libwxbase2.4-dev libstdc++3 in build-dep? :o And of course g++ is build-essential - it should not be Build-Depended on. Thank you both. Those build-depends have been removed. And thanks to David Maze, the description no longer include technical details. The updated package is still on: http://www.komite.net/laurent/debian/pizza-business/ Regards, Laurent. pgpTX9nimuUvp.pgp Description: PGP signature
