Hi
During last few days I fetched over 26 thousand of Fedora package repositories. Plan to go though all spec files and submit some patches mainly related to my aarch64 work.
We live in a world where most of Linux systems are either 32 or 64 bit. But do you know how many 64-bit architectures Fedora and RHEL have?
According to spec files we have at least 8 while current Fedora has 1 primary and 4 secondary ones.
x86-64 is main one which most of developers use for everything aarch64 is my favourite secondary one ppc64 is probably fastest one ppc64le is little endian version of previous s390x is fridge size mainframe (is such small exist)
Specs also mention ia64 (not supported Itanium), alpha (I have some friends who still own them but do not run), sparc64/sparcv9 (even Debian got rid of sparc support).
But why I write?
Because there are lot of code like:
%ifarch x86_64 ppc64 ia64 s390x sparc64 USE_64=1 %endif
Where is should be:
%if 0%{?__isa_bits} == 64 USE_64=1 %endif
Which works since RHEL6 (from what I know). And it automatically covers all 64-bit architectures not only those which maintainer remembers.
So please do me a favour and take a look at your packages and adapt their spec files. Otherwise sooner or later such patch may land in bugtracker but instead I could fix some other package at same time.
On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz <mjuszkiewicz@redhat.com
wrote:
Hi
During last few days I fetched over 26 thousand of Fedora package repositories. Plan to go though all spec files and submit some patches mainly related to my aarch64 work.
We live in a world where most of Linux systems are either 32 or 64 bit. But do you know how many 64-bit architectures Fedora and RHEL have?
According to spec files we have at least 8 while current Fedora has 1 primary and 4 secondary ones.
x86-64 is main one which most of developers use for everything aarch64 is my favourite secondary one ppc64 is probably fastest one ppc64le is little endian version of previous s390x is fridge size mainframe (is such small exist)
Specs also mention ia64 (not supported Itanium), alpha (I have some friends who still own them but do not run), sparc64/sparcv9 (even Debian got rid of sparc support).
But why I write?
Because there are lot of code like:
%ifarch x86_64 ppc64 ia64 s390x sparc64 USE_64=1 %endif
Where is should be:
%if 0%{?__isa_bits} == 64 USE_64=1 %endif
Which works since RHEL6 (from what I know). And it automatically covers all 64-bit architectures not only those which maintainer remembers.
So please do me a favour and take a look at your packages and adapt their spec files. Otherwise sooner or later such patch may land in bugtracker but instead I could fix some other package at same time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib.
You just made my day.
W dniu 24.08.2015 o 15:18, Neal Gompa pisze:
Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib.
You just made my day.
You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 on 64bit.
On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib.
You just made my day.
You should not really assume that all 64-bit architectures use /usr/lib64 either - %{_libdir} expands to the right directory path per architecture.
Regards, Daniel
On Mon, Aug 24, 2015 at 9:26 AM, Marcin Juszkiewicz <mjuszkiewicz@redhat.com
wrote:
W dniu 24.08.2015 o 15:18, Neal Gompa pisze:
Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib.
You just made my day.
You know that %_libdir is what you want? /usr/lib on 32bit, /usr/lib64 on 64bit.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I'm well aware. The buildsystem is fine. It's the code that's the problem.
On Mon, Aug 24, 2015 at 9:27 AM, Daniel P. Berrange berrange@redhat.com wrote:
On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
Oh, yes! I was trying to find something like this all weekend for my
Copr
for reprepro. I have to make a patch to access apt-methods in /usr/lib64
on
64-bit systems, but on 32-bit systems it should remain /usr/lib.
You just made my day.
You should not really assume that all 64-bit architectures use /usr/lib64 either - %{_libdir} expands to the right directory path per architecture.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Well, the problem is that the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
[0]: http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.git/...
On 24/08/15 09:31 -0400, Neal Gompa wrote:
Well, the problem is that the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler flags.
On 24/08/15 14:39 +0100, Jonathan Wakely wrote:
On 24/08/15 09:31 -0400, Neal Gompa wrote:
Well, the problem is that the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler flags.
Oops, to keep the quotes it would be
-DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely jwakely@redhat.com wrote:
On 24/08/15 14:39 +0100, Jonathan Wakely wrote:
On 24/08/15 09:31 -0400, Neal Gompa wrote:
Well, the problem is that the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
[0]:
http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/mirrorer/reprepro.git/...
You could add -DSTD_METHOD_DIR=%{_libdir}/apt/methods to the compiler flags.
Oops, to keep the quotes it would be
-DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Would that override the in-code #define statement?
On 24/08/15 10:06 -0400, Neal Gompa wrote:
On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely jwakely@redhat.com wrote:
Oops, to keep the quotes it would be
-DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
Would that override the in-code #define statement?
Yes, because the #define is guarded by:
#ifndef STD_METHOD_DIR
so if it's defined on the command line then it won't get defined in main.c
But whether you alter the #define in main.c or set it on the command-line, using %{_libdir} seems better than /usr/lib64.
On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely jwakely@redhat.com wrote:
On 24/08/15 10:06 -0400, Neal Gompa wrote:
On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely jwakely@redhat.com wrote:
Oops, to keep the quotes it would be
-DSTD_METHOD_DIR='"%{_libdir}/apt/methods"'
Would that override the in-code #define statement?
Yes, because the #define is guarded by:
#ifndef STD_METHOD_DIR
so if it's defined on the command line then it won't get defined in main.c
But whether you alter the #define in main.c or set it on the command-line, using %{_libdir} seems better than /usr/lib64.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How do I append to the CFLAGS at the %configure statement?
Am 24.08.2015 um 16:27 schrieb Neal Gompa:
On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely <jwakely@redhat.com mailto:jwakely@redhat.com>wrote:
On 24/08/15 10:06 -0400, Neal Gompa wrote: On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely <jwakely@redhat.com <mailto:jwakely@redhat.com>> wrote: Oops, to keep the quotes it would be -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"' Would that override the in-code #define statement? Yes, because the #define is guarded by: #ifndef STD_METHOD_DIR so if it's defined on the command line then it won't get defined in main.c But whether you alter the #define in main.c or set it on the command-line, using %{_libdir} seems better than /usr/lib64.
How do I append to the CFLAGS at the %configure statement?
you don't need
export CFLAGS="%{optflags} yourstuff" export CXXFLAGS="%{optflags} yourstuff" %configure ...............
P.S.: please don't quote the list-footer
On Mon, Aug 24, 2015 at 10:31 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 24.08.2015 um 16:27 schrieb Neal Gompa:
On Mon, Aug 24, 2015 at 10:15 AM, Jonathan Wakely <jwakely@redhat.com mailto:jwakely@redhat.com>wrote:
On 24/08/15 10:06 -0400, Neal Gompa wrote: On Mon, Aug 24, 2015 at 9:41 AM, Jonathan Wakely <jwakely@redhat.com <mailto:jwakely@redhat.com>> wrote: Oops, to keep the quotes it would be -DSTD_METHOD_DIR='"%{_libdir}/apt/methods"' Would that override the in-code #define statement? Yes, because the #define is guarded by: #ifndef STD_METHOD_DIR so if it's defined on the command line then it won't get defined in main.c But whether you alter the #define in main.c or set it on the command-line, using %{_libdir} seems better than /usr/lib64.
How do I append to the CFLAGS at the %configure statement?
you don't need
export CFLAGS="%{optflags} yourstuff" export CXXFLAGS="%{optflags} yourstuff" %configure ...............
P.S.: please don't quote the list-footer
Thanks.
W dniu 24.08.2015 o 15:31, Neal Gompa pisze:
Well, the problem is that the path to apt-methods is hardcoded in reprepro itself. Thankfully, it's in a #define, but I don't know of a good way to fix it beyond just replacing the #define for 64-bit systems. If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
At end of %setup add:
sed -i -e 's+/usr/lib+%{_libdir}+g' main.c
and it will replace /usr/lib with proper value on both 32 and 64 bit.
Hi,
If someone can suggest a better way than how I'm doing it now, I'm all ears, because I hate this patch[0].
I think the solution you came up with from this thread is okay as a downstream hack, but I think a better solution would be to get upstream to ask apt at built time where to put methods. It seems apt has an "apt-config" binary for this:
$ apt-config dump |grep Dir::Bin::methods Dir::Bin::methods "/usr/lib64/apt/methods";
So there's no reason this needs to be hardcoded at all.
Even better would be if apt would ship this information in it's pkgconfig file, then it could be queried using pkg-config.
--Ray
On Monday, August 24, 2015 09:18:16 AM Neal Gompa wrote:
On Mon, Aug 24, 2015 at 9:12 AM, Marcin Juszkiewicz <mjuszkiewicz@redhat.com
<snip>
Oh, yes! I was trying to find something like this all weekend for my Copr for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on 64-bit systems, but on 32-bit systems it should remain /usr/lib.
That is actually an inappropriate way to work out libbdir tyou should use the %{_libdir} macro, some 64 bit platforms, alpha for instance and I thionk ia64 from memory use /usr/lib as they are 64 bit only arches.
Dennis
On 24 August 2015 at 14:12, Marcin Juszkiewicz mjuszkiewicz@redhat.com wrote: [snip]
Because there are lot of code like:
%ifarch x86_64 ppc64 ia64 s390x sparc64 USE_64=1 %endif
Where is should be:
%if 0%{?__isa_bits} == 64 USE_64=1 %endif
Which works since RHEL6 (from what I know). And it automatically covers all 64-bit architectures not only those which maintainer remembers.
It would be worthwhile adding this to:
https://fedoraproject.org/wiki/Packaging_tricks
Cheers, Jonathan.
W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:
It would be worthwhile adding this to:
Added
On Mon, Aug 24, 2015 at 06:02:35PM +0200, Marcin Juszkiewicz wrote:
W dniu 24.08.2015 o 16:09, Jonathan Underwood pisze:
It would be worthwhile adding this to:
Added
Is there an analagous macro for "all little endian arches"? This would be useful for the msed package.