Re: Updating the fis-gtm package to V6.2-000
Hi Amul, On Thu, Oct 09, 2014 at 10:41:36AM -0400, Amul Shah wrote: > > > >Does this clarify my idea why fixing the licensing issue in > >fis-gtm-6.2-000 would be sufficient? > > [amul:11] We have two options at this point regarding > fis-gtm-6.1-000. Withdraw the version or update it. We - I, Bhaskar > and a few other GT.M developers - are fine with either. If someone > could point me to a doc to show how to fix the prior version, I can > fix it. My google-fu isn't turning anything up. The fix would be to just take apply your latest patch to d/copyright and apply it to the packaging of fis-gtm-6.1-000. However, as I explained I consider this a waste of time since it becomes fixed with the upload of fis-gtm-6.2-000 anyway (which I plan in the next couple of hours). > [amul:11] I looked through > https://www.debian.org/doc/manuals/developers-reference for the > steps to withdraw the package > (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs) > and close the bug > (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-bugfix). > Is that what I should do? Simply waiting at your side seems to be sufficient. I just did not found a spare cycle to build and upload the current state of Git. Thanks for all your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009145449.gx10...@an3as.eu
Re: Updating the fis-gtm package to V6.2-000
Hi Thorsten and Andreas, On 10/09/14 07:37, Andreas Tille wrote: Hi Thorsten, On Thu, Oct 09, 2014 at 12:26:16PM +0200, Thorsten Alteholz wrote: Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by uploading 6.2-000. I think the bug should not be assigned to package fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in fis-gtm-6.2-000 as well) Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after fis-gtm-6.2-000 will be accepted. fis-gtm in version 6.1-000 will vanish after upload of fis-gtm in version 6.2-000. But src:fis-gtm currently creates bin:fis-gtm-6.1-000 and will create bin:fis-gtm-6.2-000 after the upload. Yes. Wasn't the reason for creating the fis-gtm meta package to have different versions in the archive? Otherwise it wouldn't make sense to have the version within the package name. The agreement was that a user could pick some older binary package from snapshot.debian.org which can be installed in parallel to the versioned package. Or the user can install fis-gtm-6.2-000 in addition to an older version - but the older version vanishes from the archive. At least I have understood it this way. I have no idea whether this makes really sense - I'm no fis-gtm user. However, we agreed that for a low popcon package it is not possible to maintain several versions officially. Does this clarify my idea why fixing the licensing issue in fis-gtm-6.2-000 would be sufficient? [amul:11] We have two options at this point regarding fis-gtm-6.1-000. Withdraw the version or update it. We - I, Bhaskar and a few other GT.M developers - are fine with either. If someone could point me to a doc to show how to fix the prior version, I can fix it. My google-fu isn't turning anything up. [amul:11] I looked through https://www.debian.org/doc/manuals/developers-reference for the steps to withdraw the package (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs) and close the bug (https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-bugfix). Is that what I should do? thanks, Amul _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54369ea0.7000...@fisglobal.com
Re: Re: Re: Error while loading shared libraries
I've one more question. Since that libcamp has been uploaded in unstable, how can I configure pbuilder to force it to use sid's packages ? I have seen a documentation about it one month ago, but I'm not able to find it today... Thank you ! Corentin -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54368f4a.8090...@gmail.com
Re: [Package Fastaq] - uscan won't find upstream source - Regex in watch file not working as expected
On Thu, Oct 09, 2014 at 11:01:33AM +0100, Jorge Sebastião Soares wrote: > Source format 1.0 detected, adding exclude flags Please use source format 3.0 (quilt) (if you do not have good reasons not to use it). > dpkg-source -i(?:^|/)\.git(attributes)?(?:$|/.*$) -I.git --before-build > fastaq > dpkg-source: error: source package name 'Fastaq' is illegal: character 'F' > not allowed Dpkg-source is just telling you the problem: Debian packages have lower case names. > js21@builder:~/deb_alioth/current/fastaq_packaging/fastaq$ uscan --verbose > --force-download As always you can find the answer to your question in the Debian Med policy document. You should seek for "package_template". Check out the example watch file and adapt it. You will easily get the same as me, which works nicely and is pushed. > It seems to have replaced the uppercase F with the lowercase f but now it > can't get the source tarball. > > I also tried differenl iterations of the filenamemangle regex: > > opts=filenamemangle=s/F/f/ \ NNOO, please don't try to be more clever than uscan! > and > > opts=filenamemangle=s/(.*)F(.*)/$1f$2/ > > And others... But I still get the same error. Sure. B-) Hope this helps Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009121500.gv10...@an3as.eu
Re: Updating the fis-gtm package to V6.2-000
Hi Thorsten, On Thu, Oct 09, 2014 at 12:26:16PM +0200, Thorsten Alteholz wrote: > >>Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by > >>uploading 6.2-000. I think the bug should not be assigned to package > >>fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in > >>fis-gtm-6.2-000 as well) > > > >Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after > >fis-gtm-6.2-000 will be accepted. > > fis-gtm in version 6.1-000 will vanish after upload of fis-gtm in > version 6.2-000. > But src:fis-gtm currently creates bin:fis-gtm-6.1-000 and will > create bin:fis-gtm-6.2-000 after the upload. Yes. > Wasn't the reason for > creating the fis-gtm meta package to have different versions in the > archive? Otherwise it wouldn't make sense to have the version within > the package name. The agreement was that a user could pick some older binary package from snapshot.debian.org which can be installed in parallel to the versioned package. Or the user can install fis-gtm-6.2-000 in addition to an older version - but the older version vanishes from the archive. At least I have understood it this way. I have no idea whether this makes really sense - I'm no fis-gtm user. However, we agreed that for a low popcon package it is not possible to maintain several versions officially. Does this clarify my idea why fixing the licensing issue in fis-gtm-6.2-000 would be sufficient? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009113732.gt10...@an3as.eu
Re: Updating the fis-gtm package to V6.2-000
Hi Andreas, On Thu, 9 Oct 2014, Andreas Tille wrote: No. We *could* have fixed 6.1-000 before (and it would have migrated to testing then) but since you immediately started working on 6.2 I considered it more sensible to fix it in 6.2 which can close the bug in the same manner. Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by uploading 6.2-000. I think the bug should not be assigned to package fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in fis-gtm-6.2-000 as well) Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after fis-gtm-6.2-000 will be accepted. fis-gtm in version 6.1-000 will vanish after upload of fis-gtm in version 6.2-000. But src:fis-gtm currently creates bin:fis-gtm-6.1-000 and will create bin:fis-gtm-6.2-000 after the upload. Wasn't the reason for creating the fis-gtm meta package to have different versions in the archive? Otherwise it wouldn't make sense to have the version within the package name. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410091215440.7...@jupiter.server.alteholz.net
[Package Fastaq] - uscan won't find upstream source - Regex in watch file not working as expected
Hi all,
I have done a pretty exaustive search online for similar problems.
I also trawled through the Debian Mailing lists for this and couldn't find
a solution.
BEGIN PROBLEM
>
Upstream lives here - https://github.com/sanger-pathogens/Fastaq
Package lives here -
https://alioth.debian.org/anonscm/git/debian-med/fastaq.git/
uscan has no problem downloading the upstream source if the watch file
looks like this:
version=3
https://github.com/sanger-pathogens/Fastaq/tags \
/sanger-pathogens/Fastaq/archive/([.\d]+)\.tar\.gz
Notice the uppercase F in Fastaq.
Running
uscan --verbose --force-download
I get
js21@builder:~/deb_alioth/current/fastaq_packaging/fastaq$ uscan --verbose
--force-download
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://github.com/sanger-pathogens/Fastaq/tags
/sanger-pathogens/Fastaq/archive/([.\d]+)\.tar\.gz
-- Found the following matching hrefs:
/sanger-pathogens/Fastaq/archive/1.5.0.tar.gz
/sanger-pathogens/Fastaq/archive/1.1.0.tar.gz
Newest version on remote site is 1.5.0, local version is 1.5.0
=> Package is up to date
Newest version on remote site is 1.5.0, local version is 1.5.0
=> Forcing download as requested
-- Downloading updated package 1.5.0.tar.gz
-- Successfully downloaded updated package 1.5.0.tar.gz
and symlinked Fastaq_1.5.0.orig.tar.gz to it
-- Scan finished
The source is downloaded. All good there.
When I run git-buildpackage I get:
js21@builder:~/deb_alioth/current/fastaq_packaging/fastaq$ git-buildpackage
--git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new
dh clean --with python3 --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
debian/rules override_dh_auto_clean
make[1]: Entering directory
`/home/js21/deb_alioth/current/fastaq_packaging/fastaq'
rm -rf build .pybuild
make[1]: Leaving directory
`/home/js21/deb_alioth/current/fastaq_packaging/fastaq'
dh_clean -O--buildsystem=pybuild
rm -f debian/fastaq.substvars
rm -f debian/fastaq.*.debhelper
rm -rf debian/fastaq/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} \; \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} \; \) \)
rm -f *-stamp
Building with cowbuilder for distribution sid, architecture amd64
Source format 1.0 detected, adding exclude flags
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: warning: can't parse dependency samtools
asciidoc
dpkg-checkbuilddeps: error: error occurred while parsing
Build-Depends/Build-Depends-Arch/Build-Depends-Indep
W: Unmet build-dependency in source
dpkg-buildpackage: source package Fastaq
dpkg-buildpackage: source version 1.5.0-1
dpkg-buildpackage: source changed by DMPT <
debian-med-packag...@lists.alioth.debian.org>
dpkg-source -i(?:^|/)\.git(attributes)?(?:$|/.*$) -I.git --before-build
fastaq
dpkg-source: error: source package name 'Fastaq' is illegal: character 'F'
not allowed
dpkg-buildpackage: error: dpkg-source -i(?:^|/)\.git(attributes)?(?:$|/.*$)
-I.git --before-build fastaq gave error exit status 255
gbp:error: Couldn't run 'git-pbuilder': git-pbuilder returned 255
I understand why:
dpkg-source: error: source package name 'Fastaq' is illegal: character 'F'
not allowed
So looking at the uscan man page, searching for mangle I find:
# http://foo.bar.org/download/?path=&download_version=0.1.1";>
# could be handled as:
# opts=filenamemangle=s/.*=(.*)/foo-$1\.tar\.gz/ \
#http://foo.bar.org/download/\?path=&download_version=(.+)
So I set the filenamemangle options in the watch file to replace uppercase
F with lowercase f like so:
version=3
opts=filenamemangle=s/F(.*)/f$1/ \
https://github.com/sanger-pathogens/Fastaq/tags \
/sanger-pathogens/Fastaq/archive/([.\d]+)\.tar\.gz
And then run
uscan --verbose --force-download
I get
js21@builder:~/deb_alioth/current/fastaq_packaging/fastaq$ uscan --verbose
--force-download
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
opts=filenamemangle=s/F(.*)/f$1/
https://github.com/sanger-pathogens/Fastaq/tags
/sanger-pathogens/Fastaq/archive/([.\d]+)\.tar\.gz
-- Found the following matching hrefs:
/sanger-pathogens/Fastaq/archive/1.5.0.tar.gz
/sanger-pathogens/Fastaq/archive/1.1.0.tar.gz
Newest version on remote site is 1.5.0, local version is 1.5.0
=> Package is up to date
Newest version on remote site is 1.5.0, local version is 1.5.0
=> Forcing download as requested
-- Downloading updated package /sanger-pathogens/fastaq/archive/1.5.0.tar.gz
uscan warning: ..//sanger-pathogens/fastaq/archive/1.5.0.tar.gz does
Re: Re: Error while loading shared libraries
Hi Andreas,
>> >1557 CMake Error: Could not open file for write in copy operation
/qt.conf.tmp
>> >1558 CMake Error: : System Error: Permission denied
>> >1559 CMake Error at SrcLib/core/fwGuiQt/
> CMakeLists.txt:12 (configure_file):
>> >1560 configure_file Problem configuring file
>> Looks like someone got a path wrong.
I think I fixed the "qt.conf" issue (line 1557). In
SrcLib/core/fwGuiQt/CMakeLists.txt, line 12, I've something like that :
configure_file("${CMAKE_CURRENT_LIST_DIR}/bin/qt.conf"
"${BINPATH}/qt.conf")
However, BINPATH is not declared anymore. It has been replaced by
RUNTIME_OUTPUT_DIR, like that :
configure_file("${CMAKE_CURRENT_LIST_DIR}/bin/qt.conf"
"${RUNTIME_OUTPUT_DIR}/qt.conf")
I can't test if this change fix really the issue, because I have never
seen this log error before, I don't know where find this log.
I pushed debian/patches/fix_qtconf.patch on Alioth.
Thank you,
Corentin
Package naming question: fastaq or python3-fastaq (Was: Package Fastaq git mess)
Hi Jorge, On Thu, Oct 09, 2014 at 10:27:55AM +0100, Jorge Sebastião Soares wrote: > > > I think I'm going to delete the fastaq.git project on git alioth and > > create > > > a new project. Since the code is python3 only I will call it > > python3-fastaq. > > > > Regarding the name: If it is an *application* please stick to the fastaq > > name. Only python modules should have the python[3]- prefix. > > > > https://github.com/sanger-pathogens/Fastaq > Is a set of scripts that need to be installed for > > https://github.com/sanger-pathogens/iva > > to run. > > In that sense, it sort of is a library. But really as I said above, it's > just a set of scripts. > > Should I keep the old nomenclature? I admit I'm a bit unsure since it has Reverse complement all sequences in a file: fastaq_reverse_complement in.fastq out.fastq which looks like an application as well as Here is a template for counting the sequences in a FASTA or FASTQ file: from fastaq import sequences ... which is definitely a Python module. So I keep debian-python in CC - may be they know about a better way to distinguish. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009095022.go10...@an3as.eu
Re: [RFU] praat 5.4.0-1
I prepared a new version of the praat package in Git. Please, upload it to unstable. It is an unpstrem version bump. Thanks, Rafael -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009092747.gc4...@laboissiere.net
Re: Package Fastaq git mess
Hey Andreas, On Thu, Oct 9, 2014 at 10:23 AM, Andreas Tille wrote: > Hi Jorge, > > On Thu, Oct 09, 2014 at 09:45:03AM +0100, Jorge Sebastião Soares wrote: > > I think I'm going to delete the fastaq.git project on git alioth and > create > > a new project. Since the code is python3 only I will call it > python3-fastaq. > > Regarding the name: If it is an *application* please stick to the fastaq > name. Only python modules should have the python[3]- prefix. > https://github.com/sanger-pathogens/Fastaq Is a set of scripts that need to be installed for https://github.com/sanger-pathogens/iva to run. In that sense, it sort of is a library. But really as I said above, it's just a set of scripts. Should I keep the old nomenclature? Regards, Jorge
Re: Package Fastaq git mess
Hi Jorge, On Thu, Oct 09, 2014 at 09:45:03AM +0100, Jorge Sebastião Soares wrote: > I think I'm going to delete the fastaq.git project on git alioth and create > a new project. Since the code is python3 only I will call it python3-fastaq. Regarding the name: If it is an *application* please stick to the fastaq name. Only python modules should have the python[3]- prefix. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009092307.gm10...@an3as.eu
Re: Updating the fis-gtm package to V6.2-000
Hi Thorsten, On Thu, Oct 09, 2014 at 10:07:58AM +0200, Thorsten Alteholz wrote: > On Thu, 9 Oct 2014, Andreas Tille wrote: > >>Does it matter that the bug was submitted against 6.1-000 and we are > >>working on V6.2-000? > > > >No. We *could* have fixed 6.1-000 before (and it would have migrated to > >testing then) but since you immediately started working on 6.2 I > >considered it more sensible to fix it in 6.2 which can close the bug > >in the same manner. > > Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by > uploading 6.2-000. I think the bug should not be assigned to package > fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in > fis-gtm-6.2-000 as well) Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after fis-gtm-6.2-000 will be accepted. The buggy version will remain at snapshot.debian.org in any case and will not vanish because a fixed version will be uploaded. So what exactly would be the profit of another upload in your opinion? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009091849.gl10...@an3as.eu
Re: Package Fastaq git mess
Hi Charles, On Wed, Oct 8, 2014 at 11:30 PM, Charles Plessy wrote: > Le Wed, Oct 08, 2014 at 02:15:59PM +0100, Jorge Sebastião Soares a écrit : > > Hi all, > > > > I've reinitiated work on package Fastaq: > > > > https://github.com/sanger-pathogens/Fastaq > > http://anonscm.debian.org/cgit/debian-med/fastaq.git/ > > … > > > I got: > > > > gbp:error: > > Repository does not have branch 'upstream' for upstream sources. If there > > is none see > > > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT > > on howto create it otherwise use --upstream-branch to specify it. > > Hi Jorge, > > for packages where there is an upstream Git repository, and especially when > their release tarballs are identical to their Git tags, I do not use > git-import-orig anymore. I just use the full upstream master branch as gbp > upstream branch (you can either use the name ‘upstream’ or the original > name > after editing debian/gbp.conf accordingly), and I register the upstream > source > archive using the pristine-tar command directly. > Just to see if I understood this properly. So essentially the gbp upstream branch will point to the upstream master branch. Then to push the upstream source you simply: *pristine-tar commit* tarball tag > This way we get the best of both worlds: a layout fully compatible with the > use of git-buildpackage with pristine-tar, and the full upstream commit > history. > I understand the reason. Otherwise the history of the upstream branch is lost, unless you do some git magic. I think I'm going to delete the fastaq.git project on git alioth and create a new project. Since the code is python3 only I will call it python3-fastaq. And use this new strategy. > > See > http://debian-med.alioth.debian.org/docs/policy.html#updating-git-package > if > you are interested in following that way, and feel free to suggests > enhancements > to that section. > > I think it makes sense and I will follow it. As for suggestions, maybe later when I'm more experienced. :) > Have a nice day, > Thank you. It's probably night there already. So have a good night. Regards, Jorge
Re: Updating the fis-gtm package to V6.2-000
On Thu, 9 Oct 2014, Andreas Tille wrote: Does it matter that the bug was submitted against 6.1-000 and we are working on V6.2-000? No. We *could* have fixed 6.1-000 before (and it would have migrated to testing then) but since you immediately started working on 6.2 I considered it more sensible to fix it in 6.2 which can close the bug in the same manner. Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by uploading 6.2-000. I think the bug should not be assigned to package fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in fis-gtm-6.2-000 as well) Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410090949170.28...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
On Mon, 6 Oct 2014, Bhaskar, K.S wrote: [KSB2] Adding a license exception to the COPYING file would probably require me to go through Legal and that may add delays that increase the risk of pushing us past the deadline. Aah, ok. Would removing the claim of copyright to the reference implementation of the plugin solve the issue? Thanks. I am afraid not, you can not invalidate a license by only adding another layer. So as long as you use the plugin, the openssl license is still valid. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410090858360.25...@jupiter.server.alteholz.net
