as some already might have noticed, Coin3 is about to land in Fedora.
Therefore, I rebuilt SIMVoleon and SoQt (two addon-packages to Coin),
against Coin3 on rawhide and f22. I do not expect this to impose
problems to Fedora, because I can't spot any packages depending on these
On Fedora <= 21 these packages will have to stay with Coin2 to avoid
Though it's thinkable to do so, I do not plan to provide Coin3-compiled
versions of these packages for fc20, f21 and Coin2-compiled versions for
fc22, f23, at the moment. Please speak up now, should you have such a
I am writing patch for system-config-users that allows configure users ang group from a IPA server with python library ipalib from package ipa-python. I would like the changes be included in the system-config-users. What is the best way to implement this from the point of view of architecture? I am now implementing API that is similar to API of libuser.
I've been given a (.net4.5/c# + vmware) project to port to
Fedora/RHEL (mono + kvm), so I suddenly find myself interested
in gaining access to late-model official Fedora packages for
mono (4.0.0 alpha is just out) and monodevelop (currently at 5.7.0).
The current F21 versions are 2.10.8 and 2.8.8, respectively, and
I see those versions are still the same in rawhide.
Are there any plans to package the more recent versions in F22 or F23 ?
= Proposed System Wide Change: Disable SSL3 and RC4 by default =
Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com>
This change will disable by default the SSL 3.0 protocol and the RC4 cipher in components which use the system wide crypto policy. That is, gnutls and openssl libraries, and all the applications based on them.
== Detailed Description ==
There are serious vulnerabilities known to the SSL 3.0 protocol, since a decade. Recent attacks (e.g., the POODLE issue #1152789) take advantage of them, negating the secrecy offerings of the protocol. The RC4 cipher is also considered cryptographically broken, and new attacks against its secrecy are made known every year (#1207101). Since attacks are only getting better, we should disable these broken protocols and ciphers system wide.
== Scope ==
* Proposal owners: The crypto-policies package has to be updated to accommodate the new policies.
* Other developers: Should verify that their package works after the change. That is that their package doesn't require only SSL 3.0, or only the RC4 ciphersuites. If their package requires these options due to design, they should consider contacting upstream to update the software. If that is not possible, or this support is needed to contact legacy servers, they should consider not using the system wide policy, and make that apparent in the package documentation.
* Release engineering: This feature doesn't require coordination with release engineering.
* Policies and guidelines: The packaging guidelines do not need to be changed.
devel-announce mailing list
In two weeks we will be entering the F22 Final Freeze. At that point,
Fedora release engineering retires any packages that still have broken
dependencies in the F22 tree.
Based on today's Branched report , we still have a number of unfixed
packages with broken dependencies (package maintainers BCC'd to this
email). Anything not fixed by 2015-05-11 from the list below is going to
be automatically retired:
aeskulap ankursinha, mrceresa, susmit
bro fab, mildew
crystal bnemec, chitlesh
gcc-python-plugin dmalcolm, jakub
gl3n cicku, bioinfornatics
leksah petersen, haskell-sig
newsx rathann, itamarjp
oozie rrati, coolsvap, moceap
opensips ivaxer, peter
rss-glx nphilipp, cheese
syntastic bioinfornatics, praiskup
tango bioinfornatics, cicku
templates_parser oenone, landgraf
These are all leaf packages; no other package depends on them.
I've excluded odb-2.3.0-11.fc22, openchange-2.2-6.fc22,
rubygem-moped-1.5.2-5.fc22, zeromq-ada-2.1.0-17.24032011git.fc22 from
the list above; they all have fixes in updates-testing and just need
karma in Bodhi to go to stable.
Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu?
All my systems are multiboot, so only a select very few are on UTC. None that
are on UTC have Fedora installed. This means every Fedora boot takes about
twice as long or longer than anything else takes, waiting on all the
unnecessary FS checks.
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
As we believe that the only project that may have been using
'nss_compat_ossl' was the 'elinks' project, and they are abandoning its
use (see elinks-0.12-0.44.pre6.fc23
<http://koji.fedoraproject.org/koji/buildinfo?buildID=624753>), I am
announcing that I am orphaning the 'nss_compat_ossl' package effective
immediately in 'rawhide'.
I have a package (kubernetes) which I would like to decompose into 2
subpackages A and B. Problem is A and B share some files and directories
so installing both of them on the same machine results in file
conflicts. Solution is to create the third package C, which provides all
those conflicting/shared files and directories (documentation, one
configuration file, etc.). So A and B both Requires C. So now both A and
B can be installed on the same machine (together with C).
My question is how should I name subpackage C? Should it be named common
or shared or base or "this files and directories are shared together
package". Is there a convention on naming a subpackage with these common
or shared files and directories?
glibc-common provides configuration file, binaries, locales
emacs-common provides binaries, service file, documents, charsets,
gnuplot-common provides binaries, docs, PostScript files, one man page,
one info page, ...
Is there a minimum requirement what should a common package provide or
is it just arbitrary?
Subpackage C provides one directory, one configuration file and 4 docs.
Thanks for any answer.
I was doing a test build of zipios++ for rawhide in mock and when the build
for the documentation was attempted I got an interesting (if unhelpful)
It looks like the make doc target uses convert for part of the
+ make V=1 doc
convert doc/images/zipios++.jpg doc/images/zipios++.eps
Makefile:808: recipe for target 'doc' failed
make: *** [doc] Illegal instruction (core dumped)
Doing this by hand in my f21 system seems to work.
We have another Test Day coming up on Thursday, part of the effort to
test package management around the DNF migration. We'll be testing the
GNOME Software Center and Apper (KDE's graphical package management
It should be a fairly light effort - we just need to test basic
functionality in both tools to make sure things work.
The Test Day page is here:
It's mostly just the template at present, though - I'll clean the page
up and add some test cases tomorrow.
Please do join us in #fedora-test-day on Freenode IRC and help test if
you can! Thanks.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list