Hi,
Cyril Brulebois wrote (Sun, 12 May 2024 08:54:11 +0200):
> Keeping the whole git history of tasksel without its tag is probably
> fine, in case anyone needs to dig up why this thing is done that way,
> but I'm not sure we should keep tasksel entries in debian/changelog; I
> would probably only keep the blendsel entry, adding a reference to the
> version of tasksel it was forked off from. Unless some others feel
> strongly we should keep the whole tasksel history in debian/changelog?
I only kept that for completeness; didn't intended to keep it on the long
run. Now cleaned up.
> I've fixed a few minor things for the rename. It looks to me the README
> could probably be stripped down to mention blendsel's being a fork of
> tasksel, and pointing at tasksel's README for more information. Less
> duplication would be best (and I'm not sure how current the contents are
> anyway). Ditto for tasks/README.
Adapting READMEs is my todo list.
> I think you know best how to adjust README.translators :)
>
> I'm happy to upload it as-is (modulo debian/changelog), but I suspect
> it'd make sense to adjust tasks/ before doing so? Happy either way.
I would like to leave it as is for now.
Thank you very much for taking care of this thingy!
> > - I prepared a change in pkgsel, to call blendsel depending on the
> > descision, if Debian pure blends are wanted or not.
> > See https://salsa.debian.org/holgerw/pkgsel/
>
> That I didn't check yet, my focus is on the current blocker (as far as
> the DM vs. DD limitation is concerned).
Ok, fine with me.
Just wanted to illustrate to whole idea behind this approach.
> > Anyway, I think I have it running so far, the blendsel dialog appears
> > and shows the items to select; I'm attaching a screenshot showing the
> > current state (please note, that the dialog shows three desktop environments
> > as placeholder for now; the tasksel - and therefore blendsel as well -
> > logic does not allow to have packages|tasks|blends listed that don't
> > have the corresponding task-* packages in the archive).
>
> Understood, but please let me know if it makes sense to have them in the
> 0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been
> accepted.
I would like to keep that for future releases, even if I already went one step
further: thanks to Phil's Salsa CI black-magic tests it's proven that basically
it works in the wild as expected. Thanks Phil!
> > The template should be rephrased, I would ask for review on
> > debian-l10n-english when the time comes, but I guess there is still
> > time for that...
>
> You should talk to our beloved l10n coordinator!
Need to find some time when being along at home, to prevent my wife from
pondering "Hmm, Holger is getting bewildered, he's having a discussion with
himself!" :-)))
> And yeah, lintian/bookworm reports some things we don't normally do:
>
> W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16]
>
> Seriously though, I'm not familiar with the semantics behind /first vs.
> /tasks in tasksel. Do we want/need the same semantics in blendsel?
I already realized, that blendsel/first is not used at all, so that can go away
I think.
> I think we should have lintian-overrides for the main package, just like
> tasksel, at least for those (again, only running lintian/bookworm):
>
> E: blendsel: no-debconf-config
> W: blendsel: debconf-is-not-a-registry
> [usr/lib/blendsel/blendsel-debconf:3]
Done.
> Finally, this should probably go away from both packages, I don't even
> remember having managed that package:
>
> Conflicts: base-config (<< 2.32)
>
> (And indeed, that was 20 years ago.)
Done.
So ready for first upload! Get the ball rolling :-)
> Bonus points: maybe clean up tasksel's debian/source/lintian-overrides?
>
On the todo list now.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
