Better irc policies?
by Andreas Tunek
Currently the #fedora channel on freenode requires some kind of
registration. In my opinion it is pretty difficult to register on
freenode (I have tried but haven't managed). Do you think it would be
possible to drop the registration requirement? It is a pretty big
barrier to newbies and people like me who can't find IRC help easily.
I know there are a lot of bots and spam, but maybe it would be
possible to try and see if it really gets bad?
Best regards
Andreas
8 years, 6 months
How to make .spec Requires for libXXX.so.VER
by Jan Kratochvil
Hi,
https://bugzilla.redhat.com/show_bug.cgi?id=1249325
GDB requires some library libXXX.so.3 by dlopen(). Therefore it is not found
by rpm automatic requires/provides from DT_NEEDED. Therefore one has to add
the libXXX.so.3 by specific BuildRequires and Requires to the .spec file.
libXXX is librpm here but that is just a coincidence, it could be libz for
example.
(1) How to make a dependency on librpm.so.7?
librpm.so.7 is in rpm-libs-4.12.90-3.fc24.x86_64 which --provides:
librpm.so.7()(64bit)
librpmio.so.7()(64bit)
rpm-libs = 4.12.90-3.fc24
rpm-libs(x86-64) = 4.12.90-3.fc24
So there is no easy way to Requires: rpm-libs = NVRA
I do not see which V introduced / deprecates .so library version 7.
So I would like to: Requires: librpm.so.7
But that does not work as I need there the '()(64bit)' suffix.
%{?_isa} suffix does not work, that is '(x86-64)' and not '()(64bit)'.
I could %ifarch explicitly all 64-bit Fedora archs to append '()(64bit)' for
them but isn't there some better way how to generate the '()(64bit)' suffix?
(2) The other possibility does work:
BuildRequires: %{_libdir}/librpm.so.7
But
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies
says
Whenever possible you should avoid file dependencies as they slow down
dependency resolution and require the package manager to download file
lists in addition to to regular dependency information.
>From what I remember at least yum did not need the 'filelists' index for
/usr/bin/ files. Is it still valid today and also for dnf?
And is 'filelists' required for /usr/lib{,64}/ or not?
I think Packaging Guidelines could list these few directories - at least
/usr/bin/ - for safe file dependencies.
Thanks,
Jan
8 years, 6 months
A backup service using fuse, sqlite and btrfs.
by Stef Bon
Hi,
I would like to put the project I'm working on in the spotlight. It's
fuse-backup, a service which gives users the possibilty to enable backups
for folders, and select what is to be backupped based upon mimetype.
Fuse-backup does not backup every time a file has changed, but after every
session.
(actually at the start of the next session).
Screenshots (and the rest of the project) you'll find at:
https://sourceforge.net/projects/fusebackup/
The screenshots are of a simple qt gui, which interfaces with the
fuse-backup daemon using the fuse fs. This fuse gives information about
which backups a user has, what has been backupped and the versions per file.
It uses FUSE, sqlite and btrfs.
Earlier I spoke Michael Meeks about writing a tool for showing the
differences between office files. Fuse-backup provides very easy access to
ealier versions, now it would be very nice to have a tool which will enable
the user to view the differences between versions in a smart way. The new
toolkit for LibreOffice LibreOfficeKit offers tools for that, like showing
a page as an image (generate a pixmap from RGB).
Further I'm looking at Dolhin to create a plugin to support fuse-backup. I
would be awfully nice to show the different versions of a file with a
simple mouseclick in Dolphin, and then show a menu per version when
rightclicking, and showing the differences with the current version would
be one of the choices. So this is also work to be done.
The project is still in alpha.
Any comments?
Stef
8 years, 6 months
F21: fedora-easy-karma / bodhi / updates testing / kf5-baloo
by Reindl Harald
besdies that updates-testing is broken for days now it becomes boring
the fedora-easy-karma still don't work
bodhi2 at https://bodhi.fedoraproject.org/ is unusable for testers
because the search field seeks for users, no idea how to get to the
current firefox build for give karama as example
__________________________________________
Getting list of installed packages...
Waiting for Bodhi for a list of packages in updates-testing (F21)...
Cannot query Bodhi: 1000 is greater than maximum value 100
python-fedora-0.5.5-2.fc21.noarch
__________________________________________
Error: Package: 1:libreoffice-calc-4.3.7.2-9.fc21.x86_64 (installed)
Requires: libwps-0.3.so.3()(64bit)
Removing: libwps-0.3.1-1.fc21.x86_64 (installed)
libwps-0.3.so.3()(64bit)
Updated By: libwps-0.4.1-1.fc21.x86_64 (updates-testing)
~libwps-0.4.so.4()(64bit)
Available: libwps-0.3.0-3.fc21.x86_64 (fedora)
libwps-0.3.so.3()(64bit)
Error: Package: 1:libreoffice-writer-4.3.7.2-9.fc21.x86_64 (installed)
Requires: libwps-0.3.so.3()(64bit)
Removing: libwps-0.3.1-1.fc21.x86_64 (installed)
libwps-0.3.so.3()(64bit)
Updated By: libwps-0.4.1-1.fc21.x86_64 (updates-testing)
~libwps-0.4.so.4()(64bit)
Available: libwps-0.3.0-3.fc21.x86_64 (fedora)
libwps-0.3.so.3()(64bit)
__________________________________________
*what is that*
yum --skip-broken update tries "kf5-baloo replacing baloo.x86_64
4.14.3-1.fc21" and pulls a ton of KF5 dependencies which is a bad joke
if the only installed QT/KDE5 application is "sddm"
well, and even if you say yes, the deps are horrible broken and since my
systems are minimal-setups i doubt that anybody got that installed
Transaction check error:
file /usr/share/locale/de/LC_MESSAGES/kfilemetadata.mo from install
of kf5-kfilemetadata-5.13.0-1.fc21.x86_64 conflicts with file from
package kde-l10n-German-4.14.3-1.fc21.noarch
8 years, 7 months
Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking
by Josh Stone
I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
this morning, and now I get this stderr output:
$ /usr/bin/stap -V >/dev/null
/usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
shared object, consider re-linking
The message comes from ld.so; that symbol comes from libssl3.so.
Should I be worried about this? Do we need a rebuild of all
nss-dependent packages to clear this message?
8 years, 7 months
Looking for new maintainer: ownCloud (Fedora / EPEL)
by Adam Williamson
Hi, folks. So I've been maintaining ownCloud for the last little
while. Unfortunately I sat down today to try again and update the
package to the latest upstream (8.1.1), and somewhere in the second
hour of insanely stupid PHP autoloader code, I just snapped. I can't
take this crap any more.
I only personally really needed OC for calendar and contact sync
anyway, so I've set up Radicale instead: it's written in Python and it
doesn't have a ridiculous forest of bundled crap.
Given that there are dozens of other things I could be spending my
time on that I'd find more rewarding, I'm just not willing to do any
further major updates of the Fedora / EPEL ownCloud package, I'm
sorry. I'm willing to keep the current major versions (8.x in
everything but EPEL 6, 7.x in EPEL 6) updated until they go EOL, at
which point if no-one else is interested, I will orphan the package.
If anyone would like to take on the work of doing the 8.1 upgrade and
maintaining the package in future, please do let me know and I'll
happily transfer it over. To do a decent job, though, you are going to
*need* to know or be willing to learn quite a lot of intimate and
incredibly annoying details about things like PHP class loading and
how Composer works. If you don't, for instance, know what it means for
unbundling purposes when a PHP library specifies 'classmap' as the
autoload mechanism in its composer.json file, and you're not willing
to spend your time learning, you probably don't want to own this
package. :)
I'm very sorry to folks who are using it, but I really can't deal with
the crap any more. If all you need is calendar/contact sync, there are
easier ways. Check out Radicale or something like it.
Upstream does of course provide ownCloud packages in an OBS repo. They
do not follow Fedora web app packaging policies or unbundling rules,
and probably don't work very well with SELinux. Switching from the
Fedora/EPEL packages to the OBS ones is likely to require moving
various things around and config file editing and stuff. I'm not going
to document that, sorry. If anyone else does, though, that'd be great.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 7 months
Attempting to contact unresponsive maintainer - dvossel
by Kevin Fenzi
Greetings, we've been told that the email addresses
for this package maintainer is no longer valid. I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS). If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.
If you have a way to contact this maintainer, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!
* dvossel - former email: dvossel(a)redhat.com
Point of contact:
resource-agents -- Open Source HA Reusable Cluster Resource Scripts
( master f23 f22 f21 )
Co-maintainer:
libqb -- An IPC library for high performance servers ( master f23 f22
f21 epel7 )
sbd -- Storage-based death ( master f23 f22 f21 )
kevin
8 years, 7 months
GNOME 3.17.91 megaupdate
by Kalev Lember
Hi all,
Just a quick heads up that it's GNOME 3.17.91 release this week and we
are still using the f23-gnome side tag for builds - please use 'fedpkg
build --target f23-gnome' if you are helping with builds.
I'll take care of submitting them all in a single bodhi update ticket
later this week.
Thanks,
Kalev
8 years, 7 months
F23 System Wide Change: Glibc locale subpackaging
by Jan Kurik
= Proposed System Wide Change: Glibc locale subpackaging =
https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
Change owner(s):
* Mike Fabian <mfabian At redhat DOT com>
* Siddhesh Poyarekar <spoyarek AT redhat DOT com>
* Carlos O’Donell <codonell AT redhat DOT com>
This change should make it possible to install or uninstall locales individually.
== Detailed Description ==
Currently the file /usr/lib/locale/locale-archive contains all locales and is thus huge (103MB).
For small systems (and containers) it would be useful to be able to install only a small number of locales.
Recently we made it possible to install a small number of locales by supplying the rpm-macro “_install_langs”, for example
rpm -i -D _install_langs="en:de_DE" glibc-common.rpm
will install all English locales and all German locales which start with “de_DE”,
rpm -i -D _install_langs="en_US.utf8" glibc-common.rpm
will install only the en_US.utf8 locale,
rpm -i -D _install_langs="POSIX" glibc-common.rpm
will install nothing (but the POSIX/C is still available because it is builtin into glibc).
But this approach works only during an Anaconda based install when Anaconda supplies the _install_langs rpm-macro.
When glibc is updated later, the _install_langs macro will not be supplied on the command line during the update and the default value “all” of “_install_langs” from /usr/lib/rpm/macros will be used and all locales come back during an update.
Therefore, this solution is far from perfect.
It should be made possible to install and uninstall locales individually, for example by having a separate package for the locales for each language. Installing such a package would add these locales to locale-archive, uninstalling it would remove them.
Anaconda then needs to be changed to handle such language packages.
== Scope ==
* Proposal owners:
1. Figure out the best approach to to install/uninstall locales
2. Make sure that locales added manually by the user are not destroyed (currently they are lost when glibc is updated)
* Other developers:
Anaconda needs to be made aware of the new approach to handle installation/uninstallation of locales
* Release engineering:
I am not sure whether this has affects release engineering, probably the packages in the install image change when parts are split out of glibc-common.
* Policies and guidelines:
No, this change does not require updates to policies and guidelines.
* Trademark approval: not needed for this Change
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 7 months
