On 29 April 2017 at 22:30, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> given that i run Fedora fpr a decade on everyting from production servers to
> routers and desktops and reading all of your posts of the last week - well,
> i have no idea what your problem is
Looks like we have completely different jobs .. just accept this.
However this aspect has nothing do with this topic.
I can tell you only that there are plenty of examples where Solaris
even with paid support is cheaper than Linux without support because
in case of Linux to provide the same throughput needs to be used much
more powerful and by this expensive hardware. Many workloads cannot be
horizontally scaled so scaling service with hardware is only solution.
Bigger hardware means not only bigger initial costs but higher costs
of powering and cooling. In case of calculating costs of running
routers or desktops on scale few units I don't think that anyone is
thinking about those costs.
Does it mean that Solaris should be used everywhere? Of course not!!!
It would be idiotic.
But again: this thread is not about me or which OS is better in exact
context but about some exact technical aspects related to PM
technologies. This topic is quite static/parallel/fixed/the same as it
comes to management of some set of files used by running processes and
operating system. As some problems on exactly this area have been
already successfully solved on top of the Solaris there is no reason
to be ashamed telling again "we can do better!".
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
On 29 April 2017 at 19:14, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> but you are coming in several threads and tell everybody that Fedora has to
> be built completly different while the logical answer would be: well, if
> everything in Fedora is not the way you like it then Fedora probably just
> isn't for you?
Is it really so hard to guess that Linux and Solaris have own niches
on OS market and I'm kind of those guys which needs both OSes?
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
gnustep-base must be updated to the release 1.25.0.
I created a buildroot-override
for rebuilding its dependencies so, please, rebuild and commit a new
release of following packages in f26:
unar (successfully rebuilt)
openvpn-auth-ldap (successfully rebuilt)
raidem (rebuild failed)
sagitter AT fedoraproject dot org
See my vCard.
Just letting you all know that as part of the redefinition of
Alternative Architectures we have just enabled the building of s390x
in primary koji. this is the last new architecture we are planning to
enable at this point. s390x will be added to rawhide composes early
next week. If you have any questions or experience any issues and wan
releng to provide assistance, please contact us by one of the
With the import being done now, it has been decided that s390x is too
late for Fedora 26, as such it will be built and shipped from
s390.koji.fedoraproject.org in the Fedora 26 cycle we brought in
aarch64, ppc64 and ppc64le to primary koji. This means that the arm and
ppc koji's will be used for updates until Fedora 25 goes End of Life
and will be shut down at that point. The s390 koji will live on until
Fedora 26 goes EOL.
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything significant to discuss.
If you think there is something we need to discuss, please do reply to
this mail and we can go ahead and schedule the meeting! Thanks.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
On 26/04/17 17:08, Lee Howard wrote:
> On 04/25/2017 01:39 PM, David Sommerseth wrote:
>> This is actually just a very late heads-up about challenges with OpenVPN
>> in Fedora 26.
>> Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane and
>> good step forward. Unfortunately, that gives OpenVPN a real challenge.
>> The OpenSSL v1.1 support is not completed. Patches have been sent to
>> the upstream devel mailing list for review, but only half of them have
>> been processed and applied so far.
>> So, to be able to provide OpenVPN in Fedora 26 it was decided to switch
>> to mbed TLS instead of OpenSSL (which OpenVPN also supports). That have
>> revealed several issues:
>> - mbed TLS 2.3+ does by default not support certificates hashes
>> "older" than SHA1. And RSA keys must be 2048 bits or more.
>> This have been fixed by a couple of additional patches on top
>> of the upstream OpenVPN code base.
> Why is switching to mbed TLS and patching that preferred over just
> patching OpenVPN?
Basically, security - as VPNs are by default security sensitive. The
patches on the OpenVPN mailing list which enables OpenSSL 1.1 support
need to be reviewed properly before we can fully trust them. And
considering that the mbed TLS support have been in OpenVPN for several
years and have also been used by OpenVPN-NL  for a long time, I
consider that approach more secure.
In addition I don't want to maintain what would in effect be a fork of
OpenVPN (even though only for a while). So I follow the common
Red Hat mantra of "upstream first". One upstream have officially
blessed OpenVPN with OpenSSL 1.1, we will pull in the these patches
unless a new v2.4 release is coming. This makes it easier to get
upstream bugs fixed; we don't need to consider if a potential bug is a
result of the un-reviewed OpenSSL patches or not.
Those two patches I have added are basically based upon other patches
under review  (I have been involved in that review too). In addition
a similar approach have been implemented in the OpenVPN 3 core library
 (which is being used by the OpenVPN Connect product range) which
uses the same concept. So I consider those patches less security sensitive.
I've got an idea and I'd like to know an opinion of a wider audience.
Would it make sense to split translations from binary packages to
a noarch subpackage?
For example libreoffice does that already, it even splits the languages
by country, which may or may not be applicable to other (larger)
packages as well.
What this could help with is a save of disk space on the build servers
and mirrors. There might not be any significant difference for users,
due to the main package would require the "langs" subpackage [*]. One
may even avoid multilib issues on translation files (happened in the
past for Evolution due to it removing unused translation strings during
the build, to save package size).
To give an example, I tried this with Evolution package and the result
is that the langs subpackage is ~6MB large, while the main package is
~4MB large. Count that the languages are stored for each architecture,
and koji builds for 6 of them at the moment, then the change of split
means saving 30MB on disk for each single build of Evolution. When
searching koji for Evolution packages then there had been done more
than 70 builds since the first build for Fedora 24 (which is built for
3 arches only), which means more than 1GB on disk (roughly, counting 3
arches only). Multiply this by number of mirrors and so on.
I know I can do this for packages I maintain, but I though it would
make sense to think of it globally. Maybe?
[*] The only difference for users would be to not download languages
again when installing two+ architectures in parallel, thus less data to
download, thus only a benefit for them.