runtime dependencies not in Requires spec section
by Germano Massullo
I am one of the keepassxc maintainers. Bugreport
"Missing dependency: qt5-qtsvg libQt5Svg.so.5"
https://bugzilla.redhat.com/show_bug.cgi?id=1911210
made me wonder about the following thing:
I just installed a basic Fedora server to do a test concerning keepassxc
libs. Keepassxc spec file [1] does not contain any Requires dependency,
but when I install it, it triggers the installation of these libraries
[2] that are needed at runtime.
My question is: how can keepassxc trigger the installation of such
libraries if the spec file does not contain any Requires dependency that
should be the attribute to identify runtime dependencies that are needed
by the package?
Thank you
[1]:
https://src.fedoraproject.org/rpms/keepassxc/blob/master/f/keepassxc.spec
[2]:
fontconfig freetype glx-utils graphite2 harfbuzz langpacks-core-font-en
libICE libSM libX1 libX11-common libX11-xcb libXau libXdamage libXext
libXfixes libXi libXtst libXxf86vm libdrm libevdev libglvnd libglvnd-egl
libglvnd-glx libinput libjpeg-turbo libpciaccess libsodium libwacom
libwacom-data libwayland-client libwayland-server libxcb
libxkbcommon-x11 libxshmfence libyubikey llvm-libs mesa-filesystem
mesa-libEGL mesa-libGL mesa-libgbm mesa-libglapi mtdev pcre2-utf16
qt-settings qt5-qtbase qt5-qtbase-common qt5-qtbase-gui qt5-qtsvg
qt5-qtx11extras quazip-qt5 xcb-util xcb-util-image xcb-util-keysyms
xcb-util-renderutil xcb-util-wm xml-common ykpers Weak dependencies:
mesa-dri-drivers
3 years, 3 months
gpg-agents all over the place
by Marius Schwarz
Hi,
I sorry to tell you, that gpg-agents are inflating on numbers in Fedora
systems:
As far as I understand ssh-agents, you start ONE for each user, but
here, one for each repo is opened by PackageKit:
(today)
root 2530 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-modular-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2637 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-free-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2653 0.0 0.0 151908 796 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-nonfree-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2668 0.0 0.0 151908 816 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2693 0.0 0.0 151908 860 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/fedora-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2710 0.0 0.0 151908 708 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-modular-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2723 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3393 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3404 0.0 0.0 151908 712 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3417 0.0 0.0 151908 800 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3438 0.0 0.0 151908 812 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3451 0.0 0.0 151908 808 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3464 0.0 0.0 151908 936 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3474 0.0 0.0 151908 948 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3492 0.0 0.0 151908 768 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/teamviewer-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3512 0.0 0.0 151908 884 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3526 0.0 0.0 151908 888 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-cisco-openh264-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
it would be more effective, if you give any programm who needs it, the
password directly, instead of having useless processes laying around ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1895012
it's not even doing this for every system, as my private pc does not
have those (upgraded by dnf, and yes, it's installed), but others do
(upgraded by packagekit).
Systemd opens gpg-agents even for mailserver daemons, which do not need
nor know how to use them.
https://bugzilla.redhat.com/show_bug.cgi?id=1877308
No idea what caused this invasion lately, but bugreports about it, get
ignored.
Could someone please take a look and fix it, if it's bug.
best regards,
Marius Schwarz
3 years, 3 months
Self Introduction: Frédéric Pierret (fepitre)
by Frédéric Pierret
Hi,
My name is Frédéric and you can reach me on Github as "fepitre" (https://github.com/fepitre).
I'm currently a member of Qubes OS (https://github.com/QubesOS) core team since 2016. In this project, my work consists in releasing (building, packaging, testing or continuous integration) the OS at every stages. Qubes OS has its dom0 based on a customized Fedora for embedding our custom Xen version and Qubes specific components. For example, our own Qubes specific libraries or tools, kernel or even custom Anaconda installer. Moreover, we build our own VM templates from scratch for VMs for which I'm a maintainer of the Fedora, Debian, CentOS or Gentoo ones.
For the Fedora/CentOS work on Qubes OS, I have several COPR repositories https://copr.fedorainfracloud.org/coprs/fepitre/ for which I've built some of Fedora packages for CentOS not in EPEL or maybe some of you have seen my few PRs this summer in order to ease me the build of a larger python3.8 repository for CentOS 8+.
I'm contacting you because I would like to propose my help for either Fedora or EPEL packaging. Notably, I'm recently involved in reproducible topics (https://reproducible-builds.org/) for which I'm trying to implement RPM support and packaging for tools like `reprotest` (see https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/10 or https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/4). The idea is to help into reviving Fedora reproducible builds topic (see https://tests.reproducible-builds.org/rpms/fedora-23.html).
I'm using Redhat linux distribution family for more than 20 years so I guess it's time to propose my help into this community effort.
Best regards,
Frédéric
3 years, 3 months
Updating armadillo and dependent packages (rawhide)
by José Abílio Matos
Hi,
a bit later than what I expected (holidays are a busy time as well :-) ) I
will update armadillo to 10.1.0. This implies an so bump and so I will update
it in a side tag together with the dependent packages gdal and mlpack.
I intend to do this for rawhide, and later for Fedora 33 and 32.
Best regards,
--
José Abílio
3 years, 3 months
List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, orphan, tpokorra Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-getiabooks callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-infoslicer callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
No packages require above mentioned packages.
Affected (co)maintainers
callkalpa: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks,
sugar-infoslicer, sugar-view-slides, sugar-flipsticks
chimosky: sugar-labyrinth, sugar-starchart, sugar-ruler, sugar-getiabooks,
sugar-infoslicer, sugar-view-slides, sugar-flipsticks
elsupergomez: boo
gsgatlin: VirtualGL
pbrobinson: sugar-labyrinth, sugar-getiabooks, sugar-infoslicer,
sugar-view-slides, sugar-flipsticks
tpokorra: boo
tuxbrewr: sugar-getiabooks, sugar-infoslicer, sugar-view-slides, sugar-flipsticks
3 years, 3 months
Self Introduction -- Derek Pressnall
by dspgh＠needcaffeine.net
Hello fellow developers.
I've joined this list quite a while ago, mostly to keep a pulse on the Fedora development community, but also to look to become a package contributor. But before getting to that, a few words about myself.
I've been "into computers" since mid-80's, started off with a 4.77 Mhz 8088 (IBM PCjr). I learned Unix in the early 90's on an IBM AIX system, where I picked up C programming and sysadmin experience. Which eventually took me into the world of Linux (I think it was kernel version 0.12, came on a boot disk and root disk pair I grabbed off a BBS, long before there was easy general public Internet access).
Anyway I've been focused on Red Hat based distros for the past 15 years, and at my current employer I oversee about 700 systems installed at customer locations (where I was the resource responsible for packaging our applications and creating system build images).
Any way, what I'd like to give back to the community is a really nice backup system called Snebu (Simple Network Encrypting Backup Utility). I initially developed this more than 8 years ago since there wasn't anything else that fit my needs -- I used it to back up my personal systems, and also in some lab environments. I've read plenty of rants that have been posted about how backups are either too difficult to set up, or don't support multiple clients, or require a repository encryption password to be placed in plain text on clients, and other issues people have. With that in mind, I believe that Snebu can be just what people want.
Before going through and submitting the package for formal review, I'd appreciate some feedback on what I have packaged up so far. The current release is at https://github.com/derekp7/snebu/releases/download/v1.1.0/snebu-1.1.0-1.f..., and the project web site is at https://www.snebu.com.
The main features that it has that are interesting: It maintains a centralized package database on the server (using SQLite3) tracking backup sets and metadata; actual files are stored in the filesystem as lzop compressed files using a file hash for the file name which leads to full cross-system file level de-duplication (so no proprietary file formats); uses a snapshot style backup strategy; it uses GNU tar as a serialization format to shuffle backups to the server which leads to how the public key encryption support was added by developing "tarcrypt"; and it works in single-system installs, client-push or server-pull backups, with no agent required on the client.
Another interesting project that I may spin off is the above mentioned "tarcrypt" command. This acts as a filter for tar files, which adds RSA key data to the header (passphrase protected private key, public key, HMAC signatures, etc), compresses and encrypts the file contents while keeping standard tar headers in place (with the additional encryption metadata added via extended PAX headers). The details on this project is at https://www.snebu.com/tarcrypt.html. So far tarcrypt is part of the Snebu repository, but if there is interest then it may eventually be spun out as an independent project.
BTW, the current .src.rpm file for Snebu mentioned above has passed through a valid build using the Fedora "mock" utility, and passed rpmlint. The only error rpmlint shows is:
snebu.src: W: spelling-error %description -l en_US de -> DE, ed, d
Not sure what that error is saying, as the text at the end of the message doesn't appear anywhere in the .spec file.
Thanks, and I look forward to your feedback.
3 years, 3 months
