BunsenLabs-wayland repository - in development

johnraff · 2024-11-18 04:42:19

micko01 wrote:

Removed azote
Official trixie has a newer version of the wayland nitrogen wannabe so no need to hang on to rotting bits.

Would building a newer azote be a lot of work? If not, I wonder if you might consider putting it back on this repo for a while - till Debian sort out their dependency issues anyway?

micko01 · 2024-11-18 05:47:25

johnraff wrote:

micko01 wrote:
Removed azote
Official trixie has a newer version of the wayland nitrogen wannabe so no need to hang on to rotting bits.
Would building a newer azote be a lot of work? If not, I wonder if you might consider putting it back on this repo for a while - till Debian sort out their dependency issues anyway?

I can do that. I'll get to it some time this week.

johnraff · 2024-11-18 08:01:46

^Thanks!

micko01 · 2024-11-20 12:21:53

Ok, if I do repackage azote what would you suggest for the debian revision number? Currently in trixie the package is 1.13.1-1 (current release). Should I go for an NMU of -1.1?

I have found another wallpaper setter called hyprwall https://github.com/hyprutils/hyprwall. It's written in rust and probably won't be too hard to package.

There is a static 64 bit binary on the release page (probably at least depends on GTK-4.0) that seems to work fine in X11 (with feh) and wayland (with swaybg or others) with some brief testing, although I couldn't figure out the multi-monitor support.

----------

In other news, this afternoon I did an apt update (as you do) and greetd got updated. I didn't think much about it but when I went to log out to test hyprwall on openbox the logout crashed me to a frozen console! . Had to switch VT and do a clean shut down. I suppose that's what happens with such a vast ecosystem as linux.

johnraff · 2024-11-21 05:58:07

micko01 wrote:

Ok, if I do repackage azote what would you suggest for the debian revision number? Currently in trixie the package is 1.13.1-1 (current release). Should I go for an NMU of -1.1?

1.13.1-1.1 would probably be fine, or even 1.13.1-1.1~bl1 (~bl2 for a further tweak, etc) if you wanted to insure against somebody else uploading a 1.13.1-1.1 NMU to Debian. The tilde ensures that your package is regarded as having a lower version than the same version without it, so that hypothetical 1.13.1-1.1 would "win" over our 1.13.1-1.1~bl*

I have found another wallpaper setter called hyprwall https://github.com/hyprutils/hyprwall. It's written in rust and probably won't be too hard to package.

That looks rather nice too. If it turns out we can't use azote from Debian and have to ship our own build of someone's source, then surely hyprwall would be a candidate.

There is a static 64 bit binary on the release page that seems to work fine...

Binary blob is OK for testing or personal use, but as an open source project we shouldn't ship that, but build it ourselves from publicly available source code.

Off topic: can you tell me about Rust in a couple of sentences? I have no idea what it is.

In other news, this afternoon I did an apt update and greetd got updated ...when I went to log out the logout crashed me to a frozen console!

It seems fairly common for apps to crash if you upgrade them while they're in use. Happens with Firefox, even systemd (I think it was). It would be nice if they didn't freeze the desktop though. Usually a reboot fixes it, but sometimes if you're on a VM...

Had to switch VT and do a clean shut down.

I got frozen on a VM a couple of days ago playing on Wayland with a wallpaper setter where the necessary image viewer wasn't installed. Couldn't even switch to a different TTY, just completely frozen. I had to force shutdown from qemu which broke the following bootup. Luckily fsck got triggered at some point and it fixed itself. It might be worth considering installing openssh-server on testbed VMs to see if ssh-ing into a frozen system would help. Or maybe I should have looked into what a virsh qemu-agent-command could have done.

micko01 · 2024-11-22 06:17:54

Azote is packaged and uploaded. Tested and the deb version -1.1~bl1 overrides the installed version just fine.

If I get time over the WE I'll build and package hyprwall.

johnraff wrote:

Binary blob is OK for testing or personal use, but as an open source project we shouldn't ship that, but build it ourselves from publicly available source code.

..and that's the only reason I mentioned it. Good for testing.

