I was looking for a way to check abi compatibility for a package I
maintain that does not control API/ABI compatibility and found this:
I already have it packaged for my own use so I thought I'd check to
see if anyone else is interested in it, and if so, if someone will
want to review it.
PHP 5.4 enter RC stage
So, I'm working to upgrade all the PHP stack
(for now in my testing repo)
I think PHP 5.4.0 (finale/stable) will be available for fedora 17, so I
plan to update it (and all C extension before fedora 17 feature freeze)
Do you think I should submit a feature proposal ?
Of course this will requires to test all web app. available in the
Hello fellow devs,
I am sure quite a few of you have done some reviews and thought "Hey,
a,b,c and d could be automated. For E I could use some more
information that can be automatically gathered". Some of you even
wrote your own tools to do some of these things.
Yet there is no unified tool, nor format for package reviews. There
are more reasons, but I guess biggest one is there are just too many
guidelines and there is probably no one who knows all of them. So few
of us got together and hopefully created something that can be used by
fedora-review is now in updates-testing. It provides several checks:
66 generic tests (licensing, md5sum sources, bundling, etc.)
9 c/c++ specific checks (static libs, ldconfig, headers, rpath etc.)
13 java specific checks (javadoc, depmaps, jpackage-utils reqs)
8 R specific checks
There are still many more checks waiting to be written. I'd like to
see Perl, Python and Ruby checks, though I am not *that* familiar with
their guidelines. I think the important thing here is that checks can
be written in basically any language. We have simple JSON api using
stdin/stdout for communication. There is an example external plugin in
documentation in perl and shell (though that's just mock-check).
Our goal is for each language SIG (or other specific package group) to
maintain their own checks together with their guidelines.
* How you can help *
- Tell us what checks are missing
- Tell us if you think checks are doing it wrong
- Create new checks (in language of your choice - we have JSON api)
- do this even if the test cannot be automated. At least it will
appear on the checklist for your packages!
- Any ideas, bugreports etc will be much appreciated
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
I'm working on improving how akmods are built and had an idea I
need input/confirmation on.
Instead of the akmods packaging assuming when it needs to run, why
can't each akmod driver package provide it's own unit file?
Since the service would run as type "oneshot", am I correct in
assuming that no matter how many times it's started, it will only
start for real on the first (earliest) occurrence?
My idea is that each akmod driver package would provide a service file
with the same name as the package but include an alias to
What's the consequences of multiple unit files claiming the same
alias? Is this safe?
I am orphaning the techtalk-pse package because the Gtk2::MozEmbed perl
module will no longer be maintained in Fedora because gtkmozembed
support has been removed from xulrunner.
If upstream (or anybody) has the time to work on techtalk-pse and get it
working with something like Gtk2::WebKit, I'm glad to pick up package
maintenance again. (I would, but my perl skills go as far as running
Ian Weller <ian(a)ianweller.org>
\/"/_ All Hail the Beefy Miracle!
How are fedora with grub2 users supposed to set up crashkernel kernel
argument? Or even any argument? Writing own script for it?
I'm asking because I'm maintaining system-config-kdump and I'm not sure
how to ensure this.
I just orphaned gdk-pixbuf in pkgdb.
It failed the mass rebuild, not much left that depends on it, and
nothing I need. ;)
% repoquery --source --whatrequires gdk-pixbuf
So, if anyone really really really wants to keep it alive, feel free to
take it and fix it so it builds and works. ;)
As promised in my previous mail, here is what I find that's lacking in
Fedora, compared to the direct competition (Ubuntu, Debian, OpenSuse),
and recently even some proprietary systems: we don't have an application
While we do have two nice UIs (gpk-application and apper) for package
management, having to deal with packages, with no icons and no
translations is not appropriate for end users. Instead, I think it would
be appriopriate to follow the Ubuntu path and recognize the applications
from .desktop files, because that is what will end up in the app
Since this is free software, we already have a complete software center
available, straight from launchpad.net/software-center.
(Actually, it doesn't yet work on Fedora, partly because of unmet
dependencies, but those are just technical bugs, and I don't think it
would be difficult to have something running soon)
What is missing, though, is the data, representing the applications
available in fedora repositories.
Long long ago (march 2009), a package was proposed for inclusion, which
contained application data, in a format understood by software-center,
for fedora at that time. This package was initially rejected, then one
year later FESCo ruled that it did not actually break packaging
guidelines, yet it disappeared.
Back to present, it's almost 2012. I'm here and I want to do whatever is
required, at all layers, to ensure that application data is correctly
generated, updated, and downloaded, at all times and for all users. This
may involve changes in our repository infrastructure, in yum, packagekit
and maybe in other places as well.
I think this is specifically a Fedora feature, as it involves the whole
distribution and touches many groups at the same time, which explains
why I proposed it here instead of anywhere else. If you think it's worth
it, I'd like to propose it as an official Fedora 17 Feature, and I'll
happily write the wiki page.
I hope that some people from the relevant group will point me to the
right place (perhaps starting from what happened to
fedora-app-install...), and I hope you like the idea in general.