2015-03-19 13:10 GMT+00:00 Andreas Tille <andr...@an3as.eu>: > Hi Ghislain, > > On Tue, Mar 17, 2015 at 11:51:28PM +0000, Ghislain Vaillant wrote: > > Hi Andreas, > > > > For this package, I have experimented on an alternative layout for the > git > > repository, following > > the section entitled "When upstream uses Git" in the git-buildpackage > > manual [1]. > > > > Since the repository only contains the "debian/sid" and "pristine-tar" > > branches (no upstream or > > master), it does not play very nice with the defaults of gbp-clone and > co. > > > > I can definitely checkout the repository with the following command: > > gbp-clone git+ssh://git.debian.org/git/debian-med/irtk.git > > --upstream-branch=master --debian-branch=debian/sid > > While I can confirm that this worked now I have two problem with this > approach which I have no sensible solution for but we should find some > clue: > > 1. How to know in advance that this scheme is used? > Even if you can not know this in advance the method you are > using should be documented in detail in the team policy (feel > free to edit the policy document). > > I don't know. gbp usually assumes you have an upstream and a debian branch. How to handle the particular case where only pristine-tar and the debian branch are used is beyond my knowledge.
> 2. The method that is currently used to fetch machine readable data > from packages in VCS fails. Is based on: > > tille@moszumanska:/git/debian-med/irtk.git$ git ls-tree -r HEAD debian/ > fatal: Not a valid object name HEAD > > Here is a random example what is expected: > > tille@moszumanska:/git/debian-med/irtk.git$ cd ../ipig.git/ > tille@moszumanska:/git/debian-med/ipig.git$ git ls-tree -r HEAD debian/ > 100644 blob cba7e1853702e26bee937c80153166337c4cbdaa debian/build.xml > 100644 blob bc9a75ff0e4704e5dee767b429b61b1ab11c9694 debian/changelog > 100644 blob ec635144f60048986bc560c5576355344005e6e7 debian/compat > 100644 blob 9280cf8b5b22ede16c8b8612286b898d4ab1d0e6 debian/control > 100644 blob fcd466a5c2daeeeb5ed94cf62d0e9a13b01c5f76 debian/copyright > 100755 blob fa6488b7d78b26bbf6bf040242c782d550ad5fc0 > debian/createmanpages > 100755 blob 1c33f8ab4b05a1e2f3dc0e8d47e1393516e45a75 > debian/get-orig-source > 100644 blob 8eead9d92f4ea99eb3a2937042503d129cd0c8c7 debian/ipig.1 > 100644 blob e77248175524d9f63749c2d6ca67159eeb4aa635 debian/ipig.dirs > 100644 blob c76b352b696e5ab9deaabff1cad7ce3b8aac397d debian/ipig.jlibs > 100755 blob 816d3cf34a295cea00d7cec768dcb6434572c93a debian/ipig.sh > 100644 blob 0f651869c921dec14bcfa53fe5e807692afbfb78 debian/manpages > 100755 blob f44b6242f4a022b60055c6f5754f05014189f030 debian/rules > 100644 blob 163aaf8d82b6c54f23c45f32895dbdfdcc27b047 > debian/source/format > 100644 blob d1d8ed7adac29cacfcf20739b05f80d945c55720 > debian/upstream/metadata > 100644 blob feb8aa3e1959e34bd2085d5ba2b65c62a8a161c1 debian/watch > > > Can you provide a safe way to get the metadata if even > git ls-tree -r HEAD > fails (not mentioning the restriction to debian/ dir). > > I cannot. I should have used the method described in the policy in the first place. > > I'm not against establishing new methods if they fit some needes better. > However, we need to adapt the documentation and the tools we use to > these methods. > > > And build with: > > gbp buildpackage --git-upstream-tag='v%(version)s' > > --git-debian-branch=debian/sid > > Not tested - but it should also make its way into policy > > Again, this is just an experiment and probably not something you would document in the policy yet. > > I quite like the workflow explained in the manual, > > We should at least link to the manual[1] and give some guidelines when > it makes sense to use this method. > > > where you just fetch the > > new upstream tag, > > merge in a debian/<release> branch and use the --git-upstream-tag option > to > > specify the > > upstream source. I'll get back to the usual workflow with "gbp > import-orig" > > if that is a > > problem, it was really just by curiosity that I tried this. > > As I said: I do not want to suppress any progress in our tool set. But > as long as it is not documented in our policy and we have made sure all > our tools are working on it whe should be a bit carefully. > > I have barely tested this method and I can see no immediate advantage of using it, besides avoiding duplication between the pristine-tar and upstream branches. The last question about irtk: Do you think it should be Recommended by > med-imaging or just Suggested? Too early to say. I also have some concerns on the licensing of some of the components, which I have to sort out first. That's why I did not even file an ITP for it yet. I personally can not obtain the > relevance for medicine in the package description - or may be the > description could be enhanced? I am aware that the description is too succinct. I am working with upstream on that. > As I said the package will only show up > once the metadata can be read from Git with the usual procedure or you > suggest a patch which contains a fallback for > > $ git ls-tree -r HEAD debian/ > fatal: Not a valid object name HEAD > > which points to the debian/ files. > > Kind regards > > Andreas. > > > [1] > > > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html > > -- > 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/20150319131011.gc28...@an3as.eu > > I probably should pull the source package out of d-med, let it brew in my github repository, test it on launchpad and come back once the licensing stuff is sorted. That way I could start fresh with the repository on d-med and follow the policy. Many thanks for your feedback, Ghis
