Reminder: Fedora Board IRC meeting 1600 UTC 2009-10-01
The Board is holding its monthly public meeting on Thursday, October 1, 2009, at 1600 UTC on IRC Freenode. For this meeting, the public is invited to do the following: * Join #fedora-board-meeting to see the Board's conversation. * Join #fedora-board-questions to discuss topics and post questions. This channel is read/write for everyone. The moderator will voice people from the queue, one at a time, in the #fedora-board-meeting channel. We'll limit time per voice as needed to give everyone in the queue a chance to be heard. The Board may reserve some time at the top of the hour to cover any agenda items as appropriate. We look forward to seeing you at the meeting! (See also previous announcement here: https://www.redhat.com/archives/fedora-advisory-board/2009-September/msg00050.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 pgp6HFxm6jGGJ.pgp Description: PGP signature -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
latest python-cheetah breaks koji.
Hi, I would just submit a bug but unsure to which package to submit in the first instance. On FC11 with Hi With, koji-hub-1.3.1-2.fc11.noarch koji-1.3.1-2.fc11.noarch koji-builder-1.3.1-2.fc11.noarch koji-web-1.3.1-2.fc11.noarch koji-utils-1.3.1-2.fc11.noarch python-cheetah-2.0.1-5.fc11.x86_64 then everything is good. Updating only python-cheetah to python-cheetah-2.2.2-1.fc11.x86_64 then python-web dumps to the browser as below, full traceback attached. Downgrading back to python-cheetah-2.0.1-5.fc11.x86_64 then all is good. File /usr/lib64/python2.6/site-packages/Cheetah/Compiler.py, line 1588, in __init__ source = unicode(source) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 374: ordinal not in range(128) full back trace attached. Steve -- Steve Traylen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: latest python-cheetah breaks koji.
On 09/30/2009 04:05 AM, Steve Traylen wrote: Hi, I would just submit a bug but unsure to which package to submit in the first instance. On FC11 with Hi With, koji-hub-1.3.1-2.fc11.noarch koji-1.3.1-2.fc11.noarch koji-builder-1.3.1-2.fc11.noarch koji-web-1.3.1-2.fc11.noarch koji-utils-1.3.1-2.fc11.noarch python-cheetah-2.0.1-5.fc11.x86_64 then everything is good. Updating only python-cheetah to python-cheetah-2.2.2-1.fc11.x86_64 then python-web dumps to the browser as below, full traceback attached. Downgrading back to python-cheetah-2.0.1-5.fc11.x86_64 then all is good. File /usr/lib64/python2.6/site-packages/Cheetah/Compiler.py, line 1588, in __init__ source = unicode(source) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 374: ordinal not in range(128) full back trace attached. Sorry about that, my fault. I hadn't finished testing Koji with the new Cheetah before I pushed it. This patch should fix the errors: http://mikeb.fedorapeople.org/0001-handle-all-strings-as-unicode-for-compatibility-with.patch It'll be pushed to the Koji git repo shortly. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bitmap-fonts by default?
XEmacs needs it. We have an explicit reference to a LucidaTypewriter font. Sure: and xorg-x11-fonts also provides LT. I am not asking if we should drop bitmap-fonts (though it needs to be split up and repackaged)... the question was why are we installing it by default and when can we stop? :) Jens -- 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, 2009-09-29 at 18:21 -0700, Toshio Kuratomi wrote: One thing I think is unclear this cycle is the usage of the word Beta. It's been said many times that beta is not really beta but actually final freeze. For instance: If all goes as planned the Beta (previously known as Final Development) Freeze in the message steved linked to. And yet, no one actually expects that beta is the final development freeze. Maybe we should just give up and not use the beta moniker for it. As inaccurate as it is, release candidate is a *better inaccuracy* in terms of communicating to developers. Developers understand that by release candidate we're going to be very tough about getting changes in, even if they appear to improve the experience. Some things will just have to be deferred after a release candidate is out the door. The downside of release candidate, as Jesse has pointed out before, is that it communicates the wrong thing to end-users. There's zero chance that this cut is going to be the absolute final set of bits that we use on release day so from an end-user perspective, it's not a release candidate. One possibility is to have a beta1 at feature freeze and a beta2 now. This helps developers realize that nothing but bugfixes should be going in from feature freeze on but lets end user's know that the release we're making now is still not finished. It still doesn't give the sense of urgency and finality that release candidate does, though, so I'm not sure if that's enough. We've tried to address unclear terminology this summer with the milestone adjustment proposal. https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal This tries to apply industry standard naming to our release process, and as such we had to rename some things. Another thing that seems to be apparent in steved's complaint is that what the expectations for Final Feature Freeze (in July) are not clear enough. What is meant by testable? It seems that we mean, the Feature should be in, enabled, and in final form at that point. Right, I've always taken it to mean Our experimental code is in, and we're ready to take end user testing feedback on it which is different from our code is in, but not really done, and we don't care if it's broken because we're going to re-write it again in a week. We want to be able to do integration testing from that point forward. That means we're no longer testing the Feature in isolation, but as part of the whole experience of installing and running the distro. Bugfixes can be applied but nothing that changes the basic shape or architecture of the distro as a whole. Plainly, changing the default from nfsv3 to nfsv4 should happen at Feature Freeze rather than now for that testing to be performed. But there's other meanings of testable. I'm sure that steved considered the Feature testable at Feature Freeze... he just wasn't applying the idea that it needed to be testable as part of the whole distro experience. Perhaps we need to list some examples of things that should not happen after Feature Freeze as well as expectation of what should happen. 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 These seem like reasonable good starts and should find themselves in the wiki at some point. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Buyer Beware: A Major Change in NFS is about to happen
Jesse Keating, Tue, 29 Sep 2009 23:45:08 -0700: Right, I've always taken it to mean Our experimental code is in, and we're ready to take end user testing feedback on it which is different from our code is in, but not really done, and we don't care if it's broken because we're going to re-write it again in a week. Except this is not exactly correct ... this is not beta by industry standards, but release candidate which will be left rottening for two months before released and found completely useless (because 0day updates will be probably again bigger than amount of packages people usually install). Case in question ... I am not allowed to fix bug https:// bugzilla.redhat.com/show_bug.cgi?id=520998, which I have filed some time ago, watched that maintainer didn't do anything to it, finally after discussing it with OpenSSL maintainer I have decided that upgrading to the current stable version of the package makes a lot of sense, fixed the spec so that it builds, build it ... and found that I cannot push it to the bodhi, because I would need to humbly petition FESCO for permission to fix a bug. And no I cannot swear that it won't break anything (it is not my package after all), so I will just not bother, and let is slip for anybody who cares to take care of it. Do we have somewhere real Rawhide (i.e., dist-f13) repos available now when dist-f12 has been released? I don't want to upgrade from koji. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming Fedora 12 Development/Release Engineering Tasks
John Poelstra poels...@redhat.com writes: I realize the formatting of these emails is not pretty if your email reader uses a proportional font. Even with a fixed width font. Let me know if there are any ideas for fixing this. Don't use format=flowed. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- 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
And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... Because we do seem to fight this problem every release. Was anyone else confused about when the deadline was? It seems very clear to me, on several occasions, when features needed to be in by. What more could we have done to make this more clear? I understand what that one email says, but there's several others that clarify. I must say with the Moblin feature process I found the whole dead line for alpha/beta etc very confusing as a first timer doing a feature release (even though I've been in involved in Fedora from the beginning). Peter -- 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
Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
This problem is not restricted to zsync: deltarpm has the same problem as it supports the rsync protocol, too. (https://bugzilla.redhat.com/show_bug.cgi?id=526432 - yes, I just opened it) I did not do the research but it might be worth checking other programs that deal with the rsync protocol. There might be some more cases that suffer from the same problem. Anyway, splitting off the modified zlib in a way that other rsync related package can build against it would be the minimal step to get back on even remotely sane ground. Florian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Wed, Sep 30, 2009 at 11:05:58AM +0200, Florian Festi wrote:
deltarpm has the same problem as it supports the rsync protocol, too.
I think deltarpm's zlib patch to support 'gzip --rsyncable' is
different to the rsync patch. I've sent the patch upstream in 2005,
but got no response.
(The original --rsyncable patch was done by Rusty Russell in 2002, btw)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
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 05:33:15PM -0400, Steve Dickson wrote: * Firewall Friendly- With v4 only one port is used 2049 for all traffic including mounting and file locking. Amen to that! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- 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 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... steved. -- 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
Steve Dickson wrote: On 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Consider the alternative, which is breaking NFS access for enormous numbers (hundreds of thousands?) of people. And, in the process, severely damaging the reputation of Fedora. Andrew. -- 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 09/30/2009 06:18 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Times 1000 very 5 seconds... I really don't think the server people would appreciate all those extra cycles and network traffic... Doing something like this would be hack... a hack that I could not push upstream... There are other workagrounds (defined in original mail) that I would rather explore... Consider the alternative, which is breaking NFS access for enormous numbers (hundreds of thousands?) of people. And, in the process, severely damaging the reputation of Fedora. I am not breaking NFS access, I'm changing NFS access for the better, IMHO. Unfortunately its just a bit painful I don't see how pushing, incorporating and utilizing the latest technology available can severely damaging the reputation of Fedora. To be quite frank, my goal is just the opposite... I want Fedora have a reputation of being on the breaking edge of technology... I think that is a good thing! steved. -- 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
Steve Dickson wrote: On 09/30/2009 06:18 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/30/2009 04:53 AM, Andrew Haley wrote: Steve Dickson wrote: On 09/29/2009 10:10 PM, Jeremy Katz wrote: On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. I looked into this... Having the kernel give a different kind of error when the V4 beginning mount routine failed did not look feasible so figure it would be impossible to get through upstream I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Times 1000 very 5 seconds... So 2000 every 5 seconds as opposed to 1000 every 5 seconds. This is surely better than returning an incorrect directory does not exist response to almost every NFS user who upgrades. And it will be almost everyone: maintaining servers on older versions of RHEL and upgrading clients to recent Fedora is normal. I really don't think the server people would appreciate all those extra cycles and network traffic... Doing something like this would be hack... a hack that I could not push upstream... There are other workagrounds (defined in original mail) that I would rather explore... But they are all pretty unpleasant. The user gets an obscure error message that indicates nothing to them except NFS is broken. They then have to either export root from the server or edit their fstab. Consider the alternative, which is breaking NFS access for enormous numbers (hundreds of thousands?) of people. And, in the process, severely damaging the reputation of Fedora. I am not breaking NFS access, I'm changing NFS access for the better, IMHO. Unfortunately its just a bit painful Yep. I don't see how pushing, incorporating and utilizing the latest technology available can severely damaging the reputation of Fedora. Really? Why not? What you are proposing to is indistinguishable to a user from breaking NFS. I can easily see it. To be quite frank, my goal is just the opposite... I want Fedora have a reputation of being on the breaking edge of technology... I think that is a good thing! Me too. So, let's see how we can do that without making Fedora more fragile. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
On 09/30/2009 05:28 AM, drago01 wrote: On Wed, Sep 30, 2009 at 4:15 AM, Mail Listsli...@sapience.com wrote: On 09/29/2009 11:20 AM, Christopher Aillon wrote: Tweaking the following pref: mailnews.database.global.indexer.enabled = false Should work around the problem for now. Is that any different than turning it off in Preferences-General-Enable Global Search and Indexer ? no In my experience the indexer isn't what causes the 100% CPU lockups. Synchronization of each folder seems to be the cause. If I turn off synchronization in Properties of all folders the 100% CPU lockups seem to go away entirely for me. Right-click on each folder, Properties, Synchronization, uncheck Select this folder for offline use. The indexer is annoying and I turned it off because after crunching away for hours it had indexed only 5% of my mail. Warren Togami wtog...@redhat.com -- 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
Steve, just for clarity what you are actually saying is that. On Tue, 2009-09-29 at 22:45 -0400, Steve Dickson wrote: On 09/29/2009 09:42 PM, Chris Adams wrote: Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? Unfortunately the answer to your question yes... With version 4 there is this concept of a pseudo root. Which meanings one can define, through exports, what the root of an export can be. Which is a good idea because you can define /export as the root, and nothing above /export can be accessed... But if there is a /data *(ro,fsid=0) export then that will do, but it becomes the root of the export tree against which mounts are made? So the idea was to use 'fsid=0' to define the V4 root of the exports. Which, in theory is a good idea because you can define the namespace the client have access to. A feature, I believe, is not available in any other NFS implementation... But... The problem is the V4 protocol requires a pseudo root to exist. So with Linux servers, if the fsid=0 export does not exist, the mount will die with ENOENT (or 'No such file or directory'). Other NFS implementation decided not to support a definable pseudo roots and they just made, under the covers, their '/' as the pseudo root, along with the appropriate protections. So putting the / *(ro,fsid=0) is only adding an export of that part of the name space into the tree to make it compatible with pre-V4 name spaces. With F-12, I have added code to both the kernel and nfs-utils that will do both. Allow the 'fsid=0' export to define the pseudo root and make '/' the pseudo root (with the appropriate protections) when there is not an fsid=0 entry. So Yes, one work around to make F-12 mounts work with Linux servers is to define a pseudo root on the server with a fsid=0 export. But if that is not an option, you can make the F12 clients only use V3 mount (which would avoid the problem, but not take advantage of the V4 protocol) by set either setting the '-o v3' mount option or set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make all mounts from that machine v3 mounts). But the downside of the / *(ro,fsid=0) approach is we now have all of the root files (but not any other filing systems visible. So perhaps a better approach would be to specify a /V4root *(ro,fsid=0) directory being created and a bind mount for each export from the pre-V3 name space being made into that tree. Or have I missed something entirely? I hope this helped... It did! steved. -- Howard Wilkinson how...@cohtech.com Coherent Technology Limited -- 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 Wed, Sep 30, 2009 at 08:36:54AM +, Matej Cepl wrote:
Jesse Keating, Tue, 29 Sep 2009 23:45:08 -0700:
Right, I've always taken it to mean Our experimental code is in, and
we're ready to take end user testing feedback on it which is different
from our code is in, but not really done, and we don't care if it's
broken because we're going to re-write it again in a week.
Except this is not exactly correct ... this is not beta by industry
standards, but release candidate which will be left rottening for two
months before released and found completely useless (because 0day updates
will be probably again bigger than amount of packages people usually
install).
Case in question ... I am not allowed to fix bug https://
bugzilla.redhat.com/show_bug.cgi?id=520998, which I have filed some time
ago, watched that maintainer didn't do anything to it, finally after
discussing it with OpenSSL maintainer I have decided that upgrading to
the current stable version of the package makes a lot of sense, fixed the
spec so that it builds, build it ... and found that I cannot push it to
the bodhi, because I would need to humbly petition FESCO for permission
to fix a bug. And no I cannot swear that it won't break anything (it is
not my package after all), so I will just not bother, and let is slip for
anybody who cares to take care of it.
Er... your package is already in rawhide. You don't need to push it as a
bodhi update. So your use case is totally bogus because the change you
wanted to get into F-12 is already there:
[jwbo...@hansolo packages]$ koji latest-pkg dist-f12 pyOpenSSL
Build Tag Built by
pyOpenSSL-0.9-1.fc12 dist-f12 mcepl
[jwbo...@hansolo packages]$ koji latest-pkg f12-beta pyOpenSSL
Build Tag Built by
pyOpenSSL-0.9-1.fc12 f12-beta mcepl
Do we have somewhere real Rawhide (i.e., dist-f13) repos available now
when dist-f12 has been released? I don't want to upgrade from koji.
I have no idea what you are asking here.
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (40/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 40/2009 Time: 2009-09-29 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-29 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * StevenParrish * ThanNgo * ThomasJanssen * Mary Ellen Foster -- = Agenda = o Topics to discuss: * kde-sig steering committee * k3b/koffice reverts, recommended by upstreams * future of Phonon * upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately * mandriva developments integrating pulseaudio support (and improving gstreamer backend) [1] = Summary = o kde-sig steering committee * The KDE SIG Steering Committee will be formed by (in alphabetical order): jreznik, Kevin_Kofler, ltinkl, rdieter, SMParrish, svahl, than. * 4 votes will be required to pass decisions where a vote is called for. * rdieter will summarize the exact rules. o k3b/koffice reverts, recommended by upstreams [2] * F12 will revert to (kde3) k3b-1.0.x and koffice-1.6.x for F-12 (passed 4:2). o future of Phonon * Upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately. * Mandriva developments integrating pulseaudio support (and improving gstreamer backend). [1] * We will move back to building a standalone phonon SRPM. * The vote for the default backend is split 3:3, needs the 7th vote from svahl. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-06 = Links = [1] http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html [2] http://rdieter.livejournal.com/15770.html Jaroslav -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- 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 09/30/2009 07:22 AM, Howard Wilkinson wrote: Steve, just for clarity what you are actually saying is that. On Tue, 2009-09-29 at 22:45 -0400, Steve Dickson wrote: On 09/29/2009 09:42 PM, Chris Adams wrote: Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? Unfortunately the answer to your question yes... With version 4 there is this concept of a pseudo root. Which meanings one can define, through exports, what the root of an export can be. Which is a good idea because you can define /export as the root, and nothing above /export can be accessed... But if there is a /data *(ro,fsid=0) export then that will do, but it becomes the root of the export tree against which mounts are made? Yes.. For example say the directory tree under /data looks like /data dir1/ subdir1/ dir2/ subdir2/ Then the client could do a mount server:/ /mnt/ which would make every thing under /data visible, meaning ls /mnt/dir1 ls /mnt/dir2 Now the client could also do a mount server:/dir1 /mnt which would only make the the directories under /data/dir1 visible, meaning ls /mnt/subdir1 So the idea was to use 'fsid=0' to define the V4 root of the exports. Which, in theory is a good idea because you can define the namespace the client have access to. A feature, I believe, is not available in any other NFS implementation... But... The problem is the V4 protocol requires a pseudo root to exist. So with Linux servers, if the fsid=0 export does not exist, the mount will die with ENOENT (or 'No such file or directory'). Other NFS implementation decided not to support a definable pseudo roots and they just made, under the covers, their '/' as the pseudo root, along with the appropriate protections. So putting the / *(ro,fsid=0) is only adding an export of that part of the name space into the tree to make it compatible with pre-V4 name spaces. Exactly... With F-12, I have added code to both the kernel and nfs-utils that will do both. Allow the 'fsid=0' export to define the pseudo root and make '/' the pseudo root (with the appropriate protections) when there is not an fsid=0 entry. So Yes, one work around to make F-12 mounts work with Linux servers is to define a pseudo root on the server with a fsid=0 export. But if that is not an option, you can make the F12 clients only use V3 mount (which would avoid the problem, but not take advantage of the V4 protocol) by set either setting the '-o v3' mount option or set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make all mounts from that machine v3 mounts). But the downside of the / *(ro,fsid=0) approach is we now have all of the root files (but not any other filing systems visible). No, other mounts files systems would be visible as well.. So perhaps a better approach would be to specify a /V4root *(ro,fsid=0) directory being created and a bind mount for each export from the pre-V3 name space being made into that tree. Or have I missed something entirely? That sounds like it could work, although it may not be too scalable with large and complicated export tree... The real answer is use a F-12 NFS server since all this stuff goes away.. steved. -- 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 09/30/2009 07:05 AM, Andrew Haley wrote: I can't see how it would cause a mount storm: all you'd be doing is issuing a mount request twice, once in each protocol. Times 1000 very 5 seconds... So 2000 every 5 seconds as opposed to 1000 every 5 seconds. This is surely better than returning an incorrect directory does not exist response to almost every NFS user who upgrades. And it will be almost everyone: maintaining servers on older versions of RHEL and upgrading clients to recent Fedora is normal. Or the F-12 clients can change the default back to v3 by either setting the Nfsvers=3 variable the NFSMount_Global_Options section in the /etc/nfsmount.conf file, or set the '-o v3' mount option on the command line. I really don't think the server people would appreciate all those extra cycles and network traffic... Doing something like this would be hack... a hack that I could not push upstream... There are other workagrounds (defined in original mail) that I would rather explore... But they are all pretty unpleasant. The user gets an obscure error message that indicates nothing to them except NFS is broken. They then have to either export root from the server or edit their fstab. I'm not sure I agree with the obscure error message, but yes the client will have to change when mount to a older Linux server, only a Linux server btw... I don't see how pushing, incorporating and utilizing the latest technology available can severely damaging the reputation of Fedora. Really? Why not? What you are proposing to is indistinguishable to a user from breaking NFS. I can easily see it. With all new release of Fedora (or any OS for that matter) there are always some pain threshold people have to go through. I just see this is one those thresholds.. To be quite frank, my goal is just the opposite... I want Fedora have a reputation of being on the breaking edge of technology... I think that is a good thing! Me too. So, let's see how we can do that without making Fedora more fragile. I can't agree with this more... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
yum update vs. blender
Hi, today's yum update came along with this: # yum update ... Updating : blender-2.49b 1.fc11.x86_64 16/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' ... Cleanup: blender-2.49a-1.fc11.x86_64 48/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' What is this? Seems to me, as is something is very broken with blender's scriptlets? Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Lennart Poettering wrote: Haha. So the major 'advantage' of Phonon that it would allow replacing the backends as time progresses without breaking the KDE apps using them now officially is proven to be bogus. The KDE/Qt folks were so afraid of a media engine breaking API so that they created their abstraction thing and now break API of that one more often then the media engines themselves do. KDE is going to support Phonon for at least the whole KDE 4 cycle (which is planned to be quite long as neither Qt nor KDE sees an immediate need for an API-breaking version) as part of the API compatibility promise, and there is also strong active development ongoing on the KDE side, so it won't be deprecated on the KDE side and chances are it will still be there in future major versions of KDE (e.g. KDE 5) as well (though at that point, API changes can happen). (But of course this development currently focuses on the xine-lib backend, which is the backend KDE recommends. Though there are developers from e.g. Mandriva interested in improving the GStreamer one, too.) What is likely to happen is that Phonon is going to be deprecated on the Qt side, and Qt's bundled copy of Phonon might end up not getting updated, too. But that's one of the reasons we decided to ship Phonon from its own SRPM again in yesterday's meeting. Phonon possibly becoming deprecated in Qt is completely irrelevant for KDE application developers as it is still the preferred solution for multimedia in KDE and will remain so for the foreseeable future. There's a general rule in KDE: if there's a KDE class and a Qt class doing the same thing, always use the KDE class unless it explicitly says it's deprecated in favor of the Qt one. If Qt comes up with their own multimedia framework, multimedia will just be one more instance of this rule. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Jaroslav Reznik wrote: Another interesting thing is PA Phonon integration work by Colin Guthrie (see the link in my first message). Phonon just as wrapper/thin client for PA with nicer Qt like API. I like this idea. That's not what his current work does, and it's not really possible as PA doesn't do decoding, so you'd still need some decoding library. Colin Guthrie's branch still uses GStreamer or xine-lib (he's currently working with both backends because he knows both are used). What it adds is that PA sinks show up as Phonon devices so you can choose where to direct your output to, as opposed to the one big PulseAudio device we currently have (where it just uses the sink set as default in PA). I suppose he's also going to tag the streams with the PA stream type matching the Phonon stream type the application sets, if he doesn't already. So this lets you use Phonon's flexibility (directing specific types of streams to specific outputs) while still using PulseAudio, you don't have to choose one or the other anymore. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
Just to make things even more confusing, I have no problems with thunderbird-3.0-3.8.b3.fc12.x86_64.rpm I have a setup with - Multiple IMAP accounts - Some _huge_ folders ( 300 000 messages) - More than 11 GB of mail in one account, 9 GB in another The recent upgrade to thunderbird-3.0-3.9.b4.fc12.x86_64 made the computer almost unusable, (same as thunderbird-3.0-1.beta2.fc11.x86_64 did back in march/april). So something was fixed in b3, that is broken in b4 again - at least for me. Rgds. Ola Thoresen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Tuesday 29 Sep 2009 16:03:54 Jaroslav Reznik wrote: We, KDE SIG, are considering which backend should be default for Phonon in Fedora. Seems like it's not easy to agree on final decision @ KDE SIG meetings, we'd like to summarize what's the problem, some backends facts (please correct me, comment, add, etc.) and we'd like to hear comments from outer KDE SIG universe, from you, Fedora developers users, too. Just one comment: gapless playback. ;) I've noticed from my testing of amorok - phonon-backend-gstreamer - pulseaudio that gapless playback doesn't work seamlessly. Especially noticeable with a live album where there is a stutter, click or pop between tracks when using the gstreamer backend, and that doesn't happen with the xine backend. Not quite sure where to point the finger, amarok or phonon-backend- gstreamer, just thought I'd mention it. Regards Clive -- Clive Messer cl...@vacuumtube.org.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
2009/9/30 Lennart Poettering mzerq...@0pointer.de: On Tue, 29.09.09 22:46, Kevin Kofler (kevin.kof...@chello.at) wrote: Lennart Poettering wrote: Uh. Nokia stands pretty firmly behind gst. As do most embedded folks. Behind GStreamer, sure. Behind Phonon (and thus also Phonon-GStreamer), not so much. They're currently using it, but there are people working on the Qt Mobility project talking about replacing Phonon with something else (another abstraction layer, again around native backends (GStreamer in the GNU/Linux case), I really don't see what the advantage would be over Phonon). Haha. So the major 'advantage' of Phonon that it would allow replacing the backends as time progresses without breaking the KDE apps using them now officially is proven to be bogus. The KDE/Qt folks were so afraid of a media engine breaking API so that they created their abstraction thing and now break API of that one more often then the media engines themselves do. Do I hear an I told you so!? Abstractionitis is an illness, not a remedy. People who live in a glass houses shouldn't throw stones. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090930 changes
Compose started at Wed Sep 30 06:15:12 UTC 2009 Broken deps for i386 -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.i586 requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 labrea-2.5.1-2.fc10.i386 requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfagent.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidcommon.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfagent.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidclient.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfcommon.so.2 network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 ngrep-1.45-5.fc11.i586 requires libpcap.so.0.9 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin = 0:0.5.3-30 yersinia-0.7.1-3.fc11.i586 requires libpcap.so.0.9 Broken deps for x86_64 -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.x86_64 requires libpcap.so.0.9()(64bit) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) labrea-2.5.1-2.fc10.x86_64 requires libpcap.so.0.9()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfagent.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidclient.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfagent.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidclient.so.2()(64bit) network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) ngrep-1.45-5.fc11.x86_64 requires libpcap.so.0.9()(64bit) rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin = 0:0.5.3-30 yersinia-0.7.1-3.fc11.x86_64 requires libpcap.so.0.9()(64bit) Broken deps for ppc -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.ppc requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 15:33:43 Kevin Kofler wrote: Jaroslav Reznik wrote: Another interesting thing is PA Phonon integration work by Colin Guthrie (see the link in my first message). Phonon just as wrapper/thin client for PA with nicer Qt like API. I like this idea. That's not what his current work does, and it's not really possible as PA doesn't do decoding, so you'd still need some decoding library. Of course, I know! Colin Guthrie's branch still uses GStreamer or xine-lib (he's currently working with both backends because he knows both are used). What it adds is that PA sinks show up as Phonon devices so you can choose where to direct your output to, as opposed to the one big PulseAudio device we currently Yes, he does. have (where it just uses the sink set as default in PA). I suppose he's also going to tag the streams with the PA stream type matching the Phonon stream type the application sets, if he doesn't already. So this lets you use Phonon's flexibility (directing specific types of streams to specific outputs) while still using PulseAudio, you don't have to choose one or the other anymore. And that's what I have been talking - it does not duplicate PA, but just wraps PA. Jaroslav Kevin Kofler -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
orphaning argus
Not using argus anymore, and no cycles to do right by it. Please feel free to pick it up if there's interest. Thx, --G -- 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 9:42 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? Yea— It would be ill-advised to actually recommend this to people. Someone might actually listen and be rather unhappy that your suggestion undermined their security assumptions. (Okay, you can say someone who doesn't understand what that line does shouldn't be adding it to their exports; but people will) If this change in default behavior doesn't go in to F12 does the correct handling of the pseudo-root go in? For all the arguments against accepting the behavior change at a late date, accepting the server fixes seems far less scary and getting them in ASAP will make the behavior change less disruptive in the future. -- 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
Mike McGrath wrote: Because we do seem to fight this problem every release. Was anyone else confused about when the deadline was? It seems very clear to me, on several occasions, when features needed to be in by. This release cycle had an additional source of confusion because what used to be called Beta in previous cycles was renamed to Alpha and what used to be called Preview got renamed to Beta. I think this was a big mistake because it led many developers to believe they have a whole milestone more time than they actually do. People are used to Alpha being a mostly insignificant snapshot and Beta being the feature freeze, as it was in the past. I blame most of the feature lateness on those renames. Kevin Kofler -- 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
Steve Dickson wrote: I my past, added things of this size in a beta release was actually common.. In alpha release you get the software married to the hardware (i.e. barely booting) and in beta release you added everything else... Yes, but that Alpha doesn't exist anymore and what was called F12 Alpha was the Beta you refer to. Now the post beta release is when the door close... nothing but bug fixes.. Right, the F12 Beta is actually what used to be the Preview Release. So you're just another victim of the release newspeak. IMHO we really need to revert to the previous (F11) terminology for F13, and also reintroduce the old Alpha (because, as useless as it was in practice, it served as a way to get developers into release mode; the psychological impact of doing such a release should not be underestimated). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Freeze at 0600~ 2009-09-30 UTC
Jesse Keating wrote, at 09/30/2009 01:57 AM +9:00: Just a reminder that the Fedora 12 freeze will be happening tonight at 0600 2009-09-30 UTC, just prior to the rawhide compose tonight. The rawhide for 20090930 will be built from frozen content. You do not need to send tag requests until after that. By the way although this time already came dist-f12 tree seems still unfrozen [1] and some builds after this freeze time are already included into dist-f12-build tree [2]. Does this mean that these packages (rebuilt after F12 beta freeze) are finally included in F12 final tree? [1] http://koji.fedoraproject.org/koji/taginfo?tagID=85 [2] http://koji.fedoraproject.org/koji/builds?tagID=86order=-completion_timelatest=1 Mamoru -- 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
Matej Cepl wrote: Case in question ... I am not allowed to fix bug https:// bugzilla.redhat.com/show_bug.cgi?id=520998, which I have filed some time ago, watched that maintainer didn't do anything to it, finally after discussing it with OpenSSL maintainer I have decided that upgrading to the current stable version of the package makes a lot of sense, fixed the spec so that it builds, build it ... and found that I cannot push it to the bodhi, because I would need to humbly petition FESCO for permission to fix a bug. In this case, as Josh Boyer pointed out, it already made F12 and even F12 Beta, as you built it before the Final Devel Freeze. But if you do build something during the freeze and want it to make F12, FESCo is not the responsible body, rel-eng is. Just file a tag request at: https://fedorahosted.org/rel-eng/newticket and explain: * what changes you did, * what the benefit of those changes is (e.g. fixes an important bug (and please give URLs)), * what testing you did on the new version to ensure it works, * why you don't expect it to break things (e.g. it's an upstream bugfix release, fully backwards-compatible, no major changes). (You can look at some of the existing tag requests for freeze overrides to get an idea of how things should look like, and also of what kind of questions rel-eng asks if you don't fill in some of the above. ;-) ) Then you just need 2 rel-eng members to approve the tag request, which usually happens very quickly if you did your homework (see above). Kevin Kofler -- 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
Toshio Kuratomi wrote: One thing I think is unclear this cycle is the usage of the word Beta. It's been said many times that beta is not really beta but actually final freeze. For instance: If all goes as planned the Beta (previously known as Final Development) Freeze in the message steved linked to. And yet, no one actually expects that beta is the final development freeze. Maybe we should just give up and not use the beta moniker for it. As inaccurate as it is, release candidate is a *better inaccuracy* in terms of communicating to developers. Developers understand that by release candidate we're going to be very tough about getting changes in, even if they appear to improve the experience. Some things will just have to be deferred after a release candidate is out the door. The downside of release candidate, as Jesse has pointed out before, is that it communicates the wrong thing to end-users. There's zero chance that this cut is going to be the absolute final set of bits that we use on release day so from an end-user perspective, it's not a release candidate. Why not just call it Preview again? Everyone here understands what that means. Kevin Kofler -- 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
Jesse Keating wrote: We've tried to address unclear terminology this summer with the milestone adjustment proposal. https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal This tries to apply industry standard naming to our release process, and as such we had to rename some things. The problem is that this did quite the opposite. The previous terminology was clear to everyone here. The new one is not only unclear, it's actively dangerously confusing as it reuses names previously used for earlier snapshots for later ones, which caused several developers to deliver late. These terminology changes should be reverted for F13! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bitmap-fonts by default?
Le Mer 30 septembre 2009 16:35, Qianqian Fang a écrit : Jens Petersen wrote: We have been looking at updating bitmap-fonts recently, and noticed that it is still listed mandatory in the comps @base-x group. So I just wondered a couple of naive questions: - does bitmap-fonts have to be installed by default? - what actually needs it? anything before X may still need bitmap fonts, don't they? The problem is, we have a lot of stuff installed by default in base-x because something may use it (even though no one actually checked that was still the case). IMHO default packages in default groups should have a clear user, or be downgraded to optional. -- Nicolas Mailhot -- 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
Steve, On Wed, 2009-09-30 at 08:36 -0400, Steve Dickson wrote: On 09/30/2009 07:22 AM, Howard Wilkinson wrote: Steve, just for clarity what you are actually saying is that. On Tue, 2009-09-29 at 22:45 -0400, Steve Dickson wrote: On 09/29/2009 09:42 PM, Chris Adams wrote: Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? Unfortunately the answer to your question yes... With version 4 there is this concept of a pseudo root. Which meanings one can define, through exports, what the root of an export can be. Which is a good idea because you can define /export as the root, and nothing above /export can be accessed... But if there is a /data *(ro,fsid=0) export then that will do, but it becomes the root of the export tree against which mounts are made? Yes.. For example say the directory tree under /data looks like /data dir1/ subdir1/ dir2/ subdir2/ Then the client could do a mount server:/ /mnt/ which would make every thing under /data visible, meaning ls /mnt/dir1 ls /mnt/dir2 Now the client could also do a mount server:/dir1 /mnt which would only make the the directories under /data/dir1 visible, meaning ls /mnt/subdir1 This is the scheme we use here already and we are running V4 on everything except the kickstart network based builds as that only seems to understand V3. This is F11 with a few additions from F12 backported. So the idea was to use 'fsid=0' to define the V4 root of the exports. Which, in theory is a good idea because you can define the namespace the client have access to. A feature, I believe, is not available in any other NFS implementation... But... The problem is the V4 protocol requires a pseudo root to exist. So with Linux servers, if the fsid=0 export does not exist, the mount will die with ENOENT (or 'No such file or directory'). Other NFS implementation decided not to support a definable pseudo roots and they just made, under the covers, their '/' as the pseudo root, along with the appropriate protections. So putting the / *(ro,fsid=0) is only adding an export of that part of the name space into the tree to make it compatible with pre-V4 name spaces. Exactly... With F-12, I have added code to both the kernel and nfs-utils that will do both. Allow the 'fsid=0' export to define the pseudo root and make '/' the pseudo root (with the appropriate protections) when there is not an fsid=0 entry. So Yes, one work around to make F-12 mounts work with Linux servers is to define a pseudo root on the server with a fsid=0 export. But if that is not an option, you can make the F12 clients only use V3 mount (which would avoid the problem, but not take advantage of the V4 protocol) by set either setting the '-o v3' mount option or set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make all mounts from that machine v3 mounts). But the downside of the / *(ro,fsid=0) approach is we now have all of the root files (but not any other filing systems visible). No, other mounts files systems would be visible as well.. That is not what we see today - at least I do not think so. We still have to add exports statements to get filing system transitions to export. So perhaps a better approach would be to specify a /V4root *(ro,fsid=0) directory being created and a bind mount for each export from the pre-V3 name space being made into that tree. Or have I missed something entirely? That sounds like it could work, although it may not be too scalable with large and complicated export tree... Works with a medium size network here - we export about 100 filing systems in a single tree! The real answer is use a F-12 NFS server since all this stuff goes away.. Does that mean the F12 provides V4 servers for preference and F11 does not? I must have done something in the past to make F11 serve V4 by default then - wonder what it was? steved. -- Howard Wilkinson how...@cohtech.com Coherent Technology Limited -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 15:41, Thomas Janssen (thom...@fedoraproject.org) wrote: Haha. So the major 'advantage' of Phonon that it would allow replacing the backends as time progresses without breaking the KDE apps using them now officially is proven to be bogus. The KDE/Qt folks were so afraid of a media engine breaking API so that they created their abstraction thing and now break API of that one more often then the media engines themselves do. Do I hear an I told you so!? Abstractionitis is an illness, not a remedy. People who live in a glass houses shouldn't throw stones. Are you suggesting PA was an abstraction layer? Maybe it can act as one, but that is only a side effect, not its only purpose. Unlike for example Phonon. An abstraction layer's main purpose it to abstract differences of what is below, and as hence usually is a least common denominator of what is below, but certainly nothing that adds features. PA OTOH extends what is below, it adds features. But heck, this discussion is pretty academic and off-topic. Let's end this here. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- 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 09/30/2009 11:07 AM, Howard Wilkinson wrote: With version 4 there is this concept of a pseudo root. Which meanings one can define, through exports, what the root of an export can be. Which is a good idea because you can define /export as the root, and nothing above /export can be accessed... But if there is a /data *(ro,fsid=0) export then that will do, but it becomes the root of the export tree against which mounts are made? Yes.. For example say the directory tree under /data looks like /data dir1/ subdir1/ dir2/ subdir2/ Then the client could do a mount server:/ /mnt/ which would make every thing under /data visible, meaning ls /mnt/dir1 ls /mnt/dir2 Now the client could also do a mount server:/dir1 /mnt which would only make the the directories under /data/dir1 visible, meaning ls /mnt/subdir1 This is the scheme we use here already and we are running V4 on everything except the kickstart network based builds as that only seems to understand V3. This is F11 with a few additions from F12 backported. This is good to hear... With F-12, I have added code to both the kernel and nfs-utils that will do both. Allow the 'fsid=0' export to define the pseudo root and make '/' the pseudo root (with the appropriate protections) when there is not an fsid=0 entry. So Yes, one work around to make F-12 mounts work with Linux servers is to define a pseudo root on the server with a fsid=0 export. But if that is not an option, you can make the F12 clients only use V3 mount (which would avoid the problem, but not take advantage of the V4 protocol) by set either setting the '-o v3' mount option or set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make all mounts from that machine v3 mounts). But the downside of the / *(ro,fsid=0) approach is we now have all of the root files (but not any other filing systems visible). No, other mounts files systems would be visible as well.. That is not what we see today - at least I do not think so. We still have to add exports statements to get filing system transitions to export. Try adding either 'nohide' or 'crossmnt' on your other exports... So perhaps a better approach would be to specify a /V4root *(ro,fsid=0) directory being created and a bind mount for each export from the pre-V3 name space being made into that tree. Or have I missed something entirely? That sounds like it could work, although it may not be too scalable with large and complicated export tree... Works with a medium size network here - we export about 100 filing systems in a single tree! The real answer is use a F-12 NFS server since all this stuff goes away.. Does that mean the F12 provides V4 servers for preference and F11 does not? For now yes... but due to the all the excitement that has generated an adjustment might be made... ;-) I must have done something in the past to make F11 serve V4 by default then - wonder what it was? You must be set the '-t nfs4' fileystem type. steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 10:15, Jaroslav Reznik (jrez...@redhat.com) wrote: So where's the problem? There are two Phonons - one in Qt, one in KDE. I don't like this schizophrenia. This should be solved but now we have to live with one or another - that's why we brought this issue to the world. Maybe KDE should add another abstraction layer on top of the various Phonons which abstracts the differences between them! [1] But I'm happy you have joined this discussion as PA developer. How do you see PA support in GStreamer and Xine? Functionality, features, support - regarding to Fedora development as this could influence our final decision. Isn't it obvious where the good stuff is? Just compare how many commits happened in the last months to the xine-lib hg and how many to the gst git trees. gst has a much much larger developer community and multiple companies backing it. It's the only practical way to get licenses MP3 codecs for Linux. And it is more powerful than xine in many ways. Also, my cooperation with the gst devs is much closer. I have contributed some patches to xine a while back too, but since I don't use it it is much more lacking. Finally, Gst is used by Gnome. Would be great if this could be another place were we could not only cooperate on specs but also actually share code. Another interesting thing is PA Phonon integration work by Colin Guthrie (see the link in my first message). Phonon just as wrapper/thin client for PA with nicer Qt like API. I like this idea. Uh, PA is a PCM sound server. Phonon an abstraction layer for general media streaming. Those are different things. Yu can wrap PA and gstreamer in phonon, but just wrapping PA alone won't fly. Lennart [1] That was a joke. -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 30.09.09 13:53, Rahul Sundaram (sunda...@fedoraproject.org) wrote: On 09/30/2009 01:45 PM, Jaroslav Reznik wrote: So where's the problem? There are two Phonons - one in Qt, one in KDE. I don't like this schizophrenia. This should be solved but now we have to live with one or another - that's why we brought this issue to the world. The problem is that Nokia now seems to be developing yet another abstraction layer. So we will have to be dealing the Phonon in KDE, Phonon in Qt and whatever Nokia brings up next and all the possible backends. The number of different paths that requires comprehensive testing has exploded. We are also debating which backend to use as the default for a long time and as usual, switching backends is exchanging one set of bugs with another so neither is going to be ideal. I would prefer Gstreamer as the backend simply because users can install a set of plugins (third party repo or Fluendo) and have their content play in all the different desktop environments. We can fix bugs once in Gstreamer and be done with it. However that depends on how much testing this backend has received and what bugs have been found and how severe they are. This is a bit of a chicken-and-egg problem: if you don't activate gst noone will test it. But you don't want to activate it by default without testing. We're Fedora, the distro which is always a bit ahead of the other distributions, aren't we? So I think it would make a lot of sense to switch to make our distro Gst-only asap. Eventually this move will have to happen anyway. And if it's not us who does the switch first, who will? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On 09/30/2009 09:40 PM, Lennart Poettering wrote: This is a bit of a chicken-and-egg problem: if you don't activate gst noone will test it. But you don't want to activate it by default without testing. True but we do have Phonon using Gstreamer as the backend in Rawhide. If it has severe problems, unmaintained and we have noone willing to fix it, then using Xine might be ok. Before we comment further, it would be useful to know what the known important bugs are. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Tue, 2009-09-29 at 08:07 -0700, Toshio Kuratomi wrote: On 09/29/2009 05:00 AM, Rahul Sundaram wrote: On 09/29/2009 05:14 PM, Josephine Tannhäuser wrote: Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? They are called guidelines and there are always exceptions. Bundling a library is not ideal but removing rsync would be a extreme step. I don't think the situation warrants that. Let's not loose perspective here. So in this case, I think the following things could be said: * Removing rsync is not an option because of how widely it is used. Sure. * Bundling libraries in zsync is not an option Why is it not? Because you don't use it? Because f-i doesn't currently use it? (remember this thread started because the Fedora QA group wants to use it). Maybe we should split the packaging guidelines into ones everyone has to follow and ones that are really anal and only unpopular packages have to follow. -- James Antill ja...@fedoraproject.org Fedora -- 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
Jesse Keating wrote: People with cargo cult knowledge knew what they meant but not new contributers nor community users. The change was for the better as it more clearly defines the milestones. So clearly that many feature owners are confused about what they mean? And don't forget that development snapshots are primarily for developers (in fact many projects use developER release as synonymous to developMENT release), so it's important that THEY are familiar with the terms. Any change is going to cause some confusion with those who are used to the previous state but to change t again would just be worse. In no time you'll be used to the change and rail against any fruther change. I don't think we've reached that point at all. I think justifying the change post-facto as a one-time change for the shorter F12 cycle (even though that wasn't the plan) and changing back to the tried and true terminology from F11 for F13 would not leave many people confused. And worst case, in the unlikely event people already got used to the terms from F12, the worst that could happen after reverting to the previous terms is that they would deliver F13 features one milestone TOO EARLY. That would actually be a good thing. ;-) So really, I see no practical argument against switching back to the Alpha/Beta/Preview naming (and reintroducing the old Alpha – again, as useless as it was in practice, the psychological impact on developers shouldn't be underestimated). Kevin Kofler -- 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 09/30/2009 04:09 AM, Steve Dickson wrote: I don't really understand this reason. When you get a mount fail, why not try v3? It doesn't matter whether the kernel gives a different kind of error or not. The error that is returned is ENOENT which is fatal error because it means the remote directory does not exist... and I'm not sure it would be good to continue flood the network with mounts requests (I'm thinking about autofs mount storms) for directories that may or may not be there... Are mount requests really that resource intensive? If so, perhaps caching mount attempt results and stepping back the protocol would be appropriate. Really though, switching V4 on without an auto-fallback to V3 seems like a really bad change. Shouldn't there be at least one transitional Fedora release where auto-fallback happens, perhaps with a syslog notice? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- 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
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... :-\ steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Lennart Poettering wrote: So I think it would make a lot of sense to switch to make our distro Gst-only asap. Eventually this move will have to happen anyway. Uh, I have to disagree there. It is not our job as distribution packagers to dictate to upstream developers what multimedia library they use. If an upstream project XYZ requires e.g. libnobody-else-uses-me (fictional name) for multimedia and XYZ is worth packaging, we'll want libnobody-else-uses-me packaged too. At best we can try to get mainstream applications ported to a common framework (like we did for spellchecking (hunspell), in fact I set up KDE to use hunspell everywhere, but there are still quite some niche apps outside of GNOME and KDE using aspell), but even that doesn't always make sense: for example, the crypto consolidation (NSS) is just not working (OpenSSL is the de-facto standard upstream projects are used to work with and many still support only that) and suggesting all GUI apps to standardize on GTK+ would be a complete no-go. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Wed, Sep 30, 2009 at 10:27:44AM -0700, Toshio Kuratomi wrote:
So... that means the custom zlib isn't necessary to the proper operation
of deltarpm, correct? I haven't looked at where in the code this is
being used yet but I'm guessing this zlib is used when:
1) Reading the existing rpm -- this should work with vanilla zlib as well
2) Compressing the deltarpm -- this should work with vanilla zlib, just
not be as kind to rsync.
No, things are a bit different. Fedora's rpm used to have a
modified copy of zlib so that the created rpms were more rsync
friendly. As deltarpm needs to recreate the same compressed
payload I also had to support this.
AFAIK the current rpm uses the system's zlib library, so the
deltarpm copy is also no longer needed for Fedora.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
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 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-) steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 19:11:36 Kevin Kofler wrote: Lennart Poettering wrote: So I think it would make a lot of sense to switch to make our distro Gst-only asap. Eventually this move will have to happen anyway. Uh, I have to disagree there. It is not our job as distribution packagers to dictate to upstream developers what multimedia library they use. If an upstream project XYZ requires e.g. libnobody-else-uses-me (fictional name) for multimedia and XYZ is worth packaging, we'll want libnobody-else-uses-me packaged too. At best we can try to get mainstream applications ported to a common framework (like we did for spellchecking (hunspell), in fact I set up KDE to use hunspell everywhere, but there are still quite some niche apps outside of GNOME and KDE using aspell), but even that doesn't always make sense: for example, the crypto consolidation (NSS) is just not working (OpenSSL is the de-facto standard upstream projects are used to work with and many still support only that) and suggesting all GUI apps to standardize on GTK+ would be a complete no-go. That's not about standardize on GTK+ (yes, it would be nice world with Qt Everywhere :D) but support best supported framework. There's no problem with not supported GStreamer - it's supported in Phonon, with some question marks. So now once we have lot of stuff on Phonon, we can make Xine lib optional. Some time ago it was much more better than GStreamer, now GStreamer is better and more supported. We should choose better technology over politics. Jaroslav Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, 2009-09-30 at 00:11 +0200, Lennart Poettering wrote: On Tue, 29.09.09 22:46, Kevin Kofler (kevin.kof...@chello.at) wrote: Behind GStreamer, sure. Behind Phonon (and thus also Phonon-GStreamer), not so much. They're currently using it, but there are people working on the Qt Mobility project talking about replacing Phonon with something else (another abstraction layer, again around native backends (GStreamer in the GNU/Linux case), I really don't see what the advantage would be over Phonon). Haha. So the major 'advantage' of Phonon that it would allow replacing the backends as time progresses without breaking the KDE apps using them now officially is proven to be bogus. The KDE/Qt folks were so afraid of a media engine breaking API so that they created their abstraction thing and now break API of that one more often then the media engines themselves do. Do I hear an I told you so!? Abstractionitis is an illness, not a remedy. whatever the validity of this, it rather looks like sandbagging the intended discussion, and doesn't seem to be directly relevant to Fedora development. perhaps it should be discussed on a more appropriate list, or privately with Kevin - at the very least, in a separate thread. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/30/2009 10:43 AM, Michael Schroeder wrote: On Wed, Sep 30, 2009 at 10:27:44AM -0700, Toshio Kuratomi wrote: So... that means the custom zlib isn't necessary to the proper operation of deltarpm, correct? I haven't looked at where in the code this is being used yet but I'm guessing this zlib is used when: 1) Reading the existing rpm -- this should work with vanilla zlib as well 2) Compressing the deltarpm -- this should work with vanilla zlib, just not be as kind to rsync. No, things are a bit different. Fedora's rpm used to have a modified copy of zlib so that the created rpms were more rsync friendly. As deltarpm needs to recreate the same compressed payload I also had to support this. nod -- So historically, this bundled library seemed like a good idea for the *same* reason as the rsync/zsync situation. You had the need to produce the same format with deltarpm as rpm did with its bundled and forked private zlib. Since neither the rpm maintainer nor you wanted to be responsible externally for the forked copy, you just bundled the same version of zlib as they did. At some point, rpm maintainers asserted sanity on their situation and began to build against the system zlib, discarding the rsync patch in favor of maintainability. deltarpm didn't catch on to that change so it continued to ship a forked copy. Eventually, the fork failed to update with the latest version of zlib and so it began to ship with a known vulnerability that had already been fixed in the main zlib package. And that's how we got to where we are today. AFAIK the current rpm uses the system's zlib library, so the deltarpm copy is also no longer needed for Fedora. Interesting. That's slightly puzzling though. That would mean that deltarpm wasn't able to create the same compressed payload on Fedora where Fedora's rpm used the system zlib, correct? That would mean rpm-4.4.2.2, at least as far back as Fedora 10. Yet we were testing deltarpms for Fedora 10 and Fedora 11, correct? I'm building new deltarpm packages for F-10, F-11 now. F-12 and devel are built. I'm not sure what to do about EPEL -- EL-4's rpm is pre-rpm-4.4.2.2. EL-5's rpm starts off at rpm-4.4.2 but by the time we hit RHEL-5.4 we're past rpm-4.4.2.2 so it's okay. Also, the infrastructure builders are going to need to be updated. Since it appears we're only building deltarpms for the Fedora repos, I think it's safe to build that package with system zlib as well. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/29/2009 09:24 AM, James Antill wrote: On Tue, 2009-09-29 at 08:07 -0700, Toshio Kuratomi wrote: On 09/29/2009 05:00 AM, Rahul Sundaram wrote: On 09/29/2009 05:14 PM, Josephine Tannhäuser wrote: Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? They are called guidelines and there are always exceptions. Bundling a library is not ideal but removing rsync would be a extreme step. I don't think the situation warrants that. Let's not loose perspective here. So in this case, I think the following things could be said: * Removing rsync is not an option because of how widely it is used. Sure. * Bundling libraries in zsync is not an option Why is it not? Because you don't use it? Because f-i doesn't currently use it? (remember this thread started because the Fedora QA group wants to use it). Maybe we should split the packaging guidelines into ones everyone has to follow and ones that are really anal and only unpopular packages have to follow. No -- the rest of my bullets outline how to bring rsync into compliance with the Guidelines. All packages need to follow all MUST items unless there is an exception clause and an exception has been granted. rsync doesn't get a get of jail free card because it is popular. It gets a We must make one of these fixes a priority because it is important. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson (ste...@redhat.com) said: Right or wrong.. I took Final Feature Freeze as the last chance of getting a feature into F12.. And I will be the first to admit I do not read all the rule and regulations of all the steps of a release... I look at dates.. When is the alpha and when is the beta. After a beta release I don't even try to get anything new in, just bug fixes... http://fedoraproject.org/wiki/Releases/12/Schedule 2009-07-28 Feature Freeze--Planning Development Ends Are we actually exporting that different elsewhere? Bill -- 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 09/30/2009 03:18 PM, Bill Nottingham wrote: Steve Dickson (ste...@redhat.com) said: Right or wrong.. I took Final Feature Freeze as the last chance of getting a feature into F12.. And I will be the first to admit I do not read all the rule and regulations of all the steps of a release... I look at dates.. When is the alpha and when is the beta. After a beta release I don't even try to get anything new in, just bug fixes... http://fedoraproject.org/wiki/Releases/12/Schedule 2009-07-28 Feature Freeze--Planning Development Ends Are we actually exporting that different elsewhere? Yeah... I remember scanning this page and catching the Beta (Final Development) Freeze and thinking cool! I have unto the 29th to finish my development! and then never giving a it a second thought... Until John email came out.. cementing the 29th... Maybe removing the Final Development part and replace it with something like Beta Freeze (Bug Fixes ONLY) might have helped. But as the end of the day, I did miss the Development Ends part of the Feature Freeze since I took it the Feature Freeze as no more features allowed in the F-12 release, which was the ultimate mistake... Moving too fast for my own good... :( steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Freeze at 0600~ 2009-09-30 UTC
On Wed, 2009-09-30 at 23:31 +0900, Mamoru Tasaka wrote: By the way although this time already came dist-f12 tree seems still unfrozen [1] and some builds after this freeze time are already included into dist-f12-build tree [2]. Does this mean that these packages (rebuilt after F12 beta freeze) are finally included in F12 final tree? [1] http://koji.fedoraproject.org/koji/taginfo?tagID=85 [2] http://koji.fedoraproject.org/koji/builds?tagID=86order=-completion_timelatest=1 Well, I missed one step in the freeze process, which was locking the dist-f12 tag. I'll do that now and find the builds that snuck in and move them around. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Buyer Beware: A Major Change in NFS is about to happen
On Wed, 2009-09-30 at 19:00 +0200, Kevin Kofler wrote: So clearly that many feature owners are confused about what they mean? A few feature owners missed the repeated messages. I'm sorry, it was bound to happen. Change causes disruption, but often that disruption is for the better good. And don't forget that development snapshots are primarily for developers (in fact many projects use developER release as synonymous to developMENT release), so it's important that THEY are familiar with the terms. And many of our developERs were not used to the milestone names we gave our developMENT releases. Also, our developMENT releases are for QA testers as well, who were equally confused as to the meanings of our old milestones. Any change is going to cause some confusion with those who are used to the previous state but to change t again would just be worse. In no time you'll be used to the change and rail against any fruther change. I don't think we've reached that point at all. I think justifying the change post-facto as a one-time change for the shorter F12 cycle (even though that wasn't the plan) and changing back to the tried and true terminology from F11 for F13 would not leave many people confused. This isn't a post-facto justification. The only one-off for F12 was the removal of the milestone previously known as alpha. The rest of the milestone adjustment proposal came out of the Fedora Activity day, had lots of time to be communicated, discussed, and voted on by the community at large, FESCo specifically. And worst case, in the unlikely event people already got used to the terms from F12, the worst that could happen after reverting to the previous terms is that they would deliver F13 features one milestone TOO EARLY. That would actually be a good thing. ;-) So really, I see no practical argument against switching back to the Alpha/Beta/Preview naming (and reintroducing the old Alpha – again, as useless as it was in practice, the psychological impact on developers shouldn't be underestimated). I'm really not in favor of changing it again. A group of developers, release engineers, and QA folks brainstormed on fixing the milestone issues and what we have now is the product of that effort. If you really think it wasn't for the eventual better, float your own proposal and get approval from developers, release engineers, QA folks, and eventually FESCo. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: status of forked zlibs in rsync and zsync
On 09/30/2009 11:34 AM, Toshio Kuratomi wrote: On 09/30/2009 10:43 AM, Michael Schroeder wrote: AFAIK the current rpm uses the system's zlib library, so the deltarpm copy is also no longer needed for Fedora. Interesting. That's slightly puzzling though. That would mean that deltarpm wasn't able to create the same compressed payload on Fedora where Fedora's rpm used the system zlib, correct? Ah -- I see what you're doing. Unfortunately, there's something in the logic that assumes the presence of the modified zlib. I'll see if I can fix it to work if the compression type is plain gz and error if it's requested to do rsyncable compression and the library doesn't support it. -Toshio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/30/2009 07:43 PM, Michael Schroeder wrote: Fedora's rpm used to have a modified copy of zlib so that the created rpms were more rsync friendly. As deltarpm needs to recreate the same compressed payload I also had to support this. Always nice to see how insanity leads to even more insanity. And nice to see that we can remove it now. Florian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/28/2009 12:21 PM, Josh Boyer wrote: Hi All, As of today, ppc and ppc64 are no longer primary architectures in koji starting with the dist-f13 tag. This is in accordance with the FESCo approved demotion of PowerPC starting with Fedora 13 development. The dist-f12 and older tags continue to have them as primary. Both ppc and ppc64 have been excellent at catching software bugs in my projects that long went unnoticed on i386/x86-64. The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. Is there another big-endian platform that is on the upswing? regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Once upon a time, Tom Lane t...@redhat.com said: Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. Is there another big-endian platform that is on the upswing? IIRC ARM can be, but I think many (most?) ARM platforms that would support Fedora are little-endian. SPARC is big-endian but is not on the upswing. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. s/machines/desktop machines. You can find all kinds of PPC machines, just typically not in desktop form. The only new one that I am aware of is the fixstars.us Powerstation. Is there another big-endian platform that is on the upswing? Not to my knowledge, but I haven't paid much attention to that. We do have secondary arches at least building, like sparc and s390x. I have a ppc effort 1/2 going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Final Review of Incomplete Fedora 12 Features
Hi FESCo, With the passing of Beta Freeze we are now at the point in our release process where we expect all features to be at 100% completion. After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status. https://www.redhat.com/archives/fedora-devel-announce/2009-September/msg8.html https://fedoraproject.org/wiki/Features/DisplayPort https://fedoraproject.org/wiki/Features/LowerProcessCapabilities https://fedoraproject.org/wiki/Features/NFSv4Default In accordance with our recorded policy of requiring that all features be at 100% at Beta Freeze, I am proposing these features for your review to determine what their disposition should be. https://fedoraproject.org/wiki/Features/Policy/Dropping Thank you, John p.s. I'm going based solely on the information on the feature page. p.s.s. Feature owners are also being bcc'd on this message and a copy is also being sent to fedora-devel-announce. ___ 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: bitmap-fonts by default?
IMHO default packages in default groups should have a clear user, or be downgraded to optional. Right I suggest we make it optional in comps-f13 and see if anything breaks. Jens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik wrote: I would rather the problem be approached in a logical, scalable fashion: by distributing the workload across the package maintainers who have firsthand knowledge. ie. how things worked before. But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. I think it is only fair that the people who actually care get to do the work. Package maintainers can still fix their packages for PPC, they'll even get e-mail reports from the secondary arch Koji if the builds fail. (It already happens for the other secondary architectures.) They just won't be required to do it anymore. You can't force volunteers (and many Fedora developers are volunteers; even those paid by RH are paid primarily to work on RHEL, not Fedora, and often do Fedora work in their own free time) to work on something they're not interested in. Was ppc really such a burden? Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages. In fact, my favorite ppc64 issue was a problem with OpenBabel hitting a limitation in the ppc64 toolchain: there's a table of contents which can grow only to a small fixed size, so large compilation units just don't compile on ppc64, while being perfectly valid C/C++ and compiling fine on all other architectures. (And that's already with the minimal TOC. Without it, the limit is for the whole executable!) OpenBabel's SWIG-generated bindings exceeded that limit. We were the only ones hitting it as no other distribution is insane enough to build their packages for ppc64. (The binaries don't even get actually used as ppc32 is the preferred multilib on 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce the amount of TOC entries, which worked for 2 beta releases (requiring additional tweaking for the second one), but then it overflowed again. This was a big annoyance because the new OpenBabel betas were required for new kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream removed some things from their bindings to get them to build, a quite suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs to be redesigned from scratch. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff Garzik wrote: I would rather the problem be approached in a logical, scalable fashion: by distributing the workload across the package maintainers who have firsthand knowledge. ie. how things worked before. PPC hardware isn't exactly common these days. I'm sure there are a few machines on campus that have PPC (there are definitely SPARC workstations sprinkled around). As it stands, I have no useful access to any of the machines (I guess a Live CD could get some special access, though at what cost to my status as a student, I don't know). But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated an ability to detect problems not found on LE, it seems like this policy change will directly lead to missed bugs, and an attendent decline in software quality. Was ppc really such a burden? Jeff Build times were the worst part of it IMO. With how it was set up (ppc being default even on ppc64) ppc64 could have been dropped and ppc be left intact. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKw/+VAAoJEKaxavVX4C1XccEP/RwHvNRhDexa5klFpl3mDvlQ pFLpT2OogtNWT58RuxvyOIlQMHs8NJbWdu+cjBYxav70Uhk2a7zqCN8g+ExJz0YM QSRd8HVyNTglOOT9kVLpQR9JM9E7gehnqTbDUY3l7kb9It02oQ8xf08M7Z+UNwgB FRFcXRQRZ8m8PfkOpTAEFlwXccRuyYQcm1CgvVX52NMVma32FxkFWxfBfBEL4vkH lfSeuU1z6bzKsHbUOFV0qBcteDYRRE7UjG698qlFJY2PCu5mSZzwt8QQiiXaqemS oYRDvXxoLEL6xHVlwboYAbT5ej/Gt51EOzlH6GMinLaJCfXwbe4Eb1hkpS09p4k4 rB4ttazM5rl1SEYuXP318X0qHguhNjZeFvg4NPuep+Xbk1uy2cKDFygk5XDxgsH+ sJxGnsv09f6An7+y2seK+P9TviIr1g2SqeebaZeK2lOCIOBU0Ip7aXVM0A0/tNK8 By0qZOfOjhYoac5FvXTuJUU3+Zh7SZDxexwnsfUM8gyIMRllDMpIwp2tfqQHY6wJ AwuNoCPTchqXzr+WE24Y/9QX2Merbj0AooKzIFuHIAtpC/usD2/bggvVYiq1PM+k frIuFJmugcsMt6Yool6Sl7kJqFW4nin5xUdbPJuY6UQP+6x7oouV53WMsVFtW5zk fBXSd9Rm2dMgiXQp/2JR =MGWo -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
CalDAV Calendar (BedeWork)
Hello all, About a year ago, I suggested that BedeWork (http://bedework.org) be included. I offered to package it with some help. I unfortunately ran out of time. I now have time to package it and hopefully maintain the package. Unfortunately, I haven't written an Java code in a decade or so. I have never messed with Java packages. The problems I have: This package has a bunch of property files that you have to edit before you build the program. (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18) These include database names, locations, user/passwords for the database, etc. I do not know if this is normal or not. I do not know how to package this, how to suggest people customize this information, etc. This program also requires JBoss or Tomcat (maybe there are others that will work). Since I do not see JBoss in Fedora, Tomcat would be fine. I have not experience with this. It would be nice if a Tomcat person can help me with documentation on how to get this working and to use AD (Kerberos [SPNEGO/GSSAPI] and LDAP) for the authentication and user/group information as well. I have a few packages that I have not yet submitted that I have packaged. These include PyKota (and its dependencies), DSPAM, and C-ICAP (not yet ready as I have some code I am writing that will be turned over before I submit this package). I have no clue about any of the build systems in Fedora, so I will need help with this as well. I know that F12 is closed for this, but I could get it ready for F13. Thank you, Trever signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Jesse Keating wrote: This isn't a post-facto justification. The only one-off for F12 was the removal of the milestone previously known as alpha. Making the renaming a one-time-only change as I'm proposing would be post facto. The rest of the milestone adjustment proposal came out of the Fedora Activity day, had lots of time to be communicated, discussed, and voted on by the community at large, FESCo specifically. I don't remember FESCo ever voting on that issue and I can't find it in the meeting summaries either (and I also checked the ones from before I joined, back to April). AFAIK, this was just posted to the fedora-devel-list for feedback, got almost none, which was taken by you as everyone is fine with it (whereas I think most people probably just ignored it as yet another wacky proposal which is never going to get implemented sent to fedora-devel- list) and a few days later it was a rel-eng decision. (I remember having been really surprised by this having been implemented (Huh, there's a F12 Alpha now?), given that there was no consensus at all on the mailing list.) I don't doubt there was some in-person discussion at the FAD, but that will never be as inclusive as a mailing list discussion (which never happened because a huge list of brainstorming results (which turned out to actually mean almost decided items, which also wasn't clear from the wording or you might have gotten more objections) was dumped onto the mailing list in one e-mail). I think a small circle of people flying to some location to make lots of decisions in person in one day is really bad for transparency in an international project like ours. Ideas really need to be sent one at a time to the public mailing lists. And there's an additional important point: we have additional evidence now that the renames were harmful! So, independently from how the decision was originally achieved, we should revisit it now based on the new evidence. Back when the renames were proposed, I didn't quite see the point, but I didn't think it'd be a big issue either. But as time has progressed, I have seen many developers come to FESCo with things like oh, I was supposed to have this feature ready for Alpha? I thought it was Beta as always!. These renames turned out to have produced lots of lateness in the feature process, and Fedora development as a whole. So I'm now proposing to solve this problem by restoring the names people are used to. I think having our developers deliver on time is much more important than using pedantically correct names which lost most of their meaning anyway (beta can be everything from unusable pre-alpha code to Google's betas these days) in end-user communication. Those users are going to be the ones hurt the most by buggy, incomplete or entirely missing features, so having the milestone names make sense for developers is also what's most important for THEM. I'm really not in favor of changing it again. A group of developers, release engineers, and QA folks brainstormed on fixing the milestone issues and what we have now is the product of that effort. If you really think it wasn't for the eventual better, float your own proposal and get approval from developers, release engineers, QA folks, and eventually FESCo. My proposal is plain and simple: go back to the 3 milestones and their naming from F11. It worked and developers all knew what the milestones corresponded to. The change was completely unnecessary and just caused confusion. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CalDAV Calendar (BedeWork)
Trever L. Adams wrote: I know that F12 is closed for this, but I could get it ready for F13. Actually, new packages can be pushed as updates. You can add them even to F11, and F10 if you're really quick (new packages are accepted in F10 until 1 month before its end of life, which is basically the day of F12's release, as the end of life for Fedora n is 1 month after Fedora n+2's release). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Kevin Kofler kevin.kof...@chello.at writes: Jeff Garzik wrote: But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. I think it is only fair that the people who actually care get to do the work. Package maintainers can still fix their packages for PPC, they'll even get e-mail reports from the secondary arch Koji if the builds fail. (It already happens for the other secondary architectures.) They just won't be required to do it anymore. You can't force volunteers (and many Fedora developers are volunteers; even those paid by RH are paid primarily to work on RHEL, not Fedora, and often do Fedora work in their own free time) to work on something they're not interested in. You may have a point about volunteer maintainers, though I'd hope they'd be concerned about the quality and portability of their packages anyway. But for anyone working for Red Hat, it's insanely shortsighted to think that not testing on BE platforms is going to save work. We're going to have to make this stuff work on BE platforms for RHEL later on, and it will just be that much more painful if it happens months or years after the changes are fresh. Quite aside from people having forgotten the details of what they changed, upstream projects could be locked into little-endian-only file formats or other hard-to-change decisions by that time. Was ppc really such a burden? Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages. Again, would you rather debug glibc now, or later? Not at all is not an option. [ ppc64 horror story snipped ] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bitmap-fonts by default?
2009/10/1 Jens Petersen peter...@redhat.com IMHO default packages in default groups should have a clear user, or be downgraded to optional. Right I suggest we make it optional in comps-f13 and see if anything breaks. Yep, this looks nice In merge review of bitmap-fonts, we are splitting it as per font family we will get sufficient time to come at conclusion, which to keep default and which optional Thanks Regards, -- Pravin Satpute -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 523454] [ml_IN] Fontconfig settings for Meera font not working properly
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=523454 Rahul Bhalerao b.rahul...@gmail.com changed: What|Removed |Added CC||b.rahul...@gmail.com --- Comment #7 from Rahul Bhalerao b.rahul...@gmail.com 2009-09-30 02:01:48 EDT --- Has the ascent-descent values for meera been changed recently? If so, please revert back to last working values if the change was not deliberate. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/bitmap-fonts/F-12 bitmap-fonts.spec,1.20,1.21
Author: pravins
Update of /cvs/pkgs/rpms/bitmap-fonts/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21578
Modified Files:
bitmap-fonts.spec
Log Message:
* Wed Sep 30 2009 Pravin Satpute psatp...@redhat.com - 0.3-9
- updating as per new packaging guidelines
- bugfix 481068
Index: bitmap-fonts.spec
===
RCS file: /cvs/pkgs/rpms/bitmap-fonts/F-12/bitmap-fonts.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- bitmap-fonts.spec 24 Jul 2009 18:07:05 - 1.20
+++ bitmap-fonts.spec 30 Sep 2009 07:26:47 - 1.21
@@ -1,6 +1,12 @@
+#%global fontname bitmap
+%define common_desc \
+The bitmap-fonts package provides a number of bitmap fonts selected\
+from the xorg package designed for use locations such as\
+terminals.
+
Name: bitmap-fonts
Version: 0.3
-Release: 8%{?dist}
+Release: 9%{?dist}
License: Lucida and MIT and Public Domain
Source0: bitmap-fonts-%{version}.tar.bz2
Source1: fixfont-3.5.tar.bz2
@@ -10,25 +16,40 @@ Group: User Interface/X
Summary: Selected set of bitmap fonts
Requires(pre): fontconfig
BuildRequires: xorg-x11-font-utils
+BuildRequires: fontpackages-devel
%description
-The bitmap-fonts package provides a number of bitmap fonts selected
-from the xorg package designed for use locations such as
-terminals.
+%common_desc
+
+%package common
+Summary: Common files for bitmap-fonts
+Requires: fontpackages-filesystem
-%package cjk
+%description common
+%common_desc
+
+This package consists of files used by other %{name} packages.
+
+%_font_pkg lut* con* [0-9]*
+
+%package -n bitmap-cjk-fonts
Summary: Selected CJK bitmap fonts for Anaconda
Group: Applications/System
Requires(pre): fontconfig
+Requires: %{name}-common = %{version}-%{release}
+Provides: %{name}-cjk = %{version}-%{release}
-%description cjk
+%description -n %{fontname}-cjk-fonts
bitmap-fonts-cjk package contains bitmap fonts used by Anaconda. They are
selected from the xorg packages, and the font encoding are converted from
native encoding to ISO10646. They are only intended to be used in Anaconda.
+%_font_pkg -n cjk fangsongti*
+
%prep
%setup -q -a 1
+
%install
rm -rf $RPM_BUILD_ROOT
@@ -38,44 +59,25 @@ cd fixfont-3.5
make install DESTDIR=$RPM_BUILD_ROOT
+mv $RPM_BUILD_ROOT/usr/share/fonts/bitmap-fonts %{buildroot}%{_fontdir}
+
+#install -m 0755 -d %{buildroot}%{_fontdir}
+
# %%ghost the fonts.cache-1 file
-touch $RPM_BUILD_ROOT%{_datadir}/fonts/bitmap-fonts/fonts.cache-1
+#touch $RPM_BUILD_ROOT%{_datadir}/fonts/bitmap-fonts/fonts.cache-1
%clean
rm -rf $RPM_BUILD_ROOT
-%post
-fc-cache %{_datadir}/fonts
-
-%postun
-if [ $1 = 0 ]; then
- fc-cache %{_datadir}/fonts
-fi
-
-%post cjk
-fc-cache %{_datadir}/fonts
-
-%postun cjk
-if [ $1 = 0 ]; then
- fc-cache %{_datadir}/fonts
-fi
-
-%files
+%files common
%defattr(-,root,root)
%doc README LU_LEGALNOTICE
-%dir %{_datadir}/fonts/bitmap-fonts
-%{_datadir}/fonts/bitmap-fonts/lut*
-%{_datadir}/fonts/bitmap-fonts/con*
-%{_datadir}/fonts/bitmap-fonts/[0-9]*
-%ghost %{_datadir}/fonts/bitmap-fonts/fonts.cache-1
-
-%files cjk
-%defattr(-,root,root)
-%dir %{_datadir}/fonts/bitmap-fonts
-%{_datadir}/fonts/bitmap-fonts/fangsongti*
-%ghost %{_datadir}/fonts/bitmap-fonts/fonts.cache-1
%changelog
+* Wed Sep 30 2009 Pravin Satpute psatp...@redhat.com - 0.3-9
+- updating as per new packaging guidelines
+- bugfix 481068
+
* Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/bitmap-fonts/devel bitmap-fonts.spec,1.20,1.21
Author: pravins
Update of /cvs/pkgs/rpms/bitmap-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv24980
Modified Files:
bitmap-fonts.spec
Log Message:
* Wed Sep 30 2009 Pravin Satpute psatp...@redhat.com - 0.3-9
- updating as per new packaging guidelines
- bugfix 481068
Index: bitmap-fonts.spec
===
RCS file: /cvs/pkgs/rpms/bitmap-fonts/devel/bitmap-fonts.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- bitmap-fonts.spec 24 Jul 2009 18:07:05 - 1.20
+++ bitmap-fonts.spec 30 Sep 2009 07:36:13 - 1.21
@@ -1,6 +1,12 @@
+#%global fontname bitmap
+%define common_desc \
+The bitmap-fonts package provides a number of bitmap fonts selected\
+from the xorg package designed for use locations such as\
+terminals.
+
Name: bitmap-fonts
Version: 0.3
-Release: 8%{?dist}
+Release: 9%{?dist}
License: Lucida and MIT and Public Domain
Source0: bitmap-fonts-%{version}.tar.bz2
Source1: fixfont-3.5.tar.bz2
@@ -10,25 +16,40 @@ Group: User Interface/X
Summary: Selected set of bitmap fonts
Requires(pre): fontconfig
BuildRequires: xorg-x11-font-utils
+BuildRequires: fontpackages-devel
%description
-The bitmap-fonts package provides a number of bitmap fonts selected
-from the xorg package designed for use locations such as
-terminals.
+%common_desc
+
+%package common
+Summary: Common files for bitmap-fonts
+Requires: fontpackages-filesystem
-%package cjk
+%description common
+%common_desc
+
+This package consists of files used by other %{name} packages.
+
+%_font_pkg lut* con* [0-9]*
+
+%package -n bitmap-cjk-fonts
Summary: Selected CJK bitmap fonts for Anaconda
Group: Applications/System
Requires(pre): fontconfig
+Requires: %{name}-common = %{version}-%{release}
+Provides: %{name}-cjk = %{version}-%{release}
-%description cjk
+%description -n %{fontname}-cjk-fonts
bitmap-fonts-cjk package contains bitmap fonts used by Anaconda. They are
selected from the xorg packages, and the font encoding are converted from
native encoding to ISO10646. They are only intended to be used in Anaconda.
+%_font_pkg -n cjk fangsongti*
+
%prep
%setup -q -a 1
+
%install
rm -rf $RPM_BUILD_ROOT
@@ -38,44 +59,25 @@ cd fixfont-3.5
make install DESTDIR=$RPM_BUILD_ROOT
+mv $RPM_BUILD_ROOT/usr/share/fonts/bitmap-fonts %{buildroot}%{_fontdir}
+
+#install -m 0755 -d %{buildroot}%{_fontdir}
+
# %%ghost the fonts.cache-1 file
-touch $RPM_BUILD_ROOT%{_datadir}/fonts/bitmap-fonts/fonts.cache-1
+#touch $RPM_BUILD_ROOT%{_datadir}/fonts/bitmap-fonts/fonts.cache-1
%clean
rm -rf $RPM_BUILD_ROOT
-%post
-fc-cache %{_datadir}/fonts
-
-%postun
-if [ $1 = 0 ]; then
- fc-cache %{_datadir}/fonts
-fi
-
-%post cjk
-fc-cache %{_datadir}/fonts
-
-%postun cjk
-if [ $1 = 0 ]; then
- fc-cache %{_datadir}/fonts
-fi
-
-%files
+%files common
%defattr(-,root,root)
%doc README LU_LEGALNOTICE
-%dir %{_datadir}/fonts/bitmap-fonts
-%{_datadir}/fonts/bitmap-fonts/lut*
-%{_datadir}/fonts/bitmap-fonts/con*
-%{_datadir}/fonts/bitmap-fonts/[0-9]*
-%ghost %{_datadir}/fonts/bitmap-fonts/fonts.cache-1
-
-%files cjk
-%defattr(-,root,root)
-%dir %{_datadir}/fonts/bitmap-fonts
-%{_datadir}/fonts/bitmap-fonts/fangsongti*
-%ghost %{_datadir}/fonts/bitmap-fonts/fonts.cache-1
%changelog
+* Wed Sep 30 2009 Pravin Satpute psatp...@redhat.com - 0.3-9
+- updating as per new packaging guidelines
+- bugfix 481068
+
* Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Issue 64671] Verdana font messes up letter spacing in Impress
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64671 User dtardon changed the following: What|Old value |New value Issue type|DEFECT|PATCH - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 525498] wrongly encoded glyphs after U+10000
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=525498 --- Comment #2 from Denis Jacquerye moy...@gmail.com 2009-09-30 04:28:18 EDT --- Created an attachment (id=363148) -- (https://bugzilla.redhat.com/attachment.cgi?id=363148) path reajusting encodings The patch does several things: - clears duplicates of .notdef, .null and nonmarkingreturn - renames the out-of-bound glyphs to previous names - adjusts glyph id and references. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 225617] Merge Review: bitmap-fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225617 --- Comment #15 from Pravin Satpute psatp...@redhat.com 2009-09-30 07:18:47 EDT --- also as commented by Jens in comment #11 IMO we should plan from that direction also, otherwise it looks bad two Packages providing same Set of Fonts -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 461617] modified Sazanami-Gothic font showing vertical text rendering glitches not seen in the original
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=461617 Caolan McNamara caol...@redhat.com changed: What|Removed |Added CC||caol...@redhat.com Component|sazanami-fonts |openoffice.org Version|10 |rawhide AssignedTo|ta...@redhat.com|caol...@redhat.com --- Comment #15 from Caolan McNamara caol...@redhat.com 2009-09-30 07:46:47 EDT --- I'm now back to very suspicious about OOo itself. Both fontforge and ttx are preferring the type 2 coverage format when saving this font as its more compact in this case that the original fonts type 1 coverage table. Presuming that both ttx and fontforge are re-encoding as type 2 correctly then it would be OOo that's handling them incorrectly. http://www.microsoft.com/typography/otspec/CHAPTER2.htm has Coverage Index (GlyphID) = StartCoverageIndex + GlyphID - Start GlyphID which *plausibly* is somewhere we're going wrong. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 461617] modified Sazanami-Gothic font showing vertical text rendering glitches not seen in the original
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=461617 Caolan McNamara caol...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #16 from Caolan McNamara caol...@redhat.com 2009-09-30 10:04:59 EDT --- I think I have this as a bug in OOo after all :-) It'd probably be a good idea if we were to use ttx to build our modified font so that we could take the original source and made the modifications during our build process to make it transparent what the changes are being made. I might play around with that as a separate thing. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 526058] Review Request: sil-scheherazade-fonts - SIL Scheherazade Arabic Script Unicode Font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526058 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@fedoraproject.org|nicolas.mail...@laposte.net Flag||fedora-review?, ||needinfo?(heda...@grad.com) --- Comment #2 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-09-30 17:14:53 EDT --- Thanks for looking at this font! SIL fonts are usually high quality, it's a shame we do not package all of them yet like other distros do (hint hint) Package review: 1. current best practice is to avoid using the package name in the summary, please reword it without SIL Scheherazade (I know it was not always like this, and we haven't changed evey previous package yet). The reason is that package tools already display the package name next to the summary 2. (minor) you don't really have to use Caps Before Every Word (though that's a matter of preference) 3. (minor) I'm not sure it's a good idea to include your second description §. All this technical mumbo-jumbo is likely to frighten normal users 4. it's not a good idea to depend on dos2unix for txt file conversion, you can usually attain the same results using just sed and iconv. Your package does not build as a result in mock, since dos2unix is not present in the buildroot + dos2unix FONTLOG.txt OFL-FAQ.txt OFL.txt /var/tmp/rpm-tmp.BzkuMA: line 29: dos2unix: command not found http://fedoraproject.org/wiki/Packaging_tricks#Convert_encoding_to_UTF-8 If you intend to maintain more packages later it's a good idea to setup a mock instance on your system to test for this kind of mistake http://fedoraproject.org/wiki/Projects/Mock 5. And lastly, please add some fontconfig rules. Just the default set + Monotype Naskh should be enough, unless there is something else you feel would help users. You have standard templates and documentation in fontpackages-devel (though the F11 version may be a little old, install the latest one it will work just fine in F11 too) http://koji.fedoraproject.org/koji/packageinfo?packageID=7288 And that's all for now NEEDINFO till you answer those (PS if you're not member of the packaging group yet, I can sponsor you, but I'll require 2-3 good font package submissions before; we've streamlined the process so much a single submission is not enough to judge if someone will become a good packager anymore) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 512079] Review Request: oflb-prociono-fonts - A serif font created by Barry Schwartz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=512079 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added Flag||needinfo?(tcall...@redhat.c ||om) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 512079] Review Request: oflb-prociono-fonts - A serif font created by Barry Schwartz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=512079 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added CC||tcall...@redhat.com Blocks|182235(FE-Legal)| Flag|needinfo?(tcall...@redhat.c | |om) | --- Comment #6 from Tom spot Callaway tcall...@redhat.com 2009-09-30 17:27:26 EDT --- Public Domain declaration in the license looks fine. Lifting FE-Legal. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 512079] Review Request: oflb-prociono-fonts - A serif font created by Barry Schwartz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=512079 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added AssignedTo|nicolas.mail...@laposte.net |sanjay.an...@gmail.com Flag|fedora-review? |fedora-review+ --- Comment #7 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-09-30 17:34:05 EDT --- Therefore, this package is now ⴕⴕⴕ APPROVED ⴕⴕⴕ You can now continue from http://fedoraproject.org/wiki/Font_package_lifecycle#3.a Thank you for packaging another font in Fedora -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 225617] Merge Review: bitmap-fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225617 --- Comment #16 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-09-30 18:40:37 EDT --- I need to look at it some more (got distracted by other bug requests, and this is a complex package), however here are some remarks 1. rpm will evaluate your %global even with # (why did you want to comment it out?) 2. common_desc should be a global too 3. your -fixed subpackage contains font files that declare themselves as Console. These should go in a console subpackage 4. not too sure if it'd be better to move console8x8 in its own subpackage or just rename or remap it (cf remapping template) 5. You can drop the duplicated Group: Applications/System lines, the main one will be inherited in modern rpm 6. why do you add a Requires(pre): fontconfig ? We do not require fontconfig in font packages. Do you have a special need? 7. what do you need xorg-x11-font-utils as BR for ? 8. I think you can specify a different LICENSE field per subpackage, can you check with spot how he'd prefer the licensing reported ? (mixed licensing packages are a PITA) I feel if it'd be better if each subpackage was tagged with just the necessary license info (and included the corresponding license files) 9. fontconfig will happily use pcf.gz files, please compress your pcf files (if you're feeling ambitious ask behdad if he intends to support pcf.xz soon) That's all for this first partial review, will look more in depth tomorrow -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 526607] Review Request: openfontlibrary-smonohand-font - A handwritten monospace font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526607 Michel Alexandre Salim michael.silva...@gmail.com changed: What|Removed |Added CC||fedora-fonts-bugs-l...@redh ||at.com --- Comment #1 from Michel Alexandre Salim michael.silva...@gmail.com 2009-09-30 21:09:00 EDT --- This is my first font package, so please be very thorough. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 525498] wrongly encoded glyphs after U+10000
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=525498 --- Comment #3 from Caius 'kaio' Chance ccha...@redhat.com 2009-09-30 21:31:53 EDT --- Thanks Denis. Is this patch a proper fix which maintain closer quality with the original TTF delivered from Ascender? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 526607] Review Request: openfontlibrary-smonohand-font - A handwritten monospace font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526607 Michel Alexandre Salim michael.silva...@gmail.com changed: What|Removed |Added URL||https://fedoraproject.org/w ||iki/SMonohand_Fonts -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 512079] Review Request: oflb-prociono-fonts - A serif font created by Barry Schwartz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=512079 Ankur Sinha sanjay.an...@gmail.com changed: What|Removed |Added Flag||fedora-cvs? --- Comment #8 from Ankur Sinha sanjay.an...@gmail.com 2009-10-01 00:58:50 EDT --- New Package CVS Request === Package Name: oflb-prociono-fonts Short Description: A text roman with standard and discretionary ligatures, class-based kerning Owners: ankursinha Branches: F-10 F-11 InitialCC: fonts-sig -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: bitmap-fonts by default?
Le Mer 30 septembre 2009 16:35, Qianqian Fang a écrit : Jens Petersen wrote: We have been looking at updating bitmap-fonts recently, and noticed that it is still listed mandatory in the comps @base-x group. So I just wondered a couple of naive questions: - does bitmap-fonts have to be installed by default? - what actually needs it? anything before X may still need bitmap fonts, don't they? The problem is, we have a lot of stuff installed by default in base-x because something may use it (even though no one actually checked that was still the case). IMHO default packages in default groups should have a clear user, or be downgraded to optional. -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: bitmap-fonts by default?
IMHO default packages in default groups should have a clear user, or be downgraded to optional. Right I suggest we make it optional in comps-f13 and see if anything breaks. Jens ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Self-introduction, and review request
Hello all, I've been a Fedora packager for several years, mostly focusing on programming language and desktop packages, but have never dabbled at packaging fonts until now. Here's the review request -- for Comic Sans haters, this is Máirín's idea, I'm just the .. err.. perpetrator! Review Request: openfontlibrary-smonohand-font - A handwritten monospace font https://bugzilla.redhat.com/show_bug.cgi?id=526607 Please be thorough -- I'm probably breaking several rules I'm not even aware of. Best Regards, -- Michel Alexandre Salim ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: bitmap-fonts by default?
2009/10/1 Jens Petersen peter...@redhat.com IMHO default packages in default groups should have a clear user, or be downgraded to optional. Right I suggest we make it optional in comps-f13 and see if anything breaks. Yep, this looks nice In merge review of bitmap-fonts, we are splitting it as per font family we will get sufficient time to come at conclusion, which to keep default and which optional Thanks Regards, -- Pravin Satpute ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Blogs site?
On Wed, Sep 30, 2009 at 1:34 AM, Mike McGrath wrote: Whats the status of the blogs site? Is it ready to go? People want to use it :) Where are the directions? Hello Mike, I've just signed up. It seems that with trial to log in with my FAS credentials, I got a big fat: Not Found The requested URL /wp/http://blogs.fedoraproject.org/wp/wp-signup.php was not found on this server. I had to apply the url manually http://blogs.fedoraproject.org/wp/wp-signup.php in order to create a blog. Cheers, Chitlesh ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
