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

johnraff commented 2 months ago

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 commented 2 months ago

Ah, yes, see the other issue where I suggest that! https://github.com/01micko/01micko.github.io/issues/6#issuecomment-2226807947

Will do.

johnraff commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

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

johnraff commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.

johnraff commented 1 month ago

PR sent. https://github.com/01micko/bunsen-configs/pull/1

johnraff commented 1 month ago

Hi @01micko sorry I've been neglecting this issue, distracted by various other stuff.

What I now think I'd like to do is get the eight session-related files:

bunsenlabs.desktop
bunsenlabs-wayland.desktop
bin/bunsenlabs-session
bunsen-autostart
skel-wbase/skel/.config/bunsen/autostart
skel-wbase/skel/.config/bunsen/autostart-wayland
skel-wbase/skel/.config/bunsen/environment
skel-wbase/skel/.config/bunsen/environment-wayland

Merged into the regular Carbon branch of bunsen-configs, not a future Wayland branch. The idea being to provide a connecting point where an upcoming bunsen-configs-wayland-base package can plugin if the user installs it. As discussed here: https://forums.bunsenlabs.org/viewtopic.php?id=9081

nwg-hello+cage+greetd looks as if it will work well for choosing X11/Wayland sessions (although not as pretty as lightdm) but anyway the final choice of windowing-system-agnostic Display Manager can be shelved for a while.

I'd like to get the session files settled in first, and the remaining small rough edges smoothed over. I wonder if you could make a new PR against bunsen-configs/carbon which pushes just the above eight files? Would that be a lot of extra work for you?

Of course I could just copy in those files into bunsen-configs/carbon but that way all the git history would be lost.

01micko commented 1 month ago

No problem @johnraff

I ~will~ should tweak autostart-wayland with pretty much what I have in my current skel/.config/labwc/autostart. As well as ~/.config/labwc/rc.xml as we are at 0.7.4 now.

I'll fix up the nwg-hello config to start with cage too.

I'll do that and do up a PR this week end, or I can leave nwg-hello for later, but I think it's best dealt with now.

There will be some things to consider (later):

labwc installs the wayland-sessions/labwc.desktop file so it becomes available in the greeter. It will start the native /etc/xdg/labwc/autostart I think and use the user configs. Should we care about this? Maybe not?
what to put in environment-wayland? (we can figure it out later)
what default apps?
- I think a clipboard manager is essential, and while I use nwg-clipman it might be better to use a 'launcher'; think a wayland dmenu clone, bemenu, rofi, wofi, tofi. I'm leaning toward wofi as they can all be used to display clipboard contents and double up as launchers of apps or commands - with keyboard short cuts. See my PR for labwc.github.io which I'll fix up tonight
- I already have a cut down conky-wl (wayland specific) - mainly because conky-all has been broken since the version I have in the 01micko/debian/carbon repo, should we include it - even in wbase? I have some decent configs too.
- sfwbar is a given since I can make it look very similar to tint2 and if we decide to change orientation for carbon, no problem I can mimic the look and feel.
there will be others!

johnraff commented 1 month ago

First, sorry to change my thinking again - could you please drop bunsenlabs.desktop, bunsenlabs-wayland.desktop, autostart-wayland, environment and environment-wayland from this PR (in fact a new PR, against bunsen-configs/carbon), leaving only these three files:

bin/bunsenlabs-session
bunsen-autostart
skel/.config/bunsen/autostart

And note that the modified bunsen/autostart should go into bunsen-configs/carbon in the regular skel/ directory, not into any skel-wbase directory, which does not exist yet.

The idea is that these modified files will be enough that bunsen-configs will be able to coexist with a subsequently installed bunsen-configs-wbase. Those three files should be able to recognize a Wayland session if it exists and act accordingly, otherwise X11 life will continue as normal.

I think bunsenlabs.desktopand environment are already OK the way they are, and those other Wayland-related files can be packaged in that future bunsen-configs-wbase (or whatever name we give it).

Packages can't overwrite each other's files, so if we want bunsen-configs and bunsen-configs-wbase to be able to co-exist then those three files in bunsen-configs need to be already in shape to handle a Wayland session (without messing with X11). I think they should be OK.

I ~will~ should tweak autostart-wayland with pretty much what I have in my current skel/.config/labwc/autostart. As well as ~/.config/labwc/rc.xml as we are at 0.7.4 now.

I'll fix up the nwg-hello config to start with cage too.

I'll do that and do up a PR this week end, or I can leave nwg-hello for later, but I think it's best dealt with now.

Yes, please put all these things in a new BL package. If you like I can set up the framework inside the bunsen-configs source so you can populate it with PRs. Just let me know when you're ready to send stuff and I'll make sure the structure is in place, and let you know where things should go (perhaps everything in a Wayland/ subdirectory).

* labwc installs the `wayland-sessions/labwc.desktop` file so it becomes available in the greeter. It will start the native `/etc/xdg/labwc/autostart` I think and use the user configs. Should we care about this? Maybe not?

I think it's OK like that - it won't be labelled "BunsenLabs". Openbox does the same and people who want a "pure" Openbox experience can use it.

* what to put in `environment-wayland`? (we can figure it out later)

Later, sure. I expect there will be things to put there, and anyway we can just have an empty file for now.

01micko commented 1 month ago

https://github.com/BunsenLabs/bunsen-configs/pull/133

The autostart files had no differences, so no need to add to PR

01micko / 01micko.github.io

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