PKGBUILD for debian and ubuntu in MPR is make sufficient or cmake and various arguments are needed as well like the aur package

[justvipul]

i have tried packaging pkgbuild for MPR which is an AUR like repo for debian and ubuntu. i tried using cmake which fails but make works fine. so is the current pkgbuild good enough for debian? NOTE: its for MPR which is unofficial so AUR guidelines apply rather than debian ones. however i have tried to install in the /usr/bin instead of /usr/local nonetheles and the current pkgbuild using make works fine creates a working binary i.e. a .deb file

[Aire-One]

I'm not sure to understand the question...

I think the main difference between debian and arch in the scope of writing a pkgbuild file would be the dependencies and maybe some path (?)

Regarding dependencies, you can have a look at our GitHub Actions pipeline. It uses an Ubuntu based image, so I guess deps are more or less the same for you. (https://github.com/awesomeWM/awesome/blob/master/.github/workflows/main.yml#L92-L130)

Our makefile is basically shortcuts for cmake. So, I'm not sure to understand why you can't use cmake but make works. You also want to define the cmake LUA_INCLUDE_DIR, LUA_LIBRARY and LUA_EXECUTABLE variables to build awesome against the correct Lua version. And I don't think it's a good practice to use the make's -j flag in scripts where you don't control the running hardware.

You can also have a look at our "Building and Testing" page from our doc : https://awesomewm.org/apidoc/documentation/10-building-and-testing.md.html. I think we have a make rule to build debian package that can maybe be a cleaner way to install the git version (?)

Other than that, I think you shouldn't have any difficulties writing pkgbuild for awesome.

[justvipul]

Our makefile is basically shortcuts for cmake. So, I'm not sure to understand why you can't use cmake but make works. You also want to define the cmake LUA_INCLUDE_DIR, LUA_LIBRARY and LUA_EXECUTABLE variables to build awesome against the correct Lua version. And I don't think it's a good practice to use the make's -j flag in scripts where you don't control the running hardware.

oh i forgot to mention the error i get if i use the cmake way of building and definging these variables as well. heres the build error log and the corresponding PKGBUILD. this is the reason for my statement about cmake and make having differnt results.

1. what make rule should i follow? thats what i am confised any help is appreciated.
2. removed the -j flag. however it would cause the building to go for quite a long time for some users.
3. yeah the difficulty i faced was with the fact that i am unfamiliar with the cmake flags possible. and the github link to the build instruction is not working so i was stuck at that point. and rather than hunting for half baked solutions it was better to ask in here.
4. added the missing dependencies

[Aire-One]

Reading your build log, I found :

make[2]: *** No rule to make target '/usr/lib/liblua.so.5.3', needed by 'test-gravity'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:683: CMakeFiles/test-gravity.dir/all] Error 2
make: *** [Makefile:171: all] Error 2

This is the same error we had this issue #3425, and we couldn't solve it... (CC @psychon and @actionless : we have another instance of this build issue from a debian user this time.)

what make rule should i follow? thats what i am confised any help is appreciated.

The pkgbuild itself looks good to me, I think.

removed the -j flag. however it would cause the building to go for quite a long time for some users.

That's why there is a MAKEFLAGS config variable inpkgbuild.conf. https://wiki.archlinux.org/title/makepkg#Improving_compile_times

he github link to the build instruction is not working

Oh! Yeap this is an issue we should fix. Thanks for pointing this out!

and rather than hunting for half baked solutions it was better to ask in here.

Yes, no issue with that. You're welcome here :)

[ezz666]