johnraff · 2024-11-22 06:59:59

^thanks! Moving along...

johnraff · 2024-11-23 05:40:32

Azote showing up nicely in 'apt policy':

john@trixie-tester:~$ apt policy azote
azote:
  Installed: 1.13.1-1
  Candidate: 1.13.1-1.1~bl1
  Version table:
     1.13.1-1.1~bl1 500
        500 https://01micko.github.io/debian carbon-trixie/main amd64 Packages
 *** 1.13.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status

So yes, 1.13.1-1.1~bl1 is taken as the candidate, and will replace 1.13.1-1 in an upgrade.

But this reminds me of a subtle issue I was wondering about:
01micko.github.io/debian carbon-trixie is given the default pin number of 500.
OTOH Debian backports get 100, which means users who want to upgrade to the backports version of a package need to use the -t option. General runs of 'apt upgrade' will not pull in backported packages.

It's your call @micko01, but I wonder what you would think about setting your repo to pin 100 instead of 500? I could see pros and cons either way, but it would protect testing users from accidentally pulling in experimental versions of packages, while allowing apt upgrades to proceed normally.

In my reprepro settings, this is done for BL backports with this in the appropriate stanza in reprepro's conf/distributions:

NotAutomatic: yes
ButAutomaticUpgrades: yes

full stanza example:

Origin: bunsenlabs
Label: bunsenlabs
Codename: bookworm-backports
Suite: bookworm-backports
Architectures: i386 amd64 source
Components: main
Description: BunsenLabs bookworm backports repository
SignWith: AED6420C
NotAutomatic: yes
ButAutomaticUpgrades: yes
Contents: allcomponents

EDIT I remembered what triggered this was having the experimental lightdm here. It might be nice to have it as an optional upgrade if we want to see if it fixes some issue or other, while keeping the official package installed on our systems till then.

Last edited by johnraff (2024-11-23 07:47:20)

johnraff · 2024-11-23 05:56:05

BTW after today's upgrade, apt autoremove was able to do a big clearout. A couple of other packages had been upgraded too (eg linux-image-6.11.4-amd64), but the bulk of this is because of your azote rebuild.
See all those *-dev packages?

john@trixie-tester:~$ sudo apt autoremove
[sudo] password for john: 
REMOVING:                       
  gir1.2-atspi-2.0              libopengl-dev
  gir1.2-cloudproviders-0.3.0   libpango1.0-dev
  gir1.2-freedesktop-dev        libpcre2-32-0
  gir1.2-glib-2.0-dev           libpcre2-dev
  girepository-tools            libpcre2-posix3
  icu-devtools                  libpixman-1-dev
  libatk-bridge2.0-dev          libpkgconf3
  libatk1.0-dev                 libpng-dev
  libatspi2.0-dev               libselinux1-dev
  libblkid-dev                  libsepol-dev
  libbrotli-dev                 libsharpyuv-dev
  libbz2-dev                    libsm-dev
  libcairo-script-interpreter2  libsysprof-capture-4-dev
  libcairo2-dev                 libthai-dev
  libcloudproviders-dev         libtiff-dev
  libdatrie-dev                 libtiffxx6
  libdbus-1-dev                 libwayland-bin
  libdeflate-dev                libwayland-dev
  libegl-dev                    libwebp-dev
  libegl1-mesa-dev              libwebpdecoder3
  libepoxy-dev                  libx11-dev
  libexpat1-dev                 libxau-dev
  libffi-dev                    libxcb-render0-dev
  libfontconfig-dev             libxcb-shm0-dev
  libfreetype-dev               libxcb1-dev
  libfribidi-dev                libxcomposite-dev
  libgdk-pixbuf-2.0-dev         libxcursor-dev
  libgio-2.0-dev                libxdamage-dev
  libgio-2.0-dev-bin            libxdmcp-dev
  libgirepository-2.0-0         libxext-dev
  libgl-dev                     libxfixes-dev
  libgles-dev                   libxft-dev
  libgles1                      libxi-dev
  libglib2.0-dev                libxinerama-dev
  libglib2.0-dev-bin            libxkbcommon-dev
  libglvnd-core-dev             libxrandr-dev
  libglvnd-dev                  libxrender-dev
  libglx-dev                    libxtst-dev
  libgraphite2-dev              libzstd-dev
  libgtk-3-dev                  linux-image-6.11.4-amd64
  libharfbuzz-cairo0            native-architecture
  libharfbuzz-dev               pango1.0-tools
  libharfbuzz-icu0              pkgconf
  libharfbuzz-subset0           pkgconf-bin
  libice-dev                    python3-packaging
  libicu-dev                    uuid-dev
  libjbig-dev                   wayland-protocols
  libjpeg-dev                   x11proto-dev
  libjpeg62-turbo-dev           xorg-sgml-doctools
  liblerc-dev                   xtrans-dev
  liblzma-dev                   zlib1g-dev
  libmount-dev

