Re: Git repository of htslib is lacking pristine-tar
Le Wed, Jul 29, 2015 at 09:40:41AM +0100, Ghislain Vaillant a écrit : > > FYI, I am intending to write a piece on the d-science / d-med policies > regarding DEP-14 and its relationship with import-orig and pure Git > workflows. Just need to find the time for it. Thanks Ghislain, when editing our group policy, you will see that whitespace indentation is a mess. Do not hestiate to take action if you wish. Also, if you are unfamiliar with DocBook, please do not hesitate to ask questions. For editing the source, I recommend jEdit, which is packaged in Debian, has nice soft-wrap and soft-inentation modes (to match the whitespace practice in some section of the source), and most importanly a nice XML checker and tag completion. On command line, xmllint is useful as well. 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-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730045928.ge1...@falafel.plessy.net
Re: Git repository of htslib is lacking pristine-tar
On 29/07/15 08:54, Andreas Tille wrote: Hi Charles, On Wed, Jul 29, 2015 at 03:26:55PM +0900, Charles Plessy wrote: ... instead, I used: pristine-tar commit /tmp/htslib-1.2.1.tar.gz 1.2.1 As a result, git-buildpackage did not manage to find the pristine-tar information. This is what I realised afterwards. :-) In any case, please note that uscan or apt-get source can also provide you with an upstream tarball if you are connected to Internet. Since it regularly happens that people mess up with the pristine-tar branch (for example by forgetting to push it), this is an important workaround to remember. Sure. I'm perfectly aware of this. However, I always have the hope that more people become involved in our packages and so it helps if things are in the order they should be. Getting a beginner frustrated if gbp does not work out of the box is not helpful. I do not want to be a blocker, but on packages like htslib, I do not want to work with the pristine tarball workflow. Given that I am obviouly unable to follow your pace, I will understand if you remove my name from the Uploaders field and go ahead without me. But if you do that for all my packages, maybe you will have too much work as well ... so we must compromise :) As I said I'm willing to learn and may be I will like this workflow at some point in time. So I rather try to understand what you are doing (and I also need to spend some time into DEP-14) and we might find an alternative workflow that should be documented properly. BTW, about my pace: I'm more and more realising that it does not scale if I do the large amount of bug fixing in the Debian Med team[1]. Since I'm currenly at home (this time will end next week) I fixed more than one bug per day. We have *lots* of easy to fix targets. If a newcomer would try to fix two bugs per month he would make it into the bugs statistics[1] after one years. I bet there are more than 24 easy targets at belonging to the Debian Med team[2]. I think that the main problem is that I did not manage to document the workflow on time before reducing my activity. Otherwise, I think that it works fine. Nevertheless, there may be changes in the future, for instance to harmonise with DEP 14. I think the latter should be approached since it is documented by nature. In short: Just relax and care about your family. I hope for more bug fixers and will think about methods to strengthen the awareness that we need some more action here. Kind regards Andreas. [1] http://blends.debian.net/liststats/bugs_debian-med.png [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-packag...@lists.alioth.debian.org FYI, I am intending to write a piece on the d-science / d-med policies regarding DEP-14 and its relationship with import-orig and pure Git workflows. Just need to find the time for it. Meanwhile, should you have any questions wrt the layout of your packaging Charles, feel free to contact us. We have all been newcomers and are still learning as well. Regarding your pace, this is something you need to find by yourself. Some people maintains a handful of packages, some more, some less, some focuses on bug fixing, documentation and so on. In the end, "every little helps". Best regards, Ghis -- 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/55b89189.7090...@gmail.com
Re: Git repository of htslib is lacking pristine-tar
Hi Charles, On Wed, Jul 29, 2015 at 03:26:55PM +0900, Charles Plessy wrote: > ... > instead, I used: > > pristine-tar commit /tmp/htslib-1.2.1.tar.gz 1.2.1 > > As a result, git-buildpackage did not manage to find the pristine-tar > information. This is what I realised afterwards. :-) > In any case, please note that uscan or apt-get source can also provide you > with > an upstream tarball if you are connected to Internet. Since it regularly > happens that people mess up with the pristine-tar branch (for example by > forgetting to push it), this is an important workaround to remember. Sure. I'm perfectly aware of this. However, I always have the hope that more people become involved in our packages and so it helps if things are in the order they should be. Getting a beginner frustrated if gbp does not work out of the box is not helpful. > I do not want to be a blocker, but on packages like htslib, I do not want to > work with the pristine tarball workflow. Given that I am obviouly unable to > follow your pace, I will understand if you remove my name from the Uploaders > field and go ahead without me. But if you do that for all my packages, > maybe you will have too much work as well ... so we must compromise :) As I said I'm willing to learn and may be I will like this workflow at some point in time. So I rather try to understand what you are doing (and I also need to spend some time into DEP-14) and we might find an alternative workflow that should be documented properly. BTW, about my pace: I'm more and more realising that it does not scale if I do the large amount of bug fixing in the Debian Med team[1]. Since I'm currenly at home (this time will end next week) I fixed more than one bug per day. We have *lots* of easy to fix targets. If a newcomer would try to fix two bugs per month he would make it into the bugs statistics[1] after one years. I bet there are more than 24 easy targets at belonging to the Debian Med team[2]. > I think that the main problem is that I did not manage to document the > workflow > on time before reducing my activity. Otherwise, I think that it works fine. > Nevertheless, there may be changes in the future, for instance to harmonise > with DEP 14. I think the latter should be approached since it is documented by nature. In short: Just relax and care about your family. I hope for more bug fixers and will think about methods to strengthen the awareness that we need some more action here. Kind regards Andreas. [1] http://blends.debian.net/liststats/bugs_debian-med.png [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-packag...@lists.alioth.debian.org -- 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/20150729075438.gi16...@an3as.eu
Re: Git repository of htslib is lacking pristine-tar
Le Tue, Jul 28, 2015 at 12:19:10PM +0200, Andreas Tille a écrit : > > $ gbp clone ssh://git.debian.org/git/debian-med/htslib.git > $ cd htslib > $ gbp buildpackage > gbp:info: Orig tarball 'htslib_1.2.1.orig.tar.gz' not found at '../tarballs/' > gbp:error: Pristine-tar couldn't checkout "htslib_1.2.1.orig.tar.gz": fatal: > Path 'htslib_1.2.1.orig.tar.gz.delta' does not exist in > 'refs/heads/pristine-tar' > pristine-tar: git show refs/heads/pristine-tar:htslib_1.2.1.orig.tar.gz.delta > failed > > I tried: > > $ pristine-tar commit ../htslib_1.2.1.orig.tar.gz v1.2.1 > pristine-tar: failed to find ref using: git show-ref v1.2.1 > > which I took from bedtools debian/README.source. It seems that the 'v' > in front of the version number in the end needs to be left our here. I > commited an according README.source Hi Andreas, indeed, "pristine-tar commit" takes a tarball and a git tag as arguments, and the htslib upstream authors tag their releases with plain version numbers, without "v" on front. For htslib, I am sorry that I did not run "pristine-tar commit" well. I should have used the following command: pristine-tar commit /tmp/htslib_1.2.1.orig.tar.gz 1.2.1 instead, I used: pristine-tar commit /tmp/htslib-1.2.1.tar.gz 1.2.1 As a result, git-buildpackage did not manage to find the pristine-tar information. htslib-1.2.1.tar.gz is the name of the file downloaded by uscan (htslib_1.2.1.orig.tar.gz) is a symlink, and I picked it up by mistake. Sorry again for this. Fortunately, the instructions that we discussed on this list and that you used as README.source are correct about which file name to use. In any case, please note that uscan or apt-get source can also provide you with an upstream tarball if you are connected to Internet. Since it regularly happens that people mess up with the pristine-tar branch (for example by forgetting to push it), this is an important workaround to remember. > I admit I'm not yet convinced that the chance to enable upstream pull > requests are worth the drawback that other team members have trouble > to follow an undocumented workflow. It is not just about pull requests, it is about working with the same Git history as Upstream. When building fails, I find this property to be very important. I do not want to be a blocker, but on packages like htslib, I do not want to work with the pristine tarball workflow. Given that I am obviouly unable to follow your pace, I will understand if you remove my name from the Uploaders field and go ahead without me. But if you do that for all my packages, maybe you will have too much work as well ... so we must compromise :) I think that the main problem is that I did not manage to document the workflow on time before reducing my activity. Otherwise, I think that it works fine. Nevertheless, there may be changes in the future, for instance to harmonise with DEP 14. 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-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150729062655.gc19...@falafel.plessy.net
Re: Git repository of htslib is lacking pristine-tar
On Tue, Jul 28, 2015 at 11:53:48AM +0100, Ghislain Vaillant wrote: > > You can normally do: > > gbp buildpackage --git-upstream-tag=v1.2.1 \ > --git-debian-branch=debian/unstable \ > --git-no-pristine-tar \ > --git-pristine-tar-commit > > The last 2 options explicitly tell gbp that a pristine-tar commit does not > exist yet for this tag and that is should generate a tarball and commit one. That's probably possible in theory but this is not my problem. I could also easily have copyied the tarball to ../tarballs to work around this. However, *creating* a tarball out of no information would be definitely the wrong way to go since there is such a tarball with a certain MD5sum in the Debian archive and thus chances for creating a second one with a different MD5sum would be quite high and thus this procedure definitely not acceptable in the given situation. > This is a beginning of a documented workflow following DEP-14: > http://blog.mycre.ws/articles/git-packaging-workflow-for-py-lmdb/ I know that there is DEP-14 but Charles has introduced "something else" in a certain set of packages and I keep on trying to warm up with this but failed so far. 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/20150728114042.gr16...@an3as.eu
Re: Git repository of htslib is lacking pristine-tar
On 28/07/15 11:19, Andreas Tille wrote: Hi Charles, $ gbp clone ssh://git.debian.org/git/debian-med/htslib.git $ cd htslib $ gbp buildpackage gbp:info: Orig tarball 'htslib_1.2.1.orig.tar.gz' not found at '../tarballs/' gbp:error: Pristine-tar couldn't checkout "htslib_1.2.1.orig.tar.gz": fatal: Path 'htslib_1.2.1.orig.tar.gz.delta' does not exist in 'refs/heads/pristine-tar' pristine-tar: git show refs/heads/pristine-tar:htslib_1.2.1.orig.tar.gz.delta failed I tried: $ pristine-tar commit ../htslib_1.2.1.orig.tar.gz v1.2.1 pristine-tar: failed to find ref using: git show-ref v1.2.1 which I took from bedtools debian/README.source. It seems that the 'v' in front of the version number in the end needs to be left our here. I commited an according README.source. I admit I'm not yet convinced that the chance to enable upstream pull requests are worth the drawback that other team members have trouble to follow an undocumented workflow. Kind regards Andreas. You can normally do: gbp buildpackage --git-upstream-tag=v1.2.1 \ --git-debian-branch=debian/unstable \ --git-no-pristine-tar \ --git-pristine-tar-commit The last 2 options explicitly tell gbp that a pristine-tar commit does not exist yet for this tag and that is should generate a tarball and commit one. In case the tarball for the current tag already exist in pristine-tar, these options are simply ignored. This is a beginning of a documented workflow following DEP-14: http://blog.mycre.ws/articles/git-packaging-workflow-for-py-lmdb/ Ghis -- 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/55b75f3c.1000...@gmail.com
Git repository of htslib is lacking pristine-tar
Hi Charles, $ gbp clone ssh://git.debian.org/git/debian-med/htslib.git $ cd htslib $ gbp buildpackage gbp:info: Orig tarball 'htslib_1.2.1.orig.tar.gz' not found at '../tarballs/' gbp:error: Pristine-tar couldn't checkout "htslib_1.2.1.orig.tar.gz": fatal: Path 'htslib_1.2.1.orig.tar.gz.delta' does not exist in 'refs/heads/pristine-tar' pristine-tar: git show refs/heads/pristine-tar:htslib_1.2.1.orig.tar.gz.delta failed I tried: $ pristine-tar commit ../htslib_1.2.1.orig.tar.gz v1.2.1 pristine-tar: failed to find ref using: git show-ref v1.2.1 which I took from bedtools debian/README.source. It seems that the 'v' in front of the version number in the end needs to be left our here. I commited an according README.source. I admit I'm not yet convinced that the chance to enable upstream pull requests are worth the drawback that other team members have trouble to follow an undocumented workflow. 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/20150728101910.go16...@an3as.eu
