Re: RFS: kst: A KDE data analysis program
On Sun, 22, Aug, 2004 at 09:48:17AM -0600, Wesley J Landaker spoke thus.. > I'm willing to sponsor it once I can get it to build cleanly. That might > mean waiting a bit for some of the kde dependancies to trickle into > unstable, but if you drop me a reminder to try again, I'll give it > another look over and help you get it uploaded. Hi, There is a KDE NMU in incoming at the moment which fixes the libopenexr issue. Could you offer me one piece of advice? Should I make the Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to make sure buildds don't waste time trying to do it with 3.3.0-1? According to my reading of policy 7.1, this is allowed [the parentheses should contain a relation from the list below followed by a version number, in the format described in Version, Section 5.6.11.]. I wasn't sure whether I could include a debian revision in the versioned depends but it looks like it to me (looking at 5.6.11). Once I've done that and tested, I'll upload final versions of the package. Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD) signature.asc Description: Digital signature
Re: RFS: kst: A KDE data analysis program
On Fri, Aug 27, 2004 at 01:35:34PM +0100, Mark Hymers wrote: [...] > There is a KDE NMU in incoming at the moment which fixes the libopenexr > issue. Could you offer me one piece of advice? Should I make the > Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to > make sure buildds don't waste time trying to do it with 3.3.0-1? [...] No, that is useless. - It does not change a thing. The buildds do not automatically evaluate Build-Depends before they download and try to build the package. They download the package, install build-dependcies (ignoring the version requirements) and only after that check whether the version requirements are fullfilled. Let me show you the different outcomes on a autobuilder with old kdelibs: * with versioned Build-Depends: buildd downloads package and tries to install kdelibs4. apt screams loudly because libopenexr0 is not available. * without versioned Build-Depends: buildd downloads package and tries to install kdelibs4. apt screams loudly because libopenexr0 is not available. The buildd administrators can *manually* set pre-dependencies to save buildd time (Dep-Wait),buttheycan do that no matter how the Build-Dependencies look like. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kst: A KDE data analysis program
On Friday 27 August 2004 06:35, Mark Hymers wrote: > On Sun, 22, Aug, 2004 at 09:48:17AM -0600, Wesley J Landaker spoke > thus.. > > > I'm willing to sponsor it once I can get it to build cleanly. That > > might mean waiting a bit for some of the kde dependancies to > > trickle into unstable, but if you drop me a reminder to try again, > > I'll give it another look over and help you get it uploaded. > There is a KDE NMU in incoming at the moment which fixes the > libopenexr issue. Could you offer me one piece of advice? Should I > make the Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> > 3.3.0-1.1)) to make sure buildds don't waste time trying to do it > with 3.3.0-1? According to my reading of policy 7.1, this is allowed > [the parentheses should contain a relation from the list below > followed by a version number, in the format described in Version, > Section 5.6.11.]. I wasn't sure whether I could include a debian > revision in the versioned depends but it looks like it to me (looking > at 5.6.11). I'm pretty sure you can, but do you really need to? I would think this would only be necessary if kdelibs4 3.3.0-1 and 3.3.0-1.1 are binary incompatible. If you know or believe that they are, go ahead and add the dependancy for 3.3.0-1.1 or greater, but that's not necessary in general. > Once I've done that and tested, I'll upload final versions of the > package. Sounds good; posts the links to your packages when you feel that they're ready and I'll take a look at them. Unfortunately, like a quantum particle, I'll be popping in and out of existance this week, but I should have time to look over your package and sponsor the upload if there are no problems in the next day or two. =) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpLb7aAiQiW0.pgp Description: signature
Re: Sponsor for a new package
On Thursday 26 August 2004 23:43, Jesus Climent wrote: > On the other hand, as a comment, if the package has never been > uploaded, it does not make sense to have several changelog entries > (2.7c-1 and 2.7c-2). They should be put together, to avoid > dpkg-buildpackage to build a .changes which will not upload the > complete sources (orig.tar.gz). While this is a good idea in general, if there is some good reason to make new revisions (i.e. for uploading different versions to mentors, for local use before a package gets into debian, etc) this can be easily handled with -sa (to always upload source) and -v (to get all necessary changelog entries) to dpkg-genchanges. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgp85nXqwJO9U.pgp Description: signature
Re: RFS: kst: A KDE data analysis program
On Fri, 27, Aug, 2004 at 02:44:27PM +0200, Andreas Metzler spoke thus.. > No, that is useless. - It does not change a thing. > > The buildds do not automatically evaluate Build-Depends before they > download and try to build the package. They download the package, > install build-dependcies (ignoring the version requirements) and only > after that check whether the version requirements are fullfilled. Ah, thanks. I need to read up more on how the buildd software works in that case (added to my TODO list). Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD) signature.asc Description: Digital signature
Re: How to remove ITP from debian.org?
On Thursday 26 August 2004 22:11, Lawrence Williams wrote: > John Buttery wrote: > >* Lawrence Williams <[EMAIL PROTECTED]> [2004-08-26 23:26:25 -0230]: > >>It is pointless to leave them open, since neither package can ever > >> be released. > > > > Am I missing something here...couldn't these packages be in > > contrib if they themselves are free, even if their dependencies > > aren't? > > python2.3-lame Depends on LAME being available ( due to patent > issues, it isn't in Debian ). And LSongs is shot, since it depends on > python2.3-lame. I think what John was saying is that both python2.3-lame and LSongs, assuming they both are free on their own, could go probably go in contrib. Users could then install those packages, but would have to get lame from somewhere else (i.e. non-free, some other repository, etc). OTOH, if getting LSongs in main was important to you (or somebody) it might make sense to strip lame support out of LSongs, and either have the features that use it disabled (probably used for ripping CD's?) or simple replace that support with support for encoding to a patent-free format like Ogg/Vorbis. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpKh5EemekxL.pgp Description: signature
Re: How to remove ITP from debian.org?
Wesley J Landaker wrote: On Thursday 26 August 2004 22:11, Lawrence Williams wrote: John Buttery wrote: * Lawrence Williams <[EMAIL PROTECTED]> [2004-08-26 23:26:25 -0230]: It is pointless to leave them open, since neither package can ever be released. Am I missing something here...couldn't these packages be in contrib if they themselves are free, even if their dependencies aren't? python2.3-lame Depends on LAME being available ( due to patent issues, it isn't in Debian ). And LSongs is shot, since it depends on python2.3-lame. I think what John was saying is that both python2.3-lame and LSongs, assuming they both are free on their own, could go probably go in contrib. Users could then install those packages, but would have to get lame from somewhere else (i.e. non-free, some other repository, etc). OTOH, if getting LSongs in main was important to you (or somebody) it might make sense to strip lame support out of LSongs, and either have the features that use it disabled (probably used for ripping CD's?) or simple replace that support with support for encoding to a patent-free format like Ogg/Vorbis. I'll consider the solutions and look into seeing if it's possible to strip LAME dependencies from it. Or at least point the user to a place where they can get the lame package. I know one popular apt source that has it ( marillat.. his is the one i built python2.3-lame against apparently lol ). Hmmm I don't worry if they're not in main. Perhaps both lsongs and python2.3-lame would be okay in contrib? Later! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Packaging Question
Hi all, I have upgraded the automake to 1.7.9 and that took care of some the errors but when i try to generate the Makefile through the configure command it gives me an error saying saying that the script file is not found which is mainboard.py . Which i think due to a path that it did not find or one of the settings related to the source directories and the destination directories. My package is based on a single Python script that i am using. Is there any one who can help me on that. Regards, Amr
How to get rid of an epoch?
I'm doing a little houskeeping before sarge releases. Then I stumble upon this: Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new version (1.6-2) targeted at unstable. For some reason (the changelog doesn't help much), the previous maintainer used an epoch at some point and I would like to get rid of it. What's the best way to do it? Thanks in advance! -- .''`. Resistance is futile. You will be componentized. : :' : `. `' Proudly running Debian GNU/Linux (Sid 2.6.6 Ext3) `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get rid of an epoch?
On Fri, 2004-08-27 at 16:38, Amaya wrote: > I'm doing a little houskeeping before sarge releases. > Then I stumble upon this: > > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new >version (1.6-2) targeted at unstable. > > For some reason (the changelog doesn't help much), the previous > maintainer used an epoch at some point and I would like to get rid of > it. What's the best way to do it? > If I recall correctly, an epoch cannot be removed or else people with the epoch packages will never have a sane upgrade path. ie: say they have 1:1.6-1 and you remove the epoch in future uploads. That epoch will keep it a higher version than your new uploads and prevent upgrades without the sysadmin doing it manually. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
Re: How to get rid of an epoch?
* Chris Anderson <[EMAIL PROTECTED]> [2004-08-27 17:02:43 -0400]: > If I recall correctly, an epoch cannot be removed or else people with > the epoch packages will never have a sane upgrade path. Exactly. Someone has only one chance: upstream reasons; they change name, so package name has to be changed as well and thus epoch can be forgotten. - Laszlo/GCS signature.asc Description: Digital signature
Re: How to get rid of an epoch?
On Fri, Aug 27, 2004 at 10:38:15PM +0200, Amaya wrote: > I'm doing a little houskeeping before sarge releases. > Then I stumble upon this: > > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new >version (1.6-2) targeted at unstable. > > For some reason (the changelog doesn't help much), the previous > maintainer used an epoch at some point and I would like to get rid of > it. What's the best way to do it? You can't unless you rename the package. That's why the use of epoch's is strongly discouraged unless absolutely necessary. -- Blast you and your estrogenical treachery! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
For Howell's Shop Customers!
Dear customer! We updated our programs list, and now we offer you more new software items Visit our full catalog and check new software titles here: http://www.softbetterone.info/?classic With best regards, Product Manager Mitchell Bolden
request for help with subversion 1.1.0-rc2 Debian packages
Dear People,
I've tried my hand at building Subversion 1.1.0-rc2 packages. I've
imitated the packaging of the official Debian packages as far as possible.
Whenever possible I applied the Debian patches. However, since I don't
understand exactly what I am doing, I suppose some breakage was
inevitable.
The main thing that failed were the swig bindings. So the python and perl
binding packages, namely python2.3-subversion and libsvn-core-perl
packages are empty. However, subversion itself passed all tests. I haven't
done much with it yet, but look forward to playing with it.
If anyone is willing to take a look I'd appreciate it. Since the only
Debian patch that did not apply cleanly was debian/paches/rpath.patch in
the source directory, this seems the most likely cause of the problem.
You can get my packages (binaries and source) by using the lines below.
deb http://www.cbcb.duke.edu/~faheem/debian/ ./
deb-src http://www.cbcb.duke.edu/~faheem/debian/ ./
I attach the patch rpath.path below. The comments are the original one by
the maintainer, David Kimdon.
Here is the relevant entry from the changelog.
* subversion/trunk/debian/patches/rpath.patch: Only change is in
build/generator/gen_base.py, where I'm really just guessing. Other
changes are just relocating the patch, and not significant.
I have a few further comments.
1) I realise that the official Debian packages will be out once the
official release has happened, but I thought it would be nice to encourage
Debian users to do some testing before the release. Like everyone else,
I'm anxious to start using fsfs. And I thought it would be good practice.
If I can get everything working properly I'll post an accouncement of this
to debian-user.
2) I think it would be a good idea if packages of subversion without the
BDB dependency could be created.
Would different versions of all the Debian packages have to be created in
that case? Ie. libapache2-svn, python2.3-subversion, subversion, libsvn0,
subversion, libsvn0-dev, subversion, subversion-tools, libsvn-core-perl.
3) I noticed all the tests that were run (as far as I could tell) were
python scripts. This may be a stupid question, but how did they work when
the python bindings were not built successfully?
Faheem.
**
* subversion-1.0.2/Makefile.in (LINK) : Remove -rpath.
(LINK_LIB) : New variable. This is what we use to link libraries.
'libtool' keys off the '-rpath' argument to know that it should create a
shared library. Removing the rpath parameter from the library link will
cause libtool to produce a convenience library (a static archive) and no
shared libs, that is not what we want. For any libraries in /usr/lib
libtool knows not to actually put the rpath into the binary.
* subversion-1.0.2/build/generator/gen_base.py (TargetLinked) : Use the
'$(LINK_LIB)' command by default.
(TargetExe) : Executables should be linked with '$(LINK)' command so
no rpath is put into the binary.
* subversion-1.0.2/build/generator/gen_make.py (Generator) : Fix the
apache module link rule to explicitly link to the necessary subversion
shared libraries.
--- subversion-1.0.2.orig/Makefile.in 2004-04-15 20:43:46.0 +0200
+++ subversion-1.0.2/Makefile.in2004-04-25 20:47:08.0 +0200
@@ -134,7 +134,8 @@
COMPILE_SWIG_JAVA = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS)
$(CFLAGS) $(SWIG_JAVA_INCLUDES) $(INCLUDES) -o $@ -c
COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS)
$(CFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS)
$(LDFLAGS) -rpath $(libdir)
+LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS)
$(LDFLAGS)
+LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS)
$(LDFLAGS) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS)
$(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module
--- subversion-1.0.2.orig/build/generator/gen_base.py 2003-10-31
09:51:39.0 +0100
+++ subversion-1.0.2/build/generator/gen_base.py2004-04-25
21:04:45.972682190 +0200
@@ -332,8 +332,8 @@
self.install = options.get('install')
self.compile_cmd = options.get('compile-cmd')
self.sources = options.get('sources', '*.c')
-self.link_cmd = options.get('link-cmd', '$(LINK)')
-
+#self.link_cmd = options.get('link-cmd', '$(LINK)')
+self.link_cmd = '$(LINK_LIB)'
self.external_lib = options.get('external-lib')
self.external_project = options.get('external-project')
self.msvc_libs = string.split(options.get('msvc-libs', ''))
@@ -382,7 +382,8 @@
self.objext = extmap['exe', 'object']
self.filename = build_path_join(self.path, name +
Re: Sponsor for a new package
Mathew is right. I have to be nicer with new people. And i should not write mails at 2AM when i am almost falling asleep and not taking more care of my language. However my points stand. DFSG are the guides by which a DD and non-DD wanting to put packages in the repository should be enlightened. There is no workaround. Either a package conforms to those guidelines or cannot enter in the repository (read main). And Raster3D does not conform. On the other hand, as a comment, if the package has never been uploaded, it does not make sense to have several changelog entries (2.7c-1 and 2.7c-2). They should be put together, to avoid dpkg-buildpackage to build a .changes which will not upload the complete sources (orig.tar.gz). J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.26|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 So much to do, so little time... --Joker (Batman)
Re: RFS: kst: A KDE data analysis program
On Sun, 22, Aug, 2004 at 09:48:17AM -0600, Wesley J Landaker spoke thus.. > I'm willing to sponsor it once I can get it to build cleanly. That might > mean waiting a bit for some of the kde dependancies to trickle into > unstable, but if you drop me a reminder to try again, I'll give it > another look over and help you get it uploaded. Hi, There is a KDE NMU in incoming at the moment which fixes the libopenexr issue. Could you offer me one piece of advice? Should I make the Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to make sure buildds don't waste time trying to do it with 3.3.0-1? According to my reading of policy 7.1, this is allowed [the parentheses should contain a relation from the list below followed by a version number, in the format described in Version, Section 5.6.11.]. I wasn't sure whether I could include a debian revision in the versioned depends but it looks like it to me (looking at 5.6.11). Once I've done that and tested, I'll upload final versions of the package. Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD) signature.asc Description: Digital signature
Re: RFS: kst: A KDE data analysis program
On Fri, Aug 27, 2004 at 01:35:34PM +0100, Mark Hymers wrote: [...] > There is a KDE NMU in incoming at the moment which fixes the libopenexr > issue. Could you offer me one piece of advice? Should I make the > Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to > make sure buildds don't waste time trying to do it with 3.3.0-1? [...] No, that is useless. - It does not change a thing. The buildds do not automatically evaluate Build-Depends before they download and try to build the package. They download the package, install build-dependcies (ignoring the version requirements) and only after that check whether the version requirements are fullfilled. Let me show you the different outcomes on a autobuilder with old kdelibs: * with versioned Build-Depends: buildd downloads package and tries to install kdelibs4. apt screams loudly because libopenexr0 is not available. * without versioned Build-Depends: buildd downloads package and tries to install kdelibs4. apt screams loudly because libopenexr0 is not available. The buildd administrators can *manually* set pre-dependencies to save buildd time (Dep-Wait),buttheycan do that no matter how the Build-Dependencies look like. cu andreas
Re: RFS: kst: A KDE data analysis program
On Friday 27 August 2004 06:35, Mark Hymers wrote: > On Sun, 22, Aug, 2004 at 09:48:17AM -0600, Wesley J Landaker spoke > thus.. > > > I'm willing to sponsor it once I can get it to build cleanly. That > > might mean waiting a bit for some of the kde dependancies to > > trickle into unstable, but if you drop me a reminder to try again, > > I'll give it another look over and help you get it uploaded. > There is a KDE NMU in incoming at the moment which fixes the > libopenexr issue. Could you offer me one piece of advice? Should I > make the Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> > 3.3.0-1.1)) to make sure buildds don't waste time trying to do it > with 3.3.0-1? According to my reading of policy 7.1, this is allowed > [the parentheses should contain a relation from the list below > followed by a version number, in the format described in Version, > Section 5.6.11.]. I wasn't sure whether I could include a debian > revision in the versioned depends but it looks like it to me (looking > at 5.6.11). I'm pretty sure you can, but do you really need to? I would think this would only be necessary if kdelibs4 3.3.0-1 and 3.3.0-1.1 are binary incompatible. If you know or believe that they are, go ahead and add the dependancy for 3.3.0-1.1 or greater, but that's not necessary in general. > Once I've done that and tested, I'll upload final versions of the > package. Sounds good; posts the links to your packages when you feel that they're ready and I'll take a look at them. Unfortunately, like a quantum particle, I'll be popping in and out of existance this week, but I should have time to look over your package and sponsor the upload if there are no problems in the next day or two. =) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpalqfxNxrXR.pgp Description: signature
Re: Sponsor for a new package
On Thursday 26 August 2004 23:43, Jesus Climent wrote: > On the other hand, as a comment, if the package has never been > uploaded, it does not make sense to have several changelog entries > (2.7c-1 and 2.7c-2). They should be put together, to avoid > dpkg-buildpackage to build a .changes which will not upload the > complete sources (orig.tar.gz). While this is a good idea in general, if there is some good reason to make new revisions (i.e. for uploading different versions to mentors, for local use before a package gets into debian, etc) this can be easily handled with -sa (to always upload source) and -v (to get all necessary changelog entries) to dpkg-genchanges. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpjsLiL3tTXo.pgp Description: signature
Re: RFS: kst: A KDE data analysis program
On Fri, 27, Aug, 2004 at 02:44:27PM +0200, Andreas Metzler spoke thus.. > No, that is useless. - It does not change a thing. > > The buildds do not automatically evaluate Build-Depends before they > download and try to build the package. They download the package, > install build-dependcies (ignoring the version requirements) and only > after that check whether the version requirements are fullfilled. Ah, thanks. I need to read up more on how the buildd software works in that case (added to my TODO list). Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD) signature.asc Description: Digital signature
Re: How to remove ITP from debian.org?
On Thursday 26 August 2004 22:11, Lawrence Williams wrote: > John Buttery wrote: > >* Lawrence Williams <[EMAIL PROTECTED]> [2004-08-26 23:26:25 -0230]: > >>It is pointless to leave them open, since neither package can ever > >> be released. > > > > Am I missing something here...couldn't these packages be in > > contrib if they themselves are free, even if their dependencies > > aren't? > > python2.3-lame Depends on LAME being available ( due to patent > issues, it isn't in Debian ). And LSongs is shot, since it depends on > python2.3-lame. I think what John was saying is that both python2.3-lame and LSongs, assuming they both are free on their own, could go probably go in contrib. Users could then install those packages, but would have to get lame from somewhere else (i.e. non-free, some other repository, etc). OTOH, if getting LSongs in main was important to you (or somebody) it might make sense to strip lame support out of LSongs, and either have the features that use it disabled (probably used for ripping CD's?) or simple replace that support with support for encoding to a patent-free format like Ogg/Vorbis. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpepvrwkVSSS.pgp Description: signature
Re: How to remove ITP from debian.org?
Wesley J Landaker wrote: On Thursday 26 August 2004 22:11, Lawrence Williams wrote: John Buttery wrote: * Lawrence Williams <[EMAIL PROTECTED]> [2004-08-26 23:26:25 -0230]: It is pointless to leave them open, since neither package can ever be released. Am I missing something here...couldn't these packages be in contrib if they themselves are free, even if their dependencies aren't? python2.3-lame Depends on LAME being available ( due to patent issues, it isn't in Debian ). And LSongs is shot, since it depends on python2.3-lame. I think what John was saying is that both python2.3-lame and LSongs, assuming they both are free on their own, could go probably go in contrib. Users could then install those packages, but would have to get lame from somewhere else (i.e. non-free, some other repository, etc). OTOH, if getting LSongs in main was important to you (or somebody) it might make sense to strip lame support out of LSongs, and either have the features that use it disabled (probably used for ripping CD's?) or simple replace that support with support for encoding to a patent-free format like Ogg/Vorbis. I'll consider the solutions and look into seeing if it's possible to strip LAME dependencies from it. Or at least point the user to a place where they can get the lame package. I know one popular apt source that has it ( marillat.. his is the one i built python2.3-lame against apparently lol ). Hmmm I don't worry if they're not in main. Perhaps both lsongs and python2.3-lame would be okay in contrib? Later!
Debian Packaging Question
Hi all, I have upgraded the automake to 1.7.9 and that took care of some the errors but when i try to generate the Makefile through the configure command it gives me an error saying saying that the script file is not found which is mainboard.py . Which i think due to a path that it did not find or one of the settings related to the source directories and the destination directories. My package is based on a single Python script that i am using. Is there any one who can help me on that. Regards, Amr
How to get rid of an epoch?
I'm doing a little houskeeping before sarge releases. Then I stumble upon this: Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new version (1.6-2) targeted at unstable. Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new version (1.6-2) targeted at unstable. For some reason (the changelog doesn't help much), the previous maintainer used an epoch at some point and I would like to get rid of it. What's the best way to do it? Thanks in advance! -- .''`. Resistance is futile. You will be componentized. : :' : `. `' Proudly running Debian GNU/Linux (Sid 2.6.6 Ext3) `- www.amayita.com www.malapecora.com www.chicasduras.com
Re: How to get rid of an epoch?
On Fri, 2004-08-27 at 16:38, Amaya wrote: > I'm doing a little houskeeping before sarge releases. > Then I stumble upon this: > > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new >version (1.6-2) targeted at unstable. > > For some reason (the changelog doesn't help much), the previous > maintainer used an epoch at some point and I would like to get rid of > it. What's the best way to do it? > If I recall correctly, an epoch cannot be removed or else people with the epoch packages will never have a sane upgrade path. ie: say they have 1:1.6-1 and you remove the epoch in future uploads. That epoch will keep it a higher version than your new uploads and prevent upgrades without the sysadmin doing it manually. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
Re: How to get rid of an epoch?
* Chris Anderson <[EMAIL PROTECTED]> [2004-08-27 17:02:43 -0400]: > If I recall correctly, an epoch cannot be removed or else people with > the epoch packages will never have a sane upgrade path. Exactly. Someone has only one chance: upstream reasons; they change name, so package name has to be changed as well and thus epoch can be forgotten. - Laszlo/GCS signature.asc Description: Digital signature
Re: How to get rid of an epoch?
On Fri, Aug 27, 2004 at 10:38:15PM +0200, Amaya wrote: > I'm doing a little houskeeping before sarge releases. > Then I stumble upon this: > > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new >version (1.6-2) targeted at unstable. > Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new >version (1.6-2) targeted at unstable. > > For some reason (the changelog doesn't help much), the previous > maintainer used an epoch at some point and I would like to get rid of > it. What's the best way to do it? You can't unless you rename the package. That's why the use of epoch's is strongly discouraged unless absolutely necessary. -- Blast you and your estrogenical treachery!
