using cow-shell to build a package
Hi all, I'm currently using cowbuilder to build a package. It is much faster than pbuilder but sometimes not fast enough. I'm currently working on a package which involves tweaking the debian/rules for the right settings. After every change I have to invoke cowbuilder which takes a lot of time. Is it possible to login to a clean environment with you package, make changes and test until its ready and leave the environment later with no changes made to the environment but the package-tree? Does cow-shell provide this functionality. If yes, how? Cheers, -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: byzanz -- very small screencast utility
Hi Mentors, I'm looking for a sponsor for this tiny screen cast utility named byzanz: * Package name: byzanz Version : 0.1.1 Upstream Author : Benjamin Otte [EMAIL PROTECTED] * URL : http://people.freedesktop.org/~company/byzanz * License : GPL Description : Small screencast creator * Closes : #358558 Byzanz is a command-line/GNOME Panel applet allowing you to record your current desktop or parts of it to an animated GIF file. This is specially useful for publishing on the web, since every browser understands the GIF format. Here a few samples of the results: http://venthur.de/tmp/byzanz-test-small.gif http://venthur.de/tmp/planet-bug.gif Byzanz is not limited to gnome, you can use it under non-GTK environments like KDE too. Package status: - package builds fine under pbuilder - is linda/lintian clean - can't be tested with piuparts since, at least one dependency does not uninstall cleanly You can grab the package from here: http://venthur.de/debian/byzanz/ Kind regards, Bastian PS: According to my AM, my AM-report should be ready in the near future, so ideally you'd only be the sponsor of this package for a few months. -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: byzanz - Small screencast creator
Paul Wise wrote: On Sat, 2006-03-25 at 16:57 +0100, Bastian Venthur wrote: I'm looking for a sponsor for this tiny screen cast utility named byzanz: If you have no luck here, try the debian-gtk-gnome list. Thanks for the hint! I'll do that if I cannot find a sponsor on this list. Package status: - lintian-clean, but linda gives a warning: W: byzanz; A binary links against a library it does not use symbols A relibtoolizing could probably fix this, see the autotools-dev README I've tried to find the superfluous library but was not able to find it. Since this is only a warning and there is (according to linda) a chance that this bug could be caused by a bug in a library my package depends on, I decided to leave the warning alone for now. BTW: I've checked the ubuntu package of byzanz and unlike me the maintainer uses cdbs but has exactly the same depends line -- and off course the same linda-warning. * debian/byzanz.menu: could use an icon (in xpm format) I know, but upstream is currently searching for an appropriate icon, and I think it would be better to leave it alone until upstream comes up with an icon. * debian/control: please add the homepage in accordance with the developers reference section 6.2.4 Done. * debian/dirs: probably not needed, since the upstream install process should do that Hmm, but it does not hurt to leave it, does it? * debian/watch: probably best to remove all but the two useful lines Done. * debian/README.Debian: hmm, not sure this is needed, perhaps a small clarification to the long description would replace it I partly disagree. I think it's better to leave a bit too much help than providing too less. And the long description is probably not the best place for this hint. Although this case might be borderline, I'd prefer to provide things like this in the README. * debian/byzanz-record.1: small typo ...briefly the byzanz-record commands..., should be ...briefly the byzanz-record command... Done, thanks! * debian/byzanz-record.1: if this was generated automatically with help2man or the like, without any modifications, it might be useful to generate it at build time so it automatically keeps up with upstream. I'd like to, but the manpage had to be adjusted massively by hand after the conversion. * debian/copyright: the copyright bit needs years, ie Copyright 2006 Benjamin Otte. Grep the source code to find the correct years. Done. If someone is still interested in sponsoring the upload: http://venthur.de/debian/byzanz/ Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: byzanz - Small screencast creator
Marco Cabizza wrote: El dom, 26-03-2006 a las 14:37 +0200, Bastian Venthur escribió: Paul Wise wrote: On Sat, 2006-03-25 at 16:57 +0100, Bastian Venthur wrote: I'm looking for a sponsor for this tiny screen cast utility named byzanz: If you have no luck here, try the debian-gtk-gnome list. Thanks for the hint! I'll do that if I cannot find a sponsor on this list. I don't know if it's a good idea... Daniel Holbach already packaged this for Ubuntu, it's like duplicate effort. I'll be happy for you if you can find a sponsor anyway :) I know, he mailed me right after my ITP for this package, wishing for a good collaboration. But I fear I don't understand your point -- what has the fact that an ubuntu version exists to do with my RFS in Debian? Kind regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
howto pack python programs
Hi Mentors, I'm currently working on a program written in python. The source-tree looks like this: foo.py bar.py baz.py ex1.py ex2.py ex3.py where ex*.py are executables and the others not. My question is, where to put all these files and what should I do with the executables? My current idea is: - copy all *.py into /usr/share/$PACKAGE/ - create symlinks like /u/s/p/ex1.py - /usr/bin/ex1.py /u/s/p/ex2.py - /usr/bin/ex2.py /u/s/p/ex3.py - /usr/bin/ex3.py Is the location /usr/share/$PACKAGE OK? Should I create the symlinks without the py-extension, like: /usr/bin/ex1 - /u/s/ex1.py Next problem, lintian is complaining (W) about non-executable scripts in /usr/share/$PACKAGE -- can I ignore this? BTW: I already know and use dh_python. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: byzanz - Small screencast creator
Hi Mentors, I'm looking for a sponsor for this tiny screen cast utility named byzanz: * Package name: byzanz Version : 0.1.0 Upstream Author : Benjamin Otte [EMAIL PROTECTED] * URL : http://people.freedesktop.org/~company/byzanz * License : GPL Description : Small screencast creator * Closes : #358558 Byzanz is a command-line/GNOME Panel applet allowing you to record your current desktop or parts of it to an animated GIF file. This is specially useful for publishing on the web, since every browser understands the GIF format. Byzanz is not limited to gnome, you can use it under non-GTK environments like KDE too. Package status: - lintian-clean, but linda gives a warning: W: byzanz; A binary links against a library it does not use symbols - builds fine in a clean pbuilder environment - can't be tested with piuparts since, at least one dependency (eg xlibs-data) does not uninstall cleanly - comes with manpage and watchfile Since there is no single screencast tool available in Debian, it would be nice to have this tool ;) You can grab the package from here: http://venthur.de/debian/byzanz/ Kind regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
Joe Wreschnig wrote: On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev I guess the problem has something to do with GTHREAD, but I have no Idea which package provides it or if it's already in my build-depends, why config does not recognize it. No, the error message sucks, it doesn't distinguish between two different (completely unrelated) failures. I reported this earlier as http://bugs.debian.org/358253 when I was trying to get Byzanz compiled. Ah, thanks for the hint! Do you know a workaround for this problem, so I can compile the package? Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Solved] Compiling a Gnome app / GTHREAD or XDamage error
Bastian Venthur wrote: Joe Wreschnig wrote: On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev I guess the problem has something to do with GTHREAD, but I have no Idea which package provides it or if it's already in my build-depends, why config does not recognize it. No, the error message sucks, it doesn't distinguish between two different (completely unrelated) failures. I reported this earlier as http://bugs.debian.org/358253 when I was trying to get Byzanz compiled. Ah, thanks for the hint! Do you know a workaround for this problem, so I can compile the package? I found the solution myself, just put PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig:$(PKG_CONFIG_PATH) before your config-part in debian/rules. Works for me :) Thanks again Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFH] Compiling a Gnome app / GTHREAD or XDamage error
Hi, I'm currently working on a small GTK2 app and while trying to compile it under a clean pbuilder environment, I get the following error during the config phase: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev I guess the problem has something to do with GTHREAD, but I have no Idea which package provides it or if it's already in my build-depends, why config does not recognize it. The ubuntu counterfeit seems to use the same build-depends, but he uses cdbs and it seems to work -- debian/rules is a three liner without any special options, so I guess I have to add something to the config-options. Any idea? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
Michal Čihař wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev If build system is using it, pkg-config is missing. Sorry, added it to the build-depends but I receive the same error :( Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
Laszlo Boszormenyi wrote: On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 = and XDamage = 1.0 to compile. make: *** [config.status] Error 1 Currently my package build-depends on: debhelper (= 4.0.0), autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, intltool, libgtk2.0-dev [...] Any idea? There's a wonderful simple search place: http://packages.debian.org/ At the bottom, choose unstable and search for libgthread as keyword. It reveals that libglib2.0-dev contains: /usr/lib/libgthread-2.0.so The problem sits deeper! I've included this package before and received the same error. I even took the ubuntu package and tried do build it in a clean pbuilder environment and guess what? It fails exactly with the same error. So something really strange is going here. Maybe a bug in one package in my build-depends? Just a question: is it so poorly known that anyone can search for package contents? Nope, I know packages.d.o but I still was not *sure* which package was missing. Regards, Bastian PS: Please don't CC me, I read the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
Marco Cabizza wrote: El jue, 23-03-2006 a las 12:52 -0600, Joe Wreschnig escribió: No, the error message sucks, it doesn't distinguish between two different (completely unrelated) failures. I reported this earlier as http://bugs.debian.org/358253 when I was trying to get Byzanz compiled. I was trying to make a deb from scratch today and it worked fine. Then I discovered that it was available for ubuntu and punched the wall three times. I didn't receive any error message, though... Really? What did you change in the relevant debian/* files? I've only changed the control file (build-depends [see beginning of thread]) so far. Did you modify anything else in the debian/rules or something? Does Byzanz really build in a clean pbuilder/sid environment? Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changes to upstream sources/HOWTO patch
Hi Mentors, I've noticed that some packages contain a debian/patches-dir and I'm curious how this works. I think I need to patch one of my packages myself so I'm looking for some documentation. The Debian policy [1] does not really help since the part about changes to upstream sources is quite short. 1. http://www.debian.org/doc/debian-policy/ch-source.html#s4.3 Can someone explain to me how to apply patches to upstream sources the right way or point me to an appropriate document? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFH] update-alternatives
Hi Mentors, I am the maintainer of crystalcursors[1] and I received a bugreport[2] where the submitter asks me to register the cursors as x-cursor-theme via update-alternatives. Unfortunatly I'm not able to find some useful documentation which helps me to do so. Could somebody point me to a HOWTO or explain what I should do to register my cursors? I've already checked some other package which uses this mechanism but after my expirience just copying stuff from one package often means to copy the defects from other packages to my own (and leads to bad packaging style). Regards, Bastian [1] http://packages.qa.debian.org/c/crystalcursors.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330626 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear
Christoph Haas wrote:
On Tuesday 18 October 2005 10:24, Bastian Venthur wrote:
I'm searching for sponsorship of my packages:
dh_install 128x128 16x16 22x22 32x32 48x48
kde-icons-nuvola
+ http://packages.qa.debian.org/k/kde-icons-nuvola.html
+ http://venthur.de/debian/nuvola/
As usual I have found something to grumble about. :)
As usual... ^^
dh_install 128x128 16x16 22x22 32x32 48x48...
= Consider putting these directories into debian/kde-icons-nuvola.install
(See man dh_install)
Done. Thanks for the hint, rules looks much better now...
find ... -type f -exec chmod 644 {}
= Isn't dh_fixperms doing that already?
... if only I could get rid of those nasty find-lines. No dh_fixperms does
not the trick. You can try it yourself but without those lines all files
stay executable and lintian is not very amused. According to the manpage
dh_fixperms checks only /usr/share/doc, /usr/games and /etc/init.d
find ... -name laptop_charge -exec rm \{\} \;
= You are doing that after dh_builddeb? Advanced magic? :)
Damn... embarrassing... fixed.
The package will be completely uploaded in ~30mins.
Kind regards
Bastian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear
Christoph Haas wrote: On Tuesday 18 October 2005 10:24, Bastian Venthur wrote: I'm searching for sponsorship of my packages: kde-icons-crystalclear + http://venthur.de/debian/crystalclear/ closes: #322161 + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322161 * Package name: kde-icons-crystalclear Version : 0.0.20050623 Upstream Author : Everaldo Coelho [EMAIL PROTECTED] * URL : - Similar thoughts here about dh_install Done. and dh_fixperms. Not fixed. - debian/control contains an empty Depends: line. Done. The package will be completely uploaded in ~45min. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] kde-icons-nuvola and kde-icons-crystalclear
Hi Mentors, I'm searching for sponsorship of my packages: kde-icons-nuvola + http://packages.qa.debian.org/k/kde-icons-nuvola.html + http://venthur.de/debian/nuvola/ This upload is mainly for QA. If you've followed my last RFS for kde-icons-nuvoext you might know my rules file was *very* messy and my .orig.tar.gz was not as it should be. The same problem and solution applies to this package, wich I released in the same time as nuovext. The package if of course l/l clean. kde-icons-crystalclear + http://venthur.de/debian/crystalclear/ closes: #322161 + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322161 * Package name: kde-icons-crystalclear Version : 0.0.20050623 Upstream Author : Everaldo Coelho [EMAIL PROTECTED] * URL : http://www.kde-look.org/content/show.php?content=25668vote=goodtan=85499329 * License : LGPL Description : Everaldo's Crystal Clear icon theme for KDE Unlike kde-icons-crystal -- which is in fact Everaldos Crystal SVG icon theme from 2003, -- this package does not contain graphics in SVG-format. But the Crystal Clear icons are newer and seem to be becoming more popular than the Crystal SVG icons. . On Aug-2005 Crystal Clear was the most popular icon theme on kde-look.org. If you like the old Crystal SVG you should probably give Crystal Clear a try! This package is l/l-clean too and if you ask me the best icon theme so far (my other sets included). It has much more icons than the other ones and seems to fit very well in the KDE look-n-feel (No wonder, since its the sucessor of the current default icon theme of KDE3). Please consider sponsoring this package, I believe this package really contributes some eyecandy to KDE3. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: On Monday 17 October 2005 23:15, Bastian Venthur wrote: Hehe, I guess my package is relatively perfect (and uploaded) now ;) The $(CURDIR) is redundant in dh_installchangelogs. But I won't harass you with that any more. :) But one last question. What if upstream provides a README, which want to keep. Would it be ok to do my mv README readme trick, or is there a dh_* I've overseen? I would just dh_install it. Why is it a problem if it's in uppercase? Otherwise... the dh_install does not allow renaming which has bugged me a few times already. So if you really wanted to rename it you would rather need to use install. Moving it away would mean you cannot build the package twice (which must be working according to the policy) since the second time the source file is no longer there. Or am I wrong? Your package is now uploaded. Glad you made it. Glad you helped me (again) -- thanks very much. I'll stick to the nuvola icons on my system though. Less ugly... :) Uhm' strange you mention nuvola coughcrystalclear-is-far-better-and-nuvola-needs-a-QA-upload-too/cough sorry must be something in my throat. ;) Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: On Saturday 15 October 2005 14:59, Bastian Venthur wrote: [...] kde-icons-nuovext + http://packages.qa.debian.org/k/kde-icons-nuovext.html + http://venthur.de/debian/nuovext/ closes: #324505 (Includes text files under /usr/share/icons) Notes for kde-icons-nuovext: - why are you using gzip -9? I'd prefer dh_compress Done. - why move the documentation around manually instead of using dh_installdocs? Done. - the download URL is mentioned in http:// brackets. Why? It is not an email address. Done. - it may be a matter of taste but I would not extract the upstream tarball right into the debian/... directory. Why not using that file as an *.orig.tar.gz. Okay, it's too late for this upstream version since Debian already has your *.orig.tar.gz in the archives. It appears like your current *.orig.tar.gz consists of the real *.orig.tar.gz. Do I miss a reason why it's done this way? I would rather do it the dh_make way and install the files with dh_install. Done, I've changed it to a more standard-compilant method. Thanks for pointing out all these ugly bugs. When I created this package this was one of my first packages and the -2 fix is quite old too. I think I've learned a bit in the meanwhile. The rules file looks *much* better now. -2 never hit the archive. To test the -vVersion Option, I created a -3 version with a rather verbose changelog. I hope this is Ok this time. Kind Regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: Hi, Bastian... regarding kde-icons-nuovext... On Monday 17 October 2005 13:10, Bastian Venthur wrote: Christoph Haas wrote: - it may be a matter of taste but I would not extract the upstream tarball right into the debian/... directory. Why not using that file as an *.orig.tar.gz. Okay, it's too late for this upstream version since Debian already has your *.orig.tar.gz in the archives. It appears like your current *.orig.tar.gz consists of the real *.orig.tar.gz. Do I miss a reason why it's done this way? I would rather do it the dh_make way and install the files with dh_install. Done, I've changed it to a more standard-compilant method. Okay. Just keep in mind that you cannot change the orig.tar.gz which is currently in Debian. You can only provide new *.diff.gz files for the same upstream tarball. So it's more a todo when your upstream releases a new version. Ooops. This is not good. There is already a new upstream version (1.5) but with this version, upstream changed the license from GPL to CC with the bad non commercial clause -- so it's not very likely that I'll ever find a sponsor for this (nonfree) version. If upstream does not change his mind, I guess debian will only see 1.1 in the archive and so there won't be a new upstream anymore. Is it really not possible to provide a new orig.tar.gz (eg by removing the old one)? I mean my old version was really crappy and I don't want to leave this package in this state forever. Or you artificially release an orig.gar.gz with a version that appears higher than the current one. I've just played around with epochs. I tried to change the version to 1:1.1 but this does not work. I sniffed the sources of some other packages with epochs and saw, that they don't include the epoch in the filename. My last desperate attempt was be to change the upstream version from 1.1 to 1.1.0 -- would this be acceptable? Thanks for pointing out all these ugly bugs. When I created this package this was one of my first packages and the -2 fix is quite old too. I think I've learned a bit in the meanwhile. The rules file looks *much* better now. You wouldn't want to look at my first package. ;) ;) -2 never hit the archive. To test the -vVersion Option, I created a -3 version with a rather verbose changelog. I hope this is Ok this time. I'll check your work later when I'm at home. If it's remotely okay I'll upload it. Thanks for considering my comments. Even if the package is not uploadable due the new orig.tar.gz -- could you please take a look at my other changes in this package? I'm currently (18:00 CEST) uploading my desperate version 1.1.0-1, which is exactly the same like my previos one -3. Maybe this is uploadable, according to: debuild -v1.1-1 ... dpkg-genchanges: including full source code in upload dpkg-buildpackage: full upload (original source is included) ... it should. Kind regards and thanks again Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: Yes, that sounds like a rather good idea. Doesn't look too ugly and tricks the version comparison system. :) If you don't know it already... see the man page for dpkg. There is a nice option called --compare-versions which allows you to find out whether a revision is newer than another one. Even if the package is not uploadable due the new orig.tar.gz -- could you please take a look at my other changes in this package? Sure. Just one issue: mv $(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/CHANGELOG $(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/changelog I suggest you rather use dh_installchangelogs for that. Please see its man page. (That means also removing the debian/docs file.) The general problem here is, that upstream sometimes provides the filenames of optional docs in uppercase. But the policy wants them to be lowercase. What would be a more general solution to rename those files? If upstream provides a README, should I use dh_installchangelogs as well? Everything else looks like I had expected it. If you are happy with increasing the version from 1.1 to 1.1.0 and nobody else objects (I never had such a special case) that package would be okay for me. If the above lines of code (renaming the CHANGELOG to changelog) are acceptable, I'd rather have the 1.1.0 solution than using an epoch. In the future I'll take more care when creating an .orig.tar.gz. Maybe I can convince upstream to change his mind so he removes the non commercial clause, so a new upstream version will undo this faux pas ;) Kind regards and thanks again! Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: On Monday 17 October 2005 21:36, Bastian Venthur wrote: Christoph Haas wrote: I suggest you rather use dh_installchangelogs for that. Please see its man page. (That means also removing the debian/docs file.) The general problem here is, that upstream sometimes provides the filenames of optional docs in uppercase. But the policy wants them to be lowercase. What would be a more general solution to rename those files? If upstream provides a README, should I use dh_installchangelogs as well? You can run dh_installchangelogs with the upstream's changelog file as an argument. Thus the hint to the man page. :) The CHANGELOG file will then be moved and renamed automagically. If you would change that final issue your package would be relatively perfect. Hehe, I guess my package is relatively perfect (and uploaded) now ;) But one last question. What if upstream provides a README, which want to keep. Would it be ok to do my mv README readme trick, or is there a dh_* I've overseen? Kind regards and thanks for your help Bastian PS: I guess I'll also have to take a look at kde-icons-nuvola :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Ricardo Mones wrote: On Sat, 15 Oct 2005 22:47:26 +0200 Bastian Venthur [EMAIL PROTECTED] wrote: - a lot of commented-out debhelper calls in debian/rules Hmm, this is rather cosmetical, isn't it? Is not only cosmetics, is also disk space and bandwidth for holding useless stuff. Ok I really don't want to argue about this, but this argument seems not very appropriate. Of course you are right, leaving stuff commented-out instead of removing them *is* a waste of bandwidth and space, but we're talking about -- let's see: I've removed all the comments from the rules file and debuild'ed the package again. Let's compare the resulting filesizes against the old ones (with comments): ~/Desktop/tmp/CC$ tree . . |-- with-comments | |-- crystalcursors_1.1.1-1.diff.gz | |-- crystalcursors_1.1.1-1.dsc | |-- crystalcursors_1.1.1-1_all.deb | |-- crystalcursors_1.1.1-1_i386.changes | `-- crystalcursors_1.1.1.orig.tar.gz `-- wo-comments |-- crystalcursors_1.1.1-1.diff.gz |-- crystalcursors_1.1.1-1.dsc |-- crystalcursors_1.1.1-1_all.deb |-- crystalcursors_1.1.1-1_i386.changes `-- crystalcursors_1.1.1.orig.tar.gz 2 directories, 10 files ~/Desktop/tmp/CC$ du -b with-comments/ wo-comments/ 1083695 with-comments/ 1083357 wo-comments/ The difference in *bytes* is exactly 338 -- this is ~5-10 times smaller than the size of *one* single cursor contained in this package. The reason why I try to leave all the commands commented-out instead of removing them is simple: Packaging is a quite new task for me and it happens that I accidently remove a line too much from the rules file. Afterwards it's easier to comment them in again than to find the appropiate command and place where to insert it again, if I've removed too much. After all I'm not really convinced that this practice is worth discussing, but I admit that this might poor style. But on the other hand the package seems to be clean and fixes an (for lefthanded users) annoying bug, so if nobody finds another bug could somebody please sponsor the upload? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: On Saturday 15 October 2005 22:47, Bastian Venthur wrote: - a lot of commented-out debhelper calls in debian/rules Hmm, this is rather cosmetical, isn't it? Mostly. But the template is merely there as a superset of things you could possibly need. It doesn't do any harm to leave it in there. And I don't think it would waste more time and bandwidth than this thread. ;) It's just nicer to read. I agree -- bad style, but on the other side maybe an acceptable practice for beginners. I think crystalcursors should be OK now and I would really appreciate it if somebody could sponsor the upload, because it would close the lefty bug which has already been unneccesarily long open. Okay, uploaded. Cool, thank you very much -- the package has been ACCEPTED. In the next days I'll take a look at nouvext. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Ricardo Mones wrote: I have lots of commented-out debhelper lines which sometimes later get used when upstream does add a relevant file. If you like things all prim and proper, that's fine, but please don't impose it on others. I think the one who should take a break is you. I'm not trying to impose anything. This is debian-mentors, both keeping files clean and using a SCM are common practices for debian packaging, but you can do it as you like of course. Looks like mentioning this offended you, who used not less than three exclamation marks, brought policy and god into scene and nearly called me a nazi. I hope you're relieved now ;-) Ok, please let's stop this right here. I think we heard the pros and cons of leaving commented-out commands in rules and we all agree that this is not state of the art style on the one hand, but not really against the policy (so probably allowed) on the other one. Let's keep focusing on making high quality packages and helping each other (at least on this list ;) Regards, Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
question about closing bugs in changelog
Hi Mentors, I when I upload a new version of my package to debian, will the *whole* changelog parsed for fixed bugs, or just the last changelog entry? Assume the following situation. - foo-1.0 is in the archive - foo-1.1 fixes bug #1, but my sponsor is currently too busy to upload - foo-1.2 fixes bug #2 and my sponsor uploads this package = foo-1.1 was never in the archive, will #1 be closed automaticly? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] crystalcursors and kde-icons-nuovext
Hi Mentors, I'm searching for sponsorship of my packages: crystalcursors + http://packages.qa.debian.org/c/crystalcursors.html + http://venthur.de/debian/crystalcursors/ closes: #328298 (Hot Point of Lefthanded Themes Wrong) kde-icons-nuovext + http://packages.qa.debian.org/k/kde-icons-nuovext.html + http://venthur.de/debian/nuovext/ closes: #324505 (Includes text files under /usr/share/icons) Both packages are allready in the archive and fix a bug. My current sponsor seems to be very busy, so I'm asking you for an upload. The fix for crystalcursors seems quite important, since it fixes an annoying bug for lefthanded users. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] crystalcursors and kde-icons-nuovext
Christoph Haas wrote: On Saturday 15 October 2005 14:59, Bastian Venthur wrote: I'm searching for sponsorship of my packages: crystalcursors + http://packages.qa.debian.org/c/crystalcursors.html + http://venthur.de/debian/crystalcursors/ closes: #328298 (Hot Point of Lefthanded Themes Wrong) Notes for crystalcursors: - lintian is complaining bitterly (see the artwiz-cursor package for a lintian override if you believe that these warnings are okay) Done, the package is now l/l-clean. - a lot of commented-out debhelper calls in debian/rules Hmm, this is rather cosmetical, isn't it? - why dh_installexamples? There are no examples. - why dh_installman? There are no manpage. - why dh_link? There are no symlinks to set? Fixed. I think crystalcursors should be OK now and I would really appreciate it if somebody could sponsor the upload, because it would close the lefty bug which has already been unneccesarily long open. Thanks in advance and kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
managing my packages with svn
Hi mentors, In order to keep track of my changes in the development of my packages I've decided to put my debian folder with all the packages and sources inside into a svn repo. My question is simple: Are there common pitfalls I should look out for? I could imagine, that all the new .svn dirs in every folder could cause some trouble, when building new packages. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: managing my packages with svn
Fathi Boudra wrote: Le Jeudi 13 Octobre 2005 10:53, Bastian Venthur a écrit : Hi mentors, In order to keep track of my changes in the development of my packages I've decided to put my debian folder with all the packages and sources inside into a svn repo. My question is simple: Are there common pitfalls I should look out for? I could imagine, that all the new .svn dirs in every folder could cause some trouble, when building new packages. take a look at http://workaround.org/moin/SvnBuildpackage Thanks for pointing me to SvnBuildpackage. Allthough I think it provides a good way of keeping track of your changes, I'm afraid the whole buildprocess becomes too complicated -- especially for New Maintainers (me included). I think I still prefer the easy way by just putting the debian-dir (where all my packages are stored) under svn control or maybe an own repo for every package. This way I just have to deal with two seperate problems: (1) ci/co (2) building the package as usual Does anything speak against my method? BTW: how do I make pdebuild and debuild to ignore the .svn dirs? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Christoph Haas wrote: On Thu, Sep 01, 2005 at 11:41:00PM +0200, Bastian Venthur wrote: Cool, thanks! I've corrected all issues but one: I've left the word library in the copyright as it is, since this snippet is a verbatim copy of license.txt included in the upstream tarball. I think it's better to leave this as it is in favour of the intended upstream license than correct it for logic/semantic reasons. Do you agree? Agreed. PS: the updated package (I've not altered the debian version) can be found at http://venthur.de/debian/nuvola/ Please check your packages with linda and lintian, too. lintian found this error here: $ lintian -i kde-icons-nuvola_1.0-1_i386.changes E: kde-icons-nuvola: old-fsf-address-in-copyright-file N: N: The /usr/share/doc/pkg/copyright file refers to the old postal N: address of the Free Software Foundation (FSF). The new address is: N: N: Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, N: MA 02110-1301, USA. N: You may want to fix it and inform the upstream about it. This is really strange. Off course I'm checking all my packages to make them l/l-clean but please take a look at my output: ~/debian/nuvola$ linda *changes ~/debian/nuvola$ lintian *changes ~/debian/nuvola$ lintian -i *changes ~/debian/nuvola$ I'm currently running a deb/sid last updated a few days ago. With the same argument like above (library) I'd try to avoid to change the license from the upstream version even if it's just for an adress-change. It is a verbatim copy of the upstream license.txt and I'd rather try to convince upstream to change it. IANAL but I think if upstream provides explicitly a license by putting it into the tarball, I cannot change it since it is somehow part of the contract between upstream and the rest of the world -- isn't it? Don't think I am lazy or something, I just have a bad feeling touching the license of upstream in any way. Everything else looks fine to me. I like the icons, too. :) I hope kdelibs4 is ready now, since my kde-style-lipstik wants to be build cleanly via pbuilder for a few weeks ;) Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kde-style-lipstik -- Lipstik style for KDE3
Package: wnpp Severity: wishlist Owner: Bastian Venthur [EMAIL PROTECTED] * Package name: kde-style-lipstik Version : 1.3 Upstream Author : Patrice Tremblay [EMAIL PROTECTED] * URL : http://www.kde-look.org/content/show.php?content=18223 * License : GPL Description : a purified KDE style based on Plastik Based on the plastik style, Lipstik is a purified style with many options to tune your desktop look. --- Hi Mentors, I'm looking for a sponsor for this neat eyecandy. Lipstik is currently the most popular window-style for KDE3 according to kde-look.org. It looks very good and has *many* options to tune the eyecandy. This package is: - l/l-clean - ABI-translated - and builds fine on a clean pbuilder environment. Screenshots: http://www.kde-look.org/content/show.php?content=18223 My package: http://venthur.de/debian/lipstik/ Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
howto deal with upstream authors not responding?
Hi Mentors, I've packed the crystalclear (cc) icon-theme by everaldo which is the successor of the crystal svg (crystal) theme we currently have as default icon theme in KDE3. It seems that crystal won't be updated anymore by upstream and cc is the icon theme of choice for updated icons. These icons really look better than crystal and I use them on all my boxes. The problem is: On kde-look[1], everaldo put his icons under LGPL, but he did not put a copy of this license in his tarball. But on his homepage[2] he has a more restrict copyright which seems just because he also sells other icons. Unfortunatly all crystal icon sets he has created so far are on this page too, which means his strict copyright note must apply to the crystal icons too, because not stated otherwise. I've contacted him several times a few weeks ago, but he did not respond to my questions. NOTE: As far as I understand, this means that our current default icon set on KDE3 is unfree as well :( Any ideas what I can do now? Does somebody know everaldo or has contact to him? Maybe a kde-qt-devel reading this? Kind regards Bastian [1] http://www.kde-look.org/content/show.php?content=25668 [2] http://www.everaldo.com/legal.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Hi Christooph Christoph Haas wrote: I would have liked to look at it. But using the official upstream tarball from icon-king-com didn't match your package: dpkg-source: error: file kde-icons-nuvola_1.0.orig.tar.gz has size 13594245 instead of expected 13567432 Thanks for you interest in my package. The difference comes from my practice in packing icons: If you take a look at the orig-src from upstream, you get the following directory-tree: orig-tarball: `+ nuvola `-+ 128x128 + 64x64 + ... I've unpacked the tarball an left out the nuvola-dir -- I just used it's contence. In this case my orig-src looks like this: orig.gz: `+ kde-icons-nuvola-1.0 `-+ 128x128 + 64x64 + ... As you can see, I've not removed any files, just the nuvola dir itself. I thought this is a common practice, since most upstream sources don't include a parent dir which is compatible with debians naming-scheme. And the orig.tar.gz from venthur.de would take days to download (1 KB/second). Do you have an alternative location to download? Hmmm seems to be an issue with my host. It seems to be fixed now. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Damyan Ivanov wrote: If you take a look at the orig-src from upstream, you get the following directory-tree: orig-tarball: `+ nuvola `-+ 128x128 + 64x64 + ... This is supported by dpkg-source, no need to repack. You need to repack upstream sources *only* if they contain non-free parts. Hmmm could you please give me a hint how to use this? My steps are the following: 1) unpack tarball 2) rename dir if not compatible with debian's naming convention 3) run dh_make 4) adjust all the files in debian/ 5) run debuild 6) upload where can I improve my practice? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Tyler Trafford wrote: Run dh_make -f ../original tarball instead of just dh_make. Thanks! Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Christoph Haas wrote: On Thu, Sep 01, 2005 at 08:01:59PM +0200, Bastian Venthur wrote: Hmmm could you please give me a hint how to use this? My steps are the following: 1) unpack tarball 2) rename dir if not compatible with debian's naming convention No need to do that. Just enter the directory - no matter what it's called. this is exactly the reason, why I allways rename the dir: dh_make refuses to work if I run dh_make in the nuvola dir: --- The directory name must be package-version for dh_make to work! I cannot understand the directory name or you have an invalid directory name! --- I think I really miss something here, so let me explain my steps a bit more precise: - I'm currently in ~/debian - I create a nuvola dir just to seperate it from my other packages - Inside this dir I put the tarball and extract it, which gives me in this case a second nuvola dir, since upstream packed it this way - Now I am in ~/debian/nuvola/nuvola - If I run dh_make now, it refuses (see above) and this is why I rename it to ~/debian/nuvola/kde-icons-nuvola-1.0 - When I enter this dir, and run dh_make everything looks well but my org.tar.gz is off couse not the same as the upstream Could you please give me advice what I should to instead? 3) run dh_make 4) adjust all the files in debian/ 5) run debuild I use pbuilder to make sure the dependencies are correct and I'm building in a clean environment. But debuild is generally okay. Yeah, me too I just wanted to make my steps as easy to follow as possible. 6) upload Perfect. where can I improve my practice? You are doing well. Really. :) Just some suggestions... debian/control: - Remove the empty Builds: line - The debhelper dependency can go into Build-Depends-Indep: since your package is architecture-independent - Typo. Beautifull - Beautiful - Description:... popular is a bit generic :) What about: Description: Nuvola icon theme for KDE3 Thanks, finding a good description for a trivial thing like nice looking icons is quite hard sometimes ;) debian/copyright: - please use the exact URL where you downloaded the upstream tarball (http://www.icon-king.com/files/nuvola-1.0.tar.gz) - This library is free software... library? - On debian machines... isn't this Debian? :) debian/docs: - is thanks.to useful? - the readme.txt contains a redundant copyright and not much more useful information IMHO. What do you think? - author can surely be omitted Again, thanks -- I thought one should try to leave as much upstream information as possible in the package -- but you're right. These infos are redundant. debian/rules: - you need a binary-arch target (see http://www.de.debian.org/doc/debian-policy/ch-source.html#s-debianrules) Don't be frustrated by the amount of comments. Those are mainly minor issues. Thanks for your contribution already. I believe you'll quickly find a sponsor once this is fixed. That's really no problem, it might be frustating to find a sponsor sometimes, but having people who are willing to help eases this a bit ;) Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde-icons-nuvola -- popular icon theme for kde
Christoph Haas wrote: Just tell. I had lots of trouble finding sponsors. Yet another reason I helped found admentors.debian.net/ad. ;) Once your package is fixed I'll offer sponsorship. Let us know when you are done. Cool, thanks! I've corrected all issues but one: I've left the word library in the copyright as it is, since this snippet is a verbatim copy of license.txt included in the upstream tarball. I think it's better to leave this as it is in favour of the intended upstream license than correct it for logic/semantic reasons. Do you agree? Kind regards and thanks for your help Bastian PS: the updated package (I've not altered the debian version) can be found at http://venthur.de/debian/nuvola/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kde-icons-nuvola -- popular icon theme for kde
Package: wnpp Severity: wishlist Owner: Bastian Venthur [EMAIL PROTECTED] * Package name: kde-icons-nuvola Version : 1.0 Upstream Author : David Vignoni [EMAIL PROTECTED] * URL : http://www.icon-king.com * License : LGPL Description : popular icon theme for kde Nuvola is a very beautifull icon theme for kde and one of the most popular according to kde-look.org. If you like plastik and crystal, you should give nuvola a try! --- Hello, I'm looking for a sponsor for this package. You can get screenshots on: http://www.kde-look.org/content/show.php?content=5358vote=goodtan=12634066 The package is linda/lintian-clean and you can get it here: http://venthur.de/debian/nuvola/ Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kde-icons-nuovext
Hi Mentors, I already have kde-icons-nuovext in the archive, but a bugreport has been filed and I fixed the problem. My sponsor is currently on vacation so I'm asking whether someone is willing to sponser this (tiny) bugfix. The package is l/l-clean. the package-description: http://packages.debian.org/unstable/kde/kde-icons-nuovext the bugreport: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kde-icons-nuovext my updated version (xxx_1.1-2) http://venthur.de/debian/nuovext/ kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sponsors.debian.net beta
Eddy Petrisor wrote: --- !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html --- Of course, http://validator.w3.org/check?uri=http%3A%2F%2Fsponsors.debian.net%2F This site is still not viewable with firefox. The funny thing is: when i wget the site and surf it locally with ff everything looks well, but surfing online to sponsors.debian.net -- I just get a white page with the above code. There seems to be a difference between my local an the foreign version of this page -- at least for ff. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sponsors.debian.net beta
Neil McGovern wrote: Lo all, http://sponsors.debian.net is now around 90% finished, so I'm looking for people to try and break it :) This site seems to be empty, all i get is a white page with the following code (code-view) --- !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html --- kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sponsors.debian.net beta
Bastian Venthur wrote: Neil McGovern wrote: Lo all, http://sponsors.debian.net is now around 90% finished, so I'm looking for people to try and break it :) This site seems to be empty, all i get is a white page with the following code (code-view) --- !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html --- I only have this problem with firefox (both: sid and experimental version), with Konqueror and lynx everything looks fine. kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
Package: wnpp Severity: wishlist Owner: Bastian Venthur [EMAIL PROTECTED] * Package name: crystalcursors Version : 1.1 Upstream Author : Marco Martin [EMAIL PROTECTED] * URL : http://www.kde-look.org/content/show.php?content=6240 * License : LGPL Description : X11 mouse theme with the crystal lookfeel This package comes with 20 different mouse themes: * crystalblue, crystalblue_classic, crystalblue_nonanim * crystalblueleft, crystalblueleft_classic, crystalblueleft_nonanim * crystalgray, crystalgray_nonanim * crystalgrayleft, crystalgrayleft_nonanim * crystalgreen, crystalgreen_classic, crystalgreen_nonanim * crystalgreenleft, crystalgreenleft_classic, crystalgreenleft_nonanim * crystalwhite, crystalwhite_nonanim * crystalwhiteleft, crystalwhiteleft_nonanim --- Hi Mentors, I'm seeking a sponsor for these beautyfull mouse cursors. Alltogether it is basicly one theme which comes in 20 different flavors (different colors, left-handed, animated, not-animated). It is linda-clean but gives a lintian warning like this for every cursor: W: crystalcursors: packages-installs-file-to-usr-x11r6 usr/X11R6/lib/X11/icons/crystalwhiteleft_nonanim/ but I guess it's OK -- because these are cursors and they have to be installed in this directory. The package can be found at: http://venthur.de/debian/crystalcursors/ Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
Justin Pryzby wrote: On Wed, Aug 17, 2005 at 06:19:15PM +0200, Bastian Venthur wrote: W: crystalcursors: packages-installs-file-to-usr-x11r6 usr/X11R6/lib/X11/icons/crystalwhiteleft_nonanim/ but I guess it's OK -- because these are cursors and they have to be installed in this directory. My understanding is otherwise: http://lintian.debian.org/reports/Tpackages-installs-file-to-usr-x11r6.html | packages-installs-file-to-usr-x11r6 | Packages using the X Window System should not be configured to install | files under the /usr/X11R6/ directory unless they use imake. The | /usr/X11R6/ directory hierarchy should be regarded as deprecated for | all packages except the X Window System itself. | Programs that use GNU autoconf and automake are usually easily | configured at compile time to use /usr/ instead of /usr/X11R6/, and | this should be done whenever possible. | Refer to Policy Manual, section 11.8.7 for details. Could you test and see if it works if you use /usr/ instead? I'm no X11 expert, but I tend to believe that lintian/policy know what they're doing. I think in this special case this warning can be ignored, since all other mousecursors on my system are installed in the very same dir. BTW I've seen that other packages [1] which provide cursors have this warning too. Kind regards Bastian [1] lintian report for gtk-industrial-engine: http://lintian.debian.org/reports/mJosselin_Mouette.html#gtk-industrial-engine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
Justin Pryzby wrote: On Wed, Aug 17, 2005 at 07:41:13PM +0200, Bastian Venthur wrote: Justin Pryzby wrote: On Wed, Aug 17, 2005 at 06:19:15PM +0200, Bastian Venthur wrote: W: crystalcursors: packages-installs-file-to-usr-x11r6 usr/X11R6/lib/X11/icons/crystalwhiteleft_nonanim/ but I guess it's OK -- because these are cursors and they have to be installed in this directory. My understanding is otherwise: http://lintian.debian.org/reports/Tpackages-installs-file-to-usr-x11r6.html | packages-installs-file-to-usr-x11r6 | Packages using the X Window System should not be configured to | install files under the /usr/X11R6/ directory unless they use | imake. The /usr/X11R6/ directory hierarchy should be regarded as | deprecated for all packages except the X Window System itself. | Programs that use GNU autoconf and automake are usually easily | configured at compile time to use /usr/ instead of /usr/X11R6/, and | this should be done whenever possible. | Refer to Policy Manual, section 11.8.7 for details. Could you test and see if it works if you use /usr/ instead? I'm no X11 expert, but I tend to believe that lintian/policy know what they're doing. I think in this special case this warning can be ignored, since all other mousecursors on my system are installed in the very same dir. BTW I've seen that other packages [1] which provide cursors have this warning too. $ ls -l /usr/lib/X11 lrwxrwxrwx 1 root root 16 Jun 8 22:26 /usr/lib/X11 - ../X11R6/lib/X11 Ok, I've changed the target to /usr/lib/X11. But now instead of 1 warning per cursor i get 2 errors per cursor: E: crystalcursors: package-installs-file-to-usr-something-x11 usr/lib/X11/icons/crystalwhiteleft/cursors/plus E: crystalcursors: use-of-compat-symlink usr/lib/X11/icons/crystalwhiteleft/cursors/plus Any ideas? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kde-icons-nuovext -- nuoveXT icon theme for KDE
Package: wnpp Severity: wishlist Owner: Bastian Venthur [EMAIL PROTECTED] * Package name: kde-icons-nuovext Version : 1.5 Upstream Author : Alexandre Moore [EMAIL PROTECTED] * URL : http://sa-ki.deviantart.com * License : Attribution-NonCommercial-ShareAlike 2.0 Canada Description : nuoveXT icon theme for KDE nuoveXT is a complete icon set for KDE. It consists of high quality icons, which can be used as individual icons for X desktops or as a complete icon set for KDE 3. It is currently one of the most popular icon sets from kde-look.org. -- Hello, Nuovext, is currently on rank two of the most popular kde-icons on kde-look.org -- so I guess there are some users out there who'd like to see this package in the archive. I'm seeking a sponsor for this *non-free* package. It is non-free since version 1.5 because it has the NonCommercial clause in it's CC-license. NOTE: The previous Version 1.1 was free (GPL included). You can find both versions l/l-clean at http://venthur.de/debian/nuovext Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: kde-icons-crystalclear -- Everaldo's Crystal Clear icon theme for KDE
Package: wnpp Severity: wishlist Owner: Bastian Venthur [EMAIL PROTECTED] * Package name: kde-icons-crystalclear Version : 0.0.20050623 Upstream Author : Everaldo Coelho [EMAIL PROTECTED] * URL : http://www.everaldo.com/crystal * License : LGPL Description : Everaldo's Crystal Clear icon theme for KDE Unlike kde-icons-crystal -- which is in fact Everaldos Crystal SVG icon theme from 2003, -- this package does not contain graphics in SVG format. . But the Crystal Clear icons are newer and seem to be becoming more popular than the Crystal SVG icons. . In Aug-2005 Crystal Clear was the most popular icon theme on kde-look.org. If you like the old Crystal SVG you should probably give Crystal Clear a try! --- Hi Mentors, I am seeking a sponsor for this very nice package. Since the kde-debian-default icon theme is over two years old, I think it is time for some fresh new icons from Everaldo. As you can see in the version number, these icons are from 2005-06-23 and at this moment the most popular icon theme on kde-look.org. You can get a screenshot at http://www.everaldo.com/crystal.html The package is linda- and lintian clean and works fine my two sid-boxes. You get get it at http://venthur.de/debian/crystalclear/ Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request for sponsor: bomberclone
pedro silva wrote: Hello, debian-mentors Bomberclone is a free BomberMan like game. It was in the list of packages up for adoption. I'd like to maintain it. I've packaged upstream's new version of this game, 0.11.6.2http://0.11.6.2. Ergo, debian's new package number should be 0.11.6.2-1. It's source can be found at http://www.ageda.net/debian/ now i'm looking for a sponsor for it's review and upload. Hi Pedro, (1) If you'd contacted the current maintainer of bc you might have noticed, that the current maintainer is willing to do the sponsoring, but not just for a new maintainer release -- and BTW that you are not the first one (me included: http://venthur.de/bomberlcone) who's asking for adoption of this package. Asking the current maintainer is BTW usually the correct way and first step you take, when you want to adopt a package. (2) The current version of BC is 0.11.6 -- as you can see on bomberclone.de and it's sourcefoge.net-page -- it's the same version which is currently in debian. HTH and kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
question about increasing versionnumbers
Hi Mentors, as I've noticed no one is rightnow interested in sponsoring my tvbrowser-package. But since, I really want to maintain this package (I use it for myself) I have a question about future changes I'll make in this package. What is the best practice, when making small changes to the package like fixing typos and stuff? Should I stick to my initial release or should i alter the Versionnumber everytime I make change? And the next question in a bigger context: What if a new upstream comes out while my package is not sponsored? Should I pretend to maintain a real package and alter the changelog and stuff or should the last package which is not part of debian always be the initial release? Thanks in advance and kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Andrew Saunders wrote: [...] But having had a quick peek inside the orig.tar.gz, it looks like there's stuff in there that renders it completely undistributable, even from non-free. Everything under win/include/ contains: * Copyright 1997-1999 by Sun Microsystems, Inc., * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. * All rights reserved. * * This software is the confidential and proprietary information * of Sun Microsystems, Inc. (Confidential Information). You * shall not disclose such Confidential Information and shall use * it only in accordance with the terms of the license agreement * you entered into with Sun. And all instances of Search16.gif, About16.gif, WebComponent16.gif, Edit16.gif, Information24.gif, TipOfTheDay24.gif, Host16.gif, Refresh16.gif, Help16.gif, Find16.gif, Stop24.gif, listview24.gif, Import24.gif, Stop16.gif, Refresh24.gif, Properties16.gif, New16.gif, Export16.gif, listview16.gif, Bookmarks24.gif, New24.gif, Import16.gif, PrintPreview16.gif, details16.gif, Back24.gif, Print16.gif, Bookmarks16.gif, Forward24.gif, PageSetup16.gif, Open16.gif, Down24.gif, Delete16.gif, Down16.gif, down16.gif, Preferences24.gif, Print24.gif, Up24.gif, Delete24.gif, Up16.gif, up16.gif, Preferences16.gif, Save16.gif, Jar16.gif, Information16.gif, Find24.gif, TipOfTheDay16.gif and Edit24.gif contain the string Copyright 2000 by Sun Microsystems, Inc. All Rights Reserved. CCed the author to make him aware of the situation. Any further discussion with regards to the licensing should probably take place on -legal rather than -mentors. Hi Andrew, thank you for your hint about the copyright. But I'm not willing to give up so quickly :) As a first step, I've noticed, that this package builds without any problems after I've removed the win-dir (surprise). I think this is a very important first step. But bevore I continue, my question is: When I remove all the copyrighted stuff and if the package is still build- and runnable afterwards, is it possible to let it go into debian as contrib? I wonder, because even if I've cleaned up the whole sources, there would still be the .orig.tar.gz where all this copyrighted stuff is in. Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Andrew Saunders wrote: [...] But having had a quick peek inside the orig.tar.gz, it looks like there's stuff in there that renders it completely undistributable, even from non-free. Everything under win/include/ contains: * Copyright 1997-1999 by Sun Microsystems, Inc., * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. * All rights reserved. * * This software is the confidential and proprietary information * of Sun Microsystems, Inc. (Confidential Information). You * shall not disclose such Confidential Information and shall use * it only in accordance with the terms of the license agreement * you entered into with Sun. And all instances of Search16.gif, About16.gif, WebComponent16.gif, Edit16.gif, Information24.gif, TipOfTheDay24.gif, Host16.gif, Refresh16.gif, Help16.gif, Find16.gif, Stop24.gif, listview24.gif, Import24.gif, Stop16.gif, Refresh24.gif, Properties16.gif, New16.gif, Export16.gif, listview16.gif, Bookmarks24.gif, New24.gif, Import16.gif, PrintPreview16.gif, details16.gif, Back24.gif, Print16.gif, Bookmarks16.gif, Forward24.gif, PageSetup16.gif, Open16.gif, Down24.gif, Delete16.gif, Down16.gif, down16.gif, Preferences24.gif, Print24.gif, Up24.gif, Delete24.gif, Up16.gif, up16.gif, Preferences16.gif, Save16.gif, Jar16.gif, Information16.gif, Find24.gif, TipOfTheDay16.gif and Edit24.gif contain the string Copyright 2000 by Sun Microsystems, Inc. All Rights Reserved. Ok, after the first shock, I've investigated the problem and after all the situation is not that bad: 1) the win-dir can easily be deleted without any problems for us. Upstream assured to me, that they have taken care that everything in their project is GPL-compatible. I've asked them about the win-dir and may hopefully get an answer in the next hours. 2) The gifs are free! Upstream has taken them from http://java.sun.com/developer/techDocs/hi/repository/index.html and as you can see the license (bottom right link): http://developers.sun.com/license/berkeley_license.html is free to. I hope to get an quick answer from upstream about the win-dir, maybe there is no need to change the code at all :) Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Hi Andrew and Mentors, Andrew Saunders wrote: On 8/6/05, Bastian Venthur [EMAIL PROTECTED] wrote: 2) The gifs are free! Unfortunately not. :-( Try actually downloading the graphics from that site using the link provided, and you're forced to accept the following license agreement: [...] This license is obviously non-free as it expressly prohibits creating or distributing modified versions. I also suspect that the prohibition on using the graphics in a manner which is disparaging to Sun fails DFSG #6. Hmm strange behaviour of sun... But hey, it's still an improvement - beforehand, we didn't even have permission to distribute the graphics *at all*. Now at least they're suitable for non-free. Fine, for me that's a good start. I'd like to package tvbrowser as non-free at the first run and in the meantime try to convince upstream to substitute this non-free-images with free ones in the next version. If they don't want to do so, than I'd do this by myself in order to push tvbrowser from non-free to contrib. Would this be OK? In the meantime I've found something about the copyrighted files from sun. Actually these files are part of the official j2sdk! The contens of win/include seems to be just a copy of my /usr/lib/j2sdk1.5-sun/include. But I have no idea how to treat this information. Does this mean, that these files can be treated like our gifs, or do they block a distribution into debian? If not: here is my updated non-free version of tv-browser: http://venthur.de/debian/tvbrowser/ If these files are showstoppers, then I'll just remove the win-dir (we obviously don't need it anyway). Kind regards and thanks for your help Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Hi Andrew and Mentors, Andrew Saunders wrote: On 8/6/05, Bastian Venthur [EMAIL PROTECTED] wrote: Fine, for me that's a good start. I'd like to package tvbrowser as non-free at the first run and in the meantime try to convince upstream to substitute this non-free-images with free ones in the next version. If they don't want to do so, than I'd do this by myself in order to push tvbrowser from non-free to contrib. Would this be OK? Sounds good. In the meantime I've found something about the copyrighted files from sun. Actually these files are part of the official j2sdk! The contens of win/include seems to be just a copy of my /usr/lib/j2sdk1.5-sun/include. But I have no idea how to treat this information. Does this mean, that these files can be treated like our gifs, or do they block a distribution into debian? In order to distribute any part of Sun's j2sdk you have to agree that (iii) you do not distribute additional software intended to replace any component(s) of the Software. Since Debian distributes and encourages free replacements such as Kaffe, GCJ and SableVM, no part of j2sdk can be distributed by the Project at all, even from non-free. If these files are showstoppers, then I'll just remove the win-dir (we obviously don't need it anyway). Yep, that's what you'll need to do. Done! :) I've removed the win-dir from the original-sources and the real sources. The package is marked as non-free, lintian- and linda clean. I hope after all this endeavors, someone will sponsor this problem child ;) http://venthur.de/debian/tvbrowser/ Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: tvbrowser -- TV-Browser is a java-based TV guide
Hi Mentors, I've packaged[1] tvbrowser[2], which cloeses #321230[3] and am now seeking for a sponsor. This is my first debian-package, build from scratch. It is linda- and lintian clean. I've contact to the upstream-authors and they are already looking forward to see their nice program in debian. Here the description: Description: TV-Browser is a Java-based TV guide (EPG) TV-Browser is a Java-based TV guide aka EPG which is easily extensible using plugins. It is designed to look like a paperbased TV guide, comes with three looks (gtk+, metal and cde/motiv), an excellent looking skin and many plugins. . Right now this package is only interesting for users living in Germany, Switzerland, Austria and Poland. . Further informations under http://tvbrowser.org Kind regards Bastian [1] http://venthur.de/debian/tvbrowser [2] http://tvbrowser.org [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321230 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Arnaud Vandyck wrote: Bastian Venthur wrote: Hi Mentors, Hi Bastian (don't know if you read the list so I'm cc'ing) Hi Arnaud, hi Mentors, at first: thanks for answering my RFS I've packaged[1] tvbrowser[2], which cloeses #321230[3] and am now seeking for a sponsor. This is my first debian-package, build from scratch. It is linda- and lintian clean. I've contact to the upstream-authors and they are already looking forward to see their nice program in debian. ant, j2sdk1.4 and j2sdk1.5 are in contrib or non-free so your package couldn't go to main. (ant is moving to main, but j2sdk1.x are not!) The section (in debian/control:Section) should be contrib/utils [1] http://venthur.de/debian/tvbrowser [2] http://tvbrowser.org I see there is a client and a server, do you package the client or the server or both? I package the client -- I did not even note, that upstream also provides a server, but as far as I (now) understand, the server is a tool to provide the data, so users of tvbrowser can use them. If this is correct, I provide only the server. Did you tried to build/run it with free tools (kaffe, jamvm, sablevm, gcj/gij, jikes, etc...)? (it seems some javax.swing.text.html.* classes are missing in kaffe 1.1.5-x but I don't know if there've been implemented yet...) No I did not try yet. To be honest my idea was: try to get tvbrowser sponsored and if its in debian try to build/run it with the free tools. But I was already aware of the fact (it depends on jre to run and jsdk to build) that tvbrowser has to be contrib -- but I was not able to find a hint in the new-maintainers-guide where to set this flag. I've googled around but did not find anything -- so I thought this assignment would take place at some other point (debian-masters? I have really no idea). If I can set this flag by myself please give me a hint were. So if it's OK, I'd like to stick to my plan and would like to upload it as contrib and try to make it main as one of the next steps. BTW: I've installed this package on two different boxes and it worked like a charm :) Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Bastian Venthur wrote: Arnaud Vandyck wrote: Bastian Venthur wrote: Hi Mentors, Hi Bastian (don't know if you read the list so I'm cc'ing) Hi Arnaud, hi Mentors, at first: thanks for answering my RFS I've packaged[1] tvbrowser[2], which cloeses #321230[3] and am now seeking for a sponsor. This is my first debian-package, build from scratch. It is linda- and lintian clean. I've contact to the upstream-authors and they are already looking forward to see their nice program in debian. ant, j2sdk1.4 and j2sdk1.5 are in contrib or non-free so your package couldn't go to main. (ant is moving to main, but j2sdk1.x are not!) The section (in debian/control:Section) should be contrib/utils Sorry I somehow missed that last sentence -- I've fixed and uploaded the package to http://venthur.de/debian/tvbrowser Kind regards and thanks again Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
howto get rid of native-package-with-dash-version?
Hi Mentors, I'm packing my first debian-package from scratch and have nearly eliminated all lintian- and linda- warnings/errors. All but one and I have absolutely no idea how to fix it. When building the package lintian says: native-package-with-dash-version I've googled around but I'm still not sure what actually the problem is. Maybe someone can guess the problem, when I try to bring all relavant informations. (1) I've downloaded a sourcefile named tvbrowser_v1.1Alpha2_cvs.zip (2) After unzipping it, I had a directory named tvbrowser_v1.1Alpha2 which is of course not acceptable for dh_make. (3) So i renamed the dir to tvbrowser-1.1+cvs20050622 When i debuild the package, the following files are created: tvbrowser_1.1+cvs20050622-1_i386.deb tvbrowser_1.1+cvs20050622-1.tar.gz tvbrowser_1.1+cvs20050622-1.dsc tvbrowser_1.1+cvs20050622-1_i386.build tvbrowser_1.1+cvs20050622-1_i386.changes Can somebody give me a hint which step was wrong or where to fix this lintian-warning? Thanks in advance and kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: howto get rid of native-package-with-dash-version?
Carlo Segre wrote: I believe that this happens when dpkg-buildpackage cannot find an appropriately names original tarball. It then assumes that the package is a native Debian package which should not have a revision number by policy. This is usually dealt with by specifing the source tarball when running dh_make. In this case, you don't have a *.tar.gz source but a *.zip so you will probably just have to take the contents of the original tvbrowser_v1.1Alpha2_cvs.zip file and make a tvbrowser_v1.1Alpha2_cvs.tar.gz out of it or better yet simply name it tvbrowser_1.1+cvs20050622.orig.tar.gz. If you choose the former, then make a symbolic link tvbrowser_1.1+cvs20050622.orig.tar.gz -- tvbrowser_v1.1Alpha2_cvs.tar.gz When dpkg-buildpackage runs, it will find the *.orig.tar.gz file and not make it a native package. Thank you for your hint, I think now I get the idea of what went wrong ;) Ok but one question remains: When I unpacked the original sources, I had to rename the resulting dir to calm dh_make down -- when I now unpack the .zip in order to make an .orig.tar.gz out of it, do I have to rename the dir too or has the .orig.tar.bz an exact copy of the .zip? Thanks again and kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: howto get rid of native-package-with-dash-version?
Bas Wijnen wrote: On Thu, Aug 04, 2005 at 11:32:01PM +0200, Bastian Venthur wrote: Ok but one question remains: When I unpacked the original sources, I had to rename the resulting dir to calm dh_make down -- when I now unpack the .zip in order to make an .orig.tar.gz out of it, do I have to rename the dir too or has the .orig.tar.bz an exact copy of the .zip? Usually, it is a good idea to keep the original tarball as it is, so the directory it unpacks to should not be changed. dpkg-buildpackage will handle it if it doesn't unpack to the correct name. The reason for keeping the original is as far as I understood it that the md5 checksum is the same as the distributed version. However, since your distribution is a zip file, and not a tar.gz, that doesn't work anyway. So you can make it the renamed directory I guess. But there's not really any reason to do so, as dpkg-buildpackage doesn't need it. So I would just unzip, then tar -czf, and name it .orig.tar.gz. Hmm now I am a bit surprised: I've observed, that after running dh_make in dir foo-1.0, it creates a dir named foo-1.0.orig right besides foo-1.0. And after debuild, I have foo_1.0.orig.tar.gz too -- so I guess dbuild cares about everything and there is no need to create an *.orig.tar.gz by yourself. And so I guess my original question was only foundet in the fact, that I removed the foo-1.0.orig dir a bit too fast (I thought I would not need it, since I keep my orignal .zip). Can anybody confirm my thoughts on this? Kind regards Bastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
