Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Sorry for top posting. The debian/control was modified to append Git fields, Cvs-Git and Cvs-Browser. Git repository is following the DEP-14 as suggested, I really appreciated that workflow. Changelog was improved. It reflects the all debian package modification right now. There's something to do yet, about the gbp as Daniel had mentioned, All things about debian branch and upstream branch for debian git. I had uploaded the package to mentors, https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc The package can be checked from the git repository too, the following uri Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git Vcs-Git: https://git.gnuabordo.com.br/foolsm.git The debian/latest, debian/trixie and debian/unstable branches, all of them reflect debian package. I'm maintain all those branch right now, and all of them is identical. I'm thinking about to delete the unstable. I'll maintain just the debian/latest for development, debian/ for backports, security and propose-update and mentioned on DEP-14. Thanks, Lucas Castro Em 11/05/2024 03:44, Tobias Frost escreveu: On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote: On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote: [DEFAULT] debian-branch = gnuabordo/latest debian-tag = gnuabordo/%(version)s Please let me suggest to use DEP14 for branch naming: https://dep-team.pages.debian.net/deps/dep14/ -- tobi OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote: > On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote: > > [DEFAULT] > debian-branch = gnuabordo/latest > debian-tag = gnuabordo/%(version)s Please let me suggest to use DEP14 for branch naming: https://dep-team.pages.debian.net/deps/dep14/ -- tobi
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On Mon, May 06, 2024 at 04:31:26PM +0200, Daniel Gröber wrote: > Hi Lucas, > 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/changelog should reflect all changes made to the packaging, so if d/watch and d/patches are changed, it should be mentioned in d/changelog However, the changelog should say "WHY" something has changed. Do "d/watch updated" should be improved to "updated d/watch due to $x" or like. Same for d/parchs: Explain the why - for example "patch abc.patch has been removed, applied upstream". -- tobi
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#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
retitle 1064297 RFS: lsm/1.0.21-1 -- Link connectivity monitor tool As the source package has changed the package could be retrieve by the following url. 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 Em 24/03/2024 16:50, Lucas Castro escreveu: Em 23/03/2024 13:08, Tobias Frost escreveu: Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. Source package already kept old project name, only binary renamed. I had talked about the source package rename on IRC, and no problem was pointed as serious then the my conclusion it wasn't going to be a problem. But, by the way, it's going to be kept as it was. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) Timestamp bumped. The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. Dropped the patch, ASAP I'll forward to upstream. Already uploaded to mentors. -- tobi Thanks Tobias. On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: Em 06/03/2024 05:49, Daniel Gröber escreveu: 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. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 23/03/2024 13:08, Tobias Frost escreveu: Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. Source package already kept old project name, only binary renamed. I had talked about the source package rename on IRC, and no problem was pointed as serious then the my conclusion it wasn't going to be a problem. But, by the way, it's going to be kept as it was. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) Timestamp bumped. The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. Dropped the patch, ASAP I'll forward to upstream. Already uploaded to mentors. -- tobi Thanks Tobias. On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: Em 06/03/2024 05:49, Daniel Gröber escreveu: 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. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. -- tobi On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: > > Em 06/03/2024 05:49, Daniel Gröber escreveu: > > 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. > > Just uploaded to mentors again, now the update occur smoothly. > > > > > > --Daniel > > Thanks for taking time on testing update.
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
Em 06/03/2024 05:49, Daniel Gröber escreveu: 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. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. Lucas Castro. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 05/03/2024 08:09, Daniel Gröber escreveu: 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. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. 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. - 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. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "foolsm": * Package name : foolsm Version : 1.0.21-1 Upstream contact : [fill in name and email of upstream] * URL :http://lsm.foobar.fi/ * License : GPL-2 * Vcs : [fill in URL of packaging vcs] Section : utils 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/foolsm/ Alternatively, you can download the package with 'dget' using this command: dget -xhttps://mentors.debian.net/debian/pool/main/f/foolsm/foolsm_1.0.21-1.dsc Changes for the initial release: foolsm (1.0.21-1) unstable; urgency=medium . * New upstream release * debian/watch updated * debian/patches/ cleaned out Regards, -- Lucas Castro OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
