[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: PGP signature


Reply to: