Re: RFS: libxp-java : XML 1.0 parser for Java
W liście z sob, 29-05-2004, godz. 14:22, Arnaud Vandyck pisze: > Nicolas Duboc <[EMAIL PROTECTED]> writes: > > > On Fri, May 28, 2004 at 05:00:23PM +0200, Arnaud Vandyck wrote: > >> Nicolas Duboc <[EMAIL PROTECTED]> writes: > >> > >> Why sablevm and gij aren't alternatives for java1-runtime? (if there is > >> no reason, can I add them as alternatives? > > > >I have added kaffe on the Depend line because of the lintian warning > > "virtual-package-depends-without-real-package-depends" [1]. > > [...] > > >I don't think adding other alternatives is useful. But if I'm wrong, > > I will add it, of course. > > > > [1] > > http://lintian.debian.org/reports/Tvirtual-package-depends-without-real-package-depends.html > > I agree. I tend to add other alternatives but it's not necessary. > > I'll upload your package. > > If someone think it's useful, file a wishlist bug against libxp-java. Actually, especially in case of packages that work with free java environments I think it IS useful. You wrote: "I have chosen kaffe since I know the package perfectly works with kaffe VM and libraries. It also works with sablevm (it seems to not work on gij but I don't know yet why)." This is IMO exactly the kind of informations you want to give to a user by the Depends: alternatives. In this case you would put something like: Depends: kaffe | sablevm | java1-runtime When I see an entry like that, I expect that the maintainer tested this package with kaffe and sablevm jvms so if the package doesn't work w/ one of these anymore - it's a regression. In such case, as a JVM mantainer I'd want to hear about this regression. And I guess it might also be important for the maintainer of the package in question, as strange things happen sometime, like latest gjdoc, which works *only* with kaffe, while it used to work w/ others (but Arnaud handled it the right way). On the other hand, as a user, I treat putting names of alternative packages into Depends field as an important information, which will help me in case I had troubles running this software. Maybe I should switch to different JVM to run this app? Summarizing: in both cases - for an enduser and for jvm maintainer it is *worth* to have Depends: field describing what JVMs are expected to work. So please, include this information if you can, Grzegorz B. Prokopski PS: And, obviously, if it hasn't been tested and confirmed that a package works with some JVM, such JVM should not be explicitely listed in the Depends: field. -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM
Re: Executing with root priviliges
Eduard Bloch schrieb: > I am not sure how to implement this policy for su-replacements... Best > virtual package name? id-changer and x-id-changer? Or uid-changer? uid-changer/x-uid-changer There are many IDs out there... Ciao, Eike
RFS: gens -- Sega Genesis/CD/32X emulator
* Package name: gens Version : 2.12-rc3 Upstream Author : Stephane Akhoun * URL : http://sourceforge.net/projects/gens/ * License : GPL Description : Sega Genesis/CD/32X emulator Gens is a Sega Genesis/CD/32X emulator, originally written for Windows but ported to GTK/SDL by Stephane Akhoun. It runs most Genesis games at a reasonable speed even on slower (400MHz) systems, with a high degree of accuracy. It support save states, 2xSAI rendering, GYM music dumping, and several other features. --- Package is lintian/linda clean, built under pbuilder, available on mentoirs.debian.net. It's contrib unless there's a PD Genesis Rom in Debian that I'm unaware of, in which case I can move it over to main. I currently have it marked as i386 only due to some assembly used. I have no idea if it would also work under ia64 and amd64. ITP: http://bugs.debian.org/253095
why are these packages in testing?
Hi, I came across some strange outputs. For example: [EMAIL PROTECTED]:~$ madison aiksaurus aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc [EMAIL PROTECTED]:~$ There is a current removal suggestion by vorlon: # 20040509 # bug #241279 remove aiksaurus/1.0.1+cvs.2004.02.20-1 Why is there only the source in testing? Similar, for libapache-mod-filter, there is: [EMAIL PROTECTED]:~$ madison libapache-mod-filter libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc [EMAIL PROTECTED]:~$ but there is also a removal suggestion, and the excuses-file on ftp-master says according to http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter that this package is removed today from testing. So, why is this still there? How many hours after the generation of the excuses list are the packages really updated? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: RFS: gens -- Sega Genesis/CD/32X emulator
Argh, hold off on this, I just noticed part of this package needs to go in non-free.
Re: setting up a woody chroot for backporting
Joost van Baal <[EMAIL PROTECTED]> writes: I have very little experience with chroot-ed builds, but will spend some more time investigating. You can create a nice small chroot like this: (cdebootstrap installs less cruft then debootstrap) apt-get install cdebootstrap cdebootstrap woody /chroots/woody http://your.mirror/debian editor /chroots/woody/etc/apt/sources.list Is it me, or cdebootstrap is currently broken? # cdebootstrap woody /chroots/woody http://your.mirror/debian cdebootstrap: /usr/lib/libdebian-installer.so.4: version `LIBDI_4.3' not found (required by cdebootstrap) and it seems there's no never version of libdebian-installer than 25-really-22. Any clue? Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcin http://wfmh.org.pl/carlos/
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I finally opted for this solution. The package is ready to be uploaded, but how am I supposed to proceed now? ask for removal first and then upload or the opposite? also, is [EMAIL PROTECTED] the correct address to contact ftp-master? thanks -- mattia :wq!
Re: why are these packages in testing?
On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote: > Hi, > > I came across some strange outputs. For example: > > [EMAIL PROTECTED]:~$ madison aiksaurus > aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source > aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, > hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > > There is a current removal suggestion by vorlon: > # 20040509 > # bug #241279 > remove aiksaurus/1.0.1+cvs.2004.02.20-1 > > Why is there only the source in testing? Because 7 out of 9 binary packages of that source are still in testing: http://lintian.wolffelaar.nl/histmadison/?source=aiksaurus&package=&date=2004-06-07 Note that the testing output says removal fails due to buggyness of the package: http://packages.qa.debian.org/a/aiksaurus.html # Trying to remove package, not update it # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) # Not considered I guess the textual representation is bogus, otherwise removals can't really have worked before. > Similar, for libapache-mod-filter, there is: > [EMAIL PROTECTED]:~$ madison libapache-mod-filter > libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > but there is also a removal suggestion, and the excuses-file on > ftp-master says according to > http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter > that this package is removed today from testing. So, why is this still > there? How many hours after the generation of the excuses list are the > packages really updated? 'today' means 'just before next mirror pulse', i.e., it will be gone after tonight. Testing scripts run just after a mirror pulse, and have effect only upon next one, so there generally is a delay of about 20 hours iirc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFS: gens -- Sega Genesis/CD/32X emulator
Ok, nevermind... this package has a mess of non-free, I need some serious time to sort through what's even redistributable. Teach me to get overzealous, sheesh...
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: [...] > > Personally I'd immediately change the architecture field and change it > > back once there is a xserver for s390. - You'll probably have to > > pester ftp-master to remove the old s390 binary, otherwise > > xfree86-driver-synaptics will be blocked by "out of date on s390". > I finally opted for this solution. The package is ready to be uploaded, > but how am I supposed to proceed now? ask for removal first and then > upload or the opposite? Do both instead of waiting. There is no problem if the s390 buildd tries to build xfree86-driver-synaptics before the binary has been removed (and xfree86-driver-synaptics has been added to http://buildd.debian.org/quinn-diff/Packages-arch-specific), the build will simply fail because dpkg-buildpackage (or is it sbuild?) checks the architecture field. > also, is [EMAIL PROTECTED] the correct address to contact ftp-master? Afaict from http://www.debian.org/intro/organization yes. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: Package review and comment wanted
Bengt Thuree <[EMAIL PROTECTED]> schrieb: > Hej > > I have just created one of my first debian package, and would like to > have some comments on the actual packaging. Did you read the new maintainers guide and the developers' reference? > > Have I missed something? > I am very confused of > *) Should I only use the rules file, or a separate Makefile That depends on the complexity of the installation. In most cases, it is highly advisable to have a separate Makefile that does the compilation and installation, and in debian/rules you only call it with appropriate targets and arguments. Isn't there a Makefile in the upstream sources? > *) Should I list all the directories in the dirs (including /usr/sbin) In debian/dirs, you only list the directories that you want to create with dh_installdirs - e.g. directories that the upstream Makefiles assumes to be present upon installation, or directories to which you want to move some files in your debian/rules file - a typical example would be moving some scripts to debian/tmp/usr/share/doc/$packagename/examples. > *) Should I list the conffiles in a separate conffile? That depends on the debhelper compatibility level. Usually it is not necessary - read about it. > *) How do I automatically set the version number and perhaps a > timestamp in the program during packaging? I don't quite understand what you mean with this. Are you speaking about the output of your program when called with a "--version" option? > My package can be fetched from www.thuree.com/debian/buppo or by > simply have the following in the apt.sources > deb http://www.thuree.com/debian buppo/ > deb-src http://www.thuree.com/debian buppo/ So it does have an upstream Makefile - use it. You are packaging this as a Debian native package. You shouldn't do that, unless there is good reason why nobody outside Debian would want to use it. This is true for packages like debian-policy or apt-get (or perhaps not even for that one), but most probably not for a backup program. Consequently, you should use the manpages out of the debian directory and install them in the Makefile. You should probably look up what people mean with the difference between differential and incremental backup; it seems as if you provide both possibilities. In the description you say that it uses afio and tar, but you don't depend on tar. The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. The rules file could need some cleanup - not only removing unneeded commented lines: Do you have an idea what a CFLAG is? Why do you set it? I also had a short look over your buppo script. I don't like that you hardcode all binaries with absolute pathnames. There is a reason why the variable PATH exists, and why people use it to use different binaries. I don't know whether it's against policy, but I'd consider it bad practice. I have no idea about the usefulness of the script, and no intention to sponsor its upload, be it useful or not. I just wanted to give you some feedback. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
chugging
Carson Pollard,^
Visa Gold Promotional Offer,}
N0 Credit Check,,@
No Employment requirement,,/
N0 Finance charge,,{
No Security Depoits,,)
TO build up $1000 credit..,\
and win a car.,"
http://alphacardz.info/index.php?id=9201
,inequivalent ,capacious
,cb ,care .
RFS: libcgi-xmlapplication-perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Ragwitz wrote: | Package: libcgi-xmlapplication-perl | Severity: wishlist | | A new upstream version (currently 1.1.3) is available on cpan. Please | upgrade your package. I have uploaded the package to [EMAIL PROTECTED], so I need a sponsor for the actual upload to the Debian repository. Description: Perl module for creating XML-DOM and OO based CGI scripts ~ This module provides an XML-DOM and object-oriented extension to the ~ CGI module. The XML-DOM extension allows one to generate the output ~ from XML and laid out according to an XSLT stylesheet, separating ~ code and presentation. The object-oriented extension allows one to ~ specify handlers for events like a mouse click on a submit button or ~ on an image. The package is lintian and linda clean. Please, can somebody upload it (you might also have a look at the dmalloc package?) Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxI/m5UTeB5t8Mo0RAj8FAJsHyZwTtWeP0evbo6xRdy6HFnvlLQCglk4f 2GhNOSvsEoHuCSkKq83DlyA= =eYSF -END PGP SIGNATURE-
RFS: xpat2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I have adopted the xpat2 package. Would anybody be so kind to upload it, please? Package: xpat2 Description: Generic patience game for X11 ~ xpat2 is a generic patience game which can be used with different rule ~ sets. It does understand the rules of the well-known Spider game, as ~ well as Klondike and others. ~ . ~ This program may have difficulties to start if you have an 8-bit or ~ monochrome display. The package is lintian and linda clean (with overrides). Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxLJH5UTeB5t8Mo0RAqm7AJ4x5D0eg0EwiewpZCzZ3j2LYDvT7gCfQUDJ D7Wd8mcqNMDhKGfNjyTcf5g= =V4gz -END PGP SIGNATURE-
RFC: potracegui -- is a KDE frontend for potrace
Hi, I am quite new to packaging and just finished the initial release of potracegui. It is a KDE frontend for the potrace tracing (vectorizing) commanline tool. It enhances the commanline tool as it supports the use of any graphic format known by KDE as input. It also features the direct input of remote files (web, ftp, ...). I would appreciate any comments on the package. It is available from mentors.debian.net. Christoph
Re: RFC: potracegui -- is a KDE frontend for potrace
On Mon, Jun 07, 2004 at 09:13:18PM +0200, Christoph Wegscheider wrote: > Hi, Hello Christoph. > I am quite new to packaging and just finished the initial release of > potracegui. It is a KDE frontend for the potrace tracing (vectorizing) > commanline tool. It enhances the commanline tool as it supports the use of > any graphic format known by KDE as input. It also features the direct input > of remote files (web, ftp, ...). Nice to see that someone wants to package program that depends on my package ;) > I would appreciate any comments on the package. Ok here goes my comments: debian/changelog: You should fill ITP bug and close it with your changelog entry. http://www.debian.org/devel/wnpp/ debian/control: I'm sure that your Build-Depends header is wrong. You have to write there programs which are needed during build of that package. If it is KDE application then it certainly needs at least libqt3-mt-dev. Just try to build it in some chrooted environment. Pbuilder is great for such purposes. debian/copyright: Take a look at: http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg02190.html debian/rules: Remove unneeded comments and dh_* lines. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: RFC: potracegui -- is a KDE frontend for potrace
Bartosz Fenski aka fEnIo wrote: > debian/changelog: > > You should fill ITP bug and close it with your changelog entry. > http://www.debian.org/devel/wnpp/ Wasn't sure about this because as it is an unofficial package and maybe never get sponsered (at least not in the near future I think). I thought ITP means intention to package for official debian archive only. > debian/control: > > I'm sure that your Build-Depends header is wrong. > You have to write there programs which are needed during build of that > package. If it is KDE application then it certainly needs at least > libqt3-mt-dev. > Just try to build it in some chrooted environment. Pbuilder is great for > such purposes. Yes, I'm currently studying the appropriate policy section > debian/copyright: > > Take a look at: > http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg02190.html OK > debian/rules: > > Remove unneeded comments and dh_* lines. OK Thank you for commenting, I'll change this soon. Christoph
Re: RFC: potracegui -- is a KDE frontend for potrace
On Mon, Jun 07, 2004 at 10:16:41PM +0200, Christoph Wegscheider wrote: > > debian/changelog: > > > > You should fill ITP bug and close it with your changelog entry. > > http://www.debian.org/devel/wnpp/ > Wasn't sure about this because as it is an unofficial package and maybe > never get sponsered (at least not in the near future I think). > I thought ITP means intention to package for official debian archive only. No. ITP is mainly to not duplicate efforts. If someone fill ITP then nobody else (at least theoretical) will work on the same package. Even if you don't intend to make your package official then filling ITP is still ok. Anyone will know where to find preliminary packages. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: Package review and comment wanted
On Mon, Jun 07, 2004 at 05:17:45PM +0200, Frank K?ster wrote: > In debian/dirs, you only list the directories that you want to create > with dh_installdirs - e.g. directories that the upstream Makefiles > assumes to be present upon installation, or directories to which you > want to move some files in your debian/rules file - a typical example > would be moving some scripts to > debian/tmp/usr/share/doc/$packagename/examples. You don't use dh_installdirs for that, you use dh_installexamples. > > *) Should I list the conffiles in a separate conffile? > > That depends on the debhelper compatibility level. Usually it is not > necessary - read about it. man 7 debhelper, BTW, in the section "Debhelper compatibility levels". > > *) How do I automatically set the version number and perhaps a > > timestamp in the program during packaging? > > I don't quite understand what you mean with this. Are you speaking about > the output of your program when called with a "--version" option? The version of the debian package you produce is taken from the package's topmost changelog entry. For timestamps, you can use touch(1), but I'm having trouble coming up with why you'd want to stamp a file to a particular time... > In the description you say that it uses afio and tar, but you don't > depend on tar. No need to depend on tar, it's Essential. > The changelog entries are not really well understandable for somebody > who doesn't yet know what it's about. I wouldn't necessarily count that as a major problem -- changelog entries are for users of the package, not passers-by. Of course, if even regular users couldn't understand them, then it's time to rewrite. - Matt
Request for comments for ibwebadmin package
Hello, I am looking for comments about my packaging of ibwebadmin. Testers are also welcome. * Package name: ibwebadmin Version : 0.97 Upstream Author : Lutz Brückner <[EMAIL PROTECTED]> * URL : http://ibwebadmin.sf.net/ * License : GPL v2 Description : IBwebadmin is a web frontend for the firebird and interbase databases. The package is lintian and linda clean and builds with pbuilder. The use of yada should make things easy for reviewing (and maintaining!). It can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/i/ibwebadmin/ Cheers, Remco Seesink.
Re: Package review and comment wanted
Hej Frank, and thank you for very much appreciated comments. I will try to answer them below /Bengt Frank Küster wrote: Did you read the new maintainers guide and the developers' reference? Yes, I read them once, twice, and ten times, but must have some problem with my english apperantly. That depends on the complexity of the installation. In most cases, it is highly advisable to have a separate Makefile that does the compilation and installation, and in debian/rules you only call it with appropriate targets and arguments. ok Isn't there a Makefile in the upstream sources? Upstream this is the upstream. I created the package *) Should I list all the directories in the dirs (including /usr/sbin) In debian/dirs, you only list the directories that you want to create with dh_installdirs - e.g. directories that the upstream Makefiles Ok, but when I do not create the usr/sbin directory in the debian/dirs file the dpkg-buildpackage -rfakeroot fails with taget directory do not exist or something like this. I ended up having to put ALL my expected directories in this debian/dirs file. Then the installation went very fine. But when I tried to remove the package, it also tried to remove /usr/sbin *) How do I automatically set the version number and perhaps a timestamp in the program during packaging? I don't quite understand what you mean with this. Are you speaking about the output of your program when called with a "--version" option? Yes, the output from buppo --version. I do not as of right now anyway, use cvs or subversion to handle my revisions. But simply relying on creating a new debian package every once in a while so I have something usefull to go back to. I ended up doing a hack in the Makefile to modify the source code (which I really do not want to do) So it does have an upstream Makefile - use it. I created this Makefile as well, after some people complained that I should not try to remove /usr/sbin when they removed the package. You are packaging this as a Debian native package. You shouldn't do that, unless there is good reason why nobody outside Debian would want So, if I am the one who creates this package, should I not create the package as a Debian native package? to use it. This is true for packages like debian-policy or apt-get (or perhaps not even for that one), but most probably not for a backup program. Consequently, you should use the manpages out of the debian directory and install them in the Makefile. The Debian man pages are located in the docs folder as xml files, and compiled into man pages in the debian directory in the Makefile. You should probably look up what people mean with the difference between differential and incremental backup; it seems as if you provide both possibilities. Good point :-) In the description you say that it uses afio and tar, but you don't depend on tar. Lintian complain when I was depending upon tar. The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. True, I write them mainly for myself for the moment. The rules file could need some cleanup - not only removing unneeded commented lines: Do you have an idea what a CFLAG is? Why do you set it? From the default... I will need to check the rules file and remove some lines then. This is after all a simple bourne shell script, and no need for things to be compiled (except man pages) I also had a short look over your buppo script. I don't like that you hardcode all binaries with absolute pathnames. There is a reason why the variable PATH exists, and why people use it to use different binaries. I don't know whether it's against policy, but I'd consider it bad practice. Hmm.. perhaps. I also come from the Unix world and there it is also considered a good thing to write the paths like this. Makes it easier to change perhaps. I will consider removing the absolute paths, and trust the PATH instead. I have no idea about the usefulness of the script, and no intention to sponsor its upload, be it useful or not. I just wanted to give you some feedback. No problems... To be honest, me neither. But I am sure having fun... :) and learning a lot I really appreciated the comments though Regards, Frank Cheers bengt
Re: Package review and comment wanted
Matthew Palmer wrote: want to move some files in your debian/rules file - a typical example would be moving some scripts to debian/tmp/usr/share/doc/$packagename/examples. You don't use dh_installdirs for that, you use dh_installexamples. I managed to use this one :) *) Should I list the conffiles in a separate conffile? That depends on the debhelper compatibility level. Usually it is not necessary - read about it. man 7 debhelper, BTW, in the section "Debhelper compatibility levels". :-) Thanks, I have missed this one. The version of the debian package you produce is taken from the package's topmost changelog entry. For timestamps, you can use touch(1), but I'm having trouble coming up with why you'd want to stamp a file to a particular time... for the buppo --version output. And I think it would be handled by cvs or subversion, but for the moment I am actually using .deb as my revision control No need to depend on tar, it's Essential. Actually Lintian complains if you do... The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. I wouldn't necessarily count that as a major problem -- changelog entries are for users of the package, not passers-by. Of course, if even regular users couldn't understand them, then it's time to rewrite. I agree, the changelog entries are a bit to detailed for everyone but myself at this stage... - Matt Thanks Matt, I appreciate it /bengt
Re: Package review and comment wanted
On Tue, Jun 08, 2004 at 09:01:34AM +0900, Bengt Thuree wrote: > >The version of the debian package you produce is taken from the package's > >topmost changelog entry. For timestamps, you can use touch(1), but I'm > >having trouble coming up with why you'd want to stamp a file to a > >particular > >time... > for the buppo --version output. And I think it would be handled by cvs > or subversion, but for the moment I am actually using .deb as my > revision control OK, so you do actually want to have your version information generated automatically from your revision control stuff. I use tla for most of my ongoing development work now, and I've put scripts together to make a release for me. This includes creating a tag branch for the release, as well as automatically sorting out the version numbers in the code. (I'm actually basing my versioning off the Debian changelog, since it's a Debian-native project, but that's not important). What you could do is write a script which takes an argument of your new version number, which tags in your revision control system, does a search-n-replace with sed for inserting the current version number, and perhaps resets the debian version in debian/changelog (run something like dch -v -1). I love shell scripting. - Matt
Re: Package review and comment wanted
>>> for the buppo --version output. And I think it would be handled by cvs >> or subversion, but for the moment I am actually using .deb as my >> revision control > > OK, so you do actually want to have your version information generated > automatically from your revision control stuff. :-) That was my idea yes :-) Since I tend to forget this I wanted it to be automatically. > > I use tla for most of my ongoing development work now, and I've put > scripts > together to make a release for me. This includes creating a tag branch > for > the release, as well as automatically sorting out the version numbers in > the > code. (I'm actually basing my versioning off the Debian changelog, since > it's a Debian-native project, but that's not important). What you could > do > is write a script which takes an argument of your new version number, > which > tags in your revision control system, does a search-n-replace with sed for > inserting the current version number, and perhaps resets the debian > version > in debian/changelog (run something like dch -v -1). I ended up doing something like this in the Makefile. Taking the version number of the directory name actually, and doing the sed change in the source file. Just that I do not want to end up doing serious damage to the file itself. But I thought that perhaps the debian package building system had some features for doing this automatically. :-) Ok, I was hoping Hmm.. I think perhaps I will simply add a new one line source file in the etc directory which contains the revision data. buppo can then source this file, and this makes me feel a lot safer. > I love shell scripting. O'h yes... but I have loads to learn... > > - Matt /Bengt
Re: Executing with root priviliges
Eduard Bloch schrieb: > I am not sure how to implement this policy for su-replacements... Best > virtual package name? id-changer and x-id-changer? Or uid-changer? uid-changer/x-uid-changer There are many IDs out there... Ciao, Eike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: gens -- Sega Genesis/CD/32X emulator
* Package name: gens Version : 2.12-rc3 Upstream Author : Stephane Akhoun * URL : http://sourceforge.net/projects/gens/ * License : GPL Description : Sega Genesis/CD/32X emulator Gens is a Sega Genesis/CD/32X emulator, originally written for Windows but ported to GTK/SDL by Stephane Akhoun. It runs most Genesis games at a reasonable speed even on slower (400MHz) systems, with a high degree of accuracy. It support save states, 2xSAI rendering, GYM music dumping, and several other features. --- Package is lintian/linda clean, built under pbuilder, available on mentoirs.debian.net. It's contrib unless there's a PD Genesis Rom in Debian that I'm unaware of, in which case I can move it over to main. I currently have it marked as i386 only due to some assembly used. I have no idea if it would also work under ia64 and amd64. ITP: http://bugs.debian.org/253095 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
why are these packages in testing?
Hi, I came across some strange outputs. For example: [EMAIL PROTECTED]:~$ madison aiksaurus aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc [EMAIL PROTECTED]:~$ There is a current removal suggestion by vorlon: # 20040509 # bug #241279 remove aiksaurus/1.0.1+cvs.2004.02.20-1 Why is there only the source in testing? Similar, for libapache-mod-filter, there is: [EMAIL PROTECTED]:~$ madison libapache-mod-filter libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc [EMAIL PROTECTED]:~$ but there is also a removal suggestion, and the excuses-file on ftp-master says according to http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter that this package is removed today from testing. So, why is this still there? How many hours after the generation of the excuses list are the packages really updated? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gens -- Sega Genesis/CD/32X emulator
Argh, hold off on this, I just noticed part of this package needs to go in non-free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: setting up a woody chroot for backporting
Joost van Baal <[EMAIL PROTECTED]> writes: I have very little experience with chroot-ed builds, but will spend some more time investigating. You can create a nice small chroot like this: (cdebootstrap installs less cruft then debootstrap) apt-get install cdebootstrap cdebootstrap woody /chroots/woody http://your.mirror/debian editor /chroots/woody/etc/apt/sources.list Is it me, or cdebootstrap is currently broken? # cdebootstrap woody /chroots/woody http://your.mirror/debian cdebootstrap: /usr/lib/libdebian-installer.so.4: version `LIBDI_4.3' not found (required by cdebootstrap) and it seems there's no never version of libdebian-installer than 25-really-22. Any clue? Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcin http://wfmh.org.pl/carlos/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I finally opted for this solution. The package is ready to be uploaded, but how am I supposed to proceed now? ask for removal first and then upload or the opposite? also, is [EMAIL PROTECTED] the correct address to contact ftp-master? thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why are these packages in testing?
On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote: > Hi, > > I came across some strange outputs. For example: > > [EMAIL PROTECTED]:~$ madison aiksaurus > aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source > aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > > There is a current removal suggestion by vorlon: > # 20040509 > # bug #241279 > remove aiksaurus/1.0.1+cvs.2004.02.20-1 > > Why is there only the source in testing? Because 7 out of 9 binary packages of that source are still in testing: http://lintian.wolffelaar.nl/histmadison/?source=aiksaurus&package=&date=2004-06-07 Note that the testing output says removal fails due to buggyness of the package: http://packages.qa.debian.org/a/aiksaurus.html # Trying to remove package, not update it # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) # Not considered I guess the textual representation is bogus, otherwise removals can't really have worked before. > Similar, for libapache-mod-filter, there is: > [EMAIL PROTECTED]:~$ madison libapache-mod-filter > libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > but there is also a removal suggestion, and the excuses-file on > ftp-master says according to > http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter > that this package is removed today from testing. So, why is this still > there? How many hours after the generation of the excuses list are the > packages really updated? 'today' means 'just before next mirror pulse', i.e., it will be gone after tonight. Testing scripts run just after a mirror pulse, and have effect only upon next one, so there generally is a delay of about 20 hours iirc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gens -- Sega Genesis/CD/32X emulator
Ok, nevermind... this package has a mess of non-free, I need some serious time to sort through what's even redistributable. Teach me to get overzealous, sheesh... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: [...] > > Personally I'd immediately change the architecture field and change it > > back once there is a xserver for s390. - You'll probably have to > > pester ftp-master to remove the old s390 binary, otherwise > > xfree86-driver-synaptics will be blocked by "out of date on s390". > I finally opted for this solution. The package is ready to be uploaded, > but how am I supposed to proceed now? ask for removal first and then > upload or the opposite? Do both instead of waiting. There is no problem if the s390 buildd tries to build xfree86-driver-synaptics before the binary has been removed (and xfree86-driver-synaptics has been added to http://buildd.debian.org/quinn-diff/Packages-arch-specific), the build will simply fail because dpkg-buildpackage (or is it sbuild?) checks the architecture field. > also, is [EMAIL PROTECTED] the correct address to contact ftp-master? Afaict from http://www.debian.org/intro/organization yes. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package review and comment wanted
Bengt Thuree <[EMAIL PROTECTED]> schrieb: > Hej > > I have just created one of my first debian package, and would like to > have some comments on the actual packaging. Did you read the new maintainers guide and the developers' reference? > > Have I missed something? > I am very confused of > *) Should I only use the rules file, or a separate Makefile That depends on the complexity of the installation. In most cases, it is highly advisable to have a separate Makefile that does the compilation and installation, and in debian/rules you only call it with appropriate targets and arguments. Isn't there a Makefile in the upstream sources? > *) Should I list all the directories in the dirs (including /usr/sbin) In debian/dirs, you only list the directories that you want to create with dh_installdirs - e.g. directories that the upstream Makefiles assumes to be present upon installation, or directories to which you want to move some files in your debian/rules file - a typical example would be moving some scripts to debian/tmp/usr/share/doc/$packagename/examples. > *) Should I list the conffiles in a separate conffile? That depends on the debhelper compatibility level. Usually it is not necessary - read about it. > *) How do I automatically set the version number and perhaps a > timestamp in the program during packaging? I don't quite understand what you mean with this. Are you speaking about the output of your program when called with a "--version" option? > My package can be fetched from www.thuree.com/debian/buppo or by > simply have the following in the apt.sources > deb http://www.thuree.com/debian buppo/ > deb-src http://www.thuree.com/debian buppo/ So it does have an upstream Makefile - use it. You are packaging this as a Debian native package. You shouldn't do that, unless there is good reason why nobody outside Debian would want to use it. This is true for packages like debian-policy or apt-get (or perhaps not even for that one), but most probably not for a backup program. Consequently, you should use the manpages out of the debian directory and install them in the Makefile. You should probably look up what people mean with the difference between differential and incremental backup; it seems as if you provide both possibilities. In the description you say that it uses afio and tar, but you don't depend on tar. The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. The rules file could need some cleanup - not only removing unneeded commented lines: Do you have an idea what a CFLAG is? Why do you set it? I also had a short look over your buppo script. I don't like that you hardcode all binaries with absolute pathnames. There is a reason why the variable PATH exists, and why people use it to use different binaries. I don't know whether it's against policy, but I'd consider it bad practice. I have no idea about the usefulness of the script, and no intention to sponsor its upload, be it useful or not. I just wanted to give you some feedback. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
chugging
Carson Pollard,^
Visa Gold Promotional Offer,}
N0 Credit Check,,@
No Employment requirement,,/
N0 Finance charge,,{
No Security Depoits,,)
TO build up $1000 credit..,\
and win a car.,"
http://alphacardz.info/index.php?id=9201
,inequivalent ,capacious
,cb ,care .
RFS: libcgi-xmlapplication-perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Ragwitz wrote: | Package: libcgi-xmlapplication-perl | Severity: wishlist | | A new upstream version (currently 1.1.3) is available on cpan. Please | upgrade your package. I have uploaded the package to [EMAIL PROTECTED], so I need a sponsor for the actual upload to the Debian repository. Description: Perl module for creating XML-DOM and OO based CGI scripts ~ This module provides an XML-DOM and object-oriented extension to the ~ CGI module. The XML-DOM extension allows one to generate the output ~ from XML and laid out according to an XSLT stylesheet, separating ~ code and presentation. The object-oriented extension allows one to ~ specify handlers for events like a mouse click on a submit button or ~ on an image. The package is lintian and linda clean. Please, can somebody upload it (you might also have a look at the dmalloc package?) Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxI/m5UTeB5t8Mo0RAj8FAJsHyZwTtWeP0evbo6xRdy6HFnvlLQCglk4f 2GhNOSvsEoHuCSkKq83DlyA= =eYSF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: xpat2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I have adopted the xpat2 package. Would anybody be so kind to upload it, please? Package: xpat2 Description: Generic patience game for X11 ~ xpat2 is a generic patience game which can be used with different rule ~ sets. It does understand the rules of the well-known Spider game, as ~ well as Klondike and others. ~ . ~ This program may have difficulties to start if you have an 8-bit or ~ monochrome display. The package is lintian and linda clean (with overrides). Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxLJH5UTeB5t8Mo0RAqm7AJ4x5D0eg0EwiewpZCzZ3j2LYDvT7gCfQUDJ D7Wd8mcqNMDhKGfNjyTcf5g= =V4gz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: potracegui -- is a KDE frontend for potrace
Hi, I am quite new to packaging and just finished the initial release of potracegui. It is a KDE frontend for the potrace tracing (vectorizing) commanline tool. It enhances the commanline tool as it supports the use of any graphic format known by KDE as input. It also features the direct input of remote files (web, ftp, ...). I would appreciate any comments on the package. It is available from mentors.debian.net. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: potracegui -- is a KDE frontend for potrace
On Mon, Jun 07, 2004 at 09:13:18PM +0200, Christoph Wegscheider wrote: > Hi, Hello Christoph. > I am quite new to packaging and just finished the initial release of > potracegui. It is a KDE frontend for the potrace tracing (vectorizing) > commanline tool. It enhances the commanline tool as it supports the use of > any graphic format known by KDE as input. It also features the direct input > of remote files (web, ftp, ...). Nice to see that someone wants to package program that depends on my package ;) > I would appreciate any comments on the package. Ok here goes my comments: debian/changelog: You should fill ITP bug and close it with your changelog entry. http://www.debian.org/devel/wnpp/ debian/control: I'm sure that your Build-Depends header is wrong. You have to write there programs which are needed during build of that package. If it is KDE application then it certainly needs at least libqt3-mt-dev. Just try to build it in some chrooted environment. Pbuilder is great for such purposes. debian/copyright: Take a look at: http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg02190.html debian/rules: Remove unneeded comments and dh_* lines. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: RFC: potracegui -- is a KDE frontend for potrace
Bartosz Fenski aka fEnIo wrote: > debian/changelog: > > You should fill ITP bug and close it with your changelog entry. > http://www.debian.org/devel/wnpp/ Wasn't sure about this because as it is an unofficial package and maybe never get sponsered (at least not in the near future I think). I thought ITP means intention to package for official debian archive only. > debian/control: > > I'm sure that your Build-Depends header is wrong. > You have to write there programs which are needed during build of that > package. If it is KDE application then it certainly needs at least > libqt3-mt-dev. > Just try to build it in some chrooted environment. Pbuilder is great for > such purposes. Yes, I'm currently studying the appropriate policy section > debian/copyright: > > Take a look at: > http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg02190.html OK > debian/rules: > > Remove unneeded comments and dh_* lines. OK Thank you for commenting, I'll change this soon. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: potracegui -- is a KDE frontend for potrace
On Mon, Jun 07, 2004 at 10:16:41PM +0200, Christoph Wegscheider wrote: > > debian/changelog: > > > > You should fill ITP bug and close it with your changelog entry. > > http://www.debian.org/devel/wnpp/ > Wasn't sure about this because as it is an unofficial package and maybe > never get sponsered (at least not in the near future I think). > I thought ITP means intention to package for official debian archive only. No. ITP is mainly to not duplicate efforts. If someone fill ITP then nobody else (at least theoretical) will work on the same package. Even if you don't intend to make your package official then filling ITP is still ok. Anyone will know where to find preliminary packages. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: Package review and comment wanted
On Mon, Jun 07, 2004 at 05:17:45PM +0200, Frank K?ster wrote: > In debian/dirs, you only list the directories that you want to create > with dh_installdirs - e.g. directories that the upstream Makefiles > assumes to be present upon installation, or directories to which you > want to move some files in your debian/rules file - a typical example > would be moving some scripts to > debian/tmp/usr/share/doc/$packagename/examples. You don't use dh_installdirs for that, you use dh_installexamples. > > *) Should I list the conffiles in a separate conffile? > > That depends on the debhelper compatibility level. Usually it is not > necessary - read about it. man 7 debhelper, BTW, in the section "Debhelper compatibility levels". > > *) How do I automatically set the version number and perhaps a > > timestamp in the program during packaging? > > I don't quite understand what you mean with this. Are you speaking about > the output of your program when called with a "--version" option? The version of the debian package you produce is taken from the package's topmost changelog entry. For timestamps, you can use touch(1), but I'm having trouble coming up with why you'd want to stamp a file to a particular time... > In the description you say that it uses afio and tar, but you don't > depend on tar. No need to depend on tar, it's Essential. > The changelog entries are not really well understandable for somebody > who doesn't yet know what it's about. I wouldn't necessarily count that as a major problem -- changelog entries are for users of the package, not passers-by. Of course, if even regular users couldn't understand them, then it's time to rewrite. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request for comments for ibwebadmin package
Hello, I am looking for comments about my packaging of ibwebadmin. Testers are also welcome. * Package name: ibwebadmin Version : 0.97 Upstream Author : Lutz Brückner <[EMAIL PROTECTED]> * URL : http://ibwebadmin.sf.net/ * License : GPL v2 Description : IBwebadmin is a web frontend for the firebird and interbase databases. The package is lintian and linda clean and builds with pbuilder. The use of yada should make things easy for reviewing (and maintaining!). It can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/i/ibwebadmin/ Cheers, Remco Seesink.
Re: Package review and comment wanted
Hej Frank, and thank you for very much appreciated comments. I will try to answer them below /Bengt Frank Küster wrote: Did you read the new maintainers guide and the developers' reference? Yes, I read them once, twice, and ten times, but must have some problem with my english apperantly. That depends on the complexity of the installation. In most cases, it is highly advisable to have a separate Makefile that does the compilation and installation, and in debian/rules you only call it with appropriate targets and arguments. ok Isn't there a Makefile in the upstream sources? Upstream this is the upstream. I created the package *) Should I list all the directories in the dirs (including /usr/sbin) In debian/dirs, you only list the directories that you want to create with dh_installdirs - e.g. directories that the upstream Makefiles Ok, but when I do not create the usr/sbin directory in the debian/dirs file the dpkg-buildpackage -rfakeroot fails with taget directory do not exist or something like this. I ended up having to put ALL my expected directories in this debian/dirs file. Then the installation went very fine. But when I tried to remove the package, it also tried to remove /usr/sbin *) How do I automatically set the version number and perhaps a timestamp in the program during packaging? I don't quite understand what you mean with this. Are you speaking about the output of your program when called with a "--version" option? Yes, the output from buppo --version. I do not as of right now anyway, use cvs or subversion to handle my revisions. But simply relying on creating a new debian package every once in a while so I have something usefull to go back to. I ended up doing a hack in the Makefile to modify the source code (which I really do not want to do) So it does have an upstream Makefile - use it. I created this Makefile as well, after some people complained that I should not try to remove /usr/sbin when they removed the package. You are packaging this as a Debian native package. You shouldn't do that, unless there is good reason why nobody outside Debian would want So, if I am the one who creates this package, should I not create the package as a Debian native package? to use it. This is true for packages like debian-policy or apt-get (or perhaps not even for that one), but most probably not for a backup program. Consequently, you should use the manpages out of the debian directory and install them in the Makefile. The Debian man pages are located in the docs folder as xml files, and compiled into man pages in the debian directory in the Makefile. You should probably look up what people mean with the difference between differential and incremental backup; it seems as if you provide both possibilities. Good point :-) In the description you say that it uses afio and tar, but you don't depend on tar. Lintian complain when I was depending upon tar. The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. True, I write them mainly for myself for the moment. The rules file could need some cleanup - not only removing unneeded commented lines: Do you have an idea what a CFLAG is? Why do you set it? From the default... I will need to check the rules file and remove some lines then. This is after all a simple bourne shell script, and no need for things to be compiled (except man pages) I also had a short look over your buppo script. I don't like that you hardcode all binaries with absolute pathnames. There is a reason why the variable PATH exists, and why people use it to use different binaries. I don't know whether it's against policy, but I'd consider it bad practice. Hmm.. perhaps. I also come from the Unix world and there it is also considered a good thing to write the paths like this. Makes it easier to change perhaps. I will consider removing the absolute paths, and trust the PATH instead. I have no idea about the usefulness of the script, and no intention to sponsor its upload, be it useful or not. I just wanted to give you some feedback. No problems... To be honest, me neither. But I am sure having fun... :) and learning a lot I really appreciated the comments though Regards, Frank Cheers bengt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package review and comment wanted
Matthew Palmer wrote: want to move some files in your debian/rules file - a typical example would be moving some scripts to debian/tmp/usr/share/doc/$packagename/examples. You don't use dh_installdirs for that, you use dh_installexamples. I managed to use this one :) *) Should I list the conffiles in a separate conffile? That depends on the debhelper compatibility level. Usually it is not necessary - read about it. man 7 debhelper, BTW, in the section "Debhelper compatibility levels". :-) Thanks, I have missed this one. The version of the debian package you produce is taken from the package's topmost changelog entry. For timestamps, you can use touch(1), but I'm having trouble coming up with why you'd want to stamp a file to a particular time... for the buppo --version output. And I think it would be handled by cvs or subversion, but for the moment I am actually using .deb as my revision control No need to depend on tar, it's Essential. Actually Lintian complains if you do... The changelog entries are not really well understandable for somebody who doesn't yet know what it's about. I wouldn't necessarily count that as a major problem -- changelog entries are for users of the package, not passers-by. Of course, if even regular users couldn't understand them, then it's time to rewrite. I agree, the changelog entries are a bit to detailed for everyone but myself at this stage... - Matt Thanks Matt, I appreciate it /bengt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package review and comment wanted
On Tue, Jun 08, 2004 at 09:01:34AM +0900, Bengt Thuree wrote: > >The version of the debian package you produce is taken from the package's > >topmost changelog entry. For timestamps, you can use touch(1), but I'm > >having trouble coming up with why you'd want to stamp a file to a > >particular > >time... > for the buppo --version output. And I think it would be handled by cvs > or subversion, but for the moment I am actually using .deb as my > revision control OK, so you do actually want to have your version information generated automatically from your revision control stuff. I use tla for most of my ongoing development work now, and I've put scripts together to make a release for me. This includes creating a tag branch for the release, as well as automatically sorting out the version numbers in the code. (I'm actually basing my versioning off the Debian changelog, since it's a Debian-native project, but that's not important). What you could do is write a script which takes an argument of your new version number, which tags in your revision control system, does a search-n-replace with sed for inserting the current version number, and perhaps resets the debian version in debian/changelog (run something like dch -v -1). I love shell scripting. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package review and comment wanted
>>> for the buppo --version output. And I think it would be handled by cvs >> or subversion, but for the moment I am actually using .deb as my >> revision control > > OK, so you do actually want to have your version information generated > automatically from your revision control stuff. :-) That was my idea yes :-) Since I tend to forget this I wanted it to be automatically. > > I use tla for most of my ongoing development work now, and I've put > scripts > together to make a release for me. This includes creating a tag branch > for > the release, as well as automatically sorting out the version numbers in > the > code. (I'm actually basing my versioning off the Debian changelog, since > it's a Debian-native project, but that's not important). What you could > do > is write a script which takes an argument of your new version number, > which > tags in your revision control system, does a search-n-replace with sed for > inserting the current version number, and perhaps resets the debian > version > in debian/changelog (run something like dch -v -1). I ended up doing something like this in the Makefile. Taking the version number of the directory name actually, and doing the sed change in the source file. Just that I do not want to end up doing serious damage to the file itself. But I thought that perhaps the debian package building system had some features for doing this automatically. :-) Ok, I was hoping Hmm.. I think perhaps I will simply add a new one line source file in the etc directory which contains the revision data. buppo can then source this file, and this makes me feel a lot safer. > I love shell scripting. O'h yes... but I have loads to learn... > > - Matt /Bengt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
