Submission to Experimental: rmw (ReMove to Waste)

andy5995 · 2019-08-13 20:01:08

Hi, I've prepared a source package for rmw, one of my projects. On IRC, Centurion_Dan said after I did that, I could let him know and he'd help me get it into Experimental. I pinged him and posted the link in IRC yesterday, but while I"m patiently waiting to hear back from him, wondering if anyone would be willing to review the files under debian/, as this is the first time I've prepared a debian package.

Pretty sure it's all good. It builds, and lintian reports no errors or warnings. When I extract the resulting deb package, all the files appear to be in the correct places.

Anyway, thought it'd be a good idea to get a little review before Centurion_Dan looks at it to save him a little time.

One thing I noticed is when I run `dpkg-buildpackage` I have to use '-tc' to do a post-clean. I tried figuring out how to create rules to do that, but had to take a break from that. Should I even worry about that? Since -tc does it?

ralph.ronnquist · 2019-08-13 22:31:33

Great, Andy.

As you are experiencing, there is a bottleneck in the Devuan package building process, where the creative efforts end, and the software transitions into the more "formal" and process oriented treatment at the mouth of Devuan's automated build system. Sometimes tasks end up waiting there for some while simply because the person/people to move it along are few and with already full schedules.

Don't despair; it's not a deliberate inaction against your project and effort.

I'm only at an apprentice level as package maintainer myself, but I did pick up on a couple of small specks on this diamond. I'll go through them here, although it's a public forum, so on the one hand. many people will regard it as noise, and on the other it might attract further comments, views and perspectives in a range of usefullness:

The build dependencies (in control) seem incomplete; e.g., is there a dependency on gettext at the build stage? The control file should include "all" dependencies of what is required for building the package as well as what is required for using the built software.
The version code (in changelog) might need to separate the source versioning from the packaging versioning. There are some "rules" regarding this, and some "tradition", and in particular, it would be sensible to start at 1 (or 0 even) for the first appearance in Devuan/experimental. I'm fairly sure Dan'll want to discuss this.
The targeted suite (in changelog) should be "experimental" rather than "stable".
The project needs to have the "suites/experimental" branch with that which is going to be built into the package. The automated builder builds from that branch rather than the master branch.

As you know, it's very important to have both the build dependencies and the run-time dependencies set out relative to a "pristine", minimal installation.

To move your project further, it's good with some gentle prod's like this, although I think Dan is more often at IRC than at this forum, and well, "busy" is a good term for his time between sleeps

andy5995 · 2019-08-13 23:17:41

Thanks ralph.ronnquist...

I'll see how far I get with your feedback and post back when I get stuck.

Does the suites/experimental branch have to be the default branch, or just exist and be up-to-date?

ralph.ronnquist · 2019-08-14 00:19:26

Nothing special, other than the name.

In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a ~~(new)~~ "Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.

bgstack15 · 2019-08-14 02:30:03

Wow, thanks for using Devuan as the upstream for your project. I personally won't have a use for this project, because I'm one of those old fogies who just rm -rf $ITEM which of course has bitten me a few times but you can't teach an old-hearted dog new tricks. I appreciate that you are endeavoring to comply with the freedesktop.org Trash spec. Just because some projects from them seem a little... unwanted doesn't mean it all is unwanted.

I am not an official packager at all, but I do like building dpkgs. After looking through your debian/ dir, I have nothing to add. Good job! I took months to get up to speed on building a dpkg, so I definitely consider it a skill to be learned.

andy5995 · 2019-08-14 05:07:20

bgstack15 wrote:

Wow, thanks for using Devuan as the upstream for your project. I personally won't have a use for this project, because I'm one of those old fogies who just rm -rf $ITEM which of course has bitten me a few times but you can't teach an old-hearted dog new tricks. I appreciate that you are endeavoring to comply with the freedesktop.org Trash spec. Just because some projects from them seem a little... unwanted doesn't mean it all is unwanted.

Wow, thank you very much for the feedback. I understand what you mean about changing old ways and appreciate your honesty about your intent not to use my little program

ralph.ronnquist wrote:

Great, Andy.
As you are experiencing, there is a bottleneck in the Devuan package building process, where the creative efforts end, and the software transitions into the more "formal" and process oriented treatment at the mouth of Devuan's automated build system. Sometimes tasks end up waiting there for some while simply because the person/people to move it along are few and with already full schedules.
Don't despair; it's not a deliberate inaction against your project and effort.

@ralph... Thank you for the reassurance. I'm not despairing yet. I hope I didn't sound like I was being unrealistic about my expectations. I really didn't mean to try to make anyone feel like I was trying to rush. I had only posted the link in IRC less than 24 hours ago, so I certainly am fine to wait much longer for CenturionDan to review. I've contributed to several projects on GitHub, so am pretty used to sometimes waiting over a month for PRs to get reviewed!

[*]The build dependencies (in control) seem incomplete; e.g., is there a dependency on gettext at the build stage? The control file should include "all" dependencies of what is required for building the package as well as what is required for using the built software.[/*]

I did some work on this and created a ticket. And yes, gettext is a build dep (unless --disable-nls is used). I omitted it earlier because that's usually installed, but I think I get what your saying:

As you know, it's very important to have both the build dependencies and the run-time dependencies set out relative to a "pristine", minimal installation.

[*]The version code (in changelog) might need to separate the source versioning from the packaging versioning. There are some "rules" regarding this, and some "tradition", and in particular, it would be sensible to start at 1 (or 0 even) for the first appearance in Devuan/experimental. I'm fairly sure Dan'll want to discuss this.[/*]

ticket for that created as well

ralph.ronnquist wrote:

Nothing special, other than the name.
In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a ~~(new)~~ "Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.

I'm open to helping with some documentation; I'll give it more thought after this process is completed. I tend to get overwhelmed and scattered if I try to focus on too many things that are new. If there are any existing doc-related tickets that are open, feel free to ping me on them and I"ll have a look.

One thing I thought worth adding to a guide like you mentioned, is how to sync a source package repo with the original distribution archive. I managed to do it with rsync, using some exclude flags, etc, but never quite got rsync to do exactly what I wanted... But that can be worked out in another post or ticket. But do you think info like that would be suitable to include in a package prep guide?

andy5995 · 2019-08-25 22:30:51

ralph.ronnquist wrote:

Nothing special, other than the name.
In fact, maybe a scavenge hunt at https://git.devuan.org/devuan, https://git.devuan.org/devuan-infrastructure and https://git.devuan.org/devuan-packages would bring some nuggets for you; and if you'd then accrue notes on the what, how and where, it could yield a ~~(new)~~ "Devuan Package Maintainer Cheat Sheet" (or "Comprehensive Guide, Part 1", even), as well as corrections and updates to whatever documentation there is.

Working with golinux on forming a complete and updated doc.

The officially official Devuan Forum!

#1 2019-08-13 20:01:08

Submission to Experimental: rmw (ReMove to Waste)

#2 2019-08-13 22:31:33

Re: Submission to Experimental: rmw (ReMove to Waste)

#3 2019-08-13 23:17:41

Re: Submission to Experimental: rmw (ReMove to Waste)

#4 2019-08-14 00:19:26

Re: Submission to Experimental: rmw (ReMove to Waste)

#5 2019-08-14 02:30:03

Re: Submission to Experimental: rmw (ReMove to Waste)

#6 2019-08-14 05:07:20

Re: Submission to Experimental: rmw (ReMove to Waste)

#7 2019-08-25 22:30:51

Re: Submission to Experimental: rmw (ReMove to Waste)

Board footer