You obviously got the LUA_LIBRARY path wrong on your system. If we are talking about Debian it should be /usr/lib/x86_64-linux-gnu/liblua5.3.so.0. Thus cmake is complaining about not finding /usr/lib/liblua.so.5.3 (and it's not being build with awesome). Look for the package liblua5.3-0 contents to be sure.

[justvipul]

You obviously got the LUA_LIBRARY path wrong on your system. If we are talking about Debian it should be /usr/lib/x86_64-linux-gnu/liblua5.3.so.0. Thus cmake is complaining about not finding /usr/lib/liblua.so.5.3 (and it's not being build with awesome). Look for the package liblua5.3-0 contents to be sure.

ok this was the main issue. i tried searching for liblua.so.o.5.3 and hence couldnt find the so library. but you solved the error. now its working. heres the build log and heres the PKGBUILD you can give a nod if everything is fine so i can close this thread. the other issue might also be solved by this in a better way i suppose. that user now can just install awesome-git using an MPR helper just like yay or paru ,etc in their debian system. :)

[justvipul]

btw if i run makedeb -si in the PKGBUILD directory then it creates a .deb file that will populate the user system in the following package tree structure.

[ezz666]

I wonder why I don't see lua-lgi in the dependencies list. There is lua-lgi-dev in makedeps list, but awesome won't work without lgi.

Edit: to be precise lua-lgi-dev is not even needed to build awesome.

So it may be good idea to look through vanilla awesome package dependencies. May be you missed something else. Here they are

Depends: default-dbus-session-bus | dbus-session-bus, gir1.2-freedesktop, gir1.2-gdkpixbuf-2.0, gir1.2-glib-2.0, gir1.2-pango-1.0, libcairo-gobject2, lua-lgi (>= 0.9.2), menu, libc6 (>= 2.14), libcairo2 (>= 1.12.0), libdbus-1-3 (>= 1.9.14), libgdk-pixbuf-2.0-0 (>= 2.22.0) | libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.30.0), liblua5.3-0, libstartup-notification0 (>= 0.10), libx11-6, libxcb-cursor0 (>= 0.0.99), libxcb-icccm4 (>= 0.4.1), libxcb-keysyms1 (>= 0.4.0), libxcb-randr0 (>= 1.12), libxcb-shape0, libxcb-util1 (>= 0.4.0), libxcb-xinerama0, libxcb-xkb1, libxcb-xrm0 (>= 0.0.0), libxcb-xtest0, libxcb1 (>= 1.6), libxdg-basedir1, libxkbcommon-x11-0 (>= 0.5.0), libxkbcommon0 (>= 0.5.0) Recommends: feh, rlwrap, x11-xserver-utils, awesome-extra, gir1.2-gtk-3.0

And to make the complete list I'll also paste here build-dependencies for the source package:

Build-Depends: asciidoctor, cmake, debhelper-compat (= 13), imagemagick, libcairo2-dev, libdbus-1-dev, libgdk-pixbuf2.0-dev, libglib2.0-dev, liblua5.3-dev, libpango1.0-dev, libstartup-notification0-dev, libx11-xcb-dev, libxcb-cursor-dev, libxcb-icccm4-dev, libxcb-keysyms1-dev, libxcb-randr0-dev, libxcb-shape0-dev, libxcb-util0-dev, libxcb-xinerama0-dev, libxcb-xkb-dev, libxcb-xrm-dev, libxcb-xtest0-dev, libxdg-basedir-dev, libxkbcommon-dev, libxkbcommon-x11-dev, lua-busted, lua-discount, lua-ldoc, lua-lgi (>= 0.9.2), lua5.3, x11proto-core-dev, xmlto, zsh

I'm not saying that you should copy paste the deps. On the contrary, it makes sense to reevaluate what you really need.

[justvipul]

I shall check them and update the pkgbuild accordingly will update here accordingly.

[justvipul]

1. This PKGBUILD is the result of all the talks we had earlier. i have used all the various links provided in the replies and combined them all to include the necessary dependencies.
2. i also checked the deb-src variant and added some of those dependencies as well.
3. i have another question regarding the deb-src variant using make and we here opting for cmake and various specific varables. so what is the potential difference when cmake and variables are used instead of just clone and make package
4. some dependencies might not be needed. if thats the case what should i refer? there were mulltiple sources of possible dependencies and some didnt have distinction for needs in the build process and as standard depends.
5. is xcb-errors needed? i can provide it as a seperate package in MPR which can become a dependency for building in this package.

