libgcrypt soname bump in rawhide
by Tomas Mraz
I'm rebasing libgcrypt in rawhide to libgcrypt-1.6.1. The new upstream
release contains many improvements over the old one especially in terms
of new crypto algorithm support and performance improvements.
Unfortunately the rebase bumps soname to libgcrypt.so.20 due to dropping
some long-ago deprecated API calls. This should not break builds of any
reasonably current software. I've included the temporary old shared
library so the buildroots are not broken.
I will try to rebuild the dependencies eventually.
Regards,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 9 months
F21 System Wide Change: Fedora 21 Make 4.0 Update
by Jaroslav Reznik
= Proposed System Wide Change: Fedora 21 Make 4.0 Update =
https://fedoraproject.org/wiki/Changes/F21Make40
Change owner(s): Patsy Franklin <pfrankli(a)redhat.com>
This change brings Make 4.0 to Fedora 21.
== Detailed Description ==
The purpose of this update is to synchronize Fedora with the most recent Make
release.
Several new features, new command line options, new variables, and bug fixes
have been implemented in Make 4.0.
Improved error reporting may result in log file differences. If a recipe
fails, the makefile name and linenumber of the recipe are shown.
There is one backwards-incompatibility regarding the use of .POSIX. Make 4.0
will adhere to POSIX requirements for backshlash/newline handling. See the
link included under Documentation for more details.
A new subpackage make-devel will be created containing gnumake.h,a new file
containing externally-visible content.
== Scope ==
* Proposal owners:
** Rebase to make-4.0
** 6 patches need to be updated to work with new sources
** 14 patches will be removed as they are already supported by the make-4.0
rebase
** make.spec will be updated
** local build and test (already completed for glibc and gcc)
** patch created and submitted
** build
* Other developers: There are some minor error message changes that may show
up as log file differences.
If a package's makefile requires a specific version of make, the makefiles may
need editing to include make 4.0.
* Release engineering: There will be a new subpackage make-devel.
* Policies and guidelines: N/A
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 10 months
F21 Self Contained Change: Remote Journal Logging
by Jaroslav Reznik
= Proposed Self Contained Change: Remote Journal Logging =
https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Systemd journal can be configured to forward events to a remote server.
Entries are forwarded including full metadata, and are stored in normal
journal files, identically to locally generated logs.
== Detailed Description ==
Systemd's journal currently provides a replacement for most functionality
offered by traditional syslog daemons,
with two notable exceptions: arbitrary filtering of messages and forwarding of
messages over the network. This Change targets the latter.
The high-level goal is to have a mechanism where journal logging can be
extended
to keep a copy of logs on a remote server, without requiring any maintenance,
done
fairly efficiently and in a secure way.
Two new daemons are added as part of the systemd package:
* on the receiver side systemd-journal-remote accepts messages in the Journal
Export Format [1]. The export format is a simple serialization of journal
entries, supporting both text and binary fields. This means that the messages
are transferred intact, apart from the "cursors", which specify the location
in the journal file. Received entries are stored in local journal files
underneath /var/log/journal. Those files are subject to normal journald rules
for rotation, and the older ones will be removed as necessary to stay within
disk usage limits. Once entries have been written to the journal file, they
can be read using journalctl and the journal APIs, and are available to all
clients, e.g. Gnome Logs [2].
* on the sender side systemd-journal-upload is a journal client, which exports
all available journal messages and uploads them over the network. The (local)
cursor of the last message successfully forwarded is stored on disk, so when
systemd-journal-upload is restarted (possibly after a reboot of the machine),
it will send all recent messages found in the journal and then new ones as
they arrive.
The communication between the two daemons is done over standard HTTPS,
following rather simple rules, so it is possible to create alternate
implementations without much work. For example, curl can be easily used to
upload journal entries from a text file containing entries in the export
format. Basically, the data are sent in an HTTP POST to /upload with Content-
Type: application/vnd.fdo.journal. When doing "live" forwarding, the size of
the transfer cannot be known in advance, so Transfer-Encoding: chunked is
used. All communication is encrypted, and the identity of both sides is
verified by checking for appropriate signatures on the certificates.
== Scope ==
* Proposal owners:
The code in systemd for systemd-journal-remote and systemd-journal-upload will
have to be added. The first is done, and has already been released in the
latest Rawhide systemd package. The second is mostly done, and will be
submitted upstream soon. Necessary units will have to be created, and a
location with suitable permissions will have to be created so that systemd-
journal-remote can run unprivileged. This means that systemd-journal-remote
should probably be packaged as a separate subpackage, similarly to systemd-
journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also
packaged as a separate subpackage to avoid introducing a new dependency for
systemd.
Suitable defaults for timeouts for transfers and maximum accepted entry sizes
have to be chosen.
A port will have to be picked: systemd-journal-gatewayd uses 19531, so
systemd-journal-remote should probably use 19532.
Two new users will have to be created when the packages are installed.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://www.freedesktop.org/wiki/Software/systemd/export/
[2] https://wiki.gnome.org/Apps/Logs
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 10 months
Maybe it's time to get rid of tcpwrappers/tcpd?
by Lennart Poettering
Heya!
I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.
Why would we get rid of them?
Well, to make things simpler, primarily. They have not seen any
development since 2003 (that's 11 years I mind you, an eternity in IT).
I doubt there are many people even using them anymore, firewalls are
more comprehensive and a lot more powerful, and while every admin knows
firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
actively make use of them...
The API is awful, too, with lot's of open-coded structures, feature
checks in the headers, fixed length strings, globally exported variables,
non-namespaced symbols, really weird exported compatibility wrappers for
OS calls...
I'd propose we make a clear cut, and just start disabling it in all
services that link to it, instead of letting rot on in Fedora for all
eternity.
It's bad code, little used, crufty. We have much better stuff now, and
that enables us to say goodbye to the old mess...
I figure there will be a bit of opposition to this change, thus I
thought I start the discussion on the fedora ML first. Unless there are
major concerns I will propose a feature about this in the next few
days. If somebody wants to join me on this and put his name on the
feature proposal I'd be delighted!
Lennart
--
Lennart Poettering, Red Hat
9 years, 10 months
Re: F21 System Wide Change: Workstation: Enable Software Collections
by Kevin Kofler
Jaroslav Reznik wrote, on behalf of Matthias Clasen:
> The Software Collections repositories will be enabled by default.
So we now allow shipping the configuration for third-party repositories,
even enabled by default? Is April 1st still not over yet?
If you want those packages in Fedora, they need to get into the Fedora
repository.
Kevin Kofler
9 years, 10 months
Mass bug: packages should not auto-enable systemd units
by Andrew Lutomirski
Hi everyone-
This is a notice in accordance with the mass bug filing procedure.
A number of packages install systemd units and enable them
automatically. They should not. Please update these packages to use the
macroized scriptlet
(https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).
If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.
There is a general exception described here:
https://fedoraproject.org/wiki/Starting_services_by_default
If your package falls under the general exception, then it is possible
that no change is required. Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible. The
exception is:
In addition, any service which does not remain persistent on the
system (aka, it "runs once then goes away"), does not listen to
incoming connections during initialization, and does not require
configuration to be functional may be enabled by default (but is not
required to do so). An example of "runs once then goes away" service
is iptables.
Given that this issue can affect Fedora 20 users who install your
package as a dependency, these bugs should be fixed in Fedora 20 and
Rawhide.
The tracker bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1090684
I created it early because three of the bugs are pre-existing. Next
week, I'll file bugs against the packages below. If you fix your
package in the mean time, please let me know.
After three weeks, provenpackagers may step in and fix these issues.
OpenIPMI
at
avahi
avahi-dnsconfd
bcfg2
bcfg2-server
bwbar
cronie
deltacloud-core
device-mapper-multipath
dmapd
fsniper
gpm
groonga
hsqldb
iscsi-initiator-utils
jabberd
libvirt
libvirt-client
lvm2
mailman
mdadm
monit
openct
opendkim
openssh-server
partimage
rhnsd
rinetd
sendmail
vdsm
xrdp
yum-updatesd
It's possible that I'm missing some packages. I may follow up with an
updated list.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 10 months
F21 Self Contained Change: Docker Container Image
by Jaroslav Reznik
= Proposed Self Contained Change: Docker Container Image =
https://fedoraproject.org/wiki/Changes/Docker_Container_Image
Change owner(s): Lokesh Mandvekar <lsm5(a)fedoraproject.org>, Dennis Gilmore
<dennis(a)ausil.us>
This is Fedora running inside Docker. Currently, there are non-official images
in the docker index, but we'd like them to really come out of release
engineering.
== Detailed Description ==
The public docker registry [1] hosts many fedora images [2] including an
unprefixed (semi-official) image [3]. However, this image doesn't have rel-eng
approval which would be required for a fully official image.
== Scope ==
* Proposal owners: The proposal owner needs to build the image tarballs with
the official kickstart scripts and make them available to docker's stackbrew
repo, which is used by the Docker maintainers to build unprefixed images.
Release Engineering approval/intervention would be needed at some point
(details still TBD)
* Other developers: N/A (not a System Wide Change)
* Release engineering: Official Release Engineering image approval. Process
still TBD.
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://index.docker.io/
[2] https://index.docker.io/search?q=fedora
[3] https://index.docker.io/_/fedora/
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 10 months
Reinstalling the bootloader
by Andrew Lutomirski
Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.
Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is
there a way to reinstall it without reinstalling the world? Would it make
sense to split the whole bootloader thing out of Anaconda such that it
would be possible to re-run it? I can access my install just fine using
chroot.
FWIW, the same question applies to upgrading the bootloader. Somehow I'm
on Fedora 20 using grub 0.97.
--Andy
9 years, 10 months
gcc build with -O0 results in corrupted -debuginfo package
by Petr Spacek
Hello list,
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and built the package:
$ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. The problem is that new
debuginfo package is missing 118 out of 283 header files in
/usr/src/debug/bind-9.9.4-P2.
It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
I would be glad if anyone can give me advice how to debug this.
Original packages from Fedora 20 (with all headers in /usr/src/debug):
http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
Packages built with -O0 -ggdb (scratch build):
http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
Thank you for your time!
--
Petr^2 Spacek
9 years, 10 months
