some time the inclusion of the software Scilab  in our repos has been barred
by various dependencies, which were being resolved with time. Currently, the biggest reason we do not have this
software in our repos is that it relies in a software called JOGL .
big question here is that JOGL, in his turn, depends on other software called
Gluegen  and, more specifically, it depends on the **source tree** of
Gluegen, as explained in the instructions for build :
5 - Check out the GlueGen source tree:
GlueGen relies on the project to autogenerate most of the Java and JNI code for
the OpenGL interface. The JOGL / and gluegen /
workspaces must be side-by-side in order for JOGL to build properly. "
this stage, we have drafts of packages for both, Gluegen  and JOGL , but
we got to the stalemate that JOGL continues to need Gluegen’s **code** to build
his own build.xml, so, even if we have Gluegen packaged and installed, what
matters for the correct build of JOGL is the gluegen’s code side by side.
first I thought it would be better to generate both packages from a single .spec,
then I decided to create a separate package for Gluegen and provide a tarball
of that Gluegen’s code as Source1 for the compilation of JOGL.
Chen Lei said, the fact that JOGL needs this code may mean that it will be blocked
forever for packaging, but I do not particularly see a big problem.
more details, please, read the log in bugzilla and give your ideas regarding
 - http://www.scilab.org/
 - https: / / jogl.dev.java.net /
 - https: / /
 - http://download.java.net/media/jogl/doc/HowToBuild.html
 - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439627
 - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439630 ------------------------------
