thunderbird is removing spaces
by Stefan Assmann
Hi,
thunderbird seem to remove spaces from lines that only consist of one or
more spaces. Any way of preventing thunderbird from doing so? I already
have "mailnews.send_plaintext_flowed false" and turned of line wrapping.
With these option sending patches works pretty well, only recently I
had a patch that got corrupted because of spaces being removed.
Any ideas?
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
14 years, 2 months
Impasse on packaging JOGL and Gluegen
by Henrique Junior
Hi, gentlemen,
For
some time the inclusion of the software Scilab [1] 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 [2].
The
big question here is that JOGL, in his turn, depends on other software called
Gluegen [3] and, more specifically, it depends on the **source tree** of
Gluegen, as explained in the instructions for build [4]:
"Step
5 - Check out the GlueGen source tree:
JOGL
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. "
At
this stage, we have drafts of packages for both, Gluegen [5] and JOGL [6], 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.
At
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.
As
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.
For
more details, please, read the log in bugzilla and give your ideas regarding
this question.
[1] - http://www.scilab.org/
[2] - https: / / jogl.dev.java.net /
[3] - https: / /
gluegen.dev.java.net /
[4] - http://download.java.net/media/jogl/doc/HowToBuild.html
[5] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439627
[6] - https: /
/ bugzilla.redhat.com / show_bug.cgi? Id = 439630 ------------------------------
Henrique "LonelySpooky" Junior
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
14 years, 2 months
Cannot rely on /dev being present in %post scripts?
by David Woodhouse
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
14 years, 2 months
Suggestions
by Elad
Hello.
First of all: thank you, fedora developers, for making such a great linux
distro.
I think I have some good ideas and suggestions that might help you improve
Fedora:
1) Create a new plymouth theme (or in other words, ask the artwork team to
do so):
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.
4)
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
BiDi
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
be translated
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.
-Elad
14 years, 2 months
Fedora 13 has been branched!!
by Jesse Keating
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:
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
The real take away here is explained at
https://fedoraproject.org/wiki/Branch_Freeze_Policy
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
ground.
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
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Tree.2FRep...
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!!!
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
14 years, 2 months
Draft of maintainer and sponsor responsibility policies
by Toshio Kuratomi
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:
https://fedoraproject.org/wiki/Package_sponsor_responsibilities%28draft%29
https://fedoraproject.org/wiki/Package_maintainer_responsibilities%28draf...
and will be on the agenda for next weeks FESCo meeting.
-Toshio
14 years, 2 months
Adding optional packages to comps.xml
by alekcejk＠googlemail.com
Hi,
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>
14 years, 2 months
Heads up: X server configuration changes
by Peter Hutterer
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.
e.g. /etc/xorg.conf.d/foobar.conf
"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
technological achievements.
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:
Section "InputClass"
Identifier "superhero mouse config"
MatchIsPointer "on"
MatchProduct "Mighty Mouse"
Driver "evdev"
Option "X-Ray vision" "on"
EndSection
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.
https://fedoraproject.org/wiki/Input_device_configuration
If you think there's anything missing, please let me know or add it
yourself.
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.
Cheers,
Peter
14 years, 2 months
