Bug#733135: ITP: python-qcli -- separated module of pyqi needed for QIIME package
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: python-qcli Version : 0.1.0 Upstream Author : Greg Caporaso * URL : https://pypi.python.org/pypi/qcli * License : BSD Programming Lang: Python Description : separated module of pyqi needed for QIIME package The qiime package needs this as new dependency which is not part of the main pyqi package. Since qiime is maintained by the Debian Med team we also care for its dependencies. The package is in SVN at svn://anonscm.debian.org/debian-med/trunk/packages/python-qcli/trunk/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131226073612.17745.64888.report...@mail.an3as.eu
Bug#733132: ITP: python-nose-exclude -- exclude specific directories from nosetests runs
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-nose-exclude Version : 0.2.0 Upstream Author : Kurt Grandis * URL : https://pypi.python.org/pypi/nose-exclude * License : LGPL Programming Lang: Python Description : exclude specific directories from nosetests runs nose-exclude is a Nose plugin that allows you to easily specify directories to be excluded from testing. The --exclude-dir= option is made available after installation of the plugin. The option may be used multiple times to exclude multiple directories from testing. The directory paths provided may be absolute or relative. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131226052918.32347.18602.report...@buzig.gplhost.com
Bug#733131: ITP: codespell -- fix common misspellings in text files
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-CC: debian-devel@lists.debian.org, Paul Tagliamonte * Package name: codespell Version : 1.6 Upstream Author : Lucas De Marchi * URL : https://github.com/lucasdemarchi/codespell/ * License : GPLv2 Programming Lang: Python Description : fix common misspellings in text files Upstream description: Fix common misspellings in text files. It's designed primarily for checking misspelled words in source code, but it can be used with other files as well. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: privacy-breach-google-adsense: how to get rid of it ?
On Thu, Dec 26, 2013 at 07:26:37AM +0800, Paul Wise wrote: > On Thu, Dec 26, 2013 at 4:57 AM, Jerome BENOIT wrote: > > > is there a proper way to get rid of the recent > > privacy-breach-google-adsense Lintian violation/error report [1] ? > > Same as with every issue in upstream code, report it to upstream and > get them to fix it, sending a patch if you are able. That way Debian > helps the free software community as a whole, which we promised to do > in our social contract: > > http://www.debian.org/social_contract I tend to agree. However, what would be doubleplusgood would be to get the tools like sphinx, doxygen, and friends to not insert the code when we're building a .deb - perhaps we should look at killing this bug in generated code by forcing the generated code to suck less. Much love, Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Thu, Dec 26, 2013 at 07:34:03AM +0800, Paul Wise wrote: > On Wed, Dec 25, 2013 at 7:32 PM, Vincent Bernat wrote: > > I have no problem with automatically updating config.guess/sub but I > > have one with automatic autoreconf: as automake doesn't seem to care > > about forward or backward-compatibility, using autoreconf will lead to > > additional work for the maintainer: backporting may be harder because > > automake is too old, FTBFS may happen from time to time because > > automake introduced an incompatible change, etc. > > I tend to think users and Debian contributors making updates to Debian > stable not being able to patch and rebuild autotools based build > systems is a serious issue. We should enable detection of this issue > by enabling dh-autoreconf in as many packages as possible. > > Building as much as possible from source at package build time should > be the norm not the exception, otherwise the build process for that > source will bitrot and we will never detect that. Yes, I couldn't agree more. Having "sources" for bits of your package's build system that can't in fact be easily patched to change its behaviour is a profoundly irritating bug that's been lying around in Debian for far too long, and it's past time we made more of an effort to fix it. (I believe that I have put my money where my mouth is and fixed all my packages in this way, including ones that were written against distinctly elderly versions of the autotools.) It is true that compatibility is sometimes less than ideal, but brushing the problem under the carpet just means that somebody gets to discover this when they're in a hurry trying to fix some unrelated problem years later, when the change in the autotools has been largely forgotten about, rather than it being fixed in a timely fashion. But this is sort of off-topic for the original report, and I apologise for derailing it ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131226000415.ga2...@riva.ucam.org
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, On 26/12/13 00:26, Paul Wise wrote: > On Thu, Dec 26, 2013 at 4:57 AM, Jerome BENOIT wrote: > >> is there a proper way to get rid of the recent >> privacy-breach-google-adsense Lintian violation/error report [1] ? > > Same as with every issue in upstream code, report it to upstream and > get them to fix it, sending a patch if you are able. Indeed, I would send a patch, hence my query. I guess I was also confused by the nature of the issue. That way Debian > helps the free software community as a whole, which we promised to do > in our social contract: > Totally agree. > http://www.debian.org/social_contract > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bb724e.5030...@rezozer.net
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Wed, Dec 25, 2013 at 7:32 PM, Vincent Bernat wrote: > I have no problem with automatically updating config.guess/sub but I > have one with automatic autoreconf: as automake doesn't seem to care > about forward or backward-compatibility, using autoreconf will lead to > additional work for the maintainer: backporting may be harder because > automake is too old, FTBFS may happen from time to time because > automake introduced an incompatible change, etc. I tend to think users and Debian contributors making updates to Debian stable not being able to patch and rebuild autotools based build systems is a serious issue. We should enable detection of this issue by enabling dh-autoreconf in as many packages as possible. Building as much as possible from source at package build time should be the norm not the exception, otherwise the build process for that source will bitrot and we will never detect that. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FBsd2uN6B7XeJFLov7xJjjrt0GeL2DsSsh=6wpsos...@mail.gmail.com
Re: privacy-breach-google-adsense: how to get rid of it ?
On Thu, Dec 26, 2013 at 4:57 AM, Jerome BENOIT wrote: > is there a proper way to get rid of the recent > privacy-breach-google-adsense Lintian violation/error report [1] ? Same as with every issue in upstream code, report it to upstream and get them to fix it, sending a patch if you are able. That way Debian helps the free software community as a whole, which we promised to do in our social contract: http://www.debian.org/social_contract -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6F3CxF5ePptF_Z0Ord3F1K84Tzn+ys=v2=qpqgjttf...@mail.gmail.com
Re: privacy-breach-google-adsense: how to get rid of it ?
Thanks for the hints and the scripts. I am on my way to update my package. On 25/12/13 22:46, Bastien ROUCARIES wrote: > On Wed, Dec 25, 2013 at 10:41 PM, Bastien ROUCARIES > wrote: >> On Wed, Dec 25, 2013 at 10:20 PM, Jerome BENOIT >> wrote: >>> Hi, >>> >>> On 25/12/13 22:04, Dominik George wrote: Hi, > is there a proper way to get rid of the recent > privacy-breach-google-adsense Lintian violation/error report [1] ? obviously, remove all Adsense and related spyware fetching code from your package. >>> >>> Obviously, but the problem is that the involved html pages correspond to >>> the manual of my package so it sounds not reasonable to wipe them out: >>> is there any tools that may help to clean up the corrupted html pages ? >> >> For imagemagick I use this. Note that your html document should be >> valid before doing this. > > Use it like this > > override_dh_auto_install-indep: > # now apply privacy cleanning rules > find $(CURDIR)/debian/tmp-indep/usr/share/doc/imagemagick-doc \ > -maxdepth 2 -type f -and -name '*.html' -and -not -empty -print0 > \ > | xargs -r -0 -n 1 debian/scripts/removeprivacybreach > >> >>> Thanks in advance, >>> Jerome >>> Cheers, Nik >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmas...@lists.debian.org >>> Archive: http://lists.debian.org/52bb4c0a.4080...@rezozer.net >>> > Best wishes, Jerome > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bb5820.4000...@rezozer.net
Re: privacy-breach-google-adsense: how to get rid of it ?
On Wed, Dec 25, 2013 at 10:41 PM, Bastien ROUCARIES wrote: > On Wed, Dec 25, 2013 at 10:20 PM, Jerome BENOIT wrote: >> Hi, >> >> On 25/12/13 22:04, Dominik George wrote: >>> Hi, >>> is there a proper way to get rid of the recent privacy-breach-google-adsense Lintian violation/error report [1] ? >>> >>> obviously, remove all Adsense and related spyware fetching code from >>> your package. >> >> Obviously, but the problem is that the involved html pages correspond to >> the manual of my package so it sounds not reasonable to wipe them out: >> is there any tools that may help to clean up the corrupted html pages ? > > For imagemagick I use this. Note that your html document should be > valid before doing this. Use it like this override_dh_auto_install-indep: # now apply privacy cleanning rules find $(CURDIR)/debian/tmp-indep/usr/share/doc/imagemagick-doc \ -maxdepth 2 -type f -and -name '*.html' -and -not -empty -print0 \ | xargs -r -0 -n 1 debian/scripts/removeprivacybreach > >> Thanks in advance, >> Jerome >> >>> >>> Cheers, >>> Nik >>> >> >> >> -- >> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: http://lists.debian.org/52bb4c0a.4080...@rezozer.net >> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAYUccgf_=cr4pqtprbhmpfrfl1znnvkqo+vjwer+hj...@mail.gmail.com
Re: privacy-breach-google-adsense: how to get rid of it ?
On Wed, Dec 25, 2013 at 10:20 PM, Jerome BENOIT wrote: > Hi, > > On 25/12/13 22:04, Dominik George wrote: >> Hi, >> >>> is there a proper way to get rid of the recent >>> privacy-breach-google-adsense Lintian violation/error report [1] ? >> >> obviously, remove all Adsense and related spyware fetching code from >> your package. > > Obviously, but the problem is that the involved html pages correspond to > the manual of my package so it sounds not reasonable to wipe them out: > is there any tools that may help to clean up the corrupted html pages ? For imagemagick I use this. Note that your html document should be valid before doing this. > Thanks in advance, > Jerome > >> >> Cheers, >> Nik >> > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/52bb4c0a.4080...@rezozer.net > removeprivacybreach Description: Binary data removeprivacybreach.xslt Description: application/xslt
Re: privacy-breach-google-adsense: how to get rid of it ?
On Wed, Dec 25, 2013 at 10:20 PM, Jerome BENOIT wrote: > Hi, > > On 25/12/13 22:04, Dominik George wrote: >> Hi, >> >>> is there a proper way to get rid of the recent >>> privacy-breach-google-adsense Lintian violation/error report [1] ? >> >> obviously, remove all Adsense and related spyware fetching code from >> your package. > > Obviously, but the problem is that the involved html pages correspond to > the manual of my package so it sounds not reasonable to wipe them out: > is there any tools that may help to clean up the corrupted html pages ? > > Thanks in advance, > Jerome You could use xslt script. It is quite easy to do. See xsltproc man page. Bastien >> >> Cheers, >> Nik >> > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/52bb4c0a.4080...@rezozer.net > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAZTGi0xYO3a2t4QArW2PDoCAu6mV+ceeAFfuPD=v2e...@mail.gmail.com
Re: GnuTLS in Debian
Russ Allbery wrote: > Has anyone asked the Git maintainers whether they object to their software > being linked with a libcurl that uses OpenSSL? I am not the author of the most of Git. As a minority author: - libcurl provides a quite similar API with OpenSSL as with GnuTLS. I wish it provided a compatible ABI. Then this question could be sidestepped (similarly to the way lesstif used to be used) - I'm glad Debian git is not built against OpenSSL, since it provides a sanity check that git works without that dependency. GnuTLS is stricter about adherance to the TLS protocol and has caught some server bugs that way. It might be worth trying a build against nss to see how it compares. - I do not want git binaries built to depend on and distributed with non-free operating system components. I do not want e.g. Microsoft to customize git to rely on some custom logic in proprietary DLLs and then distribute it with the OS. If the license that achieves that *also* makes git linked against free components like OpenSSL nondistributable in some circumstances (but still useful in other circumstances, like the Mac build where OpenSSL comes separately as part of the OS), that's an unfortunate but acceptable side effect, which I don't think it's worth chipping away at the license to get rid of. Using the GPL for git makes it easy to incorporate code from other sources (e.g., the kernel). GPL+OpenSSL exception doesn't have that property. - Git has its own blk-sha1/ implementation which is pleasantly written, portably written, and very fast. Even if there were no licensing issues involved, git for Debian would be built with BLK_SHA1=YesPlease (meaning the only relevant OpenSSL dependency is via libcurl). Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131225213613.ga15...@google.com
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, > Obviously, but the problem is that the involved html pages correspond to > the manual of my package so it sounds not reasonable to wipe them out: > is there any tools that may help to clean up the corrupted html pages ? I assume there are Adsense images included from the HTML docs in your package. So add a patch to your package (e.g. with quilt) and have it remove the Adsense stuff at build time. -nik -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, On 25/12/13 22:04, Dominik George wrote: > Hi, > >> is there a proper way to get rid of the recent >> privacy-breach-google-adsense Lintian violation/error report [1] ? > > obviously, remove all Adsense and related spyware fetching code from > your package. Obviously, but the problem is that the involved html pages correspond to the manual of my package so it sounds not reasonable to wipe them out: is there any tools that may help to clean up the corrupted html pages ? Thanks in advance, Jerome > > Cheers, > Nik > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bb4c0a.4080...@rezozer.net
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, > is there a proper way to get rid of the recent > privacy-breach-google-adsense Lintian violation/error report [1] ? obviously, remove all Adsense and related spyware fetching code from your package. Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
privacy-breach-google-adsense: how to get rid of it ?
Hello List, is there a proper way to get rid of the recent privacy-breach-google-adsense Lintian violation/error report [1] ? Thnaks inadvance, Jerome [1] http://lintian.debian.org/tags/privacy-breach-google-adsense.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bb46be.2060...@rezozer.net
Re: Bug#732878: Add MariaDB as an alternative dependency
❦ 25 décembre 2013 12:41 CET, Clint Byrum :
>> > Don't you think it would be more reasonable if the mariadb-client
>> > contained a Provides: mysql-client, rather than changing each and every
>> > software dependency in Debian?
>>
>> Maybe MariaDB wants to be the "default" MySQL implementation?
>
> MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
> that you suggest why you think there should be a default, and why you
> think that "MySQL" should not be the default "MySQL".
I am saying this because the bug reports about adding support for
MariaDB were asking for mariadb-client | mysql-client and not
mysql-client | mariadb-client. My question is genuine, I really don't
know. Do we plan to transition away from MySQL to MariaDB?
--
prom_printf("Detected PenguinPages, getting out of here.\n");
2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c
signature.asc
Description: PGP signature
Re: GnuTLS in Debian
On Mon, 23 Dec 2013 23:36:34 -0800, Steve Langasek wrote: >> I, too, believe that we could use the reality check. We already did so >> with our patent policy and solved long-standing problems for our users. > > Well, I'm not sure what problems that patent policy actually solved for > our users. As far as I can see, our current patent policy was simply a > codification of existing practice. The users of faac, lame and the non-crippled ffmpeg/libav would beg to disagree. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l9f2pm$m5n$1...@ger.gmane.org
Re: Bug#732878: Add MariaDB as an alternative dependency
On Wed, 2013-12-25 at 03:41 -0800, Clint Byrum wrote: > Excerpts from Vincent Bernat's message of 2013-12-25 03:36:30 -0800: > > ❦ 25 décembre 2013 08:27 CET, Thomas Goirand : > > > > > Don't you think it would be more reasonable if the mariadb-client > > > contained a Provides: mysql-client, rather than changing each and every > > > software dependency in Debian? > > > > Maybe MariaDB wants to be the "default" MySQL implementation? > > MariaDB is not MySQL, so this is not really what you mean. Also I'd ask > that you suggest why you think there should be a default, and why you > think that "MySQL" should not be the default "MySQL". Similarly, wodim is not cdrecord LibreOffice is not OpenOffice.org Iceweasel is not Firefox etc. so clearly we should never have implemented an automatic transition from one to the other... Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Bug#732878: Add MariaDB as an alternative dependency
Excerpts from Vincent Bernat's message of 2013-12-25 03:36:30 -0800: > ❦ 25 décembre 2013 08:27 CET, Thomas Goirand : > > > Don't you think it would be more reasonable if the mariadb-client > > contained a Provides: mysql-client, rather than changing each and every > > software dependency in Debian? > > Maybe MariaDB wants to be the "default" MySQL implementation? MariaDB is not MySQL, so this is not really what you mean. Also I'd ask that you suggest why you think there should be a default, and why you think that "MySQL" should not be the default "MySQL". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387971582-sup-5479@clint-HP
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 12/25/2013 05:50 PM, John Paul Adrian Glaubitz wrote: > On 12/25/2013 08:46 AM, Thomas Goirand wrote: >>> And overriding the *entire* service file seems excessive if you wish to >>> override just one line of the package's service file. >> >> And also, systemd would be the only package behaving this way, which is >> counter-intuitive for our users. I'd even go up to say this isn't policy >> compliant (as configuration files must be in /etc). > > Thomas, we have agreed to no longer discuss this topic anymore until the > technical committee has made a decision, haven't we? Ok. > Cheers and Happy Holidays! To you as well! Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bac69f.7020...@debian.org
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
❦ 25 décembre 2013 12:32 CET, Vincent Bernat : > If we get automatic config.guess/sub handling by dh, maybe we could just > libtool-generated files as well? ... we could just "patch" libtool-generated files ... -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Bug#732878: Add MariaDB as an alternative dependency
❦ 25 décembre 2013 08:27 CET, Thomas Goirand : > Don't you think it would be more reasonable if the mariadb-client > contained a Provides: mysql-client, rather than changing each and every > software dependency in Debian? Maybe MariaDB wants to be the "default" MySQL implementation? -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
❦ 24 décembre 2013 18:33 CET, Colin Watson : > Mostly the patches I've sent for these things have either been ignored > until NMUed, or applied without complaint, but I've found that I've > ended up in arguments with a small number of maintainers who have (IMO) > irrational objections to updating config.guess/sub automatically, > generally based on either confusing it with autoreconf and incorrectly > believing that it has similar levels of breakage, or hanging onto a > more-than-15-year-old grudge about GNU config triplet changes in the > dawn of time. I'd be happy to take this to the TC if necessary, but > it's relatively minor and I figure we have enough to do. :-) [...] I don't remember you advocating for automatically update config.guess/sub. However, I remember you for advocating automatic autoreconf. Having both positions make it easier for people (like me) to be confused about them. > Yes, although note that the upcoming ppc64el port will require a full > autoreconf for anything that uses libtool, because it requires a libtool > patch that hasn't yet been part of a stable libtool release and is > generally very poorly deployed in the generated autotools files shipped > in upstream packages. I've been sending rather a lot of patches to > convert things to dh-autoreconf over the last couple of weeks. It is, > IMO, clearly the better path (both for long-term porting needs and in > the ethical sense that it makes it easier for users to change the true > source code for the build system), but it does require a bit more > knowledge and effort from maintainers. I have no problem with automatically updating config.guess/sub but I have one with automatic autoreconf: as automake doesn't seem to care about forward or backward-compatibility, using autoreconf will lead to additional work for the maintainer: backporting may be harder because automake is too old, FTBFS may happen from time to time because automake introduced an incompatible change, etc. If we get automatic config.guess/sub handling by dh, maybe we could just libtool-generated files as well? -- Make sure all variables are initialised before use. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#733089: ITP: gitprep -- Git repository management application
Package: wnpp Severity: wishlist Owner: Piotr Roszatycki * Package name: gitprep Version : 1.4 Upstream Author : Yuki Kimoto * URL : http://gitprep.org/ * License : Artistic or GPL+2 Programming Lang: Perl Description : Git repository management application GitPrep allows to manage Git repositories by simple web interface and can create users and repositories without limitation. It supports: * Smart HTTP with Basic HTTP Authentication * Markdown syntax and README.md * Git submodule repositories * Private repository and collaboration features GitPrep brings own built-in webserver with reverse proxy support. It can be also run as CGI application. It supports HTTPS. This package requires some more Perl libraries which will be packaged separately (ie. Object::Simple). It also uses modified version of Mojolicious which should be replaced by original version of this library. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131225112354.32329.98724.reportbug@sony-vaio-sve1112m1ep
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 12/25/2013 08:46 AM, Thomas Goirand wrote: >> And overriding the *entire* service file seems excessive if you wish to >> override just one line of the package's service file. > > And also, systemd would be the only package behaving this way, which is > counter-intuitive for our users. I'd even go up to say this isn't policy > compliant (as configuration files must be in /etc). Thomas, we have agreed to no longer discuss this topic anymore until the technical committee has made a decision, haven't we? And, as for your statement, it's incorrect. systemd (and udevd) have always shipped their "factory" unit files in /usr or /lib and everything that you customize is read from /etc/systemd and /etc/udevd, respectively and has precedence over the shipped unit or rules files. This is a common practice used by many packages, So there is nothing violating the policy and the information you had was simply incorrect. In any case, please let's stop here and let the committee do their work. We've had enough discussion already. Cheers and Happy Holidays! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52baaa79.20...@physik.fu-berlin.de
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On 24 December 2013 20:10, Andrey Rahmatullin wrote: > On Tue, Dec 24, 2013 at 05:33:56PM +, Colin Watson wrote: >> Generally agreed, although I believe you have to be somewhat careful >> when using it in combination with dh-autoreconf > dh-autoreconf(7) says "you do not need --with=autotools_dev if you use > --with=autoreconf" > See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698765 When a package uses autoconf/AC_CANONICAL_* but not libtool/automake dh-autoreconf does not update config.guess/config.sub. One example is given on the bug report, I have another one - x264. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjbqTHcpoMM6qj4u5ttu32-mJofhS=+9Kz4OoF=b5j...@mail.gmail.com