Henrique "LonelySpooky" Junior
Veja quais são os assuntos do momento no Yahoo! +Buscados
According to bug #517013, %post scripts should not assume that /dev is
available -- so we can't do anything that requires the existence of
/dev/null, /dev/urandom, etc.
Is this a known and expected packaging rule, or is it a bug in the way
that the user is attempting to install the packages?
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
First of all: thank you, fedora developers, for making such a great linux
I think I have some good ideas and suggestions that might help you improve
1) Create a new plymouth theme (or in other words, ask the artwork team to
The current default plymouth theme is almost the same theme from fedora 11.
I think we need to change it.
2) Plymouth boot splash background should match the gdm background
as I've explained here: https://bugzilla.redhat.com/show_bug.cgi?id=550321
3)Plymouth needs a graphical user interface to select the boot splash
screen, with a preview of the selected theme, so the user wouldn't have to
reboot to see if he likes the theme.
yum should select the mirror to download from in a smarter way, considering
the current load on the mirror and the distance of the mirror from the user.
This will help reduce the load on the mirrors and make the download faster
for the user. The mirrorlist server should know what is the load on each
mirror, and give yum the mirrorlist sorted by the load and the distance from
the user. yum should prefer the less busy and closest mirror it can find.
5)PackageKit UI improvements:
5.1)When downloading packages, display the percentage of the download
progress on the progress bar
5.2)Fix bug #551201 ( https://bugzilla.redhat.com/show_bug.cgi?id=551201)
5.3)Make it possible to undo transactions using gpk-log
6)BiDi problems with translations:
this problem is the most annoying thing in fedora for me. gnome-terminal for
example doesn't have any bidi support. terminals are not supposed to support
but the problem begins with applications like pkcon or diff, in which
terminal output is also translated.
that causes unreadable output. e.g if the output was supposed to be שלום it
will display םולש.
there are two ways to fix this problem
1) make gnome-terminal and others support BiDi output
2) put a comment in each POT file that warns the translator about strings
which will be written in the terminal so translators would know what should
I think the first way is better.
7)Combine all hardware listing programs (e.g hwbrowser, usbview, lshw-gui)
into one, comprehensive, easy to use GUI.
thank you for listening.
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
that we wrote about:
The real take away here is explained at
The upshot is that if you want to get a build into Fedora 13, you gotta
build from F-13/ and you gotta put it in bodhi. The good news is that
if your package isn't critical path, it's just like any other update in
bodhi, you decide when it goes stable. If it's critical path, releng or
QA will have to give it karma, but that means somebody will look at it!
(We're working on ways to make it more visible to the user that your
package is critical path).
There are new paths on the mirrors too:
pub/fedora/linux/development/rawhide <-- this is the new home of
rawhide. Builds from devel/ go here. This is now the F-14 development
pub/fedora/linux/development/13 <-- this is the branched Fedora 13.
Builds from F-13/ that make it through bodhi as stable show up here.
This is what we'll use to make the Alpha, Beta, Final release and all
the snapshots in between and the nightly attempt at instllable images.
pub/fedora/linux/updates/testing/13 <-- this is where the testing
updates go for the branched 13. Test 'em here before they go to stable.
For a better picture, see
I have disabled the rsync part of the rawhide compose process so that I
can do things by hand tomorrow and ensure we don't screw up the mirrors,
so you'll see a delay in things. We'll also do the branched tree
compose by hand as well and then sync the output at the same time to
preserve hardlinks. It'll be a fun day! Hop by #fedora-devel if you've
got questions and somebody will try to help you.
Welcome to the world of No Frozen Rawhide!!!
Fedora -- Freedom² is a feature!
devel-announce mailing list
At the last fesco meeting we talked about the ramifications of allowing
any person in the packager grop to commit to packages and decided that
rather than having more accounts and acls on to manage this, that it was
desirable to change the responsibilities of sponsors and maintainers.
The goal is to stop saying that a sponsor is responsible for cleaning up
after their sponsorees should the sponsoree start making bad commits to
a bunch of packages. Instead, the burden of looking for such bad commits
goes to the package maintainers who choose to open their packages to the
packager group. We want to encourage more sponsors to take on people that are
not yet good packagers but have the potential to grow into good packagers with
a little mentoring.
Updated policy drafts are here:
and will be on the agenda for next weeks FESCo meeting.
I want to add to "Sound and Video" in comps.xml
some optional packages which I not own.
v4l2ucp in comps.xml for F11-F14,
ucview for F11-F14, EL5
and gtk-v4l for F13-F14.
Is there any objections to do this?
Alexey Kurov <nucleo(a)fedoraproject.org>
So you're running an X server? Well, my lad or lass, sit down and let me
tell you about the neverending story of X server input configuration
changes that has hopefully ended now.
I'm just pushing the latest X server goodness into rawhide and enabling
udev, completing (from the X server's POV) the excision of the hardware
abstraction layer that shall not be named.
>From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many
configurations have moved into fdi files. As you may know, hal is deprecated
and as much as fdi files may be pleasing to the eyes, there's just no future
in them. You'll just have to let it go, even if it hurts.
Instead, we have the newest latest and greatest bits, namely xorg.conf.d
support and InputClasses. You can drop configuration files into the new
directory and the server will pick it up on startup.
"A configuration directory? Is this even possible?" you say? I know, it
sounds mightily advanced but we have to keep surfing the wave of new
The existing section types in xorg.conf(5) weren't really suitable, so we
now have something that resembles the functionality provided by hal's fdi
files. A section of type InputClass will match against multiple devices and
even hotplugged ones - depending on the match rules. An example section
looks like this:
Identifier "superhero mouse config"
MatchProduct "Mighty Mouse"
Option "X-Ray vision" "on"
Any pointer device that contains "Mighty Mouse" in its product name will
match against this section and be added with the evdev driver and the
options as specified. That's just one example, I've tried to detail the new
configurations on our wiki.
If you think there's anything missing, please let me know or add it
Because the match rules are different to hal's matching rules, we don't have
an automatic conversion from your custom fdi files into xorg.conf format.
If you have custom rules, I recommend porting them to the new format before
updating to ensure a smooth upgrade.
Dear Fedora Developers,
So recently I found myself desiring to update a .spec file for a
snapshot of a git tree in an automated fashion. As you may or may not
know, this actually has a surprising number of flaming hoops through
which you must jump.
The first one, when scripting such a thing, is pulling the source tree
and packing it into a source file. To this purpose, I propose we
begin adding the following key to .spec files:
#VCS: <url format entry for version control system>
Note the use of a comment. There's a ticket to support this key more
explicitly in RPM:
However I didn't want to block my scripts on that patch landing; in
any case we currently add human-consumable comments
(https://fedoraproject.org/wiki/Packaging:SourceURL) for VCS snapshots
now, so think of this key as just more of that. Having the version
control system in the spec file will help a lot for other things like
automating source tarball verification.
The second hoop is correctly handling the Release tag.
has lots of gory details. But basically, this can be automated.
Another hoop is the autotools; you have a variety of choices here, but
it's most common to add BuildRequires on them, and figure out how to
bootstrap. This latter part requires a bit of build intelligence (my
scripts recognize the case of autotools, and the more specific case of
I'd actually like to break out the build recognition system into a
separate python library of some sort.
So without further ado, my current scripts:
I'd actually like to get these into Jesse's new fedpkg work, but for
now these operate on distcvs.
Executive summary: if you find yourself needing to automate git-spec
integration, you should use my scripts, because they're cool. I'm
sure I'm not the first person to write these scripts, but I'd like to
get these upstream into fedpkg. Patches for other version control
systems (and major build systems like distutils and cmake) are happily
What am I using them for? Automating gnome-shell stack snapshots for F12:
$ fedpkg-pull-build-chain --arch=i386 --arch=x86_64 --release=F-12
--resultdir=_repo gobject-introspection gir-repository gjs clutter
I'd like to propose moving comps to fedorahosted git.
Why? Because CVS is a pain.
I can work on fixing the automated releng tasks that use comps.
What I'd like to know is if doing this at some point over the
next few weeks (say, post-Alpha) would be a problem for people.
If it is, we can push it off until after F13 ships.