Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Daniel, i prepared another candidate for the 0.4.6-1 release ( https://salsa.debian.org/spog/git-subrepo/-/commit/f96eeedd0e96b6f2bbcc8c013909de5d5325cafe ), hoping it ticks all the boxes and more:) I made the PR upstream (https://github.com/ingydotnet/git-subrepo/pull/623) and added 'Forwarded' fields with PR to all five patches. I hope that making a separate commit for adding 'Forwarded' field to patches is ok. The 'git-subrepo.d' subdir has been removed upon 'make install' and additional Makefile adjustment done according to your suggestions. Regarding internal test suite, things weren't that trivial, as the implementation requires that the project is a git worktree. However debian builds from a non-git tarball. I fixed that by git-initializing the project on the fly, when needed as well as providing local git configuration for all repos involved in tests. Another thing regarding tests was that they rely upon english output, so tests failed in reprotest, when executed in a French environment for example. By setting fixed locale during each test being run, it all went well. I also went a step further regarding tests. Three test repos being used by several tests were committed upstream as binary bare git repos, which i really do not like. So i prepared a few scripts, which generate the same repos with the same history upon each test suite startup. best regards, Samo
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Daniel, Dne 14.06.2024 (pet) ob 20:50 +0200 je Daniel Gröber napisal(a): > > Below you're not ACK'ing some of my comments again. With email review you > really kind of have to say something about each comment otherwise it's > really hard to tell if you just missed one or not and it's easier to > discuss any disagreements sooner (when I have forgotten less of the context > :x) > rather than later when you send the next version. > I just realized that i sent the unfinished mail instead of saving the draft. I am sorry. I'll add the missing replies here and thanks for the valuable response. > I noticed another thing, w > e disable the test suite for what appear to be > trivial reasons. I really don't like maintaining packages without a test > suite so this is a no-go. Please look into why it's not working and fix it > with more upstreamable patches if necessary. > > From a quick look it seems removing the `git config core.autocrlf input` > call in test/setup already gets us quite far but the way git subrepo finds > its libs needs adjustment too. > > Commit review below: > > > From: Samo Pogačnik > > > > Default 'git-core' location of git-subrepo executables currently > > +The default 'git-core' ... ? thanks > > > does not automatically integrate git-subrepo into git's own bash- > > completion. This change moves git-subrepo executables into > > /usr/share/git-subrepo and adds a symlink of its main executable > > script into /usr/bin to achieve recognition of the 'git subrepo' > > sub-command under the git bash-completion (through git's: > > --list-cmds=...,other,...). > > > > Gbp-Pq: Name 0001-Fixed-bash-completion-integration-with-git.patch > > --- > > Makefile | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 79898f5..3d84454 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -17,7 +17,7 @@ SHARE = share > > > > # Install variables: > > PREFIX ?= /usr/local > > -INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) > > +INSTALL_LIB ?= $(DESTDIR)$(PREFIX)/share/$(NAME) > > While we're fixing upstream's mess $(DESTDIR) should be interpolated in the > install target only so overriding the directory structure is easier. > > The install target should look something like this, vars listed for > clarity: > > ``` > PREFIX ?= /usr/local > INSTALL_LIB ?= $(PREFIX)/share/$(NAME) > install: > $(INSTALL) -d -m 0755 $(DESTDIR)$(INSTALL_LIB)/ > $(INSTALL) -C -m 0755 $(LIB) $(DESTDIR)$(INSTALL_LIB)/ > ``` > > Notice the canonical use of $(INSTALL) instead of the plain command, > doesn't make a difference in this case but it's good Makefile hygiene. > ACK > With that setup we can just export the INSTALL_* vars in debian/rules to > override them: > > export INSTALL_LIB=/usr/share/git-subrepo > export INSTALL_EXT=$(INSTALL_LIB) > > Setting INSTALL_EXT equal to INSTALL_LIB gets rid of the git-subrepo.d as > I've been requesting. > > I'm sending you the full patch "Drop unecessary subdir in usr/share" I used > to test this seperately, lets see if you can figure out how to apply it to > your repo ;) > ACK > You still have to add a seperate commit to make the $(DESTDIR) adjustment. > > > INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d > > INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 > > > > @@ -67,6 +67,8 @@ install: > > install -C -m 0755 $(EXTS) $(INSTALL_EXT)/ > > install -d -m 0755 $(INSTALL_MAN1)/ > > install -C -m 0644 $(MAN1)/$(NAME).1 $(INSTALL_MAN1)/ > > + install -d -m 0755 $(DESTDIR)$(PREFIX)/bin/ > > + ln -s ../share/$(NAME)/$(NAME) $(DESTDIR)$(PREFIX)/bin/$(NAME) > > Creating symlinks like this we'd usually do with dh_link(1). This would be > OK if you're intending to send this patch upstream? > ACK > > --- a/Makefile > > +++ b/Makefile > > @@ -64,7 +64,7 @@ install: > > install -C -m 0755 $(LIB) $(INSTALL_LIB)/ > > sed -i 's!^SUBREPO_EXT_DIR=.*!SUBREPO_EXT_DIR=$(INSTALL_EXT)!' > > $(INSTALL_LIB)/$(NAME) > > install -d -m 0755 $(INSTALL_EXT)/ > > - install -C -m 0755 $(EXTS) $(INSTALL_EXT)/ > > + install -C -m 0644 $(EXTS) $(INSTALL_EXT)/ > > This sort of thing would usually be done in debian/rules to keep things > maintainable. Again if the patch is intended to go upstream it's > acceptable. > ACK > > diff --git a/lib/git-subrepo.d/help-functions.bash b/lib/git-subrepo.d/help- > > functions.bash > > index 123bb54..6dd5c17 100644 > > --- a/lib/git-subrepo.d/help-functions.bash >
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Daniel, Thanks for the review. I'll do my best to include as much as i know how to into another 'release candidate', however it may take me a while. I also have some additional concerns/questions below... Dne 10.06.2024 (pon) ob 22:26 +0200 je Daniel Gröber napisal(a): > In general you're missing the Debian patch metadata, see [DEP-3]. I hate > this archaic stuff I just mention it for completness. If you use gbp-pq for > generating the patches you can mostly ignore. I do like to use the > Forwarded field to note the upstream PR for the patch tho. > > [DEP-3]: https://dep-team.pages.debian.net/deps/dep3/ > > Next time I see the patches I want to see a Forwarded field for each -- one > PR for all of them pleas, not spam upstream :) > I am a bit confused. I'm not sure i want to present patches upstream while you (at least) have not yet accepted them. Otherwise i'd have to revise my upstream proposal (and spam upstream) every time you find another thing i missed about the debian policy (which i probably will for some time). How do you see this? > > Dne 28.05.2024 (tor) ob 19:23 +0200 je Daniel Gröber napisal(a): > > > I'm not super happy with the approach of putting git-subrepo.d inside > > > /usr/share/git-subrepo tbh. I might be able to let it pass but it seems > > > lintian found another issue that needs patching anyway so you may as well > > > fix this too. > > I'm still not seeing a change to remove git-subrepo.d. My comments don't > just go away by ignoring them :P > I am sorry that you felt ignored. I simply thought i have a choice here and tbh i still do not see what could be wrong by having sourced only scripts in a separate subdirectory. I'd be happy to understand your git-subrepo.d concerns better to be able to fully support this decision. > I noticed another thing, w > e disable the test suite for what appear to be > trivial reasons. I really don't like maintaining packages without a test > suite so this is a no-go. Please look into why it's not working and fix it > with more upstreamable patches if necessary. > > From a quick look it seems removing the `git config core.autocrlf input` > call in test/setup already gets us quite far but the way git subrepo finds > its libs needs adjustment too. > > Commit review below: > > > From: Samo Pogačnik > > > > Default 'git-core' location of git-subrepo executables currently > > +The default 'git-core' ... ? thanks > > > does not automatically integrate git-subrepo into git's own bash- > > completion. This change moves git-subrepo executables into > > /usr/share/git-subrepo and adds a symlink of its main executable > > script into /usr/bin to achieve recognition of the 'git subrepo' > > sub-command under the git bash-completion (through git's: > > --list-cmds=...,other,...). > > > > Gbp-Pq: Name 0001-Fixed-bash-completion-integration-with-git.patch > > --- > > Makefile | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 79898f5..3d84454 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -17,7 +17,7 @@ SHARE = share > > > > # Install variables: > > PREFIX ?= /usr/local > > -INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) > > +INSTALL_LIB ?= $(DESTDIR)$(PREFIX)/share/$(NAME) > > While we're fixing upstream's mess $(DESTDIR) should be interpolated in the > install target only so overriding the directory structure is easier. > > The install target should look something like this, vars listed for > clarity: > > ``` > PREFIX ?= /usr/local > INSTALL_LIB ?= $(PREFIX)/share/$(NAME) > install: > $(INSTALL) -d -m 0755 $(DESTDIR)$(INSTALL_LIB)/ > $(INSTALL) -C -m 0755 $(LIB) $(DESTDIR)$(INSTALL_LIB)/ > ``` > > Notice the canonical use of $(INSTALL) instead of the plain command, > doesn't make a difference in this case but it's good Makefile hygiene. > > With that setup we can just export the INSTALL_* vars in debian/rules to > override them: > > export INSTALL_LIB=/usr/share/git-subrepo > export INSTALL_EXT=$(INSTALL_LIB) > > Setting INSTALL_EXT equal to INSTALL_LIB gets rid of the git-subrepo.d as > I've been requesting. > > I'm sending you the full patch "Drop unecessary subdir in usr/share" I used > to test this seperately, lets see if you can figure out how to apply it to > your repo ;) > > You still have to add a seperate commit to make the $(DESTDIR) adjustment. > > > INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d > > INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 > > > > @@ -67,6 +67,8 @@ install: > > install -C -m 0755 $(
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Daniel, Dne 28.05.2024 (tor) ob 19:23 +0200 je Daniel Gröber napisal(a): > I'm not super happy with the approach of putting git-subrepo.d inside > /usr/share/git-subrepo tbh. I might be able to let it pass but it seems > lintian found another issue that needs patching anyway so you may as well > fix this too. > > W: git-subrepo: bash-completion-with-hashbang bash [usr/share/bash- > completion/completions/git-subrepo:1] > W: git-subrepo: executable-not-elf-or-script [usr/share/git-subrepo/git- > subrepo.d/bash+.bash] > W: git-subrepo: mismatched-override executable-not-elf-or-script > usr/lib/git-core/git-subrepo.d/bash+.bash [usr/share/lintian/overrides/git- > subrepo:1] > N: 0 hints overridden; 1 unused override > > indeed bash+.bash is +x but shouldn't be. > > I'm not sure whether bash-completion-with-hashbang should really be W > severity but the '#!bash' it has is certainly completely wrong. Looks like > you'll have to get over your fear of patching upstream ;) > I prepared a new 0.4.6-1 release ( https://salsa.debian.org/spog/git-subrepo/-/commit/ebbc6e9df46b479f1517a5dbd8486b95f511d5be ) with patched upstream regarding: - bash-completition integration with git - executable permissions on sourced-only files - hashbangs inside sourced-only files I've also removed old lintian-override from debian/, since it is not required anymore. --Samo
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Dne 06.05.2024 (pon) ob 15:02 +0200 je Daniel Gröber napisal(a): > > Hmm. I'm not sure I like the idea of abusing libexec in this > way. Technically speaking it's for "internal binaries that are not intended > to be executed directly by users or shell scripts" this is clearly not the > case here. > > Looking over [git-* packages] to see what other packages do I see most git > addons are in fact installed into /usr/bin. > > [git-* packages]: > https://packages.debian.org/search?searchon=contents=git-=filename=stable=any > > Notable exception: git-absorb is still in lib/git-core and has [Bug#985775] > which seems like it may be relevant to our problem. Have a read of it when > you get the chance. Some snippets "Git changed the gitexecdir directory" > maybe that change is what broke completion from git-core? "... git-absorb > works but git's bash completion doesn't suggest absorb" So they are aware > of the completion issue already. > > [Bug#985775]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985775 I also believe, this bug indicates the same problem. Unfortunately nothing have changed since 2021. A reference to a git change in the bug report indicates that one can add completion commands like: git config --global completion.commands subrepo I've tested that and it works, however i am not a fan of this solution, while automatic detection of /usr/bin/git-* is available. > > Anyway. I think the right solution here is to patch git-subrepo. IMO what's > in git-subrepo.d really belongs in /usr/share/git-subrepo OR could just be > concatenated into the main git-subrepo script, hmm. Bonus points for > forwarding this bug and patch upstream. > I prepared another change regarding git bash-completion integration using "/usr/bin" and "/usr/share" in a similar way as some other packages (i.e. dcut, dput, lintian, ...). And yes it may be worth asking upstream how do they feel about the problem. For now i've avoided touching upstream code, but if you prefer i can try to rework the change in upstream code and produce first patch for the package. --Samo
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Daniel, Dne 06.05.2024 (pon) ob 15:02 +0200 je Daniel Gröber napisal(a): > > To be clear force-push should never ever be done when collaborating on the > branche(s) with multiple people, except in the most dire of circumstances > and only if everyone involved is notified appropriately. I'll be happy to > give you commit rights on the repo as soon as you show you've internalised > this :) > I am aware that force-push on shared branches causes a mess for all other branch users. For that reason i'd do initial work on my forked repo to propose changes and use force-push exclusively on my fork to reset its state to what is already in the collab-repo as needed. > I thought we agreed on using plain gbp for now? > Exactly, i temporarily used my old dgitized fork, until a new collab-maint-repo is ready. I am sorry, if i did not explain mysef enough regarding that, while working on bash-completion issue. Now my dgitized repo is unforked and renamed to git-subrepo_dgit and a new fork is created: https://salsa.debian.org/spog/git-subrepo Then i also prepared a fresh update: git clone g...@salsa.debian.org:spog/git-subrepo.git cd git-subrepo/ git remote -v git remote add upstream https://github.com/ingydotnet/git-subrepo.git git remote -v git fetch upstream gbp import-ref -u 0.4.6 gbp dch --snapshot --auto debian/ vim debian/changelog git diff gbp buildpackage --git-ignore-new gbp dch --release --auto git diff git commit -m"Release 0.4.6-1" debian/changelog gbp buildpackage git push git switch upstream git pull upstream master git log git reset --hard HEAD~1 git log git push --tags origin debian/sid upstream git switch debian/sid This is now the updated state pushed into my fork without additional changes regarding bash-completion. > > 73a01 | | * upstream origin/upstream docs: Replace 404$ Edwin Kofler 5M > | |/ > 110b9 | * 0.4.6 Release 0.4.6Austin Morgan 1Y > > The upstream branch is ahead of the 0.4.6 tag. Why? Seems to me you meddled > with the upstream branch by hand instead of letting the tooling take care > of it. Technicaly not a problem just makes me wonder what you're doing. > I wonder why the tool didn't care about it again (see above). Perhaps because the upstream branch has not been checked out initially (oh, i should've probably called gbp clone instead of git clone - my bad). I'll prepare another change regarding bash-completion later. I saw a few examples using "/usr/share" from "/usr/bin" (i.e. dcut, dput, lintian, ...). Anyway, thanks for the thorough review, --Samo
Bug#979188: Maintaining git-subrepo in Debian?
Dne 01.05.2024 (sre) ob 23:09 +0200 je Samo Pogačnik napisal(a): > Hi Daniel, > > After installing our current 'git-subrepo' deb i noticed, that bash-completion > integration with git does not work. The git-subrepo's own bash completion > works, > after you've already typed the first two words 'git subrepo TAB TAB', but the > initial recognition of the 'subrepo' sub-command to the 'git' command does not > work. > > It turns out, that current git (bash-completion) in sid does not recognize our > 'git-subrepo' executables installed by default into the git-core directory. > The > git bash-completion support finds git sub-commands using the 'git --list- > cmds=comma-separated-list-of-cmdgroups', which executes a specific search for > each group. Unfortunately none of the searches brings up the 'subrepo' sub- > command. I do not know what is needed for the 'git-subrepo' inside 'git-core' > to > be recognized there. However i noticed, that the --list-cmds group 'other' > scans > the /usr/bin/ directory, where our old friend 'git-debrebase' and friends > already reside and are being successfully recognized by git. Thus i prepared a > change (in my salsa repo: in > https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the > target installation directory, which seems to work. > > Could you please take a look, how that holds water in debian. > > thanks, Samo Unfortunately, lintian is not happy with my solution above (does not allow subdirs in /usr/bin and however git-subrepo script searches its helper functions in git-subrepo.d subdir in the location of main git-subrepo script). I managed to prepare another solution, without changing upstream sources in a way to move 'git-subrepo' executable scripts into /usr/libexec/git-subrepo and by adding a symlink to main git-subrepo executable into /usr/bin. That way bash- completion integration works as in the initial solution and lintian is also happy. I pushed (forced) the new solution over the previous one. regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, After installing our current 'git-subrepo' deb i noticed, that bash-completion integration with git does not work. The git-subrepo's own bash completion works, after you've already typed the first two words 'git subrepo TAB TAB', but the initial recognition of the 'subrepo' sub-command to the 'git' command does not work. It turns out, that current git (bash-completion) in sid does not recognize our 'git-subrepo' executables installed by default into the git-core directory. The git bash-completion support finds git sub-commands using the 'git --list- cmds=comma-separated-list-of-cmdgroups', which executes a specific search for each group. Unfortunately none of the searches brings up the 'subrepo' sub- command. I do not know what is needed for the 'git-subrepo' inside 'git-core' to be recognized there. However i noticed, that the --list-cmds group 'other' scans the /usr/bin/ directory, where our old friend 'git-debrebase' and friends already reside and are being successfully recognized by git. Thus i prepared a change (in my salsa repo: in https://salsa.debian.org/spog/git-subrepo/-/tree/debian/sid) to change the target installation directory, which seems to work. Could you please take a look, how that holds water in debian. thanks, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Dne 25.04.2024 (čet) ob 12:59 +0200 je Daniel Gröber napisal(a): > On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote: > > Ok, so i'll prepare merge request in salsa gitlab, after pushing my > > change in my working branch? > > So creating a MR is fine but it's not the whole story with gbp. With gbp > you're always dealing with both a debian and an upstream branch so the MR > model doesn't fit since it just deals with the one branch you point it > at. That doesn't really hurt as long as you remember to push your upstream > branch also since I won't be pressing that merge button on the web ui > anyway. > > Technically I can still just assume your upstream branch points to the > upstream/* tag you push -- assuming you don't forget to push the upstream > tag. Seriously this workflow has so many trap doors for DMs it's insane :) > > Anyway. What I want to see is a nice linear series of sensible commits with > your packaging changes and one merge to bring in the new upstream [history] > on the debian branch, the conventional upstream/* tag and the corresponding > upstream branch which should be fast-forward from the previous upstream > history. > > [history]: That's the one default gbp workflow tweak I insist on when it's > possible i.e. when the need for dealing with tarballs doesn't get in the > way. I want git-blame to work in packaging repos. It's increadibly valuable > for debugging but squashing the upstream changes as import-orig defaults to > looses most of that context. > > So you should be doing something like this: > > $ git remote add upstream https://github.com/ingydotnet/git-subrepo.git > $ git fetch upstream > $ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch > # changes and create the merge > $ gbp dch > > $ gbp buildpackage [...sbuild runes...] > > $ git push --tags salsa debian/sid upstream > > There's also `gbp push` to make the git-push easier but it only works after > doing a `gbp tag` to create the debian/* tag. This is however inappropriate > for you as DM to do as the convention is to have the debian tag correspond > to what I upload not what you propose to me :) > > On my side I'll do: > > $ gbp pull samo > > $ gbp buildpackage [...sbuild runes...] > > $ gbp tag# creates the debian/* tag > $ debrelease # upload to ftp-master > $ gbp push salsa > > Hope that gives you something more actionable than my previous mails. > Thanks for this explanation. I suppose we shall apply this workflow upon the git-repo, that you are going to push into the debian/* namespace. As i understand, we are going to push and pull our changes from the same branches of the sam git-repo, however i got a bit confused by your 'gbp pull samo' command which indicates another git-repo involved. If your initial command should've been 'gbp pull salsa', then it is clear to me. > > > PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do > like to keep Debian work public and that includes teaching new > contributors, do you mind if I copy our conversation back to the BTS? I do not mind at all. --Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 24.04.2024 (sre) ob 17:33 +0200 je Daniel Gröber napisal(a): > I'll push the repo there and give you access, you just have to adjust the > Vcs-* fields and get those changes to me in a way that I actually want to > accept them ;P > > FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but > I'm still trying to hone your git collab maintanance skillz :) > Ok, so i'll prepare merge request in salsa gitlab, after pushing my change in my working branch? > > idea was to reverse the gbp's view on its branches, where the debian/sid > > is the continuous branch and the patch-queue branches are the > > intermediate and temporary ones. > > I have to admit I've never really considered this to be a possible > workflow. Honestly I don't think it's a good idea to hold a loaded gun > (gbp) the wrong way round ;) > > Have you found any docs for this workflow? Not really, it was just an idea while reading about gbp and git-debrebase. > > > In this experiment i am trying to have the patch-queue branch the main > > continuous branch, brought (by any git means) to the state, where one > > could do 'gbp pq export' to a fresh debian/sid branch rooted before any > > upstream commits grouped at the end of the patch-queue branch. > > git-subrepo is a relatively simple upstream so I would really not deviate > from established and documented workflows for it. I get you probably want > to explore the possible git workflows in Debian and admittedly my idea to > use git-debrebase is probably also severe overkill (and I'm also guilty of > just wanting to play with it too ;). > > I've thought about it some more and perhaps we should for now use something > simpler (plain gbp) until you get the hang of it and/or the (unapplied) > patches actually get in the way. I agree, i just found my fork of your git-subrepo a nice small playground. As an exercise i've converted it into a git-debrebase tree (via: man 7 git-debrebase: 'converting an existing package'). regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 12.04.2024 (pet) ob 16:02 +0200 je Daniel Gröber napisal(a): > > +git-subrepo (0.4.6-1) unstable; urgency=medium > + > + [ Daniel Gröber ] > + * Fix Vcs URLs, s/guest-dxld/dxld-guest/ > + * Update changelog for 0.4.3-2 release > > Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does > usually filter those out. > > + * Add salsa-ci config > + * Revert "Update changelog for 0.4.3-2 release" > > I would collapse such VCS artifacts too since the changelog is from the > perspective of "what changed since the last version" in the end, not a blow > by blow of the git changes we used to get there. It's a judgement call tho. > > + > + [ Samo Pogačnik ] > + * Updated debian/control info > > Needs to be a lot more specifict than that. In d/changelog you're talking > to two main groups of readers: other Debian contibutors (i.e. me) and > actual end users. Does this tell me what I need to know to figure out why > you made that change? Not really. > > Looking at the diff it should have even been two commits "d/control: Point > Vcs at samo" and "d/control: Make myself Maintainer". > Thanks for the review. I followed your suggestions above and recommited d/control and d/changelog. > As for the Vcs change: I'd prefer if we put the git repo in the debian/* > namespace on Salsa. > Here i am not sure who can / how to do this? > > I also made another git-subrepo_rebase project ( > > https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with > > rebasing of debian branch onto each renewed upstream. I assume rebasing > > workflow > > shoud somehow avoid commiting patch series into main-working branch. I > > understood git-debrebase figured that out, but ... (see below) > > I have a hard time figuring out what is going on in your repos. Damn I > already hate gbp from a review standpoint. > > I'm not sure you've internalized this, with gbp you really don't want to do > any manual git-pull/git-merge calls. Let it do it throught it's > gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of > me when I try to review the package. > I feel i owe you more explanation of what i am trying to achieve here (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The idea was to reverse the gbp's view on its branches, where the debian/sid is the continuous branch and the patch-queue branches are the intermediate and temporary ones. In this experiment i am trying to have the patch-queue branch the main continuous branch, brought (by any git means) to the state, where one could do 'gbp pq export' to a fresh debian/sid branch rooted before any upstream commits grouped at the end of the patch-queue branch. So, when a new upstream version is to be integrated (after pulling the upstream repo): --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/upstream_version). 2. rebasing main patch-queue branch onto upstream at its new release 3. squashing existing d/* commits of previous releases into a single commit 4. do any necessary work on d/* and upstream code to make things work in new version 5. rebase/reorder commits after the squashed commit on patch-queue branch to put any d/* commits in front of any upstream commits 6. create a new debian/sid branch from the latest d/* commit 7. on patch-queue branch run 'gbp pq export' to generate final changes (patches) on new debian/sid --- For each new debian release (same upstream), a similar procedure is needed: --- 1. a copy of current patch-queue/debian/sid branch is to be made for future reference and current debian/sid branch renamed (i.e. *debian/debian_version). 2. do any necessary work on d/* and upstream code to make things work in new debian release 3. rebase/reorder new commits on the patch-queue branch to put any d/* commits in front of any upstream commits 4. create a new debian/sid branch from the latest d/* commit 5. on patch-queue branch run 'gbp pq export' to generate final changes on new debian/sid --- The main problem i face is: How to run test builds directly from patch queue branch to get equivalent 'snapshot' results as from the final debian/sid branch? > > I watched video about git-debrebase and it seemed reasonable to me at first, > > however they lost me when dgit and pushing to dgit repo got into play. > > The history structure does get a bit confusing yeah. My main takeway: > "patches applied" workflows exist *mind blown*. I hadn't seen that yet, > exactly what I've been looking for since gbp-pq sucks and quilt is no > better. I just want to use striaght up git damn it and that's what > debrebase and dgit seems to let you do :) >
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 18.03.2024 (pon) ob 13:55 +0100 je Daniel Gröber napisal(a): > > A good place to start is https://wiki.debian.org/Packaging > > If you prefer a talk format there's Lucas' (excellent) tutorial > https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf > I can't find a recording of it but the slides are pretty extensive. > > In video format there is > https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/ > but I can't vouch for that one. > > We can also do a call to figure out where you're at and what info you need > because the huge scope of the general packaging related documentation can > be a bit overwhelming and confusing, even if what you need to know is like > 5% of that. Thanks for all your input, i'll try to setup the debian/build environment first and go through the provided links. Which debian-specific tools do you find essential in your workflow, so that i can focus on them while reading the docs? regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a): > Hi Samo, > > wouldn't you know it I've become a DD before I got a response to the > git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it > just now. > > Are you still interested in maintaining git-subrepo in Debian? > > I'm trying to limit my personal packaging work to stuff I actually use on a > regular basis and apparently subrepo is not that essential, but as a DD I > can now sponsor any uploads and help you with figuring out the Debian > workflow and such though. > > My packaging from way back when is at > https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably > needs a once over to check for updates necessary changes tho. > > Thanks, > --Daniel Hi Daniel, please excuse me for my late response, but my situation from 2020/21 when we proposed the git-subrepo ITP changed in a way that i am spending most of my free time off-line. With this on mind i am not sure, if i am responsive enough for a maintainers job (i might be off-line for a few weeks from time to time). However, i am tempted to push this through and give git-subrepo more audience. Unfortunately i am more experienced in embedded Linux (yocto / openembedded / bitbake) than in debian packaging and my desktop is more or less Ubuntu. If you think that may shortcomings aren't that much of a showstopper, feel free to send me your procedures/commands to deal with your salsa/git-subrepo repo. I would very much appreciate any guidance regarding debian packaging procedures and needed packaging/testing environment. And of course congratulations on becoming a DD! best regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, I prepared a new git-subrepo in salsa as a fork of your project ( https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and prepared a new 'debian/sid' branch. Would you be so kind to take a look at it and comment on what should be changed/fixed and how to proceed. thanks, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 24.03.2024 (ned) ob 17:46 +0100 je Daniel Gröber napisal(a): > For building I use debuild or git-buildpackage+sbuild depending on context. > > I create chroots for sbuild with a wrapper script around > sbuild-createchroot using btrfs-snapshots for efficiency. > > To keep working on a package without having to reinstall the entire > dependency tree (as sbuild does) every time I tweak sbuild's > --anything-failed-commands or use schroot directly with a different chroot > profile setup which has my homedir mounted. > > I'm not sure all of that is the easiest setup these days. It certainly > needs "gardening" to keep it updated and in-sync between both my laptop and > workstation and I have been looking into alternatives. > Thank you for the valuable information. Currently i managed to reactivate my Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was also able to setup debian-sid chrooted environment on my old Ubuntu laptop up to the point that i think i can successfully rebuild your current 'git-subrepo' project using the following commands after entering 'debian-sid' (schroot -c debian-sid): $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git $ cd git-subrepo $ gbp buildpackage --git-pristine-tar-commit $ gbp buildpackage I hope this is the correct procedure - i wasn't very confident seing 'sbuild' requireing another 'chroot' from within my original 'chroot', however it seems to be working now? My plan now is to fork your git-subrepo project, fetch latest upstream changes and rebuild the latest version. Would that be ok to get to the point, when a new ITP could have been issued? > https://github.com/lkhq/debspawn looks really neat and tidy but may be > untrodden ground. Could be workable if you feel up to trying it. I would > also be curios to know if it works well. See > https://github.com/lkhq/debspawn/issues/27 for some discussion between > ximion (the author) and josh (sbuild maintainer) how it compares against > sbuild. > I might try debspawn on another 'non-debian' 'nixos-based' machine, but this may not happen very quickly. As i understood, it only requires a systemd-based Linux. > When trying to understand how the build tools work and fit together keep in > mind that debuild (the traditional default) is nothing but a wrapper around > dpkg-buildpackage (which has a more extensive manpage) and passess most > options down as-is. git-buildpackage (by default) wraps debuild (or > optionally sbuild if you tell it to). sbuild allows building in chroots and > has a number of fancy options to make that easy. > > Aah, it's nice and warm in the jungle but simetimes you get lost between > all the vines~ > --Daniel I get lost a lot. Three years ago even so that i created new docker-pbuilder- based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my head around debian ways. You can imagine that the project wasn't accepted very well on debian-devel:). thanks again, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, just a quick update. Dne 01.04.2024 (pon) ob 23:07 +0200 je Daniel Gröber napisal(a): > > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html > (note the navigation buttons in the top right) > Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo according to gbp manual and now i am not sure if generated changelog is ok. I also made another git-subrepo_rebase project ( https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with rebasing of debian branch onto each renewed upstream. I assume rebasing workflow shoud somehow avoid commiting patch series into main-working branch. I understood git-debrebase figured that out, but ... (see below) > > > > I wish we could use a rebase workflow with gbp but I haven't found a way to > do it yet. At least not with gbp import-ref as-is. We could work on a patch > for it I suppose ;) > I think i am a bit too green for that, however i may provide some crazy idea:) I watched video about git-debrebase and it seemed reasonable to me at first, however they lost me when dgit and pushing to dgit repo got into play. regards, Samo
Bug#979188: Maintaining git-subrepo in Debian?
Hi Daniel, Dne 31.03.2024 (ned) ob 16:01 +0200 je Daniel Gröber napisal(a): > > You removed the (Closes Bug#) ITP reference from d/changelog. It's policy > to close that but with the first upload, so you have to keep it. > Fixed (even salsa pipeline is happy:). > Workflow wise I don't see why you needed to make a merge commit at > d0cc659. Can you explan what you were doing? > Well, after i updated the upstream branch, i wanted to preserve your original debian/sid branch, so i renamed it and merged it into the new debian/sid branch, based at the latest 0.4.6 release tag of the upstream branch. Actually, this is the point, where i need to learn, how debian/sid branch is to be managed in a 'debianized' git repo through upstream updates? > I don't use pristine-tar unless absolutely required (due to DFSG repacking > or some such), gbp defaults to using git-archive to generate tarballs so > just leave off the pristine-tar options. > > Packaging repos usually declare whether they use pristine-tar in d/gbp.conf > so there should rarely be a need to fiddle with the options here. > I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to 'False' i can simply run 'gbp buildpackage'. Would you recommend setting 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo? > There's another option for importing upstream sources which I prefer (but > that is a bit of a PITA): `gbp import-ref` it is a pure git workflow > leaving the tarball hassle to gbp and that preserves upstream git history > and git-blame'ability. > > Admittedly it's not very widely used in Debian ATM (which may change thanks > to the current xz kerfluffle) so docs may be lacking. Let me know if you > can't figure it out. > something new for me to digest:) Actually i preserved upstream history in my manual git-subrepo upstream branch update and lost your history in new debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer upstream could solve that as well... > sbuild calls schroot internally. You run it from your system like > normal. You just have to configure a tell it which base chroot to use and > that chroot needs special handling to be as close to the buildd ones as > feasible. Relevant chroot bootstrapping tools often have an > "sbuild"/"buildd" mode. > > I tend to use sbuild-createchroot(8) from ubuntu-dev-tools > for chroot > building, but debspawn is probably orders of magnitudes easier as far as > setup and maintainance of the environments is concerned. > Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild) to create chroot used by sbuild, however sbuild is not run from my old ubuntu host directly, but from 'schroot -c debian-sid' prepared previously (see: https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild) > You don't need a new ITP, it's still open and valid. If you want to be > proper you can change the "owner" field to yourself. Send an email to > cont...@bugs.debian.org, see > https://www.debian.org/Bugs/server-control. Good practice for interacting > with the BTS anyway. > noted and thanks for valuable insights. best regards, Samo
Bug#962385: RFS: git-subrepo/0.4.1~2 [ITP] -- GIT Submodule alternative
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "git-subrepo" * Package name: git-subrepo Version : 0.4.1~2 Upstream Author : Ingy döt Net * URL : https://github.com/ingydotnet/git-subrepo * License : MIT * Vcs : https://github.com/spog/git-subrepo-debian Section : vcs It builds those binary packages: git-subrepo - GIT Submodule alternative To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-subrepo Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc Changes since the last upload: [ spog ] * Fixed reading installed subrepo command info. * Added subrepo to git completion commands . [ admorgan ] * Fix Bash version error messages and add to .rc * Nicer YAML formatting in .travis.yml * Wrap a long line * Update the docs * Force `make update` to always update docs * Don't use XXX in perl stuff * Add testing on MacOS * Remove conflicting -C from install -d commands. * Update version requirement documentation * Correct error message in branch * Use topo-order in subrepo branch * Make “git subrepo clean -f ...” delete refs correctly * Fix #410 Push empty repositories with recent git versions * Make subrepo work when run in a worktree * Simplify finding subrepos * Ask git to find the .gitrepo files * Doc: fix sentence repetition * Fix typos * Fixed typo * Travis CI not checking out a branch. Regards, -- Samo Pogačnik
Bug#962349: RFS: git-subrepo/0.4.1~2 -- GIT Submodule alternative
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "git-subrepo" * Package name: git-subrepo Version : 0.4.1~2 Upstream Author : Ingy döt Net * URL : https://github.com/ingydotnet/git-subrepo * License : MIT * Vcs : https://github.com/spog/git-subrepo-debian Section : vcs It builds those binary packages: git-subrepo - GIT Submodule alternative To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-subrepo Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc Changes since the last upload: [ spog ] * Fixed reading installed subrepo command info. * Added subrepo to git completion commands . [ admorgan ] * Fix Bash version error messages and add to .rc * Nicer YAML formatting in .travis.yml * Wrap a long line * Update the docs * Force `make update` to always update docs * Don't use XXX in perl stuff * Add testing on MacOS * Remove conflicting -C from install -d commands. * Update version requirement documentation * Correct error message in branch * Use topo-order in subrepo branch * Make “git subrepo clean -f ...” delete refs correctly * Fix #410 Push empty repositories with recent git versions * Make subrepo work when run in a worktree * Simplify finding subrepos * Ask git to find the .gitrepo files * Doc: fix sentence repetition * Fix typos * Fixed typo * Travis CI not checking out a branch. Regards, -- Samo Pogačnik
Bug#962321: RFS: git-subrepo/0.4.1~2 -- GIT Submodule alternative
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "git-subrepo" * Package name: git-subrepo Version : 0.4.1~2 Upstream Author : [Ingy dot Net ] * URL : [https://github.com/ingydotnet/git-subrepo] * License : [MIT] * Vcs : None Section : vcs It builds those binary packages: git-subrepo - GIT Submodule alternative To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-subrepo Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc Changes since the last upload: [ spog ] * Fixed reading installed subrepo command info. * Added subrepo to git completion commands . [ admorgan ] * Fix Bash version error messages and add to .rc * Nicer YAML formatting in .travis.yml * Wrap a long line * Update the docs * Force `make update` to always update docs * Don't use XXX in perl stuff * Add testing on MacOS * Remove conflicting -C from install -d commands. * Update version requirement documentation * Correct error message in branch * Use topo-order in subrepo branch * Make “git subrepo clean -f ...” delete refs correctly * Fix #410 Push empty repositories with recent git versions * Make subrepo work when run in a worktree * Simplify finding subrepos * Ask git to find the .gitrepo files * Doc: fix sentence repetition * Fix typos * Fixed typo * Travis CI not checking out a branch. Regards, -- Samo Pogačnik
