Packages installing files to /etc/rpm
by Ville Skyttä
A number of packages install files to /etc/rpm in Rawhide; the proper
place for macros.* is /usr/lib/rpm/macros.d for rpm >= 4.11. And no
matter what the location, these files should not be marked as %config.
Specfiles not targeting EL < 7 can simply replace %{_sysconfdir}/rpm
with %{_rpmconfigdir}/macros.d and ones that wish to stay compatible
with EL5 and 6 can do something like this to find the proper dir:
%global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] ||
d=%{_sysconfdir}/rpm; echo $d)
List of affected packages follows (maintainer package comaintainers):
bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur
bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej
cicku ldc bioinfornatics
deji mpich (none)
dledford openmpi dajt,deji,orion
epienbro mingw-filesystem ivanromanov,kalev,rjones
erikos sugar-toolkit erikos,pbrobinson,sdz,tomeu
erikos sugar-toolkit-gtk3 dsd,pbrobinson
jakub prelink mjw
jcapik octave alexlan,fkluknav,jussilehtola,mmahut,orion,rakesh
jjames ffcall salimma
jjames gap (none)
jjames xemacs stevetraylen
jnovy texlive pertusus,than
jorton httpd hubbitus,jkaluza
jorton php-pear remi,timj
jorton php remi
jplesnik perl corsepiu,cweyl,iarnell,jplesnik,kasal,perl-sig,ppisar,psabata,spot
jussilehtola libint (none)
jzeleny scl-utils bkabrda,jzeleny
kanarip ruby bkabrda,jstribny,kanarip,mmorsi,mtasaka,skottler,tagoh,vondruch
kanarip rubygems kanarip,mtasaka,skottler,stahnma,vondruch
kwizart color-filesystem rhughes
limb drupal7 asrob,pfrields,siwinski
mmorsi jruby bkabrda,goldmann,vondruch
mstuchli pypy tomspur
msuchy rhn-client-tools mzazrive
nim fontpackages fonts-sig,frixxon,tagoh
orion hdf5 davidcl,pertusus
patches nodejs-packaging humaton,jamielinux,mrunge,sgallagh
patches nodejs-tap jamielinux
peter erlang-rpm-macros erlang-sig
petersen ghc-rpm-macros haskell-sig,petersen
phracek emacs jgu,phracek
pjones pesign (none)
pmatilai redhat-rpm-config jcm,pmatilai
ppisar perl-srpm-macros mmaslano,perl-sig
rdieter ggz-base-libs (none)
rdieter polkit-qt mbriza,rnovacek,than
remi php-horde-Horde-Role nb
rmattes ros-release (none)
rombobeorn fedora-gnat-project-common (none)
rstrode GConf2 walters
s4504kr blender fcami,hobbes1069,kwizart,roma
s4504kr gnustep-make s4504kr,salimma
smani keyrings-filesystem (none)
sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb
spot generic-release bruno
spot R salimma
than sip kkofler,ltinkl,rdieter
twaugh cups jpopelka
10 years, 1 month
F20 Self Contained Change: Snapshot and Rollback Tool
by Jaroslav Reznik
= Proposed Self Contained Change: Snapshot and Rollback Tool =
https://fedoraproject.org/wiki/Changes/Rollback
Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>, Colin Walters
<walters(a)redhat.com>
With the advent of thinly-provisioned LVM pools, it has become possible for us
to implement full-system LVM snapshotting for recording rollback points. We
are planning to support this for yum updates and eventually fedup upgrades
going forwards. This change request notes the addition of new tools provided
by the roller-derby project to present an interface and a CLI for managing and
initiating rollbacks.
== Detailed description ==
The roller-derby project will be providing a library and a CLI for creating,
labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented
primarily towards rpm-managed data, but useful beyond that. The yum plugin
"yum-plugin-fs-snapshot" will be updated to consume this library and save the
system state in a compatible format. The roller-derby CLI tool will provide an
interactive and scriptable interface for manipulating these snapshots and
determining when to remove older ones. It will also allow the tagging of
snapshots as "known-good", to be skipped when automatically-trimming for
space. The roller-derby project will likely provide a small daemon to keep
track of the available space in the LVM pool to proactively clean up snapshots
before the system runs out of space.
In order to prevent "loss" of data when rebooting into an snapshot, the
roller-derby CLI will allow saving a snapshot of the current state before
rolling back and will provide tools to allow mounting of that current state to
recover changes that have occurred since the rollback point.
== Scope ==
The scope of this project is the completion of the initial release of the
roller-derby project and the inclusion of thinly-provisioned LVM as an option
in the Anaconda installer [1].
Proposal owners: We need to complete the roller-derby project. Other than the
Anaconda change referenced above, all dependencies are available in Fedora
already.
Other developers: OS Installer Support for LVM Thin Provisioning
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 1 month
Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
by Philip Prindeville
I’m seeing the following after an update (via yum) from F19 to F20:
----
time->Tue Dec 24 16:05:44 2013
type=SYSCALL msg=audit(1387926344.492:5867): arch=c000003e syscall=1 success=no exit=-13 a0=6 a1=7f4e5e7afbb0 a2=20 a3=7fff44c2c550 items=0 ppid=686 pid=693 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926344.492:5867): avc: denied { dyntransition } for pid=693 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process
----
time->Tue Dec 24 16:05:45 2013
type=SYSCALL msg=audit(1387926345.093:5883): arch=c000003e syscall=1 success=no exit=-13 a0=7 a1=7f4e5e7acef0 a2=2a a3=666e6f636e753a72 items=0 ppid=686 pid=706 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=627 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926345.093:5883): avc: denied { dyntransition } for pid=706 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
Is this a known issue? I’m running:
selinux-policy-devel-3.12.1-106.fc20.noarch
selinux-policy-targeted-3.12.1-106.fc20.noarch
selinux-policy-doc-3.12.1-106.fc20.noarch
selinux-policy-3.12.1-106.fc20.noarch
openssh-clients-6.4p1-3.fc20.x86_64
openssh-6.4p1-3.fc20.x86_64
openssh-server-6.4p1-3.fc20.x86_64
Thanks,
-Philip
10 years, 1 month
Fedora.NEXT Products and the fate of Spins
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Apologies for the slightly alarmist $SUBJECT, but I want to make sure
that this gets read by the appropriate groups.
During today's FESCo meeting, there was the start of a discussion on
how to approve new Products into the Fedora family. As part of this,
it naturally strayed into discussion of what we do about Spins as they
currently exist.
Several ideas were raised (which I'll go through below), but we didn't
feel that this was something that FESCo should answer on its own. We'd
prefer community input on how to handle spins going forward.
So, in no particular order (because it's difficult to say which
questions are the most important):
1) Are Spins useful as they currently exist? There are many problems
that have been noted in the Spins process, most notably that it is
very difficult to get a Spin approved and then has no ongoing
maintenance requiring it to remain functional. We've had Spins at
times go through entire Fedora release cycles without ever being
functional.
2) Should Spins be eliminated entirely in favor of Fedora Remixes[1].
The effect here would be that Spins are no longer an official part of
The Fedora Project but are instead projects unto themselves which are
permitted to consume (possibly large) portions of our tools, packages
and ecosystem. Maintenance and upkeep of these spins then becomes
entirely the responsibility of the downstream community that
constructs them and has no mandatory draw on Fedora's marketing,
ambassadors or quality assurance resources.
3) Should Spins be considered Products-in-development? In other words,
should we only approve Spins that are targeted or destined for
"promotion" to a fully-supported Fedora Product? This is a nuanced
question, as it means different things for different Spins, for
example Spins focusing on a target-audience (Security Spin, Design
Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz
Spin).
3b) If we treat Spins as Products-in-development, what do we do with
those Spins that don't fit that criteria?
I'm sure there are other questions that people will come up with on
this thread, but this should provide a good framework for the discussion.
[1] https://fedoraproject.org/wiki/Remix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLpZMwACgkQeiVVYja6o6NOIwCeP6Kr6FGVYLCdU9Uofv7Xrqm1
e3oAoIEky2/IjoGBF9MqVlEbkG0jd4vv
=KDoO
-----END PGP SIGNATURE-----
10 years, 1 month
Heads up; F22 will require applications to ship appdata to be listed in software center
by Richard Hughes
Hi,
As the subject suggests, Fedora 22 will require applications to have a
long description to be shown in the software center. We're introducing
this change so that we can show a powerful application full of
high-quality content, rather than what we have now which is a equal
mixture of awesome and sadness.
If you're interested you can see the number of applications with
appdata without installing gnome-software from rawhide here:
http://alt.fedoraproject.org/pub/alt/screenshots/f21/status.html
(warning; huge generated HTML file).
A lot of unmaintained or unloved applications will be removed (which
is a totally good thing, we don't want new users choosing buggy and
crashy apps), but there are also a lot of applications there that we
probably want to save. Note that I don't want the packages removed
from Fedora; users can still use the command line to install them,
just not show them in the 'Software' GUI.
"Saving" an application (so that it still appears in the software
center) is just a matter of either:
* Convincing upstream to ship and install an appdata file
* Installing an appdata file from the Fedora package into
/usr/share/appdata (if upstream is dead / unwilling to add the file)
I've written a bit about the AppData status on my blog,
http://blogs.gnome.org/hughsie/2014/01/22/appdata-status-for-january/
and so far over 200 applications ship AppData in Fedora 21. That's a
long way from what I'd like to see, but it's going up at about 1% per
month, which is encouraging.
KDE/XFCE doesn't ship gnome-software - however Apper does parse the
appdata in KDE, and we also want to show awesome KDE/XFCE applications
in gnome-software so this really applies distro-wide.
Comments welcome, thanks.
Richard
10 years, 2 months
Downstream .so versioning
by Jan Staněk
Hi,
What should one do if the SW he is trying to package produce only
unversioned *.so files? I'm currently trying to package LMDB [1] as
possible alternative for BerkeleyDB in Fedora, and the hand-written
makefile produce only liblmdb.so.
I'm trying to persuade the upstream to change it and start to do it
properly, however if that fails, what can I do with it on my end?
Thanks for answer,
Jan
[1] http://symas.com/mdb/
--
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team
10 years, 2 months
Can we have better ssh fingerprint collision messages?
by Valent Turkovic
I really enjoy working with ssh on Ubuntu just for this simple reason,
they have user friendly ssh fingerprint collision messages:
$ ssh root(a)192.168.1.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
c0:3b:b2:60:a6:e2:5e:97:aa:ae:ec:d2:ca:ba:27:1b.
Please contact your system administrator.
Add correct host key in /home/valent/.ssh/known_hosts to get rid of
this message.
Offending RSA key in /home/valent/.ssh/known_hosts:8
I really miss this feature when I return back to Fedora.
How hard would be to make this behavior default for Fedora also?
10 years, 2 months
Upgrade ICU to 52.1 with soname bump
by Eike Rathke
Hi,
If time permits I'd like to do an upgrade of ICU to 52.1 next week,
which leads to the usual soname bump.
As quite a lot of packages are affected by this, is anyone objecting and
can point out a better time for the upgrade?
If not, I'll probably announce it on Monday and do the upgrade on
Wednesday.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
10 years, 2 months