Re: RFS: krecipes (updated package)
Matthias Julius m...@julius-net.net writes: Matthias Julius m...@julius-net.net writes: I am looking for a sponsor for the new version 1.0~beta2-1 of my package krecipes. It builds these binary packages: krecipes - recipes manager for KDE krecipes-data - recipes manager for KDE - data files krecipes-doc - recipes manager for KDE - documentation Krecipes is a KDE application designed to manage recipes. It can help you to do your shopping list, search through your recipes to find what you can do with available ingredients and a diet helper. It can also import or export recipes from files in various format (eg RecipeML or Meal-Master) or from databases. The package appears to be almost (see below) lintian clean. The upload would fix these bugs: 473367, 478030, 513860 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/krecipes - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/krecipes/krecipes_1.0~beta2-1.dsc I would be glad if someone uploaded this package for me. I have to give you some background information. Maintainer for krecipes is actually Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org. Unfortunately, this is list is mostly dead except from forwarded messages from BTS or PTS. A number of mails I (and others) sent there got no response. Krecipes has not been maintained for over 2 years and the MIA team has requested the removal of the only Uploader a couple of months ago (#513860). Therefore, I would consider krecipes effectively orphaned, allthough not officially. Are there any formal steps I should undertake to take over maintainership for this package? I would really appreciate if someone could either help me to get my krecipes package into Debian. Two weeks have passed again and I would like to bring the krecipes package back to the attention of potential sponsors. So, if anyone here is interested in seeing krecipes back in testing, please help me to get it there. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
Matthias Julius m...@julius-net.net writes: I am looking for a sponsor for the new version 1.0~beta2-1 of my package krecipes. It builds these binary packages: krecipes - recipes manager for KDE krecipes-data - recipes manager for KDE - data files krecipes-doc - recipes manager for KDE - documentation Krecipes is a KDE application designed to manage recipes. It can help you to do your shopping list, search through your recipes to find what you can do with available ingredients and a diet helper. It can also import or export recipes from files in various format (eg RecipeML or Meal-Master) or from databases. The package appears to be almost (see below) lintian clean. The upload would fix these bugs: 473367, 478030, 513860 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/krecipes - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/krecipes/krecipes_1.0~beta2-1.dsc I would be glad if someone uploaded this package for me. I have to give you some background information. Maintainer for krecipes is actually Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org. Unfortunately, this is list is mostly dead except from forwarded messages from BTS or PTS. A number of mails I (and others) sent there got no response. Krecipes has not been maintained for over 2 years and the MIA team has requested the removal of the only Uploader a couple of months ago (#513860). Therefore, I would consider krecipes effectively orphaned, allthough not officially. Are there any formal steps I should undertake to take over maintainership for this package? I would really appreciate if someone could either help me to get my krecipes package into Debian. I am just not quite sure whether it is OK to hijack a package like that from an unresponsive packaging team. Should I ask QA to orphan the package? Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
Sune Vuorela nos...@vuorela.dk writes: On 2009-05-19, Matthias Julius m...@julius-net.net wrote: I would really appreciate if someone could either help me to get my krecipes package into Debian. I am just not quite sure whether it is OK to hijack a package like that from an unresponsive packaging team. Should I ask QA to orphan the package? KDE-Extra team has already said go ahead to at least one person being interested in taking over krecipes. (José Manuel Santamaría Lema) Yes, he has taken over krecipes upstream. And he is working on krecipes 2.0 (KDE4). In http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2009-April/001247.html he proposed for me to take care of krecipes for now and to co-maintain it after 2.0 is ready. Most kde communication happens in irc channels. Which is a bit unfortunate because not everyone is living in the same timezone. I like the asynchronous way mailinglists work. I just noticed that he actually cross-posted his messages to pkg-kde-talk. There seems to be a little more human presence. Next time I'll post there. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
Barry deFreese bdefre...@verizon.net writes: Dmitrijs Ledkovs wrote: I'm not a DD, but I think the correct way is to ping MIA team about it and then after 2 weeks time you ping them again and they do a little chat and come up with a solutions usally in your favor. Try that, cause they record stuff in wnpp and then you can go on and adopt stuff. i think the email was m...@debian.org but double check that (Developer's Reference / New maintainer's guide one of them had a chapter dealing with unresponsive developers.) The problem there is that you can't MIA a whole team. Especially since there are a number of active members. Unfortunately, nobody seems to read the team's list or care to reply to mails sent there. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
Sune Vuorela nos...@vuorela.dk writes: On 2009-05-19, Matthias Julius m...@julius-net.net wrote: I just noticed that he actually cross-posted his messages to pkg-kde-talk. There seems to be a little more human presence. Next time I'll post there. That's *NOT* a sponsering list, but sending sponsoring requests there is the straight road into getting fully ignored. OK, I'll keep that in mind. Thanks, this will avoid some frustration. My motivation to post to pkg-kde-extras was the often read recommendation to join some packaging team and then ask the team members (list) for sponsoring. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
José Manuel Santamaría Lema panfa...@gmail.com writes: On Martes, 19 de Mayo de 2009 23:43:50 Sune Vuorela escribió: I don't know how close you follow debian development, but many members of the debian kde people have been quite busy over the last month trying to get kde in testing updated. We do all have a finite time, and krecipe has not been blocking anything for the work. Sure, I perfectly understand this. And I certainly don't want to put any pressure on anyone and I don't expect anyone to jump on my command. This is all supposed to be fun after all. But, it is also nice to get some sort of a response to a question. Yep, I guess is right to RFS here instead of pkg-kde-extras, and potential soponsors have lots of work now. Matthias, I think you did your homework, so just be patient and wait ;) No worries. I just wanted to bring myself back into people's mind. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmemcached
LI Daobing lidaob...@gmail.com writes: 3. consider remove the .la file if you already have a .pc file. Is that a policy/best practice for library packages? ok, consider there is no conclusion here. you can keep this file there. :) But there seems to be a preference to remove it if rdepends don't need it. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: krecipes (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0~beta2-1 of my package krecipes. It builds these binary packages: krecipes - recipes manager for KDE krecipes-data - recipes manager for KDE - data files krecipes-doc - recipes manager for KDE - documentation Krecipes is a KDE application designed to manage recipes. It can help you to do your shopping list, search through your recipes to find what you can do with available ingredients and a diet helper. It can also import or export recipes from files in various format (eg RecipeML or Meal-Master) or from databases. The package appears to be almost (see below) lintian clean. The upload would fix these bugs: 473367, 478030, 513860 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/krecipes - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/krecipes/krecipes_1.0~beta2-1.dsc I would be glad if someone uploaded this package for me. I have to give you some background information. Maintainer for krecipes is actually Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org. Unfortunately, this is list is mostly dead except from forwarded messages from BTS or PTS. A number of mails I (and others) sent there got no response. Krecipes has not been maintained for over 2 years and the MIA team has requested the removal of the only Uploader a couple of months ago (#513860). Therefore, I would consider krecipes effectively orphaned, allthough not officially. Are there any formal steps I should undertake to take over maintainership for this package? Upstream has been dead for 2 years as well, but got recently revived by a different maintainer who released a new version that fixes the long-standing RC bug (#478030) that has kept krecipes out of Lenny. I have packaged the new version and fixed a number of other issues. The only complaint lintian still has is W: krecipes-data: icon-size-and-directory-name-mismatch usr/share/apps/krecipes/icons/crystalsvg/48x48/actions/categories.png 32x32 I don't consider this severe enough to start and fiddle with changing of binary files. Instead, I will try to get this fixed upstream. If this does not happen for some reason I will wait for the 3.0 (quilt) format to be accepted by ftp-master. Also, dh_shlibdeps is complaining about a ton of unnecessary dependencies. I have not yet tried to investigate where those are coming from. Kind regards Matthias Julius -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Here we go ... Paul Wise p...@debian.org writes: On Tue, Apr 28, 2009 at 1:04 AM, Matthias Julius m...@julius-net.net wrote: I would really be grateful if someone could take a look at this package and possibly upload it for me. You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but the current dnshistory package is built against libdb4.6. Should you add another debian/NEWS entry about this? I'm not sure what to do in this situation, could you investigate? As explained in another post this should not affect the user since the database format has not changed. Only the above is a blocker, some other things you may want to look at: Please use $(QUILT_STAMPFN) instead of patch in debian/rules. Please make build-stamp depend on configure-stamp. ./configure gets run twice on my machine in pbuilder due to the above two issues. Fixed. For some reason the mktime test in ./configure takes ages and a lot of CPU in pbuilder and then fails. This should be fixed by running autoconf from the configure target. I get one dpkg-shlibdeps warning, please ask upstream to remove -lm from the link flags: dependency on libm.so.6 could be avoided if debian/dnshistory/usr/bin/dnshistory were not uselessly linked against it (they use none of its symbols). I have not done anything about this. How much harm does this actually do? At least this does not cause extra package dependancy because libm comes with libc6. I get one lintian pedantic complaint: P: dnshistory: copyright-refers-to-symlink-license usr/share/common-licenses/GPL This is fixed as well. I think it might be appropriate to elevate this pedantic notice to info level. I would welcome if you could have a look at the new package which is at the same location on mentors: http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Paul Wise p...@debian.org writes: On Sat, May 2, 2009 at 12:23 AM, Matthias Julius m...@julius-net.net wrote: As explained in another post this should not affect the user since the database format has not changed. Please investigate the DB-upgrade thing Clint mentioned and forward that upstream, with a patch if you are able. Yes, I plan to do that. http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc Uploaded, thanks for your contriibution to Debian :) Thanks a lot. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Matthias Julius m...@julius-net.net writes: Paul Wise p...@debian.org writes: I don't see anything in the maintainer scripts that would migrate the db files. Does dnshistory or libdb handle upgrading the on-disk db format? Or can libdb handle older versions of the on-disk db format? I was assuming the latter. But, reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html this does not look like a safe assumption. According to http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html it is not even safe to assume that the API of a new major or minor version is backwards compatible. This means that a binNMU triggered by a libdb transition may cause the application to FTBS or not to work correctly. Therefore, I am beginning to think that build-depending on libdb-dev is not such a good idea. I am considering to build-depend on libdb4.7-dev to address a number of issues: - dnshistory can be tested when it is to be rebuilt with a new libdb version - when the database files need to be upgraded this can be mentioned in debian/NEWS - this allows to skip a couple of libdb versions potentially saving the users unnecessary database upgrades. Of course, this means there will be a new upload necessary every time the libdb version used is supposed to be dropped from the archive. Are there other reasons why I should not do that? Is there a convenient way to find all reverse build-depends of a package? Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Clint Adams sch...@debian.org writes: Typically the fear which motivates this type of question is unfounded. Looking at the dnshistory source code, it appears that the use of BDB is trivial. Generally when the feature set you require could just as easily have been satisfied by GDBM, there are rarely compatibility worries. dnshistory is using simple B-trees, which haven't changed incompatibly in over 5 years. If, in a future BDB version, the database file created by dnshistory is using too old a format, the attempt to open it would return DB_OLD_VERSION, and you could add code to dnshistory to DB-upgrade() the file, seamlessly resolving the issue. It would be a different story if dnshistory were using transactions or other subsystems. I believe this is a clear case of build-depending on libdb-dev being the proper solution. Thank you for your explanation. I will keep it as it is then. And since the database format did not change from 4.6 to 4.7 there should be nothing for the user to worry about. I will take care of the other issues and upload a new package to mentors soon. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Paul Wise p...@debian.org writes: You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but the current dnshistory package is built against libdb4.6. Should you add another debian/NEWS entry about this? I'm not sure what to do in this situation, could you investigate? I am not quite sure how to deal with that one. Since Luk Claes NMUed the package to change the Build-Depends from libdb4.4-dev to libdb-dev I don't really have control over which libdb version dnshistory is built against. If it happens that a new libdb is uploaded before dnshistory has been built on all archs or if a binNMU is triggered by a libdb transition debian/NEWS will be outdated. I wonder how other packages build-depending on libdb-dev handle this. That entry in debian/NEWS is somewhat special in that the dependancy on libdb had been downgraded from 4.5 to 4.4 in order to allow dnshistory to migrate into testing (etch at the time) and libdb4.5 was being kept out. On upgrade I would expect db files to be migrated if necessary. Only the above is a blocker, some other things you may want to look at: Please use $(QUILT_STAMPFN) instead of patch in debian/rules. Please make build-stamp depend on configure-stamp. ./configure gets run twice on my machine in pbuilder due to the above two issues. I will take care of that. For some reason the mktime test in ./configure takes ages and a lot of CPU in pbuilder and then fails. As explained by Sven this is due to an outdated ./configure. What is the best way to deal with that? Ignore? Run autoconf from debian/rules? Bug upstream? I get one dpkg-shlibdeps warning, please ask upstream to remove -lm from the link flags: dependency on libm.so.6 could be avoided if debian/dnshistory/usr/bin/dnshistory were not uselessly linked against it (they use none of its symbols). How important is this? I doubt upstream will release a new version just to fix those minor issues. I get one lintian pedantic complaint: P: dnshistory: copyright-refers-to-symlink-license usr/share/common-licenses/GPL Good catch, I will fix that, too. You might want to review the debtags and upload a screenshot: Since this is a console application and not primarily meant to be run directly by the user a screenshot is probably not very beneficial. Thanks for reviewing my package. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Paul Wise p...@debian.org writes: I don't see anything in the maintainer scripts that would migrate the db files. Does dnshistory or libdb handle upgrading the on-disk db format? Or can libdb handle older versions of the on-disk db format? I was assuming the latter. But, reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html this does not look like a safe assumption. Unless the application itself checks the libdb version and upgrades its database files. At least with the transition from 4.6 to 4.7 the database file format did not change. Bug upstream and run autoconf until the next upstream release. OK. I'll try to do that. IMO screenshots of console apps can still be useful. Sure, but this is mostly intended to be used as a pre-processor by other applications like awffull or webalizer. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Matthias Julius li...@julius-net.net writes: I am looking for a sponsor for the new version 1.3-2 of my package dnshistory. It builds these binary packages: dnshistory - Translating and storing of IP addresses from log files The package appears to be lintian clean. The upload would fix these bugs: 434881 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc I have contacted my previous sponsor twice in the last couple of weeks. He did not respond to my emails. I would be glad if someone uploaded this package for me. I would really be grateful if someone could take a look at this package and possibly upload it for me. Besides fixing that minor man page bug this is essentially a house-keeping upload. Here is the changelog entry for this upload: , | dnshistory (1.3-2) unstable; urgency=low | | * Acknowledge NMU | * Fix default location of database file in man page (Closes: #434881) | * Update Standards-Version to 3.8.1 | * Don't ship config.guess and config.sub in source package, we take them from | autotools-dev anyway | * Make Homepage its own field in debian/control | * Now using quilt; added debian/README.sources | | -- Matthias Julius m...@julius-net.net Fri, 13 Mar 2009 13:27:43 -0400 ` Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: dnshistory (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3-2 of my package dnshistory. It builds these binary packages: dnshistory - Translating and storing of IP addresses from log files The package appears to be lintian clean. The upload would fix these bugs: 434881 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc I have contacted my previous sponsor twice in the last couple of weeks. He did not respond to my emails. I would be glad if someone uploaded this package for me. Kind regards Matthias Julius -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
debian/copyright verbosity
In the light of the recent discussion about debian/copyright on -devel I am wondering how verbose it actually needs to be. Given the following files: Files: foo.c Copyright: 2006 Mr. X License: GPL2+ Files: bar.c Copyright: 2008 Mr. X License: GPL2+ Files: baz.c Copyright: 2005 Mr. Y License: GPL2+ This would be the most explicit form preserving the exact copyrights for each file. Would it be acceptable to condense this to: Files: foo.c bar.c Copyright: 2006, 2008 Mr. X License: GPL2+ Files: baz.c Copyright: 2005 Mr. Y License: GPL2+ or even further to: Files: *.c Copyright: 2006, 2008 Mr. X Copyright: 2005 Mr. Y License: GPL2+ especially for files under (L)GPL? Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/copyright verbosity
Neil Williams codeh...@debian.org writes: On Mon, 13 Apr 2009 17:24:51 -0400 Matthias Julius li...@julius-net.net wrote: I'd say condense all those down so that you only mention the one licence once. There's no harm in collating copyright as long as the licences are consistent (licence and versioning). Separate GPL-2 from GPL-2+ and GPL-3+ but if all are GPL-2+, it's fine IMHO. Yes, of course. or even further to: Files: *.c Copyright: 2006, 2008 Mr. X Copyright: 2005 Mr. Y License: GPL2+ especially for files under (L)GPL? I'd be happy with that. Me too. Other opinions? You still need the licence notice itself and I always put in the line about finding the licence in /usr/share/common-licences/ as well as the download location. debian/copyright doesn't need to be verbose but it does need to be complete and understandable by ftpmaster. That certainly makes sense. Thank you, Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Fwd: Re: [jack-mixer]bin/sh: no: command not found]]
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Mon, Apr 06, 2009 at 12:09:50PM +0200, Grammostola Rosea wrote: make[3]: Entering directory `/tmp/buildd/jack-mixer-6' GCONF_CONFIG_SOURCE= no --makefile-install-rule ./jack_mixer.schemas ^^ It's still that space right there. make is trying to call the command 'no', instead of assigning the value to the variable GCONF_CONFIG_SOURCE. From the Make Manual: , | 6.5 Setting Variables | | To set a variable from the makefile, write a line starting with the | variable name followed by ‘=’ or ‘:=’. Whatever follows the ‘=’ or | ‘:=’ on the line becomes the value. For example, | |objects = main.o foo.o bar.o utils.o | | defines a variable named objects. Whitespace around the variable name | and immediately after the ‘=’ is ignored. ` So the space should not hurt. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITR: varkon (updated package)
Paul Wise [EMAIL PROTECTED] writes: Better to run a test suite or otherwise cause an FTBFS on architectures where it is known to build broken or unusable binaries. Not being fully portable isn't an RC bug and will not block testing migration unless it is a regression and there is no good reason to block it from lenny if it only works on 32-bit arches. OK. This is another way. I will have to think about it for a while to come up with a good way to do that. Are there any opinions against this approach? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: varkon (updated package)
Matthias Julius [EMAIL PROTECTED] writes: Matthias Julius [EMAIL PROTECTED] writes: I will address the other points you mentioned earlier and also the issues Erik mentioned tonight (hopefully, maybe tomorrow) when I get home. OK, it took a little longer than two days, but I had a lot of things going on. And I fixed a couple more little issues I discovered myself. I have tried to address all of your concerns except the varkon: arch-dep-package-has-big-usr-share message from lintian which I want to take care of in a later upload. Also I havn't come up with example files, yet. I am currently trying to do that. This beast is trickier than I thought. I have started a discussion on the Varkon mailing list and confirmed that the files the package puts in /usr/share/varkon are in fact arch specific. I will therefore move them to /usr/lib/varkon. Also, Varkon is not 64bit safe. I have noticed myself that the compiler complains a lot about castings between integers and pointers of different size when I build it for amd64. When asked on the list upstream also confirmed that Varkon currently does not support 64bit archs. What is the best way to deal with that issue until it is fixed properly upstream? Should I just disable all 64bit architectures for the varkon package? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: varkon (updated package)
Erik Schanze [EMAIL PROTECTED] writes: IMO excluding of architectures is good if the program makes no sense on it, e.g. because of missing hardware. In your case it is a problem of unportable code, you should fix it before. Yes, generally I agree with you. But properly fixing the code certainly will take some time and I would like to get the package into sid before that, so people can start playing with it. I could file an RC bug myself to prevent it from migrating into testing and to let people know that it is going to be flaky on 64bit archs. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: varkon (updated package)
Matthias Julius [EMAIL PROTECTED] writes: Dear mentors, I am looking for a sponsor for the new version 1.19B-1 of my package varkon. [...] The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/varkon - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/varkon/varkon_1.19B-1.dsc Sadly, nobody here seems to be interested in this package. I would be very grateful if someone could take a look at it and ultimately sponsor it for a couple of reasons: - the version in Debian is over 3 years old - there are currently 178 installations according to popcon that deserve to be updated to the current version - Varkon is the only free parametric 3D CAD application (that I know of) and I would like to promote it by making it easily available to Debian users - the current varkon package FTBS on armel because it build-depends on gcc-3.3 which is not available on armel (and according to one of the armel porters it is the last package having this problem) Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: varkon (updated package)
Neil Williams [EMAIL PROTECTED] writes: Try with: 1. Wrong directory for manual: ./usr/share/varkon/man/ should be ./usr/share/doc/varkon-user-manual/ i.e usr/share/doc/$package_name/ Same for varkon-programmer-manual Modify the doc-base files accordingly and change the symlink to the other direction. I can do that. 6. From TODO: * [postponed]Move libfiles (*.MBO) into seperate package (they are platform independent)? More detail on that please - why was that postponed, why not use /usr/lib/ instead of ./usr/share/varkon/lib/ ? That's the reason you're getting arch-dep-package-has-big-usr-share. Is the question mark denoting that there is a query if these are platform independent or just whether to move them because they are known to be platform independent? This is my interpretation as well. TODO is from the previous maintainer. I am planning to confirm with upstream whether or not these files are architecture independent. I didn't want to wait with uploading the new package since those files are in the same location in the package currently in Debian. So, in any case this is not a regression. Testing continues Thanks a lot for that. I will address the other points you mentioned earlier and also the issues Erik mentioned tonight (hopefully, maybe tomorrow) when I get home. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I'm sorry
Ricardo Mones [EMAIL PROTECTED] writes: You can start reading the New Maintainer Guide [0], which will point you to the Work-Needing and Prospective Packages [1], where you can look for some orphaned package you may take care of. [0] http://www.debian.org/doc/manuals/maint-guide/index.en.html [1] http://www.debian.org/devel/wnpp Under [1] is also a list for requested packages. You can check there if you find one of them interesting and worth packaging. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex (updated package): 2nd try
Leo \costela\ Antunes [EMAIL PROTECTED] writes: Andreas Hoenen wrote: I have just uploaded dblatex 0.2.8-2 to mentors.debian.net [1]. Regarding the new lintian warning 'spelling-error-in-changelog' I have opened a bug report [2]. [1] dget http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.2.8-2.dsc Now there's just one last minor problem: since you closed some bugs on 0.2.8-1 which never got uploaded, you would have to close them manually as the automatic bug handling wouldn't be triggered for them. Or you (the sponsor) use dpkg-buildpackage -vlast version in archive when building the package to be uploaded. Then all relevant changelog entries will be included in .changes. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: varkon (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.19B-1 of my package varkon. It builds these binary packages: varkon - CAD system with parametric modelling varkon-programmer-manual - programmer manual for Varkon's MBS language varkon-user-manual - user manual for Varkon The package appears to be lintian clean. The upload would fix these bugs: 387800, 419086, 438255, 453009 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/varkon - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/varkon/varkon_1.19B-1.dsc I would be glad if someone uploaded this package for me. I have just adopted the package. It is a new upstream version. The version currently in sid is quite outdated. In an earlier run lintian complained about a large /usr/share. For the next release I will confirm with upstream that the files there are really architecture independent and split it into a -data package if appropriate or move the files into /usr/lib/varkon. Kind regards Matthias Julius -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: yes, GPL means GPL3 today... (Re: RFS: gnome-color-chooser)
Russ Allbery [EMAIL PROTECTED] writes: Agreed. I think debian/copyright should always refer to the exact version of the GPL that the package says it's covered under and then document whether only that version is permissable or whether the or later part is available. (The exception is GPL v1, which isn't in common-licenses; in that case, right now, I think the best course of action is to treat the software as under GPL v2 for Debian's purposes. There isn't a lot of software in this category.) I think the best way is to include the license text in debian/copyright just like any other license that is not in common-licenses. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: colordiff
Russ Allbery [EMAIL PROTECTED] writes: Dave Ewart [EMAIL PROTECTED] writes: Yes, I do run lintian (and linda), but the spare machine I used to build the packages was running Lenny at the time I built them. It's now Sid ;-) You can also pin lintian in particular to unstable on a system that's otherwise testing. It's arch: all, so it shouldn't pull in a lot of other packages. To build packages on sid is probably a good idea anyway. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog-should-mention-nmu
chaica [EMAIL PROTECTED] writes: W: yougrabber source: changelog-should-mention-nmu N: N: When you NMU a package, that fact should be mentioned on the first N: line in the changelog entry. Use the words NMU or Non-maintainer N: upload (case insensitive). N: N: Maybe you didn't intend this upload to be a NMU, in that case, please N: doublecheck that the most recent entry in the changelog is N: byte-for-byte identical to the maintainer or one of the uploaders. N: W: yougrabber source: source-nmu-has-incorrect-version-number 0.29.2-1 N: N: A source NMU should have a Debian revision of '-x.x'. This is to N: prevent stealing version numbers from the maintainer (and the -x.x.x N: version numbers are reserved for binary-only NMU's). N: N: Maybe you didn't intend this upload to be a NMU, in that case, please N: doublecheck that the most recent entry in the changelog is N: byte-for-byte identical to the maintainer or one of the uploaders. N: My package is the first debian package for this soft. My debian/changelog is the following: yougrabber (0.29.2-1) unstable; urgency=low * Initial release. -- carl [EMAIL PROTECTED] Thu, 06 Dec 2007 11:42:20 +0100 This should be your full name. Any idea what could be wrong? Thx. What is the content of the Maintainer and Uploaders fields in debian/control? As mentioned in the explanation above the name in debian/changelog needs to match one of those. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnome-color-chooser
Holger Levsen [EMAIL PROTECTED] writes: ./src/gnome-color-chooser.1 says the licence is GPL, which means GPL3, while debian/copyright says the software is GPL2+... please fix. Does it really mean GPL3? Do I have to compare the release date of a software with the publishing date of the various GPL versions to determine which one applies if it is not specified? I don't think this is reasonable. Are now all packages buggy that reference /usr/share/common-licenses/GPL instead of GPL-2 because GPL now points to GPL-3? That is probably a large portion of the archive. the GPL symlink should be removed alltogether to avoid similar issues when the next GPL version comes along. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When should versionned dependancies be dropped ?
Russ Allbery [EMAIL PROTECTED] writes: Charles Plessy [EMAIL PROTECTED] writes: I am preparing a package using the makefile include for quilt, which appeared in the quilt package starting from version 0.40. Only oldstable has an inferior version. Would there be any benefit to remove the version number in the dependancy, or shall I keep it ? I have a similar question about this for maintaining lintian, since currently lintian will complain about a wide variety of versioned dependencies that are necessary for proper behavior with oldstable but are no longer needed with stable. Should I just drop them? Is there benefit in retaining them? I would keep the versioned dependency as long as there is a inferrior version available on the mirrors. And I think lintian should not complain about suche a dependency. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: A very special package
Pierre THIERRY [EMAIL PROTECTED] writes: Scribit Michael M. dies 02/04/2007 hora 07:48: This sounds great, but could you please advice which brand of popcorn meets the DFSG? I wouldn't want to violate the spirit of the endeavor. Probably only the one with traceability information, so you have the possibility to access the source of the popcorn. Don't forget about the scripts used to compile the popcorn (also known as recipe). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
Romain Beauxis [EMAIL PROTECTED] writes:
As far as I know it is not.
A native debian package can have a single tar.gz but not a package with
upstream releases..
This is also handy when uploading new debian releases since you don't have to
upload the orig tarball at each time.. How would you have such a possibility
without the diff.gz ?
Well, we were talking about two tar.gz files, the orig.tar.gz and a
{debian|diff}.tar.gz instead of the diff.gz. If the diff.gz file
actually does not modify any file when it is applied there is no
reason for it to be a patch file. Instead it could be an archive
which is unpacked into debian/
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
Charles Plessy [EMAIL PROTECTED] writes: Having a simple and straghtforward patch system would lower the bar for new packagers, as well as open the way to have .diff.gz files which would only touch the debian directory, instead of containing a mixture of packaging instructions, code changes, and autoconf gizmo (another Debian nightmare which I do not understand the benefit). If nothing in the diff.gz touches files outside of debian there is actually no need for it to be a diff. It could be debian.tar.gz which would be able to preserve file permissions and symlinks. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GIMP plugins for refocussing blurred images
This question is better placed on [EMAIL PROTECTED] So, I am crossposting it there Bernd Zeimetz [EMAIL PROTECTED] writes: Hello, since I'm not only a geek but also a photographer and GIMP user I've decided to have a look at wnpp bug #398765 [1] and package the plugin [2]. While packaging gimp-refocus I came across the refocus-it plugin, which uses a different algorithm and also supports to refocus motion blur, so I've decided to package it, too [3]. It seems to be much slower, though - but it provides a command-line version which works totally independent of The GIMP, it only depends on libc6. I've commented and described the issues of both plugins at the given urls, testing and comments would be very appreciated. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398765 [2] http://bzed.de/debian/packages/gimp-refocus [3] http://bzed.de/debian/packages/gimp-refocus-it Thanks a lot, Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translations of the menu system.
Linas Žvirblis [EMAIL PROTECTED] writes: Charles Plessy wrote: I was kindly pointed out on -devel that the Debian menu system can handle translations in its files. No, it cannot. Not only that, but there also is no clear idea on HOW and WHAT exactly it should do. There are simply way too many political and technical issues unsolved. People claimed that menu files already supported translations when .desktop files were not even conceived. Matthias
Re: RFS: dnshistory
Daniel Baumann [EMAIL PROTECTED] writes: Matthias Julius wrote: - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.2-1.dsc please fix the following things: [...] if you fix above things, i'm happy to sponsor it. And I am happy that you are willing to do so. This list was longer than I expected, but I appreciate that you took the time to generate it. I hope I have fixed all the issues you have pointed out. The updated version can be found at: - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.2-2.dsc Thanks, Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dnshistory
Daniel Baumann [EMAIL PROTECTED] writes: Matthias Julius wrote: This list was longer than I expected, but I appreciate that you took the time to generate it. I hope I have fixed all the issues you have pointed out. everything, except: * debian/copyright has a useless empty line at the end of the file. Oops, sorry, fixed. additionally, it doesn't make sense to bumpt the revision for packages not uploaded to the archive (and not in wide use unofficially). i recommend to drop the -2 entry. Hmm, the opinion on this matter seems to be somwhat devided. Some people suggest the revision should be increased every time an upload is made to a public place like mentors.d.n. I have reverted to -1 since there wasn't any valuable information for -2 anyway. It can be found at: - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.2-1.dsc Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dnshistory
Daniel Baumann [EMAIL PROTECTED] writes: Matthias Julius wrote: Hmm, the opinion on this matter seems to be somwhat devided. Some people suggest the revision should be increased every time an upload is made to a public place like mentors.d.n. if you insist on having it bumped, do it. i /personally/ would do it, i consider it very useless and ugly. No, I don't insist. I just thought that it was usual practice. I have reverted to -1 since there wasn't any valuable information for -2 anyway. It can be found at: this -1 here is wrong, it contains none of the previous changes (yes, i made sure it's not from a proxy or cache). Sorry, my bad. I forgot to sign it and didn't wait for dupload to finish. Should be fixed now. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dnshistory
Daniel Baumann [EMAIL PROTECTED] writes: Matthias Julius wrote: Sorry, my bad. I forgot to sign it and didn't wait for dupload to finish. no problem. checked again and uploaded it. Thanks a lot. if you need further sponsoring, contact me off-list http://people.debian.org/~daniel/documents/sponsoring.html#contact Thanks again. It doesn't look like this package will receive a whole lot of updates however. But - I will let you know if it does :-) Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proper way to package mozilla extensions
Yaroslav Halchenko [EMAIL PROTECTED] writes: xpi and jar is the source -- it is just packaged with the other than tar/gzip archiver and nested in each other to make our life fun ;-) That is why there is no alternative tarball with the true source is often provided (even if the license is GPL) -- at least I didn't mention any on https://addons.mozilla.org. I will check with the upstream if they will not mind provide .tar.gz as well... Sometimes Mozilla extensions contain other binaries. One example that I know is the Html Validator extension. And I know that because my AMD64 Firefox loads the i386 version of this extension. And when I try to use it Firefox says it is not compatible. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doing RFS on -mentors
Panu Kalliokoski [EMAIL PROTECTED] writes: I understand this, but it was exactly the same situation as with my software packages -- they didn't have separate packaging and upstream changes. There have been two times in their history when only packaging information has been changed: when I added packaging for the first time, and when I incorporated the fixes proposed on -mentors. Other packaging changes have always been accompanied with changes in the software itself. Note that technically even Debian specific packages can quite easily be separated into packaging-related and other stuff. But there is no such separation even in non-native packages. The .diff.gz file may not only contain packaging related stuff but also patches to the content of the package. And for native Debian packages it probably really does not make sense to supply patches to the source. On the other hand I don't see the benefit in the distinction between native and non-native packages. I don't think the overhead would be too terrible if native packages were treated the same as non-native ones. But, I could see a benefit from separating packaging information from the source. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
