Sunset deb.grml.org?

[mika]

Our overall goal is to make grml-live the actual central place for building Grml ISOs, and fully supporting customization from within there. Custom Debian packages for all our other projects/software tend to be hard to maintain, and usually require some extra efforts and knowledge.

Another goal of us is to make our release process as smooth as possible, and reduce manual steps and maintenance efforts also on our side.

Maintenance of https://deb.grml.org/ requires some specific actions around release time and also maintaining the Debian packages requires our time and efforts. We therefore are considering to sunset deb.grml.org. But before going that road, would like to hear, whether there are any good reasons, why we shouldn't be doing so. :)

Current state of our Debian source packages that we shipped in grml-stable repository from deb.grml.org:

• grml-autoconfig -> already moved to grml-live (see Finalize repository merges grml-live#344)
• grml-crypt -> plan: merge with grml-live (only one single shell script plus docs)
• grml-debootstrap -> included in Debian already
• grml-desktop -> relevant for Grml ISO only -> plan: merge with grml-live
• grml-etc -> already moved to grml-live (see Finalize repository merges grml-live#344)
• grml-etc-core -> see New grml-console package grml-etc-core#188 (new grml-console)
• grml-hwinfo -> included in Debian already
• grml-keyring -> relevant for deb.grml.org usage only
• grml-live -> would stay as-is, plan: always use directly from within git repos
• grml-live-grml -> relevant for Grml ISO only
• grml-network -> plan: merge with grml-live
• grml-paste -> included in Debian already
• grml-quickconfig -> relevant for Grml ISO only, plan: merge with grml-live
• grml-rescueboot -> included in Debian already
• grml-scripts -> already moved to grml-live (see Finalize repository merges grml-live#344)
• grml-scripts-core -> merged with grml-etc-core already
• grml-shlib -> relevant for other scripts only, copy to relevant projects and archive
• grml-terminalserver -> plan: merge with grml-live
• grml-tips -> plan: consider redesigning for integration with grml-console (idea: provide as zsh function or so?)
• grml-udev-config -> already moved to grml-live (see Finalize repository merges grml-live#344)
• grml-x -> relevant for Grml ISO only, plan: merge with grml-live
• grml2usb -> included in Debian already
• live-boot -> relevant for Grml ISO only (might not be necessary with >=bookworm based ISOs even)
• zsh-lovers -> doesn't need to be a Debian package, possibly don't even ship with Grml ISO but refer to https://grml.org/zsh/ instead

Related issues for this are #220, grml/grml-live#344, grml/grml-scripts#27 + grml/grml-etc-core#188

We're trying to integrate as many projects as possible from the list above into grml-live itself. For the remaining ones we plan to support those via Debian itself, and if relevant also provide Debian packages through GitHub Workflows with GitHub Assets.

Do we have any users of deb.grml.org, who might want to add their feedback, f.e. why and how you're using deb.grml.org, and whether our plan makes sense for you, or are we maybe even overlooking something that should prevent us from sunsetting deb.grml.org?

[crpb]

If everything (at least those packages where it might make a difference) is also available in backports to get new functionallity w/o waiting another two years i can't see any reason why not.

[mika]

If everything (at least those packages where it might make a difference) is also available in backports to get new functionallity w/o waiting another two years i can't see any reason why not.

I personally don't want to deal with Debian backports, but we plan to provide Debian packages e.g. via GitHub assets.
(And of course we want to make sure our repos work as good as possible from within the git repos checkouts as possible :))
Thanks for your feedback!

[anarcat]

i'm sure there are plenty of debian developers that will be willing to handle that backporting, if necessary.

[jeanluc2020]

I particularly like grml-crypt and jumped through a few hoops to get it onto my debian desktop machine (mainly using it for creating/mounting encrypted USB drives/sticks). It would be nice to be able to continue to do so easily on freshly installed debian machines. However, I could also clone a github repository and run it from there, so having it as a debian package wouldn't necessarily be a hard requirement.
I'm not sure I understand your grml-crypt -> grml-live comment though. Would that mean you move the script into the grml-live repository? Or move the functionality from the grml-crypt script into the grml-live script with some added parameters? I wouldn't necessarily like the latter. The former would probably be fine.

[mika]

I particularly like grml-crypt and jumped through a few hoops to get it onto my debian desktop machine (mainly using it for creating/mounting encrypted USB drives/sticks).

Good to know!

It would be nice to be able to continue to do so easily on freshly installed debian machines.

nod

However, I could also clone a github repository and run it from there, so having it as a debian package wouldn't necessarily be a hard requirement. I'm not sure I understand your grml-crypt -> grml-live comment though. Would that mean you move the script into the grml-live repository? Or move the functionality from the grml-crypt script into the grml-live script with some added parameters? I wouldn't necessarily like the latter. The former would probably be fine.

Ah, so we're only considering to move the script into the grml-live repository, so it's option "former" from your examples AFAICT. :)

Thanks for your feedback!

[anarcat]

i'm all for reducing the number of random debian repositories out there unless really necessary.

i think all grml should be formally packaged in debian, and that normal debian mechanisms (backports, fasttrack) can be used for edge cases (if needed at all).

re. grml-live and moving scripts around (which seems, to me, like a rather separate discussion - after all, all those packages could be packaged in debian as well, as is!), i wonder if one could make the argument for a grml-scripts or grml-utils package (like moreutils and friends) which could hold a bunch of tools like grml-crypt (currently its own repo/package, which i didn't know about until today!), simple-extract (in grml-etc-core, technically a zsh function i guess). I would certainly install such a package more broadly if it would be available.

grml-live, in my mind, is something else: it's "a build system for creating a Grml and Debian based Linux Live system", according to the readme...

so i don't quite see why all the scripts are being moved there...

but then again, that already happened, so maybe that ship has sailed already and it's too late! :)

in any case, total 👍 on deprecating deb.grml.org!

[sometimesfood]

Having the grml-console and grml-console-full packages in Debian main sounds great. That would remove my main use case for deb.grml.org.

Is there any progress on creating these packages and uploading them to main? Getting a nice console setup via apt is quite useful, so it would be great if there was a viable replacement for deb.grml.org before the current repo is shut down.

[mika]

Is there any progress on creating these packages and uploading them to main?
Getting a nice console setup via apt is quite useful, so it would be great if there was a
viable replacement for deb.grml.org before the current repo is shut down.

JFTR, no, we didn't have the time for this yet.

[anarcat]

do you need help with that, actually? i have a debian member hammer i can swing... ;)

[sometimesfood]

Is there any progress on creating these packages and uploading them to main?
Getting a nice console setup via apt is quite useful, so it would be great if there was a
viable replacement for deb.grml.org before the current repo is shut down.

JFTR, no, we didn't have the time for this yet.

No worries, just wanted to make sure I hadn't missed anything.

[mika]

do you need help with that, actually? i have a debian member hammer i can swing... ;)

More than welcome, IMO! :) @zeha has some great ideas/vision what we want to do here, see grml/grml-etc-core#188 - maybe we should clarify next steps we need to take care of? 🤔