ARM and AArch64 GCC 7.1 ABI change
by Jakub Jelinek
Hi!
A severe ABI bug on AArch64 and especially on ARM 32-bit has been
recently discovered and GCC 7.1 is going to have that ABI change in.
For details see http://gcc.gnu.org/PR77728
gcc-7.1.1-0.16.fc{26,27} which I'll build tomorrow will contain the
ABI changes as well as a -Wpsabi diagnostics (note:) on code that is
changing the ABI.
The ABI change should affect primarily just C++ code passing PODs
by value where all the non-static data members and base classes are at most
word aligned, but there are some static data members with doubleword
or bigger alignment or there are typedefs or other nested types in
the class/struct which are doubleword or bigger aligned, and are passed
in certain positions in the argument list (passing them in even registers
is fine, passing them in odd ones changes ABI, on the stack at odd positions
might change the ABI too). For the typedefs, the broken ABI of GCC 5.2 to 7.0.1
has been actually not even self-consitent in some templates, earlier
instantiation vs. lack thereof could affect the ABI. GCC 5.1 and earlier
for structs used to match earlier AAPCS version and had different rules and
issues.
Could somebody from rel-eng perform a test mass rebuild on armv7hl
and aarch64 of F26 to determine which packages are affected by the
ABI changes so that we could rebuild only those that actually need changing?
If grepping for note: is not good enough for the test mass rebuild, I could
hack up a test compiler that does something different when it encounters
this (say abort if it encounters this and some special env var is set,
or writes something into some /tmp/ file and let some brp script collect
info from there, etc.).
Jakub
6 years, 11 months
[RFC] delta-repository-metadata
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello users and developers,
We had presented deltametadata project at DevConf.CZ 2017[0], goal of
this project is to minimize bandwidth required on clients to update
repository metadata (repomd.xml, primary.xml, etc.) which would improve
user experience with DNF.
So, we have DNF plugin which acts
How to try it?
1. dnf -y copr enable @rpm-software-management/deltamd
2. dnf -y install dnf-plugin-zsync
If something doesn't work, look into /var/log/dnf.log.
We would like you to try it out and give feedback, it is very important
for us! Just send it as reply to this message..
P.S. F25 and above are supported
[0] https://www.youtube.com/watch?v=l6uWxg3yMmw
- --
Regards,
lab-q Red Hat
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkCJAoACgkQaVcUvRu8
X0wrGg/+Lvb/up8swQR6Nd9BacvrubhgELvOcOIsv/69aMPqe9cDqmAKUr33AWik
zUWbAwpkS79BLLKjoxHTxR379Ubmj5mCWyuufg/HCgeCHOZwIBEQzqrBjwKMsIN+
ts6Qk7mo1bsgS3xozx/tRH+N1xhx1O+UInsDxS1qKQ5KIBntf/e8ZrgFL/fbjHYx
/JVlz2p44tZxMHCsZP/hJv+DKV+AaY9/NcvLh2KBvpj75h8cVA3RkSE85YgNFNyD
GJRjkzv+swmwWXVZMd0XNiCKKXn+qGooMsrrjAmbousG/Gd/DmTQekuO/hIkGZ+g
rjSCPRjLXe+utD2lnqK5aWm1nJvaEUTjTAWKYAhV0mAAT/Y4Y8S2XcsdY6EXxiW6
iSYmXa4Rz4rTYiZ+K2XXYoEIGDVSN8C5lQyYy4Qqg2lnAyKDZ1567s/4fCz/IYpB
rpDv+4jX1o3C8RY0XUuCYkt+/IpVH+1/DfkhWJCG2rNLDpnq5R7N4cryJg0MClW1
PUw24GJFbIwWnl6he0n+ShJ6wzZvd2jHwFBVj5a/718wech3YnIfSHf/xJeIE6Nn
dK716wgmHUPyjCwk/cWQWdj5x99lMiDZJIXXFTu0zGLxXcHzz9MnZjDCv219u6XU
Vj0dCKWa3SoLml+zmRkqb+T4acyyXlwPBahRFXN3qBhFpqoA/MY=
=5ar8
-----END PGP SIGNATURE-----
6 years, 11 months
Re: Split translations to noarch packages?
by Tomasz Kłoczko
On 27 April 2017 at 21:54, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> Am 27.04.2017 um 21:50 schrieb Tomasz Kłoczko:
>>
>> OK so what kind of problem solves those changes? Can I have look on some
>> bugzilla entry?
>
> split packages where it *really* matters instead create thousands of small
> rpm packages where the metadata and overhead is much larger than the few
> bytes in the standard package?
So far *only* argument was that his split may save ~1GB on ftp server.
[mode=sarcastic]
If Fedora Foundation is in so big financial troubles I can donate 1GB
SD card out of my pocket (probably 2-3 pounds with delivery to US).
Just please give me address where this card needs to be delivered.
[/mode]
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
6 years, 11 months
Re: DNF translation
by Rafal Luzynski
I think that developers should be asked this question.
As DNF is a software originally made by Fedora people
I think it's correct to crosspost to devel@fpo hoping to
get an answer from the DNF authors or at least from
somebody who can explain what they meant.
Just to summarize the story: somebody please explain
us what is "a payload factory" in this context.
Regards,
Rafal
29.04.2017 03:07 Daniel López <protoanima(a)hotmail.com> wrote:
>
>
> sometimes payload is used as capacity
>
>
>
> i think it means the number exceeds the capacity for , lets say, certain
> number of packages.
>
>
>
> Not really sure. Have you solved it already?
>
>
>
>
>
>
> ---------------------------------------------
> De: Máximo Castañeda <mcrcctm(a)gmail.com>
> Enviado: miércoles, 12 de abril de 2017 07:30:11 a. m.
> Para: Fedora Translation Project List
> Asunto: Re: DNF translation
>
> FWIW, I've translated it to something that back in English would be
> like "no data manager found for %s". From the code[1], it looks like
> there are different types of repos or downloadable "stuff" (payload),
> that can each have a different "manager" (factory), such as a normal
> rpm and a deltarpm.
>
> [1]
> https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104
> https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104
>
> 2017-04-12 13:39 GMT+02:00 Zdenek Chmelar <chmelarz(a)gmail.com>:
> > Hello all
> >
> > The DNF project has one sentence which I'm not able to reasonably
> > translate. I think I do not understand the sentence meaning properly. I
> > have checked French and German translations in order to understand the
> > meaning better but those languages didn't translate that sentence yet.
> >
> > So what's the magic sentence I speak about?
> > "no matching payload factory for %s" (message with number #547)
> >
> > If anyone could explain what means "payload factory" in relation to DNF, I
> > would be very thankful ;-)
> >
> > Thanks
> > Z.
> > _______________________________________________
> > trans mailing list -- trans(a)lists.fedoraproject.org
> > To unsubscribe send an email to trans-leave(a)lists.fedoraproject.org
> _______________________________________________
> trans mailing list -- trans(a)lists.fedoraproject.org
> To unsubscribe send an email to trans-leave(a)lists.fedoraproject.org
>
> _______________________________________________
> trans mailing list -- trans(a)lists.fedoraproject.org
> To unsubscribe send an email to trans-leave(a)lists.fedoraproject.org
>
6 years, 11 months
Re: What is your opinion on "sudo pip" fix for Fedora 27?
by Charalampos Stratakis
Forwarding to fedora-devel as well
Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat
----- Original Message -----
From: "Michal Cyprian" <mcyprian(a)redhat.com>
To: python-devel(a)lists.fedoraproject.org
Sent: Wednesday, April 26, 2017 11:19:00 AM
Subject: What is your opinion on "sudo pip" fix for Fedora 27?
At the present time, running sudo pip3 in Fedora is not safe.
Pip shares its installation directory with dnf, can remove
dnf-managed files and generally break the Python 3 interpreter.
Our first attempt to make sudo pip safe on Fedora [0] was
based on using a different binary (/usr/libexec/system-python)
for RPM packaging purposes and changing the behavior
of /usr/bin/python3 (and pip that uses its settings) to install
under /usr/local by default. Switching all the Python 3 packages
to system-python turned out to be much more problematic than
expected and we had to postpone the Change for F27.
We decided to try a different approach. The main idea is to detect
an ongoing RPM build and modify the behavior of the Python 3
executable only when in normal user environment so that RPM builds
won't be affected at all.
The adjustment of the behavior can be done on different levels.
The first option is to set the sys.prefix variable to /usr/local
when the interpreter is initialized. This will affect
all the install methods, but the solution can cause some
problems in applications that rely on the value of sys.prefix.
A prototype of this implementation can be seen here [1].
The other possibility is to limit the pip install location change
to distutils and pip [2]. This is the "safer" option, but does
not cover all corner cases. For example, Python software built
locally using cmake or similar tools will be installed into
/usr/lib and can conflict with system tools. Debian chose to
implement similar solution.
I would like to ask which solution would work for your applications
better, and what is in your opinion the right way to go. I will
appreciate any costructive comments or ideas on how to improve these
patches. If you want to check some specific use-case you can use the images
docker.io/mcyprian/sudo_pip_sys_prefix and
docker.io/mcyprian/sudo_pip_install_prefix
to try out the two mentioned implementations.
[0] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsa...
[1] https://github.com/mcyprian/python3/commit/6077c96460c03ddc334bae654fffcc...
[2] https://github.com/mcyprian/python3/commit/ac2f266a90871d67ba8d0b70d2b0eb...
Michal Cyprian
_______________________________________________
python-devel mailing list -- python-devel(a)lists.fedoraproject.org
To unsubscribe send an email to python-devel-leave(a)lists.fedoraproject.org
6 years, 11 months
OpenVPN, OpenSSL and Fedora 26+
by David Sommerseth
Hi,
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. It supports now RSA keys
of 1024 bits or more. In addition for OpenSSL support of the
OPENSSL_ENABLE_MD5_VERIFY, a quirk have been added to also enable
MD5 support if that environment variable have been set.
- mbed TLS build in Fedora lacked PKCS#11 support. This have
been resolved. But there are concerns how well this plays along
with another dependency OpenVPN have, pkcs11-helper. This is being
investigated and tested. Feel free to help out on bz #1432152 if
you depend on PKCS#11/Smart Card functionality. Your feedback is
valuable!
- mbed TLS completely lacks support for PKCS#12 files.
Now, there is kind of an alternative by using compat-openssl-10. But
that does not play well with pkcs11-helper; which is compiled against
OpenSSL v1.1.
Currently the plan is to stay with mbed TLS support until PKCS#11
support is fully confirmed working or not working at all. If not
working, we can at least move to compat-openssl10 without PKCS#11
support, which enables PKCS#12 support again. If PKCS#11 support works
with mbed TLS, then we will stay on mbed TLS for now as I value that
support more important than PKCS#12.
Once OpenVPN have released a version with full OpenSSL v1.1 support (or
at least have all the needed patches reviewed and applied to their
upstream git repos), then I will switch back to the default openssl
package again.
This is far from ideal. But I do consider this the best compromise than
not having an OpenVPN package in Fedora 26 at all.
For those of you having PKCS#12 files, there is a kind of workaround
where you can split up that file into CA, Certificate and Private Key
PEM files - which OpenVPN can use directly.
$ openssl pkcs12 -nokeys -cacerts -in $PKCS12FILE > ca-cert.pem
$ openssl pkcs12 -nokeys -clcerts -in $PKCS12FILE > cert.pem
$ openssl pkcs12 -nocerts -nodes -in $PKCS12FILE > private-key.pem
If switching from '-nodes' with for example '-aes256' on the last line,
the private key will be encrypted and password protected; similar to
what your PKCS#12 files may already use today.
I am sorry for not having sent this heads-up earlier. I took over
package maintenance mid-March, and I've taken this package through a
very much needed overhaul to align the packaging with improvements in
the upstream packaging. The previous maintainers have done a good job
keeping this package alive, but the gap against upstream began to be a
bit too big. There are still a few things which needs to be ironed out.
But once the mbed TLS/OpenSSL issue and a few other more minor issues
gets resolved, I'd say we're pretty much in a reasonable shape.
If you have questions, issues or comments ... feel free to reach out!
--
kind regards,
David Sommerseth
6 years, 11 months
mc 4.8.19-1 broken
by josef radinger
Hi
Could someone with write-access to mc solve
https://bugzilla.redhat.com/show_bug.cgi?id=1442842
we currently have a situation where users accidentally might delete
data. The situation is a mess. mc 4.8.19-1 changed from curses to slang
and now several keybindings are plain wrong for at least fedora 25 and
maybe fedora 24, too.
yours
josef
6 years, 11 months
