Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008, Colin Watson wrote: This isn't true if you just let the patch be applied by dpkg-source -x, since the timestamp-handling bug I mentioned earlier was fixed. It might be true if you use a less capable patching system. ;-) Eh you and me know I was referring to dpatch, simple patchsys, and quilt which suffer from this AFAIK. :) I guess we could fix the patch systems to be as capable indeed. Also, automake/autoconf/aclocal might be triggerred while e.g. some m4 macros aren't installed on the buildd or the developer's system. Of course these are usually shipped with the upstream tarballs, but are often missing/incomplete. If that is the case then the end user is going to lose out anyway when trying to modify the package. I'm not arguing that such bugs shouldn't be fixed, merely that it's a mistake to turn them into showstoppers that could potentially block more urgent upload requirements. Yes, which is a common problem which reinforces your point about the autotools suite failing to run commonly and that we shouldn't care as urgently about. To sum up, I'm with you on not making autotools breakage as important as a FTBFS, but not on the AM_MAINTAINER_MODE bits: not using AM_MAINTAINER_MODE exposes us to the fragility of autotools again (be it because of timestamp skews, upstream mistakes, or new upstream incompatibilities). I was just bitten by such an issue this morning again where upstream seems to have shipped old intltool-* files but no intltool.m4 macros, and the automatic aclocal run by the build wasn't triggering an intltoolize. This might have been triggerred with timestamp skews, but wouldn't have happened with AM_MAINTAINER_MODE in place (or would upstream have made their build run intloolize on aclocal). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
In which section should go this kernel patch package (tuxonice)?
Hi, I'm trying to make a deb of kernel patch tuxonice[1], an alternative way to suspend-to-disk and suspend-to-ram. In which section should this package go? admin? devel? What is tuxonice: TuxOnIce is most easily described as the Linux equivalent of Windows' hibernate functionality. It saves the contents of memory to disk and powers down. When the computer is started up again, it reloads the contents and the user can continue from where they left off. No documents need to be reloaded or applications reopened and the process is much faster than a normal shutdown and start up. Thanks in advance, Mattia 1 http://www.tuxonice.net/ signature.asc Description: PGP signature
Re: Writing get-orig-source targets to conform with policy
On Mon, Feb 18, 2008 at 12:30:32AM +0100, Daniel Leidert wrote: Am Sonntag, den 17.02.2008, 23:58 +0100 schrieb Bas Wijnen: [..] The get-orig-source target specifies that it must work from anywhere. Where do you read this? The policy says, that it [..] may be invoked in any directory [..]. That's what I was referring to. To my understanding, this is not a must work from anywhere. I agree, that script-calls should work from any directory. But I expect the user to run the target at a place, where the user has write permissions. I don't want to add tests and checks for this. But this would be necessary to fulfill the requirement you state. Of course the user needs write permissions. The meaning of get-orig-source is to write a file to the current directory. If the user isn't allowed to write there, trying to do this should obviously result in an error. Any sensible implementation (that is, just about any implementation except running a shell script without -e) does this automatically without the need for an explicit check. So indeed, my formulation was a bit sloppy. Sorry about that. What I meant to say was that the tarball should also be created (if the user has enough permissions) in the working directory, if that is not the top-level build directory. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
RFS: ITA: libapache-mod-layout
Dear mentors, I am looking for a sponsor for the new version 5.1-1 of my package libapache-mod-layout. It builds these binary packages: libapache2-mod-layout - Apache web page content wrapper mod_layout allows you to create a single look and feel throughout a website without using server side includes to automagically wrap pages in standard headers and footers. . It can be used to to add standard disclaimers to all of the pages on a server, add banner ads, etc. The package appears to be lintian clean. The upload would fix these bugs: 429126, 462860 * This upload fixes that apache1.x has been removed, and apache2.2 is used instead. This means changing the binary package name and changing dependencies; no more missing depends and build-depends. * This is also an adoption of an orphaned package. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libapache-mod-layout - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libapache-mod-layout/libapache-mod-layout_5.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Andreas Wenning -- Andreas Wenning [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: gnormalize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I'm very sorry for my delay, but... I forgot to subscribe the mailing list! You replied only there and I didn't noticed anything... Nice start, isn't it? :/ Anyway, thank you so much for your precious hints, I will do my best. But some doubt are still there. The source contains several tar.gz files: 0 [EMAIL PROTECTED]:/tmp/gnormalize-0.52$ ls -l *.tar.gz -rw-r--r-- 1 bzed bzed 7867 2006-12-02 21:31 Audio-CD-0.04-changed.tar.gz -rw-r--r-- 1 bzed bzed 21820 2006-12-02 21:31 CDDB_get-2.27.tar.gz -rw-r--r-- 1 bzed bzed 99599 2006-12-02 21:31 MP3-Info-1.20.tar.gz CDDB_get sounds like what's available in the libcddb-get-perl package, so you can at least remove that from the source as it doesn't make sense to ship the same source several times. Add patches if changes are needed to use the packaged lib instead of the shipped version. Probably you'll have to ask the maintainer to update it. Same for MP3-Info-1.20.tar.gz/libmp3-info-perl. Not sure about Audio-CD-0.04-changed.tar.gz due to the 'changed' in the name, if there're changes involved you probably want to integrate them in libaudio-cd-perl or find a different way. Actually, in the debianized version I've already added proper dependencies (the same indicated by you); but I left everything in the archive because I don't know what I should do with them: can/should I repackage the source? Moreover, gnormalize is a pure frontend: did I the right thing putting all needed external programs as suggestions? Should I do the same thing with libraries (now are dependencies)? From debian/TODO: Manpage for mppdec is missing If a manpage is missing - write one! Will do! Also a simple build of your package fails. [EMAIL PROTECTED]:/tmp/gnormalize-0.52$ dpkg-buildpackage -rfakeroot dpkg-buildpackage: source package gnormalize dpkg-buildpackage: source version 0.52-1 dpkg-buildpackage: source changed by Alessio Gaeta [EMAIL PROTECTED] dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. /usr/bin/make clean make[1]: Entering directory `/tmp/gnormalize-0.52' rm gnormalize.1.gz rm: cannot remove `gnormalize.1.gz': No such file or directory make[1]: *** [clean] Error 1 make[1]: Leaving directory `/tmp/gnormalize-0.52' make: *** [clean] Error 2 dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2 Strange... I actually built a (working) package, available for download on my website (unofficial, of course: http://meden.uni.cc/2007/10/21/gnormalize-per-voi/#comment-60 ). I'll give it a look. gnormalize_0.52-1.diff.gz contains a patch to the Makefile and gnormalize, I know there're different opinions about that, but I'd prefer to use a proper patches for that, using dpatch or quilt. But that's something you have to discuss with the DD who sponsors your package at the end. ... debian/rules: remove the commented dh_* calls, also remove all dh* calls which are unnecessary here (dh_strip is one example here, figuring out what else is a good way to learn what those tools do :)) I'll try it; this is my first debian-compliant package, so I'm not so confident with these tools... Thank you again (and excuse me!). - -- Alessio Gaeta http://meden.uni.cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuXwDirbk3DO+UZ0RAijHAKCofbJ6Tr5Is5qmRxmY9t7GSbS8cACgwWfS yGC2QLbXYKIEdyXeDaijL+g= =vvmV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote: On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote: On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: OTOH if the standard Debian build process jumps through unusual hoops like forcing regeneration of all the autotools files that makes it less useful as a guide for the things you'd actually want to do in the normal course of affairs. The things are pretty separate IME. The parts which do the compile after autotools have been run can easily be found in most cases. If not, then the file probably wasn't readable without running autotools either. ;-) If you're willing to do things by forcing a particular version in the general case then this sounds more like something that could be checked outside the standard package build process. No, I don't want to force a version, I want the package to force it. By forcing a version I mean doing so in the package. If you're keen on introducing this I'd suggest doing some work to see how much effort would be involved in doing so. Or do you mean I should manually transition some packages? I'm happy to Yes, that's the sort of thing I meant. We already have regular tests for things that aren't caught by the normal build processes, this could be checked in a similar fashion. We could check if an automake upgrade would produce many FTBFSs, if the packages are already build-depending on automake. However, most packages currently don't do that, and it's in the general case not possible (AFAICS) to run it for them automatically. What I'm suggesting is that if you add something out of the normal build process which regenerates autotools stuff (like an extra target in the rules file, for example) then we could test this without doing it on every single build. Personally, I expect the package to restore things to the state they were in the distribution tarball. That has been suggested, but it would mean backing up generated files which get overwritten during the build (such as config.guess and config.sub). There seems to be agreement that such backing up is not useful. My point is that I don't expect the clean target to clean with respect to anything except the upstream tarball rather than going around making things clean with respect to upstream revision control or similar. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: QA Uploade -- tkgate 1.8.7-1 - Event driven digital circuit simulator with Tcl/Tk
Hi! * Barry deFreese [EMAIL PROTECTED] [080218 02:44]: It includes a new upstream (fixes an RC bug) Would have been nice to mention which bug ;) and some significant re-packaging. It is also complaining about a large /usr/share, so I'm wondering if it should be split into a -data package or something? It was installing everything under usr/lib/pkg previously. At least a -data package should be splitted of; one could even consider to splitt of the documentation in a sepperate package. While takling about it, I don't like the places you install your the files under /usr/share. While it is okay to install stuff at /usr/share/tkgate-1.8.7, I would search for the documentation in /usr/share/doc/tkgate/. The least thing you should do is to install a symlink in /usr/share/doc/tkgate/. Uhm... and I just compiled and installed the package. It doesn't start: = $ tkgate TKGate 1.8.7 - Digital Circuit Editor and Simulator (released Jan 29 2007) [Compiled Feb 18 2008 12:30:16] Copyright (C) 1987-2007 by Jeffery P. Hansen TKGate comes with ABSOLUTELY NO WARRANTY; see 'Help...License' menu for license and warranty details. Report problems to [EMAIL PROTECTED] tkgate: 1.8.7 alex [Linux] (18-Feb-08 13:42) No localized strings for 43 messages. Use 'tkgate -v' for details. (tkgate.c, line 342) Error in startup script: couldn't read file /usr/share/tkgate-1.8.7/scripts/license.tcl: no such file or directory while executing source $sd/license.tcl (file /usr/share/tkgate-1.8.7/scripts/tkgate.tcl line 58) = Indeed, there is no /usr/share/tkgate-1.8.7/scripts/license.tcl, while the orig.tar.gz contains one. Oh, you remove it in debian/rules? Any reason for that? Looking at the rules-file, I wondered about that: # The following line is just here to make lintian happy chmod +x $(CURDIR)/debian/tkgate/usr/share/tkgate-1.8.7/scripts/tree.tcl chmod +x $(CURDIR)/debian/tkgate/usr/share/tkgate-1.8.7/scripts/elistbox.tcl While it is not a bug, I think I would have used a lintian override for that ;) Other remarks: - it build depends on tcl8.4 | tcl8.3 (and tk). AFAIK tcl8.3 is to be dropped for lenny, and tcl8.5 is the new standard tcl. So please adjust the build-depends accordingly (see mail send to debian-devel-announce a couple of days ago). - The watchfile is broken - The URL mentioned in the packages long description has been moved; please change that or drop the sentence completly (since the homepage is allread mentioned with it's own field). - debian/copyright is wrong; the files I checked under src/tkgate are gpl-2 or later. I think it should be mentioned that way (and the pointer to the common licenses adjusted). Yours sincerely, Alexander signature.asc Description: Digital signature
Re: RFS: nettee
Hi Joel, IANADD, anyways here are some comments about your sponsoring request that might be useful. First of all: On Mon, Feb 18, 2008 at 01:04:48AM -0300, Joel Franco wrote: It builds these binary packages: nettee - a network tee program It would be a good idea to include a long description of the package. Because some DDs say that they won't even consider sponsoring packages, if it is missing. Remember: Your RFS is your advertising of the work you've done. Make it interesting for others. - dget http://mentors.debian.net/debian/pool/main/n/nettee/nettee_0.1.8-3.dsc Now to your package: - debian/changelog General I'm not a fan of multiple changelog entries for one upload, but thats just my opinion. However you should note, that you need to build the package with dpkg-buildpackage -v 0.1.8 so that the other changelog entries get integrated. Otherwise the bug referenced in the first changelog entry (Initial release) will not be closed by the upload. - debian/control - lacks a Homepage header to indicate the homepage. See [1] - Description is not very descriptive. See [2] for some tipps. - debian/copyright - Some copyright holders are missing in that file - Its a good idea to include a On Debian systems the license text can be found.. notice to the license of the software, because the link in the packaging is licensed as following-text looks like it *is* for the packaging only on ordinary people IMHO. - debian/dirs is useless. You can change the installation of the binary to be install -D -m755 nettee debian/nettee/usr/bin/nettee and remove both the file and dh_installdirs. - debian/README.Debian: Hm. I'm unsure if the content is suited for README.Debian. Why? Because it seems like it has no documenting character, more beeing an advertising on how enthusiastic you are about the tool ;) I would like to hear other opinions about this, however. - debian/rules: - configure and configure-stamp target is not required by the policy and you don't need it. so you could remove it. - you could probably consider adding generating optimized binaries (e.g. -O2)? If you do, please also add support for DEB_BUILD_OPTIONS [3] - debian/watch is missing, but highly recommended. it enables tracking of new upstream versions via your QA page and even a mail notification if you want. See [4] for more information. Thats it for now. Feel free to inform me if you did changes on your package and I will have another look at it. Best Regards, Patrick [1] http://wiki.debian.org/HomepageFieldHOWTO [2] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-control [3] http://www.debian.org/doc/debian-policy/ch-files.html [4] http://wiki.debian.org/DEHS signature.asc Description: Digital signature
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: I'm trying to make a deb of kernel patch tuxonice[1], an alternative way to suspend-to-disk and suspend-to-ram. In which section should this package go? admin? devel? At first glance this is likely to be more than one package. There is the kernel-patch which would be in devel, the hibernate script which would be in admin and the user-interface which could be in utils. What is tuxonice: TuxOnIce is most easily described as the Linux equivalent of Windows' hibernate functionality. It saves the contents of memory to disk and powers down. When the computer is started up again, it reloads the contents and the user can continue from where they left off. No documents need to be reloaded or applications reopened and the process is much faster than a normal shutdown and start up. This description would probably not be enough. For example, as you said in your mail it is an alternative to the in-kernel suspend which is part of the stock Debian kernels and the uswsusp which is the user-space suspend which depends on some in-kernel features (again stock Debian kernel features). Both of these could be described as the Linux equivalent of Windows' hibernate functionality (sic). What will distinguish your package from these earlier ones? You should say this crisply in your package Description. Another thing is that there is already a package called hibernate which may cause a conflict with the version you are planning to package. Perhaps you should co-ordinate with that maintainer. That said, best wishes on your effort to package this functionality for Debian. Regards, Kapil. -- signature.asc Description: Digital signature
{done] Re: RFS: whichwayisup (new upstream release)
* Ansgar Burchardt [EMAIL PROTECTED] [080218 01:41]: I'm looking for a sponsor for the new upstream version of whichwayisup. It builds these binary packages: whichwayisup - 2D platform game with a slight rotational twist That's a nice one :) Uploaded. Yours sincerely, Alexander signature.asc Description: Digital signature
Re: RFS: thailatex (updated package)
On Feb 6, 2008 9:48 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: On Feb 6, 2008 9:23 PM, Paul Wise [EMAIL PROTECTED] wrote: I'm not so sure if this is OK, what do the texlive Debian people say? The change in the postinst looks fairly simple, perhaps it could be integrated into texlive? Again, I think that would cause kind of dangling pointer, and would make texlive-latex-base depend on thailatex for the missing part. With upstream thailatex's hat on, I agree with Norbert Preining's previous comment that it should be eventually merged into upstream babel. And that's actually thailatex's final goal. *ping* Would this be OK? Should it be uploaded? Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: In which section should go this kernel patch package (tuxonice)?
On Mon, 18 Feb 2008 18:42:32 +0530 Kapil Hari Paranjape [EMAIL PROTECTED] wrote: At first glance this is likely to be more than one package. There is the kernel-patch which would be in devel, the hibernate script which would be in admin and the user-interface which could be in utils. I'm trying to package only the kernel patch; the hibernate and tuxonice-userui programs are already packaged in debian. This description would probably not be enough. For example, as you said in your mail it is an alternative to the in-kernel suspend which is part of the stock Debian kernels and the uswsusp which is the user-space suspend which depends on some in-kernel features (again stock Debian kernel features). Both of these could be described as the Linux equivalent of Windows' hibernate functionality (sic). You are right, I copy-and-pasted from the homepage. But honestly, the first time I read it, I understood what this package was about. At least it's clear. Should I change it?. This is what it's in the package description. In the README.Debian I'll put all the features of this package. Another thing is that there is already a package called hibernate which may cause a conflict with the version you are planning to package. Perhaps you should co-ordinate with that maintainer. I'm not trying to package the hibernate script; only the kernel patch for debian linux source. I talked with the hibernate package maintainer and he was so kind to check my debian package. One question was about in which section should this package go. And here we go. So it should be devel, right? That said, best wishes on your effort to package this functionality for Debian. Regards, Kapil. Thank you very much, Mattia signature.asc Description: PGP signature
Re: RFS: QA Uploade -- tkgate 1.8.7-1 - Event driven digital circuit simulator with Tcl/Tk
Alexander Schmehl wrote: Hi! * Barry deFreese [EMAIL PROTECTED] [080218 02:44]: It includes a new upstream (fixes an RC bug) Would have been nice to mention which bug ;) Sorry, will do, next time. and some significant re-packaging. It is also complaining about a large /usr/share, so I'm wondering if it should be split into a -data package or something? It was installing everything under usr/lib/pkg previously. At least a -data package should be splitted of; one could even consider to splitt of the documentation in a sepperate package. While takling about it, I don't like the places you install your the files under /usr/share. While it is okay to install stuff at /usr/share/tkgate-1.8.7, I would search for the documentation in /usr/share/doc/tkgate/. The least thing you should do is to install a symlink in /usr/share/doc/tkgate/. Fair enough. Uhm... and I just compiled and installed the package. It doesn't start: = $ tkgate TKGate 1.8.7 - Digital Circuit Editor and Simulator (released Jan 29 2007) [Compiled Feb 18 2008 12:30:16] Copyright (C) 1987-2007 by Jeffery P. Hansen TKGate comes with ABSOLUTELY NO WARRANTY; see 'Help...License' menu for license and warranty details. Report problems to [EMAIL PROTECTED] tkgate: 1.8.7 alex [Linux] (18-Feb-08 13:42) No localized strings for 43 messages. Use 'tkgate -v' for details. (tkgate.c, line 342) Error in startup script: couldn't read file /usr/share/tkgate-1.8.7/scripts/license.tcl: no such file or directory while executing source $sd/license.tcl (file /usr/share/tkgate-1.8.7/scripts/tkgate.tcl line 58) = Indeed, there is no /usr/share/tkgate-1.8.7/scripts/license.tcl, while the orig.tar.gz contains one. Oh, you remove it in debian/rules? Any reason for that? Gah, that's new. I ripped it out because lintian was complaining that it was an extra license file. Looking at the rules-file, I wondered about that: # The following line is just here to make lintian happy chmod +x $(CURDIR)/debian/tkgate/usr/share/tkgate-1.8.7/scripts/tree.tcl chmod +x $(CURDIR)/debian/tkgate/usr/share/tkgate-1.8.7/scripts/elistbox.tcl While it is not a bug, I think I would have used a lintian override for that ;) Other remarks: - it build depends on tcl8.4 | tcl8.3 (and tk). AFAIK tcl8.3 is to be dropped for lenny, and tcl8.5 is the new standard tcl. So please adjust the build-depends accordingly (see mail send to debian-devel-announce a couple of days ago). Yeah, I wondered about that, thanks. - The watchfile is broken Hmm, I had it working. I'll check that too. - The URL mentioned in the packages long description has been moved; please change that or drop the sentence completly (since the homepage is allread mentioned with it's own field). Grr, I thought I removed that. - debian/copyright is wrong; the files I checked under src/tkgate are gpl-2 or later. I think it should be mentioned that way (and the pointer to the common licenses adjusted). I thought I left the link to GPL? Yours sincerely, Alexander Thanks for looking at this! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: On Mon, 18 Feb 2008 18:42:32 +0530 Kapil Hari Paranjape [EMAIL PROTECTED] wrote: At first glance this is likely to be more than one package. There is the kernel-patch which would be in devel, the hibernate script which would be in admin and the user-interface which could be in utils. I'm trying to package only the kernel patch; the hibernate and tuxonice-userui programs are already packaged in debian. I misunderstood. So it should be devel, right? Right. I think the remaining linux-patch-* packages are in devel too! By the way, you should figure out whether your patch is compatible with the default (patched) debian linux source or it needs the upstream linux sources. It will need to be applied and compiled accordingly. Regards, Kapil. -- signature.asc Description: Digital signature
Re: In which section should go this kernel patch package (tuxonice)?
On Mon, 18 Feb 2008 19:53:02 +0530 Kapil Hari Paranjape [EMAIL PROTECTED] wrote: Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: So it should be devel, right? Right. I think the remaining linux-patch-* packages are in devel too! This is what I thought! But when I searched in the debian archive I found: linux-patch-aufs: Section: misc linux-patch-bootsplash: Section: graphics linux-patch-debian-2.6.24: Section: devel linux-patch-debianlogo: Section: devel linux-patch-evms: Section: admin linux-patch-gcov: Section: devel linux-patch-openswan: Section: net linux-patch-skas: Section: devel That's why it was not much clear for me. By the way, you should figure out whether your patch is compatible with the default (patched) debian linux source or it needs the upstream linux sources. It will need to be applied and compiled accordingly. This patch will be compatible only with linux-source, that is the kernel with Debian patches already applied. Regards, Kapil. -- Again, thank you for your advices. Bye, Mattia. signature.asc Description: PGP signature
Re: In which section should go this kernel patch package (tuxonice)?
Hello, On Mon, 18 Feb 2008, Mattia Oss wrote: This is what I thought! But when I searched in the debian archive I found: linux-patch-aufs: Section: misc linux-patch-bootsplash: Section: graphics linux-patch-debian-2.6.24:Section: devel linux-patch-debianlogo: Section: devel linux-patch-evms: Section: admin linux-patch-gcov: Section: devel linux-patch-openswan: Section: net linux-patch-skas: Section: devel Interesting! It looks like my suggestion was not quite correct. It is also strange that bootsplash is in graphics but debianlogo is in devel! So admin seems to be a reasonable section as well. This patch will be compatible only with linux-source, that is the kernel with Debian patches already applied. That's nice. It means that one doesn't have to give up any of the other Debian features to obtain this feature. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: QA Uploade -- tkgate 1.8.7-1 - Event driven digital circuit simulator with Tcl/Tk
Hi! * Barry deFreese [EMAIL PROTECTED] [080218 15:17]: [ license.tcl ] Oh, you remove it in debian/rules? Any reason for that? Gah, that's new. I ripped it out because lintian was complaining that it was an extra license file. Ah, makes sense to remove it then, but a lintian override would be the better way :) - The watchfile is broken Hmm, I had it working. I'll check that too. Please check that; it seems that my internet connection is quite flicky currently; maybe it was just a problem on my side. - debian/copyright is wrong; the files I checked under src/tkgate are gpl-2 or later. I think it should be mentioned that way (and the pointer to the common licenses adjusted). I thought I left the link to GPL? IIRC (I allready removed your package and am to lazy to download it again), debian/copyright say it's GPL without any version. Which would mean, that I can choose any Version I like including GPL-1. However the sourcecode say, it's GPL-2 or later. IIRC debian/copyright points to /usr/share/common-licenses/GPL, which is a link to GPL-3. So you can either decide, that we distribute it under the GPL-3, than the link would be correct, but the text should be adjusted, or decide that GPL-2 or later fits out needs as well, but then you would need to adjust the text and the link to point to /usr/share/common-licenses/GPL-2. Yours sincerely, Alexander signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote: On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote: On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote: If you're willing to do things by forcing a particular version in the general case then this sounds more like something that could be checked outside the standard package build process. No, I don't want to force a version, I want the package to force it. By forcing a version I mean doing so in the package. Then I still don't understand your statement above. What is the thing that you prefer to check outside the normal build process? If you're keen on introducing this I'd suggest doing some work to see how much effort would be involved in doing so. Or do you mean I should manually transition some packages? I'm happy to Yes, that's the sort of thing I meant. Ok, I'll see what I can do. I repeat my request for packages which may be hard to transition. If I get none of those, I'll just pick some random packages from the archive which currently build-depend on autotools-dev. It would be nice to have some consensus that my transition efforts are not wasted though. So I have a question: Does everyone agree that it would in theory be better to run autotools during the build process? In other words, if you don't have to do anything to your packages for it, would you have a problem with this? (you above is addressed to anyone reading this.) We already have regular tests for things that aren't caught by the normal build processes, this could be checked in a similar fashion. We could check if an automake upgrade would produce many FTBFSs, if the packages are already build-depending on automake. However, most packages currently don't do that, and it's in the general case not possible (AFAICS) to run it for them automatically. What I'm suggesting is that if you add something out of the normal build process which regenerates autotools stuff (like an extra target in the rules file, for example) then we could test this without doing it on every single build. I still consider not building from source to be a Bad Thing, and therefore I think this is the wrong approach. The best argument I've heard so far, is we care more about other bugs, and we want to be able to ignore those. However, I don't really think this is a big problem. The program was tested with the same automake version that it is built with. Why would it suddenly FTBFS? I can see that it might do so while doing the transition to running autotools during the build. But that's the maintainer's problem. They can take their time (or ask me for help :-) ). It's not a big problem if they delay following my proposed rule. Once they have changed their rules files, things should just keep working. And if it doesn't, a dirty workaround of not running autotools can always be installed, if fixing whatever problem does come up seems to be too hard. Build-depending on versioned automake doesn't look really nice, though. This is how it currently should be done, AFAIK, but it might be better to recommend against it. However, in that case great care must be taken when increasing its version, similar to increasing the default gcc version. All this can easily be tested before actually starting the transition, though, just like with gcc. Bugs can be filed and fixed to make packages work with the newer automake before it becomes the default. Transitions may be some work, but they shouldn't result in too much breakage. And if the RMs don't like it, and want us to spend time on other bugs, they can just say the newer automake will not be the default for the next release, therefore bugs with it are not RC. Personally, I expect the package to restore things to the state they were in the distribution tarball. That has been suggested, but it would mean backing up generated files which get overwritten during the build (such as config.guess and config.sub). There seems to be agreement that such backing up is not useful. My point is that I don't expect the clean target to clean with respect to anything except the upstream tarball rather than going around making things clean with respect to upstream revision control or similar. So you don't want to remove files which are unchanged during the build. Do you agree on removing all files which were changed though? I think even that would require rerunning of some autotools parts in some cases, but I'm not sure. And just that statement, all changed files should be removed by the clean target, is enough to fix the bug we're talking about. This rule automatically makes two builds in a row give identical results (except for time stamps). Of course this is a separate point. IMO clean should remove any file which was changed during the build. And secondly, I think build should regenerate everything it can. Combined, these can be formulated as clean should
The get-orig-source target as stated in Policy 4.9
I've been told that the policy for the get-orig-source target states that it ...fetches the most recent version of the original source package However, I've seen others using the get-orig-source target to regenerate the orig tarball for their packages at a particular version. I've been doing this as well. Some packages doing this are warsow, ogre, fretsonfire, bulletml, and warzone2100. So my question is, when Policy states the most recent version, is it the most recent version _in Debian_ or the most recent version _upstream_? Even if it doesn't mean the most recent version _in Debian_, I think it's important to supply a target or some other implementation to generate an orig tarball for packages at a particular version where upstream doesn't supply a clear upstream source package. Packages in experimental and packages whose source comes from svn, git, etc. are examples of when some implementation should be supplied. Look at warzone2100 for an example. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The get-orig-source target as stated in Policy 4.9
Am Montag, den 18.02.2008, 11:54 -0500 schrieb Andres Mejia: I've been told that the policy for the get-orig-source target states that it ...fetches the most recent version of the original source package However, I've seen others using the get-orig-source target to regenerate the orig tarball for their packages at a particular version. I've been doing this as well. Some packages doing this are warsow, ogre, fretsonfire, bulletml, and warzone2100. So my question is, when Policy states the most recent version, is it the most recent version _in Debian_ or the most recent version _upstream_? Even if it doesn't mean the most recent version _in Debian_, I think it's important to supply a target or some other implementation to generate an orig tarball for packages at a particular version where upstream doesn't supply a clear upstream source package. Packages in experimental and packages whose source comes from svn, git, etc. are examples of when some implementation should be supplied. Look at warzone2100 for an example. Well, overwrite the related variables in debian/rules via command line: debian/rules get-orig-source VERSION=x.y SVNVER= to get a source package for a given point. And determine these variables for the current version in Debian e.g. via hardcoding the variables in debian/rules or (IMO much better) by parsing debian/changelog (dpkg-parsechangelog). So you can get an older version, the one in Debian or even the most recent. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xiterm+thai
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package xiterm+thai. * Package name: xiterm+thai Version : 1.07-1 Upstream Author : Vuthichai Ampornaramveth [EMAIL PROTECTED], Theppitak Karoonboonyanan [EMAIL PROTECTED] * URL : ftp://linux.thai.net/pub/thailinux/software/xiterm+thai/ * License : GPL-2 Section : x11 It builds these binary packages: xiterm+thai - X terminal program with Thai languague support The package appears to be lintian clean. The upload would fix these bugs: 465713 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/x/xiterm+thai - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.07-1.dsc I would be glad if someone uploaded this package for me. Kind regards - -- Neutron Soutmun http://wiki.debian.org/NeutronSoutmun -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHucQC1k7Ar9TO/TcRAv8SAJ9T7n7jEBbo6Rov5lgrHLh1zrUOTwCbBspw fNmTQKIsbwwcM1qK5qTFmKs= =OGvY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP takeover?
Hi David, 2008/2/17, David Paleino [EMAIL PROTECTED]: Can't we propose him to upload it to experimental? That wouldn't hurt unstable (thus also testing -- and stable) users, but we could still have Code::Blocks inside Debian repositories. As he told me, he doesn't believe on 2.8 version but he believes in the 3.0version in the near future. I think he wouldn't be interested about having a lot of work on a version he doesn't see as stable enough just to let it go to experimental which is a version only used or even known by people who are really testing softwares. Fully agree w.r.t. respecting upstream's decisions (ando also other maintainers') So do I, for two reasons: - He knows better than me the real situation of the softwares he have been involved for so much time. - I really want to help Debian because I am very grateful to this distro. It worths nothing to start fighting other members which are helping Debian for more time than me. Again, why don't you propose it for experimental? I really don't think it is a good idea as I told you before. I am conformed to wait though it is not my point-of-view. I'm currently using packages provided by the Code::Blocks team itself, plus the wxWidgets from wxwidgets.org: deb http://jens.lody.name/debian/ any main deb-src http://jens.lody.name/debian/ any main deb http://apt.wxwidgets.org/ etch-wx main My packages were based upon their job but the developers made those only to let Debian users to have a package. To create a package is completely different of that package be in conformance to all Debian standards and able to go to the repositories. That's why so much work. Before your reply we were planning on team-maintaining Code::Blocks -- if it was the case. What do you think about this? (again: I'm talking about an experimental package -- not unstable as its dependencies wouldn't be satisfied in Debian at the moment) Maintaining a package in the repositories is not a hard job. There is always someone looking forward to be a maintainer. It is not something that one doesn't need too much help except by some rare cases. So the only reasons for me not uploading it into the repositories are the problems already related. Anyway I really appreciate you are in a hurry to have Code::Blocks on the repositories too. I have been using it and I am very fan of the project. I really believe it will be very good to Debian and to Code::Blocks itself. If you still will be so helpful at the moment of some change of the actual blocks then write to me again so we can always help each other and the whole community. I think future communications from now on should be made without cc to mentors and to the ITP bug hence we don't fill Debian systems with things we can not be helped anyway. Best regards, Erick Mattos.
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: Let's compare it with a Java program. Would you consider it acceptable for the packager to build it, uuencode it, put it in the diff.gz and from debian/rules just uudecode it, instead of regenerating it? Well, I see one big difference. I often get patches from downstream to configure. I, of course, make sure to apply them to the appropriate .am (or whatever), as well as forwarding them upstream. But to me, this indicates that downstream often considers the configure file to be a readable source format. This cannot be said of a uuencoded binary. I think that's an important distinction. Whether that distinction is sufficient to justify a different set of rules, I reserve judgement on at this time. But honestly, I think our job is to deliver full source and binaries. I _don't_ think we necessarily have to exercise every bit of the source (e.g. the .am files) on every build. In fact, my primary objections to the java example would be a) that it confounds user expectations, and b) that it would result in huge diffs. I'm not sure that either of those objections would apply to the autoconf case. The fact that there exist packages which work properly without recompiling from source doesn't mean it's a good default. IMO the default should be to always compile from source. Yes, that means hassle for the packager; it's pretty much the whole task of packaging. I think there's a big difference between recompiling from source as an end user would do and (re)generating _everything_ as an upstream might do. I suspect the ultimate question here is: does Debian serve as a) a proxy for the user, generating binaries so they don't have to, or b) as a proxy for upstream? I tend to lean towards the former position; it sounds like you lean towards the latter. Bottom line: it sounds like you think the java example is fundamentally wrong; I merely see it as flawed, awkward and hard to maintain: a bad idea in general, but not necessarily wrong. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 18, 2008 at 05:03:24PM +0100, Bas Wijnen wrote: On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote: On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote: No, I don't want to force a version, I want the package to force it. By forcing a version I mean doing so in the package. Then I still don't understand your statement above. What is the thing that you prefer to check outside the normal build process? That we can regenerate the autotools products. not wasted though. So I have a question: Does everyone agree that it would in theory be better to run autotools during the build process? In other words, if you don't have to do anything to your packages for it, would you have a problem with this? If I didn't have to do anything - but the maintainer is at least going to have to upload changes to run autotools. Build-depending on versioned automake doesn't look really nice, though. This is how it currently should be done, AFAIK, but it might be better to recommend against it. However, in that case great care must be taken when increasing its version, similar to increasing the default gcc version. Of course, doing this introduces all the work that was causing people to raise concerns about this... Of course this is a separate point. IMO clean should remove any file which was changed during the build. And secondly, I think build should regenerate everything it can. Combined, these can be formulated as clean should remove all non-source files, because every shipped non-source file must be updated (and thus changed) by the build. Right, half the thing for me is that I don't see this as being something that we need to check on each and every single build. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: tcpser (updated package) (try 3)
Dear mentors, I am looking for a sponsor for my updated package tcpser. * Package name: tcpser Version : 1.0rc12-1 Upstream Author : Jim Brain [EMAIL PROTECTED] * URL : http://www.jbrain.com/pub/linux/serial * License : GPL Section : net It builds these binary packages: tcpser - emulate a Hayes compatible modem TCPSER turns a PC serial port into an emulated Hayes compatible modem that uses TCP/IP for incoming and outgoing connections. It can be used to allow older applications and systems designed for modem use to operate on the Internet. TCPSER supports all standard Hayes commands, and understands extended and vendor proprietary commands (though it does not implement many of them). TCPSER can be used for both inbound and outbound connections. The package is lintian/pbuilder clean, except for a source-contains-svn-control-dir warning which I have been advised to ignore. The package can be found in the collab-maint bzr repository at: bzr co http://bzr.debian.org/collab-maint/tcpser/unstable/ tcpser You can also get the dsc from dget http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc12-1.dsc I would be glad if someone uploaded this package for me. Thanks, -- Peter signature.asc Description: Digital signature
RFS: plywood (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.5.11-1 of my package plywood. It builds these binary packages: plywood- Playwriting typing and typesetting help The package appears to be lintian clean. The upload would fix these bugs: 213112, 446178 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/plywood - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plywood/plywood_0.5.11-1.dsc I would be glad if someone uploaded this package for me. Kind regards Monty Taylor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: vagalume
Dear mentors, I am looking for a sponsor for my package vagalume. * Package name: vagalume Version : 0.5.1-2 Upstream Author : Alberto Garcia [EMAIL PROTECTED] * URL : https://garage.maemo.org/projects/vagalume * License : GNU GPLv3 Section : sound It builds these binary packages: vagalume - GTK+-based client for the Last.fm online radio service The package appears to be lintian clean. The upload would fix these bugs: 464169 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vagalume - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vagalume/vagalume_0.5.1-2.dsc I would be glad if someone uploaded this package for me. -- Alberto García González http://people.igalia.com/berto/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nettee
On Feb 18, 2008 9:28 PM, Patrick Schoenfeld [EMAIL PROTECTED] wrote: - dget http://mentors.debian.net/debian/pool/main/n/nettee/nettee_0.1.8-3.dsc Some additional comments: Now to your package: - debian/changelog s/rewrited/rewritten/ - debian/copyright Please move Copyright (C) 2007 David Mathog onto a line on its own and remove the weird angle brackets. The software is GPL2 only, not GPL2 or later. - debian/README.Debian: Hm. I'm unsure if the content is suited for README.Debian. Why? Because it seems like it has no documenting character, more beeing an advertising on how enthusiastic you are about the tool ;) I would like to hear other opinions about this, however. I agree, perhaps this could be placed in the upstream README? - debian/rules: You don't build it with -D_LARGEFILE64_SOURCE, why is that? It would be good if there were a commented out DH_VERBOSE line in there to enable easy debugging of debian/rules. It would be good if you could write a Makefile with the following targets and send it upstream: all or build, clean, install, dist. Be sure to support CFLAGS, PREFIX and DESTDIR in your Makefile since debian/rules will need them. For extra points it should support checking for solaris and compiling appropriately (see the comments in nettee.c). - debian/watch is missing, but highly recommended. it enables tracking of new upstream versions via your QA page and even a mail notification if you want. See [4] for more information. debian/docs: No need to distribute empty files nor a HTML copy of the manual page. If you want to distribute the pdist scripts, you should at least customize them by using the right path to nettee. You can do this with either sed or a patch system like quilt. Upstream includes the binary in the tarball, please ask them to fix that. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: NMU: libauthen-smb-perl - SMB authentication module for Perl
Hi, Could someone please review/upload the following: http://mentors.debian.net/debian/pool/main/l/libauthen-smb-perl/libauthen-smb-perl_0.91-3.1.dsc Should close #432809 though I'm not sure it is the best/full solution. Description: SMB authentication module for Perl This package supplies a perl module for authenticating against an SMB password server. Tag: devel::lang:perl, devel::library, filetransfer::smb, implemented-in::perl, protocol::smb, security::authentication Thank you, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xiterm+thai
Dear mentors, I am looking for a sponsor for my package xiterm+thai. * Package name: xiterm+thai Version : 1.07-1 Upstream Author : Vuthichai Ampornaramveth [EMAIL PROTECTED] [EMAIL PROTECTED], Theppitak Karoonboonyanan [EMAIL PROTECTED] [EMAIL PROTECTED] * URL : ftp://linux.thai.net/pub/thailinux/software/xiterm+thai/ * License : GPL-2 Section : x11 It builds these binary packages: xiterm+thai - X terminal program with Thai languague support The package appears to be lintian clean. The upload would fix these bugs: 465713 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xiterm+thai - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.07-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Neutron Soutmun http://wiki.debian.org/NeutronSoutmun
Re: The get-orig-source target as stated in Policy 4.9
Hi! * Andres Mejia [EMAIL PROTECTED] [080218 17:54]: I've been told that the policy for the get-orig-source target states that it ...fetches the most recent version of the original source package However, I've seen others using the get-orig-source target to regenerate the orig tarball for their packages at a particular version. I've been doing this as well. Some packages doing this are warsow, ogre, fretsonfire, bulletml, and warzone2100. And I've people jumping a red light. That doesn't mean that it's legal ;) So my question is, when Policy states the most recent version, is it the most recent version _in Debian_ or the most recent version _upstream_? Well... beside that getting the most recent version in Debian would be quite boring (just fetch it from a mirror and compare a checksum), I don't know how policy section 4.9 could be read to mean something else than the most recent upstream version: = 4.9 Main building script: debian/rules [..] get-orig-source (optional) This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. [..] = Nowhere in this paragraph is Debian or it's archive mentioned; and while it mentiones the term source package it specifically mentions the original source package, and the original is made by upstream, isn't it? Even if it doesn't mean the most recent version _in Debian_, I think it's important to supply a target or some other implementation to generate an orig tarball for packages at a particular version where upstream doesn't supply a clear upstream source package. Packages in experimental and packages whose source comes from svn, git, etc. are examples of when some implementation should be supplied. Look at warzone2100 for an example. You are free to create any debian/rules target you like, as long as the ones mentioned in policy do wha is defined there. Why not define a new get-this-orig-source or something like that? (I still fail to see, when you would like to use such a target.) Yours sincerely, Alexander signature.asc Description: Digital signature
RFS: ITA: ksocrat
Dear mentors, I am looking for a sponsor for my package ksocrat (ITA, see bug #321596). * Package name: ksocrat Version : 3.2.1-3 Upstream Author : Zavolzhsky Alexandr [EMAIL PROTECTED] * URL : http://ksocrat.linux.kiev.ua/ * License : GPLv2 or later Section : contrib/text It builds these binary packages: ksocrat- English/Russian and Russian/English Dictionary The package appears to be lintian clean. The upload would fix these bugs: 321596, 466418 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/k/ksocrat - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/k/ksocrat/ksocrat_3.2.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards Matvey Kozhev signature.asc Description: This is a digitally signed message part.
Re: The get-orig-source target as stated in Policy 4.9
On Tuesday 19 February 2008 12:21:09 am Alexander Schmehl wrote: Hi! * Andres Mejia [EMAIL PROTECTED] [080218 17:54]: I've been told that the policy for the get-orig-source target states that it ...fetches the most recent version of the original source package However, I've seen others using the get-orig-source target to regenerate the orig tarball for their packages at a particular version. I've been doing this as well. Some packages doing this are warsow, ogre, fretsonfire, bulletml, and warzone2100. And I've people jumping a red light. That doesn't mean that it's legal ;) So my question is, when Policy states the most recent version, is it the most recent version _in Debian_ or the most recent version _upstream_? Well... beside that getting the most recent version in Debian would be quite boring (just fetch it from a mirror and compare a checksum), I don't know how policy section 4.9 could be read to mean something else than the most recent upstream version: = 4.9 Main building script: debian/rules [..] get-orig-source (optional) This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. [..] = Nowhere in this paragraph is Debian or it's archive mentioned; and while it mentiones the term source package it specifically mentions the original source package, and the original is made by upstream, isn't it? Alright, let's remember that Debian Policy 4 is talking about Source Packages. If you start reading from the beginning, it becomes clear that source package signifies the source package used in Debian. This may lead to the confusion with the get-orig-source target. Furthermore, if we want to get literal about the get-orig-source policy and look at the term ...the most recent version..., then we must start factoring in development versions of packages when we consider writing the get-orig-source target. What I would like to know is, what was the original purpose for the get-orig-source target. Maybe that would clear up what the get-orig-source target is supposed to do. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The get-orig-source target as stated in Policy 4.9
Andres Mejia [EMAIL PROTECTED] writes: What I would like to know is, what was the original purpose for the get-orig-source target. Maybe that would clear up what the get-orig-source target is supposed to do. It's been in Policy from before upgrading-checklist was started and there's no mention of it in the changelog, so my guess is that you'd have to go rather far back in time to find the original discussion. Personally, I've always read it has emphasizing an entirely different part than what people are talking about here. Rather than focusing on the current version bit, I always focused on the does any necessary rearrangement to turn it into the original source tar file format described below bit. I provide this target only for my packages that require repackaging of the upstream source as a way of automating that repackaging. It's a weird target in various respects. For example, should you declare the programs it needs in Build-Depends? I don't think so, and it would feel weird to me to do so, but as a result I use software in get-orig-source for which there's no hint in the source package control file might be needed (wget is the most common). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