Summary:
  Upgrading: 0, Installing: 0, Removing: 103, Not Upgrading: 0
  Freed space: 246 MB

Continue? [Y/n]

Last edited by johnraff (2024-11-23 05:58:43)

DeepDayze · 2024-11-23 20:38:54

johnraff wrote:

BTW after today's upgrade, apt autoremove was able to do a big clearout. A couple of other packages had been upgraded too (eg linux-image-6.11.4-amd64), but the bulk of this is because of your azote rebuild.
See all those *-dev packages?

john@trixie-tester:~$ sudo apt autoremove
[sudo] password for john: 
REMOVING:                       
  gir1.2-atspi-2.0              libopengl-dev
  gir1.2-cloudproviders-0.3.0   libpango1.0-dev
  gir1.2-freedesktop-dev        libpcre2-32-0
  gir1.2-glib-2.0-dev           libpcre2-dev
  girepository-tools            libpcre2-posix3
  icu-devtools                  libpixman-1-dev
  libatk-bridge2.0-dev          libpkgconf3
  libatk1.0-dev                 libpng-dev
  libatspi2.0-dev               libselinux1-dev
  libblkid-dev                  libsepol-dev
  libbrotli-dev                 libsharpyuv-dev
  libbz2-dev                    libsm-dev
  libcairo-script-interpreter2  libsysprof-capture-4-dev
  libcairo2-dev                 libthai-dev
  libcloudproviders-dev         libtiff-dev
  libdatrie-dev                 libtiffxx6
  libdbus-1-dev                 libwayland-bin
  libdeflate-dev                libwayland-dev
  libegl-dev                    libwebp-dev
  libegl1-mesa-dev              libwebpdecoder3
  libepoxy-dev                  libx11-dev
  libexpat1-dev                 libxau-dev
  libffi-dev                    libxcb-render0-dev
  libfontconfig-dev             libxcb-shm0-dev
  libfreetype-dev               libxcb1-dev
  libfribidi-dev                libxcomposite-dev
  libgdk-pixbuf-2.0-dev         libxcursor-dev
  libgio-2.0-dev                libxdamage-dev
  libgio-2.0-dev-bin            libxdmcp-dev
  libgirepository-2.0-0         libxext-dev
  libgl-dev                     libxfixes-dev
  libgles-dev                   libxft-dev
  libgles1                      libxi-dev
  libglib2.0-dev                libxinerama-dev
  libglib2.0-dev-bin            libxkbcommon-dev
  libglvnd-core-dev             libxrandr-dev
  libglvnd-dev                  libxrender-dev
  libglx-dev                    libxtst-dev
  libgraphite2-dev              libzstd-dev
  libgtk-3-dev                  linux-image-6.11.4-amd64
  libharfbuzz-cairo0            native-architecture
  libharfbuzz-dev               pango1.0-tools
  libharfbuzz-icu0              pkgconf
  libharfbuzz-subset0           pkgconf-bin
  libice-dev                    python3-packaging
  libicu-dev                    uuid-dev
  libjbig-dev                   wayland-protocols
  libjpeg-dev                   x11proto-dev
  libjpeg62-turbo-dev           xorg-sgml-doctools
  liblerc-dev                   xtrans-dev
  liblzma-dev                   zlib1g-dev
  libmount-dev

