I was chosen as student for Fedora Gooey Karma project in GSOC (Google
Summer of Code).
My proposal  is available on fedoraproject wiki page where you can find
main features of this new tool.
I am going to blog about development and progress of FGK on my blog which
will be ready soon :). You will be able to see it on Fedora Planet too.
If you have any questions, please feel free to contact me here on mailing
list, off-list or Brano(a)freenode.org.
It looks like the venerable calls to new-kernel-pkg (from grubby) have been
replaced by kernel-install, which checks if /sbin/new-kernel-pkg exists and
runs that if it does, and otherwise does this stuff
I'm trying to update the cloud kickstart files for F20 (now that F19 is in
the can, right?), and am trying to understand what the plan and migration
path is here. I can't find a feature page for this.
Right now, immediately, the result is no initramfs being created under
appliace-creator. (We're hoping to move _away_ from appliance-creator for
this release, but one step at a time.) I went ahead and added grubby to the
kickstart package manifest, but I'm not sure if that's the right thing.
How is this _supposed_ to be working?
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
(The same topic came up on this list about a month ago, with no
Fedora 18+ now has a proper Go compiler, and if you get the
version in updates-testing, it's even a working Go compiler :-)
Go seems to have a "unique" approach to packaging libraries. It looks
as if everything revolves around there being a Go compiler + lots of
bundled libraries that come with that Go compiler. On Fedora this
gets installed into %_libdir/golang.
But for libraries that aren't bundled with the Go compiler, it looks
like the Go designers intended you to keep them in your home directory:
This is of course not so great from a packaging/security/updates
point of view.
Now as far as I can tell, we can just ignore the $GOPATH stuff, and
instead drop files into the right places in %_libdir/golang. It works
in my single, limited experiment, but I've no idea if this is the
Right Thing to do.
I think we should leave the $GOPATH environment variable alone. If
users want to install things in their home directory too, they can set
up $GOPATH and the directory structure themselves.
Thoughts on this? (especially from anyone who knows what they're
talking about, which is not necessarily me ...)
I have a small cgo library which I'd like to package for Fedora, so
this discussion is not entirely theoretical.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
php-pecl-apc have been retired from rawhide repository.
php-pecl-apcu is a dropin alternative for user cache and is also
available in F18, F19 and EPEL6 (testing).
It's time to switch and test.
P.S. opcode cache is now provided by zend-opcache (php 5.5) or
php-pecl-zendopcache (php 5.3 / 5.4), the official PHP project opcode cache.
Is there some common practice, where to place architecture specific
header files? From output of the following command, I can't see any such
$ `gcc -print-prog-name=cc1` -v
ignoring nonexistent directory
ignoring nonexistent directory
#include "..." search starts here:
#include <...> search starts here:
End of search list.
Actually, the "ignoring nonexistent directory
might be usable, but is it allowed to use it? Does it conform to FHS
(don't think so). Shouldn't it be configured differently?
The point is, that compilation of this simple program:
$ cat > rt.c
int main(int argc, char **argv)
$ gcc rt.c
In file included from /usr/include/ruby.h:33:0,
/usr/include/ruby/ruby.h:24:25: fatal error: ruby/config.h: No such file
This should work out of the box IMO, without any configuration or
specification of additional paths etc. The problem is, that Ruby ships
architecture specific config.h header which is not available in GCC's
default search path and I am wondering how to make this work.
I recently did review or rubygem-gssapi , which is FFI wrapper above
Now, we'd like to specify dependency directly on this library, but since
rubygem-gssapi is noarch, it seems there is no way how to specify this
dependency better then "Requires: krb5-libs", unless the rubygem-gssapi
would be arch dependent. Or is there any better way? Any suggestion?