devel January 2005

devel@lists.stg.fedoraproject.org

273 participants
203 discussions

Fedora PPC things...
by Colin Charles 04 Feb '05

04 Feb '05

CC'ing fedora-devel-list because there are some things that need to be sorted for a possible FC-4/ppc _release_ Now, a list of known issues: 0. this boot.iso + nfs installation system has to go away - so we need to give anaconda love 1. out of the box video detection - system-config-display needs to be hacked on to recognise all the common Mac hardware bits out there. We can't be pushing Xautoconfig or something similar... but we can lean on it for inspiration if need be 2. anaconda and partitioning - auto partitioning possibly still fails (I don't think the Apple Bootstrap partition gets created); running yabootconfig automatically after installation, with an appropriate initrd and so on needs to happen (we can't depend on users breaking out into a shell) 3. sound is still relatively broken - dmasound_pmac tends to work, but is not the default config. system-config-soundcard definitely needs some work to make it play well with the Macs 4. power management - we need either pmud or pbbuttonsd. The latter has received no love from most fedora/ppc users, so pmud seems to be the winner, I'd guess. We need this included in Core (building only for ppc, and possibly later ppc64). We know yellow dog add some nice patches for disabling the touchpad in pmud - I guess the package maintainer can be free to include such patches at will if need be 5. updates - we can't have david woodhouse (dwmw2) grabbing packages from the RH build system and having to host them at ftp.linux.org.uk - we need a better mechanism. i.e. the normal way package updates go out, can the ppc and ppc64 packages go out with them too? This might involve some policy change at Red Hat, so can someone in the know, speak up? 6. back to the topic of power management; there are some patches out there that help G4 iBooks and newer powerbooks sleep (and wake up). They're not in the upstream kernel.org kernel, but with good benh approval (!), we might consider patching the kernel to make it more useful. dwmw2 currently builds kernels with these patches enabled 7. we'll be upfront about modems and Airport Extreme probably never working for free. Modems have drivers at linuxant (though they still might be flaky with our stack size in the kernel), but the Airport Extreme stuff is probably a no go (not yet at least) 8. 64-bit support. I personally don't have a G5 or anything ppc64, but I know that dwmw2 has one sitting at work, as probably does nasrat. We need more 64-bit testing, and making sure that anaconda boots on them too (if not we need more anaconda hacking). There have been reports that things were (or are still) broken on a 64-bit arch 9. PegasosPPC (Genesi) makers of PPC boards have thought of getting FC4/ppc to work on their machines. I'll be taking a look at this, though does anyone else have such machines around? 10. spanking MiniMac support? I guess this is a list of outstanding issues that we need to fix before Fedora Core 4 gets a PPC release. If I missed anything glaring, do add on the the thread Otherwise, lets get some C and Python hackers hacking on the packages above, and making things "just work" for FC/ppc. PPC specific discussion can take place at fedora-ppc(a)lists.infradead.org -- Colin Charles, byte(a)aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi

10 26

further package removals/potential package removals
by Bill Nottingham 04 Feb '05

04 Feb '05

Removed and orphaned: asp2php - does not show any history of usage, not really a core package Suggested for removal: xloadimage - there are better apps for displaying images (ImageMagick, eog, gthumb, kview, etc) - there are better apps for setting the root window (xsri) - it's *ancient* code that doesn't even support PNG nedit - legacy interface (motif) - doesn't support Unicode jed - doesn't support Unicode Opinions? Bill

66 185

rawhide firefox and background colour of webpages (CSS broken?)
by Kyrre Ness Sjobak 02 Feb '05

02 Feb '05

I have installed rawhide firefox on my fc3 computer, and it is pretty nice - exept two thing. Background color on several webpages (phpBB forums f.ex.) are now grayish. Not white (?) as they should be, judging from the white "border" around buttons. Also, it has no norwegian language support. This is version 1.0.8

11 13

Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine]
by Gavin Henry 01 Feb '05

01 Feb '05

Dear all, I thought that maybe you guys would have some input on this? Gavin. ---------------------------- Original Message ---------------------------- Subject: Re: Fedora Documentation Search Engine From: "Stuart Ellis" <s.ellis(a)fastmail.co.uk> Date: Fri, January 28, 2005 3:24 pm To: "For participants of the docs project" <fedora-docs-list(a)redhat.com> -------------------------------------------------------------------------- On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry" <ghenry(a)suretecsystems.com> said: > <quote who="Stuart Ellis"> > > > > On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry" > > <ghenry(a)suretecsystems.com> said: > >> Dear all, > >> > >> Has there been any discussion about this? > >> > >> I thinking along the lines of htdig/swish-e that indexes all man pages/howto/README after every rpm is installed. > >> > >> Something like a post entry in the spec file, or similar. > > > > I haven't seen any on this list, but essentially this is a function of having a desktop search/indexing engine since there isn't a common format to this stuff. The next release of yelp (GNOME help browser) will display info and man pages, but can't index the random txt, html, pdf etc. that goes into /usr/share/doc/. > > We heavily use Swish-e (www.swish-e.org) for the fileservers we install. This can handle html, xhtml, txt, pdf and the like. I've just looked at the page now, but it looks like a very useful bit of software. > Maybe something like this or a updatedocdb crontab, like slocate has and we just put the standard doc pathnames in a config file. The customize the > web search page. > My understanding is that this is where things become quite technical and problematic. There is always a disjunct between what's actually on the disk and what is listed in the index. On portable computers it's harder to guarantee that batch indexing jobs will be completed regularly as well. Beagle and Spotlight use kernel hooks to update the index as changes occur. I suppose that RPM packages could run post-install scripts that update a document registry (kind of like you suggested) would be a relatively non-invasive way to implement something. I definitely think that the default start page of the Web browser could be used very effectively by the docs project. The details of implementing an index might be a good question for fedora-devel. -- Stuart Ellis s.ellis(a)fastmail.co.uk -- fedora-docs-list mailing list fedora-docs-list(a)redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list

6 8

Starting sshd errors
by Mike Chambers 01 Feb '05

01 Feb '05

Up until a few weeks (couple I guess) openssh was working fine. But now when trying to start it, I get "initlog not found", which is around line 107, when the /etc/init.d/sshd file has "initlog -c blah blah". Have been away from home last few weeks so haven't really been able to pay attention if this problem already has a fix, so sorry if asking again. Thanks, -- Mike Chambers Madisonville, KY "It's always better to hurt a little now, than to hurt a lot later!"

2 2

Building subversion javahl bindings
by Pedro Lamarão 01 Feb '05

01 Feb '05

I've got this patch to subversion.spec that allows optional building of javahl bindings with a variable-specified JDK path. I've built it as I need Subclipse to work. What do you all think? -- Pedro Lamarão

3 2

Re: Better repodata performance
by Jeff Johnson 01 Feb '05

01 Feb '05

7 12

D-BUS 0.30 in my yum repository - porting guide attached
by John (J5) Palmieri 31 Jan '05

31 Jan '05

I have D-BUS version 0.30 in my yum repository at [j5utopia] name=J5's Experimental Project Utopia Repository baseurl=http://people.redhat.com/johnp/redhat/experimental/utopia You will have to --force --nodeps the packages for now until all the packages are updated to use the new dbus. Attached is a short porting guide. Ask me if you have any more complicated questions about the new API's. Please patch your rpm's to reflect the new API. We will make the switchover in a couple of weeks or whenever all the packages are done. Send me the srpm's so I can add packages to the repository as they are done. Here is a list of packages in core that need to be updated: gnome-volume-manager - me hal - davidz NetworkManager - dcbw NetworkManager-gnome - dcbw desktop-printing - walters cups - twaugh I'm posting this to fedora-devel so that packagers outside of core can consider themselves warned. Massive API breakage for anything that uses D-BUS is on the horizon as we move closer to 1.0. The 0.30 series should mark the biggest change moving to 1.0 and I don't expect anymore API breakage other than the glib bindings in the future. If there is I'll let you know. Thanks -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com

1 1

repository creation
by seth vidal 31 Jan '05

31 Jan '05

After all this absolutely enjoyable discussion of repodata format I figured I'd mention something that would help users tremendously to reducing the amount of data they might have to download. right now when a repository is created for use it's just made on ALL packages in the install tree. so you end up with srpms and debuginfo rpms in there. So you get 2623 pkgs to read through for fc3 base but if you just read through binary rpms you only have 1653 pkgs to read through. A pretty serious savings, almost 1000 packages. Now, yum prunes out the packages it can't use right away, but it is still having to read through all that data. so why not make the repo like this: createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml . and then make another srpm repository in the SRPMS dir all on its own. Ditto with debuginfo. but then we should add disabled-by-default srpm and debuginfo repos to each .repo file in yum.repos.d fedora.repo: [base] .... enabled=1 [base-srpm] ... enabled=0 [base-debug] .... enabled=0 then the user, if they need the debuginfo rpms, for example, can run: yum --enablerepo=base-debug install foo-debuginfo We should do the same for extras and updates, updates-testing repos, and rawhide too. I think, on the whole, we'd see a huge increase in speed for going through repos b/c we simply would have less data for 95% of the users to go through. -sv

13 23

gnome-vfs2 and cdda
by John Thacker 31 Jan '05

31 Jan '05

So I created bug #137250 a while back, and no one seems to have claimed it. ( https://bugzilla.redhat.com/beta/show_bug.cgi?id=137250 ) I can understand why, as it's a bit complicated. gnome-vfs2 has a CDDA module which uses cdparanoia. By default, it's enabled in /etc/gnome-vfs-2.0/modules/default-modules.conf. However, it doesn't get built because of the unusual location of the cdparanoia include headers in RedHat and Fedora. They're located in /usr/include/cdda/cdda_paranoia.h and /usr/include/cdda/cdda_interface.h instead of just in /usr/include. Therefore, gnome-vfs2 doesn't build the CDDA module, and, since it's enabled in the default configuration, there are tons and tons of warnings when adding new files in totem or anything else which uses gstreamer and/or gnome-vfs2, and prevents totem from playing audio CDs. (Bug 144803 - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144803 ) Other programs which use cdparanoia have been patched to detect the header files in their special location. See various bugs dealing with grip and kde ( such as 62852 ) Why is it in a non-standard place? Well, cdparanoia header files include a file called utils.h that includes a couple standard macros. Originally this wasn't included in RHL because of a reluctance to include a file called utils.h in /usr/include. (See bugs 38223 and 62852) As a result, they were put into /usr/include/cdda. (As it turns out, grip doesn't use utils.h anymore, it seems.) So, there are a couple of options: 1) Comment out the cdda plugin in default-modules.conf. Advantages: easy, no more warnings Disadvantages: still can't play audio CDs in totem 2) Patch gnome-vfs2 build process so that it finds the include files in the proper place Advantages: plugin builds, everything works Disadvantages: possibly annoying 3) (Drop utils.h and?) Put cdparanoia includes in the standard place. Advantages: easy, everything works Disadvantages: someone might want utils.h, changes old workaround, reasons for workaround might still exist I'd like to have some sort of fix for this, or at least a comment or two. I imagine that responsibility for the bug or the proper fix is difficult to identify, though, which probably has slowed things. See also bug 102754 for another problem having to do with compiling using cdparanoia. John Thacker

1 0

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 January 2005