Summary:
  Upgrading: 0, Installing: 0, Removing: 103, Not Upgrading: 0
  Freed space: 246 MB

Continue? [Y/n]

In a way it's a great thing an update sweeps out the -dev packages for a clean slate. Perhaps just then reinstall what's needed to build a particular package and it begins anew...

johnraff · 2024-11-24 07:31:24

Yeah, those dev packages were there because the Debian build of azote in the Trixie repos has a dependency on libgtk-3-dev which in turn depends on a whole slew of other dev packages. I think that's a bug: https://bugs.debian.org/cgi-bin/bugrepo … ug=1088092
but meanwhile @micko01 has rebuilt azote for us with sane dependencies. When I upgraded to that, all those other packages became unnecessary.

---
Building packages from source does tend to pull in a lot of unwanted -dev packages. These days I try to do it on pbuilder as much as possible, so the build happens in an isolated chroot which is deleted after the work is done. Keeps your system clean and makes sure the build doesn't depend on any special packages that might have come from 3rd party sources.

Last edited by johnraff (2024-11-24 07:35:39)

micko01 · 2024-11-24 08:52:03

johnraff wrote:

Azote showing up nicely in 'apt policy':
john@trixie-tester:~$ apt policy azote
azote:
  Installed: 1.13.1-1
  Candidate: 1.13.1-1.1~bl1
  Version table:
     1.13.1-1.1~bl1 500
        500 https://01micko.github.io/debian carbon-trixie/main amd64 Packages
 *** 1.13.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status
So yes, 1.13.1-1.1~bl1 is taken as the candidate, and will replace 1.13.1-1 in an upgrade.
But this reminds me of a subtle issue I was wondering about:
01micko.github.io/debian carbon-trixie is given the default pin number of 500.
OTOH Debian backports get 100, which means users who want to upgrade to the backports version of a package need to use the -t option. General runs of 'apt upgrade' will not pull in backported packages.
It's your call @micko01, but I wonder what you would think about setting your repo to pin 100 instead of 500? I could see pros and cons either way, but it would protect testing users from accidentally pulling in experimental versions of packages, while allowing apt upgrades to proceed normally.
In my reprepro settings, this is done for BL backports with this in the appropriate stanza in reprepro's conf/distributions:
NotAutomatic: yes
ButAutomaticUpgrades: yes
full stanza example:
Origin: bunsenlabs
Label: bunsenlabs
Codename: bookworm-backports
Suite: bookworm-backports
Architectures: i386 amd64 source
Components: main
Description: BunsenLabs bookworm backports repository
SignWith: AED6420C
NotAutomatic: yes
ButAutomaticUpgrades: yes
Contents: allcomponents
EDIT I remembered what triggered this was having the experimental lightdm here. It might be nice to have it as an optional upgrade if we want to see if it fixes some issue or other, while keeping the official package installed on our systems till then.

Right so here's mine:

Origin: bunsenlabs testing
Label: bunsenlabs testing
Codename: carbon-trixie
Architectures: source amd64 i386 arm64
Components: main
Description: Apt repository for project bunsenlabs testing
SignWith: 87EEBEE1F

So simply appending

NotAutomatic: yes
ButAutomaticUpgrades: yes

should make the apt policy pin number from my repo 100 ?

Just making sure before I pull the trigger

johnraff · 2024-11-25 05:49:24

micko01 wrote:

johnraff wrote:
...a subtle issue I was wondering about:
01micko.github.io/debian carbon-trixie is given the default pin number of 500.
OTOH Debian backports get 100...
It's your call @micko01, but I wonder what you would think about setting your repo to pin 100 instead of 500?
In my reprepro settings, this is done for BL backports with this in the appropriate stanza in reprepro's conf/distributions:
NotAutomatic: yes
ButAutomaticUpgrades: yes
full stanza example:
Origin: bunsenlabs
Label: bunsenlabs
Codename: bookworm-backports
Suite: bookworm-backports
Architectures: i386 amd64 source
Components: main
Description: BunsenLabs bookworm backports repository
SignWith: AED6420C
NotAutomatic: yes
ButAutomaticUpgrades: yes
Contents: allcomponents
Right so here's mine:
Origin: bunsenlabs testing
Label: bunsenlabs testing
Codename: carbon-trixie
Architectures: source amd64 i386 arm64
Components: main
Description: Apt repository for project bunsenlabs testing
SignWith: 87EEBEE1F
So simply appending
NotAutomatic: yes
ButAutomaticUpgrades: yes
should make the apt policy pin number from my repo 100 ?

Yes, that's all I had to do. The actual work is done by apt:

man reprepro wrote:

NotAutomatic
This optional field is simply copied into the Release files.
(The value is handled as an arbitrary string, though anything
but yes does not make much sense right now.)
ButAutomaticUpgrades
This optional field is simply copied into the Release files.
(The value is handled as an arbitrary string, though anything
but yes does not make much sense right now.)

You'll no doubt have to run some reprepro command like 'export' or 'processincoming' to get the changes recognized.
Test with an 'apt update' and 'apt policy' on some system that has your repo enabled.

micko01 · 2024-11-25 10:38:20

^ well it worked - got error message on apt update

Error: Repository 'https://01micko.github.io/debian carbon-trixie InRelease' changed its default priority for apt_preferences(5) from 500 to 100.
Notice: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y

I think an error is a bit harsh! But oh well, yay debian!

$ apt policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 https://repo.vivaldi.com/stable/deb stable/main amd64 Packages
     release o=Vivaldi Technologies,a=stable,l=Official Vivaldi package repository,c=main,b=amd64
     origin repo.vivaldi.com
 500 https://pkg.bunsenlabs.org/debian carbon/main amd64 Packages
     release o=bunsenlabs,a=carbon,n=carbon,l=bunsenlabs,c=main,b=amd64
     origin pkg.bunsenlabs.org
 100 https://01micko.github.io/debian carbon-trixie/main amd64 Packages
     release o=bunsenlabs testing,n=carbon-trixie,l=bunsenlabs testing,c=main,b=amd64
     origin 01micko.github.io
 500 http://mirror.aarnet.edu.au/debian trixie/non-free-firmware amd64 Packages
     release o=Debian,a=testing,n=trixie,l=Debian,c=non-free-firmware,b=amd64
     origin mirror.aarnet.edu.au
 500 http://mirror.aarnet.edu.au/debian trixie/main amd64 Packages
     release o=Debian,a=testing,n=trixie,l=Debian,c=main,b=amd64
     origin mirror.aarnet.edu.au
Pinned packages:

So it works

----

EDIT: For the record this was the kicker:

reprepro export carbon-trixie

Last edited by micko01 (2024-11-25 10:41:35)

johnraff · 2024-11-26 02:29:03

micko01 wrote:

...got error message on apt update

Error: Repository 'https://01micko.github.io/debian carbon-trixie InRelease' changed its default priority for apt_preferences(5) from 500 to 100.
Notice: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y

I think an error is a bit harsh! But oh well, yay debian!

A bit harsh, agreed. A warning would seem about right. Every time Debian do a point upgrade 'apt-get update' puts out a message like that - without even offering the chance to accept if I remember right - but 'apt update' just puts up a notification.

I suppose a repo suddenly changing - especially raising - its priority should be seen as something to check with the user.

Last edited by johnraff (2024-12-03 08:48:26)

micko01 · 2024-11-30 11:06:33

Have just uploaded gtk3dialog_0.1.0-2_amd64.deb and gtk3dialog-doc_0.1.0-2_all.deb = heaps of docs! Manual pages in with the main binary.

Gtk3dialog - A small utility for fast and easy GUI building

https://github.com/01micko/gtk3dialog

I forked this off the Puppy Linux version that didn't get much love since I left there, and probably not much before that since 2013. It was originally written in 2004 or so by László Pere and picked up by Thunor (an SDL game developer - so not too shabby with C ) in 2011. He added GTK-3.0 support.

