You are not logged in.
I had a read through some example debbuild files from you and find them a big step forward compared to the native deb packaging files. So from that point of view easydeb looks like a great improvement to me, thanks for making this tool available.
But I still have the following question:
It takes recipes and builds deb packages.
Does easydeb build the packages in a clean chroot environment (like 'mock' does for RPM based distros) or simply with the environment of the user launching it?
Last edited by tux_99 (2025-11-15 19:56:59)
Offline
When installing the deb package from your git repo I get the following error:
Unpacking easydeb-git (0.5.1.r0.g053bbf3) ...
Setting up libarchive-tools (3.7.4-4) ...
Setting up gawk (1:5.2.1-2+b1) ...
Setting up easydeb-git (0.5.1.r0.g053bbf3) ...
Compiling '/usr/share/easydeb/dependencies/missing_apt_dependencies.py'...
ln: failed to create symbolic link '/etc/firejail/easydeb.profile': No such file or directory
dpkg: error processing package easydeb-git (--configure):
installed easydeb-git package post-installation script subprocess returned error exit status 1
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12) ...
Errors were encountered while processing:
easydeb-git
Notice: Download is performed unsandboxed as root as file '/home/user/Downloads/easydeb-git_0.5.1.r0.g053bbf3_all.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
What "Download" does the Notice in the end refer to?
I had downloaded the package manually and then run apt install /home/user/Downloads/easydeb-git_0.5.1.r0.g053bbf3_all.deb as root (su - ) to install it.
Last edited by tux_99 (2025-11-15 21:04:12)
Offline
This addition is a bit off-topic but possibly historically relevant/interesting, especially to the younger generation who might be unaware of its existence over 25 years ago. I have used this method several times over the years and it never failed me:
HowTo Build a Package from Source the Smart Way (from Soul Singin')
https://forums.debian.net/viewtopic.php?f=16&t=38976
My package building days are long over but I am wondering if reinventing the wheel is just a face-lift or something completely different.
Offline
@golinux thanks for that link, it's a well written guide and there is certainly some interesting info but all those methods described are geared towards someone who just wants to install some not already packaged software on his on PC, not to produce redistributable packages.
If easydeb does a clean chroot build as I hope it does then for me that's far more useful than the methods described in your link.
Last edited by tux_99 (2025-11-15 21:20:38)
Offline
Many thanks for the clarification tux_99. ![]()
Offline
Hi there!
I am regularily building audio packages for Devuan/Debian.
At least when using the "cmake" routine this command works fine in creating deb-packages for Devuan/Debian:
sudo checkinstall -D cmake --build '/home/user/path/build' --target installGreetings, Michael
Ad aspera ad astra
Offline
@tux_99
No automatic chroot. You'll need to launch that your self, it should work just fine. The design strategy is unix/kiss (specialized and simple). For personal use it's fine like that. Even debian building tools don't automatically use a chroot. You can use it for sloppy personal packages and for high quality packages. You could also use distrobox or anything else of the sort.
ln: failed to create symbolic link '/etc/firejail/easydeb.profile': No such file or directory
buuuug, you don't have firejail installed. Speak of the devil, yes, i'm not using a chroot. tmp fix, install firejail (it's a sandboxing tool). The error, is that it's trying to symlink the firejail profile in the firejail folder that doesn't exist, so that you can use it if you want. You don't have to use firejail, this is why it's not in the dependencies, it's totally optional. I flagged it as prerelease for a reason.
the other is apt specific. I'm guessing because you used full path, it thinks it's doing a download as root. With sudo/doas and ./package i never get this.
@golinux @Babarosa
The strategy of the project is a AUR for debs. It's not "just" a new packaging format for dummies. There's all the arcane stuff you need to do to package stuff. Where you download from, dependencies, commands, patches..... Some stuff are especially badly behaved and you need to straiten them up. Now, every user must redo everything from scratch and hunt down the solution like a windows user. With a deb AUR this stuff can be greatly reduced. You are supposed to share your DEBBUILDs.
Offline
fixed the bug, new release: https://gitea.com/easydeb/easydeb/relea … 4d_all.deb
Offline
fixed the bug, new release:
Thanks, I can confirm the error is gone.
BTW, do I understand this right that I could simply take a pkgbuild file from Arch AUR, rename it to debbuild and adapt the dependencies if necessary and then build it on devuan?
In other words, is the file format specification of the debbuild files 100% compatible with the pkgbuild file format?
Offline
I took the decision to debianise the names so that there's direct correspondence between what the package is saying about it self and the debbuild, normally (unless bugs) i also left backwards compatibility but try avoiding relying on that to avoid confusion. These changes are trivial and straight forward. Beyond that, it should be almost the same.
debian/ubuntu/whatever are not arch, the libs are of different versions and are split differently and they are no -dev packages, the needed commands might need changes for various reasons, rolling vs ltr etc... From this perspective changing names was justified, since you can't just use them.
They will need manual adaptation. The differences are chaotic and can't be automatically converted. It's still better then starting from scratch though.
man pages:
man debbuild
man easydeb
And .... on gitea give me your debbuilds, i'll make you a collaborator for them. (free gitea is making it awkward to create new repos to insentivise you to pay them, you can create 5 repos max under your user name and organizations, can't git push a new repo, but you can move them any way you like and can make infinite orgs. So you would need to create them under your username, then transfer ownership to DUR.)
Offline
🎉 pkgbuild2debbuild-helper 🎉
https://gitea.com/easydeb/pkgbuild2debbuild-helper
I quickly gobbled it up with AI, expect dragons. It's rough, you need to edit it for the maintainer line, you give it a PKGBUILD and outputs in standard out a proposed DEBBUILD that you need to manually edit. Of course it's i bash.
You can edit the constants for more conversion rules. And apply_substitutions_heuristic for dependency heuristics and apply_command_heuristics for heuristics in substituting commands in functions.
yea, no help...
Offline
@exponentialmatrix
After some experimenting with easydeb I have the following questions:
how do I set the "Section" (like in the debian control file) a package belongs to in the DEBBUILD file?
how do I add a long description of the package in the DEBBUILD file?
I did read the man pages but couldn't find the above info, maybe I missed it.
Also there seems to be a small bug in the generated .dsc file, the lines with the shasums and files aren't indented. When I feed the generated .dsc file into 'sbuild' it throws and error because of this. After manually indenting the lines with one space the error disappears.
sbuild or rather dpkg-source called by sbuild also complains about the format name (easydeb):
dpkg-source: error: source package format '3.0 (easydeb)' is not supported: Can't locate Dpkg/Source/Package/V3/Easydeb.pm in @INC (you may need to install the Dpkg::Source::Package::V3::Easydeb module) (@INC entr
ies checked: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/x86_64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/p
erl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at (eval 16) line 2.If I change that to 'quilt' I get the following error instead:
dpkg-source: error: cannot write /build/reproducible-path/rssguard-4.8.6/debian/source/format: No such file or directory
E: FAILED [dpkg-source died]Maybe easydeb needs to also generate the debian/source/format file?
Last edited by tux_99 (2025-11-28 07:38:55)
Offline
for control fields use this. It will just end up above the description. Debian has too many esoteric control fields that i don't know what they are for, so easydeb doesn't support directly. You want to ask adding section as directly supported or this bellow is enough.
control_fields+=('XB-My-Custom-Field: Custom Value')There's just one description, add it there. Empty lines are not allowed, use a "." for those.
the source thing is experimental, it warns you. You use easydeb to build the final packages directly. It will not work with sbuild. It's meant to be a custom source format, so that you could in theory download it with apt, the custom format name did it's job to stop you. The whole folder with DEBBUILD is the "new source pkg" format. I never tested if apt will accept it, i never used the server side stuff. The source flags build a hopefully legal dsc and debian archive (the whole build folder, .git and all, except the sources) that apt accepts, the other sources are part of it, and you need to make sure these are in the formats that the system accepts and remove the download links if needed (i think you use the local protocol in order for easydeb to find them inside the build folder). There's also the light sources, it's just the build folder, it is supposed to download from upstream as normal. Once you downloaded it from apt, you are meant to unconpress the debian archive, move the other sources inside as is, then run easydeb as normal. The relevant code is in
/usr/share/easydeb/other/source_package.sh . I'll fix the ident, package the git repo (https://gitea.com/easydeb/easydeb-git). You also give them source packages or you are just experimenting?
Offline
Thanks for the clarifications. I managed to add the "Section" field using the method you described. The control fields are described here:
https://www.debian.org/doc/debian-polic … fieldslist
"Section" is quite useful and could be worth adding to the DEBBUILD as a directly supported parameter.
I also managed to add a multiline description as you described.
With regards to only creating a source package I thought this would have been viable as you said in an earlier post:
No automatic chroot. You'll need to launch that your self, it should work just fine.
But now I realise that easydeb is not quite there yet to create a full source package that the standard debian tools would accept to build the binary package(s) in a chroot. IMHO this would be a very useful addition since building the binary package(s) in a chroot is very much preferable.
That said I tried building the binary packages directly with easydeb (so without chroot) and that worked fine.
You also give them source packages or you are just experimenting?
I was experimenting with a DEBBUILD that I converted from a PKGBUILD from Arch. The package I was working on is RSSguard which is very old in Debian/Devuan, it hasn't been updated in over 5 years (apparently the maintainer left Debian and nobody has taken over the package).
This is the Arch PKGBUILD that was my starting point: https://gitlab.archlinux.org/archlinux/ … type=heads
Here is the current Debian package which is way behind: https://packages.debian.org/source/stable/rssguard
And here is my DEBBUILD that I created, it builds and works fine:
# Maintainer: LinuxTECH.NET <deb-packager{at}linuxtech.net>
pkgbase=rssguard
pkgname=(rssguard{,-lite})
pkgver=4.8.6
pkgrel=1
pkgdesc='simple, light and easy-to-use RSS/ATOM feed aggregator
RSS Guard is simple, light and easy-to-use RSS/ATOM feed aggregator
developed using Qt framework which supports online feed synchronization
with these services:
- [Tiny Tiny RSS](https://tt-rss.org)
- [Inoreader](https://www.inoreader.com)
- [Nextcloud News](https://apps.nextcloud.com/apps/news)
- [Gmail API](https://developers.google.com/gmail/api)
.'
arch=(amd64)
control_fields+=('Section: contrib/web')
url='https://github.com/martinrotter/rssguard'
license=(GPL-3.0-only)
depends=(libqt6widgets6
libqt6gui6
libqt6core6t64
libqt6sql6
libqt6xml6
libqt6concurrent6
libqt6core5compat6
libqt6multimedia6
libqt6multimediawidgets6
libqt6qml6
libqt6network6
libqt6dbus6
libstdc++6
libgcc-s1
libc6
libsqlite3-0)
builddepends=(qt6-5compat-dev
qt6-declarative-dev
qt6-multimedia-dev
qt6-tools-dev
qt6-base-dev
linguist-qt6
qt6-webengine-dev
libsqlite3-dev
'cmake>=3.14.0')
#suggests=('clang: Support for beautification of message filter scripts'
# 'mariadb-libs: Support for MariaDB-based data storage')
source=(${pkgbase}_${pkgver}.orig.tar.gz::https://github.com/martinrotter/rssguard/archive/refs/tags/${pkgver}.tar.gz)
sha256sums=('c29bdda08ece8de113dbdb87e8e23491221ba9ddbacd26141d6a00e04888972e')
prepare(){
cd "${srcdir}"
mv ${pkgbase}-${pkgver} rssguard
}
build() {
cmake -B build -S $pkgname \
-DCMAKE_INSTALL_PREFIX=/usr \
-DREVISION_FROM_GIT=OFF \
-DNO_UPDATE_CHECK=ON \
-DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
-DENABLE_MEDIAPLAYER_LIBMPV=OFF
cmake --build build
cmake -B build-lite -S $pkgname \
-DCMAKE_INSTALL_PREFIX=/usr \
-DREVISION_FROM_GIT=OFF \
-DNO_UPDATE_CHECK=ON \
-DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
-DENABLE_MEDIAPLAYER_LIBMPV=OFF \
-DNO_LITE=OFF
cmake --build build-lite
}
package_rssguard() {
depends+=(libqt6webenginecore6
libqt6webenginewidgets6)
DESTDIR="$pkgdir" cmake --install build
}
package_rssguard-lite() {
pkgdesc+=' without WebEngine support'
conflicts=(rssguard)
provides=(rssguard=$pkgver)
replaces=(rssguard-nowebengine)
DESTDIR="$pkgdir" cmake --install build-lite
}Last edited by tux_99 (Yesterday 09:15:01)
Offline
I'll add Section sometime later. For now survive with control_fields . Look how many they are, i plan on adding directly what people truly use, for the rest you'll be using control_fields.
the build folder with the DEBBUILD is a custom source package, the custom version in dsc was there to stop you from running the usual debian tools. You use easydeb inside the chroot/container to build the package. Why is that a problem? Trying to convert it seams difficult and error prone, and will probably be ugly... It's a bad idea. The generated debian archive is just the build folder minus the sources. It was never supposed to be processed by debian tools.
You do know what's a chroot right? It's a light container (less secure), it pretends to be a different linux install. You use it for packaging so that you are sure you use the correct build dependencies and environment, then you also install it and run it in a chroot, to test you have all the dependencies. You can just use easydeb inside. The debian tools aren't doing anything magical with a chroot.
Offline
@exponentialmatrix
Built easydeb deb package for /opt and installed it.
Used /opt/easydeb to build dsnote-git, it was a bit of a pig (dependencies) but got there in the end.
Identified only one hiccup with easydeb:
optdepends_x86_64=(
'amdvlk: Vulkan support for AMD GPU (AMDVLK Open)'the second open brace causes easydeb to barf despite being inside single quotes.
Thank you for a very useful tool.
Offline
well this thread if anything vindicates my refusal to create packages for anything i develop, less alone packaging for debian as it is an unnecesarely complicated crapshow or at least everything i've read so far has painted the creation of a new deb package from an upstream source that has not been previously packaged, admitedly i have not read the guide in the link shared by golinux but by this point i don't got high hopes.
Offline
I'll add Section sometime later. For now survive with control_fields . Look how many they are, i plan on adding directly what people truly use, for the rest you'll be using control_fields.
Thanks, I think adding both "Section" and also "Priority" would be quite useful as these two are used and displayed by the Synaptic Package Manager for each package ("Section" to categorize the package and "Priority" is displayed in the Common tab of each package).
But yes, in the meantime the control_fields are good enough.
You use easydeb inside the chroot/container to build the package. Why is that a problem?
How in practice do you do that with easydeb in an easy semi-automated way?
To explain what I mean by "easy semi-automated way":
When you have a standard debian source package it's very easy to do a semi-automated build in a chroot.
It's basically just two commands, one for updating the chroot tarball of the base system (if it hasn't been updated recently already) and then launch 'sbuild' which will take care of creating the initial chroot, downloading the dependencies, building the binary packages and then cleaning up everything again.
To set up such a semi-automated chroot build environment I followed this guide which only needed a couple minor adaptations to work with Devuan:
https://stephan.lachnit.xyz/posts/2023- … cacher-ng/
As far as I see it there are two types of people to whom easydeb is aimed at:
- the simple user who just downloads a DEBBUILD file and then uses easydeb to build the package on his local machine with the aim to install and use it. This person has no need for a chroot build environment.
- the developer who want to create a DEBBUILD file that he wants to share with other users (for example via your git repo or the future DUR). When creating a DEBBUILD file meant to be shared with others the main issue (like with every package creation for any distro) is to ensure that the list of dependencies is correct and complete.
To make sure that the list of build dependencies is correct and complete AFAIK there really only is one way: by building the binary packages in a clean chroot freshly set up for each build with a minimal base system.
So IMHO it would be very useful for easydeb to create a standard deb source package in order to be able to take advantage of the mostly automated chroot build process that already exists for deb packaging.
Of course if there is an alternative similarly automated way to do such a chroot build directly with DEBBUILD files then there would be no need for easydeb to be able to create a standard deb source package, but if this doesn't exist yet then IMHO it would be easier to use the already existing sbuild chroot process rather than reinventing the wheel for easydeb.
Last edited by tux_99 (Today 04:37:13)
Offline