For a proprietary piece of software I'd like to build and publish multiple versions of software for multiple distributions. E.g. 1.0, 1.1 and both versions for squeeze, wheezy and precise. The builds are run on automatically on different machines and produce distribution-specific .deb files. Distribution-specific in a way that they're linked to distribution-specific versions of libraries. E.g. OpenSSL 0.9.8 for squeeze, 1.0.1 for wheezy. However, these packages are built using the same version number and package name. This is what is probably the cause for the issue following. Currently I'm using reprepro with the includedeb command to add the binaries to the repository. This works out fine, until I add the same package version built for a second distribution. Publishing for Squeeze is fine # reprepro -b ./repo --outdir ./wwwpub/repo includedeb squeeze /path/to/sqeezepackages/packagename-1.0.deb But then publishing the same version of the software built on wheezy, publishing for wheezy fails: # reprepro -b ./repo --outdir ./wwwpub/repo includedeb wheezy /path/to/wheezypackages/packagename-1.0.deb /path/to/wheezypackages/packagename-1.0.deb: component guessed as 'main' ERROR: '/path/to/wheezypackages/packagename-1.0.deb' cannot be included as 'pool/main/p/packagename/packagename_1.0_all.deb'. Already existing files can only be included again, if they are the same, but: md5 expected: e7df7cd2ca07f4f1ab415d457a6e1c13, got: 0fa924209085a5713f79e6a30649455f sha1 expected: 947b41827bbac414baddf0648b9abecaad8de4fe, got: 1be168ff837f043bde17c0314341c84271047b31 sha256 expected: a883dafc480d466ee04e0d6da986bd78eb1fdd2178d04693723da3a8f95d42f4, got: a93dbf1e95ddc4cfa84e9cd3cfa6c9e0e14affd79812abde4bca688224430a65 size expected: 1234, got: 1235 There have been errors! I assume my build needs a unique version number for each distribution. * What's the easiest way to accomplish this? * How do I add this to the current version number? Is it advised to use something like 1.1~wheezy, 1.1+wheezy, 1.1-1 (incrementing), 1.1+deb6, etc.? As jessie is coming up and I'd like the system to recognize this during dist-upgrades, I think just using the distribution name won't work as j comes before the w and will be recognized as older by APT. * Once determined how to build up the version number; how do I add this to my tooling? I guess I need heuristics in the debian/control files to have the version number specific to the distribution it's built on. And for the changelog I'll have to invoke dch to comply with that version number as well.

Is there a way to predict when the next release will be out? I read somewhere that it has to do with number of bugs remaining in the testing branch . Could someone please explain how this works and when the next release will happen based on what variables?

I’m trying to build Asterisk packages for Ubuntu 22.04 LTS, and I’m encountering the same issue with both version 22.4.x and 22.5.0. During the build process, I get the following warnings: dpkg-shlibdeps: warning: symbol __ast_free used by debian/asterisk/usr/lib/x86_64-linux-gnu/libasteriskpj.so.2 found in none of the libraries dpkg-shlibdeps: warning: symbol ast_pjproject_max_log_level used by debian/asterisk/usr/lib/x86_64-linux-gnu/libasteriskpj.so.2 found in none of the libraries dpkg-shlibdeps: warning: symbol __ast_repl_malloc used by debian/asterisk/usr/lib/x86_64-linux-gnu/libasteriskpj.so.2 found in none of the libraries dpkg-shlibdeps: warning: symbol ast_option_pjproject_log_level used by debian/asterisk/usr/lib/x86_64-linux-gnu/libasteriskpj.so.2 found in none of the libraries The .deb package builds successfully, but I'm not sure if the library will function correctly. I did find these symbols in the Asterisk binary. For simplicity, I’m building a single “all-in-one” package, as this makes local deployment easier for me.

I'd like to build an RPM from https://src.fedoraproject.org/rpms/Thunar with some changes in the source code. Do they use a docker/podman image to build it? I couldn't find information about it. I'd like to build the RPM for RHEL 10 since it isn't supported yet.