I've spent quite a bit of time fixing bugs, updating widgets, getting rid of deprecated functions and documenting this thing. It was reasonably well documented but there were shortcomings and it was getting quite dated since it was written for GTK-2.0 (in fact IIRC it started out as GTK-1.0 ).

It was GTK2/3 with a lot of #ifdef pre-processing but I removed nearly all that and made it GTK3 only (hence the name - and to differentiate against upstream - and the name may change again - needs to be shorter).

It *might* should build ok in Bookworm too as in my CI it build fine on Ubuntu Jammy, which is over 2 years old now (may need to disable vte).

Anyway, if anyone likes they can download, RTFM, look at the examples and have some fun. It has a bit more flexibility than Yad.

EDIT: debver -1 was aborted for missing build depends.

Last edited by micko01 (2024-11-30 11:22:59)

johnraff · 2024-12-03 08:53:00

micko01 wrote:

...if anyone likes they can download, RTFM, look at the examples and have some fun. It has a bit more flexibility than Yad.

Considering yad seems to be running out of steam lately, that might well be something nice to have in our toolbox.

If someone would like to try out migrating a BL script from yad to gtk3dialog, and check out how hard it is...

johnraff · 2024-12-15 03:11:04

Small issue with the micko repo version of azote, this message:

libappindicator-gtk3 package not found - tray icon unavailable

And indeed the azote icon that the Debian package put in the tray is replaced by a square generic thing.
The micko package declares 'Recommends: libayatana-appindicator3-1' and that's installed.

BTW the debian version of azote declares 'Recommends: libayatana-appindicator-dev' which doesn't even exist! It should be libayatana-appindicator3-dev (with 168 MB of dependencies and installing it didn't fix the issue).

Anyway a rather small issue.

micko01 · 2024-12-15 08:46:17

^This seems like an azote bug. My python is NFG so IDK how to fix at this stage.

johnraff · 2024-12-16 02:21:25

The Debian version of Azote pulled in such a multi-mega mountain of dependencies that I don't feel like installing it again to check, but I seem to remember it displayed the icon OK without that error message.

But it's a small issue, probably not worth the hours and hours of code-unpicking it would take to track down.

#81 2024-11-18 04:42:19

Re: BunsenLabs-wayland repository - in development

#82 2024-11-18 05:47:25

Re: BunsenLabs-wayland repository - in development

#83 2024-11-18 08:01:46

Re: BunsenLabs-wayland repository - in development

#84 2024-11-20 12:21:53

Re: BunsenLabs-wayland repository - in development

#85 2024-11-21 05:58:07

Re: BunsenLabs-wayland repository - in development

#86 2024-11-22 06:17:54

Re: BunsenLabs-wayland repository - in development

#87 2024-11-22 06:59:59

Re: BunsenLabs-wayland repository - in development

#88 2024-11-23 05:40:32

Re: BunsenLabs-wayland repository - in development

#89 2024-11-23 05:56:05

Re: BunsenLabs-wayland repository - in development

#90 2024-11-23 20:38:54

Re: BunsenLabs-wayland repository - in development

#91 2024-11-24 07:31:24

Re: BunsenLabs-wayland repository - in development

#92 2024-11-24 08:52:03

Re: BunsenLabs-wayland repository - in development

#93 2024-11-25 05:49:24

Re: BunsenLabs-wayland repository - in development

#94 2024-11-25 10:38:20

Re: BunsenLabs-wayland repository - in development

#95 2024-11-26 02:29:03

Re: BunsenLabs-wayland repository - in development

#96 2024-11-30 11:06:33

Re: BunsenLabs-wayland repository - in development

#97 2024-12-03 08:53:00

Re: BunsenLabs-wayland repository - in development

#98 2024-12-15 03:11:04

Re: BunsenLabs-wayland repository - in development

#99 2024-12-15 08:46:17

Re: BunsenLabs-wayland repository - in development

#100 2024-12-16 02:21:25

Re: BunsenLabs-wayland repository - in development

Board footer