bunsen-configs-base: name and version clash with BunsenLabs package

[johnraff]

About two weeks I ran the BunsenLabs Carbon-wayland netinstall script on a Debian Trixie CLI install. At that point there were no wayland related configs and I got an X-based "base" install of BL with no problems. Adding this repository also went without issues.

Unfortunately the recent addition of an upgraded Wayland version of bunsen-configs-base to this repo means that an apt upgrade will pull that in over my current BunsenLabs package.

john@trixie-tester:~$ apt policy bunsen-configs-base
bunsen-configs-base:
  Installed: 13.0-1
  Candidate: 13.0.2-0.3
  Version table:
     13.0.2-0.3 500
        500 https://01micko.github.io/debian carbon-trixie/main amd64 Packages
 *** 13.0-1 500
        500 https://pkg.bunsenlabs.org/debian carbon/main amd64 Packages
        100 /var/lib/dpkg/status

This is only a testing VM so I will now do an apt upgrade to see what happens, but expect some fairly drastic changes, which even a testing user might not anticipate.

I suggest renaming the Wayland version of bunsen-configs-base to something which will not clash with the current BunsenLabs package (eg bunsen-configs-wbase). A new (or renamed) stanza in debian/control, additions to the Replaces: and Conflicts: lines, along with a new set of files in debian/ should do it.

[01micko]

Ah, yes, see the other issue where I suggest that! #6 (comment)

Will do.

[johnraff]

A new package name will avoid the clash, and version number will also become irrelevant. Cool.

Later we can cherry-pick the necessary bits into the official BL package - once that final structure is sorted out. Needn't be in such a hurry as long as we've got your experimental packages to work with.

[johnraff]

I will now do an apt upgrade to see what happens

What happened is that dpkg reported an error running bunsen-configs-base post-installation script.
The only change you made is at the bottom:

GREETD="/etc/greetd"

    # fix ownership of introduced files, allow showing graphical login 
    if [ -d "$GREETD" ]
    then
        chown -R _greetd:_greetd "$GREETD"
	usermod -a -G video _greetd
    fi

Tried that chown command in a terminal to be told chown: invalid user '_greetd:_greetd'
and usermod: user '_greetd' does not exist
I guess if there's no user _greetd then chown and usermod will fail. Certainly not in /etc/group.

And sure enough the package greetd had not been installed. Installed that and dpkg sorted bunsen-configs-base out by itself.

[01micko]

Hmmm.. should I add a condition... yes methinks

groups _greetd >/dev/null 2>&1 && do it || fail

[johnraff]

That looks good. Did you think of testing with 'groups' or is that a standard way of testing if a user exists?

Debian maintainer scripts must not return 1 or else dpkg goes into a sulk, so in fact || true is a safer way to end a line that might fail.

Anyway I only did that apt upgrade to see what got broken, and the good news is the X session still worked fine. The lightdm login had a new "Bunsen Wayland Session" item, which didn't work, but the new stuff in "staging" might well put that right. (Systemd did have something to say about a service symlink which already pointed to lightdm.)

[01micko]

I just thought about the 'groups' command, probably the least convoluted way of doing it.

Also, for now I've purged 'bunsen-configs-base' from the repo. (about to push)

A new package name will avoid the clash, and version number will also become irrelevant. Cool.

I can add it back later and I think using 'wbase', my original thought that has the least possible chance of causing conflicts.

I'll start a new branch - 'staging0' or something forked from yours, start again, but not too much work, mainly debian/* files.

[01micko]

Just pushed to staging0 @johnraff
Note that I had to use debian revision -1.1 to build. See changelog in stagin0 branch

Here's the tree of produced debian stuff

├── bunsen-configs_13.0-1.1_all.deb
├── bunsen-configs_13.0-1.1_amd64.build
├── bunsen-configs_13.0-1.1_amd64.buildinfo
├── bunsen-configs_13.0-1.1_amd64.changes
├── bunsen-configs_13.0-1.1.debian.tar.xz
├── bunsen-configs_13.0-1.1.dsc
├── bunsen-configs_13.0.orig.tar.gz -> bunsen-configs-13.0.tar.gz
├── bunsen-configs-13.0.tar.gz
├── bunsen-configs-base_13.0-1.1_all.deb
├── bunsen-configs-lite_13.0-1.1_all.deb
└── bunsen-configs-wbase_13.0-1.1_all.deb

All should be fully reproducible. I will rebuild with just wbase in the control file so I can upload otherwise they would all get uploaded. Even though they would conflict (1.1 > 1) it shouldn't matter. More soon.

