devel February 2010

devel@lists.fedoraproject.org

255 participants
262 discussions

thunderbird is removing spaces
by Stefan Assmann 18 Mar '10

18 Mar '10

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

3 3

Impasse on packaging JOGL and Gluegen
by Henrique Junior 13 Mar '10

13 Mar '10

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

7 11

Cannot rely on /dev being present in %post scripts?
by David Woodhouse 12 Mar '10

12 Mar '10

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

5 4

Suggestions
by Elad 11 Mar '10

11 Mar '10

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

6 6

Fedora 13 has been branched!!
by Jesse Keating 08 Mar '10

08 Mar '10

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.2FRepo_… 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

15 59

Draft of maintainer and sponsor responsibility policies
by Toshio Kuratomi 08 Mar '10

08 Mar '10

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%28draft%… and will be on the agenda for next weeks FESCo meeting. -Toshio

3 6

packaging guide
by psmith 07 Mar '10

07 Mar '10

hey guys i'm hoping to package gerix-wifi-cracker-ng(1) for fedora and i'm looking for someone who i can look to for help if i need it, is there a list of names i can look to? or what is the reccomended path? tia phil (1) http://www.backtrack.it/~emgent/hackstuff/old_gerix_wifi_cracker_ng/

3 2

Adding optional packages to comps.xml
by alekcejk＠googlemail.com 06 Mar '10

06 Mar '10

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>

1 1

Heads up: X server configuration changes
by Peter Hutterer 06 Mar '10

06 Mar '10

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

12 25

VCS key in spec files and some scripts
by Colin Walters 06 Mar '10

06 Mar '10

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: http://rpm.org/attachment/ticket/143 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. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version 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 gnome-autogen.sh). 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: http://fedorapeople.org/gitweb?p=walters/public_git/fedpkg-make-pull.git;a=… 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 accepted! 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 mutter gnome-shell

2 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2010