Does anybody else has problems creating a sid cowbuilder ?
Dear all, Wanting to work on the recent gcc-4.3 header FTBFS bugs, I tried to install a sid cowbuilder in my home directory with the following command: chouca〔~〕$ sudo cowbuilder --create --basepath cowbuilder.sid It ends with the following error message: P: Configuring package gnupg P: Configuring package debian-archive-keyring P: Configuring package apt P: Configuring helper cdebootstrap-helper-apt E: Couldn't install system due to errors! pbuilder: cdebootstrap failed -> Aborting with an error pbuilder create failed Does anybody reproduce the error ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does anybody else has problems creating a sid cowbuilder ?
Le Fri, Dec 21, 2007 at 03:33:33AM -0800, Don Armstrong a écrit : > Try using DEBOOTSTRAP=debootstrap in your .pbuilderrc. [Though it > seems to be a bug in cdebootstrap; probably #448210 or similar.] Le Fri, Dec 21, 2007 at 12:51:31PM +0100, Luca Bruno a écrit : > That is probably bug #448210. Try using plain debootstrap insted of > cdebootstrap. Le Fri, Dec 21, 2007 at 11:55:15AM -0430, Jose Luis Rivas Contreras a écrit : > It's a but in cdebootstrap but the patch had worked for me very well. Thanks everybody for your answers, I used debootstrap instead of cdebootstrap and it worked well. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
MIME support in Debian.
Dear mentors, The Debian mime policy requires packages register through update-mime, which according to its manpage uses /etc/mailcap and /usr/lib/mime/packages. However, I noticed the /usr/share/mime and /usr/share/mime-info directories that also seem to contain relevant informations. Is there a documentation somewhere that explains what is necesary and sufficient to be done so that a Debian package provides MIME support that "just works" ? Basically the goal is that the relevant program will be used by mail readers and web browsers. Also, if there are two such programs installed, is there something that can be done through MIME so that the user has a chance to chose the program ? Or will it be a "last installed is the default" situation, like with the alternative system ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457477: devscripts: [tagpending] Did not tag the bug.
Package: devscripts Version: 2.10.11 Severity: minor Dear tagpending maintainers, I tried to tag a bug with tagpending, but it had no effect. The execution of the program seems to have worked normally: chouca〔trunk〕$ tagpending tagpending info: tagging these bugs pending: 455177 My computer is able to send emails to other computers on different networks. I do not know where the failure happened. Can you indicate me how to make tests to deterimne if the problem is in tagpending or elsewhere ? Have a nice day, -- Charles Plessy -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages devscripts depends on: ii debianutils 2.28.2 Miscellaneous utilities specific t ii dpkg-dev 1.14.7 package building tools for Debian ii libc6 2.7-4 GNU C Library: Shared libraries ii perl 5.8.8-12 Larry Wall's Practical Extraction ii sed 4.1.5-5The GNU sed stream editor Versions of packages devscripts recommends: ii fakeroot 1.8.10 Gives a fake root environment -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
Le Sat, Dec 22, 2007 at 06:52:53PM +0100, Cyril Brulebois a écrit : > > > My computer is able to send emails to other computers on different > > networks. I do not know where the failure happened. Can you indicate > > me how to make tests to deterimne if the problem is in tagpending or > > elsewhere ? > > What about checking your mail logs? Indeed, here is an extract with the unsuccessful tagpending and the successful reportbug. 2007-12-22 18:15:36 1J67wm-0003fx-52 <= [EMAIL PROTECTED] U=charles P=local S=562 [EMAIL PROTECTED] 2007-12-22 18:15:37 1J67wm-0003fx-52 ** [EMAIL PROTECTED] R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<[EMAIL PROTECTED]>: host bugs.debian.org [140.211.166.43]: 550-Verification failed for <[EMAIL PROTECTED]>\n550-Unrouteable address\n550 Sender verify failed 2007-12-22 18:15:37 1J67wn-0003g7-LQ <= <> R=1J67wm-0003fx-52 U=Debian-exim P=local S=1583 2007-12-22 18:15:37 1J67wm-0003fx-52 Completed 2007-12-22 18:15:37 1J67wn-0003g7-LQ => charles <[EMAIL PROTECTED]> R=local_user T=maildir_home 2007-12-22 18:15:37 1J67wn-0003g7-LQ Completed 2007-12-22 18:23:43 1J684d-0003o3-Uh <= [EMAIL PROTECTED] U=charles P=local S=2035 [EMAIL PROTECTED] 2007-12-22 18:23:45 1J684d-0003o3-Uh => [EMAIL PROTECTED] R=dnslookup T=remote_smtp H=bugs.debian.org [140.211.166.43] 2007-12-22 18:23:46 1J684d-0003o3-Uh => [EMAIL PROTECTED] R=dnslookup T=remote_smtp H=mail.plessy.org [220.157.247.254] 2007-12-22 18:23:46 1J684d-0003o3-Uh Completed Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
Le Sat, Dec 22, 2007 at 11:01:21PM +0100, Daniel Leidert a écrit : > > Current GNOME and the upcoming KDE 4 both uses the shared-mime-info > database in /usr/share/mime. > > IMHO you should only try to support the mailcap/metamail and the fd.o > shared-mime-info systems. Hi Daniel, many thanks for your answer, I will do what you suggest : mailcap/metamail and fd.o support. If I understood correctly, to do so, I need to: - Have a MimeType entry in the .desktop file. - Have a debian/packagename.mime file in the source package and call dh_installmime. I did not find the way to associate a file suffix to the program. Is MIME the way to go ? The goal would be that mail user agents and webservers would use the right mime type with attached/downloaded files, and that doubleclicking on local files would make them opened by a relevant program. I have another question: can subcategories starting by x- created freely? The program I am working on is Treeview X, a phylogenetic tree viewer that can read Clustal W format. It is text based, so David Paleino, our collaborator from the Debian-Med packaging team, suggested text/clustalw-tree. But maybe I can submit a wishlist bug on chemical-mime-data to have chemical/clustalw-tree from your namespace ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
reopen 457477 severity 457477 wishlist retile 457477 Please support the DEBEMAIL environment variable. thanks Le Sat, Dec 22, 2007 at 10:35:07PM +0100, Julien Cristau a écrit : > On Sun, Dec 23, 2007 at 03:04:44 +0900, Charles Plessy wrote: > > > Indeed, here is an extract with the unsuccessful tagpending and the > > successful reportbug. > > 2007-12-22 18:15:37 1J67wm-0003fx-52 ** [EMAIL PROTECTED] R=dnslookup > > T=remote_smtp: SMTP error from remote mail server after RCPT TO:<[EMAIL > > PROTECTED]>: host bugs.debian.org [140.211.166.43]: 550-Verification failed > > for <[EMAIL PROTECTED]>\n550-Unrouteable address\n550 Sender verify failed > > you need to fix your mail setup, to not send mail from unrouteable > addresses. Thanks Julien for your fast answer. Tools like reportbug work out of the box on my machine; I suppose that it is because they recognise the DEBEMAIL environment variable, in which there is a routable email adress to use. Do you think that tagpending could use it? I could try to write a patch for this, but although I know a little bit of Perl, I do not know what is the level of securisation and input sanitisation that would be expected. But if somebody points me to an example where I could find inspiration, I will give it a try. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
Le Sun, Dec 23, 2007 at 06:27:59PM +0100, gregor herrmann a écrit :
> On Mon, 24 Dec 2007 02:13:48 +0900, Charles Plessy wrote:
>
> > Tools like reportbug work out of the box on my machine; I suppose that
> > it is because they recognise the DEBEMAIL environment variable, in which
> > there is a routable email adress to use. Do you think that tagpending
> > could use it?
>
> It should.
> tagpending just calls "eval bts ${BTS_ARGS}" at the end, and bts
> should honour DEBEMAIL.
Hi,
indeed, using bts directly produces the same problem : the mail is
rejected by the BTS (while test mails are accepted in my work mail box
for instance). The error message is the following:
2007-12-23 21:49:11 1J6Xl0-0006a2-6Z ** [EMAIL PROTECTED]
R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT
TO:<[EMAIL PROTECTED]>: host bugs.debian.org [140.211.166.43]:
550-Verification failed for <[EMAIL PROTECTED]>\n550-Unrouteable
address\n550 Sender verify failed
Also, it is a bit frustrating that unless digging in the logs, it is not
possible to know that the operation failed. If the problem is more the
configuration of the BTS, could at least DEBEMAIL be used to deliver an
error message ?
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
Le Sun, Dec 23, 2007 at 09:10:41PM +, Julien Cristau a écrit : > > > The problem is not bts, or tagpending, or the BTS. The problem is that > your MTA is not configured correctly. With exim, which you appear to be > using, see /etc/email-addresses. Le Sun, Dec 23, 2007 at 10:18:01PM +0100, Mohammed Adnène Trojette a écrit : > > And this causes bugs.debian.org to fail sender verification. > So either use an SMTP with *routeable* address or make your mailname a > routeable address. Well, I do understand that I have a poorly configured mail server on my machine. Indeed it is a laptop, not a mail server. Other sites accept the test mails I send from this laptop, and since I am not a system administrator, I strictly have no clue on what to do to get with `bts' the same level of functionality than with `reportbug', that is: installing it on a machine and using it "out of the box" to communicate with the BTS. Apparently I am wrong that the DEBEMAIL environment variable can contain useful information which would make `bts' able to send mails that would not be rejected by the BTS when using a default Debian instalation. I will not bother you further and stop using tools that I can not master because of my lack of interest and skills in the art of mailserver configuration. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457477: devscripts: [tagpending] Did not tag the bug.
Le Sun, Dec 23, 2007 at 04:57:12PM -0500, Asheesh Laroia a écrit : > > If your ISP has an SMTP server you can use as a relay, which is almost > always the case, configuring your Exim to go through that should be fairly > easy. That should eliminate these purplexing issues (by offloading them > to your ISPs' system administrators, who have alreaddy solved them!). > > I hope this helps - feel free to email me privately to ask for more help. Thanks a lot for the help. The machine I use is a laptop, that goes from network to network. Is there a way to get the right relay automatically selected when I plug the ethernet cable ? Have a nice day. -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
Hi Daniel, To summarise our discussion, I have created the following wiki page: http://wiki.debian.org/MimeTypesSupport = Support of MIME types in Debian packages = == For the command line == MIME support in Debian is formally described in the [http://www.debian.org/doc/packaging-manuals/mime-policy/ MIME sub-policy], which requests that packages use the update-mime command from the mime-support package. This can be done directly, or indirectly through helper programs, in particular dh_installmime from debhelper. The format of the registration file is described in the mailcap(5) manpage, and many examples can be found in /etc/mailcap. == For the desktop == The MIME system has been reused by Desktop managers in order to associate relevant programs to files. Divergent implementations have been used, but this page focuses on the standard from FreeDesktop.org. Association between a file suffix and file type is done through XML files following the Shared MIME-info Database specification. The Debian package shared-mime-info contains the specification and the program update-mime-database that is used to populate the /usr/share/mime with relevant entries, using the XML file as a source. dh_installmime can be used to simplify the work. Programs are indirectly associated to file suffixes through the association with a file type. This is done through their .desktop file, with the MimeType entry. == In summary, if you use debhelper: == * create a file named by the package name plus .mime as a suffix , containing information in the mailcap format. * create a XML file named by the package name plus .sharedmimeinfo as a suffix, containing information about a given file type, and its usual suffix. * create a destkop entry named by the program name plus .desktop as a suffix, and document inside what file types the program can accept. Install it by yourseld in /usr/share/applications, dh_desktop does not do this at the time this memo is written. * call dh_installmime and dh_desktop == Further readings == * The Debian MIME policy: http://www.debian.org/doc/packaging-manuals/mime-policy/ * The manual pages of update-mime, update-mime-database, dh_installmime, dh_desktop and mailcap. * The Shared MIME info specification: http://standards.freedesktop.org/shared-mime-info-spec/latest * The Desktop entry specification: http://standards.freedesktop.org/desktop-entry-spec/latest/ * The RFCs 2045 and 2048 * More information can be found at http://sourceforge.net/docman/?group_id=159685 Informations to write this page were collected in during a discussion on the debian-mentors mailing list : http://lists.debian.org/debian-mentors/2007/12/msg00398.html [EMAIL PROTECTED] There are still two things I am wondering: - Do the packages need to depend on mime-support and shared-mime-info ? - If two programs can open files with a given suffix, they have to ship the same .sharedmimeinfo file. How can we factorize this code ? Merry christmas to you and everybody else ! -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
Hi Daniel, hello Mentors, I have another question: I noticed that in /etc/mailcap programs are called either with their full path or just their name. Is one of the ways preferred? Merry Christmas, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
> > Am Samstag, den 22.12.2007, 23:34 +0900 schrieb Charles Plessy: > > > Also, if there are two such > > > programs installed, is there something that can be done through MIME so > > > that the user has a chance to chose the program ? > Daniel Leidert gmx.net> writes: > > Not directly through MIME (the MIME RFCs just describe the so called > > Internet Content type, e.g. "text/plain" - association with programs is > > AFAIK not part of the MIME standard). This has been described in the > > fd.o standard: > > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Le Thu, Dec 27, 2007 at 09:23:01AM +, Frank Küster a écrit : > Isn't the mailcap.order file (or similar, I'm currently condemned to use a > Windows box) used for that, probably together with update-mime? After inspecting the file and its manpage, my gut feeling is that it is not supposed to be modified by Debian packages. Apparently it serves for system-wide local configuration. However, files in /usr/lib/mime/packages contain a "priority=n" field, that is not documented in mailcap(5). (By the way, isn't the location of the files in /usr/lib against the FHS ?) I have the strange impression that the system is completely Debian-specific, or at least, it was created for Debian. Does anybody know how it works on other distributions ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan Who thinks he stepped into something bigger than expected. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mustang, btk-core
Le Tue, Jan 08, 2008 at 04:00:21PM +0100, Morten Kjeldgaard a écrit : > Dear mentors, > > I am looking for a sponsor for my package "mustang" (ITP Bug #459637) > I am looking for a sponsor for my package "btk-core". Dear Morten, nice work ! Here are a few comments en vrac. If you want to collaboratively maintain the packages within the Debian-Med team, please use the following in your control file: Maintainer: Debian-Med Packaging Team <[EMAIL PROTECTED]> Uploaders: Morten Kjeldgaard <[EMAIL PROTECTED]> Because it seems that you are experienced in packaging, I would suggest you to directly add the following field as well. XS-DM-Upload-Allowed: Yes This would allow you to upload updates without the help of a sponsor once the package is accepted if you apply to become a "Debian Maintainer". In that case I would prefer that the initial sponsoring would be done by a DD from Debian-Med, to make clear that the Debian-Med packaging team welcomes your uploads. To know more about Debian Maintaiers, please read the following : http://wiki.debian.org/Maintainers For the copyright files, you may be interested by the proposed machine-parsable format described in the following link. Although no parser has been written yet, it could be useful to start to use it: http://wiki.debian.org/Proposals/CopyrightFormat About the manpages, many thanks for writing them. Have you considered submitting them upstream ? I have a few comments specific to btk-core: - why providing libbtk-core-dev but not libbtk-core ? - libbtk-core-dev should probably be in the libdevel section. - in your changelog, a colon is missing: (Closes: #459753) - how about packaging the docs as well ? Have a nice day, -- Charles Plessy Debian-Med packaging team Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mustang, btk-core
Le Wed, Jan 09, 2008 at 10:58:09PM +0100, Morten Kjeldgaard a écrit : > > > - libbtk-core-dev should probably be in the libdevel section. > > Yes it could. Upstream defines the intended audience as "Developers, > Science/Research". I assumed the package would appeal more to > scientists than "ordinary" developers, so I chose the "science" > category. I have no strong opinions on the matter, however. I have no strong opinion about this either. But note that the source package can be in section Science and the -dev package in the libdevel section. Also, once born the package will be "debtagged", see http://debtags.alioth.debian.org/todo.html?maint=debian-med-packaging%40lists.alioth.debian.org Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: adun.app (updated package)
Le Sat, Jan 19, 2008 at 05:01:44PM +0200, Yavor Doganov a écrit : > Dear mentors, > > I am looking for a sponsor for the new version 0.8.2-1 > of the package "adun.app" (QA upload). > > It builds these binary packages: > adun.app - Molecular Simulator for GNUstep > > The package appears to be lintian clean (except one informational tag, > which would be better if addressed by the future maintainer). > > The upload would fix these bugs: 416859, 450469, 457723 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/a/adun.app > - Source repository: deb-src http://mentors.debian.net/debian unstable main > - dget > http://mentors.debian.net/debian/pool/main/a/adun.app/adun.app_0.8.2-1.dsc Dear Yavor, For biology-related packages, do not hesitate to CC [EMAIL PROTECTED] PS: maybe we (debia-med) should adopt the package ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS/RFC: bibutils; convert bibliographic data between formats
Le Sun, Jan 27, 2008 at 04:42:39AM +0100, David Bremner a écrit : > > Dear mentors, > > I am looking for a sponsor for my package "bibutils". > > * Package name: bibutils > Version : 3.39-1 > Upstream Author : Chris Putnam <[EMAIL PROTECTED]> > URL : > http://www.scripps.edu/~cdputnam/software/bibutils/bibutils.html > Programming Lang: C > License : GPL2 > Description : interconvert various bibliographic data formats > Section : text > > Bibutils is a set of command-line filters that convert between the following > bibliographic data formats: BibTeX, COPAC, EndNote refer, EndNote XML, > Pubmed XML, ISI web of science, US Library of Congress MODS, RIS, and > Word 2007 bibliography. Dear David, this package would be very useful to scientists, so I am sure that you can find long-term support on the [EMAIL PROTECTED] mailing list. I have added your package on the following wiki page: http://wiki.debian.org/DebianScienceBibliography If you want, can you update it when bibutils gets accepted in Debian? Although I am not a DD, I have a few comments on your package: * debian/copyright: bibutils is released under the GPLv2 or any later version. Also, you have to include the thee paragraphs from the "How to Apply These Terms to Your New Programs" section of the GPL to the copyright file. Lastly, the copyright of C. Putnam starts from 1995. * debian/docs: has a duplicated line. * debian/bibutils.dbk: you used a template that is not the latest (see /usr/share/doc/docbook-xsl/examples/foo.1.example_manpage.xml.gz ) You do not need to update it, but for instance, the latest has a link to its stylesheed in the header, so that `xsltproc debian/bibutils.dbk' would be enough to make the manpate. Personnaly, I do not build the manpages at buildd time anymore, I just regenerate them only if they really changed, and include the .1 files in the source package. Lastly, Policy 12.1 recommends to use symlinks instead of the .so system. * debian/control: are you sure you need the autotools.dev package? Will the config.(sub|guess) files be used by the configure script? * debian/rules: are you sure that you need to run the configure script? If not, you can drop the build-dependancy on csh. * xml2word has the potential to generate namespace clashes in the future. Maybe you can ask upstream if he would like to consider renaming it. * Bibutils provide a small test suite. Maybe you can build it and run it in during the package building. PS: actually, debhelper is very smart and replaces the .so manpages by symlinks ! Have a nice day, and many thanks for packaging bibutils! -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
handling nostrip and noopt with CDBS.
Dear all, I got very interested in CDBS, thinking that it would save me a lot of time if for instance 'nocheck' will be implemented in the Policy some day. I thought that it was handling nostrip and noopt automagically but apparently it is not the case for most of the classes. Does anybody know a way to factorise the code to handle these options ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS/RFC: bibutils; convert bibliographic data between formats
Le Sun, Jan 27, 2008 at 12:29:38PM +0100, David Bremner a écrit : > > Charles> * debian/rules: are you sure that you need to run the > Charles> configure script? If not, you can drop the > Charles> build-dependancy on csh. > > Hmm. The script is simple, and I could write a replacement, but > something has to generate a Makefile. The script could be replaced > with a few sed invocations. This makes the package slightly more > fragile with respect to upgrades; do you think this is worth it to > drop the dependency? I ran it on powerpc, diffed the new and old makefiles, and came to the conclusion that running it did not have any significant changes: only one variable was changed, containing the name of the build architecture, but it is not used in the rules called by debian/rules. I think that you can stop calling this script and therefore remove the build-dependancy on csh. > Charles> PS: actually, debhelper is very smart and replaces the > Charles> .so manpages by symlinks ! > > Right, so do you think there is any reason not to rely on this? It contradicts the principle of least surprise, so how about using dh_link instead ? it is quite trivial. On the other hand, if you want to submit your manpages for upstream inclusion, I do not know which solution is most portable. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: handling nostrip and noopt with CDBS.
Le Sun, Jan 27, 2008 at 11:56:21AM +0100, Cyril Brulebois a écrit : > On 27/01/2008, Charles Plessy wrote: > > I got very interested in CDBS, thinking that it would save me a lot of > > time if for instance 'nocheck' will be implemented in the Policy some > > day. I thought that it was handling nostrip and noopt automagically > > but apparently it is not the case for most of the classes. > > I suggest you open a wishlist bug so that the author(s) consider adding > these everywhere it is needed, possibly with examples of yours where > cdbs currently fails at doing the Right Thing©®™. Hi Cyril, actually I was wrong and nostrip and noopt are handled by many classes, as they converge to /usr/share/cdbs/1/class/langcore.mk, that does the job. (At the beginning I thought that it was independant from /usr/share/cdbs/1/class/buildcore.mk, but although it seems, in fact anyghing that calls one also calls the other). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
List of out-of-date packages on a given architecture.
Dear Mentors, I was just wondering if there was a tool accsssible to non-DDs, that would allow to get the list of packages that have been uploaded more than 10 days ago, but never built on a given architecture. I am about to write an email to the buildd admin of mips and mipsel to ask for my packages to be built but before I would like to see if I am just unlucky, or if this is a more general dysfunctioning. Have a nice day, -- Charles Plessy Debian-Med packaging team Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of out-of-date packages on a given architecture.
[CC: [EMAIL PROTECTED], because the problem has not been raised there yet.] > Charles Plessy wrote: > > > > I was just wondering if there was a tool accsssible to non-DDs, that > > would allow to get the list of packages that have been uploaded more > > than 10 days ago, but never built on a given architecture. I am about to > > write an email to the buildd admin of mips and mipsel to ask for my > > packages to be built but before I would like to see if I am just > > unlucky, or if this is a more general dysfunctioning. Le Mon, Feb 04, 2008 at 08:46:20PM -0600, Raphael Geissert a écrit : > > What about checking on > http://people.debian.org/~igloo/status.php?packages=PACKAGE ? Le Tue, Feb 05, 2008 at 03:46:43AM +0100, Cyril Brulebois a écrit : > > mipsel has a huge backlog, and ISTR that mips too. Nothing related to > your particular packages, I'd say. Remarks based on some packages of > mine, and of some packages I've been more or less tracking during the > last weeks. Le Tue, Feb 05, 2008 at 11:49:09AM +0900, Michal Čihař a écrit : > > You mean something like these: > > http://buildd.debian.org/stats/?arch=mipsel&state=Needs-Build > http://buildd.debian.org/stats/?arch=mips&state=Needs-Build > > So you can see you are not alone :-). Hi all, thanks for all your ansers. At the beginning I thought that the problem was that the buildds were ignoring some packages, but finally it is "only" seems that they are not keeping up. So in conclusion, we have nothing else to do than hoping that the buildds will restart keeping up some day, or is it time to ask on debian-release that packages not up to date on these arches are allowed to migrate in testing anyway ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon a écrit : > > 3. All advertising materials mentioning features or use of this > software must display the following acknowledgement: > This product includes software developed at the University of > Tennessee, Knoxville, Innovative Computing Laboratories. Bonjour Jean, This is the "advertisement clause" of the original BSD licence. Some works in main are or were distributed under this clause, so it is considered DFSG-Free. However, distributors of Debian can easily infringe this clause: for instance, if an hypothetical magazine, "Clusterised Linux" would sell an issue with a DVD of Debian Lenny and advertise it with a slogan such as "Debian Lenny: faster with upgraded kernel and HPL memory distribution", the university of Tenessee could obviously claim that the licence has not been respected because their name has not been cited. This example is maybe a bit artificial, but the point is that with such licences in main, redistributors who use advertisement should in theory read all the copyright files to check who to acknowledge. For this reason, I wouldn't recommend to include this program in main. But there is a much better solution. The problem has been well explained on FSF's website: http://www.gnu.org//philosophy/bsd.html and importantly, the university of Berkeley from which this licence originates has now abandonned the advertisement clause. This is a strong argument, and with it I was able to obtain the relicencing of a 4-clause-BSD-licenced program by the Whitehead Institute. I think that you have your chances with the university of Tenessee. Have a nice day, -- Charles Plessy Debian-Med packaging team. Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 06:44:38PM -0800, Russ Allbery a écrit : > Charles Plessy <[EMAIL PROTECTED]> writes: > > > This example is maybe a bit artificial, but the point is that with such > > licences in main, redistributors who use advertisement should in theory > > read all the copyright files to check who to acknowledge. For this > > reason, I wouldn't recommend to include this program in main. > > There is already much software in Debian main with this license and other > Debian Developers who do not agree with this and who will continue to > include such software in Debian main. (It is, after all specifically > called out as a free license in the Debian Free Software Guidelines.) So > the practical impact for a Debian derivative of including or not including > one more package with the four-clause BSD license is minimal. Hi Russ, I think that it is a bit frivolous to distribute software with advertisment clause in main and not properly warning the redistributors, who are the most likely persons to infringe the clause. We should remeber that for other aspects of licencing and intellectual property management, Debian is much more rigorous, so the presence of 4-clauses BSD licences is contradicting the principle of least surprise, that is usually a good guidance. Importantly, the copyright holders of such programs are often not the programmers themselves, but the universities, who nowardays face very strong financial pressures and delegate more and more the management of the intellecutal property to specialised services, who can be ran by people who know nothing about the spirit of free software that blessed the researchers when they wrote their programs. This is why, as a personnal choice, I do not take the responsability of introducing new packages with the BSD advertisement clause in Debian, and I suggest others to refrain as well. Anyway, I really think that there are good chances to obtain a relicencing, that is by far the best way to find a solution that pleases everybody. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 10:27:55PM -0800, Russ Allbery a écrit : > > Am I missing something? This ? http://web.archive.org/web/19990210065944/http://www.debian.org/misc/bsd.license http://web.archive.org/web/20001205083200/http://www.debian.org/misc/bsd.license -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Sat, Feb 09, 2008 at 01:26:55PM -0500, Joey Hess a écrit : > Riku Voipio wrote: > > I think the short term solution to this dilemma is to compile a list > > of attributions needed to be included in advertizment material. > > Also a list should be compiled attributions needed n documentation > > (such as libjpeg's). Obviously most distributors/boob writers will > > not notice such lists, but that's a different problem... > > Most writers don't have to worry about it, it's not as if we advertise > Debian as "Debian.. now with Thomas G. Lane's JPEG support and OpenSSL". > The advertisement clause tries to not allow those specific attributions > to be used in advertisements; it does NOT require that advertisements > contain any specific list of citations. Actually, this is true for libjpeg and false for openssl and other programs using similar BSD-related clauses. libjpeg: Permission is NOT granted for the use of any IJG author's name or company name in advertising or publicity relating to this software or products derived from it. This software may be referred to only as "the Independent JPEG Group's software". openssl: All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [CDBS] adding commands to the checking target.
Le Tue, Feb 12, 2008 at 03:11:05PM +, Neil Williams a écrit : > > If the tests are disabled, you won't know if some tests fail on > different architectures. The whole point of make check if ensuring that > the build works in environments other than the build machine. > > What about simply limiting the scale of the tests - e.g. if the upstream > code uses a randomized input in a loop, maybe upstream could be patched > to support a configurable number of cycles in each test routine. > if ... > DEB_MAKE_CHECK_TARGET = check > else > DEB_MAKE_CHECK_TARGET = > endif Hi Neil, Thanks a lot for the help. I have disabled the tests on arm m68k s390 because they are not so fast, and on mips mipsel hppa because the buildds for these arches are not keeping up. Anyway, I do not expect any user on these architectures. I am all open to enable the tests if one can prove me wrong with a message from a real user (the package name is primer3). Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Skipping tests on some arches.
Le Wed, Feb 13, 2008 at 02:40:02AM +0100, Cyril Brulebois a écrit : > > I'd rather enable the tests on all architectures Well, no problem for me. One of the reasons why I disabled the tests in the past was that I asked the question and I was advised to do so. Last time, the tests have taken: 1h05 on sparc, 37 min on mipsel, 39 min on mips, 37 min on powerpc, 19 min on hppa, 6 min on amd64… Not a big deal, except of course if everybody makes test like this. In popcon, there are 26 mips users, and primer3 is used by 0.1 % of the Debian users. I still think that it is useless to wait for mips users to have primer3 build before letting bug fixes to primer3 migrate to testing, but as you noted, that it is a different story. If the persons who care about the Debian ports do not mind my package eating their CPUs, I'll happily re-enable the tests everywhere. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tests that take more than ten times build time.
Re-salut Cyril, Le Wed, Feb 13, 2008 at 03:30:24AM +0100, Cyril Brulebois a écrit : > What about *relative* numbers, e.g. what % of the time is spent in the > build itself (gcc and friends), and what % of the time is spent in the > testsuite? Anyway, (almost) less than 1 hour everywhere isn't what I > call time-consuming from a buildd point of view. Test time on arch (build time) 1h05 on sparc (3 min), 37 min on mipsel (2 min), 39 min on mips (3 min), 37 min on powerpc (2 min), 19 min on hppa (2 min), 6 min on amd64 (1 min)… Of course, if this is an exception, there is no need to argue. But in the Debian-Med packaging team, we have a few package whose tests are not yet enabled (bioperl, emboss,...); I do not know if it would be wise to do so systematically if they have a similar pattern of CPU usage... Or maybe in the end it would be the role of the port responsibles to micromanage this? > Popcon is no absolute knowledge. Anyway, 25+ users is far from > negligible AFAICT. Sure, but we are talking og 0.1 % of 25+ users. So if for one popcon report there are 10 instalations, it still makes only 0.25 user. And this includes the persons who downoladed the package but are not using it. Bonne journée, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[CDBS] adding commands to the checking target.
Dear mentors, I am using CDBS for a package, in particular because it gives the support of the "nocheck" option for free, but in addition I want to disable by default the checks for some arches, because they take 20 min on an iMac G5… To add things to the clean rule, one would have to write something like this: clean:: instruction to be added. However, I have not found anything for the checks. Does anybody know? The code I would like to add is: ifeq (,$(filter $(DEB_HOST_ARCH_CPU),$(SKIP_TEST_CPUS))) @echo "Fast-cpu arch detected, performing checks." else @echo "Slow-cpu arch detected, skipping checks.t" DEB_BUILD_OPTIONS += nocheck endif (at this point, it may be obvious to some of you that I am not comfortable with the syntax of variable comparisons in makefiles, because it would of course be better to have a simple "if slow arch, then nocheck") Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tests that take more than ten times build time.
Hi Thijis, Le Wed, Feb 13, 2008 at 11:11:41AM +0100, Thijs Kinkhorst a écrit : > > we have enough build time available Well, the following package of mine are waiting for the mips buildds for testing transition (position in the queue in parenthesis): treeviewx (165) njplot (156) emboss (152) And another one, who was never built in mips, is number 509 in the queue (glam2). For njplot, the waiting time is already 29 days. Therefore, I am a bit doubtful that we have enough build power. Would we have, my original question would of course be pointless. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tests that take more than ten times build time.
Le Wed, Feb 13, 2008 at 11:58:14AM +0100, Thibaut Paumard a écrit : > > how can you find out the position in the queue? In one of the non-official buildd pages: http://people.debian.org/~igloo/status.php?packages=yorick This page is linked from the PTS: http://packages.qa.debian.org/y/yorick.html (other links / buildd / more ) Your number 148! I am jealous ;) > If I understand the information in > http://www.debian.org/devel/buildd/wanna-build-states.html Interesting... I propose to remme the "science" section "ciense" ;) Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Anonymous delayed queue?
Dear mentors, There is a minor new upstream release for a package I maintain, but on the other hand the current build will enter testing tomorrow. I therefore tried a delayed upload, but as I am a DM, I have no access to gluck. Is there a possibility to make delayed uploads as a DM ? (Of course, it is not a big deal, but it helps to make the TODO list shorter). Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anonymous delayed queue?
Le Thu, Feb 14, 2008 at 01:32:28PM +0900, Paul Wise a écrit : > > $ at tomorrow > at> dupload /home/foo/*.changes Smart :) If you or somebody else agree that it is of general interest (in private if you want to limit the traffic on this list), I can propose an update for the Developpers Reference. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468760: RFP: libace-perl -- interface for the ACEDB database
Package: wnpp Severity: wishlist Dear all, Recent versions of Bioperl, a suite of perl modules for bioinformatics, depend on the modules provided by AcePerl. The Debian-Med packaging team would be very happy to find a volunteer to prepare a Debian package for it. We can provide support and sponsorship (but please check first with the pkg-perl team if they would be interested to host the package as well). There might be copyright issues depending on the level of pickyness: files under acelib/ have no clear copyright statement, but have been released under GPL and LGPL in the ACEDB packages distributed by the Sanger Center (see below). I do not know if these files are essential. Package name: libace-perl Version : 1.91 Upstream Author : Lincoln Stein [EMAIL PROTECTED] URL : http://stein.cshl.org/AcePerl/ License : Same as Perl., and GPL/LGPL mix. Programming Lang: Perl, C Description : interface for the AceDB database Here are stubs for the control and copyright files: Priority: optional Section: science Homepage: interface for the AceDB database Enhances: bioperl Description: interface for the AceDB database AcePerl is an object-oriented Perl interface for the AceDB database. It provides functionality for connecting to remote AceDB databases, performing queries, fetching ACE objects, and updating databases. The programmer's API is compatible with the JADE Java API, and interoperable with the API used by BoulderIO. . AceDB is a genome database system developed since 1989 primarily by Jean Thierry-Mieg (CNRS, Montpellier) and Richard Durbin (Sanger Institute). It was originally developed for the C.elegans genome project , from which its name was derived (A C. elegans DataBase). X-Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat X-Upstream-Author: Lincoln Stein <[EMAIL PROTECTED]> X-Source-Downloaded-From: http://stein.cshl.org/AcePerl/AcePerl.tar.gz Files: acelib/* Copyright: © 1991-1998 J Thierry-Mieg and R Durbin License: Probably a mixture of GPL-2+ and LGPL-2+ This file is part of the ACEDB genome database package, written by Richard Durbin (Sanger Centre, UK) [EMAIL PROTECTED], and Jean Thierry-Mieg (CRBM du CNRS, France) [EMAIL PROTECTED] X-Comment: These files can be found licenced either as GPL-2+ or LGPL-2+ in ftp://ftp.sanger.ac.uk/pub/acedb/SUPPORTED/ACEDB-source.4.9.39.tar.gz Files: Ace/Model.pm, Ace/Object.pm, Ace/Local.pm, Ace/Sequence/Multi.pm, Ace/Sequence/Homol.pm, Ace/Sequence/GappedAlignment.pm, Ace/Sequence/FeatureList.pm, Ace/Sequence/Feature.pm, Ace/Sequence/Gene.pm, Ace/Sequence/Transcript.pm, Ace/Sequence.pm Copyright: © 1997-1999 Lincoln D. Stein License: GPL-1+ | Artistic (see below) Files: * Copyright: © 1998 Cold Spring Harbor Laboratory License: GPL-1+ | Artistic This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See the Artistic License file in the main Perl distribution for specific terms and conditions of use. In addition, the following disclaimers apply: . CSHL makes no representations whatsoever as to the SOFTWARE contained herein. It is experimental in nature and is provided WITHOUT WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR ANY OTHER WARRANTY, EXPRESS OR IMPLIED. CSHL MAKES NO REPRESENTATION OR WARRANTY THAT THE USE OF THIS SOFTWARE WILL NOT INFRINGE ANY PATENT OR OTHER PROPRIETARY RIGHT. . By downloading this SOFTWARE, your Institution hereby indemnifies CSHL against any loss, claim, damage or liability, of whatsoever kind or nature, which may arise from your Institution's respective use, handling or storage of the SOFTWARE. . If publications result from research using this SOFTWARE, we ask that CSHL be acknowledged and/or credit be given to CSHL scientists, as scientifically appropriate. X-Comment: On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. X-Comment: On Debian systems, the complete text of the Artistic license can be found in `/usr/share/common-licenses/Artistic'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468951: RFP: libconvert-binary-c-perl -- preprocessor and parser for C type definitions
Package: wnpp Severity: wishlist Recent versions of Bioperl, a suite of perl modules for bioinformatics, depend on the modules provided by Convert-Binary-C. The Debian-Med packaging team would be very happy to find a volunteer to prepare a Debian package for it. We can provide support and sponsorship (but please check first with the pkg-perl team if they would be interested to host the package as well). A few files have a license with a kind of advertisement clause requiring to add "Portions Copyright (c) 1989, 1990 James A. Roskind" in proeminent places. Compatibility with the Perl dual license and the DFSG remain to be investigated :( Package name: libconvert-binary-c-perl Version : 0.70 Upstream Author : Marcus Holland-Moritz URL : http://search.cpan.org/~mhx/Convert-Binary-C/ License : Same as Perl itself, plus others (see below) Programming Lang: Perl, C Description : preprocessor and parser for C type definitions Here are stubs for the control and copyright files: Priority: optional Homepage: http://search.cpan.org/~mhx/Convert-Binary-C/ Enhances: bioperl Description: preprocessor and parser for C type definitions Convert::Binary::C is a preprocessor and parser for C type definitions. It is highly configurable and should support arbitrarily complex data structures. Its object-oriented interface has pack and unpack methods that act as replacements for Perl's pack and unpack and allow to use the C types instead of a string representation of the data structure for conversion of binary data from and to Perl's complex data structures. . Portions Copyright © 1989, 1990 James A. Roskind X-Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat X-Upstream-Author: Marcus Holland-Moritz X-Source-Downloaded-From: http://search.cpan.org/CPAN/authors/id/M/MH/MHX/Convert-Binary-C-0.70.tar.gz Files: ctlib/y_pragma.c Copyright: © 2002-2007 Marcus Holland-Moritz © 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. License: Artistic | GPL-1+ Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. . This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. . As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify or redistribute the parser skeleton itself, you may (at your option) remove this special exception, which will cause the skeleton and the resulting Bison output files to be licensed under the GNU General Public License without this special exception. . This special exception was added by the Free Software Foundation in version 2.2 of Bison. . Copyright (c) 2002-2007 Marcus Holland-Moritz. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Files: ctlib/y_parser.c Copyright: © 2002-2007 Marcus Holland-Moritz © 1989,1990 James A. Roskind © 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. License: Artistic | GPL-1+ Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. . This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. . As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator u
Re: desktop file main category for a scientific data viewer?
Le Mon, Mar 03, 2008 at 08:38:33PM -0800, Russ Allbery a écrit : > Carlo Segre <[EMAIL PROTECTED]> writes: > > > The consensus on the debian-science list is no. Education is simply not > > the right category. We have made several efforts to have this changed > > in the free desktop specification to no avail. Some of us simply use an > > sensible category and let the lintian errors pile up until they come to > > their senses. > > lintian is a tool for Debian maintainers, not for Free Desktop validation, > so as far as I'm concerned if debian-science has reached a consensus on > categories, lintian should recognize those categories. It's not like it's > strictly checking against Free Desktop specifications right now anyway > (since tons and tons of .desktop files use Applications, which also isn't > valid). > > If you can tell me the list of categories on which you've agreed, I'll add > them to lintian. Dear all, There is an ongoing discussion in this subject, but it stalled a few weeks ago. A tentative summary is on the wiki: http://wiki.debian.org/ExtraMenus For the moment, in the Debian-Med packaging team, we use `Categories=Biology;Science;Education;'. Some window managers will automagically create a Science section (Xfce4 apparently), and some more strict will use Education (GNOME). While I have nothing against removing the `Education' category from the list, I am affraid that if there is no concerted changes in other packages (which I did not determine yet), it could result that the entry would appear in the `Other' category, which is not what we want. Have a nice day, PS: there is a tool for checking .desktop files, `desktop-file-validate'. -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding the origin of a binary package.
Le Tue, Mar 11, 2008 at 08:27:22PM +1100, Aníbal Monsalve Salazar a écrit : > I guess the arch is mips. Hi Aníbal, good guess :) Actually, there have been also some mipsel uploads some weeks ago. Thanks for the help! In the meantime I learnt how to use qemu, so I should be able to deal with the problem by myself. Nevertheless, trying to figure out what happens to the .arch.changes file made me curious. So if there is answer, I am still interested in. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Finding the origin of a binary package.
Dear mentors, I am wondering how to find the origin of a binary package: if it was built on a buildd or the machine of a developper, and in this case, who uploaded it. I did not manage to find this information in the Developper's reference nor on the Debian website (http://www.debian.org/devel/buildd/ and http://www.debian.org/devel/buildd/operation). The binary uploads that are joined with source uploads are listed on [EMAIL PROTECTED] Is there a similar list for binary-only uploads? Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470887: RFP: bibus -- bibliographic and reference management software
Package: wnpp Severity: wishlist Package name: bibus Version : 1.4.1 Upstream Author : Pierre Martineau <[EMAIL PROTECTED]> URL : http://bibus-biblio.sourceforge.net License : GPL-2+ Programming Lang: Python Description : bibliographic and reference management software Bibus is a bibliographic database entirely written in python that uses the cross-platform wxWidget library. Bibus has been developed with OpenOffice.org (http://www.openoffice.org/) in mind and can directly insert citations and format the bibliographic index in an opened Openoffice.org writer document. Personnal comment: As a user, I really like Bibus. I find it easier to use and more stable than its proprietary competitor, EndNote. Upstream author is responsive and packaged Bibus as a Debian native pacakge. In the following SourceForge bug, he invites people to finish the work and make bibus an official Debian package. https://sourceforge.net/tracker/?func=detail&atid=657832&aid=1913312&group_id=110943 By the way, the packager would probably have to help solving that bug... Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#470887: RFP: bibus -- bibliographic and reference management software
Le Fri, Mar 14, 2008 at 08:31:39AM -0300, Eduardo M KALINOWSKI a écrit : > Charles Plessy wrote: > > > >Upstream author is responsive and packaged Bibus as a Debian native > >pacakge. In the following SourceForge bug, he invites people to > >finish the work and make bibus an official Debian package. > > > > As this is not a Debian-specific package, it should not be a native > package. Please repackage it as a non-native package. Hi Eduardo, This is exactly what I meant: if somebody adopts this RFP into an ITP, he will not have to start from scratch, but he will have to fix some packaging defects, such as the one you pinpointed. In the meantime, since the package is not official, there is not much to do from the point of view of the Debian project. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: liblicense: dpkg-shlibdeps: failure: couldn't find library
Le Fri, Mar 14, 2008 at 01:46:42PM -0700, Asheesh Laroia a écrit : > I'm working on a package of the last release of liblicense. The > liblicense source package generates liblicense.so.1 in a > liblicense1 package and a program /usr/bin/license that links to > liblicense.so.1 to do its job. Dear Asheesh, I am just wondering if `license' isn't too much a dictionary word to get in /usr/bin. Have you considered if it is used by other programs that are yet not packaged ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: liblicense: dpkg-shlibdeps: failure: couldn't find library
Le Fri, Mar 14, 2008 at 05:19:46PM -0700, Asheesh Laroia a écrit : > > I actually don't know about another program that provides a > /usr/bin/license, even not in Debian. I honestly don't think this is a > conflict. For Debian, apt-file can help. Otherwise, I googled for /usr/bin/license, and found only your project. Nevertheless, maybe some more experience programmer can comment on the use of dictionnary words. In the Debian-Med packaging team, we often have problems of namespace collision. Be careful that from the Debian point of view, there is not guarantee of `first arrived, first served': in the future, if later somebody wants to package a program using /usr/bin/license for another purpose, both will have to be renamed if no agreement is found (Policy 10.1). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: teeworlds
Le Mon, Apr 14, 2008 at 04:19:12PM +0800, Paul Wise a écrit :
> On Mon, Apr 14, 2008 at 3:44 PM, Miriam Ruiz <[EMAIL PROTECTED]> wrote:
>
> > That's the zlib license (http://www.gzip.org/zlib/zlib_license.html)
> > with an extra clause forbidding some kind of commercial usage
> > ("Neither this software nor any of its individual components, in
> > original or modified versions, may be sold by itself"). I'm not really
> > sure that it is DFSG-compliant. I'm CCing debian-legal to get other
> > opinions on that.
>
> That is a similar clause to the one in the Open Font Library. Fonts
> using the OFL have been accepted into Debian, so presumably the
> ftpmasters would accept this licence.
Hi Paul
If yes, please post a mail on [EMAIL PROTECTED],
because I bet that many maintainers of non-free packages will be happy
to make an upload to main.
More seriously, this is obviously non-free, and would make serious
difficulties for the distributors of Debian CDs. Consider that even
software that allow redistibution for a fee but disallow profit are not
accepted in main.
Jack, I strongly recommend to contact Upstream and to expose some clear
arguments in a kind and friendly style. "No commercial use" was invented
in a past were people did not try to live from free software. Upstream
may be sensitive to this, to the problem of redistribution, and might
accept to relicense.
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Removing .pl extension in files from a package using debhelper and CDBS.
Dear mentors, I am preparing a very simple pacakge (mage2tab) that uses CDBS and debhelper: anx159《mage2tab》$ cat trunk/debian/rules #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk I would like to keep this file as simple as possible, but the programs in the pacakge are perl scripts whose name finishe in .pl, so I have to rename them at some point. My problem is that apparently, configure/mage2tab:: or install/mage2tab:: are too early rules if I want to rename after using dh_install: they are not in $(CURDIR)/debian/mage2tab/usr/bin yet. Is there a simple and elegant way to do file renaming with CDBS ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: teeworlds
Le Tue, Apr 15, 2008 at 10:03:17AM +0200, Miriam Ruiz a écrit : > In general I try to avoid heated discussions with stubborn upstreams > The 4th point is simply totally stupid and useless > Some upstreams are just plainly stupid > It's simply too childish. Hello Miriam, while I do not really disagree with your conclusions, I was just wondering before you sent this email if the discussion got heated because the upstream read the thread on -mentors and got upset by persons calling his license "stupid". Since we know that email is a communication method that is very prone to misunderstandings, I think that we should try to play safe when discussion about third parties on a public mailing list. I also wonder if IRC should be avoided for potentially difficult interactions with upstream. Anyway, thank you Jack for having tried. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing .pl extension in files from a package using debhelper and CDBS.
Dear Neil, thank you for the fast answer ! Le Tue, Apr 15, 2008 at 07:56:48AM +0100, Neil Williams a écrit : > > I would add the simple patchsys to that one - it makes it easier for > people to do NMU's on your package at a later date, even if you don't > use it yourself. > > include /usr/share/cdbs/1/rules/simple-patchsys.mk Although it is a good idea, with the arrival of the source format '3.0 (quilt)' I will wait before deciding which way to go. > > I would like to keep this file as simple as possible, but the programs > > in the pacakge are perl scripts whose name finishe in .pl, so I have to > > rename them at some point. My problem is that apparently, > > configure/mage2tab:: or install/mage2tab:: are too early rules if I want > > to rename after using dh_install: they are not in > > $(CURDIR)/debian/mage2tab/usr/bin yet. > > Why not rename them before dh_install ? Are you running these scripts > during the build? > > build/mage2tab:: > install -m 0755 path/foo.pl debian/mage2tab/usr/bin/foo I was thinking that having half of the files installed by a CDBS rule and the other half of them by dh_install was inelegant, but in the end I will do as you suggested. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
Le Fri, May 30, 2008 at 03:07:57PM -0500, Paul Johnson a écrit : > > I keep wondering, "If the goal is to re-distribute 'pristine' source > code and patches, why doesn't Debian discourage users from untarring > the sourced code?"Why can't you make it so the debian directory is > not inside the source tree? One response I've received is that "we > are not RedHat, try to get over it." Dear Paul, There are ways to build a package without untarring the source code; they usually work by indicating a path to the .dsc file to programs that will build the binary packages in a chroot, such as pbuilder (or its faster cousin cowbuilder), sbuild, ... But because of the way the .dsc file contains md5sums of the other components of the source package, I do not know an easy procedure to edit the diff.gz patch, or the format '2.0' / '3.0 (quilt)' tar archives that contain the debian directory, and re-generate the .dsc file. (Any hint from other readers of the list?) One possible way to go is simply to work in a clean unpacked source package, regenerate the source package in the parent directory using the -S option of dpkg-buildpackage, and use cowbuilder or sbuild. It is quite fast actually. For long-term work, as you read in many answers, we often use a version control system. For packages one does not maintain, it is increasingly possible to benefit from this approach by using the `debcheckout' command, if the maintainer have published the URL of their repository. If you make a package from scratch, then you will definitely have to work out the clean rule of the debian/rules makefile so that after building the binary packages and running 'fakeroot debian/rules clean', the directory tree is identical to its starting state. This is not the most funny part of the packaging, but workarounds such as the use of chroot building systems or version control systems will allow you to procrastinate it if you want. Lastly, to answer your original question, the possibility to build the source and binary packages from the untarred sources in which the debian dir has been transferred is quite useful when the compilation is time consuming and the bug in the packaging is downstream of it. Have a nice day, and welcome in Debian ! -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Latest upstream versions of files
Le Mon, Jun 16, 2008 at 02:50:39PM +1000, Ben Finney a écrit : > > The Best Practices chapter of the Developer's Reference suggests > http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-repackagedorigtargz>: > > 6.7.8.2 Repackaged upstream source > > You should upload packages with a pristine source tarball if > possible, but there are various reasons why it might not be > possible. This is the case if upstream does not distribute the > source as gzipped tar at all [???] > > In these cases the developer must construct a suitable > .orig.tar.gz file himself. > > There is no suggestion for the best way to make this happen, though. Dear Ben, the Policy gives more hints: get-orig-source (optional) This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. This target may be invoked in any directory, and should take care to clean up any temporary files it may have left. http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating a package; ediquette and procedure questions
Le Sun, Jun 22, 2008 at 07:16:52PM -0500, Paul Johnson a écrit : > Hi, again. I'm the guy who builds RPMs trying to understand the Debian > way. Still. Hi again, > $ cp ggobi-2.1.7.tar.bz2 ggobi_2.1.7.orig.tar.bz2 Debian provides many facilities in the `devscripts' package. One of them is the uscan/uupdate programs. They need a special file in the source package, `debian/watch', that is unfortunately not available for ggobi. Luckily, it is easy to write: cat > debian/watch version=3 http://www.ggobi.org/downloads/ggobi-(.+)\.tar\.bz2 now if you type `uscan': ggobi: Newer version (2.1.7) available on remote site: http://www.ggobi.org/downloads/ggobi-2.1.7.tar.bz2 (local version is 2.1.6) ggobi: Successfully downloaded updated package ggobi-2.1.7.tar.bz2 and symlinked ggobi_2.1.7.orig.tar.bz2 to it > 3. Go into the new source tree, manually copy over the debian > directory from the previous version: And then, uupdate ../ggobi_2.1.7.orig.tar.bz2 New Release will be 2.1.7-1. -- Untarring the new sourcecode archive ../ggobi_2.1.7.orig.tar.bz2 Success! The diffs from version 2.1.6-2 worked fine. Remember: Your current directory is the OLD sourcearchive! Do a "cd ../ggobi-2.1.7" to see the new package > $ debuild -r fakeroot Latest versions use fakeroot automagically if available. > That ends with a lot of warnings about the source code not being > found, because it is looking for ggobi_2.1.7.orig.tar.gz, but i have > the bz2 file instead. Maybe you do non have the latest version of our toolchain (dpkg-dev, ...)? Using bz2 works except that these packages are not yet accepted by our archive management system. > In the end, I could find no way to make that go away except for > re-packaging the source code from a bz2 file to gz. After that I'm > able to build both the deb package and the source pieces. > > Here are my questions, in no particular order. > > 2. In Ubuntu, or Debian more generally, what happens when package > maintainers don't stay up to date? It is a little tough to figure out > who is responsible for a package sometimes, there is an > OriginalMaintainer and other names in the changelog. If you email the > person you think is in charge, and don't get an answer, what do you > do? In Debian, the responsible persons are listed in the Uploaders and Maintainers field. Websites such as packages.debian.org display this information. Request for packaging a new upstream release can be adressed by mail or by bug, and if there is not answer within a month, one can enquire wether the package is unmaintained or not. If unmaintained, it will be adopted, orphaned or removed). > This reminds me, I noticed today that in Ubuntu, the supplied version > of R is 2.6.2, but I need 2.7, the current version. For Ubuntu, you have to contact Masters Of The Universe (MOTUs). They decide wether imorting the latest Debian package is appropriate given their release strategy. > 3. What do you do with code distributed in bz2 files? For the moment we bunzip2 and gzip them :( > 4. Suppose I succeed in building some packages and want to post them > on a website. http://www.debian.org/doc/manuals/repository-howto/repository-howto.en.html ? Have a nice day, and thanks for your interest in Debian. PS: You may save some time by reading things in the followign section of our website: http://www.debian.org/doc In particular http://www.debian.org/doc/manuals/maint-guide/ PPS: for more complex packages, it is not always that easy. -- Charles Plessy Debian-Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with implicit rule for .o files and overriding of CXXFLAGS.
Dear mentors, while working on an update to the `proda' package, I realised that a compilation option, DVERSION="\"1.00\"", was discarded during the build of the Debian binary package. The reason is very simple: OTHERFLAGS = -DVERSION="\"1.00\"" CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS) proda : $(OBJECTS) $(CXX) $(CXXFLAGS) -lm $(OBJECTS) -o proda The Debian build system overrides CXXFLAGS and $(OTHERFLAGS) is never passed to the compiler. First of all, I would appreciate if somebody could give me a link to an authoritative documentation that explains that CXXFLAGS (and others) should be expected to be changed to local values by the user. It seems to me that many upstream authors ignore this fact and write makefiles that will not work well if CXXFLAGS is changed to the Debian standard values. (In exchange for the link, I will update http://wiki.debian.org/GettingPackaged accordingly). For Proda, I would like to submit a change upstream, such as something like: OTHERFLAGS = -DVERSION="\"1.00\"" CXXFLAGS = -g -W -Wall -pedantic proda : $(OBJECTS) $(CXX) $(CXXFLAGS) $(OTHERFLAGS) -lm $(OBJECTS) -o proda Unfortunately, $(OBJECTS) is a long list of .o files, each built by implicit rules like: foo.o: bar.h baz.h toto.o : tata.h anotherone.o : baz.h tutu.h etc... My problem is that I do not know the contents of the implicit rule building the .o files from the .h files, nor how I can tell to make to add $(OTHERFLAGS) to this implicite rule. Any idea ? Have a nice day, -- Charles Plessy Debian-Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Le Wed, Jun 25, 2008 at 11:06:09AM +, Yavor Doganov a écrit :
>
> > OTHERFLAGS = -DVERSION="\"1.00\""
> > CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)
>
> Use CPPFLAGS for this -- of course the recipes should be properly written
> in order to have some effect.
> > authoritative documentation that explains that CXXFLAGS (and others)
> > should be expected to be changed to local values by the user.
>
> The Automake manual, or the GNU Coding Standards. CFLAGS, CXXFLAGS,
> CPPFLAGS, LDFLAGS, etc. are "user" variables so any build system that
> does not respect the user's choice is kind of buggy. At least for
> packages using the GNU build system. IOW, you should be able to define
> all of these variables from within debian/rules and upstream's build
> system should obey your choice.
Thanks Yavor and everybody else for your answers.
I have added the following paragraph in http://wiki.debian.org/GettingPackaged
Some {{{make}}} variables are reserved to the user, and the
[http://www.gnu.org/software/libtool/manual/automake/User-Variables.html#User-Variables
Automake manual] and the
[http://www.gnu.org/prep/standards/standards.html#Command-Variables GNU coding
standards] advise to never use them for switches that are required for proper
compilation of the package. When a Debian binary package is built, variables
such as {{{CFLAGS}}}, {{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set in the
environnement and override the ones in the {{{Makefile}}}. We of course
strongly recommend to follow the above advice.
For Proda, if I pass -DVERSION="\"1.00\"" through CPPFLAGS, it indeeds
solves my problem. But what can I propose upstream that fits the best
practices that I just added to the wiki? If CPPFLAGS is set in the
Makefile, it could be overriden, but if it is set to
-DVERSION="\"1.00\"" from debian/rules, then this is one more think that
one can forget to update when a new upstream version is released...
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Le Wed, Jun 25, 2008 at 03:09:28PM +, Yavor Doganov a écrit :
> ?? Wed, 25 Jun 2008 23:14:44 +0900, Charles Plessy :
>
> > When a Debian binary package is
> > built, variables such as {{{CFLAGS}}}, {{{CXXFLAGS}}},
> > {{{CPPFLAGS}}},... are set in the environnement and override the ones
> > in the {{{Makefile}}}.
>
> That's not entirely true and not entirely false. It's closer to being
> false, though. Environment variables do not override the ones explicitly
> set in the makefile (or on the command line), unless you do `make -e'.
Thanks for the clarification. Would the following be better?
When a Debian binary package is built, variables such as {{{CFLAGS}}},
{{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set by the Debian building system
to override the ones in the {{{Makefile}}}.
> So If i were you I that patch would be only:
>
> - OTHERFLAGS = -DVERSION="\"1.00\""
> + CPPFLAGS = -DVERSION="\"1.00\""
Adopted!
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg not changing the ownership of directories.
Hi all, after banging my head for hours wondering why one given directory in a pacakge I work on did not have the correct ownership (www-data), I realised that that the answer is in the Policy, footnote #71. "... the permissions and ownership of directories already on the system does not change on install or upgrade of packages. This makes sense, since otherwise common directories like /usr would always be in flux. ..." http://www.debian.org/doc/debian-policy/footnotes.html#f71 So what happened is that first I made a (local) package with the wrong permissions, and then any attempt to correct this was doomed as long as I would not remove the package before installing a new version testing a variation on how to call chown. After a few hours of more thinking, I still do not understand the footnote #71 of the Policy. Could somebody post an explanation? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Le Fri, Jun 27, 2008 at 10:01:18AM +, Yavor Doganov a écrit :
> ?? Thu, 26 Jun 2008 09:48:32 +0900, Charles Plessy :
>
> > Would the following be better?
> >
> > When a Debian binary package is built, variables such as {{{CFLAGS}}},
> > {{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set by the Debian building
> > system to override the ones in the {{{Makefile}}}.
>
> I don't know; this text still makes me feel uneasy.
Hi again,
how about :
Some {{{make}}} variables are reserved to the user, and the
[http://www.gnu.org/software/libtool/manual/automake/User-Variables.html#User-Variables
Automake manual] and the
[http://www.gnu.org/prep/standards/standards.html#Command-Variables GNU
coding standards] advise to never use them for switches that are
required for proper compilation of the package. When a Debian binary
package is built, environment variables such as {{{CFLAGS}}} and
{{{CXXFLAGS}}} are set by {{{dpkg-buildpackage}}} and may override the
corresponding variables in the {{{Makefile}}}. We therefore strongly
recommend to follow the above advice.
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Dear Mentors and Apache maintainers, In the course of making a package (emboss-explorer) FHS-compliant, I moved its files from /var/www to /usr/share. I would like http://localhost/mypackage to work after package installation just as before when the package was installing its files in the default document root of apache2 (and maybe other webservers). For the moment I will only support apache2 because of my lack of knowledge of other systems, but of course suggestions on how to achieve this with other httpd-cgi servers are appreciated. After insallation, the package must: - Check if apache2 is there, - if yes add a link to a configuration file in /etc/apache2/conf.d - restart apache. Of course, I can cut-and-paste from the postinst script of other packages already implementing this, but before doing so I was wondering if there were some factorised code somewhere that I could call instead. (I am also wondering if I have to ask the user wether he agrees to restart apache...) In the worst case, I can just document in README.Debian that the link has to be created and apache restarted, but as the package I am working on is a www interface to a command-line program, I would prefer that it does not require command-line intervention, since its public is partly composed of persons who are not comfortable with command-line. PS: would the DPKG triggers be a good mechanism to deal with this apache restarting tasks? Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sat, Jul 05, 2008 at 11:04:31AM +0800, Paul Wise a écrit : > wwwconfig-common may provide what you need. Le Fri, Jul 04, 2008 at 11:34:43PM -0400, Richard Hurt a écrit : > You could also check out webapps-common > (http://webapps-common.alioth.debian.org/draft-wac/html/index.html ) > although I don't know which one is more current/appropriate. Thanks for your answers! Unfortunately webapps-common is dead upstream, and wwwconfig-common does not provide debconf templates. I think that I will just drop a symlink in /etc/apache2/conf.d and hope that some magic will be done some day with DPKG triggers. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sun, Jul 06, 2008 at 11:02:50AM +0200, Stefan Fritsch a écrit : > On Saturday 05 July 2008, Charles Plessy wrote: > > - restart apache. > > A reload should be enough. Don't restart apache if it is not necessary > (as it aborts active connections and may require the admin to enter > ssl key passphrases, etc.). Thanks a lot for the answer. Would something like: if [ -x /etc/init.d/apache2 ]; then if which invoke-rc.d >/dev/null 2>&1; then invoke-rc.d apache2 reload else /etc/init.d/apache2 reload fi fi be acceptable? > It would be nice > though, if the restart was only done when necessary (on new installs > and on upgrades if the config file changed). Hmmm, I am not sure to know how to test if the config was changed... Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sun, Jul 06, 2008 at 03:41:09PM +0200, Marc Chantreux a écrit : > On Sun, Jul 06, 2008 at 10:19:34PM +0900, Charles Plessy wrote: > > if [ -x /etc/init.d/apache2 ]; then > > if which invoke-rc.d >/dev/null 2>&1; then > > invoke-rc.d apache2 reload > > else > > /etc/init.d/apache2 reload > > fi > > fi > > why not something simple like > > /etc/init.d/apache2 reload || error_function Because invoking directly init.d scripts is forbidden by the Policy: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 "The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly." For the test of existence of /etc/init.d/apache2, it may be a matter of taste... In that case again, having some helper functions would make the the script easier to read and factorise some code... Bonne journée -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Le Sun, Jul 06, 2008 at 09:34:33PM +0300, Yavor Doganov a écrit :
> Charles Plessy wrote:
> > how about :
> >
> > When a Debian binary package is built, environment variables such as
> > {{{CFLAGS}}} and {{{CXXFLAGS}}} are set by {{{dpkg-buildpackage}}}
> > and may override the corresponding variables in the
> > {{{Makefile}}}.
>
> The matter is more complex in general; add here the well known fact
> that a truckload of upstream makefiles/build systems is broken.
Well, this is why I tried to write something in the wiki page that is
supposed to be something to read for upstream maintainers. But I am not
a C programmer, I do not think I can improve what I wrote any further. I
can delete it if it is too confusing, however.
Thanks for the explanation anyway, this FLAGS management is a real
headache…
Have a nice day,
--
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sun, Jul 06, 2008 at 11:05:27AM -0700, Russ Allbery a écrit : > Stefan Fritsch <[EMAIL PROTECTED]> writes: > > On Saturday 05 July 2008, Charles Plessy wrote: > > >> - if yes add a link to a configuration file in /etc/apache2/conf.d > > > You can add that file or the link unconditionally. > > That would really upset me if I were a systems administrator. Most of my > Apache configurations have multiple virtual hosts, and having some package > randomly add itself to the namespace of every virtual host I run, possibly > taking over pages that were currently serving some other purpose, would be > extremely annoying. > > I'd want at least a debconf prompt before something added itself to the > global Apache configuration. Well, it definitely makes sense, but it makes me wonder if my goal is achievable. The frontend I package is as useful on purely local systems (a laptop for instance) as on servers (indeed if you search for `emboss explorer' you will find sites running it). So if the package does things automatically, it can annoy system administrators who run it on a dedicated web server. But if the package pulls apache2 and installs its configuration automatically, end users will benefit of it as just another graphical interface, with the only peculiarity that it needs a browser to be used. How can this conflict of interest be solved? EMBOSS explorer is a nice interface, and I really would like to provide to end users with no command-line interactions with the system. How about making it available only for localhost by default? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Mon, Jul 07, 2008 at 04:05:54PM +0200, Mike Hommey a écrit : > > Why not have your package create its own apache instance, with its own > config and its own port ? Probably because I have no clue on how doing this cleanly ;) But why not? An in that case, why not something lighter than Apache… Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dcraw (updated package)
Le Tue, Jul 08, 2008 at 11:54:01PM +0200, Leopold Palomo Avellaneda a écrit : > A Dimarts 08 Juliol 2008, Carl Fürstenberg va escriure: > > Dear mentors, > > > > - dget > > http://mentors.debian.net/debian/pool/main/d/dcraw/dcraw_8.86-0.1.dsc > > > > I don't understand this. > > This package has a maintainer, and he's the maintainer from the beginning I > think. I know that is not a DD, but why not to ask him, or make a bug report > if you don't like the package? Or what's happening? Hi Carl, The debdiff between 8.86-1 and 8.80-1 is definitely too intrusive for a NMU, let alone that NMUs are not to be used for new upstream releases but for helping maintainers to fix important bugs in their packages. I understand that the situation can be frustrating since the current version in Debian can not handle some cameras (#482816), but if you want to help the maintainer of the dcraw package in Debian, you should not do changes such as introducing a patch system that may not be his favorite. Have you tried to contact the maintainer? Your wishlist bug for a new upstream release is only one day old! Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dcraw (updated package)
Le Wed, Jul 09, 2008 at 03:35:12PM +0200, Carl Fürstenberg a écrit : > Hehe, perhaps I was too fast there. first of, I remade the package, > making it less changed from the previous version. The only real change > now is the new upsteam version and internationalization of manpages. I > have contacted the maintainer, but no reply as of yet, I noticed that > the wishlist report I made is a dupe from an bug report (marked > important), made 45 days ago, and no reply by maintainer, so I'm > afraid the maintainer is MIA. > When is the final deadline for lenny? was hoping that the latest > version could get squeezed in there. Hi Carl, there is no fixed deadline for Lenny, but the latest mail on debian-devel-announce says mid-July, so if you add 10 days of delay before migration to Testing, dcraw is maybe already out. http://lists.debian.org/debian-devel-announce/2008/06/msg0.html If the maintainer of the Debian dcraw pakcage is MIA, then it does not make sense to do a NMU anyway: NM in NMU means 'Non-maintainer', not 'No maintainer' ;) Basically whoever uploading a new upstream release would have to take the responsability of the package and its bugs. Not answering a wishlist bug is not the ultimate proof of disparition of the maintainer. I think that if you collect evidence that he stopped to post on the mailing lists he used to, if he does not answer mails asking him if he still has time to give to Debian, and if he doe not react to a 'Intend to Hijack' email (CC debian-devel), then you may find a sponsor that lets you taking over the responsability of the package (although I would recommend team work for any package: we all can become MIA at any time). Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dcraw (updated package)
Le Wed, Jul 09, 2008 at 11:33:17PM +0200, Leopold Palomo-Avellaneda a écrit : > > I think that the lenny deadline is an important question, but I would give to > the debian maintainer some "period of grace". What do you think? My personnal opinion is that skipping six upstream releases and not answering to bugs on the BTS is enough inactivity to seriously consider adding one maintainer to the package, but I am relatively young as a DD and I am sure that others may be more conservative than me. Ultimately, the person that is responsible of dcraw is the sposor. sorbet【tmp】$ who-uploads dcraw Uploads for dcraw: 8.80-1 to unstable: Anibal Monsalve Salazar <[EMAIL PROTECTED]> What is your opinion, Anìbal? -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dcraw (updated package)
Le Thu, Jul 10, 2008 at 03:56:30AM +0200, Cyril Brulebois a écrit : > > pkg-phototools Salut Cyril, team maintainance is definitely the way to go. dcraw is the kind of program that will always be obsolete in Debian stable anyway, so despite the time that has been lost, I agree that rushing for Lenny does not make sense. I would rather recommend a special care for easy backporting. So in conclusion, Carl, I recommend you to contact the pkg-phototools team while doublechecking that the current maintainer is MIA, and see how you can either join or help them for the takeover if necessary. In the long term, I am sure that it will benefit more to the Lenny users. Anyway, thanks a lot for raising the issue, dcraw is definitely the kind of package that will attract bitter complains if the only reason why people can not use their camera is that the pakcage has been neglected. PS: if the package is taken over, maybe you can consider using the upstream tarball complemented with other upstream files rather that assembling a debian-specific orig.tar.gz. http://www.cybercom.net/~dcoffin/dcraw/archive/ Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging for wine
Le Fri, Jul 18, 2008 at 09:01:01AM +0200, dmanye a écrit : > they ask for pajek(http://pajek.imfm.si/doku.php) Hi, Although there is no direct equivalence, you can have a look to the systems biology page of the Debian Med project on our wiki: http://wiki.debian.org/DebianSystemsBiology Many of these tools are as good with sociology as with biology. You are of course most welcome to join our team to package them :) Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preferred way to do a chown on package's dirs ?
Le Thu, Aug 07, 2008 at 03:12:42PM +0200, Olivier Berger a écrit : > Hi. > > I'm not sure I can find authoritative information on how a packager > should change the ownership (chown) of a shipped directory. > > Of course this can be done in the package's postinst. It may actually have to, if there is a possibility that the directory already exists and has a different ownership, because in that case dpkg will preserve it on install/upgrade. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to understand patch management - in combination with version control
Hi Andreas, Le Wed, Sep 03, 2008 at 01:04:36AM +0200, Andreas Schildbach a écrit : > > Now, when I (or a co-maintainer) check out the project from SVN, I get > (as expected) a nearly empty project directory, containing just the > debian directory. But, how am I supposed to actually create the patches > that go into debian/patches? My current understanding is: I > modify/delete/create a set of files and use something like > interdiff/debdiff to extract the changeset. But in the case of > mergeWithUpstream-mode there is no file to modify... Don't tell me I > have to write patches "by hand" (-: No, that would be too simple, you have to type them with the feet ;) More seriously, if you unpack the upstream tarball somewhere and copy the debian directory from your SVN in the unpacked sources, you can manage patches with your favorite program (quilt?) and commit them when they are good enough. You can refer to the Debian Med group policy (in construction): http://debian-med.alioth.debian.org/docs/policy.html#id295312 Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to understand patch management - in combination with version control
Hi Ben, Le Wed, Sep 03, 2008 at 01:04:12PM +1000, Ben Finney a écrit : > Andreas Schildbach <[EMAIL PROTECTED]> writes: > > > I am maintaining a rather large package and have decided to use a > > version control system (SVN). > > An unfortunate choice of VCS, since it is far behind more modern VCS > software for flexibility of management. Any of Git, Bazaar, Darcs, or > (perhaps) Mercurial would be a better choice for a new project IMHO. Sure, but Andreas wrote that he needs the MergeWithUpstream feature of svn-buildpackage because the upstream source contains non-redistributable material. I would be especially interested by any replacement for this. I am starting to wonder about the viability of keeping the whole upstream sources in a VCS. If a non-redistributable file brought by a new upstream release were accidentally commited (in my case, it would typically be a PDF version of a scientific article), is there a VCS that would allow to permanently delete it? If such file stays in the history, would it be a copyright violation? Which VCS allows the repository to be corrected after such an accident, even if other commits happened in the meantime? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
Le Sun, Sep 14, 2008 at 04:00:18PM +0200, Andreas Schildbach a écrit : > Is there any way to tell quilt about the debian package structure? Hi Andreas, less /usr/share/doc/quilt/README.source Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: avr-evtd
Le Tue, Sep 16, 2008 at 02:16:19AM -0300, Rogério Brito a écrit : > > I would be glad if someone uploaded this package for me or provided me > with constructive criticism. Hi Rogério, I had a look to your package. I am not very familiar with that kind of software, so I will only make comments on the packaging. * Although Upstream does not seem to be active since two years, I would anyway recommend to publish your patches on SF.net. At least it could be useful to other distros, or encourage people to prepare a new release. If you like the idea, then I suggest that once it is done you add the URL to the patch on SF.net in the header of the patch. * Some of your patches fix coding style (whitespaces, DOS carriage returns, indentation). Consider that they may create a small work overhead to people who may have to investigate the package, for instance if there is a security issue while you are in vacation. They will also make it uneasy to exchange patches with Upstream or other distros when these patches are applied after the coding-style ones. * To fully comply with Policy 3.8.0, you can copy /usr/share/doc/quilt/README.source or mention it in debian/README.source. * If you have free time, like the idea and want to help it gain momentum, you can consider converting your copyright file to the format detailed in http://wiki.debian.org/Proposals/CopyrightFormat. to the format. * Upstream chose -Os for compilation. -O2 in Debian is not strictly mandatory, so if you find that sticking to -Os helps, you can. * Upstream's makefile has some instructions (-DMIPS) if it detects mips CPU. You do not do the same test in debian/rules (an you do not use Upstream's makefile). Is it intentional? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
Le Tue, Sep 16, 2008 at 08:07:00PM +0400, Al Nikolov a écrit : > > OTOH, devreference is not a collection of common used practices (what is may > be sad), but a Le Tue, Sep 16, 2008 at 06:14:40PM +0200, David Paleino a écrit : > > AFAICT, using the proper suffix to describe *why* the upstream source tarball > has been repacked *should* be in the *recommended* procedures. Hi, the best way to figure out is to send a patch and see if it is accepted ;) Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Le Tue, Sep 16, 2008 at 07:11:59PM -0500, William Vera a écrit : > Hello Mentors > I have a problem trying to update a package using cdbs, > that's appears duplicate installations of the docs files, > in /usr/doc/foo and /usr/share/docs/foo Hi, it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Le Tue, Sep 16, 2008 at 08:56:45PM -0500, William Vera a écrit : > 2008/9/16 Charles Plessy <[EMAIL PROTECTED]>: > > > > it is probably that debhelper installs the docs (README AUTHORS > > ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo > > (see Makefile.am). The file names of the docs are generic enough that > > Debhelper guesses them. > > > > Thanks, that appears it is the problem, so I guess just need patch Makefile.am > I'm correct? Patches are a higher work overhead than we suspect. If you are not in a hurry, I would recommend to ask Upstream he can change the path to the docs. That would make him do the work for you ;) Other alternatives to patching are to delete $(CURDIR)/debian/yourpackage/usr/doc, or to try to override the path at build time. If you chose to patch, I suggest that you forward it upstream and indicate this in the patch header. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Phony patch target: is it necessary ?
Hello everybody, there was recently a discussion on this list about the necessity of using $(QUILT_STAMPFN) instead of patch as a patching target. I had a look at /usr/share/dpatch/dpatch.make and /usr/share/quilt/quilt.make and realised that only Quilt makes the patch target phony. Is there actually a good reason for this? I was considering fixing all our packages in Debian Med and maybe ask the Quilt and Dpatch maintainers to standardise their target names, but maybe the simplest solution is to make the patch rule not phony? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to install package using apt-get in folder other than /usr
Le Mon, Sep 29, 2008 at 02:46:00PM +0100, Neil Williams a écrit : > On Mon, 2008-09-29 at 06:36 -0700, Kruti wrote: > > i mean when you do apt-get install , all the files of the package > > are installed in /usr.for eg: packge binary in /usr/bin. > > but if i want the package n all its files to be installed in a directory > > other than /usr for eg in XYZ directory thn what should i do...thnks > > The package determines the directories, it is not up to you to change it > unless it is your package (and changes must be compliant with Policy) - Hi Neil, I guess that Kruti meant that if a foobar package has the following files: /usr/bin/foobar /usr/share/man/man1/foobar.1 /etc/foobarrc (...) he would like to install it the files in prefix/bin/foobar prefix/share/man/man1/foobar.1 prefix/etc/foobarrc (or even $Prefix/.config/foobarrc) (...) and that if foobar depends on bazbaz, then with an appropriate apt-get command, bazbaz can be installed in the same prefix. While I would also love to have this feature in Debian, it is indeed offtopic on this list and should better be a wishlist bug of apt-get, aptitude, or any other frontend to dpkg. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] Re: how to install package using apt-get in folder other than /usr
Le Mon, Sep 29, 2008 at 03:49:01PM +0100, Neil Williams a écrit : > > > and that if foobar depends on bazbaz, then with an appropriate apt-get > > command, bazbaz can be installed in the same prefix. > > For what purpose? Installing Debian packages without administrator privileges and without messing with other users works. Where I work, the calculation machines have a standard system installed (CentOS...), and the way to update and install software is either to request to the (busy) admins to install an (obsolete) CentOS RPM binary package, or to download the upstream tarball and compile everything in our home directory. Actually, for upgrading a program for which one is not the only user this is the only way to go because global update may expose the work of the other users to new bugs. I admit I never asked for a chroot, but can we use chroots without administrator privileges ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Re: how to install package using apt-get in folder other than /usr
Le Mon, Sep 29, 2008 at 11:15:55PM +0100, Neil Williams a écrit : > Charles Plessy <[EMAIL PROTECTED]> wrote: > > > > Installing Debian packages without administrator privileges and without > > messing with other users works. > > chroot > > That is very close to the definitive purpose of using a chroot. Hi Neil, the idea looks intersting, but in the end the consequence is that the administrators have to learn one more tool, that looks very complex, whereas one of the goals of letting the user installing packages in his home directory is to not bother the admins. Also, as giving schroot access means giving opportunity to get root priviledges, it is something that definitely sounds scary even in trusted environments. I am more looking for something that looks simple like zeroinstall. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avr-evtd (a heartbeat daemon for some embedded NASes)
Le Fri, Sep 26, 2008 at 03:09:44PM -0300, Rogério Brito a écrit : > > http://mentors.debian.net/debian/pool/main/a/avr-evtd/avr-evtd_1.7.3-1.dsc Hi Rogério, I sponsored it; it is now in the NEW queue. It was built on amd64, but I do not know if it is useful there. Please test the ppc package when it will have been autobuilt. Also, as a Debian Maintainer, you will be able to directly upload the package by yourself. But in doubt, do not hesitate to ask for review on this list or debian-powerpc (whichever the most appropriate). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Re: how to install package using apt-get in folder other than /usr
Le Wed, Oct 01, 2008 at 06:32:01AM +0530, Kapil Hari Paranjape a écrit : > Hello, > > On Tue, 30 Sep 2008 21:19:27 +0900 Charles Plessy <[EMAIL PROTECTED]> wrote: > > whereas one of the goals of letting the user installing packages in his > > home directory is to not bother the admins. > > In that case, use fakechroot, it may be enough for you. Hi Kapil, So basically, the concept would be that on workstations, no work is done in the home directories, but in chroots instead? In the end it looks similar to the Amazon elastic computer cloud. Such a concept would definitely be very flexible for users and admins, and I would definitely be eager to try it if somebody builds a user-friendly free software equivalent. I just noticed the zeroinstall-injector package in Debian. I will give it a try, and if it looks functionnal, I will suggest to use Debian instead of CentOS to our admins next time we buy a shared workstation. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building package,
> On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote: > > dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with > > libpthread.so.0 (it uses none of its symbols). Le Thu, Oct 02, 2008 at 11:15:20PM +0200, Luca Bruno a écrit : > Your package is linking against libpthread and it might not be used. If your > program uses it, then ignore the warning. If your program doesn't really use > it, add --as-needed in the LDFLAGS in your debian/rules. Hi all, Is it the kind of issue that is worth reporting upstream? If yes, could somebody update http://wiki.debian.org/GettingPackaged (I do not understand enough the issue for doing it myself). It would then be easy to inform upstream of the unnecessary links and point at this page for the explanations. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: recoverjpeg (updated package)
Le Tue, Oct 07, 2008 at 09:08:42PM -0500, William Vera a écrit : > Dear mentors, > > I am looking for a sponsor for the new version 1.1.2-1 > of my package "recoverjpeg". > > It builds these binary packages: > recoverjpeg - Recover jpeg pictures from a filesystem image Hello William, just for curiosity, how does recoverjpeg compare to photorec? http://packages.debian.org/sid/testdisk Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: recoverjpeg (updated package)
Le Tue, Oct 07, 2008 at 09:32:22PM -0500, William Vera a écrit : > > recoverjpeg just looks for a jpeg structure into the file system and > photorec appears be a more complete suite for recover files, both to > differents usages. Le Wed, Oct 08, 2008 at 11:51:41AM +0800, Paul Wise a écrit : > > A year ago I tried to get recoverjpeg, recoverPhotos and PhotoRec to > merge into PhotoRec, at the time it appeared there was no difference > between recoverjpeg and PhotoRec. Of course there was no action on the > part of any of the upstreams. Hi William, if you like and use recoverjpeg, and think it is worth being packaged, go ahead. But if your concern is to get the package into better shape for the sake of Debian's quality and excellence, please consider investigating if the package can be removed instead. This would also be a very valuable contribution to Debian. PS: you may be interested in the pkg-phototools project: http://pkg-phototools.alioth.debian.org/ Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: NMU for tau 2.16.4-1.2 (fix RC bugs)
Le Thu, Oct 09, 2008 at 08:56:37PM +0200, Luca Falavigna a écrit : > > I uploaded on mentors.d.n NMU candidate for tau 2.16.4-1.2 [1], > which fixes two RC bugs [2-3]. I attached a debdiff of the changes > provided in the bug reports. Could you please have a look at it? > > [1]http://mentors.debian.net/debian/pool/main/t/tinyscheme/tinyscheme_1.37-3.1.dsc > [2]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458874 > [3]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476638 Hi Luca, The maintainer of Tau is obviously inactive (see his QA page). Maybe it would be better to check with the QA team if they are willing to adopt the package, or if it is better to remove it? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian packages containing large files
Le Wed, Oct 15, 2008 at 09:51:32AM -0700, Sammy Yu a écrit : > > I've created a debian package which has a large file that is > slightly over 2 gigs of ram in size. When I try to install it on a > system with 16 GB of RAM via dpkg -i. It gives me > > Unpacking replacement data-instance0 ... > dpkg: error processing data-instance0-1.0-20081014.deb (--install): > failed to allocate buffer in buffer_copy (backend dpkg-deb during > `./var/lib/mysql/extdbfiles/0/archetype/table1.ibd'): Cannot allocate > memory Dear Sammy, thanks for your pioneering work :) Maybe you can ask your question on [EMAIL PROTECTED] and/or report a bug against dpkg? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: procinfo (tpu upload to fix RC bugs)
Le Wed, Oct 15, 2008 at 08:41:51PM +0200, Giuseppe Iuculano a écrit : > > This is a tpu upload approved by the release team: > http://lists.debian.org/debian-release/2008/10/msg00683.html Dear Giuseppe, thank you for your care, I uploaded it. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: blam (updated package)
Le Thu, Oct 16, 2008 at 05:48:40PM +0900, Charles Plessy a écrit : > > I'm looking for a sponsor for blam version 1.8.6. Blam is a GTK/GNOME > > feed reader whose main features are theming support and a simple > > interface. As of this version it runs completely in managed mode. By the way, since you are upstream, you may be tempted to review and close the relevant Launchpad bugs with LP:#nn instructions. https://bugs.launchpad.net/ubuntu/+source/blam Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: blam (updated package)
Le Wed, Oct 15, 2008 at 09:13:41PM +0200, Carlos Martín Nieto a écrit : > Hello, > > I'm looking for a sponsor for blam version 1.8.6. Blam is a GTK/GNOME > feed reader whose main features are theming support and a simple > interface. As of this version it runs completely in managed mode. > > The package appears lintian-clean and builds the following binary > packages: > blam - a simple RSS aggregator for GNOME > > This upload would fix the following bugs: 292461 319302 326993 342226 > 473626 480790. > Bugs #473626 and #480790 are release-critical, though the package was > removed from lenny some time ago (precisely because of this) so it's not > that impressive. Dear Carlos, it seems that blam has a freeze exception, so if all bugs are fixed the package will be free to migrate into Lenny. Have you checked with the release team that they accept to get the version 1.8.6 in, or will Xul issues prevent the migration anyway ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A bunch of questions: buildd, chm, build dependencies, software patent issue
Le Sun, Oct 26, 2008 at 03:24:22PM +0100, Jose Luis Blanco a écrit : > > This software for the detection of invariant keypoints is being made > available for individual research use only. Any commercial use or any > redistribution of this software requires a license from the University > of British Columbia. Dear Jose, this license actually clearly forbid redistribution of the program if one does not obtain a commercial licence. Debian can not redistribute it, even in the non-free section of its archive. If you really feel like packaging it, you can contact the authors and/or the copyright holder to obtain a relicencing or an exemption for Debian that would make it suitable for a redistribution in "non-free". But even in that case, I would advise avoiding using this software without a proper IP agreement, even for research: one may become unable to commercially exploit any discovery made with the patented method. And there is at least on precedent where doing non-profit research was considered commercial exploitation as it can help to attract sutdents who pay to enter the university. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Getting -m64 at the right time and place.
Dear mentors,
I am working on a package that, when unmodified, fails on 32bits arches because
-m64 is in the CFLAGS. We solved the problem by patching the configure file,
but of course this breaks when new upstream releases refresh it with newer
versions of autoconf.
I am now exploring the possibility of making one patch modifying configure.ac,
and another that would be easy to refresh with autoreconf. But before doing so
I would like to hear your advices: isn't this -m64 micromanaging useless and
should I propose Upstream to give full freedom to Autoconf to deal with the
issue?
The package is "maq", our current patch is on svn.debian.org and
patch-tracking.debian.net, and the Upstream sources can be browsed on
Sourceforge:
http://packages.qa.debian.org/m/maq.html
http://patch-tracking.debian.net/patch/series/view/maq/0.6.7-1/10_prevent_-64_option.patch
http://maq.svn.sourceforge.net/viewvc/maq/trunk/maq/configure.ac?revision=672&view=markup
The modification I consider is the following:
--- a/configure.ac
+++ b/configure.ac
@@ -23,10 +23,6 @@ case "${host_cpu}-${host_os}" in
AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64"], []);;
esac;;
*)
-AC_MSG_CHECKING([if gcc accepts -m64])
-CFLAGS="-m64"
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64";
AC_MSG_RESULT([yes])],
- [ext_CFLAGS="-D_FILE_OFFSET_BITS=64";
AC_MSG_RESULT([no])]);;
esac
AC_ARG_ENABLE(experimental, [ --enable-experimental enable experimental
features],
[ext_CFLAGS="${ext_CFLAGS} -DMAQ_SHOW_EXPERIMENTAL"],
[])
However, as I do not understand the purpose of -D_FILE_OFFSET_BITS=64, I am
worried it would be breaking maq on 32-bit arches to remove it. How can we have
a configure file that does the right thing: -m64 only on 64-bit architectures?
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting -m64 at the right time and place.
Le Sat, Nov 15, 2008 at 08:37:49AM +0100, Mike Hommey a écrit :
> On Sat, Nov 15, 2008 at 12:37:55PM +0900, Charles Plessy wrote:
> > However, as I do not understand the purpose of -D_FILE_OFFSET_BITS=64, I am
> > worried it would be breaking maq on 32-bit arches to remove it.
>
> It will only break its ability to read large files (> 2GB). That is what
> _FILE_OFFSET_BITS is for.
Le Sat, Nov 15, 2008 at 04:52:52PM +0900, Paul Wise a écrit :
>
> > I am now exploring the possibility of making one patch modifying
> > configure.ac,
> > and another that would be easy to refresh with autoreconf. But before doing
> > so
> > I would like to hear your advices: isn't this -m64 micromanaging useless and
> > should I propose Upstream to give full freedom to Autoconf to deal with the
> > issue?
>
> Send a patch upstream and educate them why this is a bad idea.
Dear Mike and Paul,
thanks a lot for your answers.
Maq is likely to have to access files bigger than 2Gb sometimes, so I probably
should not remove -D_FILE_OFFSET_BITS=64.
Would the following patch make sense?
diff --git a/configure.ac b/configure.ac
index ad2f1e6..4f2993a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,10 +23,7 @@ case "${host_cpu}-${host_os}" in
AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64"], []);;
esac;;
*)
-AC_MSG_CHECKING([if gcc accepts -m64])
-CFLAGS="-m64"
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64";
AC_MSG_RESULT([yes])],
- [ext_CFLAGS="-D_FILE_OFFSET_BITS=64";
AC_MSG_RESULT([no])]);;
+ext_CFLAGS="-D_FILE_OFFSET_BITS=64";;
esac
AC_ARG_ENABLE(experimental, [ --enable-experimental enable experimental
features],
[ext_CFLAGS="${ext_CFLAGS} -DMAQ_SHOW_EXPERIMENTAL"],
[])
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting -m64 at the right time and place.
Le Sat, Nov 15, 2008 at 12:51:48PM -0800, Russ Allbery a écrit :
> Charles Plessy <[EMAIL PROTECTED]> writes:
>
> > Would the following patch make sense?
> >
> > diff --git a/configure.ac b/configure.ac
> > index ad2f1e6..4f2993a 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -23,10 +23,7 @@ case "${host_cpu}-${host_os}" in
> > AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64"],
> > []);;
> > esac;;
> >*)
> > -AC_MSG_CHECKING([if gcc accepts -m64])
> > -CFLAGS="-m64"
> > -AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS="-m64";
> > AC_MSG_RESULT([yes])],
> > -
> > [ext_CFLAGS="-D_FILE_OFFSET_BITS=64"; AC_MSG_RESULT([no])]);;
> > +ext_CFLAGS="-D_FILE_OFFSET_BITS=64";;
> > esac
> > AC_ARG_ENABLE(experimental, [ --enable-experimental enable experimental
> > features],
> > [ext_CFLAGS="${ext_CFLAGS}
> > -DMAQ_SHOW_EXPERIMENTAL"], [])
>
> The above change is probably fine, but the ideal solution would be for
> upstream to stop trying to code this directly and instead use the Autoconf
> macro provided for this purpose. AC_SYS_LARGEFILE will add to CFLAGS
> whatever flags are needed to enable large files. (Unfortunately, since
> upstream is using ext_CFLAGS instead of CFLAGS, you may not be able to
> just delete upstream's Autoconf code and add that macro.)
Thanks again everybody for your answers. I am using the patch and have
forwarded it Upstream.
http://sourceforge.net/tracker/index.php?func=detail&aid=2298601&group_id=191815&atid=938895
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processing (#433270), no upstream tarball, other questions
Le Sun, Dec 07, 2008 at 09:49:27PM +0200, George Danchev a écrit : > > I hope that you pay extra attention to such codebases, since if they are > prone > of doing such a "software engeneering" lightly and at large, they are quite > likely to be prone of embaking on even more ingenious initiatives. Such a > package junk might impose significant loads to the seciruty and probably > release teams, and might generally slow down Debian development, so these > shouldn't be uploaded lightly IMO. Hi all, given the enormous potential of Processing, and given that the Security team is only taking care of stable release, I would not be so affraid of uploading. A preliminary pakcage could be uploaded in Experimental for instance. Of course, expect tons of bugs to solve before the package is even able to migrate to Testing. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Peer review of copyright files.
Hello everybody, Although it should never happen, sometimes a new package we submit to our archive managers is rejected because the description of the copyright status of its files is either incorrect or lacunar. This is waste of precious time for everybody. In order to ameliorate the quality of our submissions, I propose to introduce a dose of optional pre-submission peer review. One may wonder why not reviewing all QA aspects of a package? One reason is that this requires skills that are not evenly distributed, and for some aspects is simply a matter of taste. Another reason is that such kind of review is already taking place, is scaterred on many different teams, mailing lists, and social networks, and would be difficult to centralise. In contrary, all package maintainers contributing to Debian must be able to write a good copyright file, and follow the same guide: exhaustivity. I therefore think that it should be possible to centralise the effort of reviewing debian/copyright files of new packages even if it mixes people with various backgounds. I have drafted a page on the wiki that summarises the motivations and proposes a mode of operation. The key principle is peer review: the ones who review the work of others are the ones who need a review for themselves. Such a system should be self-sustainable and will not require the goodwill of persons who are not using the system themselves. http://wiki.debian.org/CopyrightReview I welcome everybody interested by the concept to help me to bootstrap the system, by writing reviews and submitting their own new packages. Would it be sucessful, the system could be extended to new upstream releases where the upstream diff is really big, via the use of RFH bugs. Have a nice day. PS: and of course, consider using the machine-readable format if you have not tried yet: http://wiki.debian.org/Proposals/CopyrightFormat PPS: If there is interest this proposal could be turned into a DEP. -- Charles Plessy Tsurumi, Kanagawa, Japan You can take your time if you want to answer: I am going to sleep -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vbetool (QA upload)
Le Wed, Dec 10, 2008 at 07:26:34PM -0600, Boyd Stephen Smith Jr. a écrit :
> On Wednesday 2008 December 10 17:07:06 Julien Lavergne wrote:
> >- Since unstable is "frozen" for Lenny, I want to let the possibility to
> >upload fixes in unstable for migration into lenny.
>
> That's not quite how I understand it. Right now testing is frozen, which
> means packages won't auto-migrate from unstable to testing unless someone
> pings the release team. Still, I'm new so I could be mistaken.
Hi,
If a fix has to be uploaded to Lenny, it can be done two ways:
- Direct upload to testing-proposed-updates.
- Upload to unstable and manual migration ("unblock" by release team).
If the package goes through unstable, it will benefit from the testing phase
before migration. For this reason, updates that are not suitable for Testing
can be uploaded to Experimental instead of Unstable during the freeze, so that
both ways of Lenny update are open.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Peer review of copyright files.
Le Fri, Dec 12, 2008 at 03:21:50PM +0100, Daniel Leidert a écrit : > > Well, licensecheck(1) exists. Maybe many packagers don't know it? Hi Daniel, I would rather think that one reason for defective debian/copyright files are the false negatives of licensecheck ;) `grep -ri copyright .' is more messy but an indispensable complement, in my opinion, and in the case nothing is found it is usually safer to try a few other keywords and to inspect some files by hand. > > PS: and of course, consider using the machine-readable format if you have > > not > > tried yet: http://wiki.debian.org/Proposals/CopyrightFormat > > Would be nice to have a licensecheck mode to compare debian/copyright to > the checked source. I was considering filing a lintian wishlist :) I have caught once in the past an upstream update that was adding a non-free MD5 implementation, but an automatic safeguard wouldn't hurt. Also, I think that my proposal can be useful as well in the case of a big update where the diff is really large. The maintainer could file a RFH and use the current procedure, giving a look to other's packges in exchange for the help with his. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: texttrainer
Le Tue, Dec 23, 2008 at 12:20:12PM +, Neil Williams a écrit : > > > Also, seeing as this is written "to use myself", why put this into > Debian anyway? Who wants yet more vanity packages in Debian? Not a good > announcement that - the package scores -100 in my estimation right > there. Hi Jacob, I see from your home page that you have some interest in neuroscience. Do you know the Debian Med project? If your "neuroLab" library is used by other free softwares, you are welcome to package it within our team. And of course you are also welcome to package other programs relevant to medecine and medical research. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpatch and .diff.gz files
Le Fri, Jan 16, 2009 at 01:01:16PM +1100, Ben Finney a écrit : > > Examine the ‘foo.diff.gz’ cat foo.diff.gz | lsdiff, for instance > Make those changes via > ‘dpatch’, instead. Note that if the changes you see are in files related to autoconf, the solution goes rather through a proper use of the clean target of debian/rules. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpatch and .diff.gz files
Le Fri, Jan 16, 2009 at 07:34:28AM +0100, Cyril Brulebois a écrit : > Charles Plessy (16/01/2009): > > > Examine the ‘foo.diff.gz’ > > > > cat foo.diff.gz | lsdiff, for instance > > I think you wanted “zcat”. Anyway, no need to waste a fork: > | lsdiff -z foo.diff.gz Nice little gem that was not in the manpage (patch submitted upstream). Thanks for the hint ! -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
