SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
by Ralf Corsepius
Hi,
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
in Fedora.
On Fedora <= 21 these packages will have to stay with Coin2 to avoid
breaking backward-compatibility.
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
demand.
Ralf
5 years, 9 months
system-config-users and IPA
by Мартынов Александр
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.
5 years, 9 months
Roadmap for Mono packages in Fedora ?
by Gabriel Somlo
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 ?
Thanks much,
--Gabriel
5 years, 10 months
F23 System Wide Change: Disable SSL3 and RC4 by default
by Jan Kurik
= Proposed System Wide Change: Disable SSL3 and RC4 by default =
https://fedoraproject.org/wiki/Changes/RemoveSSL3andRc4
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.
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
5 years, 10 months
Removing packages that have broken dependencies in F22 tree
by Kalev Lember
Hi all,
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 [1], 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:
Package (co)maintainers
========================================================
Sprog mjakubicek
aeskulap ankursinha, mrceresa, susmit
aunit landgraf
aws landgraf
bro fab, mildew
crystal bnemec, chitlesh
dnssec-check hardaker
dsqlite jouty
florist landgraf
gcc-python-plugin dmalcolm, jakub
gl3n cicku, bioinfornatics
gnatcoll landgraf
kde-style-skulpture jreznik
leksah petersen, haskell-sig
matreshka landgraf
newsx rathann, itamarjp
nifti2dicom dvratil
oozie rrati, coolsvap, moceap
opensips ivaxer, peter
python-sippy peter
quarticurve-kwin-theme kkofler
rss-glx nphilipp, cheese
rubygem-rugged tdawson
spring-maps-default gilboa
syntastic bioinfornatics, praiskup
tango bioinfornatics, cicku
templates_parser oenone, landgraf
vdr-streamdev heffer
vdr-vnsiserver3 bubeck
xavante timn
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.
[1] https://lists.fedoraproject.org/pipermail/devel/2015-April/210201.html
--
Kalev
5 years, 10 months
[Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
by Felix Miata
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/
5 years, 10 months
minimal requirements for subpackage named common
by Jan Chaloupka
Hi,
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?
E.g.
glibc-common provides configuration file, binaries, locales
emacs-common provides binaries, service file, documents, charsets,
images, ...
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.
Kind Regards
Jan
5 years, 10 months
convert program from ImageMagick broken in rawhide?
by Richard Shaw
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)
error.
It looks like the make doc target uses convert for part of the
documentation:
+ 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.
Thanks,
Richard
5 years, 10 months