Re: Fwd: Re: Help with new package version?
Hi, short notice before I'll be basically offline: I've recreated the packaging repository (please do a fresh git clone), injected latest upstream version and uploaded. I'll leave it for you once you release the next version. ;-) Have a nice weekend Andreas. On Fri, Apr 20, 2018 at 03:32:05PM +0200, Andreas Tille wrote: > Hi Benjamin, > > On Fri, Apr 20, 2018 at 08:47:08AM -0400, Benjamin Redelings wrote: > > Sorry for the delay in responding. To clarify, I wasn't thinking > > of maintaining the /debian/ directory in upstream git, but more that I > > was trying to follow the directions here: > > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html > > Ahh, OK. May be you was attracte by "When upstream uses Git" headline. > > > If I understand you correctly, it is easier to simply import > > tarballs into the salsa repo than to somehow use git to pull upstream > > commits into the salsa repo. > > What is easy depends from your workflow and what you are used to. Since > by far not all upstreams are using Git a large team (according to the > number of packages) can cooperate better if there is only a single > workflow. Thus we settled with the more generic one which does not > depend from the specific feature that upstream uses Git (despite that > becomes more and more popular). > > > This has the downside that I have to > > actually make source tarballs solely for this purpose. > > No you don't. Github is just doing this for you once you are tagging > a release. You can download this very easily by just doing > > uscan --verbose > > (that's what is the debian/watch file is written for). > > > But on the > > positive side it would establish a clear namespace separation between > > e.g. the upstream tags and the debian tags. Also it would be the > > standard workflow for debian-med. Am I understanding things correctly here? > > Yes (except that you have to do extra work to create a tarball which is > not needed). > > > Pending answer to the above question, yes, can you please create a > > pure packaging-related repository? > > I'll do so. > > > Once I understand how to perform the > > gbp magic on this new repository I can be more helpful in releasing new > > versions. > > Its described in Debian Med team policy[1] (seek for git) > > > I will probably ask more questions, but you seem to respond > > pretty quickly, so I guess I should just ask. > > Perfectly fine. As a warning: I'll be less responsive this weekend > (probably starting soon) but I'll let you know when I finished the > refactoring of the packaging Git and usually this list has also other > competent people to answer. > > > thank you for your help! > > You are welcome. > > Kind regards > >Andreas. > > [1] https://debian-med.alioth.debian.org/docs/policy.html > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: Fwd: Re: Help with new package version?
Hi Benjamin, On Fri, Apr 20, 2018 at 08:47:08AM -0400, Benjamin Redelings wrote: > Sorry for the delay in responding. To clarify, I wasn't thinking > of maintaining the /debian/ directory in upstream git, but more that I > was trying to follow the directions here: > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html Ahh, OK. May be you was attracte by "When upstream uses Git" headline. > If I understand you correctly, it is easier to simply import > tarballs into the salsa repo than to somehow use git to pull upstream > commits into the salsa repo. What is easy depends from your workflow and what you are used to. Since by far not all upstreams are using Git a large team (according to the number of packages) can cooperate better if there is only a single workflow. Thus we settled with the more generic one which does not depend from the specific feature that upstream uses Git (despite that becomes more and more popular). > This has the downside that I have to > actually make source tarballs solely for this purpose. No you don't. Github is just doing this for you once you are tagging a release. You can download this very easily by just doing uscan --verbose (that's what is the debian/watch file is written for). > But on the > positive side it would establish a clear namespace separation between > e.g. the upstream tags and the debian tags. Also it would be the > standard workflow for debian-med. Am I understanding things correctly here? Yes (except that you have to do extra work to create a tarball which is not needed). > Pending answer to the above question, yes, can you please create a > pure packaging-related repository? I'll do so. > Once I understand how to perform the > gbp magic on this new repository I can be more helpful in releasing new > versions. Its described in Debian Med team policy[1] (seek for git) > I will probably ask more questions, but you seem to respond > pretty quickly, so I guess I should just ask. Perfectly fine. As a warning: I'll be less responsive this weekend (probably starting soon) but I'll let you know when I finished the refactoring of the packaging Git and usually this list has also other competent people to answer. > thank you for your help! You are welcome. Kind regards Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html -- http://fam-tille.de
Fwd: Re: Help with new package version?
Forgot to Cc this to the list. Forwarded Message Subject:Re: Help with new package version? Date: Fri, 20 Apr 2018 08:44:23 -0400 From: Benjamin Redelings <benjamin.redeli...@gmail.com> To: Andreas Tille <andr...@an3as.eu> Hi Andreas, Sorry for the delay in responding. To clarify, I wasn't thinking of maintaining the /debian/ directory in upstream git, but more that I was trying to follow the directions here: https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html If I understand you correctly, it is easier to simply import tarballs into the salsa repo than to somehow use git to pull upstream commits into the salsa repo. This has the downside that I have to actually make source tarballs solely for this purpose. But on the positive side it would establish a clear namespace separation between e.g. the upstream tags and the debian tags. Also it would be the standard workflow for debian-med. Am I understanding things correctly here? Pending answer to the above question, yes, can you please create a pure packaging-related repository? Once I understand how to perform the gbp magic on this new repository I can be more helpful in releasing new versions. I will probably ask more questions, but you seem to respond pretty quickly, so I guess I should just ask. thank you for your help! -BenRI On 04/20/2018 05:08 AM, Andreas Tille wrote: Hi Benjamin, was this hint helpful? I could volunteer to do the needed steps. However, it would help if you could draw a decision whether you might consider a separate packaging Git repository on salsa.debian.org or whether you intend to continue it beeing a clone of your upstream repository. If you draw a decision I would volunteer to recreate a pure packaging related repository of bali-phy. Kind regards Andreas. On Thu, Mar 29, 2018 at 08:16:54AM +0200, Andreas Tille wrote: Hi Benjamin, On Wed, Mar 28, 2018 at 09:37:05PM -0400, Benjamin Redelings wrote: I've released a new version 3.0.3 of bali-phy, and I realize that I don't understand how to manage the salsa repo using git. I've tried something like this (mostly locally), but I'm pretty sure there is a way of doing this with gbp that is recommended instead: git fetch upstream git fetch upstream --tags git checkout upstream git merge -X theirs 3.0.3 git tag upstream/3.0.3+dfsg git checkout master git merge upstream I assume the problem is that you most probably intend to maintain the Debian repository in your upstream repository. I know that this is somehow possible but I'm lacking experience with this and thus can not give any helpful hint for this approach. We actually had some clones of upstream directories created by other maintainers but I was always running into problems with this (most probably just me!) and since those Debian maintainers got busy with other stuff I turned the repositories in what we consider default repository layout in Debian Med policy[1]. So if qou want to avoid any hassle I'd recommend to do the following: gbp clone g...@salsa.debian.org:med-team/bali-phy.git (may be you rename the resulting dir to bali-phy_debian ??) change to this dir and do uscan --verbose gbp import-orig --pristine-tar This approach is well tested and if something unexpected might happen you can quickly get help here. BTW, I base my assumption that you are using your development Git on the fact that yesterday arrived lots of tags in the Salsa Git repository. I took the freedom to do for tag in `git tag | grep -v -e '^debian' -e '^upstream'` ; do git tag -d $tag git push origin :refs/tags/$tag done since these tags do not make any sense in the current repository on Salsa. I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of 3.0.3+dfsg-1. Well, dch does not know what version bump you intend to do. Just use your editor to fix the version number. Would it be possible to give me the quick overview? My apologies for the basic nature of this question. Your question is perfectly valid and I'm happy to help. Just keep on with asking about any problem you might face. Hope this helps Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures -- http://fam-tille.de
Re: Help with new package version?
Hi Benjamin, was this hint helpful? I could volunteer to do the needed steps. However, it would help if you could draw a decision whether you might consider a separate packaging Git repository on salsa.debian.org or whether you intend to continue it beeing a clone of your upstream repository. If you draw a decision I would volunteer to recreate a pure packaging related repository of bali-phy. Kind regards Andreas. On Thu, Mar 29, 2018 at 08:16:54AM +0200, Andreas Tille wrote: > Hi Benjamin, > > On Wed, Mar 28, 2018 at 09:37:05PM -0400, Benjamin Redelings wrote: > > I've released a new version 3.0.3 of bali-phy, and I realize that I don't > > understand how to manage the salsa repo using git. I've tried something > > like this (mostly locally), but I'm pretty sure there is a way of doing this > > with gbp that is recommended instead: > > > > git fetch upstream > > git fetch upstream --tags > > git checkout upstream > > git merge -X theirs 3.0.3 > > git tag upstream/3.0.3+dfsg > > git checkout master > > git merge upstream > > I assume the problem is that you most probably intend to maintain the > Debian repository in your upstream repository. I know that this is > somehow possible but I'm lacking experience with this and thus can not > give any helpful hint for this approach. We actually had some clones of > upstream directories created by other maintainers but I was always > running into problems with this (most probably just me!) and since those > Debian maintainers got busy with other stuff I turned the repositories > in what we consider default repository layout in Debian Med policy[1]. > > So if qou want to avoid any hassle I'd recommend to do the following: > >gbp clone g...@salsa.debian.org:med-team/bali-phy.git > > (may be you rename the resulting dir to bali-phy_debian ??) change > to this dir and do > >uscan --verbose >gbp import-orig --pristine-tar > > This approach is well tested and if something unexpected might happen > you can quickly get help here. > > BTW, I base my assumption that you are using your development Git on the > fact that yesterday arrived lots of tags in the Salsa Git repository. I > took the freedom to do > > for tag in `git tag | grep -v -e '^debian' -e '^upstream'` ; do > git tag -d $tag > git push origin :refs/tags/$tag > done > > since these tags do not make any sense in the current repository on > Salsa. > > > I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of > > 3.0.3+dfsg-1. > > Well, dch does not know what version bump you intend to do. Just use > your editor to fix the version number. > > > Would it be possible to give me the quick overview? My > > apologies for the basic nature of this question. > > Your question is perfectly valid and I'm happy to help. Just keep > on with asking about any problem you might face. > > Hope this helps > > Andreas. > > > [1] > https://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures > > -- > http://fam-tille.de -- http://fam-tille.de
Re: Help with new package version?
Hi Benjamin, On Wed, Mar 28, 2018 at 09:37:05PM -0400, Benjamin Redelings wrote: > I've released a new version 3.0.3 of bali-phy, and I realize that I don't > understand how to manage the salsa repo using git. I've tried something > like this (mostly locally), but I'm pretty sure there is a way of doing this > with gbp that is recommended instead: > > git fetch upstream > git fetch upstream --tags > git checkout upstream > git merge -X theirs 3.0.3 > git tag upstream/3.0.3+dfsg > git checkout master > git merge upstream I assume the problem is that you most probably intend to maintain the Debian repository in your upstream repository. I know that this is somehow possible but I'm lacking experience with this and thus can not give any helpful hint for this approach. We actually had some clones of upstream directories created by other maintainers but I was always running into problems with this (most probably just me!) and since those Debian maintainers got busy with other stuff I turned the repositories in what we consider default repository layout in Debian Med policy[1]. So if qou want to avoid any hassle I'd recommend to do the following: gbp clone g...@salsa.debian.org:med-team/bali-phy.git (may be you rename the resulting dir to bali-phy_debian ??) change to this dir and do uscan --verbose gbp import-orig --pristine-tar This approach is well tested and if something unexpected might happen you can quickly get help here. BTW, I base my assumption that you are using your development Git on the fact that yesterday arrived lots of tags in the Salsa Git repository. I took the freedom to do for tag in `git tag | grep -v -e '^debian' -e '^upstream'` ; do git tag -d $tag git push origin :refs/tags/$tag done since these tags do not make any sense in the current repository on Salsa. > I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of > 3.0.3+dfsg-1. Well, dch does not know what version bump you intend to do. Just use your editor to fix the version number. > Would it be possible to give me the quick overview? My > apologies for the basic nature of this question. Your question is perfectly valid and I'm happy to help. Just keep on with asking about any problem you might face. Hope this helps Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures -- http://fam-tille.de
Help with new package version?
Hi, I've released a new version 3.0.3 of bali-phy, and I realize that I don't understand how to manage the salsa repo using git. I've tried something like this (mostly locally), but I'm pretty sure there is a way of doing this with gbp that is recommended instead: git fetch upstream git fetch upstream --tags git checkout upstream git merge -X theirs 3.0.3 git tag upstream/3.0.3+dfsg git checkout master git merge upstream I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of 3.0.3+dfsg-1. Would it be possible to give me the quick overview? My apologies for the basic nature of this question. -BenRI
