Re: Was: Im stuck
On Wed, Jul 10, 2024 at 12:57:48PM +0100, Peter B wrote: > On 04/07/2024 14:44, Daniel Gröber wrote: > > Sponsors are more likeley to pick up a package if it's personally > > interesting to them, > > Something that might help here, is for the RFS template to include the > long description of the package. The way I see it for new packages the description and a pitch on the ML have a different focus and just using the exact same text for both purposes is suboptimal, but I'd rather have the long description than only the oneline summary :) > Otherwise, potential sponsors have to unpack the source package to find out > what it does. Right. mentors.d.o also doesn't show it (I thought it did). --Daniel signature.asc Description: PGP signature
Was: Im stuck
On Thu, Jul 04, 2024 at 06:28:17PM +0500, Andrey Rakhmatullin wrote: > On Thu, Jul 04, 2024 at 03:22:35PM +0200, Daniel Gröber wrote: > > > I don't think this is necessary or helpful: most RFSes are sponsored > > > because they are in a good shape and somebody decided to sponsor them, not > > > because a sponsor is actually interested in that software. > > > https://mentors.debian.net/sponsors/ makes sense to me: you either find a > > > relevant team or wait until people that sponsor random packages sponsor > > > yours. Knowing what does the package actually do is mostly useful to skip > > > ones that don't deserve sponsoring. > > > > Andrey, when was the last time you requested sponsorship on a package with > > an identity that's not yet well established in the project? Perhaps you > > should try it next time you want to have something in Debian and see what > > happens. > > Sorry? I know that we have a problem with not having enough sponsors and > that many RFSes, especially for new packages, are open for months, I'm > just saying that providing more info about a package won't help solve it. Sponsors are more likeley to pick up a package if it's personally interesting to them, that's just human nature. Making the ITP/RFS more appealing doesn't really fix the root cause, no, but many of us work on Debian because it's intrinically interesting, no? So why shouldn't new contributors try to maximize the appeal of their work to motivate us DDs to look at it? More motivation for sponsors -> fewer sponsors needed overall :) --Daniel signature.asc Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 05:26:03PM +0500, Andrey Rakhmatullin wrote:
> > It's complicated^{TM}. The sponsorship docs don't actually guide people on
> > how to get others interested in their work
>
> I don't think this is necessary or helpful: most RFSes are sponsored
> because they are in a good shape and somebody decided to sponsor them, not
> because a sponsor is actually interested in that software.
> https://mentors.debian.net/sponsors/ makes sense to me: you either find a
> relevant team or wait until people that sponsor random packages sponsor
> yours. Knowing what does the package actually do is mostly useful to skip
> ones that don't deserve sponsoring.
Andrey, when was the last time you requested sponsorship on a package with
an identity that's not yet well established in the project? Perhaps you
should try it next time you want to have something in Debian and see what
happens.
--Daniel
signature.asc
Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 04:30:43PM +0500, Andrey Rakhmatullin wrote:
> You don't need to CC debian-mentors on ITPs, you don't use ITPs to ask for
> sponsorship and RFSes are sent to debian-mentors automatically.
It's complicated^{TM}. The sponsorship docs don't actually guide people on
how to get others interested in their work, this usually causes RFSen with
basically no description of what the package actually does -- I'm not
surprised when no one replies to those.
Now I could have gone on a rant about how to do that properly, but figured:
you know what, it's easier to just CC the ITP to d-mentors too since that
ought to have the full description.
--Daniel
PS: I was looking at the wrong wnpp bug :D
signature.asc
Description: PGP signature
Re: Im stuck
Hi Jeremy, On Thu, Jul 04, 2024 at 07:55:03AM -0300, Jeremy Theler wrote: > I'm pretty much in the same position. > > There is an RFP bug report at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068648 > but got no response. RFP means "someone else please do this", you need to file an RFS if you're actively looking for a sponsor and want to package/maintain the package yourself. https://mentors.debian.net/sponsors/rfs-howto/ RFP is more of a +1 vote on this software being useful, which can be useful to convince people it should be in Debian. However I'm not aware of any DDs actively watching those bugs for things to work on. It also looks like you didn't CC debian-devel (sending to debian-science instead) on the ITP as per devref https://www.debian.org/doc/manuals/developers-reference/pkgs.html#new-packages that's usually how DDs outside of debian-mentors learn about new (potentially interesting) packages. In the future you might consider CC'ing debian-mentors on ITPs you want sponsored anyway, just in case some mentors aren't subscribed to d-devel. Alternatively including the elaborate description from the ITP in the RFS is a good idea too. CC'ing a more focused list like d-science in the ITP/RFS isn't a bad idea either. tl;dr: more CCs == more better. Just don't go too crazy. --Daniel signature.asc Description: PGP signature
Bug#1074498: RFS: baby/1.0-2 [ITP] -- Abbreviate long commands in terminal
Hi Manuel, On Sat, Jun 29, 2024 at 08:23:14PM -0300, Manuel Guerra wrote: > I completely understand what you are saying about the program not being > very useful for Debian, it has few functions but I hope to expand it later. I'd recommend incubating your idea in the wider FLOSS community (which I admit can be hard to get a foot into). Distributions are only really interested in programs once they've reached a level of usefulnes you can usually only get to by either having lots of experience already or getting feedback from others. However Debian unstable is not the right place to gather this early stage feedback for something like this. You can try IRC or other Debian community spaces https://wiki.debian.org/Community, but I'm not sure we have anything that's quite right for you. Hmm. > Regarding the tarball and the binary included in the package, I will solve > it as soon as possible. This error is because I am new to the world of free > software and it took me a long time to get to this point since I have done > everything self-taught, breaking my brain reading forums on the web. Admirable :) You should try to find a community space where people at a comparable (but maybe slightly higher) skill level as you hang out. I'm afraid I'm not much help with specifics here. --Daniel signature.asc Description: PGP signature
Bug#1074498: RFS: baby/1.0-2 [ITP] -- Abbreviate long commands in terminal
Hi Manuel, On Sat, Jun 29, 2024 at 05:50:53PM -0400, Manuel Guerra wrote: > * Package name : baby >Version : 1.0-2 >Upstream contact : Manuel Guerra > * URL : https://github.com/manuwarfare/baby > * License : GPL-3+ > * Vcs : https://salsa.debian.org/manuwarfare/baby >Section : utils > > The source builds the following binary packages: > > baby - Abbreviate long commands in terminal The README pitch sounds interesting, but I fear there's not enough documentation (or useful functionality) at this point for this to be useful in Debian. I'm afraid your packaging also has severe problems. Somehow you've included a tarball in the (unpacked) source package as well as a binary of your program. The latter is a no-go in Debian (main) that we'd ordinarily fix during packaging, but since you're upstream you ought to just fix your source package build. Have a read of the DFSG and perhaps a friendly packaging tutorial[1]. [ I can't find a better reference for the pedantic (but necessary) definition of what we consider source code that obviously explains that compiled binaries are not allowed. ] [1]: https://www.debian.org/doc/devel-manuals#packaging-tutorial --Daniel signature.asc Description: PGP signature
Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing
Hi Daichi, On Sun, Jun 16, 2024 at 04:08:26PM +0900, Daichi Fukui wrote: > > Daichi, I'd be happy to sponsor this upload in principle (once it passes > > review) but only if you're interested in taking care of blktrace going > > forward. > > Yes, I'm interested in taking care of blktrace and have a plan to address > a different issue, that is #1069862. I appreciate it if you could > sponsor this upload. > > > Firstly, apologies Daichi, if you wish adopt this package and maintain > > it moving forward, like Daniel, I would be happy to assist and support > > you as needed if requested. > > Yes, I would like to adopt the blktrace package and hopefully get > assistance for that if you don't mind. Alright. If you want to adopt it we should fixup the maintainer/uploader metadata. Since bas agreed to the takeover you can just go ahead and implement it yourself in d/control. Whether to leave Dmitry in Uploaders (which would represent co-maintanance) is your call as maintainer now. Overall you can basically choose one of the following maintanance approaches: 1) Be responsible for dealing with everything yourself. You are in Maintainers and there's no Uploaders, 2) Have a select set of people (maint+uploaders) be collectively responsible or 3) Collaborative maintainance across all of Debian. i.e. anyone can upload (we call this NMU) at will. You'd add yourself to the [LowThresholdNmu] list in that case [LowThresholdNmu]: https://wiki.debian.org/LowThresholdNmu Currently blktrace is packaged in git using the "only debian/ dir in git" approach https://salsa.debian.org/debian/blktrace. Personally I don't like that workflow and would strongly prefer switching to something else as it also impacts my sponsorship/review work. Do you have any preference among the git workflows in Debian? .. yet ;-) > In addition, I've updated the draft package as follows, following your > review for improvement. Hold off on uploading a new package to mentors with the metadata changes, I don't have the focus right now but I'm sure to have more review comments once I get around to it ;) Feel free to poke and prod if I don't get my keyboard in gear. --Daniel signature.asc Description: PGP signature
Bug#1052015: Are NMUs packaging new upstream versions appropriate? (Was: Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing)
Hi Tobias and Phil,
On Wed, Nov 01, 2023 at 01:50:04PM +0100, Tobias Frost wrote:
> this seems to be a NMU, and for NMUs there is a set of rules [0], for
> example it needs to fix (important) bugs.
Policy section 5.11.1. explicitly says even whishlist bugs are fair game:
pol> ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new
pol> upstream version, but care should be taken to minimize the impact to the
pol> maintainer.)
> Maybe I am missing something but I think this upload is outside of the
> scope of an NMU. Please let me know if I missed something.
Note policy sections 5.11.2. and 5.11.4. also explicitly talk about this
NMU-with-new-upstream-version scenario:
pol> If a new upstream version is packaged in the NMU, the Debian revision is
pol> set to 0, for example 1.6-0.1.
and
pol> Note that if you ever need to revert a NMU that packages a new upstream
pol> version, it is recommended to use a fake upstream version like
pol> CURRENT+reallyFORMER until one can upload the latest version again.
So I hardly think we can claim this is out of scope for NMUs if policy
deals with the nitty gritty of how to do it :)
--Daniel
signature.asc
Description: PGP signature
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Fri, Jun 14, 2024 at 09:55:31PM +0200, Samo Pogačnik wrote: > 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. No worries, that happens :) > > 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
Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing
Hi all, I disagree with Phil and Tobias' assessment that an NMU is inappropriate here. Given the salvaging process uses NMUs as an indicator for maintainer inactivity I feel it's exactly what we should be doing here. NMU and eventually salvage if Bas still shows no interest in maintaining this package. Daichi, I'd be happy to sponsor this upload in principle (once it passes review) but only if you're interested in taking care of blktrace going forward. According to [contributors] Bas has not made any uploads since 2019, has been CCed on the RFS and not responded for months and is likeley about to get an NMU, which makes it look like a candidate for salvaging in the near future to me. So Daichi, you could become it's official maintainer if that interests you. [contributors]: https://contributors.debian.org/contributor/bas/ --Daniel signature.asc Description: PGP signature
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Fri, Jun 14, 2024 at 07:15:40PM +0200, Samo Pogačnik wrote: > 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. Thanks for working on this :) Recent discussion on d-devel makes me think git-subtree/subrepo have a good chance of becoming more popular as we educate upstreams about how to properly avoid future xz snafu. So you're doing really important work here <3 > 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? That's not spamming upstream so much as just doing upstream development :) There's nothing wrong with pushing revisions in that case. If you insist you can send me the patches/branch for review first, but I don't see a need for that. I was just trying to be clear about the fact that these patches should be well motivated and single-purpose so upstream can understand them. If it happens that upstream and Debian policy disagree there's no problem with sending upstream the patches they'll take and just add the rest on top in the Debian package patch stack. I do think we should try to always push patches upstream first to keep them informed about what we're doing. The "spam" comment was really just me making sure you're aware you're not expected to split each patch into it's own PR. Don't worry about that too much. Looking at the upstream activity I fear us being ignored may the worst that'll happen. My hunch is that we may end up having to take over as git-subrepo upstream. Only one way to know (send a PR) and in any case we'd want clean commits :) One workflow note: whatever you do you should make sure not to have Gbp-* fields in the commits you send upstream. Getting the Debian tooling to cooperate here can be a bit tricky. Give it a go and let me know if you need help. Overall what I'd try to do is commit the upstream changes[1] on top of our debian/sid branch, build/test using the Debian tooling and once things are working rebase onto the plain upstream branch then push that as a PR. The problem you're going to run into is dpkg-source complaining about unrepresented upstream changes. IIRC you can bypass that problem by only doing binary builds (check dpkg-buildpackage.1 for how to do that) or if all else fails temporarily switching the package to be format=3.0 (native) instead of (quilt). [1]: Dealing with changes that need both upstream and Debian adjustments is probably where git-debrebase would come in handy as it (IIRC) can seperate those a mixed upstream+Debian commit into seperate ones and then you can easily get rid of the Debian specific stuff during the final rebase. You can also just side-step that problem by committing such things separately to begin with. Re-ordering is easy whenever commits are non-overlapping after all. > > > 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. No worries. You do have a choice but you should at least communicate why you don't want to do what I suggest i.e. all review comments should be responded to with something lik ACK or NACK+further-discussion. It's not so much about "something wrong" as it is just a matter of having tidy and predictable structure. > > I noticed another thing, we disable the te
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Sat, Jun 01, 2024 at 10:01:53AM +0200, Samo Pogačnik wrote: > I prepared a new 0.4.6-1 release 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. Thanks, commit review inline below. 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 :) > 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 noticed another thing, we 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' ... ? > 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 $(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? > > # Uninstall support: > uninstall: > -- > 2.39.2 > > From: Samo Pogačnik > > Bash scripts under git-suberpo.d are not to be executed standalone > therefore should not have executable permissions. > > Gbp-Pq: Name 0002-Removed-executable-permission-on-sourced-only-files.patch > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 3d84454..818cd7d 100644 > --- a/Makefile > +++ b/Makefile > @@ -64,7 +64,7
Bug#979188: [PATCH git-subrepo] Drop unecessary subdir in usr/share
---
Makefile| 1 +
debian/rules| 7 ++-
lib/git-subrepo | 22 +-
test/setup | 3 ---
4 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index e7643a7..79898f5 100644
--- a/Makefile
+++ b/Makefile
@@ -62,6 +62,7 @@ $(DOCKER_TESTS):
install:
install -d -m 0755 $(INSTALL_LIB)/
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 -d -m 0755 $(INSTALL_MAN1)/
diff --git a/debian/rules b/debian/rules
index a6231a2..558e5cb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,9 +1,14 @@
#!/usr/bin/make -f
#export DH_VERBOSE = 1
+DESTDIR=debian/tmp
export PREFIX=/usr
+export INSTALL_LIB=$(DESTDIR)/usr/share/git-subrepo
+export INSTALL_EXT=$(INSTALL_LIB)
%:
- dh $@ --with=bash-completion
+ dh $@ \
+ -Smakefile --with=bash-completion \
+ -P$(DESTDIR)
override_dh_auto_test:
# Tests are broken without a .git directory, see
diff --git a/lib/git-subrepo b/lib/git-subrepo
index a6d5d96..7072887 100755
--- a/lib/git-subrepo
+++ b/lib/git-subrepo
@@ -12,21 +12,9 @@ set -e
export FILTER_BRANCH_SQUELCH_WARNING=1
# Import Bash+ helper functions:
-SOURCE=${BASH_SOURCE[0]}
-while [[ -h $SOURCE ]]; do
- DIR=$( cd -P "$( dirname "$SOURCE" )" && pwd )
- SOURCE=$(readlink "$SOURCE")
- [[ $SOURCE != /* ]] && SOURCE=$DIR/$SOURCE
-done
-SOURCE_DIR=$(dirname "$SOURCE")
-
-if [[ -z $GIT_SUBREPO_ROOT ]]; then
- # If `make install` installation used:
- source "${SOURCE_DIR}/git-subrepo.d/bash+.bash"
-else
- # If `source .rc` method used:
- source "${SOURCE_DIR}/../ext/bashplus/lib/bash+.bash"
-fi
+
+SUBREPO_EXT_DIR="$(realpath "$(dirname "${BASH_SOURCE[0]}")")/git-subrepo.d" #
replaced by `make install`
+source "${SUBREPO_EXT_DIR}/bash+.bash"
bash+:import :std can version-check
@@ -394,7 +382,7 @@ command:config() {
# Launch the manpage viewer:
command:help() {
- source "${SOURCE_DIR}/git-subrepo.d/help-functions.bash"
+ source "${SUBREPO_EXT_DIR}/help-functions.bash"
local cmd=${command_arguments[0]}
if [[ $cmd ]]; then
if can "help:$cmd"; then
@@ -1952,7 +1940,7 @@ OK() {
usage-error() {
local msg="git-subrepo: $1" usage=
if [[ $GIT_SUBREPO_TEST_ERRORS != true ]]; then
-source "${SOURCE_DIR}/git-subrepo.d/help-functions.bash"
+source "${SUBREPO_EXT_DIR}/help-functions.bash"
if can "help:$command"; then
msg=$'\n'"$msg"$'\n'"$("help:$command")"$'\n'
fi
diff --git a/test/setup b/test/setup
index a05f7ff..ea4df6e 100644
--- a/test/setup
+++ b/test/setup
@@ -5,9 +5,6 @@ git config core.autocrlf input
set -e
-# Set the GIT_SUBREPO_ROOT for testing.
-source "$PWD"/.rc
-
# Get the location of this script
SCRIPT_DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
--
2.39.2
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Sat, May 25, 2024 at 07:30:46PM +0200, Samo Pogačnik wrote: > https://salsa.debian.org/spog/git-subrepo/-/commit/42628d43faa4a05eb3dd3c4b75d9d194ce6bda90 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 ;) --Daniel signature.asc Description: PGP signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote:
> >https://salsa.debian.org/debian/lsm
>
> I'm already using gbp, on my own repository server
>
> https://git.gnuabordo.com.br/foolsm.git/, I haven't created the salsa
> account yet.
Ah. You should have put that in the Vcs-{Git,Browse} headers for everyone
to find then :)
FYI: Vcs-Git also supports specifying a branch which may be useful in your
case if the repo's default HEAD isn't the debianization.
> > d/rules:
> > > DEBUG=true
> > I'm not sure how to feel about this. Do you have a reason for turning it
> > on? Seems the last upload had it commented out. From a quick codereivew it
> > does look to just add more logging, so it's probably fine?
> Ops, built upon wrong git branch. = ) I'm going upload a new package.
> > Looking at the generated maintainerscripts in the foolsm deb I don't see
> > anything related to dpkg-maintscript-helper, are you sure that's hooked up
> > right? Good job finding that obscurica BTW I didn't know about that myself
> > :)
>
> Nope, the maintscript is right, should be ran just for lsm update, or
> somehow the lsm is installed but foolsm is available.
Brainfart I was just looking at the wrong package.
> The script will check if /etc/lsm/lsm.conf already exist, then it'll move
> the conf file.
Great. Just what I wanted.
> > I also noticed the upstream tarballs have started including a debian/
> > directory for a non-native packaging. Do you know what's up with that? I
> > could see why they would include it if they packaged it as a "native"
> > package but for non-native it just makes no sense. Could you talk to
> > upstream to figure out what's up with that? Feel free to CC me.
>
> My guess is they would try update the package because I had missed.
Perhaps. Would still be nice if they could remove it again. Please shoot
them a mail. It's always a good idea to keep in contact with upstream
anyway, even when it's just a "look we packaged your latest release, here's
some notes" thing.
Getting their stuff into a wideley deployed distro like Debian is positive
feedback for people doing the unthankful job of publishing free
software. We provide as much of that kind of feedback to our upstreams as
possible.
> > Just FYI: I'd appreciate git commits/patches on top of my repo above
> > instead of an updated dsc dump.
>
> As I mentioned, I don't have a salsa account, I really would like to keep my
> own repository by now, maybe soon I'll create an account.
No, there's no need really. I can pull from your repo and push to salsa, no
problem. See for the sponsorship workflow (with git) to work well for any
random DD it's best if they already have access to the repo listed in
Vcs-Git (as is the case on salsa) since they are expected to push debian/*
tags and (possibly) d/changelog updates or minor fixes there.
You can keep your repo and just tell sponsors to pull from it by adding an
additional line to the usual sponsorship message. DDs can then decide
whether to use it or not. That's how I would do it anyway.
I'll base the debian/lsm repo on your repo's state then. I do have some
review notes though:
The branch naming is non-standard see [DEP-14]. Convention is debian/latest
(used to be debian/master) or debian/unstable (used to be debian/sid) for
the development branch. I haven't looked at that document in a while either
I guess since I still use debian/sid everywhere but they changed the
recommendation from debian/$codename to debian/$suite in 2020.
[DEP-14]: https://dep-team.pages.debian.net/deps/dep14/
Further you have a number of debian/* tags in your repo that don't exist in
the debian archive. That's not going to do. If you keep your own archive of
packages you should make use of the DEP-14 $vendor feature and have
branches/tags named, say gnuabordo/*.
Since you'd have to adjust d/gbp.conf for your repo's use with something
like
[DEFAULT]
debian-branch = gnuabordo/latest
debian-tag = gnuabordo/%(version)s
and keep that on a separate branch from actual Debian packaging. Thats
obviously more work, so another way to go would be to just not tag your
internal uploads. That what I tend to do when I have something I want to
deply right away and don't feel like waiting on NEW review.
Might just be easier to apply to become DM for lsm and just not have so
much of a need for a local repo ;)
--Daniel
signature.asc
Description: PGP signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, Hi d-mentors (there's a workflow question below), On Sun, Mar 24, 2024 at 05:16:54PM -0300, Lucas Castro wrote: > The source builds the following binary packages: > > foolsm - Link connectivity monitor tool > lsm - Link connectivity monitor tool - transitional package > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/lsm/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -xhttps://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc I like using git since it makes dsc review easier. I've converted the upstream tarball history and your uploads to git using gbp and put them here: https://salsa.debian.org/debian/lsm If you don't want to use git that's fine it's just a convinience for the me or the next DD to sponsor lsm but I'd be happy to help you figure out the Debian git workflow if you want. Package Review -- d/changelog: > lsm (1.0.21-1) unstable; urgency=medium > . > * New upstream release (Closes: #1041221) > * Usrmerge compliance (Closes: #1054086) Could be more specific. "Use dh_installsystemd to install units" maybe? > * Package rename Use imperative in changelogs and be more specific: "Rename package to 'foolsm' to stay consistent with upstream" or some such. > - Added transitional package for renaming process More specific please. I'd go with straight prose and not bullet-points myself. Say: "The old 'lsm' package is now transitional and installs the new 'foolsm' package. > - Debian package was modified after upstream project rename. I'm not sure what you're trying to tell me here? > * debian/watch updated > * debian/patches/ cleaned out IMO these are implied. Ofc. we're going to do that when we update a package in Debian so while these would make good git commits I don't think they should be in d/changelog since that's mostly user-facing. Maybe that's just my git sensibilities showing and it's perfectly appropriate to note this in d/changelog for the old dsc focused workflow? Feel free to rebuttle this point. d/copyright: > Files: * > Copyright: 2009-2016 Mika Ilmaranta >2009-2015 Tuomo Soini licensecheck finds newer copyright dates, some ftp reviewers like to be pedantic here and since we'll make a trip through NEW its best to be exact here, should be: Copyright: 2009-2019 Mika Ilmaranta 2009-2021 Tuomo Soini d/rules: > DEBUG=true I'm not sure how to feel about this. Do you have a reason for turning it on? Seems the last upload had it commented out. From a quick codereivew it does look to just add more logging, so it's probably fine? Looking at the generated maintainerscripts in the foolsm deb I don't see anything related to dpkg-maintscript-helper, are you sure that's hooked up right? Good job finding that obscurica BTW I didn't know about that myself :) man says: > When using a packaging helper, please check if it has native > dpkg-maintscript-helper integration, which might make your life > easier. See for example dh_installdeb(1). Hmm. I do see: $ cat debian/lsm.preinst.debhelper # Automatically added by dh_installdeb/13.11.4 dpkg-maintscript-helper mv_conffile /etc/lsm/lsm.config /etc/foolsm/foolsm.conf 1.0.21\~ -- "$@" # End automatically added section but that somehow doesn't seem to make it into the deb. Oh. The lsm.maintscript probably has to be called s/lsm/foolsm/ for it to work. Random notes: I also noticed the upstream tarballs have started including a debian/ directory for a non-native packaging. Do you know what's up with that? I could see why they would include it if they packaged it as a "native" package but for non-native it just makes no sense. Could you talk to upstream to figure out what's up with that? Feel free to CC me. Just FYI: I'd appreciate git commits/patches on top of my repo above instead of an updated dsc dump. Thanks, --Daniel signature.asc Description: PGP signature
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
pt, hmm. Bonus points for forwarding this bug and patch upstream. Git Review -- Now, let's get into the review. Here's what I see -- if you're not reading this in a monospace font this is the time to reconsider your ~life~ eer. config choices :D 84c24 * debian/sid origin/debian/sid Release 0.4.6-2 Samo Pogačnik 2d ac9b0 * d/*: Fixed bash-completion integration with gi$ Samo Pogačnik 2d ce3fb * git-debrebase import: declare upstream Samo Pogačnik 2w |\ c9552 * | git-debrebase convert-from-gbp: drop patches$ Samo Pogačnik 2w 873da * | Release 0.4.6-1Samo Pogačnik 3w 51d5b * | d/control: Set myself as MaintainerSamo Pogačnik 3w 43a8c * | d/control: Point Vcs to new location (salsa/$ Samo Pogačnik 3w bf7e8 * | Merge tag '0.4.6' into debian/sid Samo Pogačnik 4w |\| 5a1ed * | Revert "Update changelog for 0.4.3-2 release$ Daniel Gröber 3Y 4e559 * | origin/ci/salsa Add salsa-ci configDaniel Gröber 3Y 181d5 * | debian/0.4.3-2 Update changelog for 0.4.3-2 $ Daniel Gröber 3Y b6c79 * | Fix Vcs URLs, s/guest-dxld/dxld-guest/ Daniel Gröber 3Y f180e * | debian/0.4.3-1 Initial release. (Closes: #91$ Daniel Gröber 3Y 73a01 | | * upstream origin/upstream docs: Replace 404$ Edwin Kofler 5M | |/ 110b9 | * 0.4.6 Release 0.4.6Austin Morgan 1Y 3994d | * Add test for empty pushandreasxp 1Y 89f56 | * Remove unneeded worktree on push Daniel Bauten 4Y c14bf | * Remove worktree in pushDaniel Bauten 4Y dbb99 | * Remove branch creation from GitHub Action Matijs van Z$ 2Y 84854 | * Do not depend on main repo for status testsMatijs van Z$ 4Y aa416 | * 0.4.5 Release 0.4.5Austin Morgan 2Y 1b06c | * Add --file option Austin Morgan 2Y b4ae8 | * Fix git subrepo status command for subrepos $ Catalin Cioco 3Y be9f0 | * Don't allow -b and --all Austin Morgan 3Y df975 | * Fix documentation linksAustin Morgan 3Y 4d3db | * fix tests to support use of a default branch$ Michael Tedde 3Y 87ee3 | * pass --force to git add so a user's global .$ Michael Tedde 3Y 94ac5 | * Fix .rc and enable-completion.sh for zsh bef$ Ingy döt Net 3Y 2f685 | * Better format for options Ingy döt Net 3Y |/ b562f * 0.4.3 Release 0.4.3 Ingy döt Net 3Y Drilling in: c9552 * | git-debrebase convert-from-gbp: drop patches$ Samo Pogačnik 2w I thought we agreed on using plain gbp for now? 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. ac9b0 * d/*: Fixed bash-completion integration with gi$ Samo Pogačnik 2d Don't use d/*. If many files are involved just leave off the context. I hope I haven't given you the impression you *have* to put some context there, that's not the case. The convention is to mention the file/package when the added context helps the rest of the commit subject read better of be shorter. It is a pretty soft convention however I'm not very consistent with it myself ;) My main use case for files is stuff like "d/changelog: Fix typo" or "d/copyright: Update for new upstream". As source packages get bigger which binary package you're talking about starts to be important, say "some-binpkg: Remove dep on flubnub". Technically all of these could be reworded as something like "DoThing in $context for this and that reason", but see what's actually happening is split in two that way. It just reads better to get the $context first and then the $whats_happening. Something to keep in mind here too: if you do use the prefix convention it is prudent to edit the gbp autogenerated d/changelog entries as end-users don't (and shouldn't) really know what any of this Debian stuff is. Until you're a DM/DD there's always someone in the middle editing the changelogs but you should get into the habbit of keeping in mind who uses/reads the stuff you produce. Some DDs may feel this extra editing step is too annoyi
Bug#979188: Maintaining git-subrepo in Debian?
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. > > Have you found any docs for this workflow? > Not really, it was just an idea while reading about gbp and git-debrebase. Right, that's what I figured but I wasn't sure :) > > 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'). Playing with this stuff sure is important to figure out whats going on ;) --Daniel 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? signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 08, 2024 at 09:01:24PM +0200, Samo Pogačnik wrote: > > 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. You can just edit the changelog `gbp dch` generates. I do find it fucks up most of the time the way I use it and just edit it. I am starting to think gbp is more trouble that it's worth now that I'm starting to look at some of the other workflows... +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". As for the Vcs change: I'd prefer if we put the git repo in the debian/* namespace on Salsa. + + -- Samo Pogačnik Sun, 07 Apr 2024 19:31:14 + > 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 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 Maybe, maybe not. Only one way to find out. > 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 :) I'm actually tending to just jumping onto dgit. Should actually make things easier for you once I figure out how it works. There's even nice docs for the sponsorship workflow https://manpages.debian.org/testing/dgit/dgit-sponsorship.7.en.html unlike with gbp where upload sponsorship seems to just not have been considered in it's design if my DM experience with it is any indication :D Opinions? --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 15, 2024 at 09:13:03PM +0200, Samo Pogačnik wrote: > 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'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 :) > 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. 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? > 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. > So, when a new upstream version is to be integrated (after pulling the > upstream repo): tl;dr honestly. Look, we already have too many possible workflows for git maint. in Debian adding a new one that doesn't have wide usage yet isn't going to help unless it brings something new to the table. So how does this compare to the other 50 workflows? :^) > I feel/hope debrebase is doing something similar as my little experiment but > with all the debian specific bells and whistles, i am currently not even aware > of. I would say that, if dgit/debrebase provides a workflow without messing > with patch-sets (and tarballs), then this is the tool... There's no escaping tarballs in Debian :3 Except maybe with dgit but even then you need to think about calling origtargz... *chanting* In the tarball, part of the tarball, in the tarball, part of the tarball ...[ad nauseam] https://youtu.be/SxGjdx1NXfg?feature=shared=49 and also: https://www.youtube.com/watch?v=EM9kl6jY09A --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Sun, Mar 31, 2024 at 01:42:48PM +0200, Samo Pogačnik wrote: > 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 debby> 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. 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. Workflow wise I don't see why you needed to make a merge commit at d0cc659. Can you explan what you were doing? On Wed, Mar 27, 2024 at 07:27:31PM +0100, Samo Pogačnik wrote: > 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 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. > $ cd git-subrepo > $ gbp buildpackage --git-pristine-tar-commit Don't use --git-pristine-tar-commit. Proper proceedure is to do that explicitily using gbp import-org (if using that). 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. > 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? Seems ok, but building in "clean" chroots (using sbuild) is strongly preferred for real testing. 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. > 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? 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. > > 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. I wouldn't trust it working outside of Debian. It's a Debian tool for and by Debian people. > > Aah, it's nice and warm in the jungle but simetimes you get lost between > > all the vines~ > > 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:). c.f. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence While sometimes we may need to build to understand others need to see you understand before they let you build on their land ;-) --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
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
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Mon, Apr 01, 2024 at 07:54:09PM +0200, Samo Pogačnik wrote: > > 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? Right, that's not how to do things in a git-buildpackage repo. See the problem gbp is solving is that Debian source packages (.dsc) are composed of two parts (tarballs) the upstream part (.orig.tar.*) and the debian part (debian.tar.*). To represent this in git gbp has the concept of an upstream branch and a debian branch. When updating your gbp packaging repo to a new upstream version you have to update the upstream branch pointer and merge that into the debian branch separately. import-orig and import-ref will do this for you as it's a hassle. Honestly I really hate this part of gbp's design. Having two branches is just such a hassle to manage and makes all the operations gbp performs non-atomic and it has to support rollback of whatever it has already tried to do in case anything (say a git-merge) fails down the line ... it's a mess. There are other git workflows in use in Debian, eg. dgit, but they're even harder to get your head around, or at least I haven't managed to, so gbp it is for now :/ 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) > > 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? Oh I didn't even know gbp has a user config file. That seems ill-concieved. Gah. Yeah I would strongly reccomend not messing with the pristine-tar option in the user-config. We could explicitly set it =False in d/gbp.conf but I'd rather not as I don't think that's commonly done at all though I can find a number of occurrences in my Debian packaging workdir. > > 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... 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 just want to avoid using a custom script to import upstream sources if at all possible. Debian already has too much fude factor in packaging. > > 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) I don't see why that would be necessary though? Ubuntu also uses sbuild, the version in their archive should work just fine for our purposes as long as you make it use a Debian chroot. --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Fri, Mar 15, 2024 at 06:42:54PM +0100, Samo Pogačnik wrote: > Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a): > > Are you still interested in maintaining git-subrepo in Debian? > > 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). Given that git-subrepo doesn't have much upstream activity these days I don't find that very concerning at all. In fact Debian development is pretty well suited to an offline workflow -- if only because the tools we use were designed so long ago that having no internet was still common ;) Only thing I would recommend you get yourself is a setup where you can send/read your email offline and without Debian stuff getting lost. As long as you surface regularly and especially some time before it's release'o'clock it doesn't matter much. Worst case I'm expected to deal with any packages under my sponsorship umbrella so the responsibility doesn't rest enrirely on you anyway. Now you may wonder "why don't I just do it then" and I just find having someone else on board that cares (more intensly) about a package helps make the drudgery of maintanance more fun ;) > 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. Not a big deal either. The packaging should mostly be done IIRC and since subrepo is just a simple shell script it's about the simplest thing to package I can imagine, no need to worry there. The main job(s) of a maintainer are responding to bugs, fixing or forwarding them, communicating with upstream and reviewing new versions, perhaps writing new docs if you can see users struggling. All of which are more about humans than about computer obscurities. As for the Ubuntu bit. There are tons of ways to get a Debian development environment on your system, I don't know what the easiest one is for you since that depends on what you're familiar with. Docker is certainly possible and AFAIK the dockerhub images are maintained by DDs. You just have to keep in mind to build/test with Debian unstable since that's where the actual development happens. Depending on whether you want git-subrepo to also be available for the current release (bookworm) we could also publish to the backports repo but that does double the amount of package building/testing work we have to do. > If you think that may shortcomings I don't think about people that way, what you call shortcomings I call *untapped potential* ;) > I would very much appreciate any guidance regarding debian packaging > procedures and needed packaging/testing environment. 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. > And of course congratulations on becoming a DD! Yey, now the real work begins ;) --Daniel
Bug#979188: Maintaining git-subrepo in Debian?
On Mon, Apr 01, 2024 at 11:07:50PM +0200, Daniel Gröber wrote: > 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 ;) Looking at git-debrebase (https://www.youtube.com/watch?v=iov10lD7tcg) now. Looks promising, hmm. --Daniel signature.asc Description: PGP signature
Bug#979188: Maintaining git-subrepo in Debian?
Hi Samo, On Tue, Mar 19, 2024 at 10:00:44PM +0100, Samo Pogačnik wrote: > > 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? 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. 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. 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 signature.asc Description: PGP signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: > > Are you sure you want to change the source package name? Doing so fractures > > the history of the package on tracker.d.o and it's not really necessary. > > The upstream has changed software name but it's a good point about > tracker.d.o. Right, so users will try to `apt install foolsm` in the future, but the source package name is largeley irellevant to them. > > Quick package review: > > > > - d/postinst: I don't think it's useful to print the message about editing > > the config. I've only seen packages do that in special circumstances, do > > you have a justification for it being necessary here? > Really, really not. I really would like improve that, I guess to write good > doc and manual pages is enough. I would argue users (sysadmins in this case) are going to be familiar with the concept of having to configure a package before it becomes useful and while the daemon not being started at package installation is unconventional in Debian automatic config reloading is by far not universal so any config change to make lsm useful is going to elicit a restart anyway. So I just don't see why we'd want a conspicuous message telling people what they already know :) > > - You declare Replaces+Conflicts on lsm but you don't seem to take any > > care for the new binary package to actually be compatible with the old > > one since the config location changed. > > I'm in doubt, when the old config exist, if set dpkg to copy the old config > from old location to the new one or if I just print/show up a message to > users notifying about path update requirement. I think an automatic upgrade is the way to go in this case as long as the config format is still fully compatible to the old lsm-1.0.4, but since copying will leave cruft behind for the user to cleanup manually I think we should mv the config. > If it's good/allowed do the copy, it could be applied in postinst. I think > print/show up message is rightest way. Consider that people upgrade Debian systems for many, many years without reinstalling. So every bit of cruft we leave behind due to transitions such as this accumulates. I don't see a technical need for not doing so in this case so I think we should clean up behind ourselves and move the config to the new location. You should then absoluteley print a message in the log to note this fact, but perhaps not as conspicuously as you're printing the "configure me" message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice since the package(s) involved should be obvious from the filenames. --Daniel signature.asc Description: PGP signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: > * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. - d/foolsm.init: Still has the old $CONFIG path --Daniel signature.asc Description: PGP signature
Bug#1061314: RFS: vnstat/2.12-1 -- console-based network traffic monitor
Hi Christian, I'd be happy to sponsor vnstat (as soon as my NM process propagates through the bueraucracy). In the meantime I've had a look at the packaging and I have no notes :) I'll try to remember to upload vnstat but since it might be a while still until my key is accepted by ftp-master feel free to ping if I forget. --Daniel On Mon, Jan 22, 2024 at 03:25:52PM +0100, Christian Göttsche wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "vnstat": > > * Package name : vnstat >Version : 2.12-1 >Upstream contact : Teemu Toivola > * URL : https://humdi.net/vnstat/ > * License : GPL-2, GPL-any > * Vcs : https://salsa.debian.org/debian/vnstat >Section : net > > The source builds the following binary packages: > > vnstat - console-based network traffic monitor > vnstati - image output support for vnStat > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/vnstat/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.12-1.dsc > > Changes since the last upload: > > vnstat (2.12-1) unstable; urgency=medium > . >* New upstream version 2.12 > . >* d/patches: rebase and drop upstream applied one >* d/copyright: bump years > > Regards, >Christian Göttsche > signature.asc Description: PGP signature
Re: parsing of the .changes files
Hi Frederic, On Mon, Nov 27, 2023 at 02:30:28PM +0100, PICCA Frederic-Emmanuel wrote: > Hello, I would like to know if there is command line tool usable from > bash , which allows to list all the artefacts of a given .changes file. You can use the dcmd wrapper from devscripts: $ dcmd echo foo.changes it also supports getting various subsets, only debs (--debs), only tarballs (--tar) and even just the package names (--package, -p). In fact just today I figured out how to download all the debs for a source package (given a changes file): $ dcmd -p apt download foo.changes --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Hi Martin, On Fri, Nov 24, 2023 at 09:54:30PM +0200, Martin-Éric Racine wrote: > > Looking the last your three dhcpcd revisions I wonder if you shouldn't be > > debugging these fundamental build issues on a porterbox or in a VM rather > > than through the buildds? > > I don't have access to the former and am not in a position to setup the > later. You can request access to a porterbox pretty easily, but that's only really going to help with the FTBFS part, not with testing DHCP functionality for real as that requires root which is not available on porterboxes AFAIK. I'm not very familiar with the hurd port myself, but a quick search found some pre-prepared QEMU/KVM images for hurd (with docs!) here: https://cdimage.debian.org/cdimage/ports/12.0/hurd-i386/README those should be easy enough to use. > Anyhow, doing this via the buildd has the advantage of ensuring that I > don't break anything for existing ports. I don't think this is a good use of your time (or your sponsors'!). The cyle time is just too long, please consider developing in a VM and uploading once you get it working. You should likely submit your porting changes upstream for review before even integrating them into Debian though as I expect they'll be substantial as they amount to supporting a new OS. I'm following the dhcpcd project so I'll likely review your PR(s) anyway. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
On Fri, Nov 24, 2023 at 09:03:37PM +0200, Martin-Éric Racine wrote: > On Fri, Nov 24, 2023 at 8:59 PM Daniel Gröber wrote: > > On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > > > dhcpcd (1:10.0.5-4) unstable; urgency=medium > > > . > > >* Attempt to fix the GNU/Hurd build. > > > + 003_fix_FTBFS_on_Hurd.patch > > > > Does upstream even support hurd? Looking at ./configure: > > > > gnu*) OS=hurd;; # No HURD support as yet > > Upstream never attempted to support it. I am. Looking the last your three dhcpcd revisions I wonder if you shouldn't be debugging these fundamental build issues on a porterbox or in a VM rather than through the buildds? --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Hi Martin, On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > dhcpcd (1:10.0.5-4) unstable; urgency=medium > . >* Attempt to fix the GNU/Hurd build. > + 003_fix_FTBFS_on_Hurd.patch Does upstream even support hurd? Looking at ./configure: gnu*) OS=hurd;; # No HURD support as yet doesn't look promising. --Daniel signature.asc Description: PGP signature
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Hi Nicholas, On Sun, Sep 17, 2023 at 02:56:47PM -0400, Nicholas D Steeves wrote: > Thank you for working on this! One note: where is it documented how > ipupdown and ipupdown-ng interact? You just install the ifupdown-ng package and it kicks ifupdown out the door :) More seriously: ifupdown-ng now Recommends:ifupdown-ng-compat (the bit that conflicts with ifupdown) so for testing I can do --no-install-recommends and get both at once but the old package in stable just straight up conflicts with traditional ifupdown. I'm intending to do a good amount of testing/integration work to make sure ifupdown-ng can handle an upgrade without breaking the network but that hasn't happened yet. Though I keep switching back and forth between them and haven't noticed any severe breakage yet so maybe it's already fine :3 Testers welcome. I'd also appreciate people send me weird stuff they have in /etc/network/interfaces I can try out. A bit of background: The way I see it ifupdown-ng's integration into Debian isn't complete yet. Unfortunately the very first (pretty incomplete) upload landed in stable. Part of the reason being that Thomas seems to have lost interest and I was peeved by his essentially snatching the package out from under me, re-doing my packaging work with some weirdly broken openstack-pkg specific git packaging scripts I didn't want to deal with. So I neglected the package for a while. > For example using the alternatives system, or a different config file > location, or some sort of tagging mechanism in network/interfaces. I > would appreciate it if this was in the changelog, at a minimum, and maybe > other people would too? A brief "...by using $method" seems like it > would be enough. Since the interaction amounts to "one replaces the other" I think this is mild overkill. The package description already covers how it's supposed to be a drop-in replacement, maybe you missed that. Though ATM this still seems a bit more aspirational than practical[1], but maybe I'm just pedantic about compatibility. [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/216 For a high-level overview of the project goals and how it compares to ifupdown2 etc have a look at Maximilian's DebConf-21 talk: https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/ --Daniel
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Package: sponsorship-requests Severity: normal Hello mentors, I am looking for a sponsor for my package ifupdown-ng, it's a promising modern alternative for ifupdown with support for dependencies and a lot more interface types. The headline change in this revision is that I've split a new binpkg from the package to support co-installability with traditional ifupdown. This will enable easier migration and compatibility testing. Full changelog below. * Package name : ifupdown-ng Version : 0.12.1-1 * URL : https://github.com/ifupdown-ng/ifupdown-ng * Vcs : https://salsa.debian.org/debian/ifupdown-ng * License : MIT-like Section : admin The source builds the binpkgs: ifupdown-ng - network interface configuration tool ifupdown-ng-compat - network interface configuration tool -- ifupdown compat The gbp source repo lives at https://salsa.debian.org/debian/ifupdown-ng.git please use the git repo for uploading but the package is also on mentors for linting results: https://mentors.debian.net/package/ifupdown-ng/ Changes since the last upload: ifupdown-ng (0.12.1-1) UNRELEASED; urgency=medium . [ Debian Janitor ] * Bump debhelper from old 12 to 13. * Set upstream metadata fields: Repository-Browse. * Update standards version to 4.6.1, no changes needed. * Set upstream metadata fields: Repository. . [ Daniel Gröber ] * New upstream release * Fix nonsense janitor commits * Fix d/watch * Add patch to support ifupdown compatible 'source' include patterns * Fix bogus ExecRestart systemd unit stanza (Closes: #1006817) * Align systemd service dependencies with ifupdown * Drop support for kfreebsd/hurd * Remove deprecated lsb-base dependency * Promote rdnssd to recommends for IPv6-only support by default * Fix co-installability with ifupdown * Ensure all make targets run under the same environment * Fix conflicting files in /usr/share/man * Fix networking script perms * Add autopkgtest for coinstallability with traditional ifupdown * Fix some pedantic lintian complaints * Fix upgrade path from stable not installing ifupdown compat Thanks, --Daniel signature.asc Description: PGP signature
Re: Packaging git submodule as multi upstream tarballs?
Hi Ryan, On Wed, Jun 21, 2023 at 03:07:24PM -0500, Ryan Pavlik wrote: > I'm not sure if uscan can do it, I did get it working but it's exceedingly cludgy. I have to use mode=git for the second component since uscan can't just download master.tar.gz AFACT (it's at a static location not linked from a page). I also have to set the version to "ignore" instead of "same" as the generated git commit based version is obviously not going to match the main project tag. Further I have to disable the uupdate hook since 1) it would have to be attached to the second component to work properly but 2) it gets passed the generated git version which again doesn't match the main tarball so it barfs as it can't find the orig.tar. What a mess. So I have this now: version=4 opts=filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\ https://github.com/YosysHQ/prjtrellis/tags \ (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian opts=mode=git,\ component=database \ https://github.com/YosysHQ/prjtrellis-db.git \ HEAD ignore > but for meshlab, as they don't tag the submodule when they release the > main project, I have a script that updates the submodule commit using the > github API. It's more clunky than I'd like, but I am not sure exactly how > to fix this. It parses the version out of debian/changelog to find the > main repo revision. > https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh I was looking for an API endpoint to get the submodule commit actually, this way at least I don't have to do a temp clone just to get it. This is super useful, thanks! --Daniel
Packaging git submodule as multi upstream tarballs?
Hi Mentors, I'm working on packaging prjtrellis[1] which has a git submodule that is required for building. My plan is to use dpkg-source's multi upstream tarball support to do this. [1]: https://github.com/YosysHQ/prjtrellis I'm wondering if a) this is a good idea and 2) how to get uscan to download the precise commit referenced in the main package instead of the "latest" version. Is this even possible? I have a similar situation in my yosys package already (it has a berkeley-abc submodule) but since berkeley-abc is just a seperate package I just package the latest berkeley-abc commit and pray it doesn't diverge from what upstream's release uses too much. This is less than ideal obviously. Any input would be appreciated, --Daniel
Re: Preventing a broken release arch from blocking testing migration
Hi Andrey, On Fri, Jun 17, 2022 at 05:51:36PM +0500, Andrey Rahmatullin wrote: > On Fri, Jun 17, 2022 at 02:01:42PM +0200, Daniel Gröber wrote: > > my package yosys has a test failure on mips64el that I can't figure out and > > consequently got removed from testing. I'm wondering how to deal with this? > > > > From reading the policy it seems I can use the Architecture field to list > > all arches except mips64el. Is that the right thing to do here? > Well, ideally you should fix the test or the software. If that's > impossible then yeah. Ideally yes, but I just don't see anyone wanting to build/test FPGA bitstreams on a wee little embedded mips router thingies ;) so it's just not worth spending time on IMO. > > I also wonder if there is a way to specify "everything except mips64el" > > instead of listing all arches explicitly? > Unfortunately no. Alright as long as I'm not missing something obvious :) Thanks, --Daniel signature.asc Description: PGP signature
Preventing a broken release arch from blocking testing migration
Hi Mentors, my package yosys has a test failure on mips64el that I can't figure out and consequently got removed from testing. I'm wondering how to deal with this? From reading the policy it seems I can use the Architecture field to list all arches except mips64el. Is that the right thing to do here? I also wonder if there is a way to specify "everything except mips64el" instead of listing all arches explicitly? Thanks, --Daniel signature.asc Description: PGP signature
Re: Dealing with library using upstream version as SOVERSION
Hi Gavin and Andrey, On Fri, Apr 01, 2022 at 07:24:55PM +0500, Andrey Rahmatullin wrote: > This suggests they don't know or don't care about ABI stability. Yeah, that's my guess too. On the other hand reading through their, pretty detailed, changelogs does seem to suggest they keep track of behaviour changes. This thing is supposed to allow other projects to build plugins against their API after all so they'd kind of have to. > > Is it good form to override this in the Debian package > No, both because Debian-specific sonames are often a bad idea and because > to do this correctly you need to track the ABI yourself. Yeah I think I'm just not going to bother for now we'll see if anything does end up using these libs in the future. On Fri, Apr 01, 2022 at 03:35:41PM +0100, Gavin Henry wrote: > I was just chatting with Andrey and colleagues in #debian-mentors about > something similar Let me know if you find any other good options in this space :) Thanks, --Daniel signature.asc Description: PGP signature
Dealing with library using upstream version as SOVERSION
Hi debian-mentors, I'm working on packaging [vpp] which installs a number of shared libraries that may want to be used by other Debian packages in the future. [vpp]: https://github.com/fdio/vpp/ However upstream just uses their release version in SONAME which doesn't seem very useful. Is it good form to override this in the Debian package or should I conform to what upstream is doing and deal with the fallout once a reverse dependency is actually introduced and a new release comes out? I've read the shared library policy section but since this is my first library package I'm not sure I fully get all the implications of these choices. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1003860: RFS: makemkv-oss/1.16.5-1 [ITP] -- Convert video that you own into free format that can be played everywhere
Hi Ben, I just had a quick look at your package because I didn't even know makemkv came in a version that could be considered "oss" :) I found your debian/watch file a bit peculiar, version=4 opts="" \ https://www.makemkv.com/forum/viewtopic.php?t=224 .*/download/makemkv-bin-(\d\S+)\.tar\.gz looking at the linked forum it seems a new post is made for every release, so the topic ID above is unlikely to stay the same, no? It seems to me that rather defeats the purpose of a watch file. --Daniel On Sun, Jan 16, 2022 at 08:51:04PM -0500, Ben Westover wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my packages "makemkv-oss" and "makemkv-bin" > (they depend on each other): > > * Package name: makemkv-oss >Version : 1.16.5-1 > * URL : https://makemkv.com/ > * License : GPL-2, GPL-3, LGPL-2.1, OpenSSL, X, custom > * Vcs : > https://salsa.debian.org/benthetechguy/makemkv/tree/master/makemkv-oss >Section : non-free/video > > makemkv-oss builds those binary packages: > > makemkv - Convert video that you own into free format that can be played > everywhere > libdriveio0 - MMC drive interrogation library > libmakemkv1 - MKV multiplexer library > libmmbd0 - MakeMKV BD decryption API library > > * Package name: makemkv-bin >Version : 1.16.5-1 > * URL : https://makemkv.com/ > * License : GPL-2, GPL-3, custom > * Vcs : > https://salsa.debian.org/benthetechguy/makemkv/tree/master/makemkv-bin >Section : non-free/video > > makemkv-bin builds those binary packages: > > makemkvcon - Proprietary components of makemkv > > To access further information about these packages, please visit the > following URLs: > > https://mentors.debian.net/package/makemkv-oss/ > https://mentors.debian.net/package/makemkv-bin/ > > Alternatively, one can download the packages with dget using these commands: > > dget -x > https://mentors.debian.net/debian/pool/non-free/m/makemkv-oss/makemkv-oss_1.16.5-1.dsc > dget -x > https://mentors.debian.net/debian/pool/non-free/m/makemkv-bin/makemkv-bin_1.16.5-1.dsc > > Changes for the initial release: > > makemkv-oss (1.16.5-1) unstable; urgency=medium > . >* Initial Package. >* Closes: #1003815 > > Regards, > -- > Ben Westover signature.asc Description: PGP signature
Bug#999475: RFS: zsh-histdb [ITP] -- scalable command history with git versioning and sync across hosts
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: d...@darkboxed.org Dear mentors, I am looking for a sponsor for my package "zsh-histdb": * Package name: zsh-histdb Version : 0.0~git20211013.0b63f7c-1 Upstream Author : Tom Hinton * URL : https://github.com/larkery/zsh-histdb * License : MIT * Vcs : https://salsa.debian.org/dxld-guest/zsh-histdb Section : shells This is a ZSH extension which stores the command history in an sqlite database instead of a text file while adding a number of extremely useful bits of metadata missing from zsh's native history file. A very useful aspect of this approach is that querying the history scales significantly better since sqlite can stream (search) results off the disk rather than having to read everything into memory first as zsh's native history support does. While the database file is binary and thus would ordinarily be hard to keep under version control zsh-histdb provides an automatic merge driver for use with git. This allows not only version control but naturally also syncing history across hosts with regular git push/pull. It builds these binary packages: zsh-histdb - scalable command history with git versioning and sync across hosts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zsh-histdb/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zsh-histdb/zsh-histdb_0.0~git20211013.0b63f7c-1.dsc Changes for the initial release: zsh-histdb (0.0~git20211013.0b63f7c-1) unstable; urgency=medium . * Initial release (Closes: #998883) --Daniel
Re: How to include the .git folder in a source package's .tar.xz archive?
Hi, On Thu, Oct 28, 2021 at 09:02:21PM -0500, Hunter Wittenborn wrote: > Anything I could try? I'm not sure this is a path very well travelled, but dpkg does in principle seem to support a source package format called "3.0 (git)" where the source tarball is basically a depth limited git-bundle. See dpkg-source(1) section "Format: 3.0 (git)". I just stumbled on this while looking at the dpkg source I haven't actually used it though. --Daniel
Bug#987887: RFS: git-autofixup/0.003001-1 [ITP] -- Automatically fixup commits with related changes
Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package "git-autofixup": * Package name: git-autofixup Version : 0.003001-1 Upstream Author : Jordan Torbiak * URL : https://github.com/torbiak/git-autofixup * License : Artistic-2.0 * Vcs : https://salsa.debian.org/dxld-guest/git-autofixup Section : vcs git-autofixup creates fixup commits from changes in the worktree. This can save the tedious work of amending fixes into the appropriate commits during codereview. Changes to consider are parsed out of git-diff(1) and git-blame(1) is used to assign hunks to commits since the revision given on the commandline, which will typically represent a topic branch. Then it creates fixup commits to be used with git rebase --autosquash. It builds those binary packages: git-autofixup - Automatically fixup commits with related changes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-autofixup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-autofixup/git-autofixup_0.003001-1.dsc Changes for the initial release: git-autofixup (0.003001-1) unstable; urgency=medium . * Initial Release. (Closes: #987884) Thanks, --Daniel
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, thanks for the quick review! On Mon, Jan 04, 2021 at 09:01:51PM +0100, Samo Pogačnik wrote: > Thanks for that. I sincerely hope, that you get through with this useful tool. I saw you submitted an RFS for git-subrepo a while back. I was wondering what happened with that. It's not clear from what's in the BTS why it didn't get uploaded, did you just not get a response from anyone? In case you are still interested in maintaining git-subrepo perhaps we could co-maintian it if you like? > By the way, your salsa (Vcs:) link does not work (guest-dxld should > probably be dxld-guest). Ah good catch, fixed in 0.4.3-2. Side note: I'm not sure if I'm supposed to increment the debian revision during the mentors process or if should I just keep the initial -1 revision. Thanks, --Daniel PS: You seem to have replied off-list, do you mind if I forward my response to the BTS/debian-mentors list also?
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Mon, Jan 04, 2021 at 11:16:04PM +0100, Samo Pogačnik wrote: > Dne 04.01.2021 (pon) ob 22:11 +0100 je Daniel Gröber napisal(a): > > I saw you submitted an RFS for git-subrepo a while back. I was wondering > > what happened with that. It's not clear from what's in the BTS why it > > didn't get uploaded, did you just not get a response from anyone? > there was simply no response to my RFS and 'mentors' upload got automatically > deleted about a month ago (after almost a year). Ah, I see. I didn't know mentors.d.net garbage collects packages automatically. > I have no extra preferences for maintaining the package because i am very > inexperienced regarding debian packaging. Otherwise i am willing to help... It's up to you, if you don't feel up to it I'm happy to do it. It's just always nice to have someone else that can jump in with package updates. Bus-factor and all. > Maybe i could not get more attention because of the 'native' type of my > package which it self uses 'git subrepo' instead of the preferred 'quilt' > approach (i really do not like managing series of patches, ...). I would hope people would have simply complained about that if it was in fact the problem. Seems to me there just aren't that many DDs actively watching the mentors list or maybe people do reviews mostly off-list? Had I seen the RFS I would have definitely complained about the weird repo structure in the review ;) I think people in Debian are trying to move to git-buildpackage (see also DEP-14[1]) as the main way to manage packageing in git, and since it comes with it's own way of importing upstream releases and such using git-subrepo for the packaging is unlikely to go over well. [1]: https://dep-team.pages.debian.net/deps/dep14/ I plan on using gbp-pq to manage patches as regular git commits. That seems reasonably more comfortable than plain quilt, which I agree is a PITA. > I even had the idea that git-subrepo is an excelent tool to enhance and > maybe simplify debian packaging using git, but again i am too > inexperienced to provide valid proposals covering all aspects of debian > packaging. Honestly I don't think it's worth swimming against the gbp stream at this point. Personally I'd rather have one(ish) way of doing Debian packaging in git so I can just jump into any package with debcheckout and be immediately productive, instead of having to learn each maintainer's weird conventions and tools fist. One can always improve gbp if it doesn't optimally cover a particular workflow yet. > You are of course welcome to inspect my github project: > https://github.com/spog/git-subrepo-debian I had a look of course when I started packaging, but decided to start fresh with gbp since I prefer forking the debian packaging from the upstream git repo as it makes inspecting the history and git-bisect'ing across upstream and debian revisions more streamlined. --Daniel
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
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.3-1 Upstream Author : Ingy döt Net * URL : https://github.com/ingydotnet/git-subrepo * License : GPL-2+ and GPL-2, MIT * Vcs : https://salsa.debian.org/guest-dxld/git-subrepo Section : vcs git-subrepo allows embedding and managing copies of other git repositories in your repo for purposes such as vendoring. Commits in the parent repo involving the subrepo can easily be pushed back upstream even when they touch files outside the subrepo -- these will simply be omitted. Pulling new upstream commits back into your repo is naturally also possible. git-subrepo is designed such that only the maintainer of a repo will actually need to have it installed, contributors only need to do so if they wish to push/pull from the subrepo's upstream and user should never have to interact with git-subrepo at all since all of a subrepos file are available right after a plain git-clone. This is unlike git-submodule(1)s where all users and contributors must be aware of their presence and deal with them. git-subrepo is in principle somewhat similar to git-subtree(1) as it also embedds snapshot copies of other repos, however it is much easier to use and the way the history is kept is less convoluted. Pulling any number of new commits from a subrepo's upstream will result in only a single commit in the parent repo for example. It builds this binary package: git-subrepo - Alternative to git-submodule(1) and git-subtree(1) 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.3-1.dsc Changes for the initial release: git-subrepo (0.4.3-1) unstable; urgency=medium . * Initial release. (Closes: #911397) Regards, Daniel signature.asc Description: PGP signature
Bug#968543: RFS: ungoogled-chromium/83.0.4103.116-3 [ITP] -- web browser
Hi Thomas, Thanks for working on this package! I did a quick review I noticed the Vcs-* fields in debian/control are pointing at the upstream git repo when they should be pointing to the debianized one instead, see https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields. --Daniel On Mon, Aug 17, 2020 at 12:41:10AM +, Thomas wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "ungoogled-chromium": > > * Package name : ungoogled-chromium > Version : 83.0.4103.116-3 > Upstream Author : Eloston > * URL : https://github.com/Eloston/ungoogled-chromium > * License : LGPL-2.0+, GPL-2+, ISC, LGPL-2+, LGPL-2.1+, BSD-3-clause or > LGPL-2+, MIT, zlib, BSD-3-Clause, MPL-1.1 or GPL-2+ or LGPL-2.1+, Ms-PL, ICU, > Apache-2.0, Public-domain, BSD-2-clause, MPL-1.1 or GPL-2.0 or LGPL-2.1, > APPLE-license, BSD-3-clause, GPL-2.0, LGPL-2, MPL-2.0, LGPL-2.1, BSD-3-clause > or LGPL-2.1+ or MPL-1.1, LGPL-2+ or MPL-1.1, PHP, LGPL-2.1+ or MPL-1.1 > * Vcs : https://github.com/Eloston/ungoogled-chromium > Section : web > > It builds those binary packages: > > ungoogled-chromium - web browser > ungoogled-chromium-l10n - web browser - language packs > ungoogled-chromium-shell - web browser - minimal shell > ungoogled-chromium-driver - web browser - WebDriver support > ungoogled-chromium-common - web browser - common resources used by > ungoogled-chromium packages > ungoogled-chromium-sandbox - web browser - setuid security sandbox for > ungoogled-chromium > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/ungoogled-chromium/ > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/u/ungoogled-chromium/ungoogled-chromium_83.0.4103.116-3.dsc > > Changes for the initial release: > > ungoogled-chromium (83.0.4103.116-3) unstable; urgency=low > . > * Initial Release. (Closes: #939406) > * Released 83.x instead of 84.x due to bugs found in 84.x > > Best Regards, > -- > Thomas Liang
