Help needed on providing the en_US locale in autopkgtests
Hello,
we have a package, r-cran-dplyr, that runs the upstream test suite as
part of its autopkgtests. Unfortunately it fails when it tries to set
the en_US locale to test support of non-UTF locales; maybe it is not
available in the default environment of debci? Do people know a way to
make en_US available in that context?
https://ci.debian.net/packages/r/r-cran-dplyr/unstable/amd64/53464906/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072630
More details follow.
On line 325 of the package's `tests/testthat/test-arrange.R` there is:
skip_if_not(has_collate_locale("en_US"), message = "Can't use 'en_US'
locale")
This leads to the emission of the warning "Can't use 'en_US' locale",
which causes autopkgtest to fail.
I am aware of two possible solutions that I would like to avoid:
1) Patch the test suite so that it does not run that test.
2) Allow autopkgtest to ignore warnings.
Both of them equate to put dust in the corner and run only the tests
that are the least likely to fail, which puts into question why we would
run upstream tests at all.
So if you know a good way to enable debci to provide the needed locale
to debci, please let me know.
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian R packaging team https://wiki.debian.org/Teams/r-pkg-team
Tooting from home https://framapiaf.org/@charles_plessy
- You do not have my permission to use this email to train an AI -
How to handle conffiles when renaming or splitting a package?
Hello everybody,
and happy new year !
I have recently split the mime-support package in two: media-types and
mailcap. But I wonder if I handled the conffiles correctly.
mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
package containing only a changelog and a copyright file, and depends on
media-types and mailcap. And these two packages declare a Breaks and
Replaces relationship against mime-support << 3.65.
As a result of the upgrade, the conffiles are now owned by the new
packages. But dpkg still keeps a record that the mime-support has
the "obsolete" version of them:
# dpkg-query -W -f='${Conffiles}\n' media-types
/etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530 /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n' mailcap
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n' mime-support
/etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
I have received reports from users who consider this a problem. Indeed,
in the case of mailcap it is potentially confusing as the conffile's MD5
sum has not changed.
On the other hand, once mime-support is purged, which is how
transitionnal packages eventually should be handled, the situation is
clean. So I am not sure if there is a problem here.
Is it needed to clean dpkg's database so that it does not report
obsolete conffiles for mime-support? (Actually, I would have expected
dpkg to do this automagically given the Breaks and Replaces
relationship.)
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work, https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy
Re: How to manage CPU-specific features in package ?
Le Sat, Apr 25, 2020 at 02:53:51PM -0400, Aaron Boxer a écrit : > > My library can use SIMD vector operations such as AVX2 if available on > system. > What is the best way of managing this ? Hello, maybe you can have a look at how other packages use `libsimde-dev`? https://wiki.debian.org/SIMDEverywhere Have a nice Sunday Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Riddled by debian-policy 8.1.1 about ldconfig
Le Thu, Sep 14, 2017 at 02:25:41PM +0200, Thomas Schmitt a écrit : > What is meant by "DEBIAN/triggers" in policy manual and man 5 deb-triggers ? > Is there supposed to be a "DEBIAN" directory under ./debian ? Hi Thomas, the `DEBIAN` directory is created in the process of building in binary packages. In the binary packages themselves, its contents become the contents of the `control.tar.gz` member. For a package "p", the file DEBIAN/triggers is installed in `/var/lib/dpkg/info/p.triggers`. You can find many real examples there. In particular, for libraries complying with the Policy, you will see that this file indeed "activate-noawait" the "ldconfig" trigger. For packages built using Debhelper, the triggers files is added by `dh_makeshlibs`, which explains why you can not see traces of it in the clean source package. I hope it clarifies. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: installing GUI launchers and mimes
Le Sun, Jul 30, 2017 at 11:55:20AM +0200, Narcis Garcia a écrit : > > Do you mean that with only having at the package: > ./usr/share/applications/xxx.desktop > ./usr/share/mime/packages/xxx.xml > triggers are automatically run? Hello Narcis, yes they will: $ grep usr/share/applications /var/lib/dpkg/triggers/File /usr/share/applications mime-support/noawait /usr/share/applications desktop-file-utils /usr/share/applications gnome-menus/noawait $ grep usr/share/mime/packages /var/lib/dpkg/triggers/File /usr/share/mime/packages shared-mime-info See /usr/share/doc/dpkg-dev/triggers.txt.gz for (a lot of) details. > Why transmission-gtk/postinst calls update-menus and update-mime ? Is it > some kind of compatibility measure? The short answer is: "because transmission-gtk/postinst is generated by debhelper fia dh_installmenu". $ cat /var/lib/dpkg/info/transmission-gtk.postinst #!/bin/sh set -e # Automatically added by dh_installmenu if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then update-menus fi I am not sure why this is still needed while there is already a dpkg trigger doing the work. Anyway, as noted elsewhere, the Debian menu system is being phased out. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: How to deal with arch-specific paths in .install files
Le Wed, May 03, 2017 at 11:36:01AM -0700, Shawn Sörbom a écrit : > > I have a package .install file where a library expects to go into /usr/lib/ > x86_64-gnu/[subdirectory] on amd64 systems. I realize this is not portable. > What regex can I use to substitute for the arch directory in my .install file? Hi Shawn, you can find an answer (and many alternatives) in the following wiki page: https://wiki.debian.org/Multiarch/Implementation Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Best GPG practices before sending computer to maintenance.
Hello everybody, the laptop that I use mainly for Debian development will go to hardware maintainance tomorrow. I will of course remove my .gnupg folder, but out of curiosity I wonder if there are better practices. The mass storage is a SSD that I am not going to remove it before sending the laptop. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: Review of firefox-branding-iceweasel
Le Tue, Apr 19, 2016 at 01:46:46PM -0700, Sean Whitton a écrit : > > "Every package must be accompanied by a verbatim copy of its copyright > information and distribution license in the file > /usr/share/doc/package/copyright." > > It then makes an *exception* to this verbatim rule: > > "Packages distributed under the Apache license (version 2.0), the > Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL > (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should > refer to the corresponding files under /usr/share/common-licenses, > rather than quoting them in the copyright file." > > Since you are not using /usr/share/common-licenses, your package doesn't > fall under this exception and so you need to include it in your > d/copyright file. Hi all, actually, the MPL-2 will be added to /user/share/common-licenses when a Policy Editor will find time to make it happen. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768292 So I suggest that it is fine to be forward-compatible with the future Policy :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Git-buildpackage question: tracking upstream git and tarballs
Le Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi a écrit : > > If I understand [1] and [2] correctly, one would need two upstream > branches : one originating from upstream, with the full commit history, > and one managed by gbp import-orig, which would contain upstream sources > imported as single tarballs commits. > > [1] http://www.eyrie.org/~eagle/notes/debian/git.html#combine > [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html > > I don't understand the reason for having two separate upstream branches. > Is there a specific reason against having a single upstream branch, > which would contain the full upstream commit history, and maintaining > the pristine-tar branch with a plain old "pristine-tar commit > " (since gbp import-orig would want to import the > tarball files and create a new tag, which both may conflict with the > upstream branch/tags) ? Hi Raphaël, if in your case it works well to pull updates directly from Upstream's repository and to use downloaded tarballs from the upstream website, then there is no problem to use pristine-tar directly instead of gbp import-orig, as you suggested. (The answer from Ferenc explains well why in some cases there can be problems caused by differences between the upstream repository and the upstream tarballs). If you do this and intend to make your source package's repository easy to use for collaborative maintenance, it will be good to document this workflow somewhere (perhaps README.source ?) since it is not standard. Otherwise, people may run gbp import-orig and waste time wondering why it did not work as expected. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: git-buildpackage pattern question
Le Mon, Mar 21, 2016 at 06:43:58PM -0700, Sean Whitton a écrit : > > In my usage of git-buildpackage, I've been using a different approach to > that suggested by Russ and I thought it might be useful to share it in > this thread. > > I think of (local) branches as things that I expect to make commits to, > and use tags to keep track of work done by upstream that is read-only > from my point of view. So in my repository I have all of upstreams tags > (1.0.0, 1.1.0, 1.0.2 etc.) and a master branch which contains both > upstream's code and my debian/ directory. There is no upstream branch. Hi Sean, not to nitpick your workflow itself, but I was wondering: with your approach, what is the advantage using git-buildpackage instead of simply `dpkg-buildpackage -i -I` ? For the sake of curiosity (and sorry to sidetrack the thread), what `gbp` commands are you still using in your workflow ? Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
[OT] Re: user want messages removed from mailing list
Le Wed, Nov 18, 2015 at 02:18:04PM +0100, Jakub Wilk a écrit : > > Reporting non-spam messages as spam is counter-productive. It won't help the > message disappear. But it will help actual spam messages to survive in our > archives. Hi Jakub, there are definitely precedents were messages containing private information that the poster did not want to send or regrets to have sent have been removed with the spam-removal interface. And I fail to see how it helps actual spam messages to stay, unless you are suggesting that by using the spam removal system for these purpose we will undermine it by demotivating or drain time from the people who use it for spam removal only, or that we will cause it to be more strongly moderated. I understand that listmasters do not have time to handle removal requests, but I think that we are being arrogant when we refuse for technical reasons. Especially with the trap situation that people tend to send removal requests to the debian-www address without knowing that it is also a publically archived mailing list. Some times I have the impression that our only answer is just shaming the requester. Anyway; there is not much to discuss. When I reads these requests, I tend to mark the message as spam. And sometimes it works. Cheers, -- Charles
Re: user want messages removed from mailing list
Le Mon, Nov 16, 2015 at 09:49:51PM +0800, Alex Vong a écrit : > > A user says he wasn't aware that the mailing list is public and want > his conversion with me and another person removed. I have replied to > him stating that the mailing list is like a public forum, everyone can > read it. He hasn't replied yet. But if he insisted on having the > conversation removed, what should I do? Hi Alex, You can mark it as spam and cross fingers that other people do the same and the spam cleaners (everybody's help is welcome by the way) feel compassion. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: cowbuilder/pbuilder: require newer version from experimental
Le Tue, Oct 27, 2015 at 03:11:08PM +0100, Ole Streicher a écrit : > > to build an "experimental" version of one of my packages, I need to > specify a package that is in unstable (1.0.5-1) and in experimental > (1.1~b1-1), and I need the experimental version here. Hi Ole, this is a bit off-topic answer, but if you use sbuild --build-dep-resolver=aptitude, you should be able to satisfy the dependency on the package in experimental. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Best practices for downloader packages
Le Tue, Aug 18, 2015 at 03:47:13PM +0200, Ole Streicher a écrit : > > After lunch, someone pointed out that the policy only requires that > packages that download *software* need to go to contrib. Since my one > would download *data* only, it would be probably suitable for main. Hi Ole, I doubt that the intention of the policy is to distinguish data and software here. Also, the current interpretation of the DFSG is that data is software. Altogether, in the case of your package, I think that it is a matter of taste. In my point of view, there is nothing wrong putting it in contrib, to represent that the access to the data is not as easy as if it were distributed inside the package. One of the points of Free software is that is can not be taken away from the user, and if one has a full copy of the Debian archive, it is possible to rely on all the programs and data in the main section. For downloader packages, however, they can become useless at any time, and the user has no control over this. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: doc-base for more than one document
Le Fri, Jun 19, 2015 at 04:26:58PM +0200, Ole Streicher a écrit : > > I am a bit confused on how I can register more than one document for one > package. Hi Ole, one file per document; see the emboss package for instance. 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-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150620062414.gc19...@falafel.plessy.net
Re: Not able to pull dependencies for tests ran on ci.debian.net.
Le Tue, Jun 16, 2015 at 01:52:52PM +0200, Dominique Dumont a écrit : > > from the logs, tabix package is not installed. > > Neither samtools or samtools-test depends on tabix. > > Looks like ci does not install build dependencies... Thanks Dominique, but I would have expected tabix to be installed because the file debian/tests/control declares “Depends: @, tabix”. Am I misunderstanding how this control file is used ? Cheers, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150617082105.ga...@falafel.plessy.net
Not able to pull dependencies for tests ran on ci.debian.net.
Good evening everybody,
I am probably missing something obvious, but I have simple problem with the
samtools package, where the regression tests depend on the "tabix" package for
the "bgzip" command, and fail on ci.debian.net despite my attempt to set the
dependency properly...
$ curl
http://anonscm.debian.org/cgit/debian-med/samtools.git/plain/debian/tests/control
Tests: samtools-test
Depends: @, tabix
Restrictions: allow-stderr
$ curl --silent --compressed
http://ci.debian.net/data/packages/unstable/amd64/s/samtools/20150607_002702.autopkgtest.log.gz
| tail -n15
Setting up samtools-test (1.1-1) ...
Setting up adt-satdep (0) ...
Processing triggers for libc-bin (2.19-18) ...
adt-run [00:27:23]: test samtools-test: [---
The command failed [32512]: cat /tmp/YHnFtIRjxI/bgzip.dat | bgzip -ci
-I/tmp/YHnFtIRjxI/bgzip.dat.gz.gzi > /tmp/YHnFtIRjxI/bgzip.dat.gz
out:
err:/bin/bash: bgzip: command not found
at ./test.pl line 67.
main::error("The command failed [32512]: cat /tmp/YHnFtIRjxI/bgzip.dat
| b"..., "out:\x{a}", "err:/bin/bash: bgzip: command not found\x{a}\x{a}")
called at ./test.pl line 138
main::cmd("cat /tmp/YHnFtIRjxI/bgzip.dat | bgzip -ci
-I/tmp/YHnFtIRjxI/b"...) called at ./test.pl line 300
main::test_bgzip(HASH(0x1951e78)) called at ./test.pl line 35
adt-run [00:27:24]: test samtools-test: ---]
adt-run [00:27:24]: test samtools-test: - - - - - - - - - - results - - -
- - - - - - -
samtools-testFAIL non-zero exit status 127
Does anybody spot what I have been missing ?
Have a nice day
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015061657.ga19...@falafel.plessy.net
Re: not installed and installed , where they store?
Le Sat, May 09, 2015 at 11:17:40PM -0700, Tom Lee a écrit : > Try this too if virtualbox is the specific package you're interested in: > > $ grep -A 3 "^Package: virtualbox\$" /var/lib/dpkg/status > Package: virtualbox > Status: install ok installed > Priority: optional > Section: contrib/misc Hello everybody, by the way, for such queries, there is also the command "grep-status" in the package dctrl-tools. $ grep-status -Fpackage dctrl-tools -sPackage,Status Package: dctrl-tools Status: install ok installed Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150510112738.gg22...@falafel.plessy.net
Re: dep5-copyright-license-name-not-unique
Le Tue, Mar 03, 2015 at 03:59:31PM +0100, Helge Kreutzmann a écrit : > Hello, > I recently got lots of errors for the debian/copyright files of my two > packages using the machine style copyright. > > The expanded version states "This paragraph define an already defined > license.", however the paragraphs I checked only use GPL-2+. Hello Helge, I think that the lintian tag is either too strict or too severe, given that the machine-readable format permits to repeat the long description in multiple Files paragraphs. I opened https://bugs.debian.org/779676 about this. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150303222139.ga14...@falafel.plessy.net
Re: launchpad for debian and autobuilders
Le Fri, Dec 12, 2014 at 09:15:44AM +0100, Leopold Palomo-Avellaneda a écrit : > > I build my packages with pbuilder, but I'm looking for an automatic place to > build packages for debian. Dear Leopold, how about Elida ? https://packages.debian.org/sid/elida Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212082034.gi3...@falafel.plessy.net
Re: Install files based on architecture?
Le Sat, Sep 27, 2014 at 06:55:03PM +0800, Bamm a écrit : > > Is it possible for the debian/install file to install a file based on > architecture? Perhaps something like this? > > bin/$arch/* usr/bin > > Where $arch is either i386 or amd64? Hello Bamm, you can have a look at dh-exec and how it is used in the particular case of multi-architecture packages. https://wiki.debian.org/Multiarch/Implementation But as Paul noted, wildcards are enough as long as you do not need $arch to be in the target. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927113459.gc2...@falafel.plessy.net
Re: Samtools fails to build on several architectures [nore...@buildd.debian.org: failed i386 build of samtools 1.0-1]
Le Tue, Sep 23, 2014 at 02:44:16PM +0200, Jakub Wilk a écrit :
>
> "samtools stats" displays help, but only if stdin is a terminal. If
> it is not, it'll read data from it:
>
>if ( !bam_fname )
>{
>if ( isatty(STDIN_FILENO) )
>error(NULL);
>bam_fname = "-";
>}
Brilliant, many thanks !
The issue was then quickly solved upstream.
https://github.com/samtools/samtools/issues/300
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925000902.ga2...@falafel.plessy.net
Re: [Debian-med-packaging] Bug#751255: Help needed for wxWidgets 3.0 transition of TreeviewX
Le Sun, Aug 10, 2014 at 07:27:35PM +0200, Andreas Tille a écrit : > On Sun, Aug 10, 2014 at 02:06:42PM +0200, Martin Steghöfer wrote: > > ... > > The attached patch should fix it. I removed the dangerous fall-back > > definition (that does more harm than good) and replaced the > > constructor calls (in which the definition was used) by the > > appropriate constructor calls. > > Thanks a lot - the example works now and I have uploaded the package. Many thanks, Martin ! I forwarded your patch on the upstream issue tracker, so that others may benefit from it. http://code.google.com/p/treeviewx/issues/detail?id=4 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-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817124139.gd2...@falafel.plessy.net
Re: Packaging from upstream's Git repository.
Dear Yukiharu and Jeremy, thanks for your answers. Yes, I know about git-buildpakcage and will use it in last ressort. There are multiple reasons why I prefer to base my packages on the upstream Git repository when it exists. First, in my experience, this tremendously eases the exchange of patches between us and upstream. Second, some upstreams start to prefer releasing tags instead of tarballs, especially for release candidates. Lastly, the Git repository is the source, while some files in the tarball are autogenerated. While we have a long-standing tolerance for some kind of autogenerated files, I think that it is preferable to use the source directly. So, are there other suggestions ? Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713044722.gg12...@falafel.plessy.net
Packaging from upstream's Git repository.
Hello everybody, I am trying to package the new 'datamash' tool. http://www.gnu.org/software/datamash/ I am currently in contact with the upstream author about how to make the Debian source package. I would prefer to propose him a solution where the sources used by Debian are directly his Git repository, intead of using git-import-orig to import tarballs made by ‘make distcheck’, since the first solution obviously enhances the possibility to exchange patches. I am blocking on the fact that he uses gnulib in a way that the version number of his program is expressed only via a Git tag. Thus, given that Debian source package are based on tar archives, the version number is lost unless I use the “sources” produced by ‘make distcheck’. Does anybody know a simple solution to that problem ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712044552.ge12...@falafel.plessy.net
Re: Licensing question
Le Fri, Jul 11, 2014 at 11:21:24AM -0400, Paul Tagliamonte a écrit : > > I'll of course defer to Charles' ability to understand french, so > working from the English translation (which is to say, I might be > missing something), I don't see the same issues he does. > > Both the ISC and MIT/Expat license don't explicitly allow distribution > of modified works, but it's pretty implicit: Hi all, the essence of my conclusion in 2012 was: “in doubt, ask Upstream”. Sorry that it was not clear. Also, if after reading the email of Jonathan Keller in the same thread you still have no doubts, go ahead with your conclusion; the worst case scenario is only to have to remove the packages from our Project's main archive later. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711231753.ga12...@falafel.plessy.net
Re: Help for watch file needed
Le Sun, Jun 29, 2014 at 11:43:47AM +0200, Andreas Tille a écrit : > > At first I do not understand why uversionmangle=s/\./-/g does not work: > > $ uscan --verbose --report > -- Scanning for watchfiles in . > -- Found watchfile in ./debian > -- In debian/watch, processing watchfile line: >opts=uversionmangle=s/\./-/g > http://thegrantlab.org/bio3d/download/download-bucket .*bio3d-v([-.0-9]+) > -- Found the following matching hrefs: > /bio3d/download/download-bucket?download=1:bio3d-v2-0-1 (2-0-1) > /bio3d/download/download-bucket?download=1:bio3d-v2-0-1 (2-0-1) > Newest version on remote site is 2-0-1, local version is 2.0-1 > => remote site does not even have current version > -- Scan finished Hi Andreas, shouldn't it be s/-/./g instead ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140629095848.ga22...@falafel.plessy.net
Re: script-with-language-extension
Le Mon, Mar 10, 2014 at 03:19:51PM +0800, Thomas Goirand a écrit : > On 03/10/2014 04:49 AM, Salvo Tomaselli wrote: > > Not sure if fixing it by renaming the files is what you want to do. > > > > I have such a warning in xinetd and honestly I just ignore it because I > > don't > > think that renaming scripts after they have been there for many years is a > > good idea. Besides that's the upstream name so that's how they will be > > probably called in other distributions too I guess. > > The Debian policy manual don't agree with you, AFAIR. Hi Thomas, This is very unfortunate. I have ashamed myself sending scripts to colleagues that did not work on their platform, just because I developed them on Debian, which "corrects" file names unilaterally. I would prefer my colleagues to know Debian for being rock solid and secure, rather than know it for being incompatible by design with the rest of the Unix world. Cheers, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310072711.gc9...@falafel.plessy.net
How to selectively silence git-multimail messages ?
Le Sat, Jan 25, 2014 at 10:55:16AM +0800, Paul Wise a écrit : > The news are collected on http://wiki.debian.org/DeveloperNews > > Email notifications for git commits on git.debian.org > - […] > -- Raphaël Hertzog > > [1] http://wiki.debian.org/Alioth/Git#Commit_mails_with_diff > [2] https://github.com/mhagger/git-multimail/ This was an excellent improvement, many thanks to Raphaël for this. Sometimes, I can guess in advance that a push will generate a flood of emails that will not be very relevant at best and annoying at worse on my packaging team's mailing list. For instance, merges from upstream's master branch, with hundreds of commits that do not change the contents of the debian directory. Sometimes, to avoid them, I log on Alioth and disable temporarly the commit hook. Would anybody be able to improve the system so that, when pushing with the --quiet option, the individual emails for each commits will be skipped ? Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125053149.gh24...@falafel.plessy.net
Re: (uscan) Files-Excluded mecanism documentation ?
Le Thu, Dec 12, 2013 at 04:38:20PM +0100, Andreas Tille a écrit : > > > > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > > > > with no luck so far. > > I received the answer from DEP5 drivers that this format (version 1.0) > will not be changed. Hi Andreas, The DEP 5 work is finished, and I think that its' drivers opinion on the contents of http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ does not have more weight than the one of other developers, including yours. This said, I think that going for a 1.1 update is the best solution. It is hard to say how long it will take, but in theory, it can be as fast as providing a patch to #685506, have it accepted, and upload an updated debian-policy package. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213005921.ga25...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Fri, Nov 22, 2013 at 09:31:25AM +0100, Andreas Tille a écrit : > On Fri, Nov 22, 2013 at 09:10:44AM +0100, Raphael Hertzog wrote: > > > > On Fri, 22 Nov 2013, Andreas Tille wrote: > > > $ gbp-clone ssh://git.debian.org/git/debian-med/htslib.git > > > $ cd htslib > > > (debian/unstable) $ git branch > > > * debian/unstable > > > develop > > > pristine-tar > > > (debian/unstable) $ git-buildpackage > > > (debian/unstable) $ lintian -I --pedantic > > > ../build-area/htslib_0.2.0~rc4-1_amd64.changes > > > > The mere fact that the generated files are in ../build-area/ means that > > you're using --git-export-dir (via ~/.gbp.conf) and thus you are building > > in a directory that doesn't have the .git dir. It's an export (with > > git archive) that is unpacked in ../build-area// that you use as > > build directory. > > Well, that's correct. So trying again: > > $ cd .. > $ ln -s build-area/htslib_0.2.0~rc4.orig.tar.gz > $ cd htslib > (debian/unstable) $ pdebuild Hi Andreas, I suspect that pdebuild is also using either an export or an unpacked source package. I think that if you use dpkg-buildpackage directly, you will reproduce the problem. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131122090851.gi16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Thu, Nov 21, 2013 at 11:26:24AM +0100, Andreas Tille a écrit : > On Thu, Nov 21, 2013 at 05:29:26PM +0900, Charles Plessy wrote: > > > > gbp clone git.debian.org:/git/debian-med/htslib.git > > When doing `git-buildpackage` (which for sure includes the .git dir) I > can not see the effect you are describing. The only thing lintian (and > I) are more concerned about is: > > E: libhts0: symbols-file-contains-current-version-with-debian-revision on > symbol cram_index_build@Base > W: libhts0: symbols-file-contains-debian-revision on symbol > bam_mplp_init_overlaps@Base and 1 others > > I personally would simply drop the symbols file since it seems to > introduce more harm than good. Hi Andreas, this is strange, in my case, from a fresh clone, and when building with "git buildpackage -us -uc", I see the hardening-no-relro tag. $ lintian -I --pedantic ../htslib_0.2.0~rc4-1_amd64.changes I: htslib source: quilt-patch-using-template-description debian-changes W: htslib source: newer-standards-version 3.9.5 (current is 3.9.4) W: libhts0: hardening-no-relro usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 P: libhts0: no-upstream-changelog E: libhts0: symbols-file-contains-current-version-with-debian-revision on symbol cram_index_build@Base W: libhts0: symbols-file-contains-debian-revision on symbol bam_mplp_init_overlaps@Base and 1 others P: libhts-dev: no-upstream-changelog W: libhts-dev: manpage-has-errors-from-man usr/share/man/man5/vcf.5.gz file `', around line 15: P: htslib-test: no-upstream-changelog For the tags related to the symbols file, this is because the package is work in progress. I pull upsteam commits as they go and only update the version number when upstream makes new tags, therefore Debian revisions contain changes to the library's symbols. Given that the API is not yet stable, I understand that the symbols file is not yet useful, but I prefer having it in the package now so that I do not forget to add it when I start to upload packages built on the htslib-dev package. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131122052333.gh16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Thu, Nov 21, 2013 at 09:00:48AM +0100, Andreas Tille a écrit : > > PS: Alioth is back online and I might have a look later this day if > you would commit there. Thanks a lot ! gbp clone git.debian.org:/git/debian-med/htslib.git Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131121082926.gf16...@falafel.plessy.net
Re: No relro when building from inside a Git package ?
Le Wed, Nov 20, 2013 at 10:24:29PM +0100, Andreas Tille a écrit : > > without having checked out the repository and diving into it: Can you > post a diff of the two build logs? Hi Andreas, here it is (attached). Could the problem be a side effect of the test suite ? Cheers, -- Charles --- with-.git 2013-11-21 09:32:14.244499056 +0900 +++ without-.git2013-11-21 09:34:12.908497923 +0900 @@ -150,15 +150,6 @@ dh_auto_test make -j1 test make[2]: Entering directory `/tmp/htslib' -echo '#define HTS_VERSION "debian/0.2.0_rc3-1-38-g9469458"' > version.h -gcc -g -Wall -O2 -I. -DSAMTOOLS=1 -c -o hts.o hts.c -ar -rc libhts.a kfunc.o knetfile.o kstring.o bgzf.o faidx.o hfile.o hfile_net.o hts.o sam.o synced_bcf_reader.o vcf_sweep.o tbx.o vcf.o vcfutils.o cram/cram_codecs.o cram/cram_decode.o cram/cram_encode.o cram/cram_index.o cram/cram_io.o cram/cram_samtools.o cram/cram_stats.o cram/files.o cram/mFILE.o cram/md5.o cram/open_trace_file.o cram/pooled_alloc.o cram/sam_header.o cram/string_alloc.o cram/thread_pool.o cram/vlen.o cram/zfio.o -ranlib libhts.a -gcc -pthread -o test/fieldarith test/fieldarith.o libhts.a -lz -gcc -o test/hfile test/hfile.o libhts.a -lz -gcc -pthread -o test/test_view test/test_view.o libhts.a -lz -gcc -pthread -o test/test-vcf-api test/test-vcf-api.o libhts.a -lz -gcc -pthread -o test/test-vcf-sweep test/test-vcf-sweep.o libhts.a -lz test/fieldarith test/fieldarith.sam test/hfile cd test && ./test_view.pl @@ -456,11 +447,11 @@ Failures 0 cd test && ./test.pl test_vcf_api: - /tmp/htslib/test/test-vcf-api /tmp/Vvj_N60T4W/test-vcf-api.bcf + /tmp/htslib/test/test-vcf-api /tmp/cUKPv4vctM/test-vcf-api.bcf .. ok test_vcf_sweep: - /tmp/htslib/test/test-vcf-sweep /tmp/Vvj_N60T4W/test-vcf-api.bcf + /tmp/htslib/test/test-vcf-sweep /tmp/cUKPv4vctM/test-vcf-api.bcf .. ok @@ -495,10 +486,6 @@ make -j1 install DESTDIR=/tmp/htslib/debian/tmp AM_UPDATE_INFO_DIR=no prefix=/usr PACKAGE_VERSION=0.2.0\~rc4-1 make[2]: Entering directory `/tmp/htslib' mkdir -p /tmp/htslib/debian/tmp/usr/include/htslib /tmp/htslib/debian/tmp/usr/lib /tmp/htslib/debian/tmp/usr/share/man/man5 -echo '#define HTS_VERSION "0.2.0~rc4-1"' > version.h -gcc -g -Wall -O2 -I. -DSAMTOOLS=1 -fpic -c -o hts.pico hts.c -gcc -shared -Wl,-soname,libhts.so.0 -o libhts.so kfunc.pico knetfile.pico kstring.pico bgzf.pico faidx.pico hfile.pico hfile_net.pico hts.pico sam.pico synced_bcf_reader.pico vcf_sweep.pico tbx.pico vcf.pico vcfutils.pico cram/cram_codecs.pico cram/cram_decode.pico cram/cram_encode.pico cram/cram_index.pico cram/cram_io.pico cram/cram_samtools.pico cram/cram_stats.pico cram/files.pico cram/mFILE.pico cram/md5.pico cram/open_trace_file.pico cram/pooled_alloc.pico cram/sam_header.pico cram/string_alloc.pico cram/thread_pool.pico cram/vlen.pico cram/zfio.pico -lz -ln -sf libhts.so libhts.so.0 install -p -m 644 libhts.so /tmp/htslib/debian/tmp/usr/lib/libhts.so.0.2.0~rc4-1 ln -sf libhts.so.0.2.0~rc4-1 /tmp/htslib/debian/tmp/usr/lib/libhts.so ln -sf libhts.so.0.2.0~rc4-1 /tmp/htslib/debian/tmp/usr/lib/libhts.so.0 @@ -660,7 +647,7 @@ dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libhts0/DEBIAN/symbols doesn't match completely debian/libhts0.symbols --- debian/libhts0.symbols (libhts0_0.2.0~rc4-1_amd64) -+++ dpkg-gensymbolskXM3kh 2013-11-21 09:32:00.312499189 +0900 dpkg-gensymbols4DQT53 2013-11-21 09:34:08.056497969 +0900 @@ -230,6 +230,7 @@ cram_huffman_encode_int0@Base 0.2.0~rc3 cram_huffman_encode_int@Base 0.2.0~rc3 @@ -675,12 +662,12 @@ rm -f debian/htslib-test/DEBIAN/shlibs dh_shlibdeps dpkg-shlibdeps -Tdebian/libhts0.substvars debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0\~rc4-1 -dpkg-shlibdeps: warning: symbol exp used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries -dpkg-shlibdeps: warning: symbol pthread_join used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries -dpkg-shlibdeps: warning: symbol pthread_kill used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol pthread_create used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries +dpkg-shlibdeps: warning: symbol exp used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol lgamma used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries +dpkg-shlibdeps: warning: symbol pthread_kill used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 found in none of the libraries dpkg-shlibdeps: warning: symbol log used by debian/libhts0/usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1 fou
No relro when building from inside a Git package ?
Dear all, I am experience a strange variation when building package from a Git repository or from the same source with the .git directory deleted. In the first case I have the Lintian warning 'libhts0: hardening-no-relro usr/lib/x86_64-linux-gnu/libhts.so.0.2.0~rc4-1', but not in the second case. The only git-dependant code that I found is to create a package version, but I override it in debian/rules by the Debian package's version. In Makefile: ifneq "$(wildcard .git)" "" original_version := $(PACKAGE_VERSION) PACKAGE_VERSION := $(shell git describe --always --dirty) In debian/rules: override_dh_auto_build: dh_auto_build -- \ CFLAGS="$$(dpkg-buildflags --get CFLAGS)" \ CPPFLAGS="-I. -DSAMTOOLS=1 $$(dpkg-buildflags --get CPPFLAGS)" \ LDFLAGS="$$(dpkg-buildflags --get LDFLAGS)" \ PACKAGE_VERSION="$(DEB_VERSION)" override_dh_auto_install: dh_auto_install -- prefix=/usr PACKAGE_VERSION="$(DEB_VERSION)" (Digression: I do this because after tagging a debian revision, for instance 'debian/0.2.0_rc3-1', the package will fail to build from the Git repository since the tag becomes used for the soversion of the library, and the slash is mistaken as a directory separator. Is there a smart solution to this problem ?) You can get the source with 'gbp clone https://github.com/Debian/htslib'. Does anybody see why the hardening-no-relro is triggered when building in presence of the .git directory ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131120054439.gb16...@falafel.plessy.net
Is it still needed to pre-depend on multiarch-support ?
Hello everybody, now that Wheezy has been released, I am wondering if it is still needed to pre-depend on multiarch-support, especially for a new package. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131108051240.gb9...@falafel.plessy.net
Re: [Debian-med-packaging] Please help: sra-sdk
Le Tue, Oct 22, 2013 at 08:43:05PM +0200, Andreas Tille a écrit : > > I have done the changes needed to build sra-sdk in an unstable chroot > manually. It remains totally unclear to me why the build fails with > pbuilder but works in a minimal unstable chroot anyway. > > Charles, if you can build the package, could you at least run your test > to confirm whether the upstream code leads to the same results as our > current version? Thanks Andreas, I tested the 'fastq-dump' command using the file at the URL below, and this time it worked. http://ftp-trace.ncbi.nlm.nih.gov/sra/sra-instant/reads/ByExp/sra/SRX/SRX001/SRX001881/SRR006565/SRR006565.sra I can not upload from work, becaues I removed my GPG key from my Debian computer after I started to share administrative privileges with a colleague, so if you are faster than me, please do not hesitate to upload. Just pull the most recent changes before, as I updated the symbols file. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131023010012.gf17...@falafel.plessy.net
Re: DFSG and assembler code
Le Wed, Aug 21, 2013 at 10:01:29AM +0200, Andreas B. Mundt a écrit : > > To be able to compile the program with standard tools, the > pre-compiled code of the ROM-dumpers is included in the source. This > code needs to be removed for DFSG reasons. Hi Andreas, note that the DFSG do not imply that we need to remove the pre-compiled code from the source package. If 1) it can be redistributed; 2) its source code is provided; 3,4) its modification is allowed in practical terms; 5,6) there are no unreasonable restrictions on how to use it, and 7,8,9) its license is not awkward, then the work is Free according to the DFSG. Nevertheless, our current quality standards for the binary packages is that each file must be rebuildable from source, and for the ROMs discused here, without the proper compiler in Debian it is not possible. So in practice, this pre-compiled code can not be added to the binary packages, but I would like to stress that it is not because of the DFSG. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821133612.gb20...@falafel.plessy.net
Re: How to handle a package requiring external test data for its test suite?
Le Tue, Jun 18, 2013 at 08:10:29AM +0900, Thomas Moulard a écrit : > > I am currently packaging a computer vision software[1] which test suite > requires external data (images). Considering the weight of the images > (~75Mb) compared to the package size (a few Mb) they decided to distribute > them separately. Dear Thomas, Have you considered running the tests with autopkgtest ? http://dep.debian.net/deps/dep8/ Then, you can either download the data or install it from a separate data package. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617233325.ga25...@falafel.plessy.net
A smart post-commit hook to cherry-pick only Debian changes ?
Hello everybody, With Git, I just created an email deluge by merging an upstream branch in the master branch of the repository where I maintain the euca2ools package, and pushing to Alioth, which sent hundreds of commit messages on our commit mailing list... Does anybody knows a good post-commit hook that will only send an email for the changes related to the Debian packaging ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616025449.gb7...@falafel.plessy.net
Re: What the proper way to update debian/changelog
Le Fri, May 24, 2013 at 02:14:39AM +, T o n g a écrit : > > Not complaining, Debian has lot of good documents. Just that they are not > to my taste. :-) They are written in the reference book style, whereas I > more prefer a cook book style. :-) Still not complaining -- We've got to > appreciate what we already have so far. Hi, have you considered the following tutorial ? http://www.debian.org/doc/devel-manuals#packaging-tutorial Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130524042425.ga7...@falafel.plessy.net
Bug#706361: gti review
Le Wed, May 01, 2013 at 05:37:50PM +1000, Dmitry Smirnov a écrit : > > ## debian/copyright > > License name "MIT" is incorrect even though upstream may refer to this > license as such. "MIT" is considered ambiguous by the Free Software > Foundation. copyright-format-1.0 specification recommends to label > newer MIT license as "Expat" however this is an older variant so it > would be better called "MIT-old-style" or similar. See > > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > https://en.wikipedia.org/wiki/MIT_License Hi all, to be comprehensive, there are also the Software Package Data Exchange project and the Open Source Initiative which both agree on a reference MIT license: http://opensource.org/licenses/MIT http://spdx.org/licenses/MIT So if it matches the above, it may be fair to call it "MIT" if Upstream calls it "MIT". In the case of gti, the license does not match the text of the MIT or Expat license, therefore it is better to use an arbitrary short name. Something like "gti", or "MIT-like" (as Upstream calls it), etc. would be enough. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130501084219.gc19...@falafel.plessy.net
Re: Debian Preseeding: prevent particular package from being installed
Le Tue, Mar 19, 2013 at 11:56:19AM +0100, Konrad Vrba a écrit : > I am using Debian preseeding for automated installations (from PXE) > > in my preseed config file, I have the following line, to install only > the minimum number of packages: > tasksel tasksel/first multiselect > d-i base-installer/install-recommends boolean false > > This however still installs some packages which I don't want. My question is: > how does the installation script decide which packages will be installed? > how can I modify this list? > can I prevent specific package to be installed > > or, is there some other Debian mailing list, which would be more > appropriate for my question? Hi Konrad, on the debian-b...@lists.debian.org there are people who are the most likely to be able to answer your question, but before asking there it may be useful to ask first on a debian user mailing list, where there may be people experienced with preseeding as well. I am not sure if it will work, but have you tried d-i base-installer/excludes ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130320060449.ge30...@falafel.plessy.net
Re: Changelog etiquette for upstream patches
Le Fri, Mar 01, 2013 at 10:05:52PM +, Tony Houghton a écrit : > > The thing is there isn't a separate patch in the debian packaging or > elsewhere in the pending release tarball because I've applied the patch > to the code upstream. Dear Tony, for changes made upstream, you can thank the contributor in the upstream changelog. It is not necessary to repeat the information in the Debian changelog. If there was a Debian bug associated to the issue, you can mention its number together with the mention of a "New upstream version". Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302005250.ga12...@falafel.plessy.net
Re: Why is it so hard to get sponsors.....?
Le Thu, Feb 28, 2013 at 01:04:39PM -0430, PICCORO McKAY Lenz a écrit : > > I've noticed that some reports have response as "is not critical, is still > working," or else "not reproducible", or better "u can made a patch u can > made a fix u ca... u can.. u do that" co DD/DM has no time!! NO TIME!?? Hi Lenz, with time, DDs tend to meet loved ones, make children, be promoted at work, have new passions, develop new talents not related to software, take care of their old relatives, etc. If you have time to dedicate to packaging, please step up and help the teams you mentionned. What DDs who become short in time make sure in these teams, is that the infrastructure and learning curves are as easy as possible for newcomers, in order to to help others to contribute where they can not do themselves anymore. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301035115.gc12...@falafel.plessy.net
Exact matches in files in control data format.
Hello everybody, I am trying to parse the tasks files in tasks directory of the tasksel package: I would like to list all the tasks that are in the l10n section and enhance the desktop task. Example: Task: japanese-desktop Enhances: desktop, japanese Section: l10n Key: task-japanese-desktop Using grep-dctrl, I tried the following command (with contortions to avoid the po directory and the README). find . -maxdepth 1 -type f | xargs grep -l '^Task:' | xargs grep-dctrl --exact-match -FSection l10n \ --and \ --exact-match -FEnhances desktop \ -sTask -n Unfortulately, this only returns me the tasks that enhance the desktop task and nothing else, like in the following. Task: british-desktop Test-lang: en_GB Enhances: desktop Section: l10n Key: task-british-desktop However, if I relax the search, I also get tasks that enhance gnome-desktop, like the following: Task: japanese-gnome-desktop Enhances: gnome-desktop, japanese-desktop Section: l10n Key: task-japanese-gnome-desktop Does anybody know a workaround ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130227140023.ga13...@falafel.plessy.net
Re: RFS: libengsas packages
Le Tue, Feb 26, 2013 at 08:56:11AM +0100, Helmut Grohne a écrit : > On Mon, Feb 25, 2013 at 06:58:22PM +0100, Anton Gladky wrote: > > On 02/25/2013 05:37 PM, Andrew Shadura wrote: > > >> 6) Copyright-file must be in DEP-5 format. > > > Please don't say 'must' when you're speaking about what's actually a > > > recommendation, not a rule. Thanks. > > ok, agree, my "typo". But I think it is desirable to ask for DEP-5 for > > new uploads. > > In addition it is not even possible to use DEP-5 for every case. > http://lists.debian.org/debian-devel-games/2013/02/msg00065.html is a > recent example where a license cannot be reformatted to fit into DEP-5, > because it expressly prohibits modification. (I have to admit that this > is non-free.) Hi all, in case of Steam, I do not think that including a copy of the license in a debian copyright file following the machine-readable format constitutes an alteration of the license. First, the original file in the sources is unmodified. Second, indentation and escape of empty lines is not a modification of the license, but a formatting to allow the retreival of the pristine text using dedicated software. For instance, the tool "config-edit" displays license texts after converting them back to plain text. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130226083157.ga23...@falafel.plessy.net
Re: xdg menu entries
Le Thu, Feb 07, 2013 at 03:50:58PM +1000, Steven Hamilton a écrit : > > 1) How are XDG .desktop files handled. What is Debian policy regarding > these? > > 2) Is it acceptable to create a .desktop file for the game, or more > appropriately, is it acceptable to create a shell script in /usr/games/ > that can execute the Mari0 game with a single command? That way people > can run it from a command line. Dear Steve, the best solution for the menu entry is to write a .desktop file and send it upstream, so that their build system will install it in the appropriate directory for all users. In the meantime, you can ship it in the Debian part of the source package, and install it in /usr/share/applications. Dpkg triggers will take care of everything else. There is currently no policy for FreeDeskotop (XDG) menu files, however the format has a nice speficication for you to follow. http://standards.freedesktop.org/desktop-entry-spec/latest/ In addition, the program `desktop-file-validate`, from the desktop-file-utils package, will be useful for you to check your Desktop entry file before sending it upstream and distributing in Debian. (For the possibility to drop a script in /usr/games, I have no comment to make). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130207060242.ga6...@falafel.plessy.net
Re: [Debian-med-packaging] Bug#699260: Help (Was: Bug#699260: r-cran-genabel: FTBFS: error: subscript out of bounds)
tag 699260 confirmed severity 699260 grave thanks Le Tue, Jan 29, 2013 at 01:28:36PM -0600, Dirk Eddelbuettel a écrit : > > Also, CRAN has 1.7-3, you guys are at 1.7-0 of GenABEL. Maybe this even > changed upstream... Indeed :) +*** v. 1.7-3 (2013.01.09) + +(2013.01.09) +Commented the parts related to non-additive GC in qtscore +Removed calls to 'attach' from multiple procedures +Decrease of running time for long-running examples (GC_ovdom,GC,check.marker,Xfix,srdta) + +(2013.01.07) +Fixing the problem which prevents the package from loading while checking the version on CRAN I confirm that 1.7-0 fails and 1.7-3 builds. Also, the error also affects the binary package (version 1.7-0), rendering it useless. Our choices are: a) distribute 1.7-3 in Wheezy (note that the diff is not small), b) backport the correction, and c) remove r-cran-genabel from Wheezy. I volunteer for a), and I am neutral with b) and c). Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130130044725.ga27...@falafel.plessy.net
Re: Maintainer address for collab-maint team maintained packages
Le Mon, Nov 19, 2012 at 06:54:26PM +0100, Arno Töll a écrit :
>
> On 11/19/2012 03:28 PM, Marc Haber wrote:
> > @packages.debian.org seems to add that header automatically
> > before forwarding to the PTS, but using that address as Maintainer: is
> > a lintian _error_ (not even a warning) ("Severity: serious, Certainty:
> > certain").
>
> Thing is, you can't use the QA forwarder because it relies on your
> source control field to learn about actual forwardings. If you would add
> right that address, the result would be an infinite loop because you
> would essentially forward mail to @packages.debian.org to
> @packages.debian.org. I hope it is clear why this won't work.
Hi all,
I think that the best way forward would be to fix the PTS and remove the
infinite loop. This would be tremendously useful for many packages that are
collectively maintained.
I have no time to do it myself, but see the following wiki page to contribute.
http://wiki.debian.org/qa.debian.org/pts
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121119230404.gb10...@falafel.plessy.net
Re: Once more: Need help updating my DM upload permissions
Le Fri, Nov 16, 2012 at 10:32:29AM +0100, Thomas Friedrichsmeier a écrit : > > I am a Debian Maintainer, working on a single package, "rkward"[1]. As my > former sponsor appears to be MIA, I have previously posted to debian- > mentors[2,3], asking for help adjusting my upload permissions to the new > management interface[4] (for details on what I need a DD to do, refer to [2]). Hi Thomas, In 2009 I encouraged you to apply for DM and my opinion has not changed since. I just granted you upload privileges on rkward. For #689982, it can be corrected by uploading to wheezy-proposed-updates if need is. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121117114502.gc29...@falafel.plessy.net
Re: asking for package removal
Le Fri, Sep 21, 2012 at 11:42:23AM -0300, gustavo panizzo a écrit : > hello > i was going through the list of rc bugs for wheezy and i found > #687579. > > while i think the package should be removed (dead upstream, doesn't > work with wheeze version of it's dependencies) i'm not the maintainer. > > how long do i have to wait to maintainer to reply before ask to ftp > team to remove the package? can i (neither maintainer, uploader or DD) > ask for removals? > > > is nothing "personal" with the package or the maintainer, is was just > doing QA. > > thanks > > PS: i wasn't sure if send this to mentors or qa Hi, It looks like the maintainer of abby has recently packaged a replacement, nomnom. Since this shows he is still active, I recommend to wait two weeks for his answer to the proposition to remove the package, that you made in http://bugs.debian.org/687579#10. In the absence of answer, debian-qa is an appropriate list to discuss further the removal. If there a consensus for it, you can submit the request yourself to the FTP team. But I think you were right to use debian-mentor for asking for a general advice. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120922033211.ge8...@falafel.plessy.net
Re: How to remove a package from unstable
Le Sat, Sep 15, 2012 at 04:04:19PM +0200, Olе Streicher a écrit : > > I accidently uploaded a package to unstable (python-cpl) that should > have gone to experimental. How can I remove that from unstable but not > from testing? Dear Ole, if the presence of this package is really disruptive, you can re-upload the previous version using an epoch. But if the problem is only that you wanted to keep unstable in sync with testing in case you need to correct a RC bug, then it is better to leave the package as it is: there is still the possibility of updates through testing-proposed-updates. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917235904.gc25...@falafel.plessy.net
Re: Need help for watch file
Le Fri, Sep 14, 2012 at 04:21:33PM +0200, Andreas Tille a écrit : > > version=3 > opts=\ > dversionmangle=s/[~\+]dfsg//,\ > downloadurlmangle=s/VolView-([\d\.]+)-Linux-x86_64.sh/VolViewSrc.tar.gz/,\ > filenamemangle=s/VolView(-[\d\.]+)-Linux-x86_64.sh/VolViewSrc$1.tar.gz/ \ > http://www.kitware.com/products/vvdownload.html \ > http://www.kitware.com/VolView/files/VolView-([\d\.]+)-Linux-x86_64.sh > -- Downloading updated package > http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz > uscan warning: ../http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz > does not appear to be a compressed file; > the file command says: ERROR: cannot open > `../http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz' (No such file > or directory) > Hi Andreas, the problem here is that uscan sees the file name as: http://www.kitware.com/VolView/files/VolView-3.4-Linux-x86_64.sh Your filenamemangle regular expression turns it into: http://www.kitware.com/VolView/files/VolViewSrc-3.4.tar.gz A second expression is needed to remove the URL part. With the following, filenamemangle=s/VolView(-[\d\.]+)-Linux-x86_64.sh/VolViewSrc$1.tar.gz/;s|http://www.kitware.com/VolView/files/|| Uscan now sees the file name as VolViewSrc-3.4.tar.gz Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120915004102.ga31...@falafel.plessy.net
Problems converting Subversion-managed source package to Git.
Dear all, I am trying to change the repository type of Debian Med's velvet package from Subversion to Git. I have followed the instructions from the Debian wiki, which usually work well for me. http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git To my surprise, this time a long string of commits, from d3677cd5346ef36bad621f29c5fe54ca8441ee6c to f22edca1abc3dfb1dd32e2b1713a5b6b1763c714, was not attached to the master branch, as indicated by their absence in git log, or the discontinuation in 'gitk --all'. Does anybody know the reason and a way to repair ? I have uploaded the repository at git://git.debian.org/debian-med/velvet.git Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120914042240.ga12...@falafel.plessy.net
Re: Any script to populate debian/copyright file ?
> On Mon, Jul 16, 2012 at 9:41 AM, gustavo panizzo > wrote: > > > > cd /usr/share/doc > > find . -name copyright |xargs grep > > 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/' Le Mon, Jul 16, 2012 at 10:35:03AM -0400, Aliaksei Sheshka a écrit : > > > Sorry, but not helpful. They only represent ~13% on nearly default Wheezy > setup Dear Aliaksei, you can find more examples in the following repository: http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/ There, 1,047 out of 3,302 copyright files declare that they follow the machine-readable format version 1.0. These files are refreshed each time the package is uploaded, and sometimes more often, as they are picked directly from the package's VCS. See the following URL for details. http://wiki.debian.org/UpstreamMetadata Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716220655.gc2...@falafel.plessy.net
Re: how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)
Le Sun, Jul 15, 2012 at 11:25:14AM +, Bart Martens a écrit : > > I would mention this in debian/changelog : > > * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx. > > But I don't know how detailed such information must be for debian-policy. > Sometimes it is useful to also mention the reasons. I'm adding debian-mentors > in cc so that other sponsors can comment if they want to. Hi all, Policy's section 4.4 indicates that "Changes in the Debian version of the package should be briefly explained in the Debian changelog file debian/changelog". In that sense, the entry "Remove unused build-deps" is already quite informative as it provides the explanation for the change: the entries were not used. For packages that I maintain in a Git repository, I tend to become brief like this in my changelogs, and more verbose in the corresponding commits, for which the changelog mentions the first numbers of the hash ID. But this is a matter of taste; all in all, it does not cost much to fill up the changelog line with more information. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120715114924.ge32...@falafel.plessy.net
Re: Multilicense `debian/copyright` file
Le Sat, Jul 14, 2012 at 01:09:21AM -0400, Aliaksei Sheshka a écrit : > Hi debian-devel list! > > Please help me to write a proper `debian/copyright` file. > Original COPYING file says: > > Several parties hold copyright to various parts of IRRToolSet. One or more > of the following licenses may apply to the code contained within this > distribution. > 1. USC (and occasionally USC/IBM) license > . > 2. RIPE NCC license > > 3. GNU General Public License version 2 > ... > > What should put in the `debian/copyright` then ? Dear Aliaksei, your question is more suited for the debian-mentors@lists.d.o list, so I am transferring the discussion there. The Debian Policy's section 12.5 describes the requirements for the Debian copyright file. http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Note that it is not required to list exhaustively which file names correspond to which license, and that years of publication for one copyright holder may be gathered together. If you want to browse many Debian copyright files, you can have a look at the following repository: http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/ (More information about this project at http://wiki.debian.org/UpstreamMetadata ) Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714062617.gg8...@falafel.plessy.net
Re: Bug#675701: RFS: ptop
Le Sun, Jun 24, 2012 at 06:37:42AM +, Bart Martens a écrit : > > "Files: filename1, filename2" for exceptions. Actually, it should be: Files: filename1 filename2 (The separator is a space, not a comma plus a space). Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624065911.gf6...@falafel.plessy.net
Re: Bug#678468: RFS: sgml-data/2.0.7 [RC] [QA] -- common SGML and XML data
Le Sat, Jun 23, 2012 at 02:30:38PM +0200, Helmut Grohne a écrit : > On Sat, Jun 23, 2012 at 02:55:40PM +0300, Boris Pek wrote: > > > * The description still contains the homepage. > > > > Hmm, is it a problem? I don't see nothing about it in the Debian Policy [1]. > > That lintian note was about missed homepage field which is possibly present > > in > > description. > > > > [1] > > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description > > This is not a problem. The information is just redundant, i.e. it adds > no value to the description. But this is just my opinion. Hi all, perhaps one of the problems it causes is that, when the homepage changes, the long description changes, which will spend a bit of time of the translators, just for them to acknowledge that there is nothing to translate ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623124033.ga18...@falafel.plessy.net
Re: Bug#677013: RFS: time
Dear Bob, you can find many recent copyright files in the following subversion repository. http://svn.debian.org/viewvc/collab-qa/packages-metadata/ Each time a binary package is uploaded, its copyright file is refreshed in this Subversion repository if the source package was itself stored in a VCS. http://wiki.debian.org/UpstreamMetadata For the Machine-readable copyright format (DEP 5), ther is no field to record upsteam authors, because it is widely accepted that this is not required by the Policy, that is: the FTP team accepts new packages not doing so, and no bugs are filed against packages that are not doing so. But if you wish, you can either use the Comment field as you did, or use an extra field: The syntax of the file is the same as for other Debian control files, as specified in the Debian Policy Manual. See its section 5.1 for details. Extra fields can be added to any paragraph. No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. Future versions of the debian/copyright specification will attempt to avoid conflicting specifications for widely used extra fields. Lastly, note that your current copyright file does not have a valid syntax as spaces are not allowed in short license names. The tool 'cme' frome Dominique Dumont's excellent libconfig-model-perl package, will assist you for further syntax checking. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623073100.gf16...@falafel.plessy.net
About the field "Choices-C" Debconf templates.
Hello everybody, years after becoming DD, I am learning Debconf... amazing. I could not find an explanation for the "Choices-C" field in debconf-devel(7) nor the Developers Reference. Is that field clearly defined somewhere ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515234256.gb30...@falafel.plessy.net
Re: Maintainer of GNS3 Missing-in-Action, I volunteer
Le Tue, May 15, 2012 at 06:41:58PM -0400, Alexey Eromenko a écrit : > Hi All ! > > GNS3 package is Debian has not been updated in the last year, and the > Debian maintainer, Erik Wenzel, went MIA. (doesn't answer to emails > for last few months) Hi Alexey, According to his QA page, the maintainer of gns3 uploaded another package (aggregate) 15 days ago. He is therefore not MIA. Perhaps you can try again to contact him in #665979, with a short summary of the pros and cons of releasing with 0.7.4 or 0.8.2 ? Note that since Debian has a release cycle that is roughly two years, gns3 will be eventually outdated in Stable anyway. But we have backports.debian.org for bringing new upstream stable versions to the users of Debian stable, so your work as upstream developer can be accessble to them through the Debian archive. Have a nice day, and thanks for your care of the gns3 package. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515225252.ga30...@falafel.plessy.net
Re: is wheezy frozen already?
Le Tue, May 15, 2012 at 01:09:32AM +0200, Arno Töll a écrit : > On 15.05.2012 00:26, Charles Plessy wrote: > > when the NEW queue is long, this leaves us some time to make a pre-review to > > ease the work of the FTP team, by reducing the number of errors they have to > > deal with. > > how would you do that, given packages in NEW aren't publicly accessible > on purpose? In my experience, I rarely encountered a package in NEW where neither the upstream archive nor the debian directory were downloadable from somewhere else. A very large number of packages have at least their debian directory stored in a publicly-accessible VCS, and the changes file indicates the MD5 sum of the upstream source archive, so all in all, in most of the cases a review is possible. And as you noted, the packages are also often available on mentors.d.n. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514233658.gc24...@falafel.plessy.net
Re: is wheezy frozen already?
Le Mon, May 14, 2012 at 03:49:41PM +0200, Andreas Tille a écrit : > On Sat, May 12, 2012 at 09:57:42AM +, Daniel Pocock wrote: > > I notice that packages have not been taken from the queue for 3 weeks: > > > >http://ftp-master.debian.org/new.html > > I'd rather see a correlation to the fact that some members of the > ftpmaster team might be short in time for private reasons than to the > freeze date. It might be that some "Do you need some help I could offer > in terms of 2-3 hours per week" to ftpmaster team would be welcome. Hi all, when the NEW queue is long, this leaves us some time to make a pre-review to ease the work of the FTP team, by reducing the number of errors they have to deal with. http://wiki.debian.org/CopyrightReview Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514222609.ga24...@falafel.plessy.net
Re: Is there anyway to prettify long *-Depends: lines?
Le Sun, May 13, 2012 at 02:00:04PM +1000, Ben Finney a écrit : > Paul Elliott writes: > > > I have a really long Build-Depends: line. > > > > Multiple Build-Depends: lines is an error. > > I think you mean “multiple Build-Depends fields”. Yes, that's an error. > > But the field can span multiple lines by indenting the continuation lines: > > = > Build-Depends: > foo, > bar, > baz > = Hi all, I also have seen and used: = Build-Depends: foo, bar, baz, = The trailing comma reduces the complexity of the diff when adding one package to the tail of the list, and prevents errors caused by forgetting to add a comma to the penulitmate. This said, I am not completely sure if this complies with Policy's §7.1, which mandates that “package names separated by commas”. It does not seem to break core toolchain programs, but is there somebody aware of peripheral problems ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513054631.ga21...@falafel.plessy.net
What is the best way for disabling a service from another package ?
Dear all, I am porting to Debian a package that uses dpkg-divert in its maintainer scripts to disable a service provided by another package, by moving out the other package's upstart script. I can keep the commands as they are, since the target package does not exist in Debian, but this made me curious how to actually do these kind of operations, when package A must in a way modify package B's starting behavior or configuration. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504215551.ga9...@falafel.plessy.net
Bug#659522: RFS: prelink/0.0.20111012-1 [ITA] - ELF prelinking
Le Sat, Mar 03, 2012 at 12:23:20AM +0100, Daniel Martí a écrit : > A new package is available at mentors as shown below: > > http://mentors.debian.net/debian/pool/main/p/prelink/prelink_0.0.20111012-1.dsc > Since the lintian description tells me to contact upstream before patching > with quilt (which would give extra work), I've sent a mail to Jakub about the > subject. I'll wait a week or two for his answer. For the time being, the newer > upload seems to be fine apart from those two warnings. > > I'd be very glad if someone sponsored this package for me. Dear Daniel and everybody, I am interested in prelink because of #643967 and #505906 (which pollutes my mailbox with a daily notification from a system I co-administrate). As a first step when inspecting the package, I compared the 'original' source archive that you uploaded, with the one that looks like being the upstream one. http://mentors.debian.net/debian/pool/main/p/prelink/prelink_0.0.20111012.orig.tar.gz http://people.redhat.com/jakub/prelink/prelink-20111012.tar.bz2 Can you explain why they differ ? Is it the Lintian description that confused you to repack the archive instead of patching it ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120428035339.ga16...@plessy.org
Re: how to adopt a non-orphaned package?
Le Wed, Apr 25, 2012 at 06:24:06PM +1000, Dmitry Smirnov a écrit : > > What would be the best practice to adopt a package which was not properly > orphaned? > > My particular concern is about 'autofs5' package which was not updated for > years since squeeze release due to maintainer inactivity. Dear Dmitry, judging from the maintainer's QA page, he looks totally inactive indeed. For the package you would like to adopt, consider that one day, you may be the inactive person as well, and call for co-mainainers or maintainance in an existing team, so that the same situation does not happen again. You can for instance send an "Intend to Hijack" email to debian-devel, and CC it to the persons who contributed NMUs and patches in the BTS, explaining what you already explained here, and add that the package has already been NMUed 2 times. Then, get the package sponsored with you and others as maintainers. You can keep the current maintainer in the list as well, to show that he is welcome to work on the package if he can come back to Debian. But while this would solve the problem with autofs5, this will not solve the problem with the otehr packages. You will do a great service to Debian if in parallel you follow the guidelines that Paul pointed you to, and help the QA and MIA teams to take care of the other packages. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425101008.gc9...@falafel.plessy.net
Re: Modifications of the changelog.
Le Sun, Apr 22, 2012 at 12:22:43PM +1000, Ben Finney a écrit : > Charles Plessy writes: > > > are there concrete problems caused by modifying previous changelog > > entries ? > > Doing that breaks the entirely reasonable expectation: that a changelog > only ever accumulates entries for the latest release, and nothing in > earlier releases has changed since the last time the recipient read > them. Hi Ben, What is that expectation for ? I find it dogmatic written like this. If it breaks software, especially in Debian's infrastructure, that would be a key reason for not changing any byte. Otherwise, while there is probably better things to do in life than spellchecking a changelog, I admit that once I went through the first entry, I sometimes correct the ones below. I also remove trailing spaces that distract my eyes when colored in purple by my editor, and for the packages in Git, I sometimes added the first seven numbers of the commit hash to past entries. I also have added missing hashes so that when browsing the changelog on packages.d.o, one can have a nice hyperlink to bug reports, etc. I am not advocating that other people should do this, but I think that, especially on debian-mentors, strong statements about what everybody must not do should come with explanations about the reason, if possible argumented with concrete examples of the problems caused. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422023931.ge19...@falafel.plessy.net
Modifications of the changelog.
> > * Do not modify previous changelog entries, especially not in NMUs. Hi all, are there concrete problems caused by modifying previous changelog entries ? I do it from time to time, of course not when the diff has to be carefully inspected by others as it would be a distraction, and I have not found it causing breakages. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120421073546.gb31...@falafel.plessy.net
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 05:02:13PM +0200, Thibaut Paumard a écrit : > Le 19/04/12 16:20, Charles Plessy a écrit : > > > > I think that there is a consensus that generated files must be regenerable, > > and > > that it is a bug if their build system is broken. The best way to ensure > > this > > is to regenerate them at build time, however it is not a requirement. In > > particular, I do not see advantages in distributing rebuilds that would for > > instance only update time stamps. It is increasing debdiffs and heating the > > planet for no benefit. > > File timestamps won't show up in debdiff. At the very least, the > maintainer should (IMNSHO) regenerate the files himself and check that > they match what ends-up being distributed. And he should also document > this process in debian/README.source. Honestly, I think it's simpler and > less error-prone to just distribute the regenerated files. But as you > said, it's not a policy requirement. There are other timestamps. Some documents contain the date where they were built, as an indication for the last time they were modified. For the packages I maintain, where I wrote manpages in DocBook XML, I do not regenerate them at each build and store the generated nroff code in the VCS where the package is maintained. This has the additional advantage that the package does not need to build-depend on the DocBook toolchain. debian/rules contains a target to rebuild, plus a comment explaining which packages to install. The point I am trying to make is that there is no single rule that has to be strictly followed by eveybody in all cases. Otherwise we would fall in the same selective blindess as for the freeness of pictures, videos, music and scientific data. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120420001744.ga13...@falafel.plessy.net
Re: Documentation generated by doxygen and Debian Policy
Le Thu, Apr 19, 2012 at 03:57:59PM +0200, Thibaut Paumard a écrit : > > I believe it is generally accepted that every file that can be > (re)generated during the build process should be, for various reasons. Hi all, I think that there is a consensus that generated files must be regenerable, and that it is a bug if their build system is broken. The best way to ensure this is to regenerate them at build time, however it is not a requirement. In particular, I do not see advantages in distributing rebuilds that would for instance only update time stamps. It is increasing debdiffs and heating the planet for no benefit. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419142040.ga30...@falafel.plessy.net
Re: adding a new file using (d)quilt
Le Thu, Apr 12, 2012 at 12:50:23PM +0200, Gerber van der Graaf a écrit : > Hi, for packaging freefoam-user-doc I intend to include the static file > UsersGuide.pdf.gz as asymptote is currently broken. Dear Gerber, it will be much simpler for you to include it directly in the debian tarball using the dpkg format 3.0 (quilt). In contrary to what the name suggests, this will not be done using quilt. See the manual page of dpkg-source for more details. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412111348.ge14...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Sat, Apr 07, 2012 at 04:46:33PM +0400, Vladimir Stavrinov a écrit : > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659047 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652718 > http://mentors.debian.net/package/rpg Hi, There is no need to rename bugs and mentors uploads retroactively. If repagen is accepted in Debian, it will close #652718 and #659047, and this is enough to make the link. The mentors URL (in my understanding) will not persist. This said, for your information, you can easily retitle bugs from the command line with the "bts" program in the "devscripts" package. > http://sourceforge.net/projects/rpg/ There can be discrepancies between Debian's package name and the upstream name. For instance, I packaged the program "last" in the package "last-align". Conversly, I packaged the program "bwa" in the package "bwa", but on SourceForge (and only there) it is called "bio-bwa". As a side note, I think that the comments about security in this thread are very relevant. If your package were accepted in Debian, it would need to meet Debian's and Debian's users expectations, not only your vision as an upstream developer. This means that if some design choices are perceived as flaws from Debian's point of view, somebody will have to do some work to correct the package in Sid and perhaps in Stable. That is one of the reasons for the reluctance to accept your package. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120408000525.ga24...@falafel.plessy.net
Re: installing desktop file and icon
Le Fri, Apr 06, 2012 at 04:14:49PM -0800, Christopher Howard a écrit : > Hi. I have source code that comes with a freedesktop-style .desktop file > and svg icon. I know they need to go in /usr/share/applications and > /usr/share/pixmaps (respectively). In the deb package which I am making, > what should I put in the deb's "rules" file so that these are properly > installed? Dear Christopher, thanks to dpkg triggers, everything needed is run when dpkg detects that it adds a file in /usr/share/applications. $ grep applications /var/lib/dpkg/triggers/File /usr/share/applications gnome-menus /usr/share/applications desktop-file-utils You only need to install the files like any other files. Developers using debhelper would for instance use dh_install(1) for this. Note that since /usr/share/applications and /usr/share/pixmaps are standard directories, it would be best that "make install" simply install them at the same time as the other files. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120407003246.gb3...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Fri, Apr 06, 2012 at 07:04:08PM +0400, Vladimir Stavrinov a écrit : > On Fri, Apr 6, 2012 at 3:34 AM, Charles Plessy wrote: > > > I also think that we should refrain from using short and common names for > > the > > What about "repagen" i.e. REadable PAssword GENerator ? Is it OK.? That is nice. Good luck for solving the other problems raised in that thread and finding a sponsor. Debian has thousands of packages. Each of them has an imprint on our ecosystem. Consider for instance that if one day you suddenly can not contribute anymore, somebody else will need to care of the package. Summed together, even removals takes time. In the future, Debian wants to set up a personal package archive system like in Ubuntu. That would be an ideal first stage for packages like yours, where they can demonstrate they have an audience, before entering the main distribution. This said, it is good to pick a unique name in advance, and "repagen" illustrates well the point of the package. It looks like that there is a trademarked cosmetic of the same name, but fields of use are different enough. Or pehraps unreadable passwords are bad for the skin in the long term ;) Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120407001444.ga3...@falafel.plessy.net
Re: Bug#659047: RFS: rpg - Readable Password Generator
Le Thu, Apr 05, 2012 at 07:05:16PM +0400, Vladimir Stavrinov a écrit : > > But there no package named rpg. Hi, I also think that we should refrain from using short and common names for the packages. That there is no package named rpg does not say that it is free for you, it says that there was self-discipline and peer pressure up to now to avoid it. Package names need to be thought forward, not on a first-arrived first-served manner. In your case, "rpg-password" or other suffixes can be used to increase the length a complexity of the package names. To convey the pristine name of the software that is packaged, there are other ways such as the "AppStream and Component Metadata for Debian" and "Upstream metadata gathered with yaml (UMEGAYA)" projects. http://wiki.debian.org/AppStreamDebianProposal http://wiki.debian.org/UpstreamMetadata Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120405233404.gb17...@falafel.plessy.net
Re: Signing a .deb later?
Le Wed, Apr 04, 2012 at 07:55:09AM +0200, Thibaut Paumard a écrit : > Le 04/04/12 01:01, Christopher Howard a écrit : > > So, my first question: Is there some nifty command or trick to > > (properly) GPG sign a .deb package /after/ I've finished making it? > > You can't sign your binary packages. What you can sign is the .dsc > (source package) and .changes (upload file). You sign them using debsign. Actually, there is a binary package signing tool, but it looks rather abandonned… http://manpages.ubuntu.com/manpages/precise/en/man1/debsig-verify.1.html Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404065009.gf12...@falafel.plessy.net
Re: Advice on use of patch system while hacking
Le Sun, Apr 01, 2012 at 01:30:41PM -0700, Ross Boylan a écrit : > > It's not my package, and for reasons of courtesy to the maintainer and > (I thought) minimizing work for myself I didn't want to make any > unncessary changes. Actually, since the maintainer of noweb does not seem to have made uploads for a long time, perhaps you can check if he is still interested or available; otherwise it is a good moment to take over the package or transfer it to a team that would like to adopt it, possibliy with more extensive modifications (for instance merging Ubuntu's changes). Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402020810.gb7...@falafel.plessy.net
Re: Debian-friendly upstream best practices?
Le Wed, Mar 28, 2012 at 02:29:22PM +0200, Michael Wild a écrit : > > The only unpleasant side-effect I can think of is that git-dch will > probably be a bit noisy. Same for the commit emails. This is one of the reasons I still import tarballs from upstream projects that are maintained with Git: I did not manage to find how to avoid sending a deluge of commit emails when pushing the upstream branch to Alioth. Also, they are sent with the commiter's name as sender, which gives the wrong impression he is the one who pushed the upstream changes to the Debian package. Any hint ? -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120328130646.gd1...@falafel.plessy.net
Re: Files permission in the debian directory
Le Mon, Feb 13, 2012 at 04:05:11PM +0100, fre...@free.fr a écrit : > > > What are the recommended permissions for all the files that reside inside the > debian directory ? > I've not found any documentation about it, except for debian/rules. Dear Fred, the Dpkg source format version 1.0 does not support other files than debian/rules to be executable, so I recommend that unless strictly needed, you do not rely on files in debian/ to be executable, especially if you suspect that your package might be backported by users on local installations that are too old for supporting the 3.0 (quilt) format. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213235945.ga9...@falafel.plessy.net
Re: how to manage d/changelog for updated but not yet sponsored package
Le Mon, Feb 13, 2012 at 11:53:45AM +0100, Jakub Wilk a écrit : > * Ben Finney , 2012-02-13, 13:40: > >>I want to keep trace of it in the d/changelog by keeping my > >>first version entry and adding a second entry. Can I do that ? > >>Will it confuse some Debian robots ? > > > >It's fine. I consider uploading the package to > >‘mentors.debian.net’ a release of the package, since at that point > >interested people (e.g. reviewers) can rely on it, and the version > >should refer uniquely to what I uploaded at that time. > > > >Be aware, though, that some people disagree (on the grounds that > >it's not a new version until it enters Debian). > > I believe that vast majority of sponsors disagree. Note however that the FTP team does not reject such packages. I tend to keep the changelog entries of packages that have been released outside Debian for the public. However, I revert all previous “unstable” entries to “UNRELEASED” to clearly mark that these packages were not in the Debian archive. Have a nice day, Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213110711.gd25...@falafel.plessy.net
Re: DEP-5 versioned URI / Lintian complains
Le Sat, Feb 11, 2012 at 05:42:29AM +, Samuel Bronson a écrit : > Russ Allbery debian.org> writes: > > > Daniel Stender danielstender.com> writes: > > > > > For the very next of my commits, > > > > > 1) what URI should I give to the very next commits, and should I just > > > just disregard the Lintian complain > > > > For right now, I would ignore the complaint and use an unversioned URL, > > since so far as I can tell there is no versioned URL currently available > > that takes you straight to the current text of the document. However, I > > may have missed something. > > Actually, there is > <http://anonscm.debian.org/viewvc/dep/web/deps/dep5/copyright- > format.xml?revision=269&view=markup>. Not exactly the most readable, but it > does > work. Hello Samuel, I do not recommend to use this URL. The current draft will not have normative changes anymore, so you can use: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ The DEP is in a final review stage. Unless additional delays, I will probably mark it accepted next week, and the above URL will become valid immediately after the next Policy upload. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120211064552.gh19...@falafel.plessy.net
Re: watch-file syntax help
Le Thu, Feb 09, 2012 at 08:37:58PM +0100, Daniel Martí a écrit : > > I'm having some trouble at creating a watch file for the packace "preload". > > The upstream tarballs are found as follows: > http://sourceforge.net/projects/preload/files/preload/0.6.4/preload-0.6.4.tar.gz Dear Daniel, I have the following watch file for samtools, that has similar URLs. version=3 opts=downloadurlmangle=s|/download||,filenamemangle=s|http://sourceforge.net/projects/samtools/files/samtools/.+?/||;s|.download|| \ http://sourceforge.net/projects/samtools/files/samtools/ \ http://sourceforge.net/projects/samtools/files/samtools/.+?/samtools-(.*).tar.bz2/download Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210003003.gb2...@falafel.plessy.net
Bug#659045: RFS: goplay (NMU)
Le Wed, Feb 08, 2012 at 01:36:08PM +1100, Dmitry Smirnov a écrit : > > How could I forget, I did contact them thought the Alioth request to join the > team, where I mention the prepared NMU. Alioth requests are a mess: when one admin answers, there is no notification to the other admins. As a consequence, it can happen that everyone expects the others to have answered. I recommend to contact the team on its mailing list. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120208025142.gb31...@falafel.plessy.net
Bug#659045: RFS: goplay (NMU)
Le Wed, Feb 08, 2012 at 11:10:55AM +1100, Dmitry Smirnov a écrit : > > The options are: > >* QA : Not in this case since the package is > team-maintained. > >* Team : Looks like best option, but I'm not the > team member > so I can't upload on behalf of the team. > >* NMU : Certainly not an unreasonable option, read > below. > > Of course team upload would be the best but because package hasn't been > touched for years, I have reasonable concerns that either team is not active > or they are busy with something more important. Hi Dmitry, have you actually tried to contact the team ? I do not see messages from you in January or February on their mailing list. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120208015119.ga31...@falafel.plessy.net
Re: sponsorship-requests
Le Mon, Jan 30, 2012 at 10:44:02PM +0100, Jakub Wilk a écrit : > > We could ask listmasters to filter out BTS bot messages. Now, there > are certainly people (e.g. me) who do want to see control messages. > But they could always subscribe to sponsorship-requests via PTS. > > What do others think? I tend to consider them as annoying noise, especially on debian-devel and debian-policy. I prefer when no message is send by routine tools when there is no error. But I guess that the issue is rather with the BTS. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131110035.gc11...@merveille.plessy.net
Re: RFS: bibtool
Le Thu, Jan 26, 2012 at 04:23:00PM +0100, Adam Borowski a écrit : > On Thu, Jan 26, 2012 at 12:14:15PM +0100, Jerome BENOIT wrote: > > The debian/copyright was corrected as well: > > lintian failed to detect non ASCII chars. > > Because they're perfectly fine. You're not supposed to mangle the names of > copyright holders, etc. > > It should use UTF-8. I somehow can't seem to find a policy paragraph > specifying this (an omission?), but at least common sense specifies that :p And in the particular case of this package, that uses the machine-readable copyright format, it is indirectly mandated by the Policy: DEP 5: The syntax of the file is the same as for other Debian control files, as specified in the Debian Policy Manual. See its section 5.1 for details. Policy §5.1: All control files must be encoded in UTF-8. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127093011.gd12...@merveille.plessy.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Le Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt a écrit : > SUMMARY > === > > We plan to ask for the creation of a new pseudo-package > debian-mentors or mentors.debian.org [3] (contact: > debian-mentors@lists.debian.org) in Debian's bug tracking system (the > name is still subject to change). A workflow for handling sponsoring > requests is proposed below. It is based on an earlier discussion on the > debian-mentors list[1]. > > The workflow will also be made available on [2]. > > [1] > <http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de> > [2] <http://wiki.debian.org/Mentors/BTS> > [3] mentors.debian.net is not a .org service (yet). We do not intend to > push its transition by that right now. Dear Ansgar and everybody, I think that using a bug tracking system is the way to go. I have proposed in the past a worflow for using WNPP bugs, but having a dedicated pseudo-package would definitely be superior. Another point of my proposal was to ask that developers who call for sponsorship try to review at least another package. Please do not hesitate to take the idea of you like it. http://wiki.debian.org/PackageReview Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120117235414.gb26...@merveille.plessy.net
Re: Correct value for DEP5’s Format: field?
Le Mon, Jan 09, 2012 at 02:09:54PM +1100, Craig Small a écrit : > On Sun, Jan 08, 2012 at 06:42:27PM +0100, Daniel Stender wrote: > > expected URL: > > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0 > I've seen this url twice, including with the trailing slash. > > However, it gives me a 404 from two Australian locations. > http://www.debian.org/doc/packaging-manuals/ shows no copyright-format > directory. > > wget http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > --2012-01-09 14:01:38-- > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > Resolving www.debian.org (www.debian.org)... 2001:388:1034:2900::26, > 150.203.164.38 > Connecting to www.debian.org (www.debian.org)|2001:388:1034:2900::26|:80... > connected. > HTTP request sent, awaiting response... 404 Not Found > 2012-01-09 14:01:38 ERROR 404: Not Found. > > Is this a mirror problem or a URL problem? The IP is for gluck. Dear Craig, it is not a mirror problem, but rather a chicken-and-egg problem: if we want to distribute the DEP on www.debian.org, and if we want the DEP to mention its own URL, we need its draft to mention it before it actually contains something. Given that most other recommended URLs (svn.debian.org or anonscm.debian.org) are also broken, I do not think that it is much problematic. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109032634.gd18...@merveille.plessy.net
Re: Correct value for DEP5’s Format: field?
Le Sun, Jan 08, 2012 at 04:47:34PM +0100, Andrea Bolognani a écrit : > > I’m updating a debian/copyright file in DEP5 format, but I’m finding > myself unable to pick an acceptable value for the Format: field. Dear Andrea, there will be no syntax changes until DEP 5 is finished, so for a new copyright file, I recommend you to use the URL that was chosen for publishing version 1.0. http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Note that the trailing slash is part of the URL. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109014753.gb18...@merveille.plessy.net
Re: RFS: libxml2 (NMU)
Le Sun, Jan 08, 2012 at 01:45:50PM +0300, Andrew Shadura a écrit : > > I am looking for a sponsor for my non-maintainer upload of the package > libxml2, version 2.7.8.dfsg-5.2. Dear Andrew, libxml2 has been orphaned, and two persons proposed themselves to co-maintain it. Have you tried to contact them ? http://bugs.debian.org/654176 Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120108113555.gi1...@merveille.plessy.net
Re: RFS: vodafone-mobile-broadband
Le Sun, Jan 08, 2012 at 03:05:20AM +0100, Jakub Wilk a écrit : > * Alex Chiang , 2012-01-07, 16:28: > > http://mentors.debian.net/package/vodafone-mobile-broadband > > dget -x > > http://mentors.debian.net/debian/pool/main/v/vodafone-mobile-broadband/vodafone-mobile-broadband_2.99.15-1.dsc > > Licence/copyright for resources/tools/FreeSans.ttf is not documented > in the copyright file. Worse still, I believe the font is GPL-ed and > TTF is not the preferred form of modification (for this particular > font). This renders the source package undistributable. Note that it would be preferrable to depend on ttf-freefont, that provides this font, than distributing a copy in vodafone-mobile-broadband. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120108074152.gb1...@merveille.plessy.net
Re: RFS: solarpowerlog
Le Fri, Dec 23, 2011 at 10:15:01AM +0100, Arno Töll a écrit : > > On 23.12.2011 08:57, Charles Plessy wrote: > > For projects on Git hubs that do not release tar archives, I am starting > > to use native formats. This is much more straightforward. > > just because you opted to ignore all conventions please do not advise > people to do the same giving them falsly the impression such an approach > would be right or even acceptable for many people. Hi Arno, I admit my reply was a bit provocative, but I gave it because it desolates me that some statements on this list are very dogmatic. It is very important to justify our technical decisions on facts rather than traditions, seniority, or imaginary truths. Also we must make efforts on writing accurate statements. Experience proves that works that are not specific to Debian but that use a native format are accepted in our archive; it is therefore misleading to write that they can not be uploaded, and that it is not a matter of choice. Of course, choices may be wrong. I am ready to defend mine, but I would not like to suggest that using the native format is always the best choice. Indeed, it is often the wrong one. But one can not justify to not use native formats by an upload restriction that does not exist. That is the main reason why I jumped in that thread. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223100944.GB30099@chouca.igloo
Re: RFS: solarpowerlog
Le Thu, Dec 22, 2011 at 07:59:36PM -0200, Fernando Lemos a écrit : > > It's not a matter of choice. If your package is not Debian-specific, > it can't and won't be uploaded as a native package. Hello everybody, packages that are not Debian-specific and use a native source format are rare, but can be found in the Debian archive. For projects on Git hubs that do not release tar archives, I am starting to use native formats. This is much more straightforward. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223075723.GA30099@chouca.igloo
Re: original source has file in top-level directory
Le Thu, Nov 17, 2011 at 12:59:25PM +0100, Mathias Ertl a écrit : > > I am having problems building a source package where the original source > package includes a file at the top-level directory. For example, the > orig.tar.gz contains: > > mati@haumea:~ $ tar tf some_1.7.1.orig.tar.gz > topfile > some/file1 > some/file2 > ... Dear Mathias, if the file is completely useless and is not intended to shift the tree of one level, you can delete it. Here is for instance how I did for the bedtools package, where the upstream tarball contained some Macintosh ressource files for the top-level directory. get-orig-source: uscan --no-symlink --force-download --download-version $(DEB_UPSTREAM_VERSION) zcat ../BEDTools.v$(DEB_UPSTREAM_VERSION).tar.gz \ | tar --wildcards \ --delete '*/._*' \ | xz \ > ../$(DEB_SOURCE_PACKAGE)_$(DEB_UPSTREAM_VERSION).orig.tar.xz http://anonscm.debian.org/gitweb/?p=debian-med/bedtools.git;a=blob;f=debian/rules;hb=2fe7cffc95d61a83c59569f816f83c4607fb6398 (Note that the DEB_* variables are obtained from CDBS) When re-creating the tarball, please note that if you use gzip, independant repacking will produce tarballs of different MD5 sums, so I would recommend to pass --no-name so that it does not include the timestamps that are the cause for this variability. But before embarking in adding complexity to your package, there is something even simpler to do: talk to Upstream ! Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2018001352.ga16...@merveille.plessy.net
Re: How to pass CFLAGS to upstream's Makefile with debhlepler ?
> On 2011-11-14 06:12, Charles Plessy wrote:
> >
> > trying to pass dpkg-buildglags' settings to an upstream build system
> > (http://git.debian.org/?p=debian-med/bwa.git), I found no other way than
> > patching their makefile, basically replacing
> >
> > CFLAGS = -g -Wall -O2
> >
> > with
> >
> > CFLAGS ?= -g -Wall -O2
> >
> > I wonder if it was the right thing to do, and if it is a change that can be
> > forwarded upstream.
Le Mon, Nov 14, 2011 at 07:28:32AM +0100, Niels Thykier a écrit :
> I believe that:
>
> override_dh_auto_build:
> dh_auto_build -- CFLAGS="$(CFLAGS)"
>
>
> - OR -
>
> override_dh_auto_build:
> $(MAKE) CFLAGS="$(CFLAGS)"
>
>
> ought to do. This only caveat is that it completely overrides the
> CFLAGS variable in the makefile. This is usually mostly a problem if
> upstream (ab)uses LDFLAGS to add "-llib" flags, which does not really
> belong there.
Le Mon, Nov 14, 2011 at 11:35:03AM +0100, Andrew Shadura a écrit :
>
> I always use ?= in my Makefiles because it may be important to someone
> to be able at least partially override the setting I use.
Thank you very much for your answers. I ended up using the following Debhelper
override.
override_dh_auto_build:
dh_auto_build -- CFLAGS="-Wall $(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
Does anybody know the reason why dpkg-buildflags does not include -Wall ?
Cheers,
Charles
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014104030.gd...@merveille.plessy.net
How to pass CFLAGS to upstream's Makefile with debhlepler ?
Dear all, trying to pass dpkg-buildglags' settings to an upstream build system (http://git.debian.org/?p=debian-med/bwa.git), I found no other way than patching their makefile, basically replacing CFLAGS = -g -Wall -O2 with CFLAGS ?= -g -Wall -O2 I wonder if it was the right thing to do, and if it is a change that can be forwarded upstream. Also, I added $(CPPFLAGS) $(LDFLAGS) in some calls to $(CC), but I think I remember reading that $(LDFLAGS) is not needed everywhere. When in doubt, is it safe to add them ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014051204.ga...@merveille.plessy.net
Re: What is the proper way to rename scripts?
Le Wed, Nov 02, 2011 at 05:36:29AM -0500, Paul Elliott a écrit : > > Because of Debian Policy Manual section 10.4 (Scripts) > I must rename a script. Hi Paul, if the script is not an interface, you can consider leaving its name as it is. Why would foo.pl unacceptable and pyfoo acceptable ? In any case, please pay attention to the risk of becomming incompatible with upstream's documentation, examples, scripts, as well as users scripts if you rename a program. In my work environment using Debian isolates me from my colleagues for this reason… The best solution to the problem is to convince Upstream to rename the file if you think it is worth doing so. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2002112638.gf20...@merveille.plessy.net