[johnraff]

Note that I had to use debian revision -1.1 to build. See changelog in staging0 branch

I see you still have no "non-maintainer upload" line in the changelog. That might be why you needed to go to -1.1.
See my comment about control and changelog in the previous (now purged) package. If you're using dch to write the changelog you can pass the option -n and get that automatically.

But as long as you don't upload any bunsen-configs packages whose names clash with official packages it should be OK anyway.

I will rebuild with just wbase in the control file so I can upload otherwise they would all get uploaded.

Sounds good.

Even though they would conflict (1.1 > 1) it shouldn't matter.

Yeah, not quite sure about that. Let's play safe.

[01micko]

I think it's all sorted now so closing. See the repo tree here.

├── bunsen-configs_13.0-1.1_amd64.build
├── bunsen-configs_13.0-1.1_amd64.buildinfo
├── bunsen-configs_13.0-1.1_amd64.changes
├── bunsen-configs_13.0-1.1.debian.tar.xz
├── bunsen-configs_13.0-1.1.dsc
├── bunsen-configs_13.0.orig.tar.gz -> bunsen-configs-13.0.tar.gz
├── bunsen-configs-13.0.tar.gz
└── bunsen-configs-wbase_13.0-1.1_all.deb

[johnraff]

I'm afraid I might have given you some bad advice. As long as you don't upload any other of the packages that the bunsen-configs source package generates I think we should be safe though. The thing is, you've added some files into the source directory outside debian/ so the whole package version number needs to change. You see, bunsen-configs_13.0.orig.tar.gz is no longer the same as the bunsen-configs_13.0.orig.tar.gz on the BL server. There is a potential clash if any utility tries to access that file from one or the other of the two servers. It's probably OK right now, but might be safer if you updated your version from 13.0-1.1 to eg 13.0.1-1.1 with a new changelog entry, so it's clear the two orig files are different. Then I'll be careful when I eventually merge your code and upgrade the package to use a version number which is higher than yours.

I'm not quite sure, to be honest, just what the fully Standards Compliant way to do this would be. We want your code to remain in a fork of the BL git repo so that it can be merged easily. I now think I should merge your current code into a new branch of the BL bunsen-configs repo before doing any restructuring of that package, rather than after. Pull Requests can be initiated from my end as well as yours, so I don't think there's anything you need to do for that.

[01micko]

The only things that really need merging are:

• bunsenlabs-session
• bunsenlabs-wayland-session (symlink)
• bunsenlabs-wayland.desktop
• skel-wbase/skel/.config/bunsen/autostart

The rest is fluff. I can put essential stuff in nestinstall or create my own custom packages unrelated to configs.

I'm going to try my best to get my finicky HP to login from lightdm - but I still don't like the idea that it drags in X. That will probably change in time.
I can create a PR for the above items only if you like.

[johnraff]

Right, the key stuff is what sets up the session. That will be needed for people to have the option to start a labwc session.

The "fluff" is of course quite important for inexperienced users, but as you say it can probably be easily added via the netinstall script at this stage.

Please see my recent comments about the session though:
https://forums.bunsenlabs.org/viewtopic.php?pid=136072#p136072
https://forums.bunsenlabs.org/viewtopic.php?pid=136086#p136086
Essentially I'm suggesting adding a second user autostart file ~/.config/bunsen/autostart-wayland, which will need some changes in the two BL session scripts. I think it will make things easier for users though.

If you like, I could sketch out suggested modifications for bunsenlabs-session, bunsen-autostart, autologin and wayland-autologin.
I could even send a PR against your repo...

I've also started a thread about possible reorganization of bunsen-configs:
https://forums.bunsenlabs.org/viewtopic.php?id=9072
If we end up splitting off a separate bunsenlabs-session package, that's where your final PR for files above will need to go.

I don't think there's anything difficult about any of this, but you might want to wait a bit to see how it works out.

[johnraff]

Re lightdm and lightdm-gtk-greeter, I just did a dummy install --without-recommends and it didn't want to bring in any X packages. Whether it would work like that is another question...

(xwayland already brings in xserver-common)

[johnraff]

I've modified the session files so that they should work on both X and Wayland, adding ~/.config/bunsen/autostart-wayland
Now I can launch eg lxpolkit from autostart-wayland, and the excess conkys from the X11 autostart are not started up.
There's probably some scope for cleaning up, but they seem to be doing the job atm.

No time left now because without a Trixie spice-vdagent I can't just copy-paste the files from the VM into the Real World, and I'm away 3 days from tomorrow, but I'll post something ASAP.