[ezz666]

Disclamer: I'm not sure I know enough details about awesome wm build process to make a right suggestion. I'm just a part of the community here, a bystander. But I happen to know a thing or two about cmake and debian. So I hope you'll find my advise useful.

1 Looks better, however now it probably has more dependencies than it really need. I'll give you a reason a bit later.

3 make basically calls cd build && cmake $(CMAKE_ARGS) ../. Here CMAKE_ARGS is just an environment variable which is empty by default. So calling it that way you are relying on cmake to find correct lua version by itself. It may fail on some systems (it does fail on arch btw). The success and fail may depend on packages installed. By providing CMAKE_ARGS (or calling the command directly with the args) you make sure that the right lua version will be used, and you also may tune the prefix if you want to.

4 and 5 And now we come to the reason why some dependencies may be not needed.

Lets start with clearing things about the debian source package. Debian has some polices to guide the packaging process. The current policy says the build should be reproducible. For us here it requires the fixed list of options which should be enabled on every build.

Here are the couple examples:

1. To build the documentation you should have ldoc installed, but if you don't have it the build will succeed. It won't build docs but it will build the working window manager.
2. It is possible to build awesome wm without dbus support. But it has some implications in the runtime. It won't show dbus notifications anymore and awesome-client will be broken.
3. I'm not really sure but from the first glance xcb-errors simplifies debugging. I think it does not affect user experience much.

Moreover debian splits everything into quite small pieces. So some libraries that usually supplied by the same package may have separate packages there. It is great for users, since it provides quite fine control but it also make things harder for maintainer.

You probably are not aiming to make you package build reproducible. That means you can move some of the dependencies to optional ones or even drop them. It's still not easy to find which one are really needed. It's a hard problem which requires some testing. I can't help you with that. The only thing I can say that lack of anything from the lists here will fail the cmake configure process.

[justvipul]

has more dependencies than it really need.

i have now shifted some depends dependencies to optdepends. however there are few depends i am confused. i.e luarocks and lua-yaml. should they be in depends or make or opt. the makedepends might be having some depencies which can be skipped but i would prefer to keep them as they can be removed by the user later on.

You probably are not aiming to make you package build reproducible.

any reference to make sure it is indeed reproducible? thanks for clarifying in the cmake and make difference. i assume our approach would be better then. i consider the current PKGBUILD to be good enough. thanks for helping me out with the support you gave. and to conclude is it okay to close the thread now?

[ezz666]

As far as I see luarocks is completely optional. All that is done about it is making sure that awesome can find its paths. I don't think that awesome uses lua-yaml in any way. YAML files may be found only in workflows thus they have nothing to do with awesome itself. They're a part of github repo configuration.

any reference to make sure it is indeed reproducible?

There is a tool which helps you to check the difference in packages. It's called diffoscope. Checking the build in a clean chroot is a good idea. Apart from that it is relying on the community effort.

As for the automated tools, there are some for arch and debian. But I'm not sure they will help you, since they aiming for default packaging systems. Check corresponding articles on debian wiki and archwiki. They may help you. To say the truth, I don't think you should bother with that. The reproducibility is a way to check that a binary package was made from the corresponding source package. As far as I know you don't provide a binary package. So the origins of the package are obvious here.

i consider the current PKGBUILD to be good enough. thanks for helping me out with the support you gave. and to conclude is it okay to close the thread now?

It does look good enough to make some live testing. Feel free to close the thread if you don't need it anymore.

[justvipul]

As far as I know you don't provide a binary package. So the origins of the package are obvious here.

yes correct. so it can be skipped.

As far as I see luarocks is completely optional. All that is done about it is making sure that awesome can find its paths. I don't think that awesome uses lua-yaml in any way. YAML files may be found only in workflows thus they have nothing to do with awesome itself. They're a part of github repo configuration.

done.

It does look good enough to make some live testing. Feel free to close the thread if you don't need it anymore.

this journey comes to an end for now then. :)