On 2016-06-09 01:18, Jonathan Wakely wrote:
On 09/06/16 08:02 +, Petr Pisar wrote:
That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit
executable without the i686 toolchain packages. It sounds like broken
dependencies.
The alternative would be for gcc.x86_64 to
On Thursday, June 9, 2016 11:28:05 AM CEST Jason L Tibbitts III wrote:
> > "PR" == Pavel Raiskup writes:
> PR> Thanks to Vit for the link, I'd like to see the discussion in:
> PR> https://fedorahosted.org/fpc/ticket/312
>
> Why would you bump a three year old ticket for
> "PR" == Pavel Raiskup writes:
PR> Thanks to Vit for the link, I'd like to see the discussion in:
PR> https://fedorahosted.org/fpc/ticket/312
Why would you bump a three year old ticket for this? Just open a new
one.
- J<
--
devel mailing list
On 2016-06-09, Jonathan Wakely wrote:
> On 09/06/16 08:02 +, Petr Pisar wrote:
>>On 2016-06-08, Jonathan Wakely wrote:
>>> Think about it: you can't build 32-bit software **at all** unless you
>>> install glibc-devel.i686, not even just
Thanks to Vit for the link, I'd like to see the discussion in:
https://fedorahosted.org/fpc/ticket/312
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 09/06/16 08:02 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
On 08/06/16 15:43 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
gcc
On Thu, Jun 09, 2016 at 08:02:55AM +, Petr Pisar wrote:
> > Think about it: you can't build 32-bit software **at all** unless you
> > install glibc-devel.i686, not even just "int main() { }" with no
> > headers at all.
> >
> That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit
>
On 2016-06-08, Jonathan Wakely wrote:
> On 08/06/16 15:43 +, Petr Pisar wrote:
>>On 2016-06-08, Jonathan Wakely wrote:
>>> Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
>>> gcc seems sensible! :-)
>>>
>>Why both
On 08/06/16 17:08 +0100, Jonathan Wakely wrote:
The packaging guidelines say to use BuildRequires to build C and C++
packages. I want to extend those guidelines to say don't add Requires:
gcc just because you isntall headers. That's not confusing or
contradictory.
Basically it seems like you
On Wed, Jun 08, 2016 at 05:08:30PM +0100, Jonathan Wakely wrote:
> On 08/06/16 15:43 +, Petr Pisar wrote:
> >On 2016-06-08, Jonathan Wakely wrote:
> >>Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
> >>gcc seems sensible! :-)
> >>
> >Why both
On 08/06/16 15:43 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
gcc seems sensible! :-)
Why both gcc.i686 and gcc.x86_64 are available in the x86_64 repository?
Shouldn't
On 2016-06-08, Jonathan Wakely wrote:
> On 08/06/16 15:21 +0100, Jonathan Wakely wrote:
>>I think -devel packages should not "Require: gcc" at all. Not with
>>%_isa and not without it.
>>
>>To actually compile something using those headers you need the C (or
>>C++)
On 2016-06-08, Jonathan Wakely wrote:
> Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
> gcc seems sensible! :-)
>
Why both gcc.i686 and gcc.x86_64 are available in the x86_64 repository?
Shouldn't gcc.i686 be expelled from the x86_64 repository?
On 06/08/2016 10:21 AM, Jonathan Wakely wrote:
>> If this is so, I will go to FPC with request the ammend the C guidelines
>> with explicit discourage of %{?_isa} on gcc because the main
>> architecture supports the secondary targets and because gcc is not
>> multilib safe.
>
> I think -devel
On 08/06/16 12:00 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
On 08/06/16 08:38 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
On 08/06/16 07:37 +, Petr Pisar wrote:
Guidelines require devel
On 08/06/16 15:21 +0100, Jonathan Wakely wrote:
I think -devel packages should not "Require: gcc" at all. Not with
%_isa and not without it.
To actually compile something using those headers you need the C (or
C++) build environment installed anyway, i.e. you need 'gcc' (or
'gcc-c++') installed
On 2016-06-08, Jonathan Wakely wrote:
> On 08/06/16 08:38 +, Petr Pisar wrote:
>>On 2016-06-08, Jonathan Wakely wrote:
>>> On 08/06/16 07:37 +, Petr Pisar wrote:
Guidelines require devel packages to be architecture specific (no
On 08/06/16 08:38 +, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely wrote:
On 08/06/16 07:37 +, Petr Pisar wrote:
Guidelines require devel packages to be architecture specific (no
BuildArch: noarch). Guidelines require having dependencies between
On Wed, Jun 08, 2016 at 08:38:48AM +, Petr Pisar wrote:
> Because "#include " fails without stdlib.h on the system,
> you need to depend on something that provides the stdlib.h. And
> guidelines says the provider is "gcc".
gcc doesn't provide stdlib.h, glibc-headers does. But even for the
On 2016-06-08, Jonathan Wakely wrote:
> On 08/06/16 07:37 +, Petr Pisar wrote:
>>Guidelines require devel packages to be architecture specific (no
>>BuildArch: noarch). Guidelines require having dependencies between
>>architecture specific packages restricted to the
On 08/06/16 07:37 +, Petr Pisar wrote:
Guidelines require devel packages to be architecture specific (no
BuildArch: noarch). Guidelines require having dependencies between
architecture specific packages restricted to the architecture
(Requires: foo-devel%{?_isa}). C guildelines require
I pursued this once before:
https://fedorahosted.org/fpc/ticket/312
but failed to propose the draft. But still, it would be much better if
this can be resolved on gcc side:
https://bugzilla.redhat.com/show_bug.cgi?id=979403
Vít
Dne 7.6.2016 v 17:30 Pavel Raiskup napsal(a):
> Just wanted to
On 2016-06-07, Pavel Raiskup wrote:
> Just wanted to ping here about one packaging helper [1], which is stuck in
> some (possibly infinite/priority) queue without any review.
>
> In database packages we have that multilib hack for a very long time,
> mostly C'ed among various
On 06/07/2016 11:03 PM, Jan Kratochvil wrote:
On Tue, 07 Jun 2016 17:30:58 +0200, Pavel Raiskup wrote:
In database packages we have that multilib hack for a very long time,
mostly C'ed among various spec files.
#if defined(__x86_64__)
#include "${filename}${opt_additional_suffix}_x86_64.h"
On Tue, 07 Jun 2016 17:30:58 +0200, Pavel Raiskup wrote:
> In database packages we have that multilib hack for a very long time,
> mostly C'ed among various spec files.
#if defined(__x86_64__)
#include "${filename}${opt_additional_suffix}_x86_64.h"
#elif defined(__i386__)
#include
Also, if there is any point in having a packaging guideline for this,
please submit a draft to FPC. I think I'd want to see how often it
actually helps to have a standardized/mandated way of doing this before
we go that far, though. (It's not particularly difficult to make that
argument but
On Tue, 07 Jun 2016 17:30:58 +0200
Pavel Raiskup wrote:
> Just wanted to ping here about one packaging helper [1], which is
> stuck in some (possibly infinite/priority) queue without any review.
>
> In database packages we have that multilib hack for a very long time,
>
Just wanted to ping here about one packaging helper [1], which is stuck in
some (possibly infinite/priority) queue without any review.
In database packages we have that multilib hack for a very long time,
mostly C'ed among various spec files. Having this in redhat-rpm-config
could make that more
28 matches
Mail list logo