Re: FESCo meeting summary for 2009-06-26
On 02.07.2009 18:54, drago01 wrote: > On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: >> Glen Turner (g...@gdt.id.au) said: That's a really crappy place for that message, though. What's the user supposed to do there... reboot and then go download another 700MB - 4GB? >>> >>> Yes it's a crappy place. I knew that when I suggested it. I just couldn't >>> think of a Javascript hack which would cough up the CPU features even when >>> running under a 32b OS like Windows Xp. Suggestions welcomed. >> >> Dual-arch media. (Which is a pain, and will run into space issues sooner >> or later.) > > I don't see this as an issue for live media (if it is possible to do here). > > We have 700MB x 2 = 1400MB out of 4GB which we can ship on a DVD. > > We can provide an extra link "download CD" if someone really still has > no dvd burner / drive in 2009. Such a dual-arch disc afaics also would be quite interesting for publishing companies that might want to deliver Fedora on a DVD together with their magazines. Otherwise they will definitely chose x86-32, as that's what runs on most systems. CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/03/2009 04:56 AM, Christoph Wickert wrote: > Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: >> On 07/02/2009 09:33 PM, Thomas Janssen wrote: > ... >>> "Books and Guides" even better. >> >> Committed for Fedora 12. > > Correct me if I'm wrong, but new groups in comps are expected to be > ratified by FESCo. Groups don't go through FESCo ratification. http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#New_groups Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
> "MC" == Matej Cepl writes: MC> Well, I always understood, that documentation which is part of MC> normal package is OK, but source package which contains nothing MC> else than documentation isn't. If that was the case, then I see 17 -docs packages that build completely separately from any other package. Some upstreams package their documentation in separate tarballs, and so these can be built from separate source packages. (And often this makes sense, as the documentation package doesn't have to change when a bug is fixed in the main package.) So you could have a rule that says the package has to directly document some program in the distro, but then the Linux device drivers book does just that. I don't think anyone would reasonably want to exclude the python-docs package (built as a separate source package containing nothing other than documentation) but I know I can't articulate just how diveintopython is different. Honestly I think this would be easier if we had a separate content repository, because then the decision wouldn't be about excluding some things completely but instead about which repository to put them in. I recall some discussion about that but I don't know what the end result was. Honestly I don't care either way except that I need to know what to do with this javanotes review ticket I've taken; I'd just like to be able to point people to a clear decision. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 4:26 PM, Christoph Wickert < christoph.wick...@googlemail.com> wrote: > Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: > > On 07/02/2009 09:33 PM, Thomas Janssen wrote: > ... > > > "Books and Guides" even better. > > > > Committed for Fedora 12. > > Correct me if I'm wrong, but new groups in comps are expected to be > ratified by FESCo. > If memory serves, the admonition is "use good judgement, and talk about it on -devel first." -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Dracut now has a wiki page in the Fedora wiki...
The Dracut wiki page has now been moved from my drafts to it's permanent location. https://fedoraproject.org/wiki/Dracut Debugging can be found here https://fedoraproject.org/wiki/Dracut/Debugging Note i'm not sure if the http://fedoraproject.org/wiki/Dracut#Getting_the_Source containst correct git commands hence I've label them #FIXME the maintainer(s) can confirm or fix the entry's It would be nice if someone who actually who's primary language is English reviews and fixes potential ken lee entry's i've made. JBG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Am Donnerstag, den 02.07.2009, 23:10 +0530 schrieb Rahul Sundaram: > On 07/02/2009 09:33 PM, Thomas Janssen wrote: ... > > "Books and Guides" even better. > > Committed for Fedora 12. Correct me if I'm wrong, but new groups in comps are expected to be ratified by FESCo. > Rahul Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Am Donnerstag, den 02.07.2009, 09:48 -0400 schrieb Paul W. Frields: > On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: > > 2009/7/2 Rahul Sundaram : > > > On 07/02/2009 06:15 PM, Frank Murphy wrote: > > > > > >> Is there a book group? > > >> or what search parameter? > > >> Tried yum info "Dive Into Python" > > > > > > # yum info diveintopython > > > > > > Since we have more than one book, I guess a new group could be defined > > > as well. If there is consensus on the name, I can add it. Should we just > > > call it "Books" ? > > > > +1 > > Perhaps something more inclusive like "Documentation" would be good. +1 for "Documentation", -1 for "Books". Books is to generic on the one hand but to graphic on the other (These are no real books). Documentation fits very well and it already is a group in rpm, so IMO we should stick with that. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Jason L Tibbitts III, Thu, 02 Jul 2009 12:32:48 -0500: > Open a ticket on their trac (https://fedorahosted.org/fesco/). Hmm, it *is* complicated. > The issue here is that the guidelines explicitly permit documentation > and help files; diveintopython is obviously documenting Python, and if > it was bundled with the Python tarball then there wouldn't be any > question at all about this. So I'm not really sure that the place where > you draw the line is all that clear. Well, I always understood, that documentation which is part of normal package is OK, but source package which contains nothing else than documentation isn't. But then yes we have man-pages. Hmm. Any thoughts? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 debuginfo packages without sources, build id
Op vrijdag 03-07-2009 om 00:49 uur [tijdzone +0300], schreef Ville Skyttä: > On Thursday 02 July 2009, Erik van Pienbroek wrote: > > > The implementation of mingw32 debuginfo packages has recently been > > discussed on the Fedora-MinGW mailing list: > > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html > [...] > > I think it's best to continue this discussion on the fedora-mingw > > mailing list instead of fedora-devel. There indeed are some issues > > remaining which need to be solved. > > Ok, thanks for the info. I don't think I have much to add to those > discussions, I'm just doing some semi-regular grunt work watching debuginfos > for sanity and wanted to know whether bugs should be filed against the > affected packages, but I gather not at this point as there seems to be some > work in progress. Perhaps you might want to read http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-July/001811.html which sums up my tests of these -debuginfo packages. Some help with adding MinGW32 / PE binaries support to the RPM tool debugedit (/usr/lib/rpm/debugedit) is really welcome. Regards, Erik van Pienbroek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 debuginfo packages without sources, build id
On Thursday 02 July 2009, Erik van Pienbroek wrote: > The implementation of mingw32 debuginfo packages has recently been > discussed on the Fedora-MinGW mailing list: > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html [...] > I think it's best to continue this discussion on the fedora-mingw > mailing list instead of fedora-devel. There indeed are some issues > remaining which need to be solved. Ok, thanks for the info. I don't think I have much to add to those discussions, I'm just doing some semi-regular grunt work watching debuginfos for sanity and wanted to know whether bugs should be filed against the affected packages, but I gather not at this point as there seems to be some work in progress. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf
On Thursday 02 July 2009, Xia Shing Zee wrote: > I'm a new package maintainer, but I'll try dumpasn1 and id3v2 Thanks (ditto to the others who grabbed the rest of the packages). Please go ahead and take ownership of these in pkgdb, they have been orphaned already. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates can't handle multiple bug #s?
I just submitted this update: https://admin.fedoraproject.org/updates/edit/xemacs-21.5.29-1.fc11, which is supposed to close two bugs. When I submitted it, I got this: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. I checked "My updates" before retyping the whole thing and, sure enough, there it is, but with only 1 of the two bug numbers I tried to enter. I've tried editing it several times now, always with an internal server error and no change to the update as a result. I've tried entering the two bug numbers as "xxx xxx", "xxx,xxx", and "#xxx,#xxx", but no joy. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2008 available for testing
On Sunday 28 June 2009 00:13:10 Jindrich Novy wrote: > Currently texlive correctly obsoletes all the old tetex* stuff. I > thought it is a good idea to not to provide the old tetex bits any more > because we have virtual provides for them like tex(latex) or tex(dvips) for > a long time. So it is better to fix the requires on the packages side > requiring TeX. Note that this will work even with the current old > texlive-2007 present in Fedoras. Thanks for the list of packages that > needs to be fixed. Should I bug the respective maintainers? :-) > evince-dvi will need rebuild for the libkpathsea soname bump as soon > as new texlive lands in Fedora. > > Jindrich -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2008 available for testing
On Saturday 27 June 2009 13:41:42 Jindrich Novy wrote: > Good news everyone! > > I've invented a device that installs TeX Live 2008 on your Fedora! > > > TeX Live 2008 is now packaged and available for testing. It is not in > Fedora yet because it requires reviews of couple of packages. But you > can test it before it happens. First of all I would like to thank for the amazing job you have done. Even if most of the work is automatically generated it is not an easy task by any measure. :-) With all that work coming for F12 it would be a bonus if we could come with a set of rules for packaging tex projects. Those guidelines could then go to FPC for approval. With the amount of packages coming now is the time to get this right. One of the issues discussed before but never set is the name space to be used. If I remember the rough consensus was to name packages as tex-packagename or even tex-latex-packagename. Even the packages retain the same name as they are now in your repo you could add a (virtual) Provides so that if later, for any reason, we change the tex distribution we don't need to change every involved package. What is your plan? To use the wiki Feature page as the place of contact for further actions or something else... > Thanks, > Jindrich Regards, -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Missing libxklavier.so.12 dependency
On Thu, 2009-07-02 at 15:02 -0400, Clemens Eisserer wrote: > Hi, > > For a few days now updating rawhide doesn't work, because it misses a > dependency: > > kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems > --> Missing Dependency: libxklavier.so.12 is needed by package > kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) > Error: Missing Dependency: libxklavier.so.12 is needed by package > kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest > > > Is this anything to worry about my system, or will that be fixed anyway? Known breakage, announced here: https://www.redhat.com/archives/fedora-devel-list/2009-July/msg00031.html and fixed here: * Wed Jul 01 2009 Rex Dieter 4.2.95-4 - rebuild (libxklavier) - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 debuginfo packages without sources, build id
Op woensdag 01-07-2009 om 21:02 uur [tijdzone +0300], schreef Ville Skyttä: > Hello, > > I noticed a bunch of mingw32*-debuginfo packages that contain only *.debug > (no > sources, no build id) appeared in Rawhide. Is this how mingw32 debuginfo > packages are supposed to look like, or is the infrastructure for creating the > debuginfo packages not quite complete, or are these packaging bugs? > > mingw32-boost-debuginfo-1.39.0-2.fc12.noarch > mingw32-cairomm-debuginfo-1.8.0-3.fc12.noarch > mingw32-glib2-debuginfo-2.21.2-2.fc12.noarch > mingw32-glibmm24-debuginfo-2.20.0-4.fc12.noarch > mingw32-gtkmm24-debuginfo-2.16.0-2.fc12.noarch > mingw32-libglade2-debuginfo-2.6.4-3.fc12.noarch > mingw32-libglademm24-debuginfo-2.6.7-7.fc12.noarch > mingw32-libgnurx-debuginfo-2.5.1-5.fc12.noarch > mingw32-libsigc++20-debuginfo-2.2.2-8.fc12.noarch > mingw32-libsqlite3x-debuginfo-20071018-8.fc12.noarch > mingw32-libxml++-debuginfo-2.26.0-2.fc12.noarch > mingw32-pangomm-debuginfo-2.24.0-3.fc12.noarch > mingw32-plotmm-debuginfo-0.1.2-3.fc12.noarch > mingw32-qt-debuginfo-4.5.2-1.fc12.noarch > mingw32-qwt-debuginfo-5.1.1-8.fc12.noarch > mingw32-sqlite-debuginfo-3.6.14.2-1.fc12.noarch > mingw32-tcl-debuginfo-8.5.7-6.fc12.noarch > mingw32-wpcap-debuginfo-4.1.beta5-6.fc12.noarch > mingw32-zfstream-debuginfo-20041202-6.fc12.noarch Hi, The implementation of mingw32 debuginfo packages has recently been discussed on the Fedora-MinGW mailing list: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001613.html At the moment we just started experimenting with it in rawhide and we haven't really got to thorough testing yet (due to FUDCON and a bug in mash which has just been solved). Initially only two mingw32 packages should have got -debuginfo support (just enough to perform tests), but due to a small mis-communication several other packages also got updated. I think it's best to continue this discussion on the fedora-mingw mailing list instead of fedora-devel. There indeed are some issues remaining which need to be solved. Regards, Erik van Pienbroek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (A)synchronous file operations & xdg-open
On Thu, Jul 2, 2009 at 12:47 PM, Colin Walters wrote: > I think the easiest fix here is for the app not to delete the > temporary file immediately after the helper exits. Just write it in > $TMPDIR and let tempreaper come along and eat it later. I am an XEmacs developer, and I would like to fix this upstream. We may have users on systems with xdg-open but without tmpreaper. I'll take that discussion to the upstream list, however. Thanks for the suggestion. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Missing libxklavier.so.12 dependency
Hi, For a few days now updating rawhide doesn't work, because it misses a dependency: kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems --> Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) Error: Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Is this anything to worry about my system, or will that be fixed anyway? Thanks, Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (A)synchronous file operations & xdg-open
On Thu, Jul 2, 2009 at 2:30 PM, Jerry James wrote: > > > I am more and more of the opinion that xdg-open is simply the wrong > tool for viewing/editing temporary files. It wasn't built for that > use case, and the tools it invokes were not either. I think the easiest fix here is for the app not to delete the temporary file immediately after the helper exits. Just write it in $TMPDIR and let tempreaper come along and eat it later. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 9:43 AM, Bill Nottingham wrote: > Of course, I suspect we'll now have someone claiming that the camel > book is actually a religous text. > So say we all! :) -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (A)synchronous file operations & xdg-open
On 07/03/2009 12:00 AM, Jerry James wrote: > > I am more and more of the opinion that xdg-open is simply the wrong > tool for viewing/editing temporary files. It wasn't built for that > use case, and the tools it invokes were not either. I think we need > something different altogether. Should we go back to invoking > $EDITOR, $VISUAL, etc.? ... or talk to the xdg-utils upstream developers and see if we can get a new tool added that serves our purpose. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 02:10 PM, Adam Williamson wrote: > On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: >> I'm not sure how distributable the KJV is or isnt' > > It's been out of copyright for some little time, now. Probably.(*) > > * Of course, one could potentially make some quite interesting legal > arguments about the author credit, and whether said author counts as > 'living' within the terms of copyright laws that grant copyright during > the lifetime of the author... Translations are generally considered to by copyrighted, even when the original work may not be. Regardless, we're not including religious texts in Fedora as content. Period. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (A)synchronous file operations & xdg-open
On Thu, Jun 25, 2009 at 12:32 PM, Ville Skyttä wrote: > IMO the latter is clearly preferable, and would be even a good default. But > then again, it might be too late to change the default as it could break stuff > (even if the xdg-open man page doesn't document async/sync operation at the > moment). And I'm not sure if the tools xdg-open invokes have async/sync > operation modes - at least some of them would quite probably need > modifications as well. So xdg-open currently invokes the following tools, depending on desktop: KDE: kfmclient GNOME: gnome-open XFCE: exo-open If the desktop is something else, it runs the first of these tools it can find, checking in this order: mimeopen, run-mailcap, each element of $BROWSER, htmlview, firefox, mozilla, netscape, links, lynx. We already know that gnome-open operates in asynchronous mode. In https://bugzilla.redhat.com/show_bug.cgi?id=435107, Kevin Kofler says that kfmclient is also asynchronous. Does anybody know about exo-open? The desktop-agnostic tools are all aimed at displaying random URLs to the user, and would not be appropriate for the "edit a temporary file" use-case we're talking about. I am more and more of the opinion that xdg-open is simply the wrong tool for viewing/editing temporary files. It wasn't built for that use case, and the tools it invokes were not either. I think we need something different altogether. Should we go back to invoking $EDITOR, $VISUAL, etc.? -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: > I'm not sure how distributable the KJV is or isnt' It's been out of copyright for some little time, now. Probably.(*) * Of course, one could potentially make some quite interesting legal arguments about the author credit, and whether said author counts as 'living' within the terms of copyright laws that grant copyright during the lifetime of the author... ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
No FESCo meeting for 2009-07-03
Due to the US holiday, FESCo will not hold it's regularly scheduled meeting tomorrow. All business will be postponed until next week. Have a great 4th if you're in the US, and if you're anywhere else, have a great 4th anyway! :) -Jon -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 09:33 PM, Thomas Janssen wrote: > 2009/7/2 Paul W. Frields : >> On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: >>> 2009/7/2 Rahul Sundaram : On 07/02/2009 06:15 PM, Frank Murphy wrote: > Is there a book group? Since we have more than one book, I guess a new group could be defined as well. If there is consensus on the name, I can add it. Should we just call it "Books" ? >>> >>> +1 >> >> Perhaps something more inclusive like "Documentation" would be good. >> It's possible that the Docs team might produce some content that would >> be useful here as well. Or alternately, "Books and Guides"? > > "Books and Guides" even better. Committed for Fedora 12. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
This might not be a big thing, but I was always rather annoyed that KDE applications didn't integrate nicely into the GNOME desktop. When KDE is the desktop, GNOME applications (except XUL based ones) looked very much in place and felt normal in a KDE system. KDE applications in a GNOME desktop tend to ignore GNOME and stick out like a sore thumb. Note that I mean KDE applications and not Qt applications. Qt applications (like VLC) fit right in GNOME. On Thu, Jul 2, 2009 at 12:34 PM, Matthias Clasen wrote: > On Tue, 2009-06-30 at 13:55 -0400, Christopher Beland wrote: > > On Mon, 2009-06-29 at 15:27 -0400, Matthias Clasen wrote: > > > If you have ideas for > > > other areas that could benefit from this kind of attention, please let > > > us know. > > > > I can think of a number of different cross-component tests... > > [...] > > Yeah, this is a very nice checklist for 'basic sanity'. And any bug you > file about a problem in one of those categories certainly qualifies as a > 'fit and finish' issue. But as a test day topic, it might be a bit > boring to spend the whole day testing e.g. copy-and-paste between app X > and Y to fill a big matrix... > > > Matthias > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
On Tue, 2009-06-30 at 13:55 -0400, Christopher Beland wrote: > On Mon, 2009-06-29 at 15:27 -0400, Matthias Clasen wrote: > > If you have ideas for > > other areas that could benefit from this kind of attention, please let > > us know. > > I can think of a number of different cross-component tests... [...] Yeah, this is a very nice checklist for 'basic sanity'. And any bug you file about a problem in one of those categories certainly qualifies as a 'fit and finish' issue. But as a test day topic, it might be a bit boring to spend the whole day testing e.g. copy-and-paste between app X and Y to fill a big matrix... Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
> "MC" == Matej Cepl writes: MC> So, how should I propose to FESCO exclusion of DiveIntoPython MC> (BTW, wonderful book), Jules Verne and anything else we find? Open a ticket on their trac (https://fedorahosted.org/fesco/). The issue here is that the guidelines explicitly permit documentation and help files; diveintopython is obviously documenting Python, and if it was bundled with the Python tarball then there wouldn't be any question at all about this. So I'm not really sure that the place where you draw the line is all that clear. At least the python package itself includes some reasonable documentation about the language. But the package that spawned this duscussion, the device drivers book, actually documents the kernel where the kernel doesn't really document itself. And there are other reviews for this kind of thing pending: javanotes, for example (https://bugzilla.redhat.com//show_bug.cgi?id=507916) covers Java for which we have little in-distro documentation, and there's at least one other package submitted by the same person. Make sure that the line you draw is clear with regards those packages as well. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging fix in boost
On 07/02/2009 10:45 PM, Petr Machata wrote: > Hi, > > recently we've (that's "we" as in me and Benjamin Kosnik, not a royal > "we") broken up boost to sub-packages in Fedora Rawhide, but we forgot > to drop a filelist at the main boost package, intended as an umbrella > over all the sub-packages. So in the end, main boost package was still > as big as it always was and all benefits (and bugs) that the split could > bring were lost. Meh. > > boost-1.39.0-3.fc12 that should fix the above is being built right now. > Maintainers of dependent packages, especially those that are known to > be on the Live CD, might want to consider a rebuild. Thanks for fixing this problem. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
packaging fix in boost
Hi, recently we've (that's "we" as in me and Benjamin Kosnik, not a royal "we") broken up boost to sub-packages in Fedora Rawhide, but we forgot to drop a filelist at the main boost package, intended as an umbrella over all the sub-packages. So in the end, main boost package was still as big as it always was and all benefits (and bugs) that the split could bring were lost. Meh. boost-1.39.0-3.fc12 that should fix the above is being built right now. Maintainers of dependent packages, especially those that are known to be on the Live CD, might want to consider a rebuild. Thanks, PM signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Bill Nottingham, Thu, 02 Jul 2009 12:43:10 -0400: > I'm not sure how distributable the KJV is or isnt', but it's explicitly > forbidden by the guidelines. > > Of course, I suspect we'll now have someone claiming that the camel book > is actually a religous text. Of course, and GNU Manifesto! But, no I wasn't seriously suggesting we should package Bibles (and Quaran etc. ... Fedora ME anyone http://www.sabily.org/website/ ? :)), just that if one goes other ones shouldn't as well. So, how should I propose to FESCO exclusion of DiveIntoPython (BTW, wonderful book), Jules Verne and anything else we find? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 02, 2009 at 06:30:50PM +0200, Till Maas wrote: >On Thu July 2 2009, Josh Boyer wrote: >> On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: > >> >No I didn't. Are the details published anywhere of how to request access? >> >> I'm working on it. Basically, email dwmw2 or me an ssh public key. > >I added this information to the PPC Sig wiki page: >https://fedoraproject.org/wiki/Architectures/PowerPC#PPC_Shell_access_for_debugging > Thanks. That's where I was going to add it too after doing some rework to that page. I'll be sure not to accidentally delete it when I do :) josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: > > Of course, I suspect we'll now have someone claiming that the camel > book is actually a religous text. > For the love of Larry, have you no respect? -- Mat Booth www.matbooth.co.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Package reviews
Hi All, I'm working to get the core moblin packages into Fedora with the plan of having at least experimental support in time for F-12. If you've got a few spare cycles and have some time to review a package there's a list against the tracker bug here. https://bugzilla.redhat.com/show_bug.cgi?id=506446 Regards, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
2009/7/2 Paul W. Frields : > On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: >> 2009/7/2 Rahul Sundaram : >> > On 07/02/2009 06:15 PM, Frank Murphy wrote: >> > >> >> Is there a book group? >> > >> > Since we have more than one book, I guess a new group could be defined >> > as well. If there is consensus on the name, I can add it. Should we just >> > call it "Books" ? >> >> +1 > > Perhaps something more inclusive like "Documentation" would be good. > It's possible that the Docs team might produce some content that would > be useful here as well. Or alternately, "Books and Guides"? "Books and Guides" even better. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottingham wrote: > Glen Turner (g...@gdt.id.au) said: >>> That's a really crappy place for that message, though. What's the user >>> supposed to do there... reboot and then go download another 700MB - 4GB? >> >> Yes it's a crappy place. I knew that when I suggested it. I just couldn't >> think of a Javascript hack which would cough up the CPU features even when >> running under a 32b OS like Windows Xp. Suggestions welcomed. > > Dual-arch media. (Which is a pain, and will run into space issues sooner > or later.) I don't see this as an issue for live media (if it is possible to do here). We have 700MB x 2 = 1400MB out of 4GB which we can ship on a DVD. We can provide an extra link "download CD" if someone really still has no dvd burner / drive in 2009. This also would allow us to add software like openoffice to the live media (which is ommited for space reasons because we insist on the pointless cd limit). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Matej Cepl (mc...@redhat.com) said: > And even more seriously ... sword (library for retrieval and search > through big texts used mainly by Biblical software like bibletime or > xiphos) could really use some texts ... Biblical program without any > content seems kind of bare, and I think KJV is distributable just fine. I'm not sure how distributable the KJV is or isnt', but it's explicitly forbidden by the guidelines. Of course, I suspect we'll now have someone claiming that the camel book is actually a religous text. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu July 2 2009, Josh Boyer wrote: > On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: > >No I didn't. Are the details published anywhere of how to request access? > > I'm working on it. Basically, email dwmw2 or me an ssh public key. I added this information to the PPC Sig wiki page: https://fedoraproject.org/wiki/Architectures/PowerPC#PPC_Shell_access_for_debugging Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, 2 Jul 2009, Matej Cepl wrote: Kevin Kofler, Thu, 02 Jul 2009 17:07:39 +0200: It's also a hard decision where to draw the line: will you accept a PDF of Jules Verne's Around the World in 80 Days (which is in the public domain) as well? What exact criteria make Dive into Python OK and Around the World in 80 Days not? And even more seriously ... sword (library for retrieval and search through big texts used mainly by Biblical software like bibletime or xiphos) could really use some texts ... Biblical program without any content seems kind of bare, and I think KJV is distributable just fine. no. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Julian Sikorski, Thu, 02 Jul 2009 17:30:04 +0200: > I think the main point here should be what advantage does packaging > books have. Are there any book readers that look into > /usr/share/yourfavouritebook by default? If not, I think that's actually > easier to open a file you have lying on your desktop or your docs dir > (where your recently opened files most likely are) than to dig through > the filesystem. Well, my sword example would be more complicated than just a file on Desktop. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Kevin Kofler, Thu, 02 Jul 2009 17:07:39 +0200: > It's also a hard decision where to draw the line: will you accept a PDF > of Jules Verne's Around the World in 80 Days (which is in the public > domain) as well? What exact criteria make Dive into Python OK and Around > the World in 80 Days not? And even more seriously ... sword (library for retrieval and search through big texts used mainly by Biblical software like bibletime or xiphos) could really use some texts ... Biblical program without any content seems kind of bare, and I think KJV is distributable just fine. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
Peter Robinson wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use "make V=1" so we see the actual build command lines in the build.log (see the thread about the new automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as does the package seems to play dirty games with CFLAGS. I haven't checked details, though. FWIW: Build breakdowns on ppc64 often are caused by not passing RPM_OPT_FLAGS correctly or a package playing dirty games with CFLAGS/CXXFLAGS. The dirty games were to try and work out this issue with PPC64 (it built fine on the rest of them) Well, this is expected ;) AFAICT, on the ppc64, the default/implicit -mXXX flags in GCC diverge from what is in RPM_OPT_FLAGS, so you end up with incorrectly compiled binaries, if not correctly passing through RPM_OPT_FLAGS. Conversely, if not passing RPM_OPT_FLAGS, one often gets away with "no build-breakdowns" on all targets, but is facing the kind of issue your are facing on the ppc64. Furthermore, several GCC flags people are using in dirty CFLAGS tricks often actually are target-specific, which will cause build-breakdowns on more exotic target. -ggdb is one of these non-portable options, but I am not sufficiently familiar with RH's ppc64 to be able to judge if -ggdb is valid on RH-ppc64. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu July 2 2009, Kevin Kofler wrote: > It's also a hard decision where to draw the line: will you accept a PDF of > Jules Verne's Around the World in 80 Days (which is in the public domain) > as well? What exact criteria make Dive into Python OK and Around the World > in 80 Days not? Dive into python is additional documentation to software we ship in Fedora. The Jule Verne Book is not. Nevertheless it would be nice to have a central repository for entertaining free content. Btw. an even older content older package is "man-pages". Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 02, 2009 at 04:51:50PM +0100, Peter Robinson wrote: >>> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >>> > >>> > Unrelated to this issue, but please use "make V=1" so we see the actual >>> > build command lines in the build.log (see the thread about the new >>> > automake). >>> >>> With V=1 >>> >>> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log >> >> You know you can have access to a real box to test this on if you want >> it, right? You don't have to do it all in koji and look at the build >> logs. > >No I didn't. Are the details published anywhere of how to request access? I'm working on it. Basically, email dwmw2 or me an ssh public key. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
> Does this look ok? > > --- comps-f12.xml.in.orig 2009-07-02 15:39:02.0 +0530 > +++ comps-f12.xml.in 2009-07-02 19:49:32.108616562 +0530 > @@ -520,6 +520,17 @@ > > > > + books > + <_name>Technical Books > + <_description/> > + false > + true > + > + diveintopython > + ldd-pdf > + > + > + > buildsys-build > <_name>Buildsystem building group > <_description/> What if we start including non-technical books (like educational material for the OLPC) ? If the group name is "Technical books", so should be the group id don't you think ? Might be bikeshedding, but if we can avoid closing some doors... -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 5:19 PM, Adam Miller wrote: > On Thu, Jul 2, 2009 at 10:14 AM, drago01 wrote: >> "If the content enhances the OS user experience, then the content is >> OK to be packaged in Fedora. This means, for example, that things >> like: fonts, themes, clipart, and wallpaper are OK. " >> >> So does a programming book enhance the OS user experience? > > That's subject to opinion which is exactly why this policy is flawed. I know (there is a reason why I did not provide an answer to this question) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
>> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >> > >> > Unrelated to this issue, but please use "make V=1" so we see the actual >> > build command lines in the build.log (see the thread about the new >> > automake). >> >> With V=1 >> >> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log > > You know you can have access to a real box to test this on if you want > it, right? You don't have to do it all in koji and look at the build > logs. No I didn't. Are the details published anywhere of how to request access? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 >>> >>> Unrelated to this issue, but please use "make V=1" so we see the actual >>> build command lines in the build.log (see the thread about the new >>> automake). >> >> With V=1 >> >> http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log > > AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as > does the package seems to play dirty games with CFLAGS. I haven't checked > details, though. > > FWIW: Build breakdowns on ppc64 often are caused by not passing > RPM_OPT_FLAGS correctly or a package playing dirty games with > CFLAGS/CXXFLAGS. The dirty games were to try and work out this issue with PPC64 (it built fine on the rest of them) and it seems your right with the dirty CFLAGS game as it broke other previous working ones. This rev of the spec file was the one that worked on all but ppc64. http://cvs.fedoraproject.org/viewvc/rpms/gobject-introspection/devel/gobject-introspection.spec?revision=1.9&view=markup Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 08:37 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Yes and this is not even the first time. Dive Into Python has been in >> the repo for ages already. > > That doesn't mean it's compliant with our guidelines on shipping content. I > really don't see what benefit it gives us to have a package dumping some > book into /usr/share. Can't it be given as a regular download on a website? > Possibly even the Fedora wiki. But packages sound to me like a completely > overkill format to distribute PDF books. We have heard both sides of the argument in detail several times now and I doubt there is value in debating it one more time on the list. So take it up to FESCo if you think there is some violation of guidelines. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
Peter Robinson wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use "make V=1" so we see the actual build command lines in the build.log (see the thread about the new automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log AFAIS, your spec doesn't seem to pass RPM_OPT_FLAGS correctly, as well as does the package seems to play dirty games with CFLAGS. I haven't checked details, though. FWIW: Build breakdowns on ppc64 often are caused by not passing RPM_OPT_FLAGS correctly or a package playing dirty games with CFLAGS/CXXFLAGS. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, 2009-07-02 at 16:28 +0100, Peter Robinson wrote: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 > > > > Unrelated to this issue, but please use "make V=1" so we see the actual > > build command lines in the build.log (see the thread about the new > > automake). > > With V=1 > > http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log You know you can have access to a real box to test this on if you want it, right? You don't have to do it all in koji and look at the build logs. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Glen Turner (g...@gdt.id.au) said: >> That's a really crappy place for that message, though. What's the user >> supposed to do there... reboot and then go download another 700MB - 4GB? > > Yes it's a crappy place. I knew that when I suggested it. I just couldn't > think of a Javascript hack which would cough up the CPU features even when > running under a 32b OS like Windows Xp. Suggestions welcomed. Dual-arch media. (Which is a pain, and will run into space issues sooner or later.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 10:39 AM, David wrote: > OK, but if the package payload doesn't interoperate with another > package, I can't see the point. Fonts, artwork, sure, they are a > system resource for other software. By that logic a book distributed in PDF is a "system resource" for my pdf viewer just as artwork is a "system resource" for my desktop environment's background manager. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Fri, Jul 3, 2009 at 1:23 AM, Rahul Sundaram wrote: > On 07/02/2009 08:51 PM, David wrote: > >> I disagree that Fedora should be packaging books, both of these can >> easily be downloaded via web. >> Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. OK, but if the package payload doesn't interoperate with another package, I can't see the point. Fonts, artwork, sure, they are a system resource for other software. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 02, 2009 at 08:53:52PM +0530, Rahul Sundaram wrote: > On 07/02/2009 08:51 PM, David wrote: > > > I disagree that Fedora should be packaging books, both of these can > > easily be downloaded via web. > > Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. Arguably, this particular content can be helpful for cultivating contribution, i.e. training developers. Perhaps there is a reasonably objective standard to be found there for content, but I'm not sure it captures everything we hope to include in the future. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 anaconda incompatible with current F10 yum - WTF
On Wed, Jul 1, 2009 at 5:47 PM, Kevin Kofler wrote: > Xavier Toth wrote: >> So I do a yum update, pickup a yum that isn't compatible with the >> original anaconda and then can no longer make installable DVD's. This >> is busted! If anaconda is dependent on a specific version of yum then >> it's Requires need to be equal to that version and not greater than or >> equal to. > > That would just replace the runtime error with a broken dependency. The only > solution is to release an anaconda update matching the yum update. We > really need anaconda updates for the benefit of respins! Anaconda not > working with the current update yum is a serious regression and we need a > matching Anaconda update ASAP. > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > It's a one liner. --- anaconda-11.5.0.12/yuminstall.py.orig 2009-06-30 09:05:19.0 -0500 +++ anaconda-11.5.0.12/yuminstall.py2009-06-30 09:06:03.0 -0500 @@ -575,8 +575,7 @@ YumSorter.getReposFromConfig(self) # Override this method so yum doesn't nuke our existing logging config. -def doLoggingSetup(self, debuglevel, errorlevel, syslog_indent=None, - syslog_facility=None): +def doLoggingSetup(self, *args, **kwargs): pass def doConfigSetup(self, fn='/tmp/anaconda-yum.conf', root='/'): Ted -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Rahul Sundaram pisze: > On 07/02/2009 08:51 PM, David wrote: > >> I disagree that Fedora should be packaging books, both of these can >> easily be downloaded via web. >> Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. > > Rahul > I think the main point here should be what advantage does packaging books have. Are there any book readers that look into /usr/share/yourfavouritebook by default? If not, I think that's actually easier to open a file you have lying on your desktop or your docs dir (where your recently opened files most likely are) than to dig through the filesystem. Julian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 > > Unrelated to this issue, but please use "make V=1" so we see the actual > build command lines in the build.log (see the thread about the new > automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 08:51 PM, David wrote: > I disagree that Fedora should be packaging books, both of these can > easily be downloaded via web. > Why package something that has no dependencies? We package hundreds of things that have no dependencies and can be downloaded easily via web including fonts. That is not a argument. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 10:41 PM, Rahul Sundaram wrote: > On 07/02/2009 06:03 PM, drago01 wrote: >> On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report >> wrote: >>> Compose started at Thu Jul 2 06:15:05 UTC 2009 >>> ... >>> New package ldd-pdf >>> Linux Device Drivers, Third Edition Book in PDF format >> >> We ship books as packages? > > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. I disagree that Fedora should be packaging books, both of these can easily be downloaded via web. Why package something that has no dependencies? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 08:45 PM, drago01 wrote: > > If we want to go this route, why limit it to technical books? That's what is currently available. The description can be changed if policy is. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 10:14 AM, drago01 wrote: > "If the content enhances the OS user experience, then the content is > OK to be packaged in Fedora. This means, for example, that things > like: fonts, themes, clipart, and wallpaper are OK. " > > So does a programming book enhance the OS user experience? That's subject to opinion which is exactly why this policy is flawed. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 4:22 PM, Rahul Sundaram wrote: > On 07/02/2009 06:58 PM, Adam Miller wrote: >> +1 on the Books idea > > Does this look ok? > > --- comps-f12.xml.in.orig 2009-07-02 15:39:02.0 +0530 > +++ comps-f12.xml.in 2009-07-02 19:49:32.108616562 +0530 > @@ -520,6 +520,17 @@ > > > > + books > + <_name>Technical Books > + <_description/> > + false > + true > + > + diveintopython > + ldd-pdf > + > + > + > buildsys-build > <_name>Buildsystem building group > <_description/> > If we want to go this route, why limit it to technical books? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 5:07 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Yes and this is not even the first time. Dive Into Python has been in >> the repo for ages already. > > That doesn't mean it's compliant with our guidelines on shipping content. I > really don't see what benefit it gives us to have a package dumping some > book into /usr/share. Can't it be given as a regular download on a website? > Possibly even the Fedora wiki. But packages sound to me like a completely > overkill format to distribute PDF books. +1 http://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content "If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. " So does a programming book enhance the OS user experience? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Rahul Sundaram wrote: > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. That doesn't mean it's compliant with our guidelines on shipping content. I really don't see what benefit it gives us to have a package dumping some book into /usr/share. Can't it be given as a regular download on a website? Possibly even the Fedora wiki. But packages sound to me like a completely overkill format to distribute PDF books. It's also a hard decision where to draw the line: will you accept a PDF of Jules Verne's Around the World in 80 Days (which is in the public domain) as well? What exact criteria make Dive into Python OK and Around the World in 80 Days not? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
Peter Robinson wrote: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use "make V=1" so we see the actual build command lines in the build.log (see the thread about the new automake). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Thu, Jul 2, 2009 at 12:16 PM, Glen Turner wrote: > On 30/06/09 01:39, Bill Nottingham wrote: >> >> That's a really crappy place for that message, though. What's the user >> supposed to do there... reboot and then go download another 700MB - 4GB? > > Yes it's a crappy place. I knew that when I suggested it. I just couldn't > think of a Javascript hack which would cough up the CPU features even when > running under a 32b OS like Windows Xp. Suggestions welcomed. Ah, on OS like Windows, maybe ActiveX helps. I don't have such a beast at the minute to test, but maybe this[1] works. [1] http://www.devarticles.com/c/a/JavaScript/How-to-Use-JavaScript-for-Hardware-Knowledge/1/ -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 06:58 PM, Adam Miller wrote: > +1 on the Books idea Does this look ok? --- comps-f12.xml.in.orig 2009-07-02 15:39:02.0 +0530 +++ comps-f12.xml.in2009-07-02 19:49:32.108616562 +0530 @@ -520,6 +520,17 @@ +books +<_name>Technical Books +<_description/> +false +true + + diveintopython + ldd-pdf + + + buildsys-build <_name>Buildsystem building group <_description/> Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 03:26 PM, Peter Robinson wrote: Hi Harald, On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: Here it is, dracut-0.3! Thanks for your efforts, this is excellent. We've started using it for OLPC's F11 spin, including our own modules to implement OLPC features. So much nicer than what we had before! However, the spec file already pulls in a lot of dependencies, things like device-mapper and cryptsetup which we won't need. Especially for XO-1 we need to work to keep images small (1GB hard disk). Is there any chance that this could be split up, and the more exotic dependencies moved into subpackages? Cheers, Daniel The idea is to pregenerate a generic initrd and package it in an rpm and deliver it together with the kernel. There should be no need to generate the initrd on an X0-1 itsself. How does this work for changing plymouth spash plugins as I seem to remember these are installed into the initrd? Peter Right, didn't think of that one.. ah well.. maybe package all plugins and make the theme selectable on the command line. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 03:07 PM, Harald Hoyer wrote: On 07/02/2009 12:59 PM, Harald Hoyer wrote: Here it is, dracut-0.3! Featuring booting from all kind of block devices, NFS, iSCSI and NBD. Dracut is a new initramfs infrastructure. It should replace nash/mkinitrd. Dracut is a feauture for Fedora 12 http://fedoraproject.org/wiki/Features/Dracut How to get started, if you want to test. # yum install dracut-0.3 To generate a initramfs image, run: # dracut to overwrite an existing image: # dracut -f Try to boot from that image by modifying /etc/grub.conf. Be sure to have a fallback entry. If you want to boot from network have a look at the manpage. Basically everything can be specified on the kernel command line. Bug reports can be send directly to me (har...@redhat.com) until dracut appears in the bugzilla component list. Further information about dracut: http://sourceforge.net/apps/trac/dracut/wiki Ok, it seems the debug dracut module wants to be installed automatically, due to a bug. You either have all binaries which are needed by the dracut debug module, or create the images with: # dracut --omit debug Oh, and here are the Fedora 11 rpms https://koji.fedoraproject.org/koji/buildinfo?buildID=112659 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
>> Interestingly with -ggdb it builds fine with out without -O0. > > That makes it a lot more likely to be a compiler flaw (though not guaranteed). > > Does 'make check' pass in the source tree you built with -O0? > > A backtrace would still be great though. Try setting DEBUG=fcatch in > the environment. Some day hopefully ABRT will come and do this > transparently and automatically... A -O0 segfaults in x86 too so I just discovered :-( It seems also that the frysk package isn't built in rawhide ppc and I'm not sure if there's any other bits I need to add to it. The make clean is on this koji report. http://koji.fedoraproject.org/koji/getfile?taskID=1449535&name=build.log Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 02, 2009 at 02:52:59PM +0200, Thomas Janssen wrote: > 2009/7/2 Rahul Sundaram : > > On 07/02/2009 06:15 PM, Frank Murphy wrote: > > > >> Is there a book group? > >> or what search parameter? > >> Tried yum info "Dive Into Python" > > > > # yum info diveintopython > > > > Since we have more than one book, I guess a new group could be defined > > as well. If there is consensus on the name, I can add it. Should we just > > call it "Books" ? > > +1 Perhaps something more inclusive like "Documentation" would be good. It's possible that the Docs team might produce some content that would be useful here as well. Or alternately, "Books and Guides"? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 2, 2009 at 9:20 AM, Peter Robinson wrote: > > Interestingly with -ggdb it builds fine with out without -O0. That makes it a lot more likely to be a compiler flaw (though not guaranteed). Does 'make check' pass in the source tree you built with -O0? A backtrace would still be great though. Try setting DEBUG=fcatch in the environment. Some day hopefully ABRT will come and do this transparently and automatically... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
+1 on the Books idea but I feel obligated to do something along the lines of: But I shall refrain. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
>> Hi Harald, >> >> On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: >>> >>> Here it is, dracut-0.3! >> >> Thanks for your efforts, this is excellent. >> >> We've started using it for OLPC's F11 spin, including our own modules to >> implement OLPC features. So much nicer than what we had before! >> >> However, the spec file already pulls in a lot of dependencies, things >> like device-mapper and cryptsetup which we won't need. Especially for >> XO-1 we need to work to keep images small (1GB hard disk). >> >> Is there any chance that this could be split up, and the more exotic >> dependencies moved into subpackages? >> >> Cheers, >> Daniel >> >> > > The idea is to pregenerate a generic initrd and package it in an rpm and > deliver it together with the kernel. There should be no need to generate the > initrd on an X0-1 itsself. How does this work for changing plymouth spash plugins as I seem to remember these are installed into the initrd? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, Jul 2, 2009 at 11:49 AM, Colin Walters wrote: > On Thu, Jul 2, 2009 at 6:29 AM, Peter Robinson wrote: >> Hi All, >> >> I've having some issues with a PPC64 build and was wondering if >> someone a bit more ppc savy could have a poke. > > A backtrace would be really useful here (remember to build with -ggdb > -O0 for extra usefulness). > > The typelib code is fairly heavy on lowlevel C bit-twiddling so it's > not unlikely this is an upstream issue. Interestingly with -ggdb it builds fine with out without -O0. With -O0 http://koji.fedoraproject.org/koji/taskinfo?taskID=1449368 Without. http://koji.fedoraproject.org/koji/taskinfo?taskID=1449389 Regards, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Paul W. Frields wrote: > On Tue, Jun 30, 2009 at 10:45:19AM +0100, Andrew Haley wrote: >> In Ubuntu there's a "Help" button on the top menu bar that leads to a >> nice help application, yelp. We have that app too, but it doesn't >> seem to have the same contents, which are: >> >> New to Ubuntu? >> Adding and Removing Software >> Files, Folders and Documents >> Customising Your Desktop >> Internet >> Music, Videos and Photos >> Assistive Tools >> Keeping Your Computer Safe >> Printing, Faxing and Scanning >> Advanced Topics >> >> And under each section there's a clear explanation of what to do. >> Maybe we have something equivalent for Fedora, but I can't find it. > > Perhaps this is something you could raise separately with the Fedora > Docs team. OK, will do. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: certificate not (yet) active?
Am Donnerstag, den 02.07.2009, 14:02 +0200 schrieb Till Maas:
> On Thu July 2 2009, Christoph Höger wrote:
>
> > I had to create a new .fedora.cert this morning, because make
> > new-sources told me mine was out of date.
> > So I did but now make build runs into
> >
> > Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate
> > verify failed')]
> >
> > why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*)
>
> Maybe you need to run fedora-packager-setup from fedora-packager again. If
> you
> edited your koji.conf, you may re-add your changes btw.
>
Thanks, that worked it out. It isn't the easiest thing to package from
two pcs and keep their data in sync.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 12:59 PM, Harald Hoyer wrote: Here it is, dracut-0.3! Featuring booting from all kind of block devices, NFS, iSCSI and NBD. Dracut is a new initramfs infrastructure. It should replace nash/mkinitrd. Dracut is a feauture for Fedora 12 http://fedoraproject.org/wiki/Features/Dracut How to get started, if you want to test. # yum install dracut-0.3 To generate a initramfs image, run: # dracut to overwrite an existing image: # dracut -f Try to boot from that image by modifying /etc/grub.conf. Be sure to have a fallback entry. If you want to boot from network have a look at the manpage. Basically everything can be specified on the kernel command line. Bug reports can be send directly to me (har...@redhat.com) until dracut appears in the bugzilla component list. Further information about dracut: http://sourceforge.net/apps/trac/dracut/wiki Ok, it seems the debug dracut module wants to be installed automatically, due to a bug. You either have all binaries which are needed by the dracut debug module, or create the images with: # dracut --omit debug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 02:23 PM, John5342 wrote: 2009/7/2 Harald Hoyer: On 07/02/2009 01:25 PM, Daniel Drake wrote: On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: The idea is to pregenerate a generic initrd and package it in an rpm and deliver it together with the kernel. There should be no need to generate the initrd on an X0-1 itsself. Is it going to work like this in standard Fedora too? Or will dracut be invoked like mkinitrd is today, that is at RPM-install time on the target system? Daniel My personal target is to deliver the initrd image with the kernel. For performance issues or special needs one can install dracut and generate his own image, if new kernels are installed. We will see, if can work that way. Can i just point out that i am probably not the only one to require omitting some modules and adding others to the initrd image. With the current setup i run mkinitrd once when i first install (using rescue disk) and then these altered options are remembered so it creates the correct initrd whenever the kernel is updated. If i understand correctly and the initrd images are pre-generated within an rpm then my mods will be overwritten on each update and i would presumably need to run dracut manually after each kernel update to replace the pregenerated initrd. That would be a major regression and surely cannot be allowed to happen. Please accept my apologies if i got it all wrong. As I said, "For performance issues or special needs one can install dracut and generate his own image, if new kernels are installed." .. surely this will be done automatically, if you install dracut and there is /etc/dracut.conf where you can configure additional kernel modules and your needs. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
2009/7/2 Rahul Sundaram : > On 07/02/2009 06:15 PM, Frank Murphy wrote: > >> Is there a book group? >> or what search parameter? >> Tried yum info "Dive Into Python" > > # yum info diveintopython > > Since we have more than one book, I guess a new group could be defined > as well. If there is consensus on the name, I can add it. Should we just > call it "Books" ? +1 -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, 2009-07-02 at 13:45 +0100, Frank Murphy wrote: > On 02/07/09 13:41, Rahul Sundaram wrote: > > > > > >> We ship books as packages? > > > > Yes and this is not even the first time. Dive Into Python has been in > > the repo for ages already. > > > > Rahul > > > > Is there a book group? > or what search parameter? > Tried yum info "Dive Into Python" > > Error: No matching Packages to list $ yum search "dive into python" Loaded plugins: dellsysidplugin2, presto, refresh-packagekit == Matched: dive into python === diveintopython.noarch : Dive into Python - a python book diveintopython-html.noarch : Dive into Python - a python book diveintopython-pdf.noarch : Dive into Python - a python book diveintopython-single-html.noarch : Dive into Python - a python book diveintopython-txt.noarch : Dive into Python - a python book Regards, Pierre -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 02/07/09 13:47, Rahul Sundaram wrote: > On 07/02/2009 06:15 PM, Frank Murphy wrote: > >> Is there a book group? >> or what search parameter? >> Tried yum info "Dive Into Python" > > # yum info diveintopython > > Since we have more than one book, I guess a new group could be defined > as well. If there is consensus on the name, I can add it. Should we just > call it "Books" ? > > Rahul > Books sound ok Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 06:15 PM, Frank Murphy wrote: > Is there a book group? > or what search parameter? > Tried yum info "Dive Into Python" # yum info diveintopython Since we have more than one book, I guess a new group could be defined as well. If there is consensus on the name, I can add it. Should we just call it "Books" ? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 02/07/09 13:41, Rahul Sundaram wrote: > >> We ship books as packages? > > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. > > Rahul > Is there a book group? or what search parameter? Tried yum info "Dive Into Python" Error: No matching Packages to list Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On 07/02/2009 06:03 PM, drago01 wrote: > On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report > wrote: >> Compose started at Thu Jul 2 06:15:05 UTC 2009 >> ... >> New package ldd-pdf >>Linux Device Drivers, Third Edition Book in PDF format > > We ship books as packages? Yes and this is not even the first time. Dive Into Python has been in the repo for ages already. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
On Mon, Jun 29, 2009 at 9:27 PM, Matthias Clasen wrote: > To achieve this, we will hold regular test days, each of which will > focus on use cases in a certain area. A few ideas for test day topics Overall, an excellent idea and plan. We had some very good results with an OLPC test group in Wellington NZ, which started gathering every saturday morning at a trendy cafe to test OS snapshots. They keep the practice going with both OS snapshots for the XO and Sugar-on-a-Stick (LiveUSB) images. Using liveCDs and live USB disks is great as you can upgrade, downgrade and potentially bisect a bug quickly. It also means you can run it on many different bits of HW (assuming you've invited everyone to bring their laptops ;-) ) The event is a social thing as much as a technical thing. Of course, it is a great environment to find and diagnose certain kinds of bugs, just like running Fedora betas on a server helps catch and debug only certain kinds of bugs. But the bugs that you are likely to find and diagnose are exactly those that affect the casual and newcomer desktop user. We did find a few things that work well in terms of nurturing a core group of people joining regularly, and switching from the social chatter to the effective bug-hunting and filing. Let me know if you're interested in more info on this. cheers! martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report wrote: > Compose started at Thu Jul 2 06:15:05 UTC 2009 > ... > New package ldd-pdf > Linux Device Drivers, Third Edition Book in PDF format We ship books as packages? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On Thu, Jul 2, 2009 at 1:09 PM, Daniel Drake wrote: > Thanks for your efforts, this is excellent. Guess it's time for me to learn a bit about it. > We've started using it for OLPC's F11 spin, including our own modules to > implement OLPC features. So much nicer than what we had before! Looks like it is missing my patches. Any plan to merge them in? :-) cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
On Tue, Jun 30, 2009 at 10:45:19AM +0100, Andrew Haley wrote: > Matthias Clasen wrote: > > > we'd like to announce the 'Fit and Finish' initiative for Fedora, > > > > http://fedoraproject.org/wiki/Fit_and_Finish > > > > with the goal to improve the user experience of the Fedora desktop. We > > want to identify the small (and sometimes large) roadblocks that make > > everyday computer use harder than it needs to be, and try to fix them. > > In Ubuntu there's a "Help" button on the top menu bar that leads to a > nice help application, yelp. We have that app too, but it doesn't > seem to have the same contents, which are: > > New to Ubuntu? > Adding and Removing Software > Files, Folders and Documents > Customising Your Desktop > Internet > Music, Videos and Photos > Assistive Tools > Keeping Your Computer Safe > Printing, Faxing and Scanning > Advanced Topics > > And under each section there's a clear explanation of what to do. > Maybe we have something equivalent for Fedora, but I can't find it. Perhaps this is something you could raise separately with the Fedora Docs team. I'm just getting back from some travel during which I caught wind of some new documentation standards being produced by the GNOME docs community to make documentation more task-based, with which I agree whole-heartedly. Also, our own Docs team is working on providing an easy way for people to retrieve and install language-specific documentation such as a user guide which would integrate into the desktop menu system. (I'm pretty sure that integration is desktop environment-neutral.) The confluence of those two developments might provide some better docs at the desktop level. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
2009/7/2 Harald Hoyer : > On 07/02/2009 01:25 PM, Daniel Drake wrote: >> >> On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: >>> >>> The idea is to pregenerate a generic initrd and package it in an rpm and >>> deliver >>> it together with the kernel. There should be no need to generate the >>> initrd on >>> an X0-1 itsself. >> >> Is it going to work like this in standard Fedora too? >> Or will dracut be invoked like mkinitrd is today, that is at RPM-install >> time on the target system? >> >> Daniel >> >> > > My personal target is to deliver the initrd image with the kernel. For > performance issues or special needs one can install dracut and generate his > own image, if new kernels are installed. > > We will see, if can work that way. > Can i just point out that i am probably not the only one to require omitting some modules and adding others to the initrd image. With the current setup i run mkinitrd once when i first install (using rescue disk) and then these altered options are remembered so it creates the correct initrd whenever the kernel is updated. If i understand correctly and the initrd images are pre-generated within an rpm then my mods will be overwritten on each update and i would presumably need to run dracut manually after each kernel update to replace the pregenerated initrd. That would be a major regression and surely cannot be allowed to happen. Please accept my apologies if i got it all wrong. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: certificate not (yet) active?
On Thu July 2 2009, Christoph Höger wrote:
> I had to create a new .fedora.cert this morning, because make
> new-sources told me mine was out of date.
> So I did but now make build runs into
>
> Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate
> verify failed')]
>
> why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*)
Maybe you need to run fedora-packager-setup from fedora-packager again. If you
edited your koji.conf, you may re-add your changes btw.
Regards
Till
signature.asc
Description: This is a digitally signed message part.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 01:25 PM, Daniel Drake wrote: On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: The idea is to pregenerate a generic initrd and package it in an rpm and deliver it together with the kernel. There should be no need to generate the initrd on an X0-1 itsself. Is it going to work like this in standard Fedora too? Or will dracut be invoked like mkinitrd is today, that is at RPM-install time on the target system? Daniel My personal target is to deliver the initrd image with the kernel. For performance issues or special needs one can install dracut and generate his own image, if new kernels are installed. We will see, if can work that way. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
certificate not (yet) active?
Hi,
I had to create a new .fedora.cert this morning, because make
new-sources told me mine was out of date.
So I did but now make build runs into
Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate
verify failed')]
why that? (And I wanted to update offlineimap to 6.1.0 today *sniff*)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090702 changes
reclock timout to 5 seconds - Spawn a child process in the recovery daemon ot check the reclock file to avoid blocking the process if the underlying filesystem is unresponsive - fix for filedescriptor leak when a child process timesout - Dont log errors if waitpid() returns -1 - Onnode updates by Martins - Test and initscript cleanups from Martin S * Fri Jun 05 2009 Sumit Bose - 1.0.84-1 - Update to ctdb version 1.0.84 * Tue Jun 02 2009 : Version 1.0.83 - Document how to remove a ndoe from a running cluster. - Hide all deleted nodes from ctdb output. - Lower the loglevel on some eventscript related items - Dont queue packets to deleted nodes - When building initial vnnmap, ignode any nonexisting nodes - Add a new nodestate : DELETED that is used when deleting a node from an existing cluster. - dont remove the ctdb socket when shutting down. This prevents a race in the initscripts when restarting ctdb quickly after stopping it. - TDB nesting reworked. - Remove obsolete ipmux - From Flavio Carmo Junior: Add eventscript and documentation for ClamAV antivirus engine - From Sumit Bose: fix the regex in the test to handle the new ctdb statistics output that was recently added. - change the socket type we use for grauitious arps from the obsolete AF_INET/SOCK_PACKET to instead use PF_PACKET/SOCK_RAW. - Check return codes for some functions, from Sumit Bose, based on codereview by Jim Meyering. - Sumit Bose: Remove structure memeber node_list_file that is no longer used. - Sumit Bose: fix configure warning for netfilter.h - Updates to the webpages by Volker. - Remove error messages about missing /var/log/log.ctdb file from ctdb_diagnostics.sh from christian Ambach - Additional error logs if hte eventscript switching from dameon to client mode fails. - track how long it takes for ctdbd and the recovery daemon to perform the rec-lock fcntl() lock attemt and show this in the ctdb statistics output. * Tue Jun 02 2009 : Version 1.0.84 - Fix a bug in onnode that could not handle dead nodes cups-1.4-0.rc1.7.fc12 - * Wed Jul 01 2009 Tim Waugh 1:1.4-0.rc1.6 - Fixed lpadmin for remote 1.3.x servers (bug #506977, STR #3231). * Wed Jul 01 2009 Tim Waugh 1:1.4-0.rc1.7 - Fixed template problem preventing current printer option defaults from being shown in the web interface (bug #506794, STR #3244). * Tue Jun 23 2009 Tim Waugh 1:1.4-0.rc1.5 - Added more debugging output when constructing filter chain. darcs-2.2.1-3.fc12 -- * Thu Jul 02 2009 Jens Petersen - 2.2.1-3 - drop post script since semanage now superfluous - drop the unused alphatag for now - simplify BRs dvb-apps-1.1.1-16.fc12 -- * Thu Jul 02 2009 Ville Skyttä - 1.1.1-16 - Update tuning files to 20090702. - Drop no longer needed workaround for #483644. dvdauthor-0.6.14-9.fc12 --- * Tue Jun 30 2009 Rex Dieter - 0.6.14-9 - rebuild (GraphicsMagick) eclipse-gef-3.5.0-1.fc12 * Wed Jul 01 2009 Mat Booth 3.5.0-1 - Update to 3.5.0 final release (Galileo). - Build the features seperately to allow for a saner %files section. - Use %global instead of %define. eigen2-2.0.52-0.2.20090622.fc12 --- * Mon Jun 22 2009 Rex Dieter 2.0.52-0.2.20090622 - switch to upstream-provided snapshot empathy-2.27.3-3.fc12 - * Thu Jul 02 2009 Matthias Clasen - 2.27.3-3 - Shrink GConf schemas evolution-2.27.3-3.fc12 --- * Wed Jul 01 2009 Milan Crha - 2.27.3-3.fc12 - Rebuild against newer gcc evolution-data-server-2.27.3-2.fc12 --- * Wed Jul 01 2009 Milan Crha - 2.27.3-2.fc12 - Rebuild against newer gcc evolution-exchange-2.27.3-2.fc12 * Wed Jul 01 2009 Milan Crha - 2.27.3-2.fc12 - Rebuild against newer gcc fence-agents-3.0.0-13.rc4.fc12 -- * Thu Jul 02 2009 Fabio M. Di Nitto - 3.0.0-13.rc4 - New upstream release. - spec file updates: * BuildRequires / Requires: latest corosync and openais * Drop --enable_virt. Now default upstream findutils-4.4.2-1.fc12 -- * Wed Jul 01 2009 Vitezslav Crhonek - 1:4.4.2-1 - Update to findutils-4.4.2 flickrnet-2.2-1.fc12 * Fri Jun 26 2009 Paul Lange - 2.2-1 - Update to upstream release 2.2. gdm-2.26.1-12.fc12 -- * Wed Jul 01 2009 Ray Strode - 1:2.26.1-12 - Drop defunct arch conditional buildrequires * Tue Jun 30 2009 Matthias Clasen - 1:2.26.1-11 - Rebuild against new libxklavier ghc-haskell-src-exts-1.0.1-1.fc12 - * Wed Jul 01 2009 Conrad Meyer - 1.0.1-1 - Version bump. gnome-applets-2.27.3-3.fc12 --- * Tue Jun 30 2009 Matthias Clasen - 1:2.27.3-3 - Rebuild against new libxklavier gnome-media-2.27.3.1-1.fc12 --- * Wed Jul 01 2009 Bastien Nocera 2.27.
Re: [ANNOUNCEMENT] dracut-0.3
On Thu, 2009-07-02 at 13:14 +0200, Harald Hoyer wrote: > The idea is to pregenerate a generic initrd and package it in an rpm and > deliver > it together with the kernel. There should be no need to generate the initrd > on > an X0-1 itsself. Is it going to work like this in standard Fedora too? Or will dracut be invoked like mkinitrd is today, that is at RPM-install time on the target system? Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Jim Meyering wrote: > I try to accommodate progressiveness, when the benefit appears to > outweigh the risk. ACK. The risk of an automake-1.10->automake-1.11 upgrade on Fedora is close to zero and outweigh the effects of bug fixes having gone into automake-1.11. So far, I know of no incompatibility that would require any manual work. I am not aware of any, either. The latest major breakage with autoconf/automake, I encountered was introduction of AC_ENABLE/DISABLE_OPTION_CHECKING, which causes irritating warnings when not being treated manually. However this was introduced by autoconf, not automake, and is more a nuissance but a regression. But even if there are a few corner cases, anyone who cannot find the time for whatever small changes are needed to update to automake-1.11 can install an older version and use that. The fact "make V=..." uses an unprefixed/non-namespace safe environment variable is a candidate to cause problems. Admitted, the likelihood of older packages tripping over this is close to null. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
On 07/02/2009 01:09 PM, Daniel Drake wrote: Hi Harald, On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: Here it is, dracut-0.3! Thanks for your efforts, this is excellent. We've started using it for OLPC's F11 spin, including our own modules to implement OLPC features. So much nicer than what we had before! However, the spec file already pulls in a lot of dependencies, things like device-mapper and cryptsetup which we won't need. Especially for XO-1 we need to work to keep images small (1GB hard disk). Is there any chance that this could be split up, and the more exotic dependencies moved into subpackages? Cheers, Daniel The idea is to pregenerate a generic initrd and package it in an rpm and deliver it together with the kernel. There should be no need to generate the initrd on an X0-1 itsself. Read the dracut manpage. You could explicitly set the modules you want to use and omit those, you know you will never use. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCEMENT] dracut-0.3
Hi Harald, On Thu, 2009-07-02 at 12:59 +0200, Harald Hoyer wrote: > Here it is, dracut-0.3! Thanks for your efforts, this is excellent. We've started using it for OLPC's F11 spin, including our own modules to implement OLPC features. So much nicer than what we had before! However, the spec file already pulls in a lot of dependencies, things like device-mapper and cryptsetup which we won't need. Especially for XO-1 we need to work to keep images small (1GB hard disk). Is there any chance that this could be split up, and the more exotic dependencies moved into subpackages? Cheers, Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
