BunsenLabs-wayland repository - in development

micko01 · 2024-06-21 07:51:05

I have started up a proper Debian repository, using https transport and proper debian security on github preempting the release of Debian Trixie 13 and more importantly Bunsenlabs Carbon. You can see discussion in the Wayland and BunsenLabs thread.

For the current state of the repo visit the below link

Current state of the repository

I'm looking for people who are keen to package for this repo and test the repo - testing may have to come at a later date, as there isn't much there yet. That won't take too long, maybe a month or so.

The repo is hosted at https://github.com/01micko/01micko.github.io

The short term goal is to offer up a net install to build a developer preview of BunsenLabs on Wayland. I've been running on bare metal and hacking in stuff as I go and a lot of that (configs and the like) will hopefully make it back to the BunsenLabs repo proper.

The mid term goal is to offer up a meta package to install Wayland on top of a stock BunsenLabs X install and hopefully switch between them at logout/login.

The nitty gritty

To start packaging you need to read up!

* @johnraff's thread is s good start - Debian packaging - just the very basics

* I have some stuff in my Links page including how to setup the repo (must be running trixie).

* Debian basic packaging tutorial - which is mostly up to date https://www.debian.org/doc/manuals/debm … 04.en.html

If you know how to package

* There are instructions for Pull Requests in The README.md/debian/ at my github repo.

How to test

This will come at a later date, so stay tuned, but if you already have a standard trixie graphical install then you can follow the instructions on my above Links page.

---
Speaking of the repo, it's up!

Only 2 packages azote and labwc-menu-generator, but it is a success! I enabled it on my laptop and after sudo apt update I was offerred to update labwc-menu-generator_0.1-1 to labwc-menu-generator_0.1.0-1! Works a treat . Also installed azote.

Now onto building some more packages .. hopefully I'll have a few done by the end of the week-end.

Last edited by micko01 (2024-07-08 11:25:37)

hhh · 2024-06-21 18:04:41

micko01 wrote:

Speaking of the repo, it's up!

Super cool!

nwg packages are starting to come into the repo...

https://packages-pkgmirror-csail.debian … ywords=nwg

micko01 · 2024-06-21 22:06:49

hhh wrote:

micko01 wrote:
Speaking of the repo, it's up!
Super cool!
nwg packages are starting to come into the repo...
https://packages-pkgmirror-csail.debian … ywords=nwg

That's great! Already using official nwg-hello and as others make trixie official I'l take whatever nwg* packages I host out.

@hhh and anyone else that wants to make packages for trixie that official doesn't cover, I have put instructions for offering a PR in the README.md to add packages.

README.md/debian/

01micko@github wrote:

This is a special repository that complements BunsenLabs (mostly) but can be used on any debian system.
I will accept packages compiled on debian/trixie the proper debian way. If you don't know what the debian way is then learn!
If you have packages to add then I need the full suite of files produced including debug symbol files (if produced) but do not try to insert them in the debian/ directory. Just create any directory name you want (the package name would be a good idea) and add them there. Leave them unsigned as they need to be signed by my key for apt to work correctly. Offer up your PR.

johnraff · 2024-06-22 05:44:34

@Micko this looks brilliant. And it all appeared while I was away a couple of days! Speed!!

I was also super-impressed by your debianization of labwc-menu-generator (the only one I looked at). Is that the work of Osamu Aoki's utility debmake or did you really figure it all out over a weekend? (The only bit that had me puzzled was the changelog's "Closes: #1003272". That points to a Lintian bug, but in the Debian world it should be an Intent To Package bug on labwc-menu-generator. In BL I've never added such entries in fact.)

micko01 wrote:

I'll also hold special configs and the like much like the packages.bunsenlabs.org repo until they are stable then hopefully @johnraff can pick them up. Much easier than trying to merge in wayland stuff with bunsen configs etc.

I was thinking a bit the last couple of days about how Wayland stuff would eventually be merged into the existing BL framework (post below), and this repo will certainly come in super useful.

micko01 · 2024-06-22 06:15:37

johnraff wrote:

(The only bit that had me puzzled was the changelog's "Closes: #1003272". That points to a Lintian bug, but in the Debian world it should be an Intent To Package bug on labwc-menu-generator. In BL I've never added such entries in fact.)

That fact is a little ironic! While I do intend to post a bug about "Intent To Package bug on labwc-menu-generator", I do have to convince @malm to create a release for it first. I have committed some bugfixes and enhancements recently. (The broken tests in the CI was a stumbling block but @malm has fixed that ). I was just trying to tell Lintian to STFU! And I ended up with ZERO lintian warnings . Hopefully we can get a 'release' soon and I'll contact the debian/labwc maintainer @b1rger.

