Bug#671524: Dropping coverage patch in Samtools ?
On Wed, Nov 26, 2014 at 3:49 AM, Charles Plessy ple...@debian.org wrote: in recent versions of samtools, the mpileup command has a new option to specify the coverage at run time. Would it be fine to drop our patch that was raising the default coverage cap from 8,000 to 1,000,000 ? If yes, do you think we need to mention it as a NEWS entry ? Le Wed, Nov 26, 2014 at 02:27:22PM -0500, Dominique Belhachemi a écrit : I think we still need the patch. samtools depth doesn't support the -d flag. Hi Dominique, in my latest upload, I delete the patches by mistake. But on the other hand, I see that you solved the issue upstream in the meantime. https://github.com/samtools/samtools/pull/375 Unless we need a new upload before version 1.3, shall we just wait ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659070: bad internal links on www.debian.org for developers-reference
Le Fri, Jun 12, 2015 at 10:19:40PM +0900, Osamu Aoki a écrit : PS: Charles, you are the only committer to the cron script except me. I hope you do not mind making some refactoring of code around ssh://git.debian.org/git/debwww/cron.git parts/7doc Hi Osamu, no problem, it would take as much time for me to remember how the script works than to learn it again from scratch. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788283: jessie-pu: package r-cran-rcurl/1.95-4.3-1+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Dear Stable release team, the r-cran-rcurl package provides curl functionalities for the R statistical environment. In Jessie (version 1.95-4.3-1), we built it against libcurl4-nss-dev, but this creates errors that prevent R users to download and install other R packages from GitHub (https://bugs.debian.org/786473). I wouldn't be surprised if there would be other problems not yet reported. In Unstable and Testing, we solved this in version 1.95-4.3-2 by building the package against libcurl4-openssl-dev. In the following proposed update (1.95-4.3-1+deb8u1), we do the same, but the package was built against Jessie. diff -Nru r-cran-rcurl-1.95-4.3/debian/changelog r-cran-rcurl-1.95-4.3/debian/changelog --- r-cran-rcurl-1.95-4.3/debian/changelog 2014-09-17 20:10:59.0 +0900 +++ r-cran-rcurl-1.95-4.3/debian/changelog 2015-06-09 21:54:48.0 +0900 @@ -1,3 +1,10 @@ +r-cran-rcurl (1.95-4.3-1+deb8u1) jessie; urgency=medium + + * Team upload. + * Build-Depend on libcurl4-openssl-dev only (Closes: #786473). + + -- Charles Plessy ple...@debian.org Tue, 09 Jun 2015 21:54:38 +0900 + r-cran-rcurl (1.95-4.3-1) unstable; urgency=medium * New upstream version diff -Nru r-cran-rcurl-1.95-4.3/debian/control r-cran-rcurl-1.95-4.3/debian/control --- r-cran-rcurl-1.95-4.3/debian/control2014-09-17 19:36:29.0 +0900 +++ r-cran-rcurl-1.95-4.3/debian/control2015-05-31 09:15:18.0 +0900 @@ -9,7 +9,7 @@ cdbs, r-base-dev, r-cran-bitops, - libcurl4-nss-dev | libcurl-dev + libcurl4-openssl-dev Standards-Version: 3.9.5 Vcs-Browser: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/r-cran-rcurl/trunk/ Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-rcurl/trunk/ Have a nice day, Charles -- Charles Plessy Debian Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.
Package: debian-policy Severity: normal Le Thu, Jun 04, 2015 at 07:09:00PM -0700, Russ Allbery a écrit : I have not looked at this at all, but this list should be aware that it exists. Date: Wed, 03 Jun 2015 09:19:04 -0400 Subject: [fhs-discuss] FHS 3.0 The LSB workgroup is happy to announce the release of FHS 3.0. ... Release notes can be found here: https://wiki.linuxfoundation.org/en/FHSReleaseNotes30 Thanks Russ for the heads-up. Judging from the release notes, it would not be too hard to update the Policy's description of how Debian follows and deviates from the FHS. By the way, I wonder if the debian-policy package is the best place for shipping a copy of the FHS. I just checked out the bzr repository that contains its sources, and it builds out of the box (build-depends on xmlto and fop). Perhaps it would deserve its own package ? Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787571: How about transferring /etc/mime.types from mime-support to base-files.
Package: base-files Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Dear Santiago, the mime-support package that I maintain can be thought of two compontents: - the /etc/mime.types file, that is parsed directly by some indepentent packages such as apache2, and - the mailcap system, with its executables, its configuration files, its dpkg triggers, etc... I am currently planning to separate these components and one possibility would be to have a single package for /etc/mime.types, that would track the one in Fedora's Git repository. I detailed this in https://bugs.debian.org/786889. Alternatively, we could ship this file in base-files, since it is among these traditional Unix files that one always expects to be available. But it has frequent updates, to it may be extra work for you. What do you think about this ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787459: mime-support: Please document ~/.mailcap-order
Control: tag -1 pending Users can override the order with ~/.mailcap-order, just like system-wide overrides with /etc/mailcap.order. Unfortunately this is not documented in mailcap.order(5), or anywhere else that I can see. (I had to look at the source to find out!) I was just about to file a bug report asking for this functionality when I found it…so please can it be documented, since it already exists? Hi Thomas, thanks for your suggestion. I made a brief addition to the manpage of update-mime, see below. http://anonscm.debian.org/cgit/collab-maint/mime-support.git/commit/?id=4cd9ea47eca1ddbca3f517935669faa96480aeec Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787285: File RegExp.pas, documented in debian/copyright is not in the package anymore.
Package: cqrlog Severity: wishlist Hi, debian/copyright gives the license of RegExp.pas, and this license has some borderline terms, but fortunately the file is not in the package anymore. Maybe you can remove this part from debian/copyright ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680109: Missing note that e-mails to debian-...@lists.debian.org are published
Le Wed, May 27, 2015 at 10:20:54AM +0200, Laura Arjona Reina a écrit : I used the note that is already published in https://www.debian.org/contact Actually, I do not see the note on https://www.debian.org/contact... (Assuming that what you mean by the note is To report a problem with the web site, e-mail debian-...@lists.debian.org. For other contact information, see the Debian contact page. Web site source code is available.) Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680109: Advice on bug #680109 (proposal would break translations of the website footer)
Le Wed, May 27, 2015 at 11:34:41AM +0200, Laura Arjona Reina a écrit : I'm attaching a new patch, that would change that to: To report a problem with the web site, and other contact information, see the Debian contact page. Note that this would break translations as the former one, so i18n advice about how to handle that is still welcome :) In contact page ( https://www.debian.org/contact ), we already have (among other info): * Please note that most of the e-mail addresses below represent open mailing lists with public archives. Read the disclaimer before sending any messages. Hi again, I also like the idea to remove the mailto link to debian-www@l.d.o from the footer, so that only the link to the contact page remains. However, the disclaimer above, that most (...) adresses (...) represent open mailing lists is not accurate. Here is the list of the adresses on the contact page. - debian-proj...@lists.debian.org- public archived list -debian-u...@lists.debian.org- public archived list -debian-b...@lists.debian.org- public archived list -mirr...@debian.org - not a list - package name@packages.debian.org - depends - secur...@debian.org - not a list, information discreet - debian-de...@lists.debian.org- public archived list - debian-...@lists.debian.org- public archived list - ad...@db.debian.org - not a list. Obsolete ? (not listed on https://wiki.debian.org/Teams/DSA) - listmas...@lists.debian.org- not a list (not sure about confidentiality) - ow...@bugs.debian.org - not a list (not confidential ?) - antiharassm...@debian.org - not a list (confidential ?) With 5 or 6 out of 12, I would not say that open mailing lists are most of the addresses. So I think that the best would be to have the disclaimer to say that addresses may be a public list, and for each address listed on the page, be explicit on publicity and confidentiality. I can prepare a patch unless Laura or somebody else is up for (I am a bit short of time). Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680109: Missing note that e-mails to debian-...@lists.debian.org are published
Le Tue, Apr 28, 2015 at 10:26:42PM +0200, Laura Arjona Reina a écrit : Since all the pages show a footer with mailto:debian-...@lists.debian.org, I think it would be nice to add the disclaimer to the footer. … Index: footer.wml === RCS file: /cvs/webwml/webwml/english/template/debian/footer.wml,v retrieving revision 1.128 diff -u -r1.128 footer.wml --- footer.wml9 May 2014 14:14:07 - 1.128 +++ footer.wml28 Apr 2015 20:24:36 - @@ -94,7 +94,16 @@ # you can add some information of your own translation mailing list # (i.e. debian-l10n-xxx...@lists.debian.org) for reporting things in # your language. - gettextTo report a problem with the web site, e-mail a href=mailto:debian-...@lists.debian.org;debian-...@lists.debian.org/a. For other contact information, see the Debian a href=m4_HOME/contactcontact page/a. Web site source code is a href=m4_HOME/devel/website/using_cvsavailable/a./gettext + gettextTo report a problem with the web site, e-mail a href=mailto:debian-...@lists.debian.org;debian-...@lists.debian.org/a. For other contact information, see the Debian a href=m4_HOME/contactcontact page/a. + /gettext +/define-tag +define-tag publicmailinglists whitespace=delete +gettextPlease note that most of the e-mail addresses represent open mailing lists with public archives. +Read the a href=$(HOME)/MailingLists/disclaimer\ +disclaimer/a before sending any messages./gettext +/define-tag +define-tag sourcecode whitespace=delete +gettextWeb site source code is a href=m4_HOME/devel/website/using_cvsavailable/a./gettext /define-tag define-tag lastmodified whitespace=delete gettextLast Modified/gettext Hi Laura, on behalf of everybody who sent a public message without knowing, thank you for your work on this ! I think that the people who contact us need a clear indication that the contact address is a public mailing list. In that sense, why not simplifying your patch and simply have the disclaimer everywhere by adding “Please note that this contact address and many other on this website are open mailing lists with public archives.” between the first and second sentences ? Or even simpler: “To report a problem with the web site, e-mail our publically archived mailing list debian-...@lists.debian.org.” Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150527065539.gm4...@falafel.plessy.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786889: ITP: media-types -- List of media types associated to file suffixes
Package: wnpp Severity: wishlist Owner: Charles Plessy ple...@debian.org Package name: media-types Version : 2.1.44 Upstream Author : Mostly Ville Skyttä ville.sky...@iki.fi, for Fedora URL : https://git.fedorahosted.org/cgit/mailcap.git/tree/mime.types License : Public domain Programming Lang: Just a text file Description : List of media types associated to file suffixes The IANA [Internet Assigned Numbers Authority] maintains a list of media types (see [RFC 6838]) and their detailed descriptions that indicate which file name suffixes, if any, are used to signal that a given file is of the given type. On Unix systems, the file `/etc/mime.types` summarises this information in a plain text tabular format (media types were formerly called MIME types). . The IANA does not provide directly a `mime.types`f ile. To keep it up to date, one has to regularly monitor changes on the IANA website. This is done very well by the maintainer of Fedora's `mailcap` package. This Debian package provides Fedora's `/etc/mime.types` in Debian systems. . [Internet Assigned Numbers Authority]: https://www.iana.org/assignments/media-types [RFC 6838]: https://tools.ietf.org/html/rfc4855 Further comments: Currently, /etc/mime.types is provided by the mime-support package, which I maintain. This package also provides Debian's implementation of the Mailcap system (https://tools.ietf.org/html/rfc1524). However, the /etc/mime.types files is consumed by other systems, like Apache, and not all computers need to have the Mailcap system installed. Moreover, maintaing the /etc/mime.types is time-consuming (see above), so I plan to track Fedora's file. Since it lives in a Git repository it is tempting to base a Debian source package on it, but this Debian package would only distribute a single file. Alternatively, /etc/mime.types could be moved to a different package, for instance base-files, but this would increase the work load of the package maintainer. Your comments are welcome. Please CC this ITP as I am not subscribed to debian-devel. Cheers, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786473: [Debian-med-packaging] Bug#786473: r-cran-rcurl: Linking to the NSS library causes failures.
Hi Andreas, Le Fri, May 22, 2015 at 07:29:20AM +0200, Andreas Tille a écrit : Good catch. Well, actually it is me who was caught :) On Fri, May 22, 2015 at 11:29:12AM +0900, Charles Plessy wrote: The solution to these failures is to link to libcurl3 instead (by build-depending on libcurl4-openssl-dev). Would that cause forseable problems ? If not, I would be tempted to call the bug serious and ask for a stable update. I personally can't see any problem. What would you think about this ? Just tell us whether you volunteer to do this or if you want somebody else (=me) caring for it. Hi Andreas, I will do it if there are no further objections. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786473: r-cran-rcurl: Linking to the NSS library causes failures.
Package: r-cran-rcurl Version: 1.95-4.3-1 Severity: important Hi all, we distribure RCurl linked to libcurl3-nss, but this causes failures with the 'devtools' R package: - https://github.com/hadley/devtools/issues/650 - https://github.com/hadley/devtools/issues/467 - http://stackoverflow.com/questions/23287685/devtoolsinstall-github-error-in-function-type-msg-aserror-true-not-se The solution to these failures is to link to libcurl3 instead (by build-depending on libcurl4-openssl-dev). Would that cause forseable problems ? If not, I would be tempted to call the bug serious and ask for a stable update. What would you think about this ? Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field
Control: tags -1 - patch (the patch tag has a special meaning in the bugs on debian-policy, to indicate that consensus has been reached and discussion is over). Le Fri, May 22, 2015 at 10:07:45AM +1000, Ben Finney a écrit : Package: debian-policy Severity: wishlist Control: tags -1 + patch As discussed in the ‘debian-devel’ thread in 2015-05 URL:https://lists.debian.org/msgid-search/85lhgjzqy3@benfinney.id.au, there is value in recording the explicit text from the copyright holder that *grants* a license to the recipient. The attached patch updates the ‘copyright-format’ specification to describe a “License-Grant” field, and clarifies the other fields in relation to this. Hi Ben, I just read through the thread on debian-devel; I think that the Lintian warning dep5-copyright-license-name-not-unique is wrong. As you can see on lintian.debian.org, it is issued for more than a thousand packages. At this point one needs to consider if the current practice should be adatped to Lintian or if Lintian should be adapted to the current practice. The current practice is that in cases like the following one, the stand-alone license paragraph is the one that defines the license text. -- Files: * License: foo You must follow the foo license. License: foo Do whatever foo you want. -- In my opinon, clarifying the standard would be better than changing one thousand packages. Experiments on new fields are welcome, and it is good to open bugs to track them. But I think that we should first see how the proposed field gets traction before adding it to the specification. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781518: Please remove very outdated MakeHuman package
Le Mon, May 11, 2015 at 07:22:02PM +0200, Muammar El Khatib a écrit : I have finished to package the new makehuman's upstream version. I am now in the phase of checking copyrights and cleaning lintian warnings. Thanks ! -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630174: debian-policy: forbid installation into /lib64
Le Mon, May 11, 2015 at 11:30:54AM +0200, Bill Allombert a écrit : We should document that to prevent /lib64 to be used for wrong purpose. In any case I'm not quite sure whether shipping files in lib64 in amd64 packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK. I only found zynaddsubfx-dssi: /usr/lib64/dssi/libzynaddsubfx_dssi.so which I think is a RC bug. But note that this bug is about /lib64, not /usr/lib64 Hi Bill, while the title is only about /lib64, the main text of the original message in for this bug is about /lib64 and /usr/lib64. How about the following. Packages must not install files in file/lib64/file and file/usr/lib64/file. The ttlibc6/tt package is exempted from this restriction. I think that we are practical enough that, if we need another core package to ship files in these directories for a very good reason, this can happen before a revised version of the Policy is released. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621050: Document dependencies needed to use multiarch paths
Jonathan Nieder jrnie...@gmail.com writes: diff --git a/policy.sgml b/policy.sgml index 4aeae363..0ca925e0 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6214,6 +6214,14 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ /footnote /p p + Packages installing libraries to + file/usr/lib/vartriplet/var/file must declare a + ttPre-Depends/tt relationship against + packagemultiarch-support/package to ensure the + libraries are visible to prgnld.so/prgn during + partial upgrades from Debian 6.0 (squeeze) and earlier. +/p +p Applications may also use a single subdirectory under file/usr/lib/vartriplet/var/file. /p Le Fri, May 08, 2015 at 06:40:08PM +0200, Bill Allombert a écrit : Is it still relevant know that squeeze has been released ? Hi Bill and everybody, Actually, the whole patch can be dropped now and the bug closed, because the pre-depends relationship is not needed anymore. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783195: Exits 0 even if the handler cannot be executed
Le Thu, Apr 23, 2015 at 08:00:08PM +0200, martin f krafft a écrit :
% pdfmod
zsh: command not found: pdfmod
% run-mailcap --debug --action=edit /tmp/3290_001.pdf
(...)
- running test: test -n $DISPLAY (result=0=true)
- executing: pdfmod /tmp/3290_001.pdf
% echo $?
0
Thanks Martin for the report.
Here are the Perl commands defining the returned error code.
--
print STDERR - executing: $comm\n if $debug;
if ($norun) {
print $comm,\n;
$res = 0;
} else {
$res = system $comm;
$res = int($res/256);
}
if ($res != 0) {
print STDERR Warning: program returned non-zero exit code
\#$res\n;
$retcode = $res;
}
(...)
exit($retcode);
--
I do not understand why the original command's error code (127 in our case) is
turned to zero by changing it to int($res/256). I could remove this, but
before doing so, I would prefer to understand why it is done like this. Do you
have an idea ? If not, I will ask to the original author.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769818: Bug#766118: lintian: False positive for “missing-license-paragraph-in-dep5-copyright”
Hi David, Martin, and everybody, regarding the tag missing-license-paragraph-in-dep5-copyright, I think, like Martin, that it should not be triggered by multi-line License fields in the header paragraph. The specification states: If there are no remaining lines, then all of the short names or short names followed by license exceptions making up the first line must be described in stand-alone License paragraphs. Conversely, if the License field has multiple lines, then there is no need for a stand-alone license paragraph. The fact that License fields in header paragraphs are used for a different purpose than License fields in Files paragraphs does not change that point. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781518: Please remove very outdated MakeHuman package
Dear Muammar, there is a report that your makehuman package is broken and outdated, see below. Accordingly, the package is already removed from our Testing distribution and will not be part of our next Stable release. Still, its presence in Unstable can still mislead users. The upstream maintainers propose to remove the package from Debian. Would you agree to that ? Have a nice day, -- Charles Le Mon, Mar 30, 2015 at 01:31:19PM +0200, Joel Palmius a écrit : Package: qa.debian.org The version of MakeHuman currently included in the repo is a four year old alpha. As per bug report (#781306) it does not even seem to start. At this point it seems unlikely that an acceptable, less ancient, version could be included in Debian. Thus, we in the MakeHuman crew humbly requests that the currently available package at least be removed. It reflects poorly upon both Debian and MakeHuman that the current package is still around. We have filed a request (#751755) for a version bump, where we also offered to help in whatever way we could, but have so far not got a response. As per https://wiki.debian.org/qa.debian.org/removal: 1. - (we don't know how many, or if anyone, is using the debian version) 2. The version in the repo is an alpha. A stable version has been around for some time 3. There is a functional deb available on our home page. However, this might need to be adapted to fit debian guidelines 4 6. As far as we can see, the maintainer hasn't touched the package, nor commented on bug reports for quite some time 5. - (upstream is very active) 7. No stable release was ever in debian, but a stable release is available. -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55193407.3000...@contuitus.com -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781518: Please remove very outdated MakeHuman package
Le Mon, Mar 30, 2015 at 01:31:19PM +0200, Joel Palmius a écrit : The version of MakeHuman currently included in the repo is a four year old alpha. As per bug report (#781306) it does not even seem to start. At this point it seems unlikely that an acceptable, less ancient, version could be included in Debian. Thus, we in the MakeHuman crew humbly requests that the currently available package at least be removed. It reflects poorly upon both Debian and MakeHuman that the current package is still around. Dear Joel, thank you for contacting us. I am sorry that we are causing trouble to your project with our outdated package. The bug report #781306 caused the package to be removed from our Testing distribution, therefore it will not be part of our next Stable release. This partially solves the problem, but as of today the package is still distributed in our Unstable distribtion and while this distribution is not directed at general users, I understand that you would like it to be removed as well. As you have seen, I have contacted the package maintainer, and I propose to wait 15 days and transfer the request for removal to our FTP archive team in the absence of a response, which will result in the final removal of the package. Is that good for you ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781654: copyright-format: IBM CPL - CPL in license short names table
user debian-pol...@packages.debian.org usertags 781654 + informative proposal thanks in the short name license tables, shipped as part of the machine readable copyright format specification and available online at https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name the long name of the Common Public License (CPL) is incorrect. It currently reads IBM Common Public License, but it should simply be Common Public License, without leading IBM. This is confirmed by both http://spdx.org/licenses/CPL-1.0 (which the table entry points to) and http://opensource.org/licenses/cpl1.0.php Hi Stefano, this is correct. Since the long names from the license table are not formally used in the specification, I think that the issue is non-normative and can be corrected without changing the revision number in the Format string of the Copyright files. I am wondering if it would be better to mark the corrected version of the specification as 1.0.1 in the text, but keep distributing the files as 1.0, or to just correct the version 1.0 without incrementing any revision number anywyere. What do other people think about this ? (Many thanks to Mike Milinkovich for spotting this.) Thanks indeed, and have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Requesting input on TC deliberations about menu system and policy
[I think that what follows is entirely redundant with what I wrote earlier.] Le Mon, Mar 30, 2015 at 08:32:58PM -0400, Sam Hartman a écrit : Steve claimed that the policy process is not a rough consensus process and that the fact that Bill objected in-and-of-itself might be sufficient to argue that there was not consensus. The process.txt document dated Spetember 14, 2014 does not support Steve's claim. I have not read previous versions of that document, and I don't know which version of the process the TC should look at here. Hi Sam, thanks for your efforts in resolving this conflict. After one year of discussion and negociation, following the policy change process, a consensus was found, with nobody standing up against it. A couple of weeks later, Bill abused his commit privileges and reverted the change. I think that this is clearly unacceptable, and I hope that the change on which everybody worked on and agreed will be restored without further discussion. If the TC insits on discussing, then the next question is what to discuss. And then you will realise that Bill's objections are still not clear as of today. Since Bill makes no effort to discuss, I think that the discussion should stop with the rejection of his objections. In the end, what is at a stake here is not the menu systems. The Debian menu system is not a default anymore, and after the release we will see its installation rate erode, and its usage to continue to fade away. Blocking the policy change has no effect, because already a large number of package maintainers disregard that in theory, it is a must to have a menu entry for every interactive program in Debian. So what is at a stake here, is whether the Policy reflects the current consensual and unchallenged practice, or whether it is lagging on real facts by a couple for years or more. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780637: cloud-init: needs to be build in the cloud
Le Tue, Mar 17, 2015 at 10:15:38AM +0100, Holger Levsen a écrit : building the cloud-init package fails during package tests because the hostname metadata.google.internal cannot be resolved and cloud specific URLs like http://169.254.169.254/openstack/latest cannot be accessed, see attached log. Hi Holger, it is more complicated than this: the package builds fine with sbuild. To what extent do we need to support pbuilder ? Please adjust the severity according to your answer if necessary. Have a nice day -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780637: cloud-init: needs to be build in the cloud
On Dienstag, 17. März 2015, Charles Plessy wrote: it is more complicated than this: the package builds fine with sbuild. Le Tue, Mar 17, 2015 at 12:00:20PM +0100, Holger Levsen a écrit : does it run the tests with sbuild too? (I assume not.) It runs the tests but skips some... which makes me think that the problem is not necessarly with pbuilder, but rather with the build machine. For instance, in your case, it is virtualised ? ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) override_dh_auto_test: dh_auto_test $(MAKE) test endif So when nocheck is defined in DEB_BUILD_OPTIONS it should run make test??? This is just Makefile syntax horror in all its splendor. if nocheck is not defined, then the result of findstring is empty, which is equal to the emptiness between ( and , after ifeq. It took me years to understand :) Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779676: dep5-copyright-license-name-not-unique check is too strict or too severe.
On Tue, Mar 3, 2015 at 11:13 PM, Charles Plessy ple...@debian.org wrote: I think that the dep5-copyright-license-name-not-unique tag should either: - reduce its severity, as just an advice for readability, or - only be issued when the same short name is used with a different description. Le Fri, Mar 06, 2015 at 11:19:38PM +0100, Bastien ROUCARIES a écrit : Could you pin point the exact verse of the specification ? Hi Bastien: Stand-alone License paragraphs can be used to provide the full license text for a given license once, instead of repeating it in each Files paragraph that refers to it. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph Since it is can and not must, Lintian is too severe. Have a nice week-end, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779676: dep5-copyright-license-name-not-unique check is too strict or too severe.
Package: lintian Version: 2.5.30+deb8u3 Severity: normal Dear Lintian maintainers, thank you for your support of the machine-readable copyright format. Regarding the tag dep5-copyright-license-name-not-unique, I think that it is either too strict or too severe. The specification does not require the use of stand-alone License paragraphs when the same license short name is used in multiple Files paragraphs. Hence it is only an error if two Files paragraphs use the same short name for a License, but with a different description. I think that the dep5-copyright-license-name-not-unique tag should either: - reduce its severity, as just an advice for readability, or - only be issued when the same short name is used with a different description. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Sun, Feb 08, 2015 at 09:52:49AM +0100, Matthias Urlichs a écrit : Charles Plessy: Later, I might propose on debian-devel and debian-dpkg to forbid empty fields in the whole specification (which means, since we are not using empty fields, to guarantee that valid files do not and will not contain empty fields). (For the avoidance of doubt, by empty I mean: nothing or whitespace only after the colon.) Why? Because of variable substitution when processing the source control file, we need to do empty-entry removal there anyway, so any external substitution mechanism (e.g. producing d/control from d/control.in) would have to repeat that algorithm. Unnecessarily. Today, any such substitution can be pretty dumb, e.g. a shell loop or a couple of s/@VAR@/value/g regexps, and I'd like to be able to keep doing that. Hi Matthias, just to clarify: I think that the specification of the format of the Debian control files in paragraph format only applies to final files, not to transient representations during processing of these files, nor to templates such as debian/control.in. Actually, the Debian source package control file (debian/control) itself is already very much like a template, and the exceptions that we have for it are to some extent a description of the de facto templating system used by dpkg. Perhaps it might be interesting to refactor the Policy's chapter 5 under this perspective... Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Fri, Feb 06, 2015 at 12:04:05AM +0100, Bill Allombert a écrit : Thus I would like to restrict this bug to what is agreed, i.e. binary package control files. This also side-step nicely the definition of empty. Hi Bill and everybody, if we all agree that empty fields are not allowed in binary package control files, and that it is not needed to define what empty means, then let's go for it. Later, I might propose on debian-devel and debian-dpkg to forbid empty fields in the whole specification (which means, since we are not using empty fields, to guarantee that valid files do not and will not contain empty fields). Anybody is welcome to do so before me. My goal is to have the format of Debian control files in the paragrap format a little bit less ad-hoc than now, where a lot of things have to be individually specified for each use of this format. (For the avoidance of doubt, by empty I mean: nothing or whitespace only after the colon.) Have a nice week-end, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776939: mime-support: please make the build reproducible
Control: tag -1 pending Le Tue, Feb 03, 2015 at 12:37:21PM +, Chris Lamb a écrit : While working on the reproducible builds effort [1], we have noticed that mime-support could not be built reproducibly. Hi Chris, this is actually fixed already in the package's VCS thanks to the new Lintian warning, but not uploaded yet because of the Freeze. Thanks anyway for your work on this issue. It is both important and exciting development. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777090: unblock: bowtie/1.1.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package bowtie, that was missing its core programs in /usr/bin. unblock bowtie/1.1.1-2 Here is the full debdiff. diff -Nru bowtie-1.1.1/debian/bowtie.install bowtie-1.1.1/debian/bowtie.install --- bowtie-1.1.1/debian/bowtie.install 2014-09-03 19:03:28.0 +0900 +++ bowtie-1.1.1/debian/bowtie.install 2015-02-03 10:41:26.0 +0900 @@ -1,5 +1,5 @@ bowtie usr/bin -bowtie-build usr/bin -bowtie-inspect usr/bin -bowtie*-debug usr/bin +bowtie-align* usr/bin +bowtie-build* usr/bin +bowtie-inspect* usr/bin debian/tests/[er]* usr/share/doc/bowtie/tests diff -Nru bowtie-1.1.1/debian/changelog bowtie-1.1.1/debian/changelog --- bowtie-1.1.1/debian/changelog 2014-10-07 00:01:31.0 +0900 +++ bowtie-1.1.1/debian/changelog 2015-02-03 10:45:22.0 +0900 @@ -1,3 +1,10 @@ +bowtie (1.1.1-2) unstable; urgency=high + + * Team upload. + * Install missing commands. Closes: #776881. + + -- Charles Plessy ple...@debian.org Tue, 03 Feb 2015 10:44:39 +0900 + bowtie (1.1.1-1) unstable; urgency=medium * New upstream release Let me take again the opportunity to say that I really like the way the Jessie release is organised ! Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan Debian Med packaging team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776557: debian-policy: Please clarify 2.5 'unix heritage = important'
Le Thu, Jan 29, 2015 at 09:06:15AM +, Martin Zobel-Helas a écrit : the following sentence in 2.5 leave much room for maneuver, therefor i would like to see a clarification how it should be interpreted: | Important programs, including those which one would expect to find on | any Unix-like system. If the expectation is that an experienced Unix | person who found it missing would say What on earth is going on, where | is foo?, it must be an important package. Background here is, that i moved the package ed to optional years ago, and now have bug #776413 open, which disagrees on that move. I would like to keep ed in optional, but also see the arguments the submitter gave here. Hi Martin, I fully agree. Given that Debian is 20 years old, we can not expect people to have the same opinion on What on earth is going on, where is foo? means. On my side, I thought that killall or less would be what-on-earth programs, but this is not the case. My first reaction was to argue they should be present by default on minimal systems, but my current opinion would be to rather keep minimal systems as lean as possible and rely on tasks for adding groups of packages. Regarding the Policy, we need to either find a different principle for defining the Important priority, or transfer the responsibility for choices to a do-o-cratic group of persons, like people making minimal images, maintaining debootstrap, etc. (and by default, the package maintainer of course) 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776203: Please extend LAST_UID 29999 to 59999.
Package: adduser Severity: normal Dear adduser maintainers, please extend LAST_UID 2 to 5 as this range is not reserved anymore since version 3.9.0 of the Policy. See https://bugs.debian.org/582495 and https://lists.debian.org/54c0d5a1.2020...@majbe.net for reference. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774384: developers-reference: soften advice to justify retirement to debian-private
Le Thu, Jan 01, 2015 at 09:49:22PM +, Jonathan Wiltshire a écrit : Please consider the attached patch, which rewords the advice into a courtesy mail rather than a should requirement. It's still necessary to mail debian-private, just not to include any justification. Hi Jonathan, since the Developers Reference is on collab-maint now, and since your proposition was greeted with a large number of appreciations that it reflects Debian's collective vision, I think that you can push your patch. Happy 2015 year ! -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774303: mime-support: norun option prints temp file path
Hi John and Salvatore, actually, the security fix did not change the behaviour of run-mailcap when filenames contained spaces, which already triggered renaming to a temporary file. I think that the behaviour of the --norun option is correct: it indicates exactly what run-mailcap would be doing. It would be confusing if renaming would only happen when the command is run for real. How about the following: I can add a SECURITY section in run-mailcap's manpage, which would indicate that « A temporary copy of the file is opened if the file name matches the Perl regular expresssion [^[:alnum:],.:/@%^+=_-], in order to protect from the injection of shell commands, and to make sure that the name can always be displayed in the current locale. In addition, the file is opened using its absolute path to prevent the injection of command-line arguments, for instance using file names starting with dashes. » Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774142: unblock: mime-support/3.58
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mime-support to fix CVE-2014-0666 in Jessie.
unblock mime-support/3.58
Have a nice day,
and a BIG THANK YOU for your outstanding work.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
diff -Nru mime-support-3.57/debian/changelog mime-support-3.58/debian/changelog
--- mime-support-3.57/debian/changelog 2014-10-04 20:29:52.0 +0900
+++ mime-support-3.58/debian/changelog 2014-12-28 15:06:43.0 +0900
@@ -1,3 +1,17 @@
+mime-support (3.58) unstable; urgency=high
+
+ * CVE-2014-7209: run-mailcap shell command injection.
+Thanks to Timothy D. Morgan for the report.
+
+ d156797 Escape file name also when not passed through %s. This
+ avoids command injections using for instance semicolons.
+ b585022 Resolve file name to an absolute path to avoid injection of
+ command arguments with file names starting with dashes etc.
+ Use File::Spec to avoid race conditions with temporary files.
+ Thanks, Salvatore Bonaccorso for the patch.
+
+ -- Charles Plessy ple...@debian.org Sun, 28 Dec 2014 14:45:59 +0900
+
mime-support (3.57) unstable; urgency=medium
* Media types added:
diff -Nru mime-support-3.57/run-mailcap mime-support-3.58/run-mailcap
--- mime-support-3.57/run-mailcap 2014-05-25 09:49:18.0 +0900
+++ mime-support-3.58/run-mailcap 2014-12-28 15:06:43.0 +0900
@@ -11,7 +11,7 @@
use Encode qw(decode);
use I18N::Langinfo qw(langinfo CODESET);
-
+use File::Spec;
$debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
$norun=0;
@@ -469,27 +469,22 @@
}
if ($file ne -) {
-if ($comm =~ m/[^%]%s/) {
-if (decode(langinfo(CODESET()), $file) =~ m![^[:alnum:],.:/@%^+=_-]!i) {
-$match =~ m/nametemplate=(.*?)\s*($|;)/;
-my $prefix = $1;
-my $linked = 0;
-while (!$linked) {
-$tmplink = TempFile($prefix);
-unlink($tmplink);
-if ($file =~ m!^/!) {
-$linked = symlink($file,$tmplink);
-} else {
-my $pwd = `/bin/pwd`;
-chomp($pwd);
-$linked = symlink($pwd/$file,$tmplink);
-}
-}
-print STDERR - filename contains shell meta-characters; aliased to '$tmplink'\n if $debug;
-$comm =~ s/([^%])%s/$1$tmplink/g;
-} else {
-$comm =~ s/([^%])%s/$1$file/g;
+# Resolve file name to an absolute path
+$file = File::Spec-rel2abs($file);
+if (decode(langinfo(CODESET()), $file) =~ m![^[:alnum:],.:/@%^+=_-]!i) {
+$match =~ m/nametemplate=(.*?)\s*($|;)/;
+my $prefix = $1;
+my $linked = 0;
+while (!$linked) {
+$tmplink = TempFile($prefix);
+unlink($tmplink);
+$linked = symlink($file,$tmplink);
}
+$file = $tmplink;
+print STDERR - filename contains shell meta-characters; aliased to '$tmplink'\n if $debug;
+}
+if ($comm =~ m/[^%]%s/) {
+$comm =~ s/([^%])%s/$1$file/g;
} else {
if ($comm =~ m/\|/) {
$comm =~ s/\|/\Q$file\E \|/;
Bug#774153: wheezy-jessie: systemd-tty-ask-password-agent hung
Le Mon, Dec 29, 2014 at 11:43:11PM +0100, Michael Biebl a écrit : I think I can reproduce the problem in a VM, having wheezy installed and systemd v44 as PID 1. ... If I manually run systemctl daemon-reexec at this point, the upgrade continues successfully. Hello Michael and everybody, I confirm the bug and its workaround on a Wheezy system that I attempted to upgrade today. Many thanks for your prompt reaction ! -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Dear TC, I would like to react to Ian's message, that uses words like deliberate dismantling that can be interpreted as if the misbehaviour is on my side, and will add a remark on the fact that Policy maintainers have no veto in contrary to what seemed implied in November's TC meeting on IRC. First, there is no dismantling of the Debian menu in the Policy. Ian calls this menu comprehensive, but the reality is that its coverage is patchy, in sharp contrast with the must directive in the Policy. The patch applied changed this to a should, which is a strong statement that is ground for overriding maintainers refusing patches with no reason. This adjustement of the Policy to the current practice was the core answer to the original requirement in #707851. On top of this change I wanted to take the opportunity to brush up the Policy by describing how to use FreeDesktop menu entries in Debian. Very unfortunately, this gave the impression that one menu system replaces the other, but in practice it is two parallel changes. This is why I am asking the TC to refrain from refactoring that part of our work: it has full consensus, and to be honest, I would feel it a big slap in my face (in the sense that it would call for me reconsider if my contribution is really welcome) if the TC would bypass the Policy change process to modify the changes related to the FreeDesktop menu. Ian's message goes in length on obstructive behaviours. I disagree with such behaviours and I think that the TC should override maintainers who deliberately block the work of others for tactical reasons. The obstruction discussed here is the one of a Policy editor who ignored the Policy changes process and engaged in an blocking strategy by withdrawing the discussion and then reverting the consensus-driven changes unilaterally. In the Policy changes process there is no vote and there is no veto. Bill had ample time to make his points when the discussion was opened. See through the BTS entry: I took all the time needed - more than eight months ! - to address people's reactions and seek consensus. The consensus was assessed by a Policy editor, which is the final point of the process. Bill's behaviour turns the whole discussion into a waste of time, and leaves the Policy in a state that does not reflect the reality. Far from increasing the coverage of the Debian menu systems, Bills commit reversal undermines the value of Debian's policy manual and sends the message that the personal opinion of Policy editors has precedence on consensus (and the *work* that it represents to create that consensus). For this reason, sorry to repeat myself, I am asking the TC to please rule on the question that I raised: should Bill's commit reversal be overriden ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770162: htslib: fai_build_core in faidx.c assumes char is signed
Le Sun, Dec 14, 2014 at 09:22:44AM +0100, Andreas Tille a écrit : Charles, I'm not sure how you want to deal with this. I'd regard the issue RC and it should be uploaded. However, I'm not really sure how you want to deal with the git repository and thus I simply commited the new branch and let you deal with it at your preference. Hi Andreas, on my side, since in Jessie we still have the old SAMtools, and since most NGS applications using the libbam have not been migrated to the HTSlib, I would not consider portability issues RC for Jessie. This would bring constant work before and after the release, for very few benefits. Needless to say, the fixes are welcome in Sid. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771949: pv-grub-menu: emits full path even when /boot is on separate partition
Le Sun, Dec 07, 2014 at 08:30:15PM +0100, Samuel Thibault a écrit : Charles Plessy, le Thu 04 Dec 2014 23:08:03 +0900, a écrit : In your system, can't pv-grub-menu be replaced by grub-legacy ? Indeed, that works. Good to know ! Given that maybe grub-legacy will be retired one day, you are still welcome to add the functionality you need in pv-grub-menu. However, if you are undecided about this, could you close the bug for the moment, or alternatively retitle the bug and send a brief summary giving a bit more precise guidance on what is needed to solve the problem ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771949: pv-grub-menu: emits full path even when /boot is on separate partition
Hi Samuel, I agree that the severity should not be release-critical since it is not a regression. When I introduced this package, I could only test it on the Amazon cloud, where it did not make sense to have a separate /boot partition. In addition, the MBR of the instances can not be modified, so the regular grub-legacy package could not be installed, which was one the justification for creating this package (the other being to clean the cloud-init package when importing initially from Ubuntu, which contained the ancestor of pv-grub-menu as part of the package diff). In your system, can't pv-grub-menu be replaced by grub-legacy ? In any case, you are very welcome to enhance pv-grub-menu to support your use case. The source package is in collab-maint. The original work for pv-grub-menu, Ubuntu's grub-legacy-ec2, seemed to be a partial fork of Ubuntu's grub-legacy, that itself had accumulated a large quantity of difference from Debian's grub-legacy, which is in maintainance mode. This was way too hard to maintain for me and I trimmed the main script (http://anonscm.debian.org/cgit/collab-maint/pv-grub-menu.git/log/update-menu-lst), in order to obtain something that I could understand. But please feel free to add some complexity back. Or if you prefer, you can also rewrite it altogether. What we need is a generator for menu.lst, and it does not necessary need to be a fork of grub-legacy. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769960: Possible problem with nvidia drivers ? (Re: gdm3: upgrade from 3.14.0 to 3.14.1 results in blank screen)
Hi all, I had a problem that looked similar, but was caused by a strange interaction with other pacakges (probably xserver-xorg-video-nvidia). On my side, on two desktop machines, I also had GNOME crashing on start after an update to Jessie. To my surprise this was caused by the presence of NVIDIA drivers or something in their dependancy chain, that were freshly installed during the updgrade, while the machine's graphic card were either Intel or AMD. Purging every package with nvidia in the name solved the problem (but I can not exclude that the problem was really solved by the autoremovals that came with the purge). Martin, if you have non-free enabled, maybe it is worth trying to purge the non-free nvidia drivers if they are pressent on your machines ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671524: Dropping coverage patch in Samtools ?
Le Fri, Jul 27, 2012 at 02:51:13PM +, Debian Bug Tracking System a écrit : Changes: samtools (0.1.18-2) unstable; urgency=low . * added patch to fix segfault in mpileup (Closes: #544976) * added patch to fix coverage cap (Closes: #671524) Hi Dominique and everybody, in recent versions of samtools, the mpileup command has a new option to specify the coverage at run time. Would it be fine to drop our patch that was raising the default coverage cap from 8,000 to 1,000,000 ? If yes, do you think we need to mention it as a NEWS entry ? Here is a link to our patch: http://anonscm.debian.org/cgit/debian-med/samtools.git/tree/debian/patches/fix_coverage_cap.patch. And here is a link to the pull request where I was informed about the new option. https://github.com/samtools/samtools/issues/284 Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Sat, Nov 22, 2014 at 08:15:03AM -0200, Henrique de Moraes Holschuh a écrit : Empty fields in debian/control must be valid in *source* packages. It is a widely used feature of the dpkg-dev suite, and it has been around for a very very long time AFAIK. Hi Henrique, do you have examples of packages having empty fields in source package control files ? I have not found any. (In the sense that a field that only contains a substitution variable is not considered empty). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit :
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package
control
files ? I have not found any. (In the sense that a field that only
contains
a substitution variable is not considered empty).
They come from empty substitutions, yes.
Then they are not empty: there is a big difference between Depends: and
Depends: ${foo}. I think that it would be very confusing if we would refer
them as empty.
Also, the bug started with a problem where empty means nothing after the
colon.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Sun, Nov 23, 2014 at 04:14:14PM -0200, Henrique de Moraes Holschuh a écrit :
On Mon, 24 Nov 2014, Charles Plessy wrote:
Then they are not empty: there is a big difference between Depends: and
Depends: ${foo}. I think that it would be very confusing if we would
refer
them as empty.
Well, both are valid. Can you suggest alternative wording?
Le Sun, Nov 23, 2014 at 08:09:29PM +0100, Bill Allombert a écrit :
This bug is mostly to document a check in dak. Are you suggesting the check is
looking at the debian/control file and reject source packages with empty
fields
?
Hi Henrique and Bill,
first, on the original purpose of this bug, it is to document that empty fields
in binary package control files are not supported and can crash tools such as
apt. There, empty meant that the semicolon at the end of a field name is
followed by a newline character. A member FTP team answered to the submitter
by confirming that binary packages with empty fields in their control file are
rejected from the Debian archive.
I think that we all agree to document that fields must not be empty in binary
package control files. Let's see the other points under discussion.
* The definition of empty. Henrique has used the word empty to designate
fields of a source package control file that contain a substitution variable
that may not contain a value at build time. I think that this complicates
the
defintion of empty too much, since in that case one has to build a package
to
determine if a field is empty or not. The answer would even depend on the
state of the archive ! Regarding the submitter's definition, it is a bit
stricter than what the syntax of control fields allows, where a field in
which
the colon after the name is followed by spaces is also empty.
* Whether to disallow empty fields in other control files. I have not seen
empty
fields elsewhere, and I am not aware of plan to use some. Empty fields are
not
used when a field is solely needed as a flag, such as the Essential field.
Altogether, I think that it would be neater to clarify the section about the
syntax
of control files that fields must not be empty, than to make this a special
restriction of binary package control files.
For the wording, if my original wording was too unclear, how about requesting
that all fields must have a value, so that there is no ambiguity on what
empty means ? We could for instance add Fields with no value are invalid.
at the end of the second paragraph of section 5.1. (New patch attached).
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
From 1cd63a7a20d4f1ff71fd68987f6efcbf3a5924d0 Mon Sep 17 00:00:00 2001
From: Charles Plessy ple...@debian.org
Date: Mon, 24 Nov 2014 08:53:10 +0900
Subject: [PATCH] Clarify that fields with no value are not valid.
Closes: #666726
---
policy.sgml | 1 +
1 file changed, 1 insertion(+)
diff --git a/policy.sgml b/policy.sgml
index 7bb703b..daf0f12 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2544,6 +2544,7 @@ endif
space, and colon (i.e., characters in the ranges 33-57 and
59-126, inclusive). Field names must not begin with the comment
character, tt#/tt, nor with the hyphen character, tt-/tt.
+ Fields with no value are invalid.
/p
p
--
2.1.1
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Fri, Nov 21, 2014 at 10:56:15AM +0100, Bill Allombert a écrit :
What about automatically generated control files and substvar ?
e.g.
Depends: ${misc:Depends}
where ${misc:Depends} resolve to the empty string ?
Does dpkg-gencontrol take care of that ? In that case we should not lead
people
to believe that the above is incorrect.
Hi Bill,
a quick check where I added Recommends: ${misc:Recommends} and Suggests: to
the source control file of the hello package suggests that empty fields
are removed by default.
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
Le Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin a écrit : Control: tags -1 + patch On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote: How about the attached patch, that adds Its value must not be empty. after The field ends at the end of the line or at the end of the last continuation line. Seconded. Thanks Andrey. are there objections against forbidding empty control fields ? If not, would somebody eles second the patch ? have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: Clarify network access for building packages in main
Le Tue, Nov 18, 2014 at 03:03:07PM +0600, Andrey Rahmatullin a écrit : 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. Note that there may be other requirements which are not codified, as mentioning only things that are packaged is not enough, it should say something like must not use any stuff except for packages in main. Hi Andrew, I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. This said, one could argue that the definition of main should not depend on the definition of contrib or non-free... Would you, Holger or somebody else propose a patch ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: [summary] Re: Bug#758234: transitive dependencies
a consensus on a) accepting that packages may depend on lower-priority packages if we find a satisfying way of b) keeping the relevant people informed of decisions that may change Debian's installation size. Therefore I have questions for you, and I would be especially pleased if your answers could converge into a final proposition that makes everybody comfortable. - Would a message to the relevant package maintainers be enough ? - Should the debian-boot and debian-cd mailing lists be notified as well ? - Is a message to debian-devel needed ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: [summary] Bug#759260: removal of the Extra priority.
Control: reopen -1 Control: tag -1 + patch [CCed everybody who contributed in #758234 and #759260, sorry if you were not interested in that part of the discussion] Hello again, Here is a summary of the discussion in #759260 (cloned from #758234), regarding the suppression of the Extra priority. The purpose of the original proposition was to ease the manual adjustment of higher priorities, but aside from that goal, there was a broad agreement that the Extra priority is not really needed anymore. The submitted patch (https://bugs.debian.org/759260#62) deletes the whole paragraph on the Extra priorities, as well as the requirement for pairs of conflicting packages that at most one is above the lowest priority. It was seconded in https://bugs.debian.org/759260#67, and other messages in the discussion are also going in the same direction (https://bugs.debian.org/759260#47). A second call for support or objections was given on Oct 6: (https://bugs.debian.org/759260#131), and in the absence of feedback, the bug was closed on Oct 20 (https://bugs.debian.org/759260#136) was closed. I am reopening is because I think that we have actually reached consensus for the change. One of the potential uses of the Extra priority was to allow for co-installing all packages down to the Optional priority. However, this goal is not seem realistic anymore given the current size of the Debian archive, and indeed, no concrete example (that is, not just a though experiment or a single exploratory attempt) of relying on this co-installability was given. The Extra priority was also defended on the basis that it is useful for at least transitional packages and detached debug symbols(https://bugs.debian.org/759260#83). However, these are better managed with Sections instead of Priorities. (https://bugs.debian.org/759260#108). The Extra priority was also said to be potentially useful to see which packages are safe to remove, or to search for them. If Extra were removed, it would not be possible anymore to define defaults for conflicting Optional packages. However I am unsure that in that case there are real defaults in the same sense that exim is default and postifx is not. After reading the whole thread, I think that the objections against the removal of the Extra priority have been adequately addressed, and the people who raised them (mostly Ansgar and Matthias), while not supporting the change, are not opposing it to the point of asking to block it. Therefore, I second Gerrit's proposition. Together with Jonathan's seconding, this opens the way for a Policy change if Editors agree and of course if there is no last-minute novel argument. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: [summary] Bug#759260: removal of the Extra priority.
Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit : The purpose is to allow the user to install as many optional packages as he/she wants without having to bother with conflicts. Hi Santiago, practically speaking, how do you or others use the Optional priority to check that a package is not directly or transitively conflicting with another package ? First, according to debcheck (https://qa.debian.org/debcheck.php?dist=sidlist=main-only-priorityarch=ANY) there are thousands of packages whose Priority setting violates the current policy. Second, tools such as apt-get --simulate are very efficient at checking if the installation of one package will need or trigger the removal of another one. In which case would it be more efficient to check the priority instead, especially given the first point above ? Can you give concrete examples where the Extra priority has been instrumental for you as a user or a developer, in a way that has no practical alternative ? Or said differently, what would break concretely for you if tomorrow the Optional and Extra priorities were merged ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769219: function moved
Le Sun, Nov 16, 2014 at 12:36:05AM +0100, Bill Allombert a écrit : Do you know if there is a org to XML (or SGML) conversion option ? Hi Bill, according to its documentation, Pandoc can do convert Org-Mode to DocBoox Have a nice Sunday, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: transitive dependencies
Le Thu, Nov 13, 2014 at 01:24:32PM +0100, Matthias Urlichs a écrit : p - Packages must not depend on packages with lower priority - values (excluding build-time dependencies). In order to - ensure this, the priorities of one or more packages may need - to be adjusted. + Packages may depend on other packages with lower priority values. + These other packages, or their dependencies, must not conflict with + another higher-priority package.footnote + Debian does not require its base-system installation scripts to employ a + full-featured dependency resolver; this rule ensures that install + all ttimportant/tt packages and their open dependencies works + and results in a consistent and bootable system. + /footnote + /p + p + This restriction does not apply to packages of priority + ttoptional/tt or lower. It applies transitively. + It does not apply if a dependency is already satisfied by another + higher-priority package. If alternative dependencies are used, + it only applies to the first alternative(s). /p Hi Matthias and everybody, on my side I agree that self-contained priority levels are not needed anymore and are even becoming harmful. This said, there were objections to the removal of this rule in this thread and in #759260, and I do not remember if we had good answers to each of them. Matthias, do you think that you could make a summary of the pros and cons that were discussed in these threads ? Regarding your proposed change, I wonder what is the practical case for forbidding conflicts with higher-priority packages. Could you give an example showing that it is strictly necessary ? Otherwise, it would be simpler to simply remove the requirement for adjusting priorities. Lastly, while we are at it, let's insert a clarification that in Debian, the priority of the packages are determined by the archive administrators, and that the source package control file is not the canonical source of information for a binary package's priority when this package is distributed in the Debian archive. (This would close #616055). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768292: Let's add the MPLs to /usr/share/common-licenses ? (was Re: Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files)
Le Sun, Nov 09, 2014 at 09:13:21AM -0800, Russ Allbery a écrit : How about adding both MPLs to /usr/share/common-licenses ? Given those numbers, I think we should. And possibly also CC-BY-SA 3.0 while we're at it. Hi Russ, I fully agree. For the avoidance of doubt, I have also counted the numbers for other CC licenses; here is the result. AGPL 3 294 Apache 2.0 4740 Artistic 3811 Artistic 2.0195 BSD (common-licenses) 347 CC-BY 1.011 CC-BY 2.0 1 CC-BY 2.533 CC-BY 3.0 311 CC-BY-SA 1.0 2 CC-BY-SA 2.0 32 CC-BY-SA 2.5 16 CC-BY-SA 3.0883 CC-BY-SA 4.0 23 CDDL504 CeCILL 54 CeCILL-B 50 CeCILL-C 33 GFDL (any) 2155 GFDL (symlink) 539 GFDL 1.2 1074 GFDL 1.3619 GPL (any) 40659 GPL (symlink) 7641 GPL 1 3657 GPL 2 25546 GPL 3 11363 LGPL (any)18315 LGPL (symlink) 2466 LGPL 214666 LGPL 2.1 10422 LGPL 3 2644 LaTeX PPL76 LaTeX PPL (any) 197 LaTeX PPL 1.3c 184 MPL 1.11146 MPL 2.0 847 SIL OFL 1.0 13 SIL OFL 1.1 567 Total number of packages: 73292 By the way, would you and the other Policy editors mind if I would save these numbers in the Git repository, for insance in a text file named tools/license-check.latest.txt ? This way, it will be easier to keep an eye on the evolution of these numbers. As far as I could see with search engine, the previous number for MPL-1.1 was 740. https://lists.debian.org/debian-policy/2011/12/msg00130.html For the CC licenses, it was: CC-BY 3.068 CC-BY-SA 3.0133 https://bugs.debian.org/662649#31 Before taking final action, shall we consider adding also CC-BY 3.0 (not as popular as the SA variant, but this may avoid some errors), and the 4.0 version of the licenses ? The rationale for using the 4.0 version is that if their use increases like for the 3.0 versions (and I would be surprised if not), then waiting to add them to /usr/share/common-licenses is giving double work to the maintainers: first they have to include them in debian/copyright, and then they will have to remove them. This said, I do not have a strong opinion. Once this is discussed, I will propose a patch to the Policy. After it is properly seconded, I will ping the Lintian maintainers (please remind me if I forget). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769050: [Debian-med-packaging] Bug#769050: sra-toolkit should only install binaries, not symlinks to symlinks to binaries
Le Mon, Nov 10, 2014 at 04:15:07PM -0800, Don Armstrong a écrit : Package: src:sra-sdk Version: 2.3.5-2+dfsg-1 Severity: minor Since sra-toolkit isn't co-installable with another version, it should just install the binaries, and not symlinks which are two levels deep. Hi Don, I (or any other packager quicker than me) will investigate this for the next update of the package. Update to version 2.4.x has been delayed because the source tarball is not distributed on the NCBI's website. It is now on GitHub but there has been a gap. If you have time, and if it is till relevant to version 2.4.2-3, maybe you can also make your suggestion in Upstream's tracker ? https://github.com/ncbi/sra-tools 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768292: Let's add the MPLs to /usr/share/common-licenses ? (was Re: Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files)
Le Sun, Nov 09, 2014 at 08:21:58AM +0900, Mike Hommey a écrit : Note the iceweasel copyright file uses that stanza for both MPL-1.1 and MPL-2.0, and is still about 100K long. Even if MPL-2.0 ends up in the common set of licenses, that would still leave the MPL-1.1 being a problem, while, in fact, it's barely relevant: all the code under the MPL-1.1 is either dual or tri-licensed with LGPL-2.1 as an alternative. So, I would still hate to have to put the verbatim MPL-1.1 text in the iceweasel copyright file. Hi Mike and everybody, here is the current license count that I just calculated on the lintian lab (lilburn.debian.org) using tools/licence-count from the Policy's Git repository. AGPL 3 292 Apache 2.0 4764 Artistic 3818 Artistic 2.0201 BSD (common-licenses) 349 CC-BY 3.0 309 CC-BY-SA 3.0883 CDDL504 CeCILL 54 CeCILL-B 50 CeCILL-C 33 GFDL (any) 2181 GFDL (symlink) 541 GFDL 1.2 1088 GFDL 1.3617 GPL (any) 41017 GPL (symlink) 7765 GPL 1 3659 GPL 2 25825 GPL 3 11428 LGPL (any)18377 LGPL (symlink) 2480 LGPL 214714 LGPL 2.1 10441 LGPL 3 2644 LaTeX PPL76 LaTeX PPL (any) 197 LaTeX PPL 1.3c 184 MPL 1.11146 MPL 2.0 853 SIL OFL 1.0 13 SIL OFL 1.1 567 Total number of packages: 73267 How about adding both MPLs to /usr/share/common-licenses ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files
Le Sat, Nov 08, 2014 at 02:27:10PM -0800, Russ Allbery a écrit : Russ Allbery r...@debian.org writes: The other objection, though, was that, as a project, we don't really *like* the MPL 2.0 license. It's a rather irritating license that we'd rather people not use, and having it in common-licenses can be seen as a sort of endorsement. I'm not sure how much weight to put on that argument. It appears that I confused this license with the Netscape Public License. Please ignore this paragraph; I don't know of anything wrong with the MPL 2.0 other than it being complicated and long, which is just a matter of taste. :) Good news. Simon, would it solve your problem if the MPL-2.0 license were added to /usr/share/common-license ? (By the way, for the record, I consider that /usr/share/common-license is not a mark of endorsement anyway). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files
Le Thu, Nov 06, 2014 at 09:44:29AM +, Simon McVittie a écrit : Some packages currently have stanzas like this in their copyright files: License: MPL-2.0 The complete text of the Mozilla Public License 2.0 can be found in the `MPL-2.0' file in the same directory as this file. It is not clear to me whether Debian Policy allows this. Hi Simon, within our current practice, the MPL-2.0 license would need to be added to /usr/share/common-licenses to allow quoting it from the Debian copyright file. Last time Russ looked if the license was frequent enough, the answer was no. But you can have a look at tools/license-count in the Policy's source package, and run it again at lintian.debian.org to see if the situation changed significantly. That would solve your problem with this license. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: it's actively harmful
Le Thu, Oct 30, 2014 at 05:09:45PM +0100, Matthias Urlichs a écrit : Santiago Vila: Maybe because current policy allows one to take the following set of packages: + Packages of required priority. * Packages of important or higher priority. * Packages of standard or higher priority. and all those sets are self-consistent (i.e. they don't have dependencies outside the set). I think this is a useful and nice property, but I don't know how many people rely on it. It certainly is useful to have these sets of packages IMHO. But the work to keep the priorities consistent is not useful when you already have a tool that adds them (and nothing else) to a set of packages when you need it, as opposed to when ftpadmin gets around to updating the override file. Hello everybody, altogether, this is a cost/performance issue: self-conistency is nice to have, but there is a soft limit to the amount of time and energy that Debian can spend acheiving it. One of the problems identified is that it is easy raise the priority of a package to increase consistency, but harder to remember to lower it when it is not needed anymore. If there is a strong interest to keep self-consistency of priorities, could it be done by making the archive overrides work in a two-step manner ? First apply the overrides as defiend manually (by the first upload and then by requests to the FTP team), and then in a second step make the archive self-consistent by increasing priorities where it is needed, without permanently modifying the manual information of the override file itself. But before doing that work, it would be good to make sure that it is really needed. The alternative, to change the Policy to remove the requirement of self-consistency, is obviously easier, and the information of what the transitive priority of a package can be calculated or served in a separate way that does not require changes to the Debian archive. Have a nice Sunday. -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762154: lintian: ignore header's license field for missing-license-paragraph-in-dep5-copyright ?
Le Tue, Oct 21, 2014 at 10:45:49AM +1100, Ben Finney a écrit : On 19-Sep-2014, Charles Plessy wrote: I have a package where the machine-readable copyright file has the following licence field in its header. License: GPL-2 and MIT and GPL-3+ with runtime exception and zlib BEDTools combines source code under GPL-2, LGPL-2.1 and MIT licenses, and links to libc6, libgcc, libstdc++ and zlib1g. Why put that paragraph in the header? Is it not superfluous, since you will also need to repeat that license information in the “files” paragraphs? Hi Ben, in this paragraph, I summarise the situation of the binary executables, taking dynamic linking into account (links to libc6, libgcc, libstdc++ and zlib1g). This is why the GPL-3+ with runtime exception and zlib licenses are not present in full in this debian/copyright file. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753485: [Debian-med-packaging] Bug#753485: Status of samtools
Le Fri, Oct 10, 2014 at 06:42:34PM +, Aleksandar Zlicic a écrit : On the other hand, most of the changes regarding unaligned access issues weren't accepted and upstream developers suggested this should be fixed in another way, that is by implementing a standard set of functions for accessing memory in both cases (where architecture supports unaligned access and for architectures which don't) and using these functions for accessing memory throughout the code. One of the samtools developers has done some work to implement this (https://github.com/jkbonfield/htslib/tree/SPARC), but changes from this experimental branch haven't been merged to the main branch yet. Hi Aleksandar and Andreas, I was contacted by one of the upstream developers about getting access to a SPARC porter box, and just asked for it to the DSA. Let's see how it goes. Cheers, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764424: Thanks again ! (Re: Bug#764424 closed by Thomas Goirand z...@debian.org (Bug#764424: fixed in python-requestbuilder 0.2.3-1))
Le Wed, Oct 08, 2014 at 09:27:31AM +, Debian Bug Tracking System a écrit : This is an automatic notification regarding your Bug report which was filed against the python-requestbuilder package: #764424: Please upgrade to version 0.2.3. It has been closed by Thomas Goirand z...@debian.org. Merci encore ! I just could confirm that euca2ools works well with python-requestbuilder 0.2.3-1. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764424: Please upgrade to version 0.2.3.
Package: python-requestbuilder Version: 0.2.2-1 Severity: wishlist Good morning Thomas, actually, euca2ools did not work with python-requestbuilder version 0.2.2, and I was told by the upstream author by the upstream author (of both, actually) that this particular version is broken. Can you update to 0.2.3 ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764297: New upstream release needed for euca2ools
Package: python-requestbuilder Version: 0.1.0-1 Severity: wishlist Hi Julien, Thomas, Mehdi and everybody, for updating euca2ools to the latest stable version, I would need python-requestbuilder to be updated to version 0.2 at least. Do you think it would be possible ? Is there a way I can help ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764297: Thanks ! (Re: Bug#764297 closed by Thomas Goirand z...@debian.org (Bug#764297: fixed in python-requestbuilder 0.2.2-1))
Le Tue, Oct 07, 2014 at 03:24:09AM +, Debian Bug Tracking System a écrit : This is an automatic notification regarding your Bug report which was filed against the python-requestbuilder package: #764297: New upstream release needed for euca2ools It has been closed by Thomas Goirand z...@debian.org. You rock :) -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763563: RM: fitgcp [armel armhf mips mipsel powerpc s390x] -- ROM; unsatisfiable Depends
Package: ftp.debian.org Severity: normal Dear FTP team, fitgcp depends on python-pysam, which is not available on armel armhf mips mipsel powerpc s390x and which does not seem to become available there in the short term. fitgcp 0.0.20130418-1 got built on every architecture, and therefore could not migrate to Testing. We updated it (0.0.20130418-2) to build-depend on python-pysam so that architecture availability of these packages will match automatically. Please remove fitgcp from armel armhf mips mipsel powerpc s390x to let version 0.0.20130418-2 migrate to testing. Thanks for your support, and have a nice day, -- Charles Plessy Debian Med packaging team https://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763218: [Debian-med-packaging] Bug#763218: python-pysam: FTBFS: Tests failures
Control: tag -1 - jessie
Le Sun, Sep 28, 2014 at 07:15:05PM +0200, David Suárez a écrit :
Source: python-pysam
Version: 0.7.7-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20140926 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
==
FAIL: testBAM (__main__.TestUnmappedReads)
--
Traceback (most recent call last):
File ./pysam_test_offline.py, line 998, in testBAM
self.assertEqual( len(list(samfile.fetch( until_eof = True))), 2 )
AssertionError: 0 != 2
--
Ran 158 tests in 9.110s
FAILED (failures=2, errors=31)
E: pybuild pybuild:256: test: plugin custom failed with: exit code=1: cd
tests PYTHONPATH=/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build python2.7
./pysam_test_offline.py
dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned
exit code 13
make[1]: *** [override_dh_auto_test] Error 13
debian/rules:29: recipe for target 'override_dh_auto_test' failed
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2014/09/26/python-pysam_0.7.7-1_unstable.log
Thanks David.
The build logs show that the tests fail because the version of samtools is not
0.1.19. Here is an example:
==
ERROR: testBam2fq (__main__.BinaryTest)
--
Traceback (most recent call last):
File ./pysam_test_offline.py, line 303, in setUp
samtools_version ))
ValueError: versions of pysam/samtools and samtools differ: 0.1.19 !=
1.1
Given that samtools is still at version 0.1.19 in Jessie and that it is unsure
whether the version in sid (1.1) will migrate before the Freeze, I am removing
the
tag 'jessie' from this bug.
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726262: Will help packaging
Le Fri, Apr 11, 2014 at 01:42:40PM -0600, Mike Place a écrit : I'm on the SaltStack core development team. I will volunteer to maintain the m2crypto package going forward. Whom do I need to contact to help to manage the transition? Dear Mike, I am worried that I forgot to answer your proposition for taking over the package… You are of course very welcome to do so, there is no extra permission to ask for. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762647: [Debian-med-packaging] Bug#762647: samtools: FTBFS: test suite errors
Le Tue, Sep 23, 2014 at 11:20:15PM -0400, Aaron M. Ucko a écrit : The builds of samtools for arm64 and ppc64el both failed because the first samtools faidx test hit the autobuilders' activity timeout. Given that these timeouts are generous (300 minutes for arm64, 150 for ppc64el), I suspect the test managed to hang on those systems. Meanwhile, the other builds attempted so far all encountered unexpected test failures -- 2 on kfreebsd-amd64, and 95 each on i386, kfreebsd-i386, and mipsel. Hi Aaron, regarding the test failures on the ‘stats’ command (2 unit failures), I reported the issue upstream and will implement a workaround if necessary. https://github.com/samtools/samtools/issues/300 The other failures and timeouts are probably symptoms of non-portability outside amd64. Some porters have contacted upstream on endianness issues, but I do not know if the problem is likely to be solved in the short term. https://github.com/samtools/samtools/issues/268 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707338: Bug#707341: upgrade to important, python-uno should go away
Le Mon, Jun 30, 2014 at 09:18:26PM +0200, Karsten Hilbert a écrit : On Sat, Jun 14, 2014 at 10:07:24PM +0200, Rene Engelhard wrote: On Sat, Jun 14, 2014 at 04:23:20PM +0200, Rene Engelhard wrote: still supporting python-uno gives much headache (for example it's build is a big hack and right now it's broken for wizard/lightproof usage inside LO. I am trying to fix it but if I don't succeed we should make -common force python3-uno. Which would mean it conflicted against python-uno...) [...] Anyway: I'll try to fix python-uno for LO 4.2.x but I have just decided to It was easier than it looked after some tries with the build - a simple missing file :) [1] disable building it with LO 4.3 (which IS still planned for jessie). [...] So expect python-uno going away without further notice once dovert is fixed, or removed - breaking whatever functionality you need it for. As said, you can make it work again by switching to python3-un Now that it's fixed: Maybe also only after jessie release because I do acknowledge that it's not much time until the freeze. Which would means 4.4 or newer, which I already have changed to remove the option alltogether [2] Still your package must be changed to support python3. ASAP. Well, since ATM there is neither any python-wxgtk3 (which would also mean having to port from wxp2 to wxp3) nor any python-wxgtk2.8-for-python3 this assertion seems of little use ? Hi Karsten, not sure if it will help, but please note that there is now a package python-wxgtk3.0 in Unstable and Jessie. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762412: ITP: paraclu -- Parametric clustering of genomic and transcriptomic features
Package: wnpp Severity: wishlist Owner: Charles Plessy ple...@debian.org * Package name: paraclu Version : 9 Upstream Author : Martin C. Frith * URL : http://www.cbrc.jp/paraclu/ * License : GPL-3+ Programming Lang: C++ Description : Parametric clustering of genomic and transcriptomic features Paraclu finds clusters in data attached to sequences. It was first applied to transcription start counts in genome sequences, but it could be applied to other things too. . Paraclu is intended to explore the data, imposing minimal prior assumptions, and letting the data speak for itself. . One consequence of this is that paraclu can find clusters within clusters. Real data sometimes exhibits clustering at multiple scales: there may be large, rarefied clusters; and within each large cluster there may be several small, dense clusters. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762154: lintian: ignore header's license field for missing-license-paragraph-in-dep5-copyright ?
Package: lintian Version: 2.5.27 Severity: wishlist Dear Lintian maintainers, I have a package where the machine-readable copyright file has the following licence field in its header. License: GPL-2 and MIT and GPL-3+ with runtime exception and zlib BEDTools combines source code under GPL-2, LGPL-2.1 and MIT licenses, and links to libc6, libgcc, libstdc++ and zlib1g. It triggers the following warnings W: bedtools source: missing-license-paragraph-in-dep5-copyright zlib (paragraph at line 7) W: bedtools source: missing-license-paragraph-in-dep5-copyright gpl-3+ with runtime exception (paragraph at line 7) W: bedtools source: missing-license-paragraph-in-dep5-copyright mit (paragraph at line 7) I wonder if it wouldn't be better to ignore the license field of the header for that check. The alternative would be to add standalone paragraphs for these licenses, but this would be a lot of “boilerplate” text in the copyright files… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753485: [Debian-med-packaging] Bug#753485: Status of samtools
Le Wed, Sep 03, 2014 at 09:36:02AM +0200, Andreas Tille a écrit : currently we have samtools/0.1.19-1 with bug #753485 tagged patch but are missing a confirmation from upstream for this patch. We also have a new upstream version of samtools (1.0) in experimental (that might or might have not applied this patch). Can anybody give some status update what the plan for samtools regarding the Jessie release might be? Hi Andreas, unless there are major problems of backwards compatibility, I think that we should release with the new version of SAMtools based on the HTSlib, which introduces support for the new CRAM format. I uploaded version 1.0 in experimental for only two reasons: - first, I wanted to test it more, and give opportunity to others to test it as well, - second, I was not sure if dynamic linking was fully supported since it requires patching the makefile. My current plan is to wait a bit more if there is a new upstream version that would solve all of this (and include our patches that I forwarded on GitHub). But if such an update does not come soon, then I (or others) should upload samtools to Unstable. Regarding the portability, I do not know if the 1.x line will induce regressions or not, but if this is the case, I would like to solve the problem by dropping support for the failing architectures, unless the upstream developers show interest for them. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759746: mime-support: Missing rule for ddeb files
Control: severity -1 wishlist Control: tag -1 pending Le Fri, Aug 29, 2014 at 06:04:57PM -0400, Samuel Bronson a écrit : The mime.types entry for application/vnd.debian.binary-package should list ddeb along with deb and udeb; this extension is used on Ubuntu and hopefully will be used in Debian for automatically-generated debug info packages. See https://wiki.debian.org/AutomaticDebugPackages for more information. Dear Samuel, I added ddeb to /etc/mimes.types an unless you need it to be propagated quickly, I will wait for more changes until I upload the next update of mime-support. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#291015: mime-support: run‐mailcap to understand URL notation and start sensible-browser if required.
Dear Eric, do you still have interst for this bug report ? Have a nice week-end, -- Charles Plessy Le Sat, May 03, 2014 at 09:02:28PM +0900, Charles Plessy a écrit : Le Tue, Jan 18, 2005 at 09:56:22AM +0100, Eric Lavarde a écrit : more and more utilities use URL notation to pass around file names, hence it would be very useful to have run-mailcap understand URL and do one of two things: - handle file:/... URL as normal files. - pass along other kinds of URL (http://, ftp://, etc...) to sensible-browser. This could be possibly controlled by a switch (e.g. --allow-url) for security reasons. Dear Eric, for the first part of your proposition, I think that there is a serious obstacle: with the mailcap system, it is not possible to determine if a program would be able to use an URL to retreive a file. For the second part, here is what we could do: - send a patch to the sensible-utils package, to add two lines in its mailcap file, where the media types x-scheme-handler/http and x-scheme-handler/ftp would be associated to the sensible-browser program. - Detect URLs passed to run-mailcap, and execute what /etc/mailcap proposes for the corresponding media type. The problem I have with this approach is that x-scheme-handler media types are not registered to the IANA. As far as I know, they originate from the Shared MIME-info Database specification. http://standards.freedesktop.org/shared-mime-info-spec/ Perhaps it would be better to ask for comments on debian-devel before using these unregistered media types outside the scope where thay have been developed originally. What do you think about this ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759491: Bug#758234: Defining pseudo-essential
Le Wed, Aug 27, 2014 at 03:15:28PM -0700, Russ Allbery a écrit : Jakub Wilk jw...@debian.org writes: * Russ Allbery r...@debian.org, 2014-08-27, 09:22: + often tricky and inobvious. Is it inobvious, unobvious, or non(-)obvious? Maybe just say not obvious. Yes, that's better. Thanks. Thanks Russ, I think that this new paragraph is very useful. If need is I second its addition. This addition will cause the current section 3.9 (Maintainer Scripts) to be renumbered 3.10, but I do not expect this to cause big confusions. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759186: debian-policy: please consider adding nodoc as a possible value for DEB_BUILD_OPTIONS to policy
Le Wed, Aug 27, 2014 at 08:21:05AM -0700, Russ Allbery a écrit : How about: This tag says to skip any build steps that only generate package documentation. Required files such as copyright and changelog files must still be generated and put in the package, but other generated documentation such as help2man-generated pages, Doxygen-generated API documentation, or info pages generated from Texinfo sources should be skipped if possible. This option does not change the set of binary packages generated by the source package, but documentation-only binary packages may be nearly empty when built with this option. I was a bit worried that some source packages might actually use the nodoc build option to process a control.in file and remove the doc packages, but a quick inspection of a handful of examples suggests that it is not the case. I think that the workding is very good, thanks to you and Johannes. I second it, including minor improvements such as the one proposed by Johannes. Cheers, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel
Le Tue, Aug 26, 2014 at 01:27:23PM +0200, Andreas Tille a écrit : Hi, yesterday I joined the videostream of the installer BoF at DebConf[1]. I also became a bit involved via IRC. Joey Hess raised the question about the criteria to add a Blend or not. I answered all in the list of the bug report #758116 which IMHO fits the criterion of actively maintained and some valuable content for users. I think it should be also a criterion that the team behind the Blend confirms that they are interested and so I'm hereby pinging all lists in question to ask you for confirmation. I have set Reply-To to the bug report and the general Blends list in case you are interested in further discussion with other Blends. Any input is welcome to make sure users will realise the fruits of your great work at the earliest point in time. Hi Andreas, Joey and everybody, I am sure that it would be great for Debian Med to have the Blends as first-class citizens in the Debian Installer. While it is not difficult to install the metapackages by hand, I expect that having it as an option in the installer will help convincing people to give it a try. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759186: debian-policy: please consider adding nodoc as a possible value for DEB_BUILD_OPTIONS to policy
Le Mon, Aug 25, 2014 at 06:06:01AM +0200, Johannes Schauer a écrit : please consider adding nodoc as a possible DEB_BUILD_OPTIONS value to § 4.9.1 [1]. The value nodoc or nodocs is currently used in 72 source packages according to [2]. Documenting nodoc in policy would avoid the confusion between the two. The singular should be preferred because nocheck is written in singular as well and because *-doc packages have the singular as a postfix. Hello Johannes, I think that it is a good idea. Here is a draft patch. When writing this patch, I became unsure if “*-doc” packages are the best description for the binary packages that will not be built. Should it be any package in the “documentation” section instead ? Or should it be kept vague to give flexibility to the maintainer to do the right thing ? I opted for this choice and wrote “packages containing the generated documentation”. Do you or others have modifications to propose ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan From 512bca9ac18d8bd4e07eba0b02463369d40420a0 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Wed, 27 Aug 2014 06:37:41 +0900 Subject: [PATCH] =?UTF-8?q?Document=20the=20=E2=80=98nodoc=E2=80=99=20buil?= =?UTF-8?q?d=20option.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes: #759186 --- policy.sgml | 5 + 1 file changed, 5 insertions(+) diff --git a/policy.sgml b/policy.sgml index 6eac491..62d2bdf 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2256,6 +2256,11 @@ zope. This tag says to not run any build-time test suite provided by the package. /item + tagnodoc/tag + item + Do not build the documentation and do not build the binary + packages containing the generated documentation. + /item tagnoopt/tag item The presence of this tag means that the package should -- 2.0.1
Bug#759316: Document the use of /etc/default for cron jobs
Le Tue, Aug 26, 2014 at 09:55:29AM +0200, Tanguy Ortolo a écrit : For practical reasons, variables that are used to configure init scripts behaviour are placed in separate files in /etc/default, as documented in Policy §9.3.2. The same is often applied to cron jobs as well, for the same practical reasons as crontab jobs are quite similar to init scripts (being both configuration files and scripts, and containing both configuration and code). But, contrary to init scripts, this practice is not yet documented in the Policy. I think this practice would be worth adding to the Policy, as it is both useful and already used with no opposition as far as I know. If that seems relevant, I can write a patch for that. Hi Tanguy and everybody, I am unsure what the standard practice is in this situation. Can you and others comment on the existence or not of alternatives, in Debian and elsewhere ? If we document the use of /etc/default to configure cron jobs without considering alternatives, the risk will be to push towards a Debian-only standard, or worse, to push maintainers to modify upstream cron jobs using a legitimate way to configure, but not using /etc/default. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: Bug#759260: [PATCH] Remove priority extra, make all corresponding packages priority optional
Le Wed, Aug 27, 2014 at 12:43:16AM +0200, Matthias Urlichs a écrit : Russ Allbery: Do you actually do this? Is optional actually conflict-free? I'm pretty sure it isn't. No, it's not. But I'd like it to be. However, if a consensus should emerge that it's too much hassle to file bugs against 100 packages (and then have at least half of their maintainers show up in -devel for the first time in $FOREVER, and try to argue that $OTHER_PACKAGE should be in Extra instead, because of $AD_HOC_REASON) then I'd grudgingly be OK with abolishing Optional. Hi Matthias, changes to the Policy are not made in order to trigger others to work in one direction or the other, that is, the Policy is not an instrument to change the current practice. Rather the contrary: the Policy documents the current practice. Unless you or others are going to invest significant amounts of time to make the ‘extra’ priority taken seriously by the majority of the package maintainers, you opposition has only the effect of keeping our documentation in a state of confusion that does not reflect what is actually done. So, thank you for being “grudgingly OK” with the proposed changes :) When we do not contribute to an area of Debian's development, I think that we need to be parcimonious in opposition, and keep it only for changes that have a major impact on us. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Hello everybody, I would also support the suppression of the priority “extra” – which never brought concrete benefits in my experience in the Debian Med team – but the situation as of today is that this suppression is opposed by a member of the FTP master team, and since this is the team that would have to to the work induced by the suppression, this is a major blocking point. Ansgar, you have written that you find the priority “extra” useful in some situations, but for me it is not clear if the uses cases are for human readability, or if it is to rely on that priority in automated processes. Could you give us details ? There is probably something to learn from them. Regarding the clarification of how priorities are managed, this has been under consideration for more than 10 years in #196367, whith one of the proposed wordings being seconded. In my point of view, we should insert this clarification in the Policy in a non-normative way, that is, with a wording that escapes the procedural overhead of looking for seconds. Something like: “The Priority and Section of the binary packages distributed in the Debian archive are set through a centralised ‘override’ file where values may differ from the field value in the source packages. The ‘override’ system is managed by the FTP master team and is outside the scope of this document.” Lastly, about raising directly or transitively priorities to required or important, I think that it would be useful and constructive to ask that at least a notification is sent on debian-devel. However, given the toxic levels of naysaying on this list, it would be too paralysing to require for a formal consensus. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756780: Status bowtie + tophat (Was: [Help] Need help for architecture specific code)
Le Sat, Aug 23, 2014 at 07:30:21PM +0200, Andreas Tille a écrit : What can we do to get tophat and bowtie into testing? tophat: 1. tophat only Recommends: bowtie2 | bowtie or 2. tophat Architecture: amd64 kfreebsd-amd64 I think 1. is the better option Hi Andreas, In my understanding, it is not possible to run TopHat without Bowtie (version 1 or 2). Therefore, the “Depends” relationship is the most appropriate. Regarding the migration to Testing, it looks like both bowtie2 and bowtie must be installable to satisfy “bowtie2 | bowtie”, so we need to adapt ourselves to this constraint. Here are two possible solutions to the problem : 1. bowtie2 and bowtie provide a virtual “bowtie-aligner”, and tophat depends on “bowtie2 | bowtie-aligner”. 2. tophat depends on bowtie2 only. Given that bowtie and bowtie2 can be co-installed, and given that most users will want to use Bowtie 2 with TopHat, how about solution 2 ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758910: [pkg-eucalyptus-maintainers] Bug#758910: euca2ools: please update to euca2ools 3.1
Le Fri, Aug 22, 2014 at 02:12:08PM -0400, Scott Moser a écrit : Newest available version of euca2ools is 3.1.0. Hi Scott, I ran into a problem of backwards compatibility with 3.1.0, that I am currently reporting upstream; see the link below for details. http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/2014-July/001048.html Otherwise, the 3.1.0-1 package is ready for upload. I can upload it to experimental if it helps you. Have a nice week-end, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758124: Documenting the Testsuite field in the Policy.
Le Thu, Aug 14, 2014 at 09:36:50PM +0900, Charles Plessy a écrit : Here is a patch to update the Policy accordingly. Do you have comments ? On Tue, Aug 19, 2014 at 07:44:19AM +0900, Charles Plessy wrote: Anybody wanting to see the Testsuite field documented in the Policy, please raise your hand ! Le Tue, Aug 19, 2014 at 03:48:26PM +0200, Andreas Tille a écrit : Raise my hand ... but for what purpose? Is policy a matter of voting about it? BTW, if I remember correctly recent dpkg will add the field automatically so perhaps the documentation for the user might become less important (or am I wrong here)? Hi Andreas, changes to the Policy work by consensus, so if out of ~1,000 developers there is not a single one who supports a proposed change, then nothing will happen, because a wall of silence is a sign of reprobation. This is actually very efficient to make nothing happen. As to whether document or not this field, my personal opinion is that Policy's chapter 5, which documents most fields, should be comprehensive. But perhaps I over-value the Policy ? Still, I think that it is one asset that Debian has and other distributions do not. But yes, we can do without if we do not have the manpower to prevent it from bitrotting. Anybody Developer who thinks that 1) the Policy is useful and 2) the Testsuite field is useful, can participate. What is needed is to read the text below, verify that it reflects the facts, and if yes, send an email containing something like “seconded”. + headingttTestsuite/tt/heading + + p + Simple field containing a comma-separated list of values allowing + test execution environments to discover packages which provide + tests. Currently, the only defined value is ttautopkgtest/tt. + /p + + p + This field is automatically added to Debian source control files by + prgndpkg/prgnfootnotefrom version 1.17.11./footnote when + a filedebian/tests/control/file file is present in the source + package. This field may also be used in source package control + files if needed in other situations. + /p The whole process for changing the Policy is described in details at the URL below: https://wiki.debian.org/PolicyChangesProcess Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758124: Documenting the Testsuite field in the Policy.
Le Thu, Aug 14, 2014 at 09:36:50PM +0900, Charles Plessy a écrit : Package: debian-policy Version: 3.9.5 Severity: wishlist Hi Guillem and everybody, thanks for adding direct support for the Testsuite field in Dpkg. Here is a patch to update the Policy accordingly. Do you have comments ? Anybody wanting to see the Testsuite field documented in the Policy, please raise your hand ! Have a nice day, -- Charles diff --git a/policy.sgml b/policy.sgml index 6eac491..a8b27e2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2666,6 +2666,7 @@ Package: libc6 itemqref id=f-Standards-VersionttStandards-Version/tt/qref (recommended)/item itemqref id=f-HomepagettHomepage/tt/qref/item itemqref id=f-VCS-fieldsttVcs-Browser/tt, ttVcs-Git/tt, et al./qref/item + itemqref id=f-TestsuitettTestsuite/tt/qref/item /list /p @@ -2761,6 +2762,7 @@ Package: libc6 itemqref id=f-UploadersttUploaders/tt/qref/item itemqref id=f-HomepagettHomepage/tt/qref/item itemqref id=f-VCS-fieldsttVcs-Browser/tt, ttVcs-Git/tt, et al./qref/item + itemqref id=f-TestsuitettTestsuite/tt/qref/item itemqref id=f-DgitttDgit/tt/qref/item itemqref id=f-Standards-VersionttStandards-Version/tt/qref (recommended)/item itemqref id=sourcebinarydepsttBuild-Depends/tt et al/qref/item @@ -3863,6 +3865,24 @@ Checksums-Sha256: further details. /p /sect1 + + sect1 id=f-Testsuite + headingttTestsuite/tt/heading + + p + Simple field containing a comma-separated list of values allowing + test execution environments to discover packages which provide + tests. Currently, the only defined value is ttautopkgtest/tt. + /p + + p + This field is automatically added to Debian source control files by + prgndpkg/prgnfootnotefrom version 1.17.11./footnote when + a filedebian/tests/control/file file is present in the source + package. This field may also be used in source package control + files if needed in other situations. + /p + /sect1 /sect sect -- 2.0.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Le Fri, Aug 15, 2014 at 02:22:33PM -0300, Henrique de Moraes Holschuh a écrit : Am 15.08.2014 17:47, schrieb Gerrit Pape: That this rule is violated in hundreds of cases [1] clearly shows that there is something wrong which needs to be addressed in a more idiomatic way. Maybe update the policy text to match reality? Any packages depended upon by a higher priority package are, effectively, raised to that package's priority. Le Fri, Aug 15, 2014 at 06:17:32PM +0200, Ansgar Burchardt a écrit : I suggest to drop the following paragraph from 2.5: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. This requirement is not fulfilled by many packages and it doesn't seem to break anything. Having packages with priority = standard pull in libraries with lower priority seems also more useful than raising the priorities of the libraries as they alone do not satisfy the requirements for higher priorities: I don't think any library belongs to Important programs, including those which one would expect to find on any Unix-like system., yet we have many libraries with such priority in the archive. Hi Ansgar and everybody, there seems to be a consensus that the Policy should be updated, but there are two non-compatible proposals. Given that raising the priority of the packages needed by other high-priority packages is a work that would be done by the FTP Master team via overrides, mabye Ansgar or another member can give us a first-hand opinion on Henrique's proposition ? By the way, related to priorities, there is #196367 where it was proposed to document in the Policy that priorities are determined via overrides. Patches were submitted in 2003 and 2010. Is there a wording that you find more suitable ? - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196367#65 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196367#104 Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758124: Documenting the Testsuite field in the Policy.
Package: debian-policy Version: 3.9.5 Severity: wishlist Hi Guillem and everybody, thanks for adding direct support for the Testsuite field in Dpkg. Here is a patch to update the Policy accordingly. Do you have comments ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan From b2679f5e6e871c3316625d231ef88e5858d1b57c Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Thu, 14 Aug 2014 21:30:47 +0900 Subject: [PATCH] Document the Testsuite field. --- policy.sgml | 20 1 file changed, 20 insertions(+) diff --git a/policy.sgml b/policy.sgml index 6eac491..a8b27e2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2666,6 +2666,7 @@ Package: libc6 itemqref id=f-Standards-VersionttStandards-Version/tt/qref (recommended)/item itemqref id=f-HomepagettHomepage/tt/qref/item itemqref id=f-VCS-fieldsttVcs-Browser/tt, ttVcs-Git/tt, et al./qref/item + itemqref id=f-TestsuitettTestsuite/tt/qref/item /list /p @@ -2761,6 +2762,7 @@ Package: libc6 itemqref id=f-UploadersttUploaders/tt/qref/item itemqref id=f-HomepagettHomepage/tt/qref/item itemqref id=f-VCS-fieldsttVcs-Browser/tt, ttVcs-Git/tt, et al./qref/item + itemqref id=f-TestsuitettTestsuite/tt/qref/item itemqref id=f-DgitttDgit/tt/qref/item itemqref id=f-Standards-VersionttStandards-Version/tt/qref (recommended)/item itemqref id=sourcebinarydepsttBuild-Depends/tt et al/qref/item @@ -3863,6 +3865,24 @@ Checksums-Sha256: further details. /p /sect1 + + sect1 id=f-Testsuite + headingttTestsuite/tt/heading + + p + Simple field containing a comma-separated list of values allowing + test execution environments to discover packages which provide + tests. Currently, the only defined value is ttautopkgtest/tt. + /p + + p + This field is automatically added to Debian source control files by + prgndpkg/prgnfootnotefrom version 1.17.11./footnote when + a filedebian/tests/control/file file is present in the source + package. This field may also be used in source package control + files if needed in other situations. + /p + /sect1 /sect sect -- 2.0.1
Bug#756754: mime-support: Add support for application/x-xz mime type, ie xz files
Control: tag -1 pending Le Sun, Aug 03, 2014 at 05:34:31PM +0200, Diederik de Haas a écrit : On Saturday 02 August 2014 21:22:11 Charles Plessy wrote: perhaps you can contact (http://tukaani.org/contact.html) the upstream authors and ask them if they would like to submit a media type to the IANA ? I have just asked it and the upstream author added it to the to-do list, but also said it wasn't given a high priority, His estimate was that it'll probably have to wait till after 5.2 is out, so it could be (quite) a while (possibly years). I'll leave it up to the maintainers whether they want to patch the debian package until then .. or not. Hi Diederik, given that “application/x-xz” is specified in the upstream documentation, http://tukaani.org/xz/xz-file-format.txt, I will (reluctantly) add it to mime-support. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: Reintroducing FFmpeg to Debian
user debian-le...@lists.debian.org usertags 729203 one-copyright-review thanks Le Fri, Aug 08, 2014 at 01:53:15AM +0200, Andreas Cadhalpun a écrit : Now, could anyone review the debian/copyright file of ffmpeg? The sources are available in this repository: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git Hi Andreas, I searched for license information missing from your debian/copyright and could find only one case, libavutil/x86/x86inc.asm, which is under the ISC license. The debian/copyright file of your package looks comprehensive to me. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757281: [Debian-med-packaging] Bug#757281: dialign-t: FTBFS with clang instead of gcc
Dear Amarendran,
six year after my previous email to you, DIALIGN and DIALIGN-TX are still
distributed in Debian, where they have a stable user base as you can see from
the graph at the link below.
https://qa.debian.org/popcon-graph.php?packages=dialign-tx+dialignshow_vote=onwant_legend=onbeenhere=1
We run frequently quality tests over the whole Debian archive, and one of
them let to the production of a patch to compile DIALIGN-TX with Clang.
You can refer to the message below for details. A clean version of the
patch can be downloaded from the following link.
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=undef-ref.patch;att=1;bug=757281
Also, in a previous quality control run by a third party, some crashes were
found. You an see details at the following URL.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715816
Have a nice day,
-- Charles Plessy, Debian Med packaging team, Tsurumi, Kanagawa, Japan.
Le Wed, Aug 06, 2014 at 03:57:26PM -0500, Arthur Marble a écrit :
Package: dialign-t
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Detected this kind of error:
http://clang.debian.net/status.php?version=3.4.2key=UNDEF_REF
Full build log is available here:
http://clang.debian.net/logs/2014-06-16/dialign-t_1.0.2-6_unstable_clang.log
Thanks,
Arthur
-- System Information:
Debian Release: jessie/sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.5.0-+rc1-2 (tags/RELEASE_35/rc1) (based on
LLVM 3.5.0)
diff -Naur dialign-t.orig/dialign-t-1.0.2/debian/changelog
dialign-t/dialign-t-1.0.2/debian/changelog
--- dialign-t.orig/dialign-t-1.0.2/debian/changelog 2014-08-06
15:44:15.135034437 -0500
+++ dialign-t/dialign-t-1.0.2/debian/changelog2014-08-06
15:52:44.235043303 -0500
@@ -1,3 +1,13 @@
+dialign-t (1.0.2-7) unstable; urgency=low
+
+ * Fix FTBFS with clang
+- Fixed the undefined reference error in
+ source/alig.c
+ source/assemble.c
+ source/diag.c
+
+ -- Arthur Marble art...@info9.net Wed, 06 Aug 2014 15:52:44 -0500
+
dialign-t (1.0.2-6) unstable; urgency=medium
* debian/patches/consistent_declarations.patch: Make sure declarations
diff -Naur dialign-t.orig/dialign-t-1.0.2/debian/patches/clang-ftbfs.diff
dialign-t/dialign-t-1.0.2/debian/patches/clang-ftbfs.diff
--- dialign-t.orig/dialign-t-1.0.2/debian/patches/clang-ftbfs.diff
1969-12-31 18:00:00.0 -0600
+++ dialign-t/dialign-t-1.0.2/debian/patches/clang-ftbfs.diff 2014-08-06
15:51:34.219042084 -0500
@@ -0,0 +1,78 @@
+--- a/source/diag.c
b/source/diag.c
+@@ -183,7 +183,7 @@ void fill_tmp_pdist(struct prob_dist *pd
+ * omitScore = 0: normal
+ * omitScore = 1: no score calculation
+ */
+-inline void real_calc_weight(struct diag* dg, struct scr_matrix* smatrix,
++static inline void real_calc_weight(struct diag* dg, struct scr_matrix*
smatrix,
+ struct prob_dist *pdist, char omitScore, long double
**tmp_dist, struct alignment *algn ) {
+
+ if(dg-multi_dg) {
+@@ -302,7 +302,7 @@ inline void real_calc_weight(struct diag
+ }
+ }
+
+-inline void calc_weight(struct diag* dg, struct scr_matrix* smatrix,
++void calc_weight(struct diag* dg, struct scr_matrix* smatrix,
+ struct prob_dist *pdist) {
+ real_calc_weight(dg, smatrix, pdist, 0,NULL,NULL);
+ }
+@@ -312,7 +312,7 @@ inline void calc_weight(struct diag* dg,
+ /**
+ * calculates the overlap weight for the given diag
+ */
+-inline void calc_ov_weight(struct diag* dg, struct diag_col *dcol, struct
scr_matrix* smatrix,
++static inline void calc_ov_weight(struct diag* dg, struct diag_col *dcol,
struct scr_matrix* smatrix,
+ struct prob_dist *pdist) {
+ int sn1 = dg-seq_p1.num;
+ int sn2 = dg-seq_p2.num;
+@@ -958,7 +958,7 @@ inline struct simple_diag_col* find_diag
+ * The pointer returned (and the ones included in the struct)
+ * has to be deallocted explicitely from memory.
+ */
+-inline struct simple_diag_col* find_diags_dialign(struct scr_matrix
*smatrix,
++static inline struct simple_diag_col* find_diags_dialign(struct scr_matrix
*smatrix,
+ struct prob_dist *pdist, struct seq* seq1,
+ struct seq* seq2, struct alignment *algn,
+ long double **tmp_dist, int round) {
+--- a/source/assemble.c
b/source/assemble.c
+@@ -10,7 +10,7 @@
+
+ extern void error(char *message);
+ extern void merror(char *msg1, char *msg2);
+-extern inline void calc_weight(struct diag* dg, struct scr_matrix* smatrix,
++extern void calc_weight(struct diag* dg, struct
Bug#756835: First steps towards source-only uploads
Control: retitle -1 Extension of the syntax of the Packages-List field. Le Wed, Aug 06, 2014 at 07:16:37AM +0200, Johannes Schauer a écrit : The field started out with the binary package name, type, section and priority. For bootstrapping it is necessary to know for which architectures and build profiles a binary package builds without having access to the unpacked source package but just from looking at the Packages/Sources files. Thus this information was added as optional fields. Every field that comes after the first four will be of the form key=value. The arch information will always be printed and the profile field only for a build with a build profile. Guillem explains the new field here: Hi Johannes, Ansgar, Guillem, and everybody, what do you think about the patch I sent to the Policy, for describing the syntax of the current optional fields of the Packages-List field ? Do you think that modifications are needed ? Would you second it ? https://bugs.debian.org/756835 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756574: lintian: Please consider removing the tag license-problem-gfdl-non-official-text.
Le Thu, Jul 31, 2014 at 10:59:23AM +0200, Bastien ROUCARIES a écrit : On Thu, Jul 31, 2014 at 4:33 AM, Charles Plessy ple...@debian.org wrote: For one of them, license-problem-gfdl-non-official-text, I have strong doubts if it will ever be useful. In my understanding from the statistics from the Lintian website, hundreds if not thousands of upstream authors would need to be convinced to uppercase their GFDL statements. I think that it will never happen fully. Dear Charles, the matching is case insensitive, so case is not important for this tag (it will not fire if the case is only changes). If it is not clear, could you suggest more appropriate warning? For that reason, please remove the tag license-problem-gfdl-non-official-text, which is distracting and has no chances to have a significant effect. It is important for me as lintian developper. For each different wording I need to add a regex in lintian to check if it is really a free gfdl. And moreover it help to catch spelling mistake. I could add this tag is mainly for lintian developper if needed. Hi Bastien, first, indeed, I misunderstood the long description, which I thought was advocating case-only changes. Sorry for this. Looking for typos and confusing rephrasings is good after reading the long description again, I find it clear. This said, I have the impression that this Lintian tag is often triggered with a very frequent variation: with no invariant sections, with no front-cover texts, and with no back-cover texts This variation is found in a large number of GNU packages, which makes me wonder if it comes from a template, perhaps from the Texinfo system, see: http://www.gnu.org/software/texinfo/manual/texinfo/html_node/GNU-Sample-Texts.html Can you whitelist this variation ? If GNU packages use it by default, it is hard to consider it “non-official”. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756835: First steps towards source-only uploads
Package: debian-policy Severity: wishlist Version: 3.9.5.0 Le Fri, Aug 01, 2014 at 12:25:05PM +0200, Ansgar Burchardt a écrit : On 08/01/2014 12:17, martin f krafft wrote: also sprach Paul Wise p...@debian.org [2014-08-01 11:33 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. Hi Ansgar, Martin, and Policy Editors, here is a proposed update for the description of the Package-List field in the Policy's section 5.6.27. (patch attached). For the busy people, here is the current content of §5.6.27–8. - 5.6.27 Package-List Multiline field listing all the packages that can be built from the source package, considering every architecture. The first line of the field value is empty. Each one of the next lines describes one binary package, by listing its name, type, section and priority separated by spaces. Fifth and subsequent space-separated items may be present and parsers must allow them. See the Package-Type field for a list of package types. 5.6.28 Package-Type Simple field containing a word indicating the type of package: deb for binary packages and udeb for micro binary packages. Other types not defined here may be indicated. In source package control files, the Package-Type field should be omitted instead of giving it a value of deb, as this value is assumed for paragraphs lacking this field. - Everybody's suggestions are welcome ! Have a nice week-end, and big thank you to Ansgar and the other FTP Masters for the source-only uploads ! -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan From b1aa1bf72723e4594557f9898da97afe23f0c900 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sat, 2 Aug 2014 19:30:57 +0900 Subject: [PATCH] =?UTF-8?q?Document=20the=20=E2=80=98arch=E2=80=99=20and?= =?UTF-8?q?=20=E2=80=98profile=E2=80=99=20options=20in=20the=20Package-Lis?= =?UTF-8?q?t=20field.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- policy.sgml | 8 1 file changed, 8 insertions(+) diff --git a/policy.sgml b/policy.sgml index ae9d173..33c4f1a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3826,6 +3826,14 @@ Checksums-Sha256: qref id=f-Package-TypePackage-Type/qref field for a list of package types. /p + p + The optional fields currently in use add informations related to +architectures build profiles, with a syntax such as +ttname=value1,value2/tt and names ttarch/tt and +ttprofile/ttfootnote + They were introduced in prgndpkg/prgn version + tt1.17.7/tt in emJessie/em/footnote. + /p /sect1 sect1 id=f-Package-Type -- 2.0.1
Bug#756754: mime-support: Add support for application/x-xz mime type, ie xz files
Le Fri, Aug 01, 2014 at 01:37:12PM +0200, Diederik de Haas a écrit : According to http://filext.com/file-extension/XZ the mime type for xz files is application/x-xz. Unfortunately the mime type doesn't seem registered (yet) with iana according to http://www.iana.org/assignments/media-types/media-types.xhtml#application I tried to read through the document about registering a new mime type, but got lost pretty quickly. Sorry. Hello Diederik, perhaps you can contact (http://tukaani.org/contact.html) the upstream authors and ask them if they would like to submit a media type to the IANA ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756708: mime-support: /usr/bin/edit should point to /etc/alternatives/editor
Control: tag -1 unreproducible Le Fri, Aug 01, 2014 at 12:48:27AM +0200, Kai-Martin Knaak a écrit : the package mime-supports installs /usr/bin/edit as a symlink to /usr/bin/run-mailcap . However, in many cases this does not open the the application most probably desired by the user. E.g.: $ edit foobar.html would open the sensible www-browser, most likely iceweasel. The expected behaviour would be to open an editor instead. Hello, on my system, the ‘edit’ command does the right thing. Can you run it on your system with the ‘--debug’ option ? $ edit --debug toto.html - parsing parameter toto.html - Reading mime.types file /home/charles/.mime.types... could not read /home/charles/.mime.types -- Aucun fichier ou dossier de ce type - Reading mime.types file /usr/local/etc/mime.types... could not read /usr/local/etc/mime.types -- Aucun fichier ou dossier de ce type - Reading mime.types file /usr/share/etc/mime.types... could not read /usr/share/etc/mime.types -- Aucun fichier ou dossier de ce type - Reading mime.types file /etc/mime.types... - extension html maps to mime-type text/html - Reading mailcap file /home/charles/.mailcap... could not read /home/charles/.mailcap -- Aucun fichier ou dossier de ce type - Reading mailcap file /etc/mailcap... - Reading mailcap file /usr/local/etc/mailcap... could not read /usr/local/etc/mailcap -- Aucun fichier ou dossier de ce type - Reading mailcap file /usr/share/etc/mailcap... could not read /usr/share/etc/mailcap -- Aucun fichier ou dossier de ce type - Reading mailcap file /usr/etc/mailcap... could not read /usr/etc/mailcap -- Aucun fichier ou dossier de ce type Processing file toto.html of type text/html (encoding=none)... - checking mailcap entry text/*; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; needsterminal - program to execute: vim %s - needsterminal is satisfied by stdout - running test: test -x /usr/bin/vim (result=0=true) - executing: vim toto.html $ file toto.html toto.html: HTML document, ASCII text Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756721: tracker.debian.org: Please use same font size as in the PTS.
Package: tracker.debian.org Severity: normal Hello everybody, first of all, thanks a lot for setting up tracker.debian.org. It is exciting to see all the nice cooperative work taking place now. The new package tracker uses a font that is smaller than in the PTS, while at the same time taking more vertical space than the PTS. As a result, I find the text painful to read when it is not just isolated words or numbers, and if I increase font size the information gets scattered on a significantly wider area than in the PTS. Needless to say, I wear glasses that give me a good correction, but can not reach 100 % on one of my eyes. I guess that for many persons the font size is not a problem. Nevertheless, please consider increasing font size and compensating by reducing the vertical intervals between lines. Many thanks again, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756574: lintian: Please consider removing the tag license-problem-gfdl-non-official-text.
Package: lintian Version: 2.5.25 Severity: minor Dear Lintian maintainers, thanks for your work on Lintian. I use it a lot, including the pedantic tags. For one of them, license-problem-gfdl-non-official-text, I have strong doubts if it will ever be useful. In my understanding from the statistics from the Lintian website, hundreds if not thousands of upstream authors would need to be convinced to uppercase their GFDL statements. I think that it will never happen fully. For that reason, please remove the tag license-problem-gfdl-non-official-text, which is distracting and has no chances to have a significant effect. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755886: RM: bedtools [armel] -- ROM; Build-dep unavailable
Package: ftp.debian.org Severity: normal Dear FTP team, please remove bedtools on armel. It build-depends on samtools, which does not build on armel. This problem prevents migration of the latest version of bedtools to Jessie. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
