Re: PPC/PPC64 disabled in Koji for dist-f13
On 10/05/2009 04:13 PM, Josh Boyer wrote: On Mon, Oct 05, 2009 at 03:46:52PM +0200, Roman Rakus wrote: On 09/29/2009 04:48 PM, Josh Boyer wrote: On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh Any idea when I will be able to build them? Is there any bug report or I can build the for you for now if you just point out which ones you want built. The setup I have isn't publicly accessible yet (details on fedora-ppc list). something like it? No, no bug report per se. josh Many thanks. Let's move this discussion to fedora-ppc-list. RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Oct 05, 2009 at 03:46:52PM +0200, Roman Rakus wrote: > On 09/29/2009 04:48 PM, Josh Boyer wrote: >> On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: >> >>> On 09/29/2009 12:31 AM, Jesse Keating wrote: >>> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: > What do we have to do in order to build on PPC? Does it happen > automagically? > > Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. >>> What about ppc specific packages (with exclusive arch set to ppc/ppc64)? >>> >> What about them? They can exist in the CVS repo. You just won't be able to >> build them in koji for F-13 until a secondary arch instance is going. >> >> josh >> >> > Any idea when I will be able to build them? Is there any bug report or I can build the for you for now if you just point out which ones you want built. The setup I have isn't publicly accessible yet (details on fedora-ppc list). > something like it? No, no bug report per se. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/29/2009 04:48 PM, Josh Boyer wrote: On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh Any idea when I will be able to build them? Is there any bug report or something like it? Thanks. RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
2009/10/1 Josh Boyer :
> On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote:
>>Nice bug; this one is my favourite:
>>https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
>>don't expand %{_libdir} to the correct place.
>
> I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}'
> repeated several times.
>
Eclipse is an archful package and that plonks files in %{_libdir} that
are needed during the build of plugins that may or may not be noarch.
--
Mat Booth
A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote:
>Nice bug; this one is my favourite:
>https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
>don't expand %{_libdir} to the correct place.
I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}'
repeated several times.
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
John Reiser writes: > The IXP4xx networking engine operates big endian only. Nevertheless > many NSLU2 machines run little-endian and still use that networking > hardware. With a performance penalty since all buffers have to be swapped. > Little- > endian operation of the CPU offers the advantage that an unaligned > fetch from memory gives results that are usable after quick fixup. > An unaligned fetch in big-endian mode essentially gives junk. Both BE and LE obviously have advantages and disadvantages. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 11:00, Tom Lane wrote:
Mat Booth writes:
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
You absolutely *cannot* build Eclipse plugins on ppc64 hosts because
of this beauty. The current workaround is to just keep resubmitting
the build until Koji picks an i386, x86_64 or ppc host. (Nothing to
do
with Eclipse either, BTW, seems like an RPM or mock problem.)
Sweet ... and of course removing PPC64 from the primary arch set does
nothing to help you on this, since those machines are still in the
build
farm, and will have to stay there for at least another year to support
F11/F12.
Actually when removed as a primary arch I do believe no build will be
done (even noarch) on a ppc builder. It cannot init a buildroot as
there are no archful packages for ppc.
--
Jes
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Mat Booth writes:
> Nice bug; this one is my favourite:
> https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
> don't expand %{_libdir} to the correct place.
> You absolutely *cannot* build Eclipse plugins on ppc64 hosts because
> of this beauty. The current workaround is to just keep resubmitting
> the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do
> with Eclipse either, BTW, seems like an RPM or mock problem.)
Sweet ... and of course removing PPC64 from the primary arch set does
nothing to help you on this, since those machines are still in the build
farm, and will have to stay there for at least another year to support
F11/F12.
regards, tom lane
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
2009/10/1 Kevin Kofler :
> Jeff Garzik wrote:
>> Was ppc really such a burden?
>
> Yes. It slowed down builds, and it often triggered bizarre build failures
> which were NOT bugs in the program, but in the toolchain or in some core
> library like glibc, which in turn delayed important updates to the affected
> packages.
>
> In fact, my "favorite" ppc64 issue was a problem with OpenBabel hitting a
> limitation in the ppc64 toolchain: there's a "table of contents" which can
> grow only to a small fixed size, so large compilation units just don't
> compile on ppc64, while being perfectly valid C/C++ and compiling fine on
> all other architectures. (And that's already with the "minimal TOC". Without
> it, the limit is for the whole executable!) OpenBabel's SWIG-generated
> bindings exceeded that limit. We were the only ones hitting it as no other
> distribution is insane enough to build their packages for ppc64. (The
> binaries don't even get actually used as ppc32 is the preferred multilib on
> 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce
> the amount of TOC entries, which worked for 2 beta releases (requiring
> additional tweaking for the second one), but then it overflowed again. This
> was a big annoyance because the new OpenBabel betas were required for new
> kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream
> removed some things from their bindings to get them to build, a quite
> suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs
> to be redesigned from scratch.
>
> Kevin Kofler
>
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
You absolutely *cannot* build Eclipse plugins on ppc64 hosts because
of this beauty. The current workaround is to just keep resubmitting
the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do
with Eclipse either, BTW, seems like an RPM or mock problem.)
--
Mat Booth
A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 1, 2009 at 10:45 AM, Jesse Keating wrote: >> I know that last week several ppc people (IBM, etc) expressed alarm and >> concern about the demotion of ppc to a secondary arch. Most of those people >> I pointed at Bill and Jesse who were staffing the fedora booth. >> >> Did we get any positive feedback/offers of help from them? >> >> Ric >> >> > > > No. They heard that here would be a secondary arch effort and seemed to > think "oh, they will fix it for us". Seems to be the running theme. People > want ppc to stick around but nobody wants to work on it. That's why > secondary arch seems right. People who care can work on it but lack of care > won't hold Fedora back. Keep in mind that many upstreams (most?) don't have > access or care about ppc. In the nonserver world ppc is dead. > That is sadly true, even of Apple (PPC support is dropped from Snow Leopard, and their LLVM framework is more buggy on PPC -- fastcall does not work, etc. A lot of maintainers probably do care that their software does not have broken assumptions about endianness, so it would be nice that, for a given package N-V-R, we can see both the primary and secondary Kojis' build results. Regards, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 11:10:51AM -0400, Bill Nottingham wrote: >Jeff Garzik (jgar...@pobox.com) said: >> But you're dodging the larger point -- Fedora has, de facto, demoted >> big endian support in its entirety to a second-hand effort, rather >> than distributed the workload much more widely. Given M package >> maintainers and N secondary-platform volunteers, it is clear M > N >> by orders of magnitude. > >Sure, but it's not like M, in a sizeable percentage of cases, is particularly >useful in this regard. > >In any case: > >- ppc has no one looking at the actual bugs in any case. LiveCDs have > been broken on PPC for *years*, for example, and no one cares. Graphics > drivers have been broken on PPC throughout the F11 release and no one > cares. Going to counter this one. I look at bugs. I know David look(s/ed) at bugs. We just can't get to all of them. This echos your point about community, but I didn't want you to get away with saying that nobody is trying. LiveCDs are pretty useless because demand for them is non-existent. So yes, it is broken and I don't think it works even after some of the recent fixes I sent to livecd-tools. So yeah, no one cares on that. I know I don't, mostly because I'm actually busy with the other stuff. I file bugs on graphics drivers regularly. I know Dave A has been pretty great about helping me get him info to fix the Radeon stuff. I have a bug opened against nouveau right now as well and Ben has been helpful there too (need to get back to that.) If you mean some other driver, then yeah maybe. I can only test/file bugs on hardware I have. >that; well, I don't think Fedora necessarily should be a charity for cases >there's no community for. s/no/a small. Pretending we don't exist isn't exactly kind, but I will admit the few of us that participate are limited in time and resources. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik (jgar...@pobox.com) said: > But you're dodging the larger point -- Fedora has, de facto, demoted > big endian support in its entirety to a second-hand effort, rather > than distributed the workload much more widely. Given M package > maintainers and N secondary-platform volunteers, it is clear M > N > by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has very few users. This is demonstratable by smolt stats and download stats. - ppc has declining hardware availability, unless you're counting increased scavenging via dumpsters. - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. In essence, if the bug doesn't affect the build or install environment, it *doesn't get noticed*, in most regards. > Given that ppc32 and ppc64 (or pick your BE platform) have > demonstrated an ability to detect problems not found on LE, it seems > like this policy change will directly lead to missed bugs, and an > attendent decline in software quality. If you feel that this is the case, *step up and join the PPC secondary arch effort*. They could use the help. But I don't see the logic in making Fedora a charity case. As to the RHEL argument, well, that's a RHEL problem. If Red Hat (or anyone, really) feels that it's worth a significant effort to have an up-to-date, maintained, PPC tree, then they should pony up for that effort. Saying "Fedora should do this!" and not providing real resources to accomplish that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 7:58, Josh Boyer wrote: On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? No. They heard that here would be a secondary arch effort and seemed to think "oh, they will fix it for us". Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). Fair point! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: >> I know that last week several ppc people (IBM, etc) expressed alarm >> and concern about the demotion of ppc to a secondary arch. Most of >> those people I pointed at Bill and Jesse who were staffing the fedora >> booth. >> >> Did we get any positive feedback/offers of help from them? >> > > > No. They heard that here would be a secondary arch effort and seemed to > think "oh, they will fix it for us". Seems to be the running theme. > People want ppc to stick around but nobody wants to work on it. That's > why secondary arch seems right. People who care can work on it but lack > of care won't hold Fedora back. Keep in mind that many upstreams (most?) > don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 6:49, Ric Wheeler wrote: On 09/30/2009 08:47 PM, Jesse Keating wrote: On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric No. They heard that here would be a secondary arch effort and seemed to think "oh, they will fix it for us". Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Matej Cepl wrote: > I.e., it was discovering bugs ... not in your program but in glibc, gcc, > etc. (I have experienced this couple of times with pspp on Sparc). But usually in target-specific code. Plus, it's not the toolchain's updates which get stalled, but the updates for some package which just happens to trigger the toolchain bug. Having the arches be secondary allows to at least proceed with building things on the primary arches while the bug on the secondary arch is being fixed. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/30/2009 08:47 PM, Jesse Keating wrote: On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 10/01/2009 04:54 AM, Krzysztof Halasa wrote: "Richard W.M. Jones" writes: Is ARM big endian? It can be either. Intel's IXP4xx networking chips are usually running BE since their internal network engines are BE-only and it's thus more efficient. The IXP4xx networking engine operates big endian only. Nevertheless many NSLU2 machines run little-endian and still use that networking hardware. Current and future Debian releases for ARM (which is a top-tier architecture on Debian) are little-endian only. Little- endian operation of the CPU offers the advantage that an unaligned fetch from memory gives results that are usable after quick fixup. An unaligned fetch in big-endian mode essentially gives junk. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
"Richard W.M. Jones" writes: > Is ARM big endian? It can be either. Intel's IXP4xx networking chips are usually running BE since their internal network engines are BE-only and it's thus more efficient. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 11:32:59AM +0200, Kevin Kofler wrote: > Tom Lane wrote: > > > [ ppc64 horror story snipped ] > > > > Well, I'm by no means wedded to ppc64; I just want *some* BE > > architecture in the primary set. Maybe a reasonable compromise would be > > to include ppc but not ppc64? That would cover basic BE portability > > issues, if not the occasional BE-and-64-bit bug. And it would halve the > > present workload of the PPC builders, which might help the build time > > issue. > > Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just > has room for twice as many entries because pointers are half the size, so in > practice projects trigger the awfully low ppc64 limit first. And many other targets have similar limitations. Even x86-64 has them, just big enough that you rarely notice (you need to go over 2GB of code/data to start having issues there, and even then there are code models that allow larger code). In some cases it is just -fpic vs. -fPIC, but in other cases the limitations are more severe. Most of the limitations are related to the encoding of instructions, what immediates they allow and what addressing modes they support. It is actually very desirable if developers don't think all the world is i386/x86_64, that leads to horribly unportable code and many bugs go unnoticed. In the OpenBabel case just using an array, or changing the generator to spit more smaller sources, etc. would be desirable for portability. So I think making PPC a secondary arch is a very bad idea and will hurt Fedora quality. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik, Wed, 30 Sep 2009 18:55:56 -0400: > Both ppc and ppc64 have been excellent at catching software bugs in my > projects that long went unnoticed on i386/x86-64. > > The lack of big endian builds by default is a notable loss, and will > lead to a decline in software quality. > > I think this is a net-negative for Fedora. I don't think it is that bad with secondary archs ... I maintain PSPP (I didn't know what I've fallen into when I packaged that ;)) and we are routinely finding bugs on SPARC ... in pspp as well as in glibc, gcc, and other places. PSPP by its nature has quite extensive unit tests, so it is catching a lot of stuff which otherwise goes unnoticed. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Richard W.M. Jones píše v Čt 01. 10. 2009 v 10:29 +0100: > On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > > Jeff Garzik writes: > > > The lack of big endian builds by default is a notable loss, and will > > > lead to a decline in software quality. > > > I think this is a net-negative for Fedora. > > > > I think the same, but it's getting harder to find PPC machines. > > This was my problem too with PPC builds - it's hard to get time on a > PPC/PPC64 machine to fix the problems. > > > Is there another big-endian platform that is on the upswing? > > Is ARM big endian? The chips can usually do both endians, but Fedora/ARM is built as little endian, because the targeted HW is little endian. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Tom Lane wrote: > > [ ppc64 horror story snipped ] > > Well, I'm by no means wedded to ppc64; I just want *some* BE > architecture in the primary set. Maybe a reasonable compromise would be > to include ppc but not ppc64? That would cover basic BE portability > issues, if not the occasional BE-and-64-bit bug. And it would halve the > present workload of the PPC builders, which might help the build time > issue. Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just has room for twice as many entries because pointers are half the size, so in practice projects trigger the awfully low ppc64 limit first. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Kevin Kofler, Thu, 01 Oct 2009 02:58:15 +0200: > Yes. It slowed down builds, and it often triggered bizarre build > failures which were NOT bugs in the program, but in the toolchain or in > some core library like glibc, which in turn delayed important updates to > the affected packages. I.e., it was discovering bugs ... not in your program but in glibc, gcc, etc. (I have experienced this couple of times with pspp on Sparc). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 11:51:36PM -0400, Jeff Garzik wrote: > If sheer number of build machines is an issue, one could spin up a qemu > running ppc on a non-ppc box. This isn't as easy as it sounds. I couldn't get qemu-system-ppc[1] to boot at all, *even* with the supposed PPC experts on the qemu list helping me. There are multiple problems with the BIOS that ships with qemu. Rich. [1] or qemu-system-ppc64, or both, I can't recall now. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > Jeff Garzik writes: > > The lack of big endian builds by default is a notable loss, and will > > lead to a decline in software quality. > > I think this is a net-negative for Fedora. > > I think the same, but it's getting harder to find PPC machines. This was my problem too with PPC builds - it's hard to get time on a PPC/PPC64 machine to fix the problems. > Is there another big-endian platform that is on the upswing? Is ARM big endian? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Sep 28, 2009 at 12:21 PM, Josh Boyer wrote: > Hi All, > > As of today, ppc and ppc64 are no longer primary architectures in koji > starting > with the dist-f13 tag. This is in accordance with the FESCo approved demotion > of PowerPC starting with Fedora 13 development. > Can we drop AOT bits from java packages now? Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Josh Boyer píše v St 30. 09. 2009 v 19:52 -0400: > On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > >Jeff Garzik writes: > >> The lack of big endian builds by default is a notable loss, and will > >> lead to a decline in software quality. > >> I think this is a net-negative for Fedora. > > > >I think the same, but it's getting harder to find PPC machines. > > s/machines/desktop machines. You can find all kinds of PPC machines, just > typically not in desktop form. The only new one that I am aware of is the > fixstars.us Powerstation. But there should be enough of older IBM Power4+ workstations (IntelliStation 275) with prices around 100 EUR (at least here in Europe) making it possible to buy one just for playing with. > >Is there another big-endian platform that is on the upswing? > > Not to my knowledge, but I haven't paid much attention to that. We do have > secondary arches at least building, like sparc and s390x. I have a ppc > effort 1/2 going. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/30/2009 11:12 PM, Tom Lane wrote: Again, would you rather debug glibc now, or later? "Not at all" is not an option. [...] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. Seconded on all points. If sheer number of build machines is an issue, one could spin up a qemu running ppc on a non-ppc box. One does reach a tipping point where a modern machine + emulation winds up beating a native machine, as progress marches on, too. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Kevin Kofler writes: > Jeff Garzik wrote: >> But you're dodging the larger point -- Fedora has, de facto, demoted big >> endian support in its entirety to a second-hand effort, rather than >> distributed the workload much more widely. Given M package maintainers >> and N secondary-platform volunteers, it is clear M > N by orders of >> magnitude. > I think it is only fair that the people who actually care get to do the > work. Package maintainers can still fix their packages for PPC, they'll even > get e-mail reports from the secondary arch Koji if the builds fail. (It > already happens for the other secondary architectures.) They just won't be > required to do it anymore. You can't force volunteers (and many Fedora > developers are volunteers; even those paid by RH are paid primarily to work > on RHEL, not Fedora, and often do Fedora work in their own free time) to > work on something they're not interested in. You may have a point about volunteer maintainers, though I'd hope they'd be concerned about the quality and portability of their packages anyway. But for anyone working for Red Hat, it's insanely shortsighted to think that not testing on BE platforms is going to save work. We're going to have to make this stuff work on BE platforms for RHEL later on, and it will just be that much more painful if it happens months or years after the changes are fresh. Quite aside from people having forgotten the details of what they changed, upstream projects could be locked into little-endian-only file formats or other hard-to-change decisions by that time. >> Was ppc really such a burden? > Yes. It slowed down builds, and it often triggered bizarre build failures > which were NOT bugs in the program, but in the toolchain or in some core > library like glibc, which in turn delayed important updates to the affected > packages. Again, would you rather debug glibc now, or later? "Not at all" is not an option. > [ ppc64 horror story snipped ] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff Garzik wrote: > I would rather the problem be approached in a logical, scalable fashion: > by distributing the workload across the package maintainers who have > firsthand knowledge. ie. how things worked before. PPC hardware isn't exactly common these days. I'm sure there are a few machines on campus that have PPC (there are definitely SPARC workstations sprinkled around). As it stands, I have no useful access to any of the machines (I guess a Live CD could get some special access, though at what cost to my status as a student, I don't know). > But you're dodging the larger point -- Fedora has, de facto, demoted big > endian support in its entirety to a second-hand effort, rather than > distributed the workload much more widely. Given M package maintainers > and N secondary-platform volunteers, it is clear M > N by orders of > magnitude. > > Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated > an ability to detect problems not found on LE, it seems like this policy > change will directly lead to missed bugs, and an attendent decline in > software quality. > > Was ppc really such a burden? > > Jeff Build times were the worst part of it IMO. With how it was set up (ppc being default even on ppc64) ppc64 could have been dropped and ppc be left intact. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKw/+VAAoJEKaxavVX4C1XccEP/RwHvNRhDexa5klFpl3mDvlQ pFLpT2OogtNWT58RuxvyOIlQMHs8NJbWdu+cjBYxav70Uhk2a7zqCN8g+ExJz0YM QSRd8HVyNTglOOT9kVLpQR9JM9E7gehnqTbDUY3l7kb9It02oQ8xf08M7Z+UNwgB FRFcXRQRZ8m8PfkOpTAEFlwXccRuyYQcm1CgvVX52NMVma32FxkFWxfBfBEL4vkH lfSeuU1z6bzKsHbUOFV0qBcteDYRRE7UjG698qlFJY2PCu5mSZzwt8QQiiXaqemS oYRDvXxoLEL6xHVlwboYAbT5ej/Gt51EOzlH6GMinLaJCfXwbe4Eb1hkpS09p4k4 rB4ttazM5rl1SEYuXP318X0qHguhNjZeFvg4NPuep+Xbk1uy2cKDFygk5XDxgsH+ sJxGnsv09f6An7+y2seK+P9TviIr1g2SqeebaZeK2lOCIOBU0Ip7aXVM0A0/tNK8 By0qZOfOjhYoac5FvXTuJUU3+Zh7SZDxexwnsfUM8gyIMRllDMpIwp2tfqQHY6wJ AwuNoCPTchqXzr+WE24Y/9QX2Merbj0AooKzIFuHIAtpC/usD2/bggvVYiq1PM+k frIuFJmugcsMt6Yool6Sl7kJqFW4nin5xUdbPJuY6UQP+6x7oouV53WMsVFtW5zk fBXSd9Rm2dMgiXQp/2JR =MGWo -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik wrote: > I would rather the problem be approached in a logical, scalable fashion: > by distributing the workload across the package maintainers who have > firsthand knowledge. ie. how things worked before. > > But you're dodging the larger point -- Fedora has, de facto, demoted big > endian support in its entirety to a second-hand effort, rather than > distributed the workload much more widely. Given M package maintainers > and N secondary-platform volunteers, it is clear M > N by orders of > magnitude. I think it is only fair that the people who actually care get to do the work. Package maintainers can still fix their packages for PPC, they'll even get e-mail reports from the secondary arch Koji if the builds fail. (It already happens for the other secondary architectures.) They just won't be required to do it anymore. You can't force volunteers (and many Fedora developers are volunteers; even those paid by RH are paid primarily to work on RHEL, not Fedora, and often do Fedora work in their own free time) to work on something they're not interested in. > Was ppc really such a burden? Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages. In fact, my "favorite" ppc64 issue was a problem with OpenBabel hitting a limitation in the ppc64 toolchain: there's a "table of contents" which can grow only to a small fixed size, so large compilation units just don't compile on ppc64, while being perfectly valid C/C++ and compiling fine on all other architectures. (And that's already with the "minimal TOC". Without it, the limit is for the whole executable!) OpenBabel's SWIG-generated bindings exceeded that limit. We were the only ones hitting it as no other distribution is insane enough to build their packages for ppc64. (The binaries don't even get actually used as ppc32 is the preferred multilib on 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce the amount of TOC entries, which worked for 2 beta releases (requiring additional tweaking for the second one), but then it overflowed again. This was a big annoyance because the new OpenBabel betas were required for new kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream removed some things from their bindings to get them to build, a quite suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs to be redesigned from scratch. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: > Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/30/2009 07:28 PM, Jesse Keating wrote: On Wed, 2009-09-30 at 18:55 -0400, Jeff Garzik wrote: Both ppc and ppc64 have been excellent at catching software bugs in my projects that long went unnoticed on i386/x86-64. The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. Builds will still be done on ppc32/ppc64 as part of the secondary arch effort. Of course, there will still be an extremely small amount of people who test those builds and can help fix things. Are you willing to be one of those people since you find value in it? Helping to ensure ppc remains a successful secondary arch is the best thing you can do to help. I would rather the problem be approached in a logical, scalable fashion: by distributing the workload across the package maintainers who have firsthand knowledge. ie. how things worked before. But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M > N by orders of magnitude. Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated an ability to detect problems not found on LE, it seems like this policy change will directly lead to missed bugs, and an attendent decline in software quality. Was ppc really such a burden? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: >Jeff Garzik writes: >> The lack of big endian builds by default is a notable loss, and will >> lead to a decline in software quality. >> I think this is a net-negative for Fedora. > >I think the same, but it's getting harder to find PPC machines. s/machines/desktop machines. You can find all kinds of PPC machines, just typically not in desktop form. The only new one that I am aware of is the fixstars.us Powerstation. >Is there another big-endian platform that is on the upswing? Not to my knowledge, but I haven't paid much attention to that. We do have secondary arches at least building, like sparc and s390x. I have a ppc effort 1/2 going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, 2009-09-30 at 18:55 -0400, Jeff Garzik wrote: > Both ppc and ppc64 have been excellent at catching software bugs in my > projects that long went unnoticed on i386/x86-64. > > The lack of big endian builds by default is a notable loss, and will > lead to a decline in software quality. > > I think this is a net-negative for Fedora. > Builds will still be done on ppc32/ppc64 as part of the secondary arch effort. Of course, there will still be an extremely small amount of people who test those builds and can help fix things. Are you willing to be one of those people since you find value in it? Helping to ensure ppc remains a successful secondary arch is the best thing you can do to help. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Once upon a time, Tom Lane said: > Jeff Garzik writes: > > The lack of big endian builds by default is a notable loss, and will > > lead to a decline in software quality. > > I think this is a net-negative for Fedora. > > I think the same, but it's getting harder to find PPC machines. > Is there another big-endian platform that is on the upswing? IIRC ARM can be, but I think many (most?) ARM platforms that would support Fedora are little-endian. SPARC is big-endian but is not "on the upswing". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik writes: > The lack of big endian builds by default is a notable loss, and will > lead to a decline in software quality. > I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. Is there another big-endian platform that is on the upswing? regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/28/2009 12:21 PM, Josh Boyer wrote: Hi All, As of today, ppc and ppc64 are no longer primary architectures in koji starting with the dist-f13 tag. This is in accordance with the FESCo approved demotion of PowerPC starting with Fedora 13 development. The dist-f12 and older tags continue to have them as primary. Both ppc and ppc64 have been excellent at catching software bugs in my projects that long went unnoticed on i386/x86-64. The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/29/2009 04:48 PM, Josh Boyer wrote: On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh ah, ok. Thanks RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: > On 09/29/2009 12:31 AM, Jesse Keating wrote: >> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: >> >>> What do we have to do in order to build on PPC? Does it happen >>> automagically? >>> >> Once the ppc builders are setup and running smoothly, successful build >> requests on the primary arches will be tried on the secondary arches, >> which will include ppc. You'll need to do nothing specific on your end >> for this to happen. >> >> > What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Sep 28, 2009 at 11:33:37PM +0100, Peter Robinson wrote: >On Mon, Sep 28, 2009 at 11:31 PM, Jesse Keating wrote: >> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: >>> What do we have to do in order to build on PPC? Does it happen >>> automagically? >> >> Once the ppc builders are setup and running smoothly, successful build >> requests on the primary arches will be tried on the secondary arches, >> which will include ppc. You'll need to do nothing specific on your end >> for this to happen. > >Will (does?) the same happen for the other secondary arches like sparc or arm? The s390x and sparc ports use koji-shadow to my knowledge. This goes through and finds builds in the primary koji instance that are missing in the secondary arch instance and rebuilds them for the secondary arch. If a public ppc koji instance gets setup, it will use the same tools. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Sep 28, 2009 at 11:31 PM, Jesse Keating wrote: > On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: >> What do we have to do in order to build on PPC? Does it happen >> automagically? > > Once the ppc builders are setup and running smoothly, successful build > requests on the primary arches will be tried on the secondary arches, > which will include ppc. You'll need to do nothing specific on your end > for this to happen. Will (does?) the same happen for the other secondary arches like sparc or arm? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, 2009-09-28 at 19:02 -0300, Itamar Reis Peixoto wrote: > the ppc will be replaced by something else ? > > like ARM for example ? No, there is no other arch that is ready for primary status. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: > What do we have to do in order to build on PPC? Does it happen > automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
the ppc will be replaced by something else ? like ARM for example ? -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
2009/9/28 Josh Boyer : > Hi All, > > As of today, ppc and ppc64 are no longer primary architectures in koji > starting > with the dist-f13 tag. This is in accordance with the FESCo approved demotion > of PowerPC starting with Fedora 13 development. > > The dist-f12 and older tags continue to have them as primary. > > Happy building. > > josh > What do we have to do in order to build on PPC? Does it happen automagically? -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PPC/PPC64 disabled in Koji for dist-f13
Hi All, As of today, ppc and ppc64 are no longer primary architectures in koji starting with the dist-f13 tag. This is in accordance with the FESCo approved demotion of PowerPC starting with Fedora 13 development. The dist-f12 and older tags continue to have them as primary. Happy building. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