EDIT: Issue openned

Last edited by micko01 (2024-06-22 06:21:58)

hhh · 2024-06-24 03:21:32

@micko01 and anyone, I have amd64 debs of hyprlock,/hyprlanf, and alternative to swaylock for you to test. They were built with debmake/debuild and seem to install and work correctly. The debuild produced all sorts of lintian warnings as I didn't alter any of the templates, but they passed the build and installed correctly...

lab@wayland:~$ apt policy hyprlang
hyprlang:
  Installed: 0.5.2-1
  Candidate: 0.5.2-1
  Version table:
 *** 0.5.2-1 100
        100 /var/lib/dpkg/status
lab@wayland:~$ apt depends hyprlang
hyprlang
  Depends: libc6 (>= 2.38)
  Depends: libgcc-s1 (>= 4.3)
  Depends: libstdc++6 (>= 13)
lab@wayland:~$

lab@wayland:~$ apt policy hyprlock
hyprlock:
  Installed: 0.3.0-1
  Candidate: 0.3.0-1
  Version table:
 *** 0.3.0-1 100
        100 /var/lib/dpkg/status
lab@wayland:~$ apt depends hyprlock
hyprlock
  Depends: hyprlang (>= 0.5.2)
  Depends: libc6 (>= 2.38)
  Depends: libcairo2 (>= 1.2.4)
  Depends: libdrm2 (>= 2.4.109)
  Depends: libegl1
  Depends: libgbm1 (>= 21.3.0~rc1)
  Depends: libgcc-s1 (>= 4.3)
  Depends: libglib2.0-0t64 (>= 2.12.0)
  Depends: libopengl0
  Depends: libpam0g (>= 0.99.7.1)
  Depends: libpango-1.0-0 (>= 1.14.0)
  Depends: libpangocairo-1.0-0 (>= 1.14.0)
  Depends: libstdc++6 (>= 13.1)
  Depends: libwayland-client0 (>= 1.20.0)
  Depends: libwayland-egl1 (>= 1.15.0)
  Depends: libxkbcommon0 (>= 0.5.0)
lab@wayland:~$

If anyone wants to test, I've uploaded them to my Google Drive...

hyprlang

hyprlock

If they install and work for you, let me know here and I can rebuild them with more attention to the lintian warnings and put in a PR to @micko01's git repo (including the dbg packages).

Configuration instructions for Hyprlock are here...

https://wiki.hyprland.org/hyprland-wiki … /hyprlock/

micko01 · 2024-06-24 06:34:32

@hhh

Fire in your PR when ready!

Last edited by johnraff (2024-06-24 07:04:55)

johnraff · 2024-06-24 06:41:56

micko01 wrote:

Speaking of the repo, it's up!
I enabled it on my laptop and after sudo apt update I was offerred to update labwc-menu-generator_0.1-1 to labwc-menu-generator_0.1.0-1! Works a treat .

Confirmed on my Carbon VM. Repo enabled, and I installed labwc-menu-generator, which works perfectly (including the manpage).
An X session, not Wayland though.

---
BTW @micko01 before you upload too many more packages, you might want to think a bit about version numbers.
Like, labwc-menu-generator_0.1.0-1 might cause problems if a future maintainer were ever to upload a labwc-menu-generator_0.1.0-0 (debian revision numbers start with 0). Dpkg would register his version as older than yours.
EDIT: I was wrong about debian revision numbers, they start at 1.

In fact there is no upstream release of this code yet, so no upstream version number, which makes it all a bit tricky. If there's an existing version then all you have to do is to tweak the "debian revision" part.

Non-maintainer upload debian revisions start with a dot, eg 0.1.0-0.1 Maybe consider using that, or a tilde 0.1.0-1~micko0 or both? A tilde-suffixed version always ranks lower than the same version without the tilde suffix, so a future release of that version will rank higher than yours.

And a + suffix, always ranks higher than the same number without the suffix, but lower than any increment of the preceeding number so 0.1.0-0+mick1 ranks lower than 0.1.0-0.1

The idea of all this complexity is to try to smooth out upgrading issues.

https://www.debian.org/doc/debian-polic … -f-version

Last edited by johnraff (2024-10-04 07:36:58)

johnraff · 2024-06-24 07:19:49

Small usability suggestion: paste in the full download url of setup_apt_secure.sh.tar.gz in the setup instructions?
https://01micko.github.io/apt_add_repo.txt
So it's easy to read and type in for people who haven't yet set up a graphics desktop.

Usually I'm a bit wary of downloading a script off the internet, and running it as root to be honest. Maybe also post up the file contents for people to check it's legit? Or just to copy/paste?

About the DEB822 sources format: we thought about using that here too
https://forums.bunsenlabs.org/viewtopic … 06#p119806
or rather adding "signed-by" info, but dropped it then because the line entry eventually added very little and DEB822 wasn't very widely supported by the family of apt tools. (Apt itself has supported DEB822 for a long time.)
https://bugs.debian.org/cgi-bin/bugrepo … bug=980743
In fact even 'man sources.list' still says

It is intended to make this format gradually the default
format, deprecating the previously described one-line-style format, as
it is easier to create, extend and modify for humans and machines alike
especially if a lot of sources and/or options are involved. Developers
who are working with and/or parsing apt sources are highly encouraged
to add support for this format and to contact the APT team to
coordinate and share this work. Users can freely adopt this format
already, but may encounter problems with software not supporting the
format yet.

I think we might hold off until live-build and the Debian-Installer itself start using it.

micko01 · 2024-06-24 10:30:36

johnraff wrote:

Like, labwc-menu-generator_0.1.0-1 might cause problems if a future maintainer were ever to upload a labwc-menu-generator_0.1.0-0 (debian revision numbers start with 0). Dpkg would register his version as older than yours.

debian-policy/ch-controlfields.html#s-f-version wrote:

It is conventional to restart the debian_revision at 1 each time the upstream_version is increased.

Ok, so while you are correct, the maintainer's convention is to start at "1" . So I think, to keep it simple I'll start at "0.1" for the debian revision. I only have 2 packages up there and they can stay as-is and as soon as there is a "-1" release of the same version I'll delete mine, and if I'm wrong and the very first debian revision iteration of a package starts at "0" then I'll delete mine asap.

Thanks for the lesson

johnraff - next post wrote:

Usually I'm a bit wary of downloading a script off the internet, and running it as root to be honest. Maybe also post up the file contents for people to check it's legit? Or just to copy/paste?

For sure. I thought about that and now have a link to the source code - updating soon.

johnraff wrote:

About the DEB822 sources format: we thought about using that here too

Well, it is the recommended way in the docs, and I do need to come up with a better way than just dropping a script!

As this is a 'temporary repo' (at least for carbon/trixie) I'll leave it as is for now. I'll think about a package before I have a netinstall script ready for testing. I suppose my script would work fine as a "postinst"? It's not bash, just 'sh'.

hhh · 2024-06-24 14:14:46

I deleted the "now copied" thread. It's done at the subforum level (Development & Suggestions), not at the thread level.

hhh · 2024-06-24 17:17:17

I've rebuilt my hyrplock packages with the -0.1 suffix as per @johnraff's suggestion, forked @micko01's repo and submitted a pull request. I'm hoping I've done all that correctly because GitHub's documentation, in my opinion, is terrible.

If anyone has installed the Google Drive debs, I would remove them and install the current build instead, again as per John...

johnraff wrote:

Non-maintainer upload debian revisions start with a dot, eg 0.1.0-0.1 Maybe consider using that, or a tilde 0.1.0-1~micko0 or both? A tilde-suffixed version always ranks lower than the same version without the tilde suffix, so a future release of that version will rank higher than yours.

The forked repo is here...

https://github.com/hhhorb/01micko_hhhorb

... and the debs for hyprlock are in the new folder "hyprlock" (click a file, then click "View raw" to download the deb file)...

The *.deb packages are in /debian/pool/main/h/ (click a file, then click "View raw" to download the deb file. You need to install hyprlang first).

I didn't use a tilde suffix, oops! I think this should be fine for now, though.

micko01 wrote:

Leave them unsigned as they need to be signed by my key for apt to work correctly.

I didn't add any private signing key, I hope that's what you mean by this.

hhh · 2024-06-24 20:45:51

Crud, I didn't include the orig.tar.gz, debian.tar.xz and dsc files. I'll push them shortly...

-edit- Done.

-edit2- JPG doesn't currently work as a background in hyprlock, although the Wiki says otherwise. Convert to PNG in GIMP (for example).

Last edited by hhh (2024-06-24 22:51:19)

johnraff · 2024-06-25 03:14:08

micko01 wrote:

johnraff wrote:
Like, labwc-menu-generator_0.1.0-1 might cause problems if a future maintainer were ever to upload a labwc-menu-generator_0.1.0-0 (debian revision numbers start with 0). Dpkg would register his version as older than yours.
debian-policy/ch-controlfields.html#s-f-version wrote:
It is conventional to restart the debian_revision at 1 each time the upstream_version is increased.

Yes, I was plain wrong there! First Debian revision is always 1. And I knew that, I think...

So I think, to keep it simple I'll start at "0.1" for the debian revision. I only have 2 packages up there and they can stay as-is and as soon as there is a "-1" release of the same version I'll delete mine, and if I'm wrong and the very first debian revision iteration of a package starts at "0" then I'll delete mine asap.

No I don't think you're wrong, and my guess FWIW is that a deb rev of 0.1 (possibly later incrementing to 0.2...) for your packages ought to work OK. No Debian maintainer is likely to use -0 for the first releaase of a package IMHO.

Thanks for the lesson

"lesson"?? Well I'm certainly no authority. But I've made some mistakes in the past with versioning that were a lot of trouble to disentangle afterwards, especially if people had already installed the packages.

Of course Debian standards (which we at BL try to follow too) are intended for people who are planning to put something in a Debian repository. Derivatives like BL (there are many others) are in a slightly different position. I'm guessing that you'll want to smooth the path for packages in your testing repo to eventually make their way into Debian, either maintained by you or by some other Debian developer/maintainer, and/or into the BL repositories (an easier path).

Different cases:

1) Package is already in Debian Sid or Experimental but you want to backport it to Trixie. Upstream package version 1.1 Debian version 1.1-1 so for a backport usually a tilde string is added, eg 1.1-1~micko-0
Safest to end the tilde string with a digit that can later be incremented if necessary. Alphabetic sorting is very confusing.

2) Software has been released upstream with a tag/version number 1.1 but nobody has packaged it yet. Maybe this is a case for an NMU-style debian revision, even though it's not about to be uploaded to Debian: 1.1-0.1 ?
On Boron you can check dillo:

john@boron:~$ apt policy dillo
dillo:
  Installed: 3.1.0-0.1~bl1+git20211214
  Candidate: 3.1.0-0.1~bl1+git20211214
  Version table:
 *** 3.1.0-0.1~bl1+git20211214 500
        500 https://pkg.bunsenlabs.org/debian boron/main amd64 Packages
        100 /var/lib/dpkg/status
     3.0.5-7+b1 500
        500 https://deb.debian.org/debian bookworm/main amd64 Packages

Dillo already has a Debian maintainer who has packaged 3.0.5-7+b1 (the -b1 means the same source code was rebuilt on bookworm as on bullseye where it was 3.0.5-7) and when I built 3.1.0 from a github repo I pretended to be doing an NMU but added a tilde string too for good measure to get 3.1.0-0.1~bl1+git20211214

3) Software hasn't yet been released, even upstream. This is the case with labwc-menu-generator. Here it's hard to recommend anything. Try to invent a version number which isn't going to cause trouble down the line. Your choice of 0.1.0-0.1 sounds fair enough. I guess @malm isn't likely to give the first release a version lower than 0.1.0??

You probably know already, but when disentangling version numbers this is very useful:

dpkg --compare-versions ${newversion} gt ${oldversion} && echo "Yes, ${newversion} is greater than ${oldversion}"

---

johnraff wrote:
About the DEB822 sources format: we thought about using that here too
Well, it is the recommended way in the docs, and I do need to come up with a better way than just dropping a script!

DEB822 is certainly better, and Debian devs seem to be looking forward to its implementation. But 'man sources.list' does warn about software that doesn't yet support it:

man sources.list wrote:

Users can freely adopt this format already, but may encounter problems with software not supporting the format yet.

And in bug #980743:

Julian Andres Klode wrote:

My goal would be to migrate to deb822 sources files with keys embedded in them eventually, that would solve all issues; but it's blocked by python-apt's aptsources package and all its consumers which all need to be changed to be able to understand deb822.

That was in Jan 2021 so python-apt might have moved on by now.

But I think it's perfectly fine for you to recommend users to use DEB822 when setting up your repo. It is a better format. My comments were more meant to explain why we hadn't yet switched in our iso and netinstall script. I'm waiting for live-build and debian-installer to go first.

I'll think about a package before I have a netinstall script ready for testing. I suppose my script would work fine as a "postinst"? It's not bash, just 'sh'.

A package to set up the test repo? Sounds good as long as there's a way for users to install it without enabling the repo first - Catch 22. We could perhaps drop it in BL backports as long as other devs were OK with that.

And I think a postinst ought to work. Even bash, perl etc scripts are acceptable as long as the shebang is correct. Dev docs are very insistent on 'set -e' but an alternative is to test every command in the script for failure or success and do the appropriate thing. Anyway, yours is very short so should work fine. Maybe consider a prerem script too, so people can disable the repo by uninstalling the package? And don't forget to make sure scripts are idempotent.

Last edited by johnraff (2024-10-04 07:42:16)

johnraff · 2024-06-25 06:48:04

micko01 wrote:

01micko@github wrote:
If you have packages to add...
Leave them unsigned as they need to be signed by my key for apt to work correctly.

Actually, I think it's OK for incoming packages to be signed. You will sign the whole repository (I think maybe both the inRelease and Release files), not the individual packages. The repo manager (you) can check the signatures of signed packages as they come in if they want to. There's a reprepro file conf/uploaders where you can set the gpg keys of allowed uploaders, eg mine:

allow * by key 93071671

That refers to my personal GPG signing key. Then after some packages are added, the repo is signed with the key set in conf/distributions:

SignWith: AED6420C

which refers to the BL release signing key.

The setup as I have it is kindof meaningless since the signer of all the BL packages is me anyway, but in theory other people might be providing packages too and then it won't hurt to have them signed so reprepro can check before adding them to the repo.

But without any restrictions in conf/uploaders, and you trust the people who send packages, I don't think it matters whether they sign them or not.

Last edited by johnraff (2024-06-26 03:10:44)

micko01 · 2024-06-25 09:01:15

hhh wrote:

Crud, I didn't include the orig.tar.gz, debian.tar.xz and dsc files. I'll push them shortly...
-edit- Done.
-edit2- JPG doesn't currently work as a background in hyprlock, although the Wiki says otherwise. Convert to PNG in GIMP (for example).

2 more files needed, my bad for not being clear enough! Sorry! I'm a novice repo hoster - but I'm learning

Just the hyprlock*.changes and hyprlang*.changes

Also added a few commands to the README to make the process easier.

micko01 · 2024-06-25 09:03:00

hhh wrote:

I deleted the "now copied" thread. It's done at the subforum level (Development & Suggestions), not at the thread level.

Thank you

micko01 · 2024-06-25 09:07:14

johnraff wrote:

The setup as I have it is kindof meaningless since the signer of all the BL packages is me anyway, but in theory other people might be providing packages too and then it won't hurt to have them signed so reprepro can check before adding them to the repo.
But without any restrictions in conf/uploaders, and you trust the people who send packages, I don't think it matters whether they sign them or not.

Thanks for the info. I'll adjust the notes and go from there. Something like "no need to be signed but it doesn't hurt if they are".

hhh · 2024-06-25 13:40:18

micko01 wrote:

I'm a novice repo hoster - but I'm learning
Just the hyprlock*.changes and hyprlang*.changes
Also added a few commands to the README to make the process easier.

And I'm a novice GitHub user and ultra-novice packager, no worries.

johnraff · 2024-06-26 03:12:14

We're all learning...

#1 2024-06-21 07:51:05

BunsenLabs-wayland repository - in development

Current state of the repository

#2 2024-06-21 18:04:41

Re: BunsenLabs-wayland repository - in development

#3 2024-06-21 22:06:49

Re: BunsenLabs-wayland repository - in development

#4 2024-06-22 05:44:34

Re: BunsenLabs-wayland repository - in development

#5 2024-06-22 06:15:37

Re: BunsenLabs-wayland repository - in development

#6 2024-06-24 03:21:32

Re: BunsenLabs-wayland repository - in development

#7 2024-06-24 06:34:32

Re: BunsenLabs-wayland repository - in development

#8 2024-06-24 06:41:56

Re: BunsenLabs-wayland repository - in development

#9 2024-06-24 07:19:49

Re: BunsenLabs-wayland repository - in development

#10 2024-06-24 10:30:36

Re: BunsenLabs-wayland repository - in development

#11 2024-06-24 14:14:46

Re: BunsenLabs-wayland repository - in development

#12 2024-06-24 17:17:17

Re: BunsenLabs-wayland repository - in development

#13 2024-06-24 20:45:51

Re: BunsenLabs-wayland repository - in development

#14 2024-06-25 03:14:08

Re: BunsenLabs-wayland repository - in development

#15 2024-06-25 06:48:04

Re: BunsenLabs-wayland repository - in development

#16 2024-06-25 09:01:15

Re: BunsenLabs-wayland repository - in development

#17 2024-06-25 09:03:00

Re: BunsenLabs-wayland repository - in development

#18 2024-06-25 09:07:14

Re: BunsenLabs-wayland repository - in development

#19 2024-06-25 13:40:18

Re: BunsenLabs-wayland repository - in development

#20 2024-06-26 03:12:14

Re: BunsenLabs-wayland repository - in development

Board footer