Re: RFS: ballview - A free molecular modeling andmoleculargraphics tool
Hi, I have just uploaded a new version of the package and most issues should be fixed now. I would be glad if someone could have a look at it and maybe find remaining mistakes. Yours sincerely Andreas Moll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 01:14:59PM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:46:20 +0100, Marc Haber [EMAIL PROTECTED] said: On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber [EMAIL PROTECTED] said: There is no need to fork ucf to create a command that provides functionality not in ucf. the intersection between zmct (zugschlus' magical conffiles tool) and ucf would be non-negligible and a lot of routine stuff would need to be present in both packages. err, why would there be anything non-negligible beyond a single grep call in common? I fail to see why there will be mounds and mounds of common stuff -- as the tetex example already demonstrates. I haven't thought about this in the necessary depth. To a newbie DD who has only been with Debian for six years it looks like ucf is not completely finished. And, arguably, this functionality should be in a different script anyway, perhaps one that can read the simple ucf cache, which, given the installed base, is unlikely to change from under you. Where is the documentation of the stable interface to ucf's cache that is reliable not to change between ucf releases? My goodness. Are we so lost in ISO 9000 processes that we need formal documentation to realize that ucf hash files have a md5sum and a file path? And to realize that the hashfile exists on user machines, and changing formats will be a major effort now? ucf could suddenly start to write the hashfile in some other format while still being able to read the old format. If a change like this is not coordinated between the hypothetical zmct and ucf, all packages using zmct will suddenly be RC-buggy. And I remember you scolding me for using an internal kernel-package interface back in 2001. This has nothing to do with ISO900x (which I hate with a passion). It is about stability. Then it is good for you tat the tetex folks hve written the (simple) wrapper code for you -- and the complex common part was: md5sum=$(grep $file$ /var/lib/ucf/hashfile | cut -f 1 -d ' ') I suspect that there is some wrapper code needed anyway which is the actual hard part (taking care of special cases). Additionally, imagine this code being scattered away to 100 packages and then some obscure bug surfacing. Currently, ucf does a lot less than dpkg does. What ucf does, it does much better than dpkg. But since there are still things that dpkg handles quite well while ucf basically says well, code it yourself, ucf does not provider conffile like handling as it is advertising in its package description. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Sat, Jan 20, 2007 at 07:03:24PM +0100, Florent Rougon wrote:
Marc Haber [EMAIL PROTECTED] wrote:
but ucf does not know about the file any more if it is not in the new
package and will therefore not handle it.
Uh, if you don't 'ucf --purge' it, I fear it will remain in the ucf
cache. There is code doing what you want in tetex-bin (not written by
me). For instance, in debian/common.functions.in, you can find:
ucf_md5sum(){
file=$1
md5sum=$(grep $file$ /var/lib/ucf/hashfile | cut -f 1 -d ' ')
if [ -z $md5sum ]; then
get_sarge_md5sum_from_list $file
fi
echo $md5sum
}
[...]
preinst_remove_or_move_ucf(){
file=/etc/texmf/$1
newname=$(get_newfilename $1)
debug $file
test -f $file || return 0
debug handled\n
oldmd5sum=$(ucf_md5sum $file)
currmd5sum=$(md5sum $file | cut -d ' ' -f 1)
if [ $oldmd5sum != $currmd5sum ]; then
mv $file $oldstuff_dir/$(basename $file).$PREINST_MOVE_EXT
else
rm $file
if [ -x /usr/bin/ucf ]; then ucf --purge $file; fi
fi
}
These are 23 lines of code which have the potential for a lot of bugs.
I do not think it is a good idea to cutpaste this code into a hundred
packages.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: crotch
Hi, Chris Amthor wrote: I would be glad if someone uploaded this package for me. IANADD so i cannot upload it for you, but anyways some comments. Hope they help you. * General: - public-key-file: What is it for? As far as I see, you don't package it, so why should you need to include it? - Your package does not include a manpage for a binary. Thats not an 'error', but is highly recommended and the fact that there is none, results in a lintian warning. - upstream source should unpack to name-version, not name-version.orig - I would recommend not do make changes to upstream sources directly. Instead (if you really need to do so) make use of a patch system, like dpatch - Personally i find it better to have a as-clean-as-it-could-be build, without warnings. You could fix warnings yourself with patches or ask upstream to do so. In every case you may want to inform the upstream author. * debian/copyright: - Policy states that the copyright file must say where the upstream sources (if any) were obtained so you should do so. - Also *I* would include an excerpt of the license, as many others do, so that the user, who might not be interested in reading the full license can read the basic aspects without opening another file. As an (unfortunately more 'advanced') example you could have a look at mantis) - I find that the empty line at EOF is unneeded, so it could be removed * debian/rules: - In general i would tidy this file a little bit up (e.g removing unneeded empty lines between commands inside of a target, removing dh_make comments) - You could use install -d to create the directory usr/bin and save yourself from the dirs file and the dh_installdirs call or even better (imho): Instead of calling make install you could install it yourself with install -D which will create the directory AND you will not need to edit upstream source. - There is no need for the commented calls in debian/rules. If you need it for you to remember you can recreate this dh_make template any time. * debian/changelog: - Doesn't your build close any bug? Normally it would at least close an ITP bug, which should exist so that others see that there is someone working on this package. * debian/control: - Description should contain the Upstream URL, like so: hints unreadable at the first glance. . Homepage: * debian/compat: - Your compatibility level is 4, but thats old. Instead you may want to use the current level 5. Greets Patrick signature.asc Description: OpenPGP digital signature
Re: Removing self-managed configuration files?
Marc Haber [EMAIL PROTECTED] wrote: These are 23 lines of code which have the potential for a lot of bugs. I do not think it is a good idea to cutpaste this code into a hundred packages. I didn't know you were alone maintaining a hundred of packages that need this particular removal code. Interesting. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Wed, Jan 24, 2007 at 02:37:46PM +0100, Florent Rougon wrote: Marc Haber [EMAIL PROTECTED] wrote: These are 23 lines of code which have the potential for a lot of bugs. I do not think it is a good idea to cutpaste this code into a hundred packages. I didn't know you were alone maintaining a hundred of packages that need this particular removal code. Interesting. You seem to be deliberately misunderstanding me. I'll stop wasting my time. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: native packages
Roberto C. Sanchez roberto at connexer.com writes: A parallel branch structure might make sense in your case. Then you can just merge trunk changes up to your branch periodically. As long as you use dpatch and don't touch any upstream files, you will never have a conflict. [EMAIL PROTECTED]@separate patches in debian/patches/@ There's more than one way to keep patches, and personally you might conflicts with me if you use dpatch on too large a project. And I like quilt very much. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: crotch
Hi, haven't known that you are the author, so some things are different: Chris Amthor schrieb: Hi Patrick, [EMAIL PROTECTED] wrote: [...] IANADD so i cannot upload it for you, No problem. but anyways some comments. Hope they help you. Yes, they helped, though I still have some questions left. Thank you very much! Since this is my first attempt to get a package into Debian, any advice is more than appreciated. Especially the technical parts were indeed helpful. The main part I still do not get is that upstream/author/URL thing. I wrote the C code, I wrote the Makefile, I invented the name and I built the packages for i386, powerpc and sparc. The only official sources for crotch are my webserver and my fileserver. Okay, so *you* are upstream. So ask yourself the question: Do you intend to publish it *only* in Debian (personally I think there is no good reason for that)? If not, you may/should provide a website, on which others can download the software, too. Then you would include this homepage in the apppropriate places of your package and provide a proper orig tarball, a debian diff, etc. But you even have it easier, cause you can change your original source, e.g. regarding the install process instead of rewriting it in debian/rules or helping out with patches. So why do I have to make a difference between the packager, the maintainer, the author? The URL I got the sources for building the packages was: file:///mnt/nfs/Develop/C/crotch/crotch-1.0.1/, that cannot be of any use if I mention it in the package. Btw. you do not have to make a difference between the packager/maintainer/author but you should tell at the right places who it is. See above comments. But I'll go through my questions one by one: [...] - public-key-file: What is it for? As far as I see, you don't package it, so why should you need to include it? Well, dput refused to upload the unsigned package. So I took my GPG key and things worked. Which point did I miss? Well, but for signing your .changes files you do not need to carry your key with the package. Indeed it must not be there. - Your package does not include a manpage for a binary. Thats not an 'error', but is highly recommended and the fact that there is none, results in a lintian warning. Ahem, correct. That's for two reasons: firs crotch only understands two arguments, no options in only uses STDIN and STDOUT, therefore I thought I could omit a manpage. Second, I do not know how to write manpages... :o( Okay, so it does not have much to say in the man. But users might ask the man first if they want to know, which parameters your software has. Also: You can include an information about you as the AUTHOR and informations about how they can provide bugreports. About writing of man pages. It is easier then writing applications. Just open up an existing manpage in an editor and look at it. On the first sight it might look a little bit obscure, but it isn't. Even I am able to write manpages (but I cannot code much C) [...] You could fix warnings yourself with patches or ask upstream to do so. In every case you may want to inform the upstream author. So I have to inform myself? Isn't the upstream my upload itself, hence me the author? Haha. Ofcourse you don't need to inform yourself. But you can fix it in upstream source ;-) Why should I let others see that I'm packaging S/W that nobody knows of? Everyone that already has got the software could ether get the source tarball or a package, so why should anyone go repackage it? Or is there a general difference in the procedure of getting bugfixes upoloaded than getting initial packages uploaded? Not really. An ITP is a bugreport on bugs.debian.org which is handled a bit different. Say: It is listed on the WNPP page [1]. But you are right. If nobody yet knows that your software exists you don't need to WNPP. * debian/compat: - Your compatibility level is 4, but thats old. Instead you may want to use the current level 5. Hmm, with level 5 dpgk-buildpackage failed for some reason. I think I'll have to check this once again. Have a look at man debhelper. It lists the differences between the different compat levels. Anyways, thanks for your help and best regards, You're welcome. Best Regards Patrick [1] http://www.debian.org/devel/wnpp/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber [EMAIL PROTECTED] wrote: I didn't know you were alone maintaining a hundred of packages that need this particular removal code. Interesting. You seem to be deliberately misunderstanding me. I'll stop wasting my time. I meant that when a maintainer copies code in its maintainer scripts, he *must* read the code carefully and understand it. Therefore, if a hundred maintainers do that as you suggest, there is a very high probability that most, if not all, bugs are found during the process. You know, the eyeball theory. But here, it really should work, as maintainers are *really* expected to carefully check what they put in their maintainer scripts (contrary to the general flaw in the eyeball theory, where the actual eyeballs scrutinizing the code are not that numerous for most projects IMHO). And finally, please accept my apologies for having wasted your precious time correcting your question (where the use of conffile was wrong, and that of ucf not even mentioned), your algorithm (which was missing 'ucf --purge') and extracting the relevant portion of code from tetex-bin that does what you want. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN snapshot versioning
Russ Allbery [EMAIL PROTECTED] wrote: In other words, use previous-version+svn-stuff if you're packaging that version plus some additional upstream modifications, and use next-version+svn-stuff if you're packaging an alpha or beta arelease ^ I hope you meant '~' here. of next-version. Well, you're free to do what you want with that. I gave my opinion, no need to repeat it. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Wed, Jan 24, 2007 at 04:13:24PM +0100, Florent Rougon wrote: Marc Haber [EMAIL PROTECTED] wrote: I didn't know you were alone maintaining a hundred of packages that need this particular removal code. Interesting. You seem to be deliberately misunderstanding me. I'll stop wasting my time. I meant that when a maintainer copies code in its maintainer scripts, he *must* read the code carefully and understand it. Therefore, if a hundred maintainers do that as you suggest, there is a very high probability that most, if not all, bugs are found during the process. I doubt this. Additionally, this is a huge waste of maintainer time. Code like this _BELONGS_ into a standardized tool. Following your course of argumentation, why not have debhelper removed from the archive? And finally, please accept my apologies for having wasted your precious time correcting your question (where the use of conffile was wrong, Mea culpa for writing a wrong subject. Please have my posting privileges to -mentors removed for two years as punishment for this terrible mistake. Millions of innocent bits had to be flipped because I wrote a wrong subject over a correctly worded question. If you find some more efficient punishment, such as force-orphaning all my packages or having me expelled from the project, please go ahead. and that of ucf not even mentioned), That was a deliberate omission since the challenge is independent of ucf. Actually, the challenge is there _BECAUSE_ ucf was not designed to address this issue (which it actually should) and its maintainer considers this missing feature a feature. your algorithm (which was missing 'ucf --purge') My algorithm assumed a ucf-less setup as the issue at hand is independent of ucf. ucf doesn't help here. and extracting the relevant portion of code from tetex-bin that does what you want. Thanks for doing so. Seeing that code has reconfirmed my opinion that this task is so common and so complicated that there needs to be a standarized tool to handle this issue, and I still feel that the right place to do this is the tool that claims to be able to replace dpkg conffile (sic!) handling, ucf. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
Marc Haber [EMAIL PROTECTED] wrote: I doubt this. The code is definitely not what I call complex. The tetex-bin package is, but not that particular piece of code, once isolated. Additionally, this is a huge waste of maintainer time. Code like this _BELONGS_ into a standardized tool. Following your course of argumentation, why not have debhelper removed from the archive? You're resorting to hyperbole and putting words in my mouth (sorry, don't know how to express that well in english). Of course a standard tool for doing that would be nice, but there is no such tool now, as it seems. Now, ask yourself: when debhelper didn't exist, did people refuse to make packages because there ought to be a standard easy-to-use tool for doing all these little things? As Manoj explained you, a standard tool won't magically pop up if everyone is passively waiting for it. I still feel that the right place to do this is the tool that claims to be able to replace dpkg conffile (sic!) handling, ucf. This sic has nothing to do here. ucf indeed performs a comparable task as dpkg's conffile handling. Remember: dpkg does _nothing_ particular for configuration files that are not conffiles. The particular handling that ucf is trying to replace is therefore aptly named dpkg's conffile handling. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
broken packages?
Hi, I have a package called morg-mailcommands that depends on Postfix. Trying to install it with aptitude gives E: Unable to correct problems, you have held broken packages. E: Unable to correct dependencies, some packages cannot be installed E: Unable to resolve some dependencies! Some packages had unmet dependencies. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following packages have unmet dependencies: morg-mailcommands: Depends: postfix but it is not installable Removing all exim4 packages fixes the problem, however I would like to ask: * aptitudes says I have held broken packages. `dpkg --get-selections` says I have no held packages at all. Is this a (small) bug in aptitude? * Why is my package considered broken? All dependencies are correct. Should it explicitly conflict with exim4? (I think this is pointless since postfix already does.) * How can I make aptitude to remove exim4 when installing morg-mailcommands? Even the -f flag to aptitude doesn't help. Thanks, -- Szabolcs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Wed, 24 Jan 2007 12:52:53 +0100, Marc Haber [EMAIL PROTECTED] said: I haven't thought about this in the necessary depth. To a newbie DD who has only been with Debian for six years it looks like ucf is not completely finished. ucf scratches the itch I had to begin with, and it does everything my packages need it to do. Feature creep is to be guarded against. I suspect that there is some wrapper code needed anyway which is the actual hard part (taking care of special cases). Additionally, imagine this code being scattered away to 100 packages and then some obscure bug surfacing. I suspect that generalizing the specific code might make it harder. For example, the previous md5sum specification is unnecesarily complex in a generic tool; and much easier in the maintainer scripts where each maintainer can choose the best method that works for them Currently, ucf does a lot less than dpkg does. Well, duh. What ucf does, it does much better than dpkg. Why, thank you. But since there are still things that dpkg handles quite well while ucf basically says well, code it yourself, ucf does not provider conffile like handling as it is advertising in its package description. Matter of opinion. ucf's man page says: preserve user changes in configuration files. ucf is a prompting tool -- and is designed to handle user interaction, and copy files in place if the user says so. That's all it does. ucf. Actually, the challenge is there _BECAUSE_ ucf was not designed to address this issue (which it actually should) and its maintainer considers this missing feature a feature. Why should ucf provide a means for removing old configuration files as well? It is not code that is in common with the current functionality. Hell, you don't even need ucf. You look to see if the current files md5sum matches any known md5sums, and you knwo if it is an unmodified file. I still feel that the right place to do this is the tool that claims to be able to replace dpkg conffile (sic!) handling, ucf. Why should ucf be involved at all? This is not what ucf does. manoj -- This is NOT a repeat. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broken packages?
Hi Székelyi, On 1/24/07, Székelyi Szabolcs [EMAIL PROTECTED] wrote: I have a package called morg-mailcommands that depends on Postfix. Trying to install it with aptitude gives (...) You are missing some important pieces of information: 1) How you tried to install the package 2) Where is this package (so we can look at it) Please add that info, so that we can try to help you out. -- Love, Marga
Re: RFS: crotch
On Wed, 24 Jan 2007 16:08:14 +0100 schönfeld / in-medias-res [EMAIL PROTECTED] wrote: - Your package does not include a manpage for a binary. Thats not an 'error', but is highly recommended and the fact that there is none, results in a lintian warning. Ahem, correct. That's for two reasons: firs crotch only understands two arguments, no options in only uses STDIN and STDOUT, therefore I thought I could omit a manpage. Second, I do not know how to write manpages... :o( About writing of man pages. It is easier then writing applications. Just open up an existing manpage in an editor and look at it. On the first sight it might look a little bit obscure, but it isn't. Even I am able to write manpages (but I cannot code much C) There are plenty of tools that help create manpages without having to understand the Groff/troff format. help2man can take your STDOUT usage message and convert that to a usable manpage, doclifter can then take that manpage and create XML that is easier to edit and gives you instructions on how to use xsltproc to turn the XML back into a manpage. dh_make creates an example manpage (groff, xml and sgml formats) which you probably deleted and which you can recreate in any temporary directory. There really is no excuse for not being able to write a manpage. If you can write a ChangeLog entry, you can write a manpage. OK, it may not be the most verbose or comprehensive manpage in Debian but it is a start. Some packages don't need more than a single screen of manpage output - many packages could do with splitting their overly verbose manpages into separate files. Generating a simple manpage is trivial compared to all the other packaging tasks. When generating a manpage, ensure you package the original XML/SGML so that if there are bug reports against your manpage, people can submit patches that you can actually use. Converting a patch for a manpage into a patch for the generating XML is not trivial. You don't have to generate the manpage during the package build process, just update the manpage when the XML/SGML changes. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp4HvJwoUEOM.pgp Description: PGP signature
Re: SVN snapshot versioning
Florent Rougon [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: In other words, use previous-version+svn-stuff if you're packaging that version plus some additional upstream modifications, and use next-version+svn-stuff if you're packaging an alpha or beta arelease ^ I hope you meant '~' here. Yes, sorry. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: ballview : new package version
Dear mentors, I am looking for a sponsor for my package ballview. Package name: ballview Version : 1.2-1 Upstream Author : myself URL : www.ballview.org License : LGPL Section : science It builds these binary packages: ballview - A free molecular modeling and molecular graphics tool The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/ballview - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/ballview/ballview_1.2-1.dsc I have rebuild the package and fixed all lintian errors and warnings. Now I am looking for potential testers and a sponsor. Kind regards Andreas Moll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ballview : new package version
Hi Andreas Thanks a lot for your work. Package name: ballview Version : 1.2-1 Upstream Author : myself URL : www.ballview.org License : LGPL Section : science It builds these binary packages: ballview - A free molecular modeling and molecular graphics tool I had a real short look at your package and gave it a try in my cowbuilder and I got the following output: W: /home/white/.pbuilderrc does not exist dpkg-checkbuilddeps: Unmet build dependencies: sip4 python-sip4-dev libglew-dev W: Unmet build-dependency in source dpkg-buildpackage: source package is ballview dpkg-buildpackage: source version is 1.2-1 dpkg-buildpackage: source changed by Andreas Moll [EMAIL PROTECTED] dpkg-buildpackage: source version without epoch 1.2-1 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. debian/debian-ball-install clean make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 [EMAIL PROTECTED]:~/white/debian/debs/sponsoring/ballview/ballview-1.2$ fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. debian/debian-ball-install clean make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 You are using this particular script, but I guess it might be easier to do the needed stuff directly in the debian/rules file, though I did not investigate it further, this is just what I got right now, I hope it helps you. Cheers Steffen pgpkEcz393Lof.pgp Description: PGP signature
RFS: libsbc
Dear mentors, I am looking for a sponsor for my package libsbc. * Package name : libsbc Version : 0.0cvs20060124-1 Upstream Authors : Marcel Holtmann [EMAIL PROTECTED] Henryk Ploetz [EMAIL PROTECTED] Brad Midgley [EMAIL PROTECTED] * URL : http://sbc.sourceforge.net/ * License : LGPL Section : libs It builds these binary packages: libsbc-dev - Development files for subband codec (SBC) library libsbc0- Subband codec (SBC) library sbcinfo- Subband codec (SBC) analyzer The package is lintian clean. The upload would fix these bugs: 406406 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libsbc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libsbc/libsbc_0.0cvs20060124-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broken packages?
On Wed January 24 2007 09:18, Székelyi Szabolcs wrote: ... Removing all exim4 packages fixes the problem, however I would like to ask: * aptitudes says I have held broken packages. `dpkg --get-selections` says I have no held packages at all. Is this a (small) bug in aptitude? * Why is my package considered broken? All dependencies are correct. Should it explicitly conflict with exim4? (I think this is pointless since postfix already does.) Try dselect, it gives you a more detailed view of conflicts and the packages around them. - Bruce
Re: RFS: ballview : new package version
Steffen Joeris schrieb: Hi Andreas Thanks a lot for your work. Package name: ballview Version : 1.2-1 Upstream Author : myself URL : www.ballview.org License : LGPL Section : science It builds these binary packages: ballview - A free molecular modeling and molecular graphics tool I had a real short look at your package and gave it a try in my cowbuilder and I got the following output: W: /home/white/.pbuilderrc does not exist dpkg-checkbuilddeps: Unmet build dependencies: sip4 python-sip4-dev libglew-dev W: Unmet build-dependency in source dpkg-buildpackage: source package is ballview dpkg-buildpackage: source version is 1.2-1 dpkg-buildpackage: source changed by Andreas Moll [EMAIL PROTECTED] dpkg-buildpackage: source version without epoch 1.2-1 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. debian/debian-ball-install clean make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 Hi, I dont have any clue what went wrong with the permissions of this file since I have tested the package multiple times on several computers by calling dpkg-buildpackage -rfakeroot It never showed me an error like this before. Could you perhaps try to build the package with the line above? I am wondering if this would solve this issue. Maybe there is a problem with the cowbuilder? I dont want to do all the staff in the rules file, since I plan to reuse the debian-ball-install file for packaging on other platforms. Yours sincerely Andreas Moll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ballview : new package version
On Thu, Jan 25, 2007 at 12:37:24AM +0100, Andreas Moll wrote: make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 Hi, I dont have any clue what went wrong with the permissions of this file since I have tested the package multiple times on several computers by calling dpkg-buildpackage -rfakeroot It never showed me an error like this before. I'd guess it's because the debian .diff does not preserve execute permissions in files. Maybe, if you want to keep using that file, you could chmod it in debian/rules *before* calling it. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: ballview : new package version
Le Thu, Jan 25, 2007 at 12:37:24AM +0100, Andreas Moll a écrit : debian/debian-ball-install clean make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 Hi, I dont have any clue what went wrong with the permissions of this file since I have tested the package multiple times on several computers by calling dpkg-buildpackage -rfakeroot It never showed me an error like this before. Could you perhaps try to build the package with the line above? I am wondering if this would solve this issue. Maybe there is a problem with the cowbuilder? Hi Andreas, When I ran dpkg-buildpackage in your sources, it warned that the debian diff would not keep the executable permissions. This problem was not present before because you built a native package, in which everything was in the tar.gz. If the scripts are intended to be used on other platforms, how about moving them out of the debian directory, in the upstream sources? By the way, I built a previous version of your package on a intel PC, and the following problems remain : - Some files have executable permissions while not necessary (such as pictures) - There is no manpage for BALLview. Please run a lintian test on your .deb and .dsc files before asking for sponsorship. Sponsors will anyway do this test and ask you to fix the problems, so there is no need to wait for them to do it :) But more importantly, it seems that your latest version does not fix the problem of building on all debian arches. I doubt somebody will sponsor your package until this is fixed. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sshproxy
OoO En ce début d'après-midi nuageux du samedi 20 janvier 2007, vers 14:38, je disais: Dear mentors, I am looking for a sponsor for my package sshproxy. Anyone interested in sponsoring it ? -- BOFH excuse #447: According to Microsoft, it's by design -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
