Re: Top Crashers
On Mon, Jan 04, 2010 at 04:35:54PM +, Daniel P. Berrange wrote: > On Mon, Jan 04, 2010 at 03:12:18PM +, Matthew Booth wrote: > > Now we have abrt making it easier for lazy people to submit crash > > reports, do we have enough information for a 'Top Crashers' list? It > > would be good to highlight these centrally to provide an incentive to > > give them the attention they deserve. > > > > My specific motivation for this is: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=532307 > > > > This crashes daily for me and, from the evidence of the BZ traffic, a > > whole lot of other people too. It has also been ignored for 2 months > > now. Highlighting and fixing this kind of high-impact bug would be a > > great way to improve the quality of Fedora. > > You have essentially just suggested kerneloops.org, but for userspace > apps. It would be very nice to have such a beast! Doing statistical > analysis by extracting the ABRT reports from BZ would just be horrible. Is the existing CBI project helpful in this case? http://lwn.net/Articles/362777/ -- 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
Packaging problem with %find_lang
Hi,
Packaging up monodevelop-boo and I've hit a problem with find_lang which
I can't figure out as everything seems fine!
I have the %find_lang %{name} in the %install section where name =
monodevelop-boo (which is the correct name for the translation files).
When the spec file reaches this point though, it complains there are no
translation files despite there being translation files!
The build is producing the following
mkdir
-p
/home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386/usr/lib/monodevelop/AddIns/BooBinding/locale/zh_CN/LC_MESSAGES/
cp '../build/locale/zh_CN/LC_MESSAGES/monodevelop-boo.mo'
'/home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386/usr/lib/monodevelop/AddIns/BooBinding/locale/zh_CN/LC_MESSAGES/monodevelop-boo.mo'
mkdir
-p
/home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386/usr/lib/monodevelop/AddIns/BooBinding/locale/zh_TW/LC_MESSAGES/
cp '../build/locale/zh_TW/LC_MESSAGES/monodevelop-boo.mo'
'/home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386/usr/lib/monodevelop/AddIns/BooBinding/locale/zh_TW/LC_MESSAGES/monodevelop-boo.mo'
make[1]: Leaving directory
`/home/paul/rpmbuild/BUILD/monodevelop-boo-2.2/po'
make[1]: Entering directory
`/home/paul/rpmbuild/BUILD/monodevelop-boo-2.2'
make[1]: Leaving directory
`/home/paul/rpmbuild/BUILD/monodevelop-boo-2.2'
+ /usr/lib/rpm/find-lang.sh
/home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386 monodevelop-boo
No translations found for monodevelop-boo
in /home/paul/rpmbuild/BUILDROOT/monodevelop-boo-2.2-1.fc13.i386
Am I going insane here (more than usual that is) or is find_lang
misbehaving? It works fine for monodevelop and mono itself.
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
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: Mono.Cecil & monodevelop-debugger-mdb
Hi, > > You can't expect everyone to change their software design to work > for > > Fedora, even if it has disadvantages. > > We do expect that, sorry. Bundling libraries is not a solution, fixing > the library not to break its ABI/API every couple days is. Here I have to agree with you Kevin. Mono.Cecil is a pain, but it's the only one in Mono which does change between packages. I don't understand why. As it stands, the fix was easy; change monodevelop so that it doesn't add mono.cecil to the list that it provides and add it in by itself. It's not a fix upstream will listen to (as aren't the 64 bit lib fixes - don't ask, I've been trying for ages to get them to accept them). I'm going to have a go at building the other monodevelop plugins over the next week and get them into rawhide Assuming I still can by then ;-p TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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
Fixing the kernel for intel laptops
Hi, I'm trying to get my Intel graphics driven laptop up and running again (see BZ 523646 for details of the problem) and am trying to rebuild the kernel using the latest from kernel.org and the fedora srpm (install srpm, copy the kernel, run the spec). The idea is I drop each patch, build and see which one is killing the system and then feed that back to the kernel bods. The current rawhide kernel (2.6.32.2-14.fc13.i686) is no go on the laptop. Question is, how do I configure the spec file to use the latest kernel tarball? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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
BZ 523646 - F13Blocker?
Hi, I originally reported this bug in September 2009 when f12 was rawhide. It was fixed but has recently resurfaced for both F12 and rawhide users leaving anyone with an intel chipset for video with unusable systems. Given that this kills quite a few laptop users, can this be escalated to F13Blocker? It is already listed as high for both priority and severity. I've not tried booting a live distro that is not a fedora one as to be honest, I'd rather not sully my machines! However, I've not heard of anyone using Ubuntu with the same kernel and xorg-x11-drv-intel version having the same problems. Thoughts folks? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: 20091227 changes
Hi, > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.Debugger) = 0:2.1.0.0 > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.Core) = 0:2.1.0.0 > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.AspNet) = 0:2.1.0.0 Fixed. Grab it from koji now or wait until tomorrows rawhide update. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: Mono.Cecil & monodevelop-debugger-mdb
Hi,
> No, we should patch the broken packages to work with the current
> Mono.Cecil.
> And upstream deserves a beating for this attitude. :-/ Why am I not
> surprised this is coming from the M$-loving Mono community?
I quite agree - there should be a universal mono.cecil.
> In any case, if you do think an exception should be granted, this will
> have
> to go through FESCo. But I doubt we will approve it, at least not if
> you
> don't provide evidence that somebody competent in C# tried to patch
> MonoDebugger to work with the new Mono.Cecil and failed due to some
> unsurmountable obstacle. If none of you Mono SIG folks is fluent in
> C#, then
> that's a problem that needs solving first of all.
MD itself works fine with Mono.Cecil as provided by other packages. The
problem is MD also copies Mono.Cecil to %{_libdir}/monodevelop/bin
which is what is being picked up on when -pkg:monodevelop is referenced
in the make file. It's not a problem with MD or Mono.Cecil really...
Oh well. I'll look at it (again) on the 28th.
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
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
Mono.Cecil & monodevelop-debugger-mdb
Hi, MD-debugger-mdb is currently broken for rawhide. I've tried many ways to get it to build and have finally asked for help from the the md mailing list. The big problem is that we're using a system wide Mono.Cecil rather than individual packages having their own version of Mono.Cecil. Here's the conversation followed by a request from me... 8--> On Wed, Dec 23, 2009 at 4:14 PM, Paul wrote: > I've got MD-2.2 installed from Fedora rawhide and am trying to build the > MD debugger plugin. Problem is that it's looking for Mono.Cecil in the > MD addins. > > With Fedora, we use a system wide Mono.Cecil instead of having a pile of > them around the place. We use a local copy of Cecil because Cecil API is (was?) not guaranteed to be stable and therefor the library is *supposed* to be bundled with apps. This also allows us to rely on the exact behaviour of the version we ship. By upgrading MD's Cecil to one it has not been tested with, Fedora is potentially exposing their users to bugs that we will be unable to reproduce and fix. See http://www.mono-project.com/Cecil#Using_Cecil <--8 Given this, should we change the approach we currently have for using the system wide Mono.Cecil and allow the likes of MD to ship with it's own version of Mono.Cecil? Mono.Cecil is not added into GAC so having different versions of Mono.Cecil for different applications should not cause conflicts. "Should" is being used in it's lightest sense! TTFN Paul P.S. Going off until Boxing Day now, so Merry Christmas to you all! -- Sie können mich aufreizen und wirklich heiß machen! 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
Power Management caused 2 second instant poweroff on Desktop
Hey, I just had the weirdest thing ever, on Fedora 12 I was working on my desktop, running F-12, KVM and like 10 VM's up and running. I had clicked on the "update" button, but since I was using a voip (hardware) phone had not yet clicked on "download updates". I iconified the window to get rid of it while on my call and forgot about it. Later, while just doing some file editing, a (gnome power management?) popup appears with a power button on the left side, stating "Paul Wouters is logged on. System will shut down in 60 seconds". Looking at the popup kinda surprised, I move my hand to my mouse to hit cancel and before I reached my mouse, the machine does an instant poweroff, leaving me stunned in a very quiet room pondering about my 10 VM's that just crashed along with it. After the boot, it seems I have no new updates left to install :P Also, kernel did not change, still 2.6.31.6-166.fc12.x86_64, so even if this was some automatic update effect timed badly, I am not sure why it needed to poweroff my machine. I'm not sure which component to bug report for, or whose Christmas present to take away :P Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono 2.6 - heads up
Hi, > > There are a pile of changes under the hood for mono and > monodevelop... > > > > http://www.mono-project.com/Release_Notes_Mono_2.6 > > > > and this time, I've added a new subpackage for the preview of C# 4.0 > > I presume that will only be for rawhide? Correct :-) Uploading now... Watch this space! TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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
Mono 2.6 - heads up
Hi, Sometime today or tomorrow I'll be uploading Mono-2.6 and the final release of MD-2.2 with all the fun that it will bring. There are lots of changes under the hood of mono and while the likes of gtk-sharp2 et al are still working on my test boxes, it might be wise to rebuild to take advantage of the improved facilities. The only thing holding up proceedings is that mono-debugger is failing to build for me which may be the debugger or mono. I'm waiting on something from Novell on that. There are a pile of changes under the hood for mono and monodevelop... http://www.mono-project.com/Release_Notes_Mono_2.6 and this time, I've added a new subpackage for the preview of C# 4.0 TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: Pulseaudio problem with xine, xmms and mplayer
Hi, > > Any ideas? > > Yes. > > Firstly, next time please report bugs to bugzilla, that's why we have > it. https://bugzilla.redhat.com/show_bug.cgi?id=548989 > > Secondly, this is not a PA problem. The RT folks broke PI mutexes > again, this is a kernel/glibc problem. S, don't ask if anyone else has seen it or report it under the wrong application then? Sounds like a cunning plan to me... TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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
Pulseaudio problem with xine, xmms and mplayer
Hi, Whenever I try to run xine, xmms or mplayer from the command line, I keep getting an error from pulseaudio Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. It makes no difference if I try to use ogg, mp3 or wav files, they all fail and die with the same error. I'm using pulseaudio-0.9.21-3.fc13 and the 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel PAM fires up and reports all the audio devices are running fine. Any ideas? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: FESCo election results December 2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: > Election Results for FESCo - Fedora 13 Cycle > > Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC > > Nominations: > > * Adam Jackson (ajax) > * Christoph Wickert (cwickert) > * Justin M. Forbes (jforbes) > * Matthew Garrett (mjg59) > * Peter Jones (pjones) > * Richard June (rjune) > * Robert Scheck (rsc) > > Outcomes: > > As defined in the election text, the four (4) candidate(s) with the > greatest number of votes will be elected for full 2 release term. > > Information: > > At close of voting there were: > 216 valid ballots > > Using the Fedora Range Voting method, each candidate could attain a > maximum of 864 votes (4*216). > > Results: > > 1. Adam Jackson (ajax) 1028 > 2. Christoph Wickert (cwickert) 934 > 3. Peter Jones (pjones) 820 > 4. Matthew Garrett (mjg59)753 > * * * * * > 5. Robert Scheck (rsc)663 > 6. Justin M. Forbes (jforbes) 535 > 7. Richard June (rjune) 415 > > As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew > Garrett are elected to FESCo for a full 2 release term. As Bill Nottingham and others correctly pointed out, the maximum vote numbers above were incorrect. The number should be 7*216, or 1512. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLK96srNvJN70RNxcRAiZ4AKDRs3eVUpyJSNHx5e5byjDFkM3aXwCfeiGA SYGmwpZvMnya5hDu2IOnXpc= =Jofb -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo election results December 2009
On Fri, Dec 18, 2009 at 06:09:42PM +, Bryn M. Reeves wrote: > Fri, 2009-12-18 at 13:06 -0500, Adam Jackson wrote: > > On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: > > > > > Information: > > > > > > At close of voting there were: > > > 216 valid ballots > > > > > > Using the Fedora Range Voting method, each candidate could attain a > > > maximum of 864 votes (4*216). > > > > > > Results: > > > > > > 1. Adam Jackson (ajax) 1028 > > > > That's right, I'm so awesome I got more than the maximum number of > > votes. > > Was this tabulated in Florida? Didn't "Vote early, vote often" originate in Chicago? Wait a second, our Infrastructure team lead's in Chicago ;-) Just a simple human error of using "4" instead of "7". I've sent a GPG-signed correction as followup. Thanks to all who caught the error -- I've entered an RFE for the voting system: https://fedorahosted.org/elections/ticket/32 -- 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
FESCo election results December 2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Election Results for FESCo - Fedora 13 Cycle Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC Nominations: * Adam Jackson (ajax) * Christoph Wickert (cwickert) * Justin M. Forbes (jforbes) * Matthew Garrett (mjg59) * Peter Jones (pjones) * Richard June (rjune) * Robert Scheck (rsc) Outcomes: As defined in the election text, the four (4) candidate(s) with the greatest number of votes will be elected for full 2 release term. Information: At close of voting there were: 216 valid ballots Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 2. Christoph Wickert (cwickert) 934 3. Peter Jones (pjones) 820 4. Matthew Garrett (mjg59)753 * * * * * 5. Robert Scheck (rsc)663 6. Justin M. Forbes (jforbes) 535 7. Richard June (rjune) 415 As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew Garrett are elected to FESCo for a full 2 release term. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLK7mzrNvJN70RNxcRAvCNAKDvrCQTbqX5AnUwZ7yOIstqY9Kw6gCgwx4Y iChaOSEv0FdG1kOXPgWcGXI= =2kq6 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Election results for FAmSCo, FESCo coming shortly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our election coordinator, Nigel Jones, was too swamped today to process all of the election results, but will be doing so later today (UTC time). Thanks for your patience, and thanks to Nigel for all his work coordinating the voting system and results. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLKkm/rNvJN70RNxcRAjY9AKCoRs/EplwBz3kXCbYJlW9heW19TQCgtHmx wmnUs+PWljamrXBKBi1jq/c= =8gZv -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Matthew Garrett wrote: The problem here is that you appear to be massively underestimating the amount of work that would be required to actually support this configuration. Support is a multi-valued thing as well as a process. Not every i has to be dotted for something to be of use. E.g. there are secondary arches to act as staging grounds. I would not except everything to be magically perfect tomorrow, however there may be low-hanging fruit (like yum having separate notions of default native word-size for userspace and kernel, see below). We'd need to audit every ioctl entry point, every file in proc and every sysfs attribute. Or just let people file bugs as they find things.. We'd need to port every application that uses vm86 over to using x86emu. Or let people using such apps continue to use a 32bit kernel (such kernel would have to continue to be supported, obv). We'd need to add, test and support a 32-to-64 bit cross building toolchain. GCC has a -m64 flag that may or may not help somewhat there (though, it got b0rken, though possibly just in combination with profiling). yum would need some amount of work that Seth has implied is significant. That's may be the easiest bit. It updates packages just fine, except it doesn't know I want it to install 64bit kernels, after I forced it to think the machine was 32bit. That's a lot of work for marginal benefits, and nobody seems interested in stepping up to do that work. I.e. money meet mouth, mouth likewise, you mean? :) I'll try poke at it later in 2010. I'm more a C programmer than a python programmer, so I'd rather look at stuff like things like the SG_IO interface (which Peter Jones pointed me at in private) than at yum, but I'll see. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: One of the disadvantages of having children is that they eventually get old enough to give you presents they make at school. -- Robert Byrne -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Debarshi Ray wrote: He is just pointing out that there is lot more work to do than you think. In other words he is contesting your claim that "The kernel side apparently works fine AFAICT". Well, I don't really know how to else to counter "there may be unknown bugs". Kernel sub-system interfaces generally are well-designed and specified (i.e. explicit widths of fields). Booting a system and using it for a while exercises many of the important ones. Could there be bugs in some lesser-used, oddball interface? Of course (and I am sure there are - I think I gave an example in a thread earlier this year). They're likely to reasonably trivial bugs though (oversights in the interface specification, e.g. a 'long' instead of a __u32, etc). If there really are interfaces that are so messed up that they'd be hard to fix up, then that's probably a warning sign that the code may have deeper, bigger problems. People who run into such bugs can always go back to a 32bit kernel (standard or PAE) until it's fixed, if it even affects them. They're put back in the same position as they're in now, which I'm sure must be acceptable. Anyway.. I'll try look into this again later next year, and see if I can fix the "bugs" (in the RFE sense for yum, libvirt) I found. Was simply hoping to get other people interested in 32-on-64, no more or less. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: "Do you believe in intuition?" "No, but I have a strange feeling that someday I will." -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Matthew Garrett wrote: "It works for me" is a poor standard of support. There must be something transmogrifying my emails before it reaches other subscribers of this list, either that or I am being unreasonable in thinking that by asking /if/ Fedora would consider *supporting* this configuration (i.e. in the future) that it would be clear that: - I do not expect it to be supported already - I am not complaining about software not working quite right now E.g. I was impressed at how yum pretty much works (with minor tweaking to override which arch it think it's running on). I didn't mean to complain or whinge or intend for people to think I had silly expectations of this being supported already. Apologies if I did and/or if that's how it came across. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: ASHes to ASHes, DOS to DOS. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Paul Jakma wrote: My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. Oh, I don't quite remember the details, but I think libvirt also gets a bit confused when its 32bit and the kernel is 64. Another data-point is that I've used and developed on other 32/64 x86-64 systems for a number of years and those manage it just fine. It really shouldn't be hard, if you decide its worth supporting. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Life is like an onion: you peel off layer after layer and then you find there is nothing in it. -- James Huneker -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Paul Jakma wrote: I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a "generally-32bit" userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Your own qualities will help prevent your advancement in the world. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Jon Masters wrote: But again, Apples to Oranges. x86_64 (we should formally call it "Intel 64", or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. It's not about the instruction set. If you look back at the posts, from myself and the poster who gave a toy test case, the extra memory usage is from data, not from programme text. Programme text is not too significant in size when compared to data (about a 10:1 data:text ratio for cases I've looked at). So the instructions being compact is simply not very relevant - pointers and longs in *data* double up in size on 64bit. (This transcends specific ISAs..). the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. Right. I.e. a 64bit *kernel* is very useful (and much faster than a PAE one). That's precisely what I am arguing for. Again, there is a difference between aggregate usage (e.g. of RAM) and per-process memory requirements, similarly for performance. I.e. in the aggregate, a system can make good use of *both* 32 and 64 bit. I.e.: - In the aggregate, systems now need to make efficient use of >3GB of memory - PAE (slow, other problems) - 64bit - more and more systems have this, it'd be nice to be able to use this with a 32bit install. - On a per-process basis, few processes need 64bit pointers - those which do, can easily be 64bit on a 32/64 system. - those which can be 32bit can avoid a circa 30 to 60% memory overhead - On a per-process basis, few processes need the advantages of x86-64 - I am incredulous at the people who keep arguing that "x86-64 is better" because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). - those processes which do, can be 64bit I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. A lot of respondents have argued as if this is a binary matter, approaching the debate as if it's an either-or choice between 32 OR 64, which was not my intention at all. And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. Anyway :) Sorry for extending this thread, but it seemed I miscommunicated in previous emails and failed to get the basic points across properly. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Seeing is believing. You wouldn't have seen it if you hadn't believed it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Chris Adams wrote: Have you actually shown any concrete benefits, or has it all just been hand-waving? Well, the benefits were already known from the introduction of 64bit systems in the mid 90s. E.g. a rule of thumb with AXP systems was that they required at least 30% odd more RAM, compared to other Unix systems (either 32bit, or 32-userspace/64kernel systems - which is what most of the other Unix RISC vendors went with when they went to 64bit CPUs). E.g., a fresh F12 install: 32bit free -m: used +/- buffers/cache at gdm: 71 logged into desktop: 123 +firefox:183 +OO writer: 203 64bit: at gdm: 113 logged in: 159 Unfortunately, I couldn't get the 64bit one past "logged in" and even then I couldn't get it to display a useful desktop (good bit of GNOME stuff was running, but nothing shown), so it's probably under-representative. That shows a 59% increase for "at GDM", and at least a 29% increase for "logged into desktop". However, to be fair, that's probably /over/-representing the difference, as I didn't do much with any applications. Pure data, like the contents of webpages, your email, etc.. doesn't contain arch-dependent variable width data like pointers. That said, attendent meta-data (e.g. mail indices, data structures for the layout of your rendered webpage, etc..) may have arch-dependent variable-width data. So I'd expect that that 60% figure would go down a bit if you really used the system. I would expect a memory increase, due to 64bit, of somewhere between 30 and 60%, depending on system - or a saving of between 23 to 38%. I can't do this test as running F12 x86-64 under Qemu is just too damn slow, even if did finish login successfully. If someone wants to replicate the above with KVM on x86_64: 1. Install F12 2. After the first boot, reboot again, to eliminate the run of 'firstboot' 3a. login via ssh 3b. login via GDM 4. start firefox 5. switch to the 2nd desktop 6. start oowriter Use the SSH session to note the memory usage with 'free -m' after steps 3b, 4 and 6. You may need to run the command a few times to wait for the usage to stabilise (it probably will spike and decrease again). For certain workloads, e.g. servers dealing in large numbers of instances of small amounts of data, 60% extra could be quite normal (or even low). It was in optimising memory usage for a BGP implementation where I personally noticed just how much bloody space those 64bit pointers can take up. ;) If somebody shows real benefits (with real data to back it up), and is willing to put forth the effort to make it work, it might be interesting. All I'm saying is that it would be nice if: a) an x86_64 kernel was made a supported option for a 32bit Fedora (it pretty much works already) - i.e. its an additional kernel. b) yum grokked out of the box how to upgrade such systems (at the moment you have to tweak some file to make it think it's a 32bit system, and then kernel updates have to be done manually) I'm saying there is at least one very reasonable and rational reason for 32-on-64. I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If you can't learn to do it well, learn to enjoy doing it badly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
On Mon, Dec 14, 2009 at 05:01:56PM -0500, Mike Bonnet wrote: > On 12/14/2009 04:50 PM, Paul W. Frields wrote: > > On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: > >> When trying to install astronomy-bookmarks I get the error that > >> "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I > >> looked at the source (an HTML file) but I can't quite figure out why it > >> would conflict. Does anyone know? > > > > [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks > > astronomy-bookmarks = 1-6.fc12 > > system-bookmarks > > [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks > > fedora-bookmarks = 11-2 > > system-bookmarks > > > > They both provide 'system-bookmarks'. > > Multiple packages can Provides: the same thing without problems. > > The issue here is that astronomy-bookmarks explicitly Conflicts: with > fedora-bookmarks: > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 Thanks for the clarification Mike! -- 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: astronomy-bookmarks conflicts with fedora-bookmarks
On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: > When trying to install astronomy-bookmarks I get the error that > "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I > looked at the source (an HTML file) but I can't quite figure out why it > would conflict. Does anyone know? [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. -- 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: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Adam Williamson wrote: On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. It's quite meaningful, e.g. for power conservation. As you no doubt are aware of, modern system regularly clock down the CPU. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: It occurred to me lately that nothing has occurred to me lately. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Gregory Maxwell wrote: Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. I'm not rejecting the performance metric at all. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) Only because it's obsolete. Multi-process browsers use a lot less RAM per process. What was the point of this conversation again? For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. Some people chose to argue "But you should just run 64bit completely", despite people already having described one reason to 32bit (memory usage). And from that we somehow got into a "x86_64 versus x86" thread of doom, with (IMHO) much missing of the general point. Anyway, enough. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Where do you go to get anorexia? -- Shelley Winters -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Debarshi Ray wrote: Regarding shared libraries its worth noting the point about "Instruction pointer relative data access": http://en.wikipedia.org/wiki/X86-64#Architectural_features You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. The point is that few applications need to be 64bit (this may change in time, when email and browser apps start to demand 4GB+, but that time is a while away - per-process memory demands should stay flat for a while if browsers and the like switch from single-process/multi-threaded to a multi-processes model). For the few apps where it makes a difference, sure, run them as 64bit. (Also, please assume in any replies that I have a modicum of clue about the low-level technical details between i386 and x86_64). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: magnetic interferance from money/credit cards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Ralf Corsepius wrote: Of course, this is an extreme case, It isn't that extreme - pointers can make up a significant component of data-structures. E.g. any programme that has to store many instances of small amounts of data, the pointer size can have a big impact on memory usage. If the data is heavily inter-linked, even more so. Whether that's the case for most applications, I do not know however. It would though be interesting for someone to go measure this, especially in the aggregate. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If this is timesharing, give me my share right now. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Chris Adams wrote: As soon as you bring in even one 64 bit user-space program that is run much, you've pulled in at least glibc and friends. At that point, you might as well run all (or as close to all as possible) 64 bit user-space, because the libraries are shared (code will be in the cache, etc.). That's assuming that the footprint of libraries relative to distinct applications is large enough to cancel out the space savings. (I have no data either way). A 64bit kernel doesn't need any 32bit userspace. An X server, on my 32bit system has about 8.5MB of programme text (server and libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. So if you ran a 32bit system with a 64bit kernel and X server, you'd lose out on about 10MB of shareable code. For comparison, my 32bit system has O(10) times that allocated to things like browsers and feed-readers. It's using 4.8GB in total (ex buffers/cache) apparently. Space for text (programmes, code) is simply insignificant these days, compared to the huge amounts of data which programmes allocate - data which sometimes includes a lot of pointers. You're also assuming that this cancels out the other benefits. The only time my systems have run 32 bit code in several years is for the Flash plugin (since the open-source plugins don't seem to be able to keep up and since the 64 bit Adobe plugin doesn't seem to get the security updates) and sometimes the Acrobat Reader plugin (since I've run into websites that assume they can embed PDFs in the page and AFAIK there's no plugin for Evince). It's interesting that both you and drago have "almost always" (to paraphrase) run 64bit pure systems. Surely that *reinforces* my point about the futility of "64bit pure systems" as an achievable goal (in the aggregate across all reasonable uses of a distro), and i386 being a de-facto standard for software interfaces. As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. I have one 32 bit desktop at work, and comparing the resident RAM usage between it and a 64 bit desktop, I don't see much difference in the common desktop programs. That's the wrong comparison - compare the aggregate RAM usage, with each system in similar states. I know that for some reason PHP on 64 bit arches bloats up significantly (at least older versions), but that's the only major difference I've seen. Pointer rich data structures, likely.. Anyway, as I don't intend to contribute anything, I'll try stop making noise. Aside to the list: Thanks for all the hard-work on Fedora ;) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Dogs just don't seem to be able to tell the difference between important people and the rest of us. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Paul Jakma wrote: b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. Oops, this is unclear - "memory bound" here in these 2 cases refers to memory-I/O, not amount of memory. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Plus ,ca change, plus c'est la m^eme chose. [The more things change, the more they remain the same.] -- Alphonse Karr, "Les Gu^epes" -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, drago01 wrote: such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste a) i386 has a lower memory footprint, as has been mentioned in this thread. b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches - QA - package building and distribution Every supported arch increases the size of the test matrix. Minimising the number of arches you have to, say, test a "cp" bugfix against helps reduce QA load and helps you get better software to your users, faster (better cause you release time spent on architecture QA that can be spent on improving software generally). d) Like or not, i386 is the de-facto standard for binary interfaces: - Netscape plugins - Windows executables The retort no doubt will "Oh but this is Fedora, we don't care about any closed-source stuff", but that would miss the point entirely re *Interface*. The i386 machine can be a plugin interface between 2 different open-source systems, e.g. consider: - VM images to run in, say, QEMU/KVM - Sandboxing technologies for, say, browser plugins (I think Google have stuff in this area) - Free software windows-only apps (don't know if they exist) All the code here can be open-source/free-software and still be relying on i386 as a widely known and hence convenient /interface/. As such, it likely needs to be supported on x86_64 kernel-based systems anyway, as performantly as possible. (And yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). So personally I think x86_64-pure is unrealistic and, independently, I think 32-on-64 makes sense, but hey. :) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: He who despises himself nevertheless esteems himself as a self-despiser. -- Friedrich Nietzsche -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 18 Nov 2009, Roland McGrath wrote: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. For what percentage of code is that an appreciable advantage? regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: QOTD: "If he learns from his mistakes, pretty soon he'll know everything." -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 18 Nov 2009, Jeff Garzik wrote: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while. About the only thing that doesn't work right is yum wrt kernel updates. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. Indeed. It would be nice if i386-userspace/x64-kernel were officially support.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Blore's Razor: Given a choice between two theories, take the one which is funnier. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote: > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: > > Jef, I'll help with istanbul. If anyone else out there is considering > > doing so, please feel free to team up with me. > > Other than revelation(which essentially has a dead > upstream)...Istanbul is probably the most in need of more development > love. Upstream seems to be inactive with no release activity in quite > a while. There's a lot of deprecation warnings for some pygtk calls > that I would love to clean up in time for F13. And there are a couple > of abrt crash tickets being spawned by istanbul.. which maybe traced > back to gdk libraries calls if I'm reading the crash dumps correctly. Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this weekend at FUDCon if memory serves. I'll also do what I can for existing bugs in my Copious Spare Time(tm). You might be interested in knowing that we had some discussion at FUDCon about extending my PulseCaster project (currently only functional in the most gracious sense) to cover more 'casting needs while maintaining a simple, usable interface: * Newscast -- single person audio, e.g. reading the news * Screencast -- single person audio + desktop screencap * Interview -- multi-person audio * App discussion or instruction -- multi-person audio + one desktop screencap * Save to file or send to streaming server I'm planning on spending some time on the project as part of my Christmas vacation. We had a lot of great ideas for how this functionality will work, but I do want some UI review for it including comparing it to GNOME HIG. -- 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: Docs Installation Guide - Submission and Download problem
On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote: > 2009/12/3 Ruediger Landmann : > > On 12/02/2009 05:47 PM, Dimitris Glezos wrote: > >> > >> Rudi, you could clear the cache and refresh it. > >> > > > > Really? How do I do that? I'd thought that a button like that would be > > useful for the > > maintainer of a project > > This button is available on the web interface on component pages for > maintainers. > > > , not least of which because changes to a POT in the repo don't > > automatically > > trigger a refresh (of course!) while submissions of updated POs do. > > This functionality has been available in Transifex for a while, it's > just that Fedora is still running an old (and unmaintained) version. Diego posted the summary of what needs to be done here: https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10 In short, we need a few people to step up and help with the process Diego posted. We already do have a L10n Admin group[1] that should be overseeing and managing this process, to ensure a successful rollout for translators. Their charter is to maintain the infrastructure for translators, and this clearly falls into that area. I've heard from two of the people in that group that they can't do all this work themselves, but haven't heard from Ankit or Asgeir about it. What I would suggest is that Diego should help with bullet #4 on that list, as it probably requires the greatest degree of specific technical knowledge, in this case a database upgrade. The rest of the work on that ticket could likely be done entirely by the remainder of the team, maybe with limited input from Diego. It would be helpful for Asgeir or Ankit to help manage this set of tasks in collaboration with Diego, who has appropriate package access. (I'm cc'ing Ignacio directly as well, so he can add appropriate CVS access for any other people who are willing to help maintain the EL-5 package used on our Infrastructure.) Without help, it's doubtful there will be a new Transifex rolled out, and that means some of the problems people are experiencing will continue, even though they're already fixed upstream. I'm cc'ing the docs, devel, and infrastructure lists to see if any of the people in areas well served by translators are willing to help see this project through. It's time to pull together, guys, and see if we can help the translators who give so much across the whole Fedora Project. * * * [1] https://fedoraproject.org/wiki/L10N/Tools#Website -- 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: Request for help maintaining packages while away.
On Wed, Dec 09, 2009 at 10:24:16AM -0900, Jeff Spaleta wrote: > Good Alaskan Morning! > > In two weeks I'm going to be in Antarctica for a month+ and I'm > looking for other packagers to step in for me and maintain my packages > and prepare them for F13. I'm not exactly sure what my time and > bandwidth access will be so I'm planning for the worst and that I'll > be reliably off the grid through mid Feb. Please let me know if you > can take on a co-maintainer/primary maintainer role for any of the > packges and see them through the next couple of months. > > Here's the set of packages that I own. I will be contacting existing > co-maintainers for individual packages in the list separately this > week. > > ScientificPython -- A collection of Python modules that are useful for > scientific computing > g3data -- Program for extracting the data from scanned graphs > gourmet -- Recipe Manager for the GNOME desktop environment > gpodder -- Podcast receiver/catcher written in Python > istanbul -- Desktop Session Recorder > nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C > pyscript -- PyScript - Postscript graphics with Python > python-basemap -- Plots data on map projections (with continental and > political boundaries) > python-basemap-data -- Data for python-basemap > python-dateutil -- Powerful extensions to the standard datetime module > python-matplotlib -- Python plotting library > python-xlib -- X client library for Python > pytz -- World Timezone Definitions for Python > revelation -- Password manager for GNOME 2 > safekeep -- The SafeKeep backup system > scipy -- Scipy: Scientific Tools for Python > telescope-server -- Opensource Telescope control servers to interface > with stellarium > usbsink -- USBSink is a GNOME Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. -- 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: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: > Matthew Booth (mbo...@redhat.com) said: > > The separate updates directory has been a pain for as long as I've > > been using RHL/Fedora Core/Fedora. It means you have two places to > > look when searching for packages manually, and twice as much to > > configure when you're configuring yum. It has never benefitted me, > > or anybody I know, but it has caught me out on any number of > > occasions. What's more, nobody really seems to know why it's like > > that: it seems it's always been that way, and nobody ever bother to > > fix it. > > > > So lets fix it. The package set at release time is only interesting > > to historians. If any of them are really that bothered, I'm sure > > somebody can come up with a yum module which finds the oldest > > available version of a package in a repo. > > The separate Everything tree that does not get obsoleted is required > in some form for GPL compliance, with respect to the ISO images that > we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? -- 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: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
On Wed, Nov 25, 2009 at 09:02:45AM +0100, Thorsten Leemhuis wrote: > Hi > > Me again ;-) > > Thorsten Leemhuis wrote on 24.11.2009 08:44: > > Thorsten Leemhuis wrote on 17.11.2009 20:47: > >> On 17.11.2009 07:54, Thorsten Leemhuis wrote: > >>> Thorsten Leemhuis wrote on 11.11.2009 22:30: > >>>> As you may have heard already, several seats of the Fedora > >>>> Board, FESCo, and FAMSCO are up for election soon(¹). Right now > >>>> we are in the nomination period, which will be followed by a > >>>> "Candidate Questionnaire." [...] > >> Deadline for answers: 20091124-06:00 UTC [...] > > Quick status update: I sent the questions to 23 people and 19 of them > > replied with the answers. I didn't get any replies to the questions (or > > my reminder mail from Sunday evening) from > > > > * Rodrigo Padula de Oliveira (RodrigoPadula) > > * Max Spevack (spevack) > > * Scott Seiersen (sseiersen) > > * Will Woods (wwoods) > > Max sent a apology, but the other remained silent afaics. > > > I hope to find time to work through the answers later today (in > > something like 12 hours from now) and publish them afterwards. > > Compiled a wiki page with the answers and gave the nominees 12 hours to > check the results. A few bugs were found and fixed, but I think > everything is fine now. > > So the answers are now free for public consumption on this page: > https://fedoraproject.org/wiki/Elections/F13_Questionnaire Thorsten, thanks for the time and effort you put into this. We'll make sure to notify the community that if they want to see results for a questionnaire for the next election, someone will need to take over this responsibility. Your help has been much appreciated! -- 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: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On 30/11/09 09:55, Terry Barnaby wrote: On 11/29/2009 11:30 PM, Dan Williams wrote: On Sat, 2009-11-28 at 09:10 +, Terry Barnaby wrote: On 11/28/2009 08:35 AM, Rakesh Pandit wrote: 2009/11/28 Terry Barnaby wrote: If the NetworkManager service is running, but not managing the current network connection, then Firefox starts up in offline mode. Is this a bug in NetworkManager or Firefox ? This is odd behaviour and needs to be fixed. I would suggest open up a bug against firefox. I know one can change toolkit.networkmanager.disable preference, but it is a PITA for our users. One of use cases is: Sometime network manager does not connect me via my CDMA usb modem (in case signal is weak), but wvdial does and once I switch from NM to wvdial, my firefox gets to offline mode, which I don't expect it to as I am connected. Ok, filed as: 542078 NetworkManager is intended to control the default internet connection. If NetworkManager cannot control the default internet connection, then you may not want to use NetworkManager. In your case, you're using a mobile broadband device. The real bug here is that for whatever reason, NM/MM aren't connecting your modem, and we should follow up on that bug instead. Dan I am not using a mobile broadband device. The network connection my systems use is not just the Internet it is a local network LAN connection that also serves the internet. Most of my systems use a local network server which provides NIS, /home and /data using NFS and VPN etc. I normally use the service "network" to bring up wired or wireless networking for this. Fedora, by default, uses NetworkManager to manage all network devices though. I use the service "network" as, for some reason, the NetworkManager service is started after the netfs and other services are started. Is there a reason for this ?? Don't know about the reason, but on my work desktop (where we have LDAP auth and NFS home dirs), I can still use NetworkManager in F12: * Make sure your LAN interfaces are marked "available to all users" in NetworkManager (I think this corresponds to "ONBOOT=yes" in /etc/sysconfig/ifcfg-eth*) * Add to /etc/sysconfig/network: NETWORKWAIT=true This should bring the network up before netfs. Unfortunately I've had to revert to the old network service because I need bridged networking for my virt guests; there was a plan to support this in NetworkManager in F-12 (http://fedoraproject.org/wiki/Features/NetworkManagerBridging) but nothing seems to have happened with that, though I see there is a similar feature proposed for F-13 (http://fedoraproject.org/wiki/Features/Shared_Network_Interface). Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-11-18 x86_64
On Sun, 22 Nov 2009 09:39:49 +0100 Gianluca Sforna wrote: > On Fri, Nov 20, 2009 at 10:05 PM, Matt Domsch > wrote: > > > > it's not SELinux (that is Disabled on my builders). I believe it > > is: Bug 510183 - mock mounts /dev/pts in chroot with wrong options > > > > because the failure comes during your %check section: > > openpty failed > > Child returncode was: -15 > > Is this the same as my buildbot failure? I see: > > [ERROR]: buildbot.test.test_slavecommand.ShellPTY.testShell1 > Traceback (most recent call last): > File > "/builddir/build/BUILD/buildbot-0.7.11p3/buildbot/slave/commands.py", > line 388, in start self._startCommand() > File > "/builddir/build/BUILD/buildbot-0.7.11p3/buildbot/slave/commands.py", > line 507, in _startCommand usePTY=self.usePTY) > File > "/usr/lib/python2.6/site-packages/twisted/internet/posixbase.py", > line 221, in spawnProcess processProtocol, uid, gid, usePTY) > File "/usr/lib/python2.6/site-packages/twisted/internet/process.py", > line 812, in __init__ > masterfd, slavefd = pty.openpty() > File "/usr/lib/python2.6/pty.py", line 29, in openpty > master_fd, slave_name = _open_terminal() > File "/usr/lib/python2.6/pty.py", line 70, in _open_terminal > raise os.error, 'out of pty devices' > exceptions.OSError: out of pty devices Looks like it. Does a koji scratch build succeed? > If so, should I just close the bug? I'd wait until Matt's builders are fixed or you might just end up getting another bug raised. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-11-18 x86_64
On Fri, 20 Nov 2009 15:05:12 -0600 Matt Domsch wrote: > On Fri, Nov 20, 2009 at 09:20:54PM +0100, Robert Scheck wrote: > > Hello Matt, > > > > On Wed, 18 Nov 2009, Matt Domsch wrote: > > > mksh-39-1.fc12 (build/make) robert > > > > I tried to reproduce your build failure from your mass rebuild for > > mksh > > > > - > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/mksh-39-1.fc12.src.rpm/result/build.log > > - > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/mksh-39-1.fc12.src.rpm/result/build.log > > > > using a koji scratch build at the Fedora buildsystem - and there it > > did not fail: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1820331 > > > > I think, you've enabled SELinux at your buildsystem which causes > > the /dev/* files to be missing in the end, but compare yourself: > > it's not SELinux (that is Disabled on my builders). I believe it is: > Bug 510183 - mock mounts /dev/pts in chroot with wrong options > > because the failure comes during your %check section: > openpty failed > Child returncode was: -15 > > The builders are all running mock-0.9.19-1.fc12.noarch, which claims > in %changelog to have the fix for Bug 510183, but there are now > several FTBFS bugs blocking on it still, so the problem remains... The original problem that Bug 510183 was reported about is indeed fixed, but along with the fix came an enhancement to use separate instances of /dev/pts in the chroots where the kernel supported it, and this enhancement is broken. As mentioned in Comment 10 of the bug, commenting out two lines mock/backend.py to disable the enhancement should be sufficient to get these packages building again. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On 20/11/09 11:24, Matthew Booth wrote: Firstly, I'd like to say I think abrt is fantastic. Call what follows a nit-pick. It's just a pretty in-your-face nit. After installing F12, after a short while I got presented with a couple of SELinux errors. This is nothing unusual in a new Fedora release, but this time it asked me for my bugzilla login details and offered to submit the bug automatically for me. Fantastic! The lazy person in me who wants to do the right thing truly appreciates this. Turns out I wasn't the first person report them, so it added me to the CC list. There are, however, still 2 significant problems with this. Firstly it needed a BZ login. I happen to have one, and I use it often enough that I don't need a password reset every time. However, I'll bet I'm in the minority of Fedora users[1]. To get useful bug reports from the unwashed masses we need anonymous submission, or at least submission which doesn't require any kind of account creation or authentication. Secondly, I'm now being subjected to bugzilla spam every time anybody else does the right thing. I have received 24 bugzilla spams in the last 12 hours telling me that other people have been added to the CC list. This information is interesting to people who want to know how to prioritise bugs, but it's not interesting to me, the submitter. I can remove myself from the CC list, but the lazy person in me whispers it might just be easier not to submit bugs. If you've used Windows, you'll be familiar with the Windows send bug report dialog. I've once seen it additionally give me useful information. After submission it told me a fix was available and sent me to a web page which told me where to get an updated third-party driver. That's what I really want to know: can I fix it? So, turning that into some feature requests: 1. Can Fedora enable anonymous/unauthenticated bug submission. 2. Can abrt not add duplicate reports to the CC list. 3. Can abrt/Fedora please ensure that original abrt reporters don't get email either. FWIW, you could configure this for your own account by editing your bugzilla email preferences to not send you mail when the Cc: list changes. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, Nov 19, 2009 at 02:37:36PM -0800, Adam Williamson wrote: > On Fri, 2009-11-20 at 09:25 +1100, Bojan Smojver wrote: > > On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote: > > > > > I would have thought, it should have actually convinced you to not > > > indulge in same thing but apparently not. I will lower my expectations. > > > > You don't seem to realise that right now you have a protest staged > > outside your office. Your response appears to be "all you stupid people > > go home and wait for a decision". > > No-one's calling anyone stupid. What would you suggest would be better > than escalating the issue at the first available opportunity to the > appropriate authority - FESco - which is exactly what's happened? The > only alternative is for someone to abuse Red Hat chains of command to > force some kind of change in this policy, which is exactly the kind of > thing that should _not_ happen in Fedora. The current process appears to > precisely the correct one, so far as I can see. The issue will be > considered in very timely fashion by the appropriately-constituted (and > majority-elected!) authority, which will decide what the appropriate > response will be. Those aren't the only alternatives. There's also the alternative of the maintainers voluntarily making a change to accommodate feedback. A situation where we have one part of the Fedora community giving unwanted marching orders to the other parts of the Fedora community is not an optimal result. (Where that's happened before on rare occasions, it's never been a good thing.) I'm not saying that FESCo shouldn't have purview over the issue, just that you're really drawing a black and white picture where there's clearly some in-between. -- 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: Security policy oversight needed?
On Thu, Nov 19, 2009 at 12:32:50PM +, Richard Hughes wrote: > 2009/11/19 Naheem Zaffar : > > policykit-profile-server > > policykit-profile-controlled-deployment > > policykit-profile-personal-desktop > > Sure, that's not an insane idea at all. I would imagine most network > admins worth their salt would be shipping custom PolicyKit overrides > in F12 anyway. Aim for the desktop use cases on the "Desktop" spin, > and let other spins change the defaults. It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. A good bit of this issue would need to be addressed upstream though. (Maybe I just repeated what you said, not sure if I caught the nuance.) -- 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
Broken dependencies script at it again
Please make it stop. milter-regex-1.7-6.fc12.ppc requires /bin/sh I guess this is happening because of dropping ppc/ppc64 as primary arches? ISTR the last time the dep checker went off on a mailbombing session it was suggested that it checks for broken deps against obvious things like /bin/sh and declared itself insane, sparing us all the pointless mails? Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 has gone gold
On Mon, Nov 09, 2009 at 10:39:23PM -0600, Bruno Wolff III wrote: > On Tue, Nov 10, 2009 at 09:55:03 +0530, > Rahul Sundaram wrote: > > > > Hopefully Nouveau gets 3D support within a couple of releases as well. > > Getting rid of the biggest pain of proprietary drivers would be one > > giant step forward for Linux on the desktop. > > Yeah. While I wouldn't go out and buy nvidia cards I have a couple in systems > I got as scrap and it would be nice to have 3d on them. I don't trust the > nvidia stuff not to screw things up for helping test the nouveau drivers, > so I have been stuck with only 2d support for a good chunk of F12's > development. > > The nouveau guys have made a surprising amount of progress and I think there > is a good chance they will have good 3d support 2 or 3 releases down the road. > (Though I would like to see Red Hat help out more to cut this to 1 or 2 > releases, since I think the current situation hurts Fedora.) I'd also > like to see people move away from Cg and use the free and more portable > equivalents. I had the good fortune to meet Ben Skeggs, a nouveau developer at Red Hat's Brisbane office, and tell him how effective some of his work has been so far. (I have a laptop with NVidia, not by choice but through a weird set of circumstances you can find on my blog from last year.) I have full KMS now on this laptop, and while there's no 3D yet, I still managed to surprise a bunch of people here in Brisbane by plugging my laptop into an external LCD TV, and having it just work. I used this as a great example of how 6 months in Fedora-land can bring a lot of changes. By the way, I also met Dave Airlie and told him my r770-based ATI card was also rocking, with the added bonus of 3D support. I'm really happy with the progress in F12 and I hope other people enjoy it too! -- 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: rawhide report: 20091104 changes - excluding noarch packages
On 04/11/09 17:09, Peter Lemenkov wrote: 2009/11/4 Orion Poplawski: Is there any way to exclude a noarch package from certain arches? If it does depends on arch, then it isn't a noarch. So a noarch script package that depends on its arch script interpreter (e.g. all python and perl packages) should be arch packages? Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: httpd run directory permissions in F12/11
On 29/10/09 11:29, Clodoaldo Neto wrote: I've been using Fedora 10 and while trying F12 beta I noticed a problem in the httpd run directory permission. Then I tried F11 and the same problem happens: [Wed Oct 28 12:05:02 2009] [notice] Apache/2.2.13 (Unix) DAV/2 PHP/5.2.9 mod_python/3.3.1 Python/2.6 mod_ssl/2.2.13 OpenSSL/0.9.8k-fips mod_wsgi/2.6 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations [Wed Oct 28 12:05:09 2009] [error] [client 10.0.2.15] (13)Permission denied: mod_wsgi (pid=2722): Unable to connect to WSGI daemon process 'mygroup' on '/etc/httpd/run/wsgi.2692.0.1.sock' after multiple attempts. The problem is that until F10 the httpd socket directory was /var/run/ and in F11 and F12 it is /var/run/httpd: # ll /etc/httpd/run lrwxrwxrwx. 1 root root 19 2009-10-28 11:04 /etc/httpd/run -> ../../var/run/httpd # ll -d /var/run/httpd drwx--. 2 root root 4096 2009-10-28 11:51 /var/run/httpd # ll -d /var/run drwxr-xr-x. 31 root root 4096 2009-10-28 11:35 /var/run # ll /var/run/httpd/ total 4 -rw-r--r--. 1 root root 5 2009-10-28 12:05 httpd.pid srwx--. 1 apache root 0 2009-10-28 12:05 wsgi.2692.0.1.sock That can break some apache modules like mod_wsgi which rely on sockets. Any of these solve the problem: # chmod o+x /var/run/httpd # chown apache.root /var/run/httpd Is there a reason for the /var/run/httpd permissions to be as in F11/12 ? Is it necessary to have the user intervention to fix it? I have posted at the mod_wsgi list: http://groups.google.com/group/modwsgi/t/c5f5abc122088478 I had exactly the same problem with mod_fcgid and ended up creating a separate socket directory /var/run/mod_fcgid with appropriate permissions instead of following /etc/httpd/run. If you create a directory matching /var/run/mod_.* with suitable permissions and include that directory in your package then it should get the right SELinux context set so that it will work out of the box. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Wed, Sep 30, 2009 at 01:52:07PM -0400, Steve Dickson wrote: > On 09/30/2009 01:47 PM, Paul W. Frields wrote: > > On Wed, Sep 30, 2009 at 01:11:56PM -0400, Steve Dickson wrote: > >> After further review... by a number of people, its been decided > >> the /etc/nfsmount.conf file will be installed with the default > >> protocol version set to v3. This will stop the mount failures > >> with older Linux servers but make it very easy to make v4 > >> the default version. A nice compromise, IMHO... > >> > >> Note, with nfsmount.conf file one can configure mount options > >> per mount point, per server and globally (which is how the default > >> version will be set). See the nfsmount.conf(5) for details. So > >> I strongly urge you try the v4 protocol by setting the version > >> to v4 in one of those sections... > >> > >> The new nfs-utils rpm will be ready shortly... > >> > >> My apoloizes for all the excitement... It was truly unintended > >> and unexpected... :-\ > > > > Steve, > > > > One thing you could do to spread the knowledge about NFSv4 > > capabilities would be to write a bit in the Release Notes beat that > > covers NFS, encouraging people to try the setting in appropriate > > environments: > > > > https://fedoraproject.org/wiki/Documentation_Networking_Beat > > > > (There may be another place to put this information -- consult with > > the Docs team at #fedora-docs for more information.) > > > Good idea... but when is that deadline? 8-) According to the schedules at http://poelstra.fedorapeople.org/schedules/f-12/ , the preparation of the GA release notes starts on 2009-10-13, so if I were you I'd have the change on the wiki before then. -- 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: Buyer Beware: A Major Change in NFS is about to happen
On Wed, Sep 30, 2009 at 01:11:56PM -0400, Steve Dickson wrote: > After further review... by a number of people, its been decided > the /etc/nfsmount.conf file will be installed with the default > protocol version set to v3. This will stop the mount failures > with older Linux servers but make it very easy to make v4 > the default version. A nice compromise, IMHO... > > Note, with nfsmount.conf file one can configure mount options > per mount point, per server and globally (which is how the default > version will be set). See the nfsmount.conf(5) for details. So > I strongly urge you try the v4 protocol by setting the version > to v4 in one of those sections... > > The new nfs-utils rpm will be ready shortly... > > My apoloizes for all the excitement... It was truly unintended > and unexpected... :-\ Steve, One thing you could do to spread the knowledge about NFSv4 capabilities would be to write a bit in the Release Notes beat that covers NFS, encouraging people to try the setting in appropriate environments: https://fedoraproject.org/wiki/Documentation_Networking_Beat (There may be another place to put this information -- consult with the Docs team at #fedora-docs for more information.) -- 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: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 06:21:04PM -0700, Toshio Kuratomi wrote: > Examples of what to do and not do from this point forward: > Do: Have something testable > Do: Have the the feature significantly complete > Do: submit bugfixes > Do not: Enable the feature by default > Do not: Make changes that cause other software to have to make changes I thought this was a particularly good idea. -- 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: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 07:12:03PM -0400, Steve Dickson wrote: > On 09/29/2009 06:55 PM, Paul W. Frields wrote: > > On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: > >> > >> > >> On 09/29/2009 06:13 PM, Jesse Keating wrote: > >>> On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: > >>>> I thought today was the dead line... > >>>> > >>>> http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html > >>>> > >>> > >>> I should mention that Beta is the deadline to have the code in what we > >>> think is the final state, baring any glaring bugs, not a point to enable > >>> experimental code/settings for further experimentation. > >> This is in the final state... its been a 18 month effort to get this > >> accepted by upstream... > >> > >> At the end of the day, I was just following the rules that were deemed by > >> that email and a number of earlier ones... I'm a bit dumbfound... > > > > I think that what we need, Steve, is some sort of information about > > what testing has happened up to this point that satisfies FESCo that > > this change the equivalent of moving the needle from 99% complete to > > 100% complete, as opposed to moving from 90% complete to 91% complete > > (with testing being the last 9%). > > > Not a problem... I want to and will work closely with FESCo to make > sure we know all the ins and outs of this change... believe me my > slate is cleared for few weeks to be as responsive as possible > for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an "all clear" on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. -- 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: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: > > > On 09/29/2009 06:13 PM, Jesse Keating wrote: > > On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: > >> I thought today was the dead line... > >> > >> http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html > >> > > > > I should mention that Beta is the deadline to have the code in what we > > think is the final state, baring any glaring bugs, not a point to enable > > experimental code/settings for further experimentation. > This is in the final state... its been a 18 month effort to get this > accepted by upstream... > > At the end of the day, I was just following the rules that were deemed by > that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). -- 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: yum-presto not on by default
On Wed, Sep 23, 2009 at 10:23:31AM -0400, Seth Vidal wrote: > On Wed, 23 Sep 2009, James Antill wrote: >> No, we have at least 3 problems I think: >> >> 1. Nobody wants to download uncompressed rpms, if they don't have >> presto. >> >> 2. gig signature is over the rpm data (and thus. is over compressed >> data). >> >> 3. createrepo sha256 data is over the entire rpm (and thus. is over >> compressed data). >> >> ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If >> nobody can fix xz before F12 GA then IMNSO we should revert the >> compression to something that works ... the minor savings in xz >> compression isn't worth as much as delta's. >> > > agreed. The xz feature is among the Fedora 12 talking points, so I've made a note to track this going forward. https://fedoraproject.org/wiki/Fedora_12_Talking_Points We'll need a heads-up to the Marketing list if there's a reversion that affects F12 GA. -- 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: perl-Mail-:SPF should obsolete perl-Mail-SPF-Query
On 21/09/09 19:16, Warren Togami wrote: On 09/21/2009 11:41 AM, Paul Howarth wrote: On 21/09/09 16:33, Warren Togami wrote: Should we obsolete and remove perl-Mail-SPF-Query? Apparently perl-Mail-SPF obsoleted perl-Mail-SPF-Query ~3 years ago. Really? Says who? It certainly doesn't provide any implementation of Mail::SPF::Query. spampd owned by thias is the only package according to repoquery that requires perl(Mail::SPF::Query). What is to be gained by doing this other than a miniscule saving in mirror space and metadata size? Paul. What stake do you have in defending software that hasn't been developed in 3+ years? I'm sure there's plenty of software in Fedora that hasn't been developed in 3+ years, sometimes as in this case because it's dead upstream and sometimes because it's simply stable and doesn't need fixing. Other than the fact that I did the original upstream packaging for this module, I have no particular attachment to this package. If it goes from Fedora I won't miss it myself. I fully accept that any new development of perl code using SPF will use Mail::SPF and not Mail::SPF::Query. I see that you're removing the (optional) SPF functionality from spampd, which is OK because it passes mail through SpamAssassin, which has its own SPF code, so there won't be any user of Mail::SPF::Query in Rawhide. There may still be out-of-distribution code such as the original sendmail-spf-milter that uses it though. On 21/09/09 23:37, Warren Togami wrote: > On 09/21/2009 05:06 PM, Warren Togami wrote: > spampd was requiring perl(Mail::SPF::Query) for no good reason. > Rather than require Mail::SPF I've stripped that artificial > requirement because SPF is actually rather useless. So now nothing > in Fedora requires perl(Mail::SPF::Query). Since SPF is as you say "rather useless", why aren't you trying to get rid of Mail::SPF too? > I'm soon blocking perl-Mail-SPF-Query from rawhide. It is true that > perl-Mail-SPF does not provide perl(Mail::SPF::Query). perl-Mail-SPF > will obsolete perl-Mail-SPF-Query to ensure its removal but not > "provide" for the old package. > > Any objections? I'm not objecting to perl-Mail-SPF-Query being blocked from Rawhide and marked as a dead package, given its maintainer's consent. I am, however, curious as to just why you've singled out this particular package out of the myriad of legacy code that's in the distribution and doing no harm. Or is there some big issue with it that I'm not aware of? I'm also not sure about the merits of having perl-Mail-SPF obsolete perl-Mail-SPF-Query. Why do we need to remove something from users' systems that (a) they may be actually using, and (b) does not in any way conflict or cause problems for the upgraded distribution? Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: perl-Mail-:SPF should obsolete perl-Mail-SPF-Query
On 21/09/09 16:33, Warren Togami wrote: Should we obsolete and remove perl-Mail-SPF-Query? Apparently perl-Mail-SPF obsoleted perl-Mail-SPF-Query ~3 years ago. Really? Says who? It certainly doesn't provide any implementation of Mail::SPF::Query. spampd owned by thias is the only package according to repoquery that requires perl(Mail::SPF::Query). What is to be gained by doing this other than a miniscule saving in mirror space and metadata size? Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dnssec-conf problem
On Sat, 19 Sep 2009, Gene Czarcinski wrote: https://bugzilla.redhat.com/show_bug.cgi?id=505754 https://bugzilla.redhat.com/show_bug.cgi?id=510290 https://bugzilla.redhat.com/show_bug.cgi?id=523973 I have closed 510290 and 523973 as dups of 505754. Report 505754 has a comment by p...@xelerance.com dated 2009-06-25 that the bug has been found and that the fix in is dnssec-conf 1.22 which will be posted "today" (2008-06-25). Since that time ... nothing ... including and especially no 1.22. Sorry. I was stuck on a pyparsing bug that prevented me from getting this working before, and it kind of escaped my attention. I am not sure what happened to Paul (accident? fired? three month vacation? ??) but there appears to be no active author/creator/maintainer since late June or since about three months ago. I've been active with Fedora, just not on this issue. And certainly not misisng as a single email or popping on #fedora-devel would have shown you. Another possible work around may be to remove the dnssec-conf package (I have not tried this so I am not sure). Or setting /etc/sysconfig/dnssec's DNSSEC to false. If there is anyone with pyparsing experience around to help my solve a bug preventing me to releasea new dnssec-configure based on pyparsing, please drop me a line. Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mono-2.6 - heads up
Hi Folks, Just spotted on the mono forums that mono-2.6 is being branched on Monday which means that it (should) be in the Rawhide repos Tuesday. As it stands, 2.6 is a world of difference to 2.4.2.3 in terms of speed and reliability. I've not encountered any big problems with code compiled under previous versions of Mono not running under the 2.6 svn branch yet, so it should be good and smooth. I would recommend though that maintainers of applications reliant on mono recompile them against 2.6 when it hits rawhide just to be safe. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: how to become a co-maintainer for an _existing_ RPM pkg
On 15/09/09 12:50, Josephine Tannhäuser wrote: I want to become a maintainer too and I want to impress with some unofficial reviews. Don't really know if this is socially accepted to nag in other reviews without having an open review request Go right ahead. A valid comment is a valid comment regardless of whether or not you have a review request open. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On Sun, Sep 13, 2009 at 10:07:46PM +0530, Aditya Patawari wrote: >I was just reading the mails about the Fedora print magazine. There > Paul Frields said that "In the longer term we really do want to move >away from the Install DVD to a Live DVD that has more >relevant applications and content". We didn't had any SIG for creating >Live DVD and Live DVD spin. So I have started the same. The main motive of >the SIG will be to roll out one live DVD per fedora release which will >have all the packages of live cd and other packages as suggested by the >community. For this to be a success, community support is very much >required. Interested contributors please join the SIG at >[1]https://fedoraproject.org/wiki/SIGs/LiveDVD .� Any kind of suggestions >or pointers are most >welcome. To clarify, what I was talking about was the fact that the Installation DVD is really just a continuation of what has shipped since time immemorial in Red Hat Linux many years ago. It doesn't have any particular target. At the same time, our Live CDs are highly constrained by a combination of (1) the 700 MB limit, and (2) our desire -- a worthy one, IMHO -- to keep them usable in as many languages as possible. So whenever we talk about media that includes a bunch of applications that users do really want, but we can't include on a CD-sized medium, we fall back to the DVD, which loses much of the appeal of the Live image. I think the Desktop SIG has already been discussing the need for a larger image due to constantly having to bump out useful applications to stay under the CD size limit. At the same time, the Installation DVD does provide a helpful testing bed for Anaconda. Mainly, I was just interested in the idea of existing SIGs feeling empowered to produce their Live spins for larger media, rather than everyone needing more applications having to fall back to the Installation DVD. I'm not sure what an equally untargeted generic Live spin really achieves, but at the same time, if there are contributors interested in producing one, our spin process certainly permits it. -- 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: Fedora 12 Beta Blocker Meeting #1 Recap--2009-09-11
On Fri, Sep 11, 2009 at 01:51:09PM -0700, John Poelstra wrote: > Today was the first of many exciting blocker bug review meetings in > anticipation of the Fedora 12 Beta release. Thanks to everyone who > filed bugs and participated in the discussion. I think we saw a much > smoother release (or at least less surprises) of the Fedora 12 Alpha by > doing these reviews each week. Hopefully the same will be true for the > Beta and final release! I wanted to suggest https://bugzilla.redhat.com/show_bug.cgi?id=518880 as a candidate for blocker status, because it's a regression in a well-publicized feature. (The maintainers are already aware of the problem and working on it, I'd just like to make sure it's not lost in the shuffle.) That criterion is worth considering generally for blocker status. But maybe it needs some refinement? -- 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: Changes to openvrml.spec
On Sat, 12 Sep 2009 19:10:35 -0400
"Tom \"spot\" Callaway" wrote:
> On 09/12/2009 07:05 PM, Tom "spot" Callaway wrote:
> > If and when they do so, then (and ONLY THEN) is it appropriate for
> > you to have:
> >
> > Requires: foo%{isa}
>
> Ugh, this should be:
>
> Requires: bar%{isa}
>
> (as I pointed out, foo%{isa} will always work in modern Fedora
> (F10+)).
>
> Sorry for the confusion.
And you probably mean %{_isa} rather than %{isa} too.
Paul.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
FUDCon Toronto 2009 update!
her with you the next day to work on it! You can start by adding information about your hackfest in advance. Visit this URL and add what you'll be working on: https://fedoraproject.org/wiki/FUDCon:Toronto_2009#Hackfests More information will be forthcoming as it develops! - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKqpnlrNvJN70RNxcRApVuAKDWq7S4kFEcUagLywpnexpUJG8zlACgg6Kl TulrYZytVEODthDvKelaSuk= =w/XB -END PGP SIGNATURE- ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug buddy and gnomebreakpad
On Thu, Sep 10, 2009 at 06:57:43PM -0400, Matthias Clasen wrote: > On Thu, 2009-09-10 at 18:40 -0400, Tom "spot" Callaway wrote: > > On 09/10/2009 06:36 PM, Matthias Clasen wrote: > > > should get rid of it. The harder question is where to put that > > > command... > > > > %post for abrt-gui ? :) > > That doesn't help, since the gconf key is in your users gconf db. The > command has to be run inside your session to have the desired effect. > > Conceivably, abrt-applet could do it on startup. The fix, workaround, or decision not to provide either should definitely get a mention in the release notes. Just edit the wiki here: https://fedoraproject.org/wiki/Documentation_Desktop_Beat -- 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
gtk-sharp2 heads up
Hi, Monodevelop 2.2 beta 1 has just hit paydirt and, of course, I've built it and plonked it over to koji to do its magic. However, to get MD to compile, I've also had to update gtk-sharp2 to 2.12.9. This should not have any direct effect on anything else, but you can never tell.. MD 2.2 (full version) is due in October sometime. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: source file audit - 2009-08-10
On 09/09/09 14:26, Zoltan Kota wrote: On Mon, 10 Aug 2009, Kevin Fenzi wrote: zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar It seems the bazaar-1 (aka baz) sources are not available anymore at the bazaar's site. At least I haven't found them. What to do with this then? (I know, this package is dead, and I will likely orphan it soon. :-) ) Try here: http://bazaar-vcs.org/releases/src/obsolete/ Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On Thu, 03 Sep 2009 10:53:54 -0600
Philip Prindeville wrote:
> Paul Howarth wrote:
> > On 03/09/09 17:07, Philip Prindeville wrote:
> >
> >> Paul Howarth wrote:
> >>
> >>> On 02/09/09 22:52, Philip Prindeville wrote:
> >>>
> >>>
> >>>> Seems to be an rpm versioning issue:
> >>>>
> >>>> [r...@builder SRPMS]# mock -r fedora-10-x86_64 --rebuild
> >>>> perl-Net-Patricia-1.15_01-1.fc9.src.rpm INFO: mock.py version
> >>>> 0.9.14 starting... State Changed: init plugins
> >>>> State Changed: start
> >>>> INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
> >>>> Config(fedora-10-x86_64) State Changed: lock buildroot
> >>>> State Changed: clean
> >>>> State Changed: init
> >>>> State Changed: lock buildroot
> >>>> Mock Version: 0.9.14
> >>>> INFO: Mock Version: 0.9.14
> >>>> INFO: enabled root cache
> >>>> State Changed: unpacking root cache
> >>>> INFO: enabled yum cache
> >>>> State Changed: cleaning yum metadata
> >>>> INFO: enabled ccache
> >>>> State Changed: running yum
> >>>> State Changed: setup
> >>>> ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
> >>>> Config(fedora-10-x86_64) 0 minutes 15 seconds INFO: Results
> >>>> and/or logs in: /var/lib/mock/fedora-10-x86_64/result ERROR:
> >>>> Command failed: # /usr/bin/yum
> >>>> --installroot /var/lib/mock/fedora-10-x86_64/root/ resolvedep
> >>>> ccache 'perl(ExtUtils::MakeMaker)' rpmdb: Program version 4.3
> >>>> doesn't match environment version error: db4 error(-30974) from
> >>>> dbenv->open: DB_VERSION_MISMATCH: Database environment version
> >>>> mismatch error: cannot open Packages index using db3 - (-30974)
> >>>> error: cannot open Packages database
> >>>> in /var/lib/mock/fedora-10-x86_64/root/var/lib/rpm Traceback
> >>>> (most recent call last): File "/usr/bin/yum", line 29,
> >>>> in yummain.user_main(sys.argv[1:], exit_code=True) File
> >>>> "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode
> >>>> = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in
> >>>> main base.getOptionsConfig(args) File
> >>>> "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
> >>>> enabled_plugins=self.optparser._splitArg(opts.enableplugins))
> >>>> File "/usr/lib/python2.5/site-packages/yum/__init__.py", line
> >>>> 192, in _getConfig self._conf =
> >>>> config.readMainConfig(startupconf) File
> >>>> "/usr/lib/python2.5/site-packages/yum/config.py", line 774, in
> >>>> readMainConfig yumvars['releasever'] =
> >>>> _getsysver(startupconf.installroot, startupconf.distroverpkg)
> >>>> File "/usr/lib/python2.5/site-packages/yum/config.py", line 844,
> >>>> in _getsysver idx = ts.dbMatch('provides', distroverpkg)
> >>>> TypeError: rpmdb open failed
> >>>>
> >>>> [r...@builder SRPMS]#
> >>>>
> >>>>
> >>>>
> >>>> The host was originally an FC8 host, that was yum updated to
> >>>> FC9. I use it to build FC9 and FC10 packages via Mock.
> >>>>
> >>>> Unfortunately, it looks like it doesn't want to use the old RPM
> >>>> database from the previous FC8 install.
> >>>>
> >>>> How do I clobber all of this to that the database gets written
> >>>> afresh?
> >>>>
> >>>> Apparently, "mock -r fedora-10-x86_64 --clean" isn't adequate.
> >>>> Perhaps "mock --nuke" would be useful here following an version
> >>>> update to zap stale state?
> >>>>
> >>>> Or should I just uninstall and reinstall mock?
> >>>>
> >>>>
> >>> I'd try this first:
> >>>
> >>> # rm -rf /var/lib/mock/fedora-10-x86_64/root
> >>>
> >>> Paul.
> >>>
> >>>
> >>>
> >> No joy:
> >>
> >> [r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
> >> [r...@builder SRPMS]# mock -r fedora-10-x86_64 --init
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On 03/09/09 17:07, Philip Prindeville wrote:
Paul Howarth wrote:
On 02/09/09 22:52, Philip Prindeville wrote:
Seems to be an rpm versioning issue:
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --rebuild
perl-Net-Patricia-1.15_01-1.fc9.src.rpm
INFO: mock.py version 0.9.14 starting...
State Changed: init plugins
State Changed: start
INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm) Config(fedora-10-x86_64)
State Changed: lock buildroot
State Changed: clean
State Changed: init
State Changed: lock buildroot
Mock Version: 0.9.14
INFO: Mock Version: 0.9.14
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64) 0 minutes 15 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result
ERROR: Command failed:
# /usr/bin/yum --installroot /var/lib/mock/fedora-10-x86_64/root/
resolvedep ccache 'perl(ExtUtils::MakeMaker)'
rpmdb: Program version 4.3 doesn't match environment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database
environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in
/var/lib/mock/fedora-10-x86_64/root/var/lib/rpm
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in
yummain.user_main(sys.argv[1:], exit_code=True)
File "/usr/share/yum-cli/yummain.py", line 229, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 84, in main
base.getOptionsConfig(args)
File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
enabled_plugins=self.optparser._splitArg(opts.enableplugins))
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 192, in
_getConfig
self._conf = config.readMainConfig(startupconf)
File "/usr/lib/python2.5/site-packages/yum/config.py", line 774, in
readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
File "/usr/lib/python2.5/site-packages/yum/config.py", line 844, in
_getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
[r...@builder SRPMS]#
The host was originally an FC8 host, that was yum updated to FC9. I use
it to build FC9 and FC10 packages via Mock.
Unfortunately, it looks like it doesn't want to use the old RPM database
from the previous FC8 install.
How do I clobber all of this to that the database gets written afresh?
Apparently, "mock -r fedora-10-x86_64 --clean" isn't adequate. Perhaps
"mock --nuke" would be useful here following an version update to zap
stale state?
Or should I just uninstall and reinstall mock?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
No joy:
[r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --rebuild
perl-Net-Patricia-1.15_01-1.fc9.src.rpm
INFO: mock.py version 0.9.14 starting...
State Changed: init plugins
State Changed: start
INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm) Config(fedora-10-x86_64)
State Changed: lock buildroot
State Changed: clean
State Changed: init
State Changed: lock buildroot
Mock Version: 0.9.14
INFO: Mock Version: 0.9.14
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64) 0 minutes 30 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result
ERROR: Command failed:
# /usr/bin/yum --installroot /var/lib/mock/fedora-10-x86_64/root/ resolvedep
ccache 'perl(ExtUtils::MakeMaker)'
rpmdb: Program version 4.3 doesn't match environment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database
environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in
/var/lib/mock/fedora-10-x86_64/root/var/lib/rpm
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in
yummain.user_main(sys.argv[1:], exit_code=True)
File "/usr/share/yum-cli/yummain.py", line 229, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 84, in main
base.getOptionsConfig(args)
File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
enabled_plugins=self.optparser._splitArg(opts.enableplugins))
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 192, in
_getConfig
self._conf = config.readMainC
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On 02/09/09 22:52, Philip Prindeville wrote:
Seems to be an rpm versioning issue:
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --rebuild
perl-Net-Patricia-1.15_01-1.fc9.src.rpm
INFO: mock.py version 0.9.14 starting...
State Changed: init plugins
State Changed: start
INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm) Config(fedora-10-x86_64)
State Changed: lock buildroot
State Changed: clean
State Changed: init
State Changed: lock buildroot
Mock Version: 0.9.14
INFO: Mock Version: 0.9.14
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64) 0 minutes 15 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result
ERROR: Command failed:
# /usr/bin/yum --installroot /var/lib/mock/fedora-10-x86_64/root/ resolvedep
ccache 'perl(ExtUtils::MakeMaker)'
rpmdb: Program version 4.3 doesn't match environment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database
environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in
/var/lib/mock/fedora-10-x86_64/root/var/lib/rpm
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in
yummain.user_main(sys.argv[1:], exit_code=True)
File "/usr/share/yum-cli/yummain.py", line 229, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 84, in main
base.getOptionsConfig(args)
File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
enabled_plugins=self.optparser._splitArg(opts.enableplugins))
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 192, in
_getConfig
self._conf = config.readMainConfig(startupconf)
File "/usr/lib/python2.5/site-packages/yum/config.py", line 774, in
readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
File "/usr/lib/python2.5/site-packages/yum/config.py", line 844, in
_getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
[r...@builder SRPMS]#
The host was originally an FC8 host, that was yum updated to FC9. I use
it to build FC9 and FC10 packages via Mock.
Unfortunately, it looks like it doesn't want to use the old RPM database
from the previous FC8 install.
How do I clobber all of this to that the database gets written afresh?
Apparently, "mock -r fedora-10-x86_64 --clean" isn't adequate. Perhaps
"mock --nuke" would be useful here following an version update to zap
stale state?
Or should I just uninstall and reinstall mock?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit and yum --skip-broken
On Tue, Aug 25, 2009 at 02:28:21PM -0400, Michel Alexandre Salim wrote: > Would it be desirable to have a PK equivalent of yum --skip-broken? > Instead of being told that the current selection set canot be installed > because of dependency problems, a more useful message would be "some > selected packages have dependency problems -- here they are. they have > been deselected, press OK again to retry". I might be wrong, but I could swear that PK acted like this in my Rawhide machine the other day when there was a particular deps problem at the mirror. -- 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: Orphaning packages
On Fri, 21 Aug 2009 22:34:24 +0200 Aurelien Bompard wrote: > I'm orphaning a few packages I'm not using anymore, feel free to take > over: > ... > - perl-Jcode -- Perl extension interface for converting Japanese text I've taken that one. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Wed, Aug 19, 2009 at 03:57:02PM +0100, Peter Robinson wrote: > Hi Spot, > > >>> After requesting status updates, including direct email to the feature > >>> > owners, the following feature pages do not have a current status or > >>> > their > >>> > ability to tested during the Alpha is unclear based on the lack of > >>> > information provided or percentage of completion. > >>> > > >>> > https://fedoraproject.org/wiki/Features/FedoraMoblin > >> I'm the maintainer of this. I think its very much in a similar > >> category to gnome/kde. The only difference is there is some packages > >> still awaiting review, about 2 that are actually critical, but moblin > >> 2 like gnome etc are still in there development phase so its a moving > >> target. > > > > I'm concerned about FESCo's decision to drop this feature for Fedora 12. > > The more that I think about this, the more I agree with what Peter has > > written above. I think that Moblin support in Fedora is something that > > is useful to a wide audience of users, and that Peter has made every > > effort to address the concerns raised by FESCo. I do not think it is > > necessary for a spin to be made available to consider this a noteworthy > > feature. > > > > I've asked FESCo to reconsider the Moblin feature at their meeting on > > Friday, and I hope they will reconsider their decision. > > Thanks for the support. > > I've since moved my plan to do a remix for F-12 instead and reconsider > it again for F-13. The core of moblin would still be in Fedora anyway > for people to install as they see fit and the advantage of the respin > is that I can patch up xulrunner and hence include a working browser. > Either way I'm just continuing on working towards it to see where I > can get to. Its still somewhat of a moving target as they've just > split out one of the packages into a number of smaller ones. I'm not sure if this would make sense from your perspective Peter, but is it worthwhile to have a Moblin component in the comps file that delivers some set of packages (albeit without a browser, given what you mentioned above), and re-scope the F12 feature to that end? -- 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: Last call for talking points - what makes you excited about F12?
On Tue, Aug 18, 2009 at 12:27:53PM -0500, Mike McGrath wrote: > On Tue, 18 Aug 2009, Matthias Clasen wrote: > > > On Tue, 2009-08-18 at 22:18 +0530, Rahul Sundaram wrote: > > > On 08/18/2009 10:15 PM, Mel Chua wrote: > > > >>> PS: I know this is last-minute notice - sorry about that. We're still > > > >>> learning how to do things on a schedule, and next time around we'll > > > >>> put > > > >>> the call out here much earlier. > > > >> > > > >> Is there a particular reason today is the last day instead of some date > > > >> closer to the release? > > > > > > > > We need to brief Ambassadors on Talking Points at Beta release (9/22) so > > > > they need to be complete by then, so we have to freeze the list asap to > > > > give us enough time to find writers, and give the writers enough time to > > > > write them. > > > > (http://poelstra.fedorapeople.org/schedules/f-12/f-12-marketing-tasks.html) > > > > > > > > (Feel free to push back if this schedule sounds unreasonable, btw; it > > > > probably could use some patches for the next cycle in terms of having > > > > more time for getting dev feedback.) > > > > > > The schedule itself might have been fine but it still looks rather early > > > to me. If you want to collect feedback from developers, one day is > > > definitely not going to be enough. Atleast three days or so needs to be > > > provided and you usually need more than one reminder to get as much > > > feedback as you can. Otherwise you are going to end up with a rather > > > small list which is not meaningful. > > > > To a first approximation, the relevant information should already be in > > the feature pages, no ? I don't think it is wise to establish the > > feature process as painfully as we've done over the last few releases, > > only to then start new, different initiatives to collect marketing > > talking points... > > > > I think the point is to take the technical feature list and sort of run a > filter around it so it's more general purpose / markety. Additionally I > don't see any need to tie talking points and marketing directly to the > feature list in a 1:1 because we may miss things. That's fairly dead on, Mike. We can include an item beyond the feature list if there's a compelling story to tell the appropriate audience about that item. These talking points become the basis for Ambassadors to talk to their local communities, I often refer to them in interviews with press, and so forth. -- 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: Last call for talking points - what makes you excited about F12?
On Tue, Aug 18, 2009 at 01:15:27PM -0400, Matthias Clasen wrote: > On Tue, 2009-08-18 at 22:18 +0530, Rahul Sundaram wrote: > > On 08/18/2009 10:15 PM, Mel Chua wrote: > > >>> PS: I know this is last-minute notice - sorry about that. We're still > > >>> learning how to do things on a schedule, and next time around we'll put > > >>> the call out here much earlier. > > >> > > >> Is there a particular reason today is the last day instead of some date > > >> closer to the release? > > > > > > We need to brief Ambassadors on Talking Points at Beta release (9/22) so > > > they need to be complete by then, so we have to freeze the list asap to > > > give us enough time to find writers, and give the writers enough time to > > > write them. > > > (http://poelstra.fedorapeople.org/schedules/f-12/f-12-marketing-tasks.html) > > > > > > (Feel free to push back if this schedule sounds unreasonable, btw; it > > > probably could use some patches for the next cycle in terms of having > > > more time for getting dev feedback.) > > > > The schedule itself might have been fine but it still looks rather early > > to me. If you want to collect feedback from developers, one day is > > definitely not going to be enough. Atleast three days or so needs to be > > provided and you usually need more than one reminder to get as much > > feedback as you can. Otherwise you are going to end up with a rather > > small list which is not meaningful. > > To a first approximation, the relevant information should already be in > the feature pages, no ? I don't think it is wise to establish the > feature process as painfully as we've done over the last few releases, > only to then start new, different initiatives to collect marketing > talking points... The talking points really do come from the feature pages, and to that end I revisited the feature list to pull out a couple features that are comprehensible and interesting for developers, and added them to the developer-centric talking points. The list for each audience (desktop users, sysadmins, developers) is short, as it should be. We do have entries in the list now, although we'll be fleshing them out with more descriptive information over the next few days. The purpose of the talking points is to call out specific features, so Ambassadors and other people can explain what they are to a variety of audiences, and why they're important in terms of advancing FOSS. To do this, we develop additional material like podcast and print interviews with the people responsible for or involved with the features. Developing that material takes time and energy so it behooves us to get an early start, shortly after feature freeze since the list is complete at that point. The list is short so that we can concentrate on the most compelling features from the audience's standpoint. So yes, the feature pages have a lot from which we can pull at this point. -- 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: An error while using livecd-creator
On Tue, Aug 11, 2009 at 12:11:25PM +0530, Kushal Das wrote:
> Hi,
>
> I am using livecd-creator on a F-11 box. I have 27GB free on my / partition.
> The error I am getting is given below:
>
>
> [r...@rhelabi spin-kickstarts]# livecd-creator
> --config=photographers-11.ks --cache=cache/ --fslabel=photographers
> mke2fs 1.41.4 (27-Jan-2009)
> Filesystem label=photographers
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 196608 inodes, 786432 blocks
> 7864 blocks (1.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=805306368
> 24 block groups
> 32768 blocks per group, 32768 fragments per group
> 8192 inodes per group
> Superblock backups stored on blocks:
> 32768, 98304, 163840, 229376, 294912
>
> Writing inode tables: done
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information: done
>
> This filesystem will be automatically checked every 35 mounts or
> 180 days, whichever comes first. Use tune2fs -c or -i to override.
> tune2fs 1.41.4 (27-Jan-2009)
> Setting maximal mount count to -1
> Setting interval between checks to 0 seconds
> filespec_eval: hash table stats: 12 elements, 12/65536 buckets used,
> longest chain length 1
> Retrieving
> http://ftp.linux.ncsu.edu/pub/fedora/linux/releases/11/Everything/i386/os/repodata/repomd.xml
> ...OK
> Retrieving
> http://mirror.hmc.edu/fedora/linux/updates/11/i386/repodata/repomd.xml
> ...OK
> No such package *debuginfo to remove
> /usr/lib/python2.6/site-packages/imgcreate/errors.py:45:
> DeprecationWarning: BaseException.message has been deprecated as of
> Python 2.6
> return unicode(self.message)
> Error creating Live CD : Unable to install: [('installing package
> bug-buddy-1:2.26.0-2.fc11.i586 needs 684KB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 700416L)), ('installing
> package gvfs-gphoto2-1.2.3-9.fc11.i586 needs 920KB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 942080L)), ('installing
> package gvfs-fuse-1.2.3-9.fc11.i586 needs 948KB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 970752L)), ('installing
> package gvfs-smb-1.2.3-9.fc11.i586 needs 2MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 1273856L)), ('installing
> package gvfs-archive-1.2.3-9.fc11.i586 needs 2MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 1421312L)), ('installing
> package vino-2.26.2-1.fc11.i586 needs 4MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 3796992L)), ('installing
> package gnome-session-xsession-2.26.2-1.fc11.i586 needs 4MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 3805184L)), ('installing
> package postr-0.12.3-2.fc11.noarch needs 5MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 4587520L)), ('installing
> package gnome-panel-2.26.3-1.fc11.i586 needs 16MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 16580608L)), ('installing
> package gnome-applets-1:2.26.3-1.fc11.i586 needs 40MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 41603072L)), ('installing
> package bluez-4.42-1.fc11.i586 needs 41MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 42848256L)), ('installing
> package pulseaudio-module-bluetooth-0.9.15-14.fc11.i586 needs 42MB on
> the /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 43061248L)), ('installing
> package gnome-bluetooth-2.27.5-1.fc11.i586 needs 43MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 44228608L)), ('installing
> package gnome-bluetooth-libs-2.27.5-1.fc11.i586 needs 43MB on the
> /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
> '/var/tmp/imgcreate-rScTyr/install_root', 44331008L))]
>
>
> Any pointer on how to fix this ?
My bet is that either your package set is too big for the created
file system image, or you ran out of space on whatever partition holds
/var/tmp on your system.
--
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: "Reign?"
On Fri, Aug 07, 2009 at 02:01:40PM +0300, Nicu Buculei wrote: > On 08/07/2009 01:33 PM, Richard W.M. Jones wrote: >> >> Just went to download a Fedora ISO and I'm struck once again by how >> peculiar the Fedora homepage has become: >> >> http://fedoraproject.org/ >>(or screenshot: http://www.annexia.org/tmp/fedora.png) >> >> What does the word "Reign" have to do with a Linux distro? If I knew >> nothing about Fedora, what impression would I get from this page? > > See: http://fedoraproject.org/wiki/F11_release_slogan > > IIRC the slogan was conceived on the marketing list and on the websites > list there were talks and mockups abut redesigning the front page. Correct on both counts. There are threads going on in fedora-advisory-board concerning redesign of the web pages, and I've spent a substantial amount of time over the last weeks talking to people on the Board, Design, and Websites teams about how we can improve the appearance of the website, and focus the message it sends about Fedora. I would suggest this is really off-topic for this list. If we want this list to be a hospitable place for developers to discuss code, features, and packaging, we need to get conversations to the places they can be most effective. -- 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: Lower Process Capabilities
On 31/07/09 01:09, Matthew Woehlke wrote: Bill McGonigle wrote: What's it going to take to make most people who shut off SELinux stop doing that? ...being able to install bleeding-edge devel KDE to /usr/local/my-kde-install and be able to use that as my primary desktop. I guess that would - at best - take some kind of "smart" auto-labeling on the first exec of an unlabeled process. Could probably be done by using file context equivalence and a restorecon run after the build completes: # semanage fcontext -a -e /usr /usr/local/my-kde-install # restorecon -rvF /usr/local/my-kde-install http://danwalsh.livejournal.com/27571.html Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Fri, Jul 31, 2009 at 10:50:22AM +0530, Rahul Sundaram wrote: > On 07/31/2009 10:42 AM, James Antill wrote: > > > > > *sigh*, if you want to do some benchmarking of different package > > managers available in Fedora (zypp makes the 4th, if apt is working > > again) then feel free to actually do _a bunch of work_ comparing apples > > to apples. You'll almost certainly be speaking privately with developers > > from all of the tools, to make sure you aren't screwing it up. _Then_ > > post the results somewhere. > > Why would the conversations have to be private? > > > I would be more than happy to help you, with regards to yum, if only > > because it'd be nice to have _some_ third party results somewhere that > > weren't completely insane. > > If, however, you want to just post "yum is slow" feel free to not do so > > on f-d-l. Likewise with quick "benchmarks" like this (which amounts to > > the same thing, IMO). > > You are being needlessly defensive. HWhy not just explain how solv > update and yum update is that different? It is obvious why people would > want to compare. If you think, there is a lack of proper comparison, do > it yourself and post the results or explain the guidelines and ask > people to run the tests and post the results. Either way, performance of > yum is a frequently raised point and it would be useful to get some good > comparisons. James has written about these before: http://illiterat.livejournal.com/5043.html http://illiterat.livejournal.com/5218.html -- 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: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Tue, 28 Jul 2009, Lennart Poettering wrote: I'd like to ask everyone to test this new volume logic. If you don't raise your voice now that some output port is not properly detected or audio is too faint then later on you won't have any right to complain. Is there a way to test this if one does not have the luxury of re-installing one's desktop to F12 (from F11)? ObPA: I wish client volume state was kept PA side - not enjoying the frequent resets of volume in clients in F11. Bring back system-side state for volume please.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Your mode of life will be changed to ASCII. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Mon, Jul 27, 2009 at 12:14:08PM -1000, David Cantrell wrote: > On Tue, 28 Jul 2009, Rahul Sundaram wrote: > > > On 07/28/2009 03:14 AM, David Cantrell wrote: > > > >> > >> I've been doing that for Jeroen. He's submitting patchsets for review and > >> I've built at least a few anaconda updates for him. He is currently > >> testing > >> updates for F-11 and when that's ready, he'll submit the patches for review > >> for anaconda and we can do an update. > > > > That's good news. Thanks for doing it. Are these test packages available > > publicly? > > You'll have to ask Jeroen how he handles testing. Once he has a patchset > suitable for an F-11 update, he submits it for review and then we go from > there. The idea being that once we roll the update for F-11, he'll be ready > to pick it up and make images. http://www.kanarip.com/anaconda/ ...is what you want, I think. -- 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: Updated Anaconda packages
On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: > On Tuesday, July 28 2009, Ralf Corsepius said: > > An alternative would be, to ship a script to let people build such an > > image themselves. It would not help everybody in all situations, but it > > at least help people who have some (other) version of Fedora running > > somewhere. > > As it turns out, we ship all the tools to build the distribution the > exact way we do! And as David said, he's been working with Jeroen for > occasional updated anaconda packages. Jeroen also kindly publishes those packages here: http://www.kanarip.com/anaconda/ That means that you can take revisor, pungi or livecd-tools in your existing Fedora system (or in a VM, or mock, I believe), and build an ISO that includes the updated anaconda, and all updates up until present time. These tools have been available for many releases now. -- 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: rawhide report: 20090727 changes
Hi, > kernel-2.6.31-0.94.rc4.fc12 > --- > * Fri Jul 24 2009 Chuck Ebbert > - Enable CONFIG_DEBUG_KOBJECT in debug kernels. (#513606) > > * Fri Jul 24 2009 Kristian Høgsberg > - Add drm-page-flip.patch to support vsynced page flipping on intel > chipsets. > - Really add patch. > - Fix patch to not break nouveau. Sorry, nouveau is still broken due the kernel. Works fine under 2.6.31-0.81.rc3.git4.fc12.i686.PAE, but nothing since. I've a GF7600 on this box. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: 20090724 changes
Hi, > udev-145-2.fc12 > --- > * Fri Jul 24 2009 Harald Hoyer 145-2 > - fix file permissions > - remove rpath > - chkconfig --add for udev-post > - fix summaries > - add "Required-Stop" to udev-post Does this now mean inserting a USB drive into my machine will actually mount or do I still need to do this as su? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: No Frozen Rawhide
On Wed, Jul 22, 2009 at 06:24:40PM -0400, Bill McGonigle wrote:
> On 07/22/2009 12:39 PM, Bruno Wolff III wrote:
> > I think the confusion for normal users will be minimal, because normal users
> > won't be looking at the raw repos in any case.
>
> There's a class of users between active developers/QA folk and people
> who only use GUI package managers who are apt to go to a download site
> looking for RPM's.
>
> That said, I think a succinct README ("This is pre-release code, there
> be goblins here") in the right directory that Apache auto-displays for
> index listings would be sufficient to warn off those users. Otherwise,
> _somebody_ is going to say, "oh, cool, 12 is out, I missed that."
This would be hard to enforce with mirrors, some of which may not use
those automatic features. Any user trying to install from Rawhide,
though, receives the famous betanag up front, which basically tells
them "I'm a pre-release, are you sure you want to install me?"
--
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: No Frozen Rawhide
On Wed, Jul 22, 2009 at 12:21:17PM -0500, Bruno Wolff III wrote: > On Wed, Jul 22, 2009 at 12:36:38 -0400, > Jarod Wilson wrote: > > > > $ cd .../pub/fedora/linux/releases/test/ > > $ mv 12 ../ > > You actually want overlap for a while so that when rsyncing you can use > hardlinks instead of having to redownload files you already have. > This is going to be more relevant if koji signing happens and packages don't > get different signatures depending on which repo they are in. Surely we could work that overlap into the schedule, especially since package data should be frozen pretty hard for the last couple of weeks? -- 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: Fit and Finish test day: batteries and suspend
On Tue, Jul 21, 2009 at 01:10:58PM +1000, Rodd Clarkson wrote: > I'd really like to join in with this having experienced issues with > suspend/resume with: > > * Dell Inspiron 9300 (using nvidia driver as nouveau/nv don't support > suspend/resume) > * Dell Studion XPS 16 (using either radeon or radionhd as the catalyst > driver won't compile on kernel 2.6.29) > * EeePC 1000 series with the 160GB HDD (using the default x driver) > > However, I'm a little confused how to build myself a livecd with rawhide > on is and to be honest, I don't have the time to figure it out (as it > appears it's going to take some investigation). I wrote this a while ago and finally moved it to a better name where more people could find it: https://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing -- 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: Are all your Fedora 12 Features Where They Should be?
Hi, > Could you try running "gparted" as root after plugging USB drive? > For me it triggers some kind of scan, after which proper HAL-based mount > proccess works. Still says i'm not authorised to mount the drive... TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: Are all your Fedora 12 Features Where They Should be?
Hi, > Nine days remain before Fedora 12 Feature freeze. No more features can > be added after 2009-07-28. I'm missing 2 features (still). No sound and no mounting of USB drives. I can get sound by a combination of su / chown -R paul:audio /dev/snd / exit / pulseaudio -k. USB I have to create a directory in /home/paul, su, mount /dev/sd*1 newdir and then can only do things as su to that directory, but as paul for taking from it. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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
Mono heads up
Hi, As of next week, I'll be starting the weekly builds of mono from svn and putting them into rawhide. It is my intention to push 2.4.2.2 into F11 in about a months time (it should hit rawhide tomorrow). TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: Feature proposal: Rebootless Installer
On Tue, Jul 14, 2009 at 08:09:09AM -0600, Douglas McClendon wrote: > Colin Walters wrote: >> Another thing to keep in mind that immediately post-installation there >> are going to be updates, which will at a minimum need desktop reset >> (fast reboot experience), or more likely system restart. > > I don't exactly get this. I might understand some negligible things. But > historically I've often done > > -normal install, reboot > > -booted, logged in using everying, then a massive yum update, then I'd > wait till it was absolutely convenient to logout of the desktop or reboot > > In fact, when I felt I needed to do it before my convenience, I generally > regarded it as a pretty horrible bug. I thought that preupgrade is supposed to help ease this discomfort. It deals pretty well with combining the base release of the new distro with package updates, and you reboot when you're ready. There's nothing in preupgrade to deal with repartitioning, though, it's purely for an in-place upgrade. Downloading happens in the background, and you reboot when you're ready to run the transaction. May not cover all the cases you're looking at, but worth noting. -- 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: $HOME/bin
On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote: > Stefan Assmann wrote: > > Hi all, > > > > I was wondering why there's no $HOME/bin directory and $HOME/bin not > > mentioned in the $PATH variable. Any particular reason not to have that > > by default? > > $HOME/bin is not on every system and the other default directories in > default PATH are(at least on the most of systems ;) ). However, some > Linux distros do add something as: > # set PATH so it includes user's private bin if it exists > if [ -d "$HOME/bin" ] ; then > PATH="$HOME/bin:$PATH" > fi > as default - so this dir gets added automatically when does exist. > I'm generally +1 for changing the default that way - as it would not > change anything for users without that directory. I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons. -- 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
Oh to have USB/CD write and sound...
Hi, As you're all aware on here, I've been using Rawhide for many many many moons now, I accept the risks, I accept the bleeding edge and that my fingers may get burned from time to time. However, it's been quite a while now (I think it broke shortly after the rawhide repos opened post the release of f11) since I can plug in a USB drive and have it mount without having to open a terminal window, su and mount it by hand. I can no longer use my DVD writer as I don't have the correct user permissions and the only way to get sound is to again su, change the ownership of /dev/snd to be me and restart pulseaudio. The above are really just annoyances that I can deal with. However, I now find that I can't open a terminal window (makes no difference to program used - happens with xterm, gnome-terminal and the kde one) without being told that "there was an error creating the child process for this terminal". OK, xterm just sits there, but I'm guessing it's suffering from the same problem. Any ideas when normality will be returned? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: readline update?
On 03/07/09 11:27, Miroslav Lichvar wrote: I'd like to update readline to the latest version 6.0. The problem is that the license was changed to GPLv3+ and we have some GPLv2 packages using readline. A possible replacement is the editline library which provides a compatible interface and is licensed under BSD, unfortunately it doesn't handle UTF-8. Are we stuck with readline 5.2? Suggestions? The package list is: GMT-4.4.0-2.fc11 Macaulay2-1.2-4.fc12 afpfs-ng-0.8.1-2.fc11 bti-015-1.fc11 calc-2.12.2.1-13.fc11 callweaver-1.2.0.1-3.fc11 cgdb-0.6.4-4.fc11 chrony-1.23-5.20081106gitbe42b4.fc12 clisp-2.47-3.fc11 coda-6.9.4-2.fc11 devtodo-0.1.20-3.fc12 fityk-0.8.1-14.fc10 gnu-smalltalk-3.1-5.fc12 gnubg-0.9.0.1-7.fc11 gnuplot-4.2.5-4.fc12 grass-6.3.0-12.fc11 kdeedu-4.2.95-1.fc12 ktechlab-0.3.70-1.20090304svn.fc11 lvm2-2.02.48-1.fc12 maxima-5.18.1-3.fc12 ocfs2-tools-1.3.9-10.20080221git.fc11 socat-1.7.0.0-2.fc11 You've missed perl-Term-ReadLine-Gnu (and I wonder how many other packages?) but that one's OK as it's GPL+. Paul. -- 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: 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: 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: Getting MD5 sum mismatch errors unpacking rawhide on FC9
On Wed, 01 Jul 2009 14:01:20 -0700 "Philip A. Prindeville" wrote: > Dennis Gilmore wrote: > > On Wednesday 01 July 2009 03:43:31 pm Philip A. Prindeville wrote: > > > >> I have an FC9 (updated) x86_64 install, and I just tried to pull > >> down proftpd.src from rawhide-source. > >> > >> I'm seeing the following: > >> > >> [phil...@builder SPECS]$ rpm -vv > >> -i /tmp/proftpd-1.3.2-2.fc11.src.rpm D: > >> == /tmp/proftpd-1.3.2-2.fc11.src.rpm D: Expected > >> size: 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: > >> Actual size: 2471936 D: opening db > >> index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db > >> index /var/lib/rpm/Packages D: opening db > >> index /var/lib/rpm/Pubkeys rdonly mode=0x0 > >> warning: /tmp/proftpd-1.3.2-2.fc11.src.rpm: Header V3 RSA/SHA256 > >> signature: NOKEY, key ID d22e77f2 D: added source package > >> [0] D: found 1 source and 0 binary packages D: Expected size: > >> 2471936 = lead(96)+sigs(1284)+pad(4)+data(2470552) D: Actual > >> size: 2471936 D: InstallSourcePackage: Header V3 RSA/SHA256 > >> signature: NOKEY, key ID d22e77f2 proftpd-1.3.2-2.fc11 > >> D: == Directories not explicitly included in package: > >> D: 0 /home/philipp/rpmbuild/SOURCES/ > >> D: 1 /home/philipp/rpmbuild/SPECS/ > >> D: == > >> warning: user mockbuild does not exist - using root > >> warning: group mockbuild does not exist - using root > >> D: undo 100664 1 ( 0, 0) 2457498 > >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949 > >> GZDIO: 301 reads, 2465792 total bytes in 0.008182 secs > >> error: unpacking of archive failed on file > >> /home/philipp/rpmbuild/SOURCES/proftpd-1.3.2.tar.bz2;4a4bc949: > >> cpio: MD5 sum mismatch D: closed db > >> index /var/lib/rpm/Pubkeys D: closed db > >> index /var/lib/rpm/Packages D: May free Score board((nil)) > >> [phil...@builder SPECS]$ > >> > >> > >> What am I missing here? > >> > > rpm in F-11 and newer uses a sha256sum and mot md5sum the rpm is > > incompatible. you would need to get the rpm from F-10 updates to > > install it > > > > > > Dennis > > > > Grrr... that would cause all sorts of other things to be brought in. > > I just need to rebuild certain Rawhide or FC11 packages for FC9. Is > there an easy way to do this using mock? Easiest way is probably to check out the desired packages from CVS, do "make srpm" and then rebuild that. proftpd will be updated to 1.3.2a in a day or two by the way. Paul. > > -Philip > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
