Re: Question about dist-cvs make targets
Jesse Keating píše v Čt 07. 01. 2010 v 09:28 -0800: > As I proceed to port our make system over into fedpkg, I've ran across a > couple targets that are giving me pause. > > Is anybody out there making use of the following targets? > > unused-patches I tried to use this one when putting some packages with long history and some balast into a shape, but I wasn't 100% successful IIRC. > If so, please reply to which one, and in what scenario you use those > targets. Thanks! Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-06
Michael Schwendt píše v Pá 06. 11. 2009 v 09:49 +: > The following packages in the repository suffer from broken dependencies: > > == > The results in this summary consider Test Updates! > == > > package: qlandkartegt-0.16.0-1.fc11.i586 from fedora-updates-testing-11-i386 > unresolved deps: > libQMKToolBox.so > libSerialPort.so > > package: qlandkartegt-0.16.0-1.fc11.ppc from fedora-updates-testing-11-ppc > unresolved deps: > libQMKToolBox.so > libSerialPort.so > > package: qlandkartegt-0.16.0-1.fc11.ppc64 from fedora-updates-testing-11-ppc64 > unresolved deps: > libQMKToolBox.so()(64bit) > libSerialPort.so()(64bit) > > package: qlandkartegt-0.16.0-1.fc11.x86_64 from > fedora-updates-testing-11-x86_64 > unresolved deps: > libQMKToolBox.so()(64bit) > libSerialPort.so()(64bit) Can someone help me to find out where these libraries are coming from? My "repoqueries" were unsuccessful. The qlandkartegt build is http://koji.fedoraproject.org/koji/buildinfo?buildID=138829 Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
disabling internal crash handler in wxGTK
Hello, I plan to disable the internal crash handler in wxGTK for the the devel/F13 branch so we can use ABRT to report crashes. This will mean a rebuild of wxGTK with --disable-catch_segvs. This change affects all applications linked with wxGTK, because one symbol is removed from the "base" library. I will take care of rebuilding the packages, but the package owners should still check what is their implementation of the wxApp::OnFatalExpection() virtual method doing, because it will not be called anymore. Usually it is used to display the wxGTK-based crash report. Please let me know if you want to rebuild the package yourself or if you have some questions. This is the list of packages that are linked with the base wxWidgets/wxGTK library (libwx_baseu-2.8.so.0): audacity-0:1.3.9-0.4.beta.fc12.x86_64 bacula-console-wxwidgets-0:3.0.2-4.fc12.x86_64 boinc-manager-0:6.6.37-4.r18632svn.fc12.x86_64 codeblocks-contrib-libs-0:8.02-9.fc12.x86_64 codeblocks-libs-0:8.02-9.fc12.x86_64 codeblocks-0:8.02-9.fc12.x86_64 crystalspace-0:1.2.1-6.fc12.x86_64 DivFix++-0:0.30-8.fc12.x86_64 extrema-0:4.3.6-5.fc12.x86_64 fbg-0:0.9.1-4.fc12.x86_64 filezilla-0:3.2.8.1-1.fc12.x86_64 fityk-0:0.8.8-1.fc12.x86_64 flamerobin-0:0.9.2-1.fc12.x86_64 freedink-dfarc-0:3.4-1.fc12.x86_64 glest-0:3.2.2-1.fc12.x86_64 gnuplot-0:4.2.6-1.fc12.x86_64 grass-0:6.3.0-14.fc12.x86_64 gspiceui-0:0.9.97-1.fc12.x86_64 hugin-base-0:2009.2.0-1.fc12.x86_64 hugin-0:2009.2.0-1.fc12.x86_64 iaxclient-0:2.1-0.4.beta3.fc12.x86_64 kicad-0:2009.07.07-4.rev1863.fc12.x86_64 LuxRender-0:0.5-5.fc12.x86_64 mkvtoolnix-gui-0:2.9.8-2.fc12.x86_64 mrpt-apps-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 mrpt-core-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 mrpt-hwdrivers-0:0.7.1-0.1.20090818svn1148.fc12.x86_64 multiget-0:1.2.0-7.fc12.x86_64 nightview-gui-0:0.3.2-8.fc12.x86_64 OpenSceneGraph-examples-0:2.8.2-3.fc12.x86_64 panoglview-0:0.2.2-6.fc12.x86_64 perl-Wx-0:0.92-1.fc12.x86_64 pgadmin3-0:1.10.0-2.fc12.x86_64 plplot-wxGTK-0:5.9.5-1.fc12.x86_64 poedit-0:1.4.3-1.fc12.x86_64 rapidsvn-0:0.10.0-2.fc12.x86_64 scorched3d-0:42.1-3.fc12.x86_64 scummvm-tools-0:0.13.0-2.fc12.x86_64 simdock-0:1.2-7.fc12.x86_64 sooperlooper-0:1.6.13-4.fc12.x86_64 springlobby-0:0.27-1.fc12.x86_64 toped-0:0.9.5-1.fc12.x86_64 trustedqsl-0:1.11-5.fc12.x86_64 ucblogo-0:6.0-5.fc12.x86_64 vavoom-0:1.30-3.fc12.x86_64 wxBase-0:2.8.10-6.fc12.x86_64 wxGTK-devel-0:2.8.10-6.fc12.x86_64 wxGTK-gl-0:2.8.10-6.fc12.x86_64 wxGTK-media-0:2.8.10-6.fc12.x86_64 wxGTK-0:2.8.10-6.fc12.x86_64 wxiax-0:2.1-0.4.beta3.fc12.x86_64 wxMaxima-0:0.8.3a-1.fc12.x86_64 wxPython-0:2.8.9.2-3.fc12.x86_64 xchm-0:1.17-2.fc12.x86_64 xmlcopyeditor-0:1.2.0.2-2.fc12.x86_64 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
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
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: what features are required in Fedora kernel
Roland McGrath píše v Pá 04. 09. 2009 v 14:20 -0700: > > This is an interesting question. I'd hate to think that something being > > unable to be included because of technical reasons would cause us to be > > unable to call something Fedora. > > Well, I think it's more or less "whatever works". That is, we require > the various kernel features that the rest of the Fedora packages and > their integration need to work properly. > > Are you trying to get the installed kernel rpm size real small, > or just to get the kernel+initrd real small? The latter seems I am not playing with the kernel rpm for now, having a working kernel rpm on ARM is a long-term goal. > fairly easy--just make everything not in the boot path modular > and make sure mkinitrd doesn't include anything unnecessary. > Then everything else can be in post-boot modules and you don't > necessarily have to strip down the kernel build particularly. Yes, it works. The first experiment was how small today's kernel can be. And it's good to know that it can be small enough, at least on 32-bit platform. Now it requires to properly mix the built-in and modularized stuff. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
Mike McGrath píše v Pá 04. 09. 2009 v 15:55 -0500: > On Fri, 4 Sep 2009, Dan Horák wrote: > > > Hi all, > > > > I am building kernels for some ARM based devices that use Fedora/ARM as > > user-land. These devices are usually very limited in the size of kernel > > that can be stored in their flash memories (like 2MB kernel, 4MB > > ramdisk). So I would like to know what kernel features make a "Fedora > > kernel", what are the MUST HAVE features? > > > > This is an interesting question. I'd hate to think that something being > unable to be included because of technical reasons would cause us to be > unable to call something Fedora. It's not meant as a strict question what can or can't be called Fedora, but rather what are the important features that are used by the user space tools in Fedora. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
Steve Grubb píše v Pá 04. 09. 2009 v 14:41 -0400: > On Friday 04 September 2009 02:17:10 pm Dan Horák wrote: > > I am building kernels for some ARM based devices that use Fedora/ARM as > > user-land. > > Glad to see someone else looking at the ARM kernel. > > > > These devices are usually very limited in the size of kernel > > that can be stored in their flash memories (like 2MB kernel, 4MB > > ramdisk). So I would like to know what kernel features make a "Fedora > > kernel", what are the MUST HAVE features? > > Maybe some usb devices. Which ones...I don't know. :) USB support is built as modular so I can enable all :-) > > Now I have those on my list > > - audit > > Note that the audit system on ARM is dysfunctional. No one has ever taken the > time to write the requisite code in arch/arm/kernel/ptrace.c to call > audit_syscall_entry(). Without that code upstream (or as a patch), the audit > system is limited to user space originating events. I don't know if SE Linux > AVC's are affected by the audit system not having its hands on a lot of > information during the syscall. good to know > > - SELinux > > - IPv6 > > - Netfilter for both IPv4 and IPv6 > > Netfilter is needed badly on that arch since the default system image has a > mail server listening to the public IP address and running as root. Iptables > is needed to block this access. I have uploaded my kernel + modules, see https://www.redhat.com/archives/fedora-arm/2009-September/msg6.html for details. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
what features are required in Fedora kernel
Hi all, I am building kernels for some ARM based devices that use Fedora/ARM as user-land. These devices are usually very limited in the size of kernel that can be stored in their flash memories (like 2MB kernel, 4MB ramdisk). So I would like to know what kernel features make a "Fedora kernel", what are the MUST HAVE features? Now I have those on my list - audit - SELinux - IPv6 - Netfilter for both IPv4 and IPv6 but there are others for sure. Heavily modular kernel is about 1.65 MB now. Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpqarrayd for fedora 11 and 12
Howard Wilkinson píše v Čt 27. 08. 2009 v 11:02 +0100: > I have had to patch the code for cpqarrayd to get it working under > Fedora 11. It was failing with a stack smashing exception. I have fixed > this by replacing stack structures with dynamic allocation. Where should > I send the patch ... the last development on this was in 2007 so it is > probably not being maintained, although I will try to contact the author. Please also open a bug in our Bugzilla. Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
> sharkcz:BADSOURCE:entertrack-1.2.6.tar.gz:entertrack modified tarbal in Fedora > sharkcz:BADURL:mm3d-1.3.8.tar.gz:mm3d OK now (probably sf.net issue) > sharkcz:BADURL:openoffice-python-0.1-r34-20090228.tar.bz2:python-openoffice fixed > sharkcz:BADURL:PyWebDAV-0.9.2.tar.gz:pywebdav buggy download on googlecode > sharkcz:BADURL:tryton-1.2.1.tar.gz:tryton fixed > sharkcz:BADURL:xa-2.3.5.tar.gz:xa site doesn't like wget, download from browser works Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Jim Meyering píše v Po 24. 08. 2009 v 11:14 +0200: > Roland McGrath wrote: > > I agree with Jeff here. Sorry, Jim. I know life is too complicated to > > Heh, no need to feel sorry, Roland, unless its for the code pollution. > It's fixed properly, now. And it's not even that ugly. > > > keep track of, but that's just how it is. A robustly-written application > > really needs to distinguish the build-time vs runtime dependencies it has. > ... > > The bottom line is that a properly portable program has to check for ENOSYS > > at runtime now if the function in question has ever existed in a libc > > capable of running on a kernel that does not support that system call. > > You should know well that we have to strike a balance here. > There is a limit. Work-arounds like this are worthwhile only > when the older kernels are in frequent-enough use that not applying > the work-around would cause significant risk or discomfort. > > For example, if I were to make coreutils programs run flawlessly on 2.4.* > or earlier kernels even when configured/built against modern headers and > libraries, I suspect there would be significant performance degradation > in a few key tools. If the degradation didn't impact maintainability, > and were negligible when running on modern systems, then it might be ok. AFAIK glibc has its minimum kernel requirement and it should be 2.6.18 (RHEL 5) now. In my opinion the rest of user space should expect this as the minimal version too. > Unless someone can point out a flaw that causes real trouble, > I'll continue making pragmatic compromises. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More Fedora mock breakage
Tom Lane píše v So 01. 08. 2009 v 00:09 -0400: > Bastien Nocera writes: > > On Fri, 2009-07-31 at 18:48 -0400, Tom Lane wrote: > >> [ consults CVS... ] So XZ support in F-11's rpm is less than a week > >> old, there is *no* support in F-10, and we're already requiring > >> the capability in order to do useful development work? > > >> All I can say is WTF. > > > An rpm with Xz support is in F11 updates-testing. I'm pretty sure it's > > also in updates-testing for F10. > > It is not in F-10's package CVS, let alone in updates-testing. Yes, > I looked before complaining. This was not well-managed. rpm with xz support for F-10 is available at http://fedora.danny.cz/rpm/ Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status - gdal
Dan Horák píše v Čt 30. 07. 2009 v 10:42 +0200: > And again there are troubles with gdal :-) I have a patch (thanks to > PLD), that solves the incompatibility with the new libdap 3.9.3. And an > update to 1.6.1 solves some swig related issues from 1.6.0. gdal 1.6.1 is built in rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=1565598 Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status - gdal
And again there are troubles with gdal :-) I have a patch (thanks to PLD), that solves the incompatibility with the new libdap 3.9.3. And an update to 1.6.1 solves some swig related issues from 1.6.0. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [pkgdb] libatomic_ops: sharkcz has requested approveacls
Nicolas Chauvet píše v Pá 24. 07. 2009 v 10:06 +0200: > This package was orphaned because libatomic_ops is going to be merged with gc. > Do we have a particular rationale about why to continue to maintain it > over splitting libatomic_ops-static from the current gc 7.1 where > libatomic_ops snapshot is newer ? > (despite versioned as 1.2) But do you know about any status update or confirmation of the plan from upstream besides the 1 year old notice on thier web page? I couldn't find anything on their mailing list. And it's not orphaned now with rdieter being the owner and I want to help him with maintaining the lib on secondary archs. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
Matthew Woehlke píše v Út 21. 07. 2009 v 13:27 -0500: > Jesse Keating wrote: > > List of deps left behind by orphan removal: > > > > Orphan: libatomic_ops > > pulseaudio requires libatomic_ops-devel = 1.2-6.fc12 > > Obviously, this is also a problem, except that again F11 has no such > dependency. libatomic_ops will survive either as a standalone package or as a subpackage of the "gc" package. Process has been started. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: creating minimal boot image for network installations
Jeremy Katz píše v Čt 16. 07. 2009 v 10:05 -0400: > On Thursday, July 16 2009, Dan Hor?k said: > > I don't know about a simple way to start a network installation of > > Fedora from USB stick. Creating of boot.img, that server that purpose, > > was stopped by rel-engs some releases ago. I have found a blog post [1] > > that makes possible to transform a boot.iso image into a bootable USB > > stick. But it still requires to download the 200+ MB large boot.iso file > > and do it by hand, while in theory only initrd.img and vmlinuz files > > should be needed and the whole process could be automated. So I have > > created mkbootimg.sh script [2] that automates all required steps and > > has a bootable disk image as a result. It can be transferred to real USB > > disk by the dd command. I find it useful when testing rawhide > > installations, but can be used for releases too. There is naturally no > > warranty for the script, it can eat whole your system :-) > > With Fedora 12, you'll be able to just dd the boot.iso onto a USB stick > since we're making isohybrid'd images. That will be appreciated :-) > Note that while kernel + initrd is all you "need", not having the stage2 > means we have to ask where to find it rather than being able to automate > the use of the mirror list for everything On other side one can prefer setting the mirror manually e.g. when having a private/local mirror. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
creating minimal boot image for network installations
I don't know about a simple way to start a network installation of Fedora from USB stick. Creating of boot.img, that server that purpose, was stopped by rel-engs some releases ago. I have found a blog post [1] that makes possible to transform a boot.iso image into a bootable USB stick. But it still requires to download the 200+ MB large boot.iso file and do it by hand, while in theory only initrd.img and vmlinuz files should be needed and the whole process could be automated. So I have created mkbootimg.sh script [2] that automates all required steps and has a bootable disk image as a result. It can be transferred to real USB disk by the dd command. I find it useful when testing rawhide installations, but can be used for releases too. There is naturally no warranty for the script, it can eat whole your system :-) Dan [1] http://hansdegoede.livejournal.com/4573.html [2] http://fedora.danny.cz/misc/mkbootimg.sh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-cvs flag could not be set
Miroslav Suchý píše v St 15. 07. 2009 v 16:31 +0200: > I just wanted to set fedora-cvs flag to "?" in my bug > https://bugzilla.redhat.com/show_bug.cgi?id=491331 > But it is grey (i.e disabled) and I could not change it. I can edit: > fedora‑review > fedora_requires_release_note > needinfo > but not > fedora-cvs > > Q: Did I miss some process change? It is bug in BZ? Did somebody set > some wrong settings? Did I forgot to set someting in BZ? you are not the only one with this problem :-) See https://fedorahosted.org/fedora-infrastructure/ticket/1534 for details. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: glib2 gio GSocket conflicts (Re: Fedora rawhide rebuild in mock status 2009-06-08 x86_64)
Michael Schwendt píše v Čt 11. 06. 2009 v 13:54 +0200: > On Thu, 11 Jun 2009 13:48:29 +0200, Dan wrote: > > > Michael Schwendt píše v Čt 11. 06. 2009 v 13:40 +0200: > > > On Wed, 10 Jun 2009 17:06:50 -0500, Matt wrote: > > > > > > > Fedora Rawhide-in-Mock Build Results for x86_64 > > > > using the first rawhide of the Fedora 12 development cycle, cut on > > > > 6/8/2008. > > > > > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > > > > compat-wxGTK26-2.6.4-7 (build/make) mschwendt > > > > wxGTK-2.8.10-1.fc11 (build/make) mattdm,sharkcz > > > > > > This is due to glib2 2.21.1's gio introducing a GSocket that conflicts > > > with wxGTK's GSocket class. > > > > See http://trac.wxwidgets.org/ticket/10883 for a workaround. > > Well, I've worked around it differently by including less glib/gdk headers > to avoid including giotypes: > > http://cvs.fedoraproject.org/viewvc/rpms/compat-wxGTK26/devel/wxGTK-2.6.4-gsocket-conflict.patch?revision=1.1&view=markup > Fortunately the upcoming version 3.0 of wxWidgets uses a rewritten socket code without this conflict. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: glib2 gio GSocket conflicts (Re: Fedora rawhide rebuild in mock status 2009-06-08 x86_64)
Michael Schwendt píše v Čt 11. 06. 2009 v 13:40 +0200: > On Wed, 10 Jun 2009 17:06:50 -0500, Matt wrote: > > > Fedora Rawhide-in-Mock Build Results for x86_64 > > using the first rawhide of the Fedora 12 development cycle, cut on 6/8/2008. > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > compat-wxGTK26-2.6.4-7 (build/make) mschwendt > > wxGTK-2.8.10-1.fc11 (build/make) mattdm,sharkcz > > This is due to glib2 2.21.1's gio introducing a GSocket that conflicts > with wxGTK's GSocket class. See http://trac.wxwidgets.org/ticket/10883 for a workaround. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: access to a ppc64 machine for bigloo's upstream
Josh Boyer píše v Út 02. 06. 2009 v 13:17 -0400: > On Tue, Jun 02, 2009 at 06:41:49PM +0200, Dan Horák wrote: > >Hi, > > > >is here anybody that could give access to a ppc64 machine to bigloo's > >upstream? The builds of bigloo on ppc64 (and s390x) gets stuck and they > >are willing to debug/fix it, but need a ppc64 machine. > > Email me an ssh pubkey and your preferred login and I'll give you an account > on my G5 running rawhide Thanks, information forwarded. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
access to a ppc64 machine for bigloo's upstream
Hi, is here anybody that could give access to a ppc64 machine to bigloo's upstream? The builds of bigloo on ppc64 (and s390x) gets stuck and they are willing to debug/fix it, but need a ppc64 machine. their homepage is http://www-sop.inria.fr/mimosa/fp/Bigloo/ failing builds https://koji.fedoraproject.org/koji/taskinfo?taskID=1389648 (internal copy of gc) https://koji.fedoraproject.org/koji/taskinfo?taskID=1389647 (using packaged gc) thread on upstream mailing list http://thread.gmane.org/gmane.lisp.scheme.bigloo/4289 Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora Mips\Arm Processors?
Frank Murphy (Frankly3d) píše v So 30. 05. 2009 v 13:23 +0100: > Looking at following: > > http://broadcast.oreilly.com/2009/05/the-mips-processor-and-the-150-1.html > > How is Fedora in regards to running mips\arm processors? Fedora/ARM is an alive secondary architecture - see https://fedoraproject.org/wiki/Architectures/ARM for details. There is no public effort to port Fedora to MIPS, but someone (connected to a netbook vendor?) was asking some questions about our buildsystem. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