While running pacman -Syu After "(8/8) checking package integrity" I'm facing the following issue with these packages:

error: 7-zip: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/7-zip-23.01-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: brave-bin: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/brave-bin-1:1.52.126-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: pamac-aur: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/pamac-aur-11.0.1-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: spotify: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/spotify-1:1.2.13.661-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: visual-studio-code-bin: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/visual-studio-code-bin-1.79.2-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: yay: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/yay-12.1.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: zoom: signature from "TNE " is unknown trust
:: File /var/cache/pacman/pkg/zoom-5.15.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

So far, I've tried running this (without success): - sudo pacman -S archlinux-keyring | pacman -Su - pacman -Sy archlinux-keyring | pacman-key --refresh-keys - `pacman-key --delete 91BD8815FE0040FA7FF5D68754C28F4FF5A1A949 | pacman-key --populate archlinux` - `pacman-key --delete D6C9442437365605 | pacman-key --populate archlinux` - sudo pacman -Sc - sudo pacman -Fy

I have an application that I am packaging as an RPM and installing on CentOS 7. When I install the RPM I want it to install some compiled binaries as well as some Python modules with their dependencies. My Python modules require a newer version of Python than is provided by CentOS, so I will be installing the modules in a Python altinstall under /usr/local/lib/python2.7/site-packages. This means I can't use CentOS-provided RPMs since they install under /usr/lib. I can easily install the modules under /usr/local/lib using pip. Is there a way to package my application such that: * I can install my application from an RPM. * My Python modules get installed under /usr/local/lib when the application is installed. * Any Python dependencies also get installed. * I avoid maintaining RPM packages for the Python dependencies. Is there a convention for this kind of thing? Or are there maybe some examples? I didn't see anything directly relevant in Fedora's Python Packaging documentation . The options I have considered are: 1. Bundle my application, Python modules, and all Python dependencies into one RPM. I don't like this option because I would not be able to update individual dependencies on the client system without upgrading my entire application to a new version. 2. Create individual RPMs for my application, my Python modules, and third-party dependencies. I don't like this option because I would have to maintain RPMs for every single third-party module in my dependency tree. 3. Call pip from within my RPM. I don't like this option because RPM would not be able to track the changes that pip makes, and I would not be able to determine whether I can safely remove third-party Python modules when removing the RPM.

What is the Fedora equivalent of the Debian build-essential package?

It's all very confusing. There are different examples out there, for e.g.: _:--.deb *source: debian package file names * Is section 5.6.12 Version or the Debian Policy Manual also related to the actual package filename too? Or only to the fields in the control file? In this wiki topic about repository formats it doesn't really say anything about conventions, same in the developers best practices guide . Maybe I'm just looking for the wrong thing, please help me and tell me where to find the Debian package name conventions. I'm especially curious where to put the Debian codename. I want to do something like this: _.-_.deb where ` is just squeeze or wheezy`.

I'm trying to add a systemd service file to an existing Debian package. I followed https://wiki.debian.org/Teams/pkg-systemd/Packaging , so I created debian/packagename.service. Because my debhelper is version 9.x, I also: - added dh-systemd to Build-Depends in debian/control - added --with systemd to the dh command in debian/rules. Now when I rebuild the package with debuild -i -us -uc -b, it fails with this output: Now running lintian... [...] W: packagename: init.d-script-not-marked-as-conffile etc/init.d/packagename E: packagename: init.d-script-not-included-in-package etc/init.d/packagename It seems like the build script expects an init.d script if there is a .service file. And indeed, the generated DEBIAN/postinst includes this section: # Automatically added by dh_installinit if [ -x "/etc/init.d/infinoted" ]; then update-rc.d infinoted defaults >/dev/null invoke-rc.d infinoted start || exit $? fi # End automatically added section Is this expected behavior? Should I always include SysV init scripts when I include a .service file? If not, what is the recommended way to prevent the generation of this section? My system is Debian Jessie.

I am building a Yum repository to install RPM packages. I am creating a folder mkdir -p ~/yum/el7/x86_64 and moving rpm file to it under same path given above. ### Here is my my-app.repo file info. [my-app] name=My App baseurl=https://dl.my-app.com/yum/el7/$basearch gpgkey=https://dl.my-app.com/rpm.gpg gpgcheck=1 enabled=1 repo_gpgcheck=1 ### Here is the error I get when I install the package. [root@ip-192-31-59-132 ~]# yum install my-app Loaded plugins: langpacks, priorities, update-motd Resolving Dependencies --> Running transaction check ---> Package my-app.x86_64 0:1.3.15-2.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================================================================================================================== Package Arch Version Repository Size ================================================================================================================================================================================== Installing: my-app x86_64 1.3.15-2.el7 my-app 9.5 M Transaction Summary ================================================================================================================================================================================== Install 1 Package Total download size: 9.5 M Installed size: 33 M Is this ok [y/d/N]: y Downloading packages: my-app-1.3.15-2.el7.x8 FAILED https://dl.my-app.com/yum/el7/x86_64/my-app-1.3.15-2.el7.x86_64.rpm : [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=my-app clean metadata Trying other mirror. Error downloading packages: my-app-1.3.15-2.el7.x86_64: [Errno 256] No more mirrors to try. [root@ip-192-31-59-132 ~]# I have the Gnupg configuration correct. I hope thats not the cause of this issue. What am I doing wrong here? Why is Yum throwing Package does not match intended download error?

I am automating version bumping of my project with this bash script:

#!/usr/bin/env bash

CHANGELOG="Changelog.md"
DEBIAN_CHANGELOG="debian/changelog"
UPSTREAM_VERSION=$(cat VERSION)

# Updating entries in rpm files

DEB_RELEASE_NOTES=$(awk '{print "  * " $0}'   Mon, 10 Mar 2025 20:08:00 +0200

Whereas the RELEASE_NOTES file contains:

1. Split codebase into multiple files.
2. Use a seperate version file and define built version upon compile.
4. [BUGFIX] If input file is same as output file copy input file into a temporary one.
5. Improved Documentation

Do you know why all lines are stuck as a single bullet???

I'm often in the situation where I backport some fedora-packaged software to CentOS, or forward-port something from an older version of EPEL to Fedora, or vice versa. How can I do that with the least amount of effort?

Let's say your spec file is synced to upstream v1.0.0 and that changes to v2.0.0, what should the changelog entry say that rebuilds the package from the latest upstream source? [From the docs](https://rpm-packaging-guide.github.io/) > The last section, %changelog is a list of date-stamped entries that correlate to a specific Version-Release of the package. **This is not meant to be a log of what changed in the software from release to release, but specifically to packaging changes.** For example, if software in a package needed patching or there was a change needed in the build procedure listed in the %build section that information would go here. That example is one where the change in patching or in the RPM spec, but what do you put in the specfile if you're just rebuilding from a new upstream? What if you're packaging your own software and the specfile is generated from your repository, or exists in your repo.

My goal is to publish my Debian trixie source package somewhere. I attempted to dput it to my Launchpad PPA, but I got an email saying > Unable to find distroseries: trixie Is there a way to fix it or are Launchpad PPAs for Ubuntu only?

## *CONTEXT* With a local package repository, I'm able to provide my APT instances with a set of software packages and configurations from a server which I control, allowing any client to install this software using just the normal apt install command (providing the repository is added to their /etc/apt/sources.list{,.d/}). For my attempt at creating a local package repository, I followed this tutorial on bipmedia.com, which roughly consists of: 1. Generate the .deb 2. Store the .deb on an Apache2 web server 3. Generate a Package.gz file ### My Attempt #### Generating the binary package file To generate the .deb, the software files are required, a DEBIAN folder with metadata is generated and the following command compiles the code and assembles the package: dpkg-deb --build [*source code tree with DEBIAN directory*] #### Serve repository files with Apache2 server _I'm skipping this part as it's unrelated to the problem I'm seeking to solve with this question._ #### Generating a Packages.gz file (repository metadata) With the an open shell instance whose working directory is the Apache server root folder containing the .deb file from above, I called: dpkg-scanpackages debian /dev/null | gzip -9c >debian/Packages.gz ## *PROBLEM* Calling apt update on the client machine, it complains with:

W: The repository 'http://example.com  packages/ Release' does not have a Release file.

This necessary file is missing in my local repository. It seems to be a register of package checksums, but after searching on the Internet, my very limited understanding of the topic kept me from being able to find out how to generate it. --- ***Note:*** My /etc/apt/sources.list file does have the following line: deb http://example.com packages/ ## *QUESTION* How do I generate the Release file for a local APT package repository?

I've been working on creating a Linux configuration scheme based on my own system configuration. It consists of 1. A configuration of the Interception program [Dual Function Keys](https://gitlab.com/interception/linux/plugins/dual-function-keys) . 2. A custom keyboard layout with several higher layers. 3. A configuration of [StumpWM](https://github.com/stumpwm) . 4. A configuration of Emacs. This configuration is supposed to come in two variants: - a basic one which is maybe most analogous to evil mode, a configuration scheme which remaps the commands in Emacs itself. - Another one, which assumes the existence of several plugins to both rebind keys and to add and replace commands which would thus be a bit more like Spacemacs or Doom Emacs in scope. 5. A configuration of the Firefox Plugin Tridactyl. All of these are attuned to each other. Furthermore, I made in the course of creating the Emacs configuration two parts which I think I should make into packages on their own. But apart from those I'm not sure how to best integrate the entire thing into the software it uses. I also don't assume that a user would just adopt it at once, the parts build on each other but not all of them depend on all others. For instance, it would be possible to only use the Dual Function Keys config, the keyboard layout and the Emacs configuration while not using StumpWM or Tridactyl. I'm also thinking of introducing a variant of the keyboard layout whose lower two layers are fairly normal QWERTY. So for instance I'm not sure whether I should try to get the Emacs parts into MELPA or not, and whether to put them in together or not, since the advanced version uses commands from the basic one. Should I try to get each part into the service that usually distributes its kind or should I just put them all up together for now? How should I best proceed to make the installation as easy as possible while still retaining modularity as much as possible?

I have a single upstream source package using cmake and I'd like to package it as two binary debian packages.

$ tree proj
proj/
├── app1.c
├── app2.c
└── CMakeLists.txt

Upstream's CMakeLists.txt was already written with this in mind. They use the COMPONENTS argument of [install](https://cmake.org/cmake/help/v3.7/command/install.html)

$ cat proj/CMakeLists.txt
include(GnuInstallDirs)

add_executable(app1 app1.c)
install(
  TARGETS app1 
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
  COMPONENT app1)

add_executable(app2 app2.c)
install(
  TARGETS app2
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
  COMPONENT app2)

To compile/install locally, it's pretty easy:

$ mkdir build && cd build
$ cmake ../proj -DCMAKE_INSTALL_PREFIX=/usr/local  # Configure
$ cmake --build .                                  # Build
$ cmake -DCOMPONENT=app1 -P cmake_install.cmake    # Install app1 component
$ cmake -DCOMPONENT=app2 -P cmake_install.cmake    # Install app2 component

But how would you build a debian/rules file for this?

I have found a similar question on https://askubuntu.com/questions/144547/how-to-package-a-single-text-file-into-a-deb - unfortunately there is no answer I can use. Basically, I want to manage a text file, say myapp.txt.config, in git; and then, I'd want to create a .deb package that copies it on Raspberry Pi in /usr/share/myapp/myapp.txt.config. However, most of the work I do in this repository is in MSYS2/MINGW64 on Windows 10, so I would like to avoid the round-trip to a Raspberry Pi, just to build the .deb package. Since this is just a text file, I'd like a single .deb to be valid for all distributions (stretch, bookworm for Raspbian). How would I go about implementing this? I can see that a .deb file is an [ar archive with tar archives inside](https://en.wikipedia.org/wiki/Deb_(file_format)) - and there is working ar, tar, install, bash, python3, perl, make on MSYS2/MINGW64, however there are no Debian tools in the MSYS2/MINGW64 repos, as MSYS2 uses pacman instead. I have seen in https://askubuntu.com/questions/90764/how-do-i-create-a-deb-package-for-a-single-python-script that the basic source package layout would be:

myapp-config/
    -- myapp.txt.config
    -- debian/
        -- changelog
        -- copyright
        -- compat
        -- rules
        -- control
        -- install

... but I'd have to run dch --create to "create a properly formatted debian/changelog entry", and debuild --no-tgz-check to build; though dch is a Perl script ([devscripts/scripts/debchange.pl](https://github.com/Debian/devscripts/blob/master/scripts/debchange.pl)) , and so is debuild ([devscripts/scripts/debuild.pl](https://github.com/Debian/devscripts/blob/master/scripts/debuild.pl)) ; but I cannot tell to what extent they will work on MSYS2/MINGW64. I thought also of creating a Makefile with a [single install entry](https://stackoverflow.com/questions/39892692/how-to-implement-make-install-in-a-makefile) :

install:
	install -D -m 644 myapp.txt.config /usr/share/myapp/

... and then calling [checkinstall](https://github.com/ruxkor/checkinstall/blob/master/checkinstall) on it to create a deb package; checkinstall seems to be bash, but I cannot tell if it will run on MSYS2/MINGW64, as it probably needs sudo - also that github version is from 13 years ago, and it might even be that checkinstall is [no longer being maintained](https://askubuntu.com/questions/1138384/why-is-checkinstall-no-longer-being-maintained) . So, what would be the right approach to build a .deb package in my case? If there is no way to build a .deb package on MSYS2/MINGW64, what would be the right way to organize the project, so I build this single-text-file .deb on Raspberry Pi with least amount of effort?

I downloaded a package I wanted to install, but during installation, the system returned an error: dependency is not satisfiable: libffi7. I assume this is because I have a newer version of Linux where libffi7 is no longer supported. How can I resolve this issue? What should I do to install a package that requires libffi7, or is there a way to use a newer version of libffi instead, if possible? I try to solve it like this: sudo apt-get install -f but it's does't work! when I try to enter the command sudo dpkg -i SceneBuilder-23.0.1.deb through the terminal. I got this:

Selecting previously unselected package scenebuilder.
(Reading database ... 738809 files and directories currently installed.)
Preparing to unpack SceneBuilder-23.0.1.deb ...
Unpacking scenebuilder (23.0.1) ...
dpkg: dependency problems prevent configuration of scenebuilder:
 scenebuilder depends on libffi7; however:
  Package libffi7 is not installed.
 scenebuilder depends on libgdk-pixbuf2.0-0; however:
  Package libgdk-pixbuf2.0-0 is not installed.
 scenebuilder depends on libpcre3; however:
  Package libpcre3 is not installed.

dpkg: error processing package scenebuilder (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 scenebuilder

I also try sudo apt install ./SceneBuilder-23.0.1.deb and i got:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'scenebuilder' instead of './SceneBuilder-23.0.1.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 scenebuilder : Depends: libffi7 but it is not installable
E: Unable to correct problems, you have held broken packages.

I'm building an app that depends on Qt6 and by default dpkg-buildpackage generates a >= dependencies for shlibs dependencies I didn't explicitly specify . So specifying:

Depends: ${shlibs:Depends}

Causes:

$ dpkg-query --show -f '${Depends}' mypackage
... qt6-base (>= 6.7.2), ...

The problem is that Qt requires the exact specific version that the app was built against in order to run. If the system has qt6-base version 6.8.0 installed, my app will install but will fail to run - how can I prevent that? I don't want apt to update my app until I have a version that explicitly supports the exact version of Qt that is available on the system (and/or prevent updating Qt until I have released an appropriate version). I know I can add manual explicit dependencies for each and every Qt package I depend on - and then update the version manually every time I build with a new Qt version - but this is going to be so much trouble. I would expect there would by an option of something like "for packages that have the text 'qt' in their name, use a = dependency instead of a >=".