RFS: windowlab -- Small and simple Amiga-like window manager
Package: windowlab Short Description: Small and simple Amiga-like window manager Version Packaged: 1.33-2 Version in Debian: 1.33-1 WindowLab is a Window Manager for the X Window System. Features include click-to-focus, a simple menu/taskbar combination and integration with Debian menu system. WindowLab is incredibly fast and small. This release introduces preliminary support for the Debian menu system. More Debian-integration features are coming soon. The package was given an overhaul with CDBS and a simple patch system. Debian Sources: http://mentors.debian.net/debian/pool/main/w/windowlab/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
On Thu, 26 Jan 2006 14:11:27 +0100, Daniel Knabl [EMAIL PROTECTED] wrote: Einst schrieb Marc 'HE' Brockschmidt [EMAIL PROTECTED]: * postinst is sometimes called with other values (*not* only configure). Though these are perfectly OK, your postinst script will fail. Could you describe what you exactly think about? (so that I can imagine what would happen ... and learn from this) How many times have you been pointed to Debian policy? And you are still asking questions that neatly show that you didn't read it? And that also neatly show that you have never looked at other packages? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: ITP vexim
Am Fri, 27 Jan 2006 10:44:47 +0100 schrieb Marc Haber [EMAIL PROTECTED]: How many times have you been pointed to Debian policy? Do you mean after I already read it? Then the answer is too many times... And you are still asking questions that neatly show that you didn't read it? And that also neatly show that you have never looked at other packages? Maybe my question was confusing, that's possible. As I understand the policy, in details the chapters 6.6, 6.6 and 6.7, there have to be some actions performed on various targets of the files. The main target in postinst, when someone initially installs the software, is configure, and in postrm, when someone purges it, it is purge. For these two targets I found examples by looking at some other packages (phpmyadmin, album, ...) that do very similar things. And I implemented those actions to be performed also in my scripts. Now it seems, that I should also perform actions on some targets that do not get used in real installation process: who should upgrade the package, when there has never been a version of it before? Who should downgrade the package (to a non-existent version before)? I did some tests (installing, removing,purging ...) and there was no unexpected behavior. So now I don't understand, really NOT understand, what you are complaining about? Is it because I want to release a piece of software that you don't like? Is it because of me as person? If there's any other place where I could ask, not just if there has something to be done, but what in special case has to be done, then please pint me over there. No problem for me to getting told that this is the wrong list too, but anyone should even tell me then ... I followed your suggestions not to ask on debian-devel, and i have read the policy more often now, especially the chapters 6.5 to 6.7 about control files and their behavior, but there are still questions that affect the actual state of the package. Greetings Marc Peace Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B signature.asc Description: PGP signature
Re: [Update] Re: What to do if the upstream keeps debian directory in original tarball?
On Thu, Jan 26, 2006 at 07:30:22PM -0800, Stan Vasilyev wrote: From the last e-mail I got from Thierry it looks like he wants to make a compromise. Since I annoyed him so much with my e-mails, he proposed to start releasing Xdialog in two versions: Xdialog-version.tar.bz2 file with debian directory and Xdialog-version.orig.tar.gz without the debian directory. Is that such a good idea? I don't see a reason to have a version with a debian directory, but if he insists on having that, this sounds like a good compromise. At this point he thinks that Debian developers are a bunch of political fanatics who only care about the holy Debian Policy Manual and don't care about other distros. Oh, misunderstandings... Well, some of us[1] are. ;-) Anyway, personally I think that Debian users benefit a lot from the policy, because they know what to expect from packages. I really don't see why the (unwritten) policy of don't bother others with your distribution-specific stuff is offensive for those others.[2] Well, it would be nice if you could make him think less negative about us. :-) You seem to be doing a good job at least in getting results. Keep it up! Thanks, Bas [1] I'm not an official Debian Developer, but I do consider myself a Debian developer (mind the lowercase 'd'). [2] Note that I do think having a debian directory in cvs (or svn, or whatever they use) is useful, if it is maintained. It just shouldn't be in the release tarball. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: ITP vexim
This one time, at band camp, Daniel Knabl said: Am Fri, 27 Jan 2006 10:44:47 +0100 schrieb Marc Haber [EMAIL PROTECTED]: How many times have you been pointed to Debian policy? Do you mean after I already read it? Then the answer is too many times... And you are still asking questions that neatly show that you didn't read it? And that also neatly show that you have never looked at other packages? Maybe my question was confusing, that's possible. As I understand the policy, in details the chapters 6.6, 6.6 and 6.7, there have to be some actions performed on various targets of the files. The main target in postinst, when someone initially installs the software, is configure, and in postrm, when someone purges it, it is purge. For these two targets I found examples by looking at some other packages (phpmyadmin, album, ...) that do very similar things. And I implemented those actions to be performed also in my scripts. Now it seems, that I should also perform actions on some targets that do not get used in real installation process: who should upgrade the package, when there has never been a version of it before? Who should downgrade the package (to a non-existent version before)? I did some tests (installing, removing,purging ...) and there was no unexpected behavior. Disclaimer: I have not looked at your packaging. The standard way to do this sort of thing is look through the reference for all the arguments your script can be called with, and handle them. so something like: case $1 in configure) do_something ;; targets|you|could|be|called|with) ;; *) echo Unknown arg $1 2 exit 1 ;; esac What it seems like you are missing is that Debian does not work in isolation. Other distributions like Knoppix and Ubuntu and many others reuse the work of Debian developers, and making your maintainer scripts as robust as possible will help them as well as you. At the moment, there are no Debian packaged versions of vexim, so why have an upgrade target, right? Well, presumably you will add a new version at some point, and then you'll have to handle the upgrade and downgrade targets. Knoppix may in the meantime have added a new version before you get to it, and forgot to check the maintainer scripts you wrote - bang, all the upgrades on Knoppix fail. Since it's not that hard to follow the recommendations of policy, and to future proof your work, why not just do it? I agree, Marc is being a little combative (I assume you've struck a nerve with him), but it does sound from the outside like you've still some way to go on this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: dsbltesters
отправлено в группы и по почте Christoph Haas wrote: - Please close the WNPP bug 273204 which you opened yourself one and a half year ago. Ok, i'll close it. I assumed though that ITP should be closed after that the package was become ready and was appeared in the pool. I'm i wrong? Please use the debian/changelog to close it. http://www.de.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-upload-bugfix Yes, that's better. - The copyright file should contain the years of copyright. Ok, i'll fix that. BTW i see many copyright files in Debian packages whitout (c)year lines. Is it actually a violation? http://groups.google.de/group/linux.debian.announce.devel/browse_frm/thread/ee00935883c7bec2/5326ec35388edb3c IMHO, the Debian Policy really should be more exacting. - There has been long time no change. Did you contact the upstream to make sure the software is still maintained? This piece of software is developed and distributed by dsbl.org project which acts as great free network service. I have no doubt, the software is pretty _useful_ as one of methods to open proxy/relay reliable testing and it's included in FreeBSD ports collection. Should i care if it wasn't updated for 2 years? The main concern is that security bugs may come up. And in that case the upstream should jump in quickly and help to fix it. If the upstream software became unmaintained then the situation may lead to the removal of the package. It's okay if the last update is a year ago. I just wanted to make sure you talked to the upstream at least once. Waiting for the answer. - The package is not lintian clean. Three issues there. Do you mean issues above or something other? I saw only one: $ lintian dsbltesters_0.9.5-1.dsc W: dsbltesters source: out-of-date-standards-version 3.6.1 I got these messages: W: dsbltesters source: out-of-date-standards-version 3.6.1 E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file Could you be so kind to check dsbltesters_0.9.5-2? Just did. Still not lintian clean. Did you use a current Sid (unstable) installation to build the package? These are the remaning messages: E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file Please make sure your package are lintian-clean. Hmm... The history follows. I made built package checks under my usual system (testing), and now i see that it should be produced in pbuilder environment. I just added linda- and lintian-hooks to pbuilder (DISTRIBUTION=testing). They reports: Setting up linda (0.3.17) ... Linda: Running as root, dropping to nobody. E: dsbltesters; dsbl.conf is in /etc, but not marked as a conffile. Setting up lintian (1.23.14) ... E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf W: dsbltesters: old-fsf-address-in-copyright-file To me, it's a kind of magic, because i use up-to-date etch system and certanly same linda/lintian versions as for pbuilder environment. How come the difference? Anyway, now, pbuilder environment was upgraded for sid and next release should be lintian-clean. Be so nice, look at dsbl-testers_0.9.5-3... -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Update] Re: What to do if the upstream keeps debian directory in original tarball?
Am Donnerstag, den 26.01.2006, 19:30 -0800 schrieb Stan Vasilyev: On Tuesday 24 January 2006 13:14, Stan Vasilyev wrote: I have a situation with a Debian package xdialog: http://packages.qa.debian.org/x/xdialog.html The upstream author, Thierry Godefroy [EMAIL PROTECTED], insists on keeping the debian changes inside the upstream tarball, orig.tar.gz. This complicates the development process. First of all, when he makes a new version of xdialog, he sends it to the Debian maintainer (me). I then have to make changes to the debian directory and send him the changes. Finally, he releases the new upstream with Debian changes already included. From the last e-mail I got from Thierry it looks like he wants to make a compromise. Since I annoyed him so much with my e-mails, he proposed to start releasing Xdialog in two versions: Xdialog-version.tar.bz2 file with debian directory and Xdialog-version.orig.tar.gz without the debian directory. Is that such a good idea? It's a compromise with more work for him. At this point he thinks that Debian developers are a bunch of political fanatics who only care about the holy Debian Policy Manual and don't care about other distros. Why we don't care about other distros? The Debian packaging files you wrote are based on your decisions for Debian _only_, not for all Debian based distributions. So forcing others to use your packaging files is what I call don't care about other distributions. Or whyy should the source package on RedHat or Mandriva contain the Debian packaging files? They are completely useless there but they increase the archive size. I really don't understand this position. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Daniel Knabl [EMAIL PROTECTED] wrote: The main target in postinst, when someone initially installs the software, is configure, No, not only upon initially installing it. On every upgrade. and in postrm, when someone purges it, it is purge. No, if the package is purged, postrm is called twice, with different arguments. And it's also called when the package is upgraded or removed. Now it seems, that I should also perform actions on some targets that As I understood Marc, you did some actions unconditionally, no matter what the first argument is (that seems to be fixed now), and some in configure unconditionally on the second argument that should not be performed upon upgrade. This you still do. Err, and you keep configuration files in /usr/share. do not get used in real installation process: who should upgrade the package, when there has never been a version of it before? The package could be in state rc. Who should downgrade the package (to a non-existent version before)? I did some tests (installing, removing,purging ...) and there was no unexpected behavior. So now I don't understand, really NOT understand, what you are complaining about? Is it because I want to release a piece of software that you don't like? It's a software whose quality I cannot judge, but the quality of the packaging is not fit for Debian. Is it because of me as person? If there's any other place where I could ask, not just if there has something to be done, but what in special case has to be done, then please pint me over there. No problem for me to getting told that this is the wrong list too, but anyone should even tell me then ... It's the right list for asking questions after you've tried to understand the Debian policy, and consulted the Developer's reference where Policy is unclear to you. But it seems you haven't read the policy, or I followed your suggestions not to ask on debian-devel, and i have read the policy more often now, especially the chapters 6.5 to 6.7 about control files and their behavior, but there are still questions that affect the actual state of the package. you didn't understand it. Sections 6.5 to 6.7 deal with the installation procedure and maintainer scripts. Control files only exist in the source package. And what you wrote above about postinst and postrm can also easily be shown to be false (or at least incomplete) by looking at these sections. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: ITP vexim
Am Fri, 27 Jan 2006 11:37:42 + schrieb Stephen Gran [EMAIL PROTECTED]: Disclaimer: I have not looked at your packaging. The standard way to do this sort of thing is look through the reference for all the arguments your script can be called with, and handle them. so something like: case $1 in configure) do_something ;; targets|you|could|be|called|with) ;; *) echo Unknown arg $1 2 exit 1 ;; esac That's what I actually did. Decide on the target and go on... What it seems like you are missing is that Debian does not work in isolation. Other distributions like Knoppix and Ubuntu and many others reuse the work of Debian developers, and making your maintainer scripts as robust as possible will help them as well as you. At the moment, there are no Debian packaged versions of vexim, so why have an upgrade target, right? So if there is nothing to be done before an upgrade, there has to be no action performed in prerm's target upgrade, is it ok that way? I really would like to get it working. Well, presumably you will add a new version at some point, and then you'll have to handle the upgrade and downgrade targets. Knoppix may in the meantime have added a new version before you get to it, and forgot to check the maintainer scripts you wrote - bang, all the upgrades on Knoppix fail. Would it be a good new version if they did not care about the manitainer scripts? Of course my scripts also need some work, still. But I always thought, that they (knoppix, ubuntu...) took our packages and modified them to fit their needs, not the other way. While I'm in a quite good cooperation with the upstream author, I think that new versions will be released not quite too often, and until something changes in a larger amount, there will just be some enhancements and minor bugfixes. For example in the php-section of the package, but not in the sql layout or the basic behavior (system user, mysql user, ...). Would it be a good idea to outsource the database creation to a script the user has to invoke manually? So maybe the maintainer script could become a little bit smaller, and would not be possible to be overwritten by accident. Since it's not that hard to follow the recommendations of policy, and to future proof your work, why not just do it? I agree, Marc is being a little combative (I assume you've struck a nerve with him), but it does sound from the outside like you've still some way to go on this. I am confident to get this piece of software packaged the right way within some time, maybe within the next month. This will include, maybe completely, redesign of my scripts. And your answer is a kind of medicine for me at this point. Maybe i would have started to think, that it is a personal conflict, or worse, that this software is not welcome in the Debian distribution. If my questions and requests for help are really that much pain for Marc, then I would kindly his pardon. It was NOT my intent to get others doing my work, but sometimes there are so many things at the same time, that cause confusion. In short: If my questions are a pain, and you think still, that I dind't read the domcumentation and policy, then try even not to answer, at least no every time read the policy, why didn't you. And I'll promise not to ask more often than really needed. many thanks Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B signature.asc Description: PGP signature
Custom Debian CD.
I have created my own custom Debian installer CD based on the debian net-inst cd image. I modified the local repository to include some additional packages I would like to have installed by default. I then reburned the iso and installed the system. Everything works perfectly until I try to install sendmail. I get the following error: # apt-get install sendmail Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. 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. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: exim4-base: Depends: exim4-config (= 4.30) but it is not going to be installed or exim4-config-2 E: Broken packages If I change my sources to a full debian repository this works perfectly without any errors. Also if I do a: apt-get remove --purge exim4-base then the apt-get install sendmail command works perfectly well. Did I mess something up in creating the Packages file? Does anybody know what I'm missing? If you need more information just let me know. This problem has me really stumped. -- o)Derek Wueppelmann (o (D .[EMAIL PROTECTED]D). ((` http://monkey.homeip.net/ ( ) ` signature.asc Description: This is a digitally signed message part
Re: [RFS] OptiPNG - advanced PNG (Portable Network Graphics) optimizer
* Nelson A. de Oliveira [EMAIL PROTECTED] [060126 17:16]: I am searching for a sponsor for OptiPNG. Files can be obtained from: http://biolinux.df.ibilce.unesp.br/naoliv/optipng/ and it will close ITP #347993. I won't sponser it myself, as I do not understand cdbs, but some hints: It does not compile with -g and is linked with -s. The later because you miss to give it proper LDFLAGS (i.e. without -s) the first because the Makefile is called with those in the environment CFLAGS=-g -Wall -O2 CXXFLAGS=-g -Wall -O2 make -f scripts/gcc-syslib.mak but it overwrites them with CFLAGS = -O2 -Wall LDFLAGS = -s The easiest way is to simply put them after the call to make. (and place a LDFLAGS= there fixed the other problem, too). that is instead of CFLAGS=bla make do a make CFLAGS=bla LDFLAGS= Things like lintian or linda cannot catch this, as the binaries are stripped by dh_strip so the resulting binaries do not differ, but if anyone has a problem with your program and wants to build and debug it, he first has to patch the Makefile to get the correct flags. For further reference see section 10.1 of the policy. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Daniel Knabl [EMAIL PROTECTED] writes: The main target in postinst, when someone initially installs the software, is configure, and in postrm, when someone purges it, it is purge. For these two targets I found examples by looking at some other packages (phpmyadmin, album, ...) that do very similar things. And I implemented those actions to be performed also in my scripts. Yes. The problem is that the Debian policy specifies other targets in the maintainer script. Normally, most people don't implement them and do a 'abort-upgrade|bla|baz) #do nothing'. You don't do so, your maintainer scripts simply FAIL when they're called with another argument than postinst. That shouldn't happen if the actions did not fail. Marc -- BOFH #171: NOTICE: alloc: /dev/null: filesystem full pgp4qDYdQ6yoe.pgp Description: PGP signature
RFS: pyme
Hello, I need a sponsor for pyme package. My previous sponsor doesn't have the time currently to review the package i have made. * Package name: pyme Version : 0.7.0 Upstream Author : Igor Belyi belyi.users.sourceforge.net * URL : http://sourceforge.net/projects/pyme/ * License : LGPL Description : Python interface to the GPGME GnuPG encryption library Pyme is, for the most part, a direct interface to the C GPGME library. However, it is re-packaged in a more Pythonic way -- object-oriented with classes and modules. Take a look at the classes defined here -- they correspond directly to certain object types in GPGME for C. . Features: * Feature-rich, full implementation of the GPGME library. Supports all GPGME features except interactive editing (coming soon). Callback functions may be written in pure Python. * Ability to sign, encrypt, decrypt, and verify data. * Ability to list keys, export and import keys, and manage the keyring. * Fully object-oriented with convenient classes and modules. I have put the source package here : https://velma.mini-dweeb.org/~arnau/deb/official/ Regards, -- Arnaud Fontaine [EMAIL PROTECTED] - http://www.andesi.org/ | GPG Public Key available on pgp.mit.edu | Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3 pgpSAxcRJelF9.pgp Description: PGP signature
Re: ITP vexim
Am Fri, 27 Jan 2006 17:27:09 +0100 schrieb Marc 'HE' Brockschmidt [EMAIL PROTECTED]: Yes. The problem is that the Debian policy specifies other targets in the maintainer script. Normally, most people don't implement them and do a 'abort-upgrade|bla|baz) #do nothing'. You don't do so, your maintainer scripts simply FAIL when they're called with another argument than postinst. That shouldn't happen if the actions did not fail. Marc I have made the changes according to the policy already. Besides this errors did you find any others? Thanks Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B signature.asc Description: PGP signature
Re: create password in postinst
Hello, You can look at debian/passwd.config in the passwd package for a solution written in perl. Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Could you please build your package as nonnative, and preferrably pristine? Otherwise I don't know where to start looking at your work. nonnative means that an .orig.tar.gz of the expected name exists in the parent directory, and pristine means that the tarball is identical to upstreams (not just the contents). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: proxycheck
Hi, there I'm seekig for new sponsor of existing package. Package: proxycheck Description: checks existence of open proxy License: GPL URL: http://www.corpit.ru/mjt/proxycheck.html Upstream Author: Michael Tokarev proxycheck is a simple tool that will work on a reasonable *nix system and may be used to quickly check whenever a given host or set of hosts has open proxy server running -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: proxycheck -- link
Al Nikolov wrote: Excuse me, forgot link to http://mentors.debian.net/debian/pool/main/p/proxycheck/ -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Am Fri, 27 Jan 2006 13:24:49 -0500 schrieb Justin Pryzby [EMAIL PROTECTED]: Could you please build your package as nonnative, and preferrably pristine? Otherwise I don't know where to start looking at your work. nonnative means that an .orig.tar.gz of the expected name exists in the parent directory, and pristine means that the tarball is identical to upstreams (not just the contents). Sorry, my mistake. I had to remove CVS dirs from the tarball. Now this should be correct. At the moment I'm changing the scripts to use dbconfig-common. It seems to be a very good framework. After all the changes are made, I will rebuild the package with a new version number. If you could have a look at it then, this would be a great help. In short: Do not waste your time right now. Clear skies, Justin Thanks Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B signature.asc Description: PGP signature
Re: ITP vexim
On Fri, Jan 27, 2006 at 10:09:56PM +0100, Daniel Knabl wrote: Am Fri, 27 Jan 2006 13:24:49 -0500 schrieb Justin Pryzby [EMAIL PROTECTED]: Could you please build your package as nonnative, and preferrably pristine? Otherwise I don't know where to start looking at your work. nonnative means that an .orig.tar.gz of the expected name exists in the parent directory, and pristine means that the tarball is identical to upstreams (not just the contents). Sorry, my mistake. I had to remove CVS dirs from the tarball. Now this should be correct. Thats not a sufficient reason to repack the tarball; it is more important that it is pristine (if applicable). Perhaps the clean target can remove them, and then you don't have to look at them nearly as much (instead, the dpkg: foo was removed warnings, though). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
Am Fri, 27 Jan 2006 16:21:47 -0500 schrieb [EMAIL PROTECTED]:
Thats not a sufficient reason to repack the tarball; it is more
important that it is pristine (if applicable). Perhaps the clean
target can remove them, and then you don't have to look at them nearly
as much (instead, the dpkg: foo was removed warnings, though).
Would you suggest to simply do (in the clean target)
find . -depth -name CVS -exec rm -r {} \;
and not to care about the blah was removed messages?
Justin
Thanks
Daniel
--
mfg
Daniel Knabl http://www.tirolinux.net
PGP Fingerprint [EMAIL PROTECTED]
A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B
signature.asc
Description: PGP signature
Re: ITP vexim
Am Fri, 27 Jan 2006 18:08:38 -0500 schrieb [EMAIL PROTECTED]: Nearly all Debian packages should be pristine; if you can do that, you should. If upstream *only* exists in CVS, then you can't really, and you can run that command before creating your orig tarball. If upstream has a real tarball, though, then please use it :) The upstream tarball is beeing built daily from CVS, but always includes CVS dirs. OTOH, lintian will still warn CVS dir in sourceball, so you might not even both running such a command, and minimize your warnings.. Would it then be OK to remove the CVS dirs, or should I just not care about the lintin warnings? I thought, that it would be ok to remove :/ Justin Thanks Daniel -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B signature.asc Description: PGP signature
What should I do about unresponsive maintainer?
Hi, I know it is not question for this group, but maybe I would love to know what will happen to me, if I will behave as a maintainer of wvdial, which let bug# 316575 without response for 210 days :-). Thanks a lot for the answer, Matej -- Matej Cepl, http://www.ceplovi.cz/matej/blog/ GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC My life has been full of terrible misfortunes most of which never happened. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should I do about unresponsive maintainer?
On Fri, Jan 27, 2006 at 10:18:42PM -0500, Matej Cepl wrote: Hi, I know it is not question for this group, but maybe I would love to know what will happen to me, if I will behave as a maintainer of wvdial, which let bug# 316575 without response for 210 days :-). This is the realm of the QA group, which deals with MIA maintainers, package removals, and orphaned packages. In the case of a single forgotten bug, it makes sense to just email the maintainer again, unless you specifically check that they appear to be inactive, by checking other bugs on their packages, recent uploads, NMUs, etc. A helpful resource is: http://haydn.debian.org/~thuriaux-guest/qa/mia.html (a 2.3 MB html, be forewarned). In this case, the maintainer seems active (Last upload: 2006-01-22), although I'm a bit surprised by rutebook 2002-06-20. I'll also note than it is essentially always useful to post a patch to the bug report :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should I do about unresponsive maintainer?
Matej Cepl wrote: I know it is not question for this group, but maybe I would love to know what will happen to me, if I will behave as a maintainer of wvdial, which let bug# 316575 without response for 210 days :-). You could send a (friendly) reminder and inquiry to the bug report ([EMAIL PROTECTED]). Sometimes bugs get overlooked. It's important to send such mails via the BTS for better documentation. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
