[ANNOUNCEMENT] Red Hat Bugzilla 3.4 Upgrade Public Beta
Greetings, I am sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Fedora uses this instance of bugzilla too. Please forward this on to any appropriate lists that were missed. Thanks, James == Greetings, The Red Hat Bugzilla team is happy to announce the first public beta release of the next version of Red Hat Bugzilla based on the upstream 3.4 code base. Please test drive at: https://partner-bugzilla.redhat.com Over the years Red Hat has made substantial customizations to Bugzilla to fit into the Engineering tool chain. Over time the upstream has incorporated some of these customizations or solved them in different ways. Upgrading reduces our customization footprint (and thus maintenance) while bringing many bug fixes & enhancements. The main area of focus for our public betas are stability. Functionality that currently works in our 3.2 code base should continue to work as expected in the new 3.4 release. These include various ajax optimizations, needinfo actor support, frontpage.cgi, product browser, several various UI enhancements, and of course the XMLRPC API. Please feel free to point your various scripts and third party applications that use the XMLRPC API at the test server to make sure they continue to function properly. There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 3.2 is possible in the new system. There are also numerous new features/fixes that are part of the upstream 3.4 release. For more detailed information on what has changed since the last release, check out the Release Notes page. The database is a recent snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Also with a full snapshot it is possible to test for any performance related issues. Email has been disabled so that unnecessary spam is not sent out. So feel free to make changes to bugs to verify proper working order. We are asking for everyone to get involved as much as possible with testing and feedback on the beta releases to help us make this the most robust and stable release possible. Please file any enhancement requests or bug reports in our current Bugzilla system at bugzilla.redhat.com. File them under the Bugzilla product and relevant component with the version 3.4. With everyone's help we can make this a great release. Thanks The Red Hat Bugzilla Team ___ 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
UPDATE: Final F-10 updates push date revised
On Tue, Nov 24, 2009 at 08:31:35PM -0500, Josh Boyer wrote: >Hi All, > >Fedora 10 will go EOL on December 17th. The final day for >updates to be submitted will be December 14th. Please make >sure any final updates you want pushed to the F10 repos are >submitted by this date. Due to the infrastructure outage that has been scheduled for this timeframe, the final F10 updates push has now been rescheduled for December 11th, 2009. Please make sure any final updates you want pushed to the F10 repos are submitted by the revised date of December 11th, 2009. Apologies for the confusion and change in schedule. We will work more closely with the Infrastructure team in the future to avoid a similar situation. josh ___ 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: Proposed F13 feature: drop separate updates repository
On 12/05/2009 06:22 AM, Orion Poplawski wrote: On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: Yes, for people who are doing "full featured networked installs" w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. OK, then it's likely a "full time" professional admins vs. "part time"/"side-job" admins and "home-users" thing. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: > On 12/03/2009 07:22 AM, Jesse Keating wrote: >> On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: >>> Yes, for people who are doing "full featured networked installs" w/ >>> custom kickstart files. I've never met such a person. >> >> Really? I meet people who use kickstart all the time. > May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. In fact - every "upgrade" is a fresh kickstart install + restore critical files from backup. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler wrote: > Mathieu Bridon (bochecha) wrote: > > How about visually impaired people? Compiz and the zoom plugin *are* > > essential to them. > > They can use the plain old KMag which doesn't require any sort of > compositing at all. > >Kevin Kofler > > But why? And if you didn't install KDE, I doubt you would have KMag installed. And all the dependencies that get pulled in for installing a single KDE app is ridiculous. Plus, Compiz and the zoom plugin are smoother and more effective than KMag. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing "full featured networked installs" w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. No, I didn't. It's just that unless this "little check button" is the default, many users will ignore it or as in my case ... I am normally "yum-upgrading" between distros and rarely use anaconda. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, Where? Unlike now, where you have each package twice (in Everything and "updates"), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, Correct. which as noted in other parts of this thread gets complicated with GPL compliance. Not necessarily - E.g. it would be GPL compliant to store "purged packages" outside of the "current" repos. And whether "spins" and the way they currently are implemented is "good"/"feasible"/"reasonable" is a different question. => An estimate for the increase in downloaded files's sizes you are talking about is ca. factor 2, from 18.2M (current "updates") to 32.8M+ (current "Everything"+"newly introduced packages) Whether this increase in download-size is "significant" is up to the beholder. For me, it gets lost in the noise of accessing a "good" or a "bad" connection to a mirror and in the time required to download packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. Yes, but ... some more figures: The same figures as above for FC10: => Everything: 25.8M => updates: 18.5M => A rough estimate for sizes of repodata for a "near EOL'ed" Fedora: 70% of the size of "Everything's repodata". I.e. should this estimate apply to later Fedoras, Fedora 11 users are likely to see 70% of 33MB = 23MB near EOL of Fedora 11. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. Yes, the keys to minimize bandwidth demands would be * to shink the size of the repodata/-files * to shink the size of "changes" to them. Besides obvious solutions, such as using a different compression (e.g. xz instead of bz2) and minimizing their contents, one could ship repodata/-files in "chunks". What I mean: In theory, one could * update repodata/-files incrementally by shipping some kind of "deltas". * split repodata/-files into several, e.g. sorted by "some other criteria", i.e. to provide several sets of *-[primary,filelist,other] files. One "package push", then would only affect a subset of the files, but not all. - This is very similar to what (IIRC) Seth had proposed (Split the repo into several repos, alphabetically), except that the "split" would happen inside of repodata and thus be transparent to users. I am not sure how difficult to implement this would be. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
Mathieu Bridon (bochecha) wrote: > How about visually impaired people? Compiz and the zoom plugin *are* > essential to them. They can use the plain old KMag which doesn't require any sort of compositing at all. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
On Fri, 2009-12-04 at 16:45 -0500, Bill Nottingham wrote: > Miroslav Lichvar (mlich...@redhat.com) said: > > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > > > The features highlight list has: > > Communication with the init daemon over D-Bus. > > > > > Questions? Comments? > > > > Does this mean that running dbus will be required to reboot/shutdown > > the system? > > No. The init daemon speaks the dbus protocol, and can be communicated > with over the system daemon. But it can also be talked to directly. Looking at upstart-0.6.3-3.fc13.src.rpm, the specfile includes /sbin/shutdown etc. ... and looking at the tarball those seem to come from util/*.c. Which AFAICS require DBus to work. Also given that init now listens and is controlled by DBus, has anyone done any analysis of how resistant DBus services are to DOS attacks? -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
> Why aren't the sysVinit scripts being ported over to native upstart scripts? > I thought the reason why upstart was adopted was to be able to utilize the > benefits of native upstart scripts (event based daemon handling, etc.)? No one is holding you back from starting to convert them now, but the format is most probably going to change again till the 1.0 release. Happy porting to you. ;) kind regards, Rudolf Kastl > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
On Fri, Dec 4, 2009 at 3:45 PM, Bill Nottingham wrote: > Miroslav Lichvar (mlich...@redhat.com) said: > > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > > > The features highlight list has: > > Communication with the init daemon over D-Bus. > > > > > Questions? Comments? > > > > Does this mean that running dbus will be required to reboot/shutdown > > the system? > > No. The init daemon speaks the dbus protocol, and can be communicated > with over the system daemon. But it can also be talked to directly. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Why aren't the sysVinit scripts being ported over to native upstart scripts? I thought the reason why upstart was adopted was to be able to utilize the benefits of native upstart scripts (event based daemon handling, etc.)? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
Miroslav Lichvar (mlich...@redhat.com) said: > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > The features highlight list has: > Communication with the init daemon over D-Bus. > > > Questions? Comments? > > Does this mean that running dbus will be required to reboot/shutdown > the system? No. The init daemon speaks the dbus protocol, and can be communicated with over the system daemon. But it can also be talked to directly. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > https://fedoraproject.org/wiki/Features/Upstart0.6.0 The features highlight list has: Communication with the init daemon over D-Bus. > Questions? Comments? Does this mean that running dbus will be required to reboot/shutdown the system? -- Miroslav Lichvar -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
Bill Nottingham (nott...@redhat.com) said: > Obvious FAQ: > > Q: Should we port our SysV scripts to native upstart scripts? > > A: No, not at this time. Q: I'd like to play with it before it lands. A: There's a repo at http://notting.fedorapeople.org/upstart0.6/. You can also check the new upstart package out of devel/ CVS, and the initscripts changes out of the upstart-0.6.0-branch in initscripts git. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Upstart 0.6.3 coming to a rawhide near you
https://fedoraproject.org/wiki/Features/Upstart0.6.0 was approved at today's FESCo meeting. We hope to land this in the next week or so. What this means for you (for very specific values of you): If you own any of the following packages, you have upstart job files that will need modified for any needed format changes, and the new location. * vpnc rjones * ConsoleKitmccann * clamavensc * dhcp-forwarderensc * hdapsdttorcz * ip-sentinel ensc * milter-greylist ensc * olpc-utilspbrobinson * tor ensc We're willing to do the legwork for you, or you can do the update yourself once we land 0.6.x; give us a reply with which you'd prefer. See the feature page for more details on the changes required. What this means for you (for very general values of you): Once it lands, it's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. We can investigate adding some compat code to ease this, if people would really prefer. Once you reboot, things should work pretty much the same. Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Questions? Comments? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On Fri, 2009-12-04 at 10:55 -0800, Dan Williams wrote: > On Wed, 2009-12-02 at 16:52 -0500, Bill Nottingham wrote: > > Dan Williams (d...@redhat.com) said: > > > > ONBOOT=yes > > > > BOOTPROTO=dhcp > > > > TYPE=Wireless > > > > NM_CONTROLLED=yes > > > > USERCTL=yes > > > > PEERDNS=yes > > > > IPV6INIT=no > > > > MODE=Auto > > > > > > This is the problem. "Auto" is not a valid mode. > > > > It's a valid mode according to the iwconfig man page. I have no idea > > what cards actually support it. > > Oh, probably none. I'll go fix ifcfg-rh to alias "Auto" to > infrastructure mode. 96a61a9909c9442aa5f1c14d89dbd3356d4715f1 (master) 090eeaff16c77f4db4454de39d6d4e76d5390443 (0.7.x) Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: > > People doing network installs can either add the updates repo to their > > kickstart, or check the box in the anaconda UI, so that the updates > > repos are considered at install time. No download of duplicate data. > Yes, for people who are doing "full featured networked installs" w/ > custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. > > > In fact, having separate repos would likely cost less bandwidth. If we > > only had one combined repo, there would be many duplicate packages, > Where? Unlike now, where you have each package twice (in Everything and > "updates"), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, which as noted in other parts of this thread gets complicated with GPL compliance. > > It would help people like me, who are locally reusing downloaded > packages in a networked environment, instead of letting each machine > accesses the original repos directly. Surely a caching proxy server doesn't care what folder a file comes from, it'll cache it. Whether the new file shows up in Everything/ or the new file shows up in updates/ shouldn't matter. > > > especially if we went the route of having updates-testing mixed in and > > only marked by some update tag. > Updates-testing is an add-on repo to "Everything+updates". > > A merged new Everything would not change anything wrt. > "updates-testing". The only difference would be packages being pushed to > "Everything" instead of "updates". > > > We'd have to keep sets of what's in > > updates-testing, updates, and the GA release set, and all of that would > > be in one repodata set. Everybody doing a network install, whether they > > wanted updates, updates-testing, or not would have to download and > > consume that larger repodata, introducing a higher cost for them. > Your concern is the bigger repodata? > > Reality check: > # ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2 > updates/11/x86_64/repodata/*.sqlite.bz2 > > 16M > releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2 > 11M > releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2 > 5.8M > releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2 > > 9.0M > updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2 > 6.0M > updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2 > 3.2M > updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2 > > => An estimate for the increase in downloaded files's sizes you are > talking about is ca. factor 2, from 18.2M (current "updates") > to 32.8M+ (current "Everything"+"newly introduced packages) > > > Whether this increase in download-size is "significant" is up to the > beholder. For me, it gets lost in the noise of accessing a "good" or a > "bad" connection to a mirror and in the time required to download > packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. -- 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: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 06:51 +0100, Ralf Corsepius wrote: > > We wouldn't be talking about removing the original GA set - just adding > > updated pkgs into the path. > > Woa!!! With all due respect, but this would seem an stupid and silly > plan to me. The only way not to do that would be to maintain yet another directory of packages that matches the GA set, for GPL compliance. Now we're just getting silly. -- 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: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On Wed, 2009-12-02 at 16:52 -0500, Bill Nottingham wrote: > Dan Williams (d...@redhat.com) said: > > > ONBOOT=yes > > > BOOTPROTO=dhcp > > > TYPE=Wireless > > > NM_CONTROLLED=yes > > > USERCTL=yes > > > PEERDNS=yes > > > IPV6INIT=no > > > MODE=Auto > > > > This is the problem. "Auto" is not a valid mode. > > It's a valid mode according to the iwconfig man page. I have no idea > what cards actually support it. Oh, probably none. I'll go fix ifcfg-rh to alias "Auto" to infrastructure mode. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 2009-12-04
=== #fedora-meeting: FESCo meeting 20091204 === Meeting started by notting at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-12-04/fesco.2009-12-04-17.00.log.html . Meeting summary --- * ACTION: notting will close out ticket 274 (notting, 17:04:23) * F13 schedule (notting, 17:04:38) * AGREED: F13 schedule as proposed is accepted. (notting, 17:10:39) * Feature Intellij IDEA (notting, 17:11:51) * LINK: http://www.jetbrains.com/idea/nextversion/editions_comparison_matrix.html (Kevin_Kofler, 17:15:54) * ACTION: this was already accepted at the 2009-11-20 meeting (notting, 17:20:03) * Feature - Better Hostname (notting, 17:22:47) * ACTION: discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page (notting, 17:33:21) * Feature - User Account Dialog (notting, 17:33:35) * ACTION: User Account Dialog feature has been accepted for F13 (notting, 17:38:37) * Feature - Copy/Paste Just Works (notting, 17:38:56) * ACTION: CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. (notting, 17:44:30) * ACTION: correction: Fedora 13 (notting, 17:45:18) * Feature - Upstart 0.6.x (notting, 17:45:49) * ACTION: Upstart 0.6.x has been accepted as a Fedora 13 feature (notting, 17:50:08) * Feature - NetBeans 6.8 (notting, 17:50:24) * ACTION: NetBeans 6.8 feature has been approved for Fedora 13 (notting, 17:54:30) * Feature - RPM 4.8 (notting, 17:54:45) * ACTION: RPM 4.8 has been accepted as a Fedora 13 feature (notting, 17:57:58) * Feature - Rollback with BTRFS (notting, 17:58:11) * AGREED: Rollback with BTRFS has been approved as a F13 feature (notting, 18:17:54) * Open floor (notting, 18:18:43) * FPC report (notting, 18:20:11) * AGREED: pkgconfig guideline change approved (notting, 18:22:59) * Emacs Packaging (notting, 18:23:09) * AGREED: Emacs guideline change approved (notting, 18:24:57) * PHP guidelines revised (notting, 18:25:30) * AGREED: PHP guideline revision approved. (notting, 18:29:17) * Open floor (notting, 18:29:25) Meeting ended at 18:33:36 UTC. Action Items * notting will close out ticket 274 * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature Action Items, by person --- * notting * notting will close out ticket 274 * sk * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * **UNASSIGNED** * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature People Present (lines said) --- * notting (118) * Kevin_Kofler (60) * nirik (56) * dwmw2 (38) * cjb (19) * josef (17) * sharkcz (17) * zodbot (15) * tibbs|h (12) * sadmac (3) * mjg59 (1) * miniperl (1) * skvidal (0) * j-rod (0) * sk (0) * jds2001 (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Behdad Esfahbod wrote: > Since the patents covering the TrueType bytecode interpreter expired at > the end of October, I've now built FreeType in rawhide with that part of > code enabled. IMHO, if we want to ship this by default, we really need to fix FreeType for the case where the font doesn't provide hinting bytecode. AFAICT, currently, in that case, if FreeType is built with the BCI enabled, it won't do any hinting at all. See e.g. the CJK characters in the screenshot by Martin Sourada at: http://2.bp.blogspot.com/_lh41g82r7rk/SuWk7rqgaJI/AQ8/AfWQU9yAHu8/s1600-h/mark-the-difference.png (the first line is no antialiasing, no hinting, the second one is antialiasing only, the third one is antialiasing+hinting and the last one is antialiasing+hinting with forced autohinter) from: http://mso-chronicles.blogspot.com/2009/10/mark-difference-ugly-fonts-in-fedora.html It should fall back to the autohinter when the font does not provide hinting bytecode. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Matěj Cepl wrote: > can we hope for the update in F12 as well, please? Well, that would change the looks of our default DejaVu fonts a lot. (freetype-freeworld currently disables the BCI for the DejaVu family by default for that reason, which has always been a controversial move, I'll of course stop doing that from F13 on.) I'm not convinced this is a good idea to ship as an update. >> Note that the subpixel stuff remains disabled as it was. > > What does this exactly mean? If I have freetype-freeworld installed can > I get rid of it now (well, when this comes to F12)? If you need subpixel antialiasing, no. I will continue to build freetype- freeworld packages for the subpixel stuff. > Will we have also cairo and pango (whichever is relevant) upgraded to use > it? "It" as in subpixel rendering? There have been patches to Cairo to use the FreeType subpixel filters, they even remove some probably patent-encumbered code (dumb subpixel filters) from Cairo itself, but still they haven't been accepted yet. :-( As FreeType always provides the relevant APIs, just implemented as dummies which always return an error, it's perfectly possible to make the decision whether to use freetype-freeworld's subpixel filters at runtime (e.g. Qt 4 does that). As for the BCI, it should need no special support from Cairo nor Pango. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Hans Ulrich Niedermann (h...@n-dimensional.de) said: > > > The big issue is with KMS on using radeonhd is like shooting > > > yourself in the face. Either we need to patch radeonhd in Fedora to > > > not start with KMS enabled or remove it from the distro. > > > > I am working on such a patch to radeonhd right now. > > The patch has been finished and has been tested on my system. > > Packages with the patch have been built and are both in rawhide and on > their way towards updates-testing/ and updates/ for F11 and F12 > (xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc*). Cool. Objection withdrawn. :) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Finally! It was like a non-ending movie through all these years, having such one essential/basic feature disabled. An update for F12, whenever it gets ready, would be really welcome! > Given how any font rendering changes seems to degrade font rendering for some The TrueType bytecode interpreter really makes the difference. -Ilyes On Fri, Dec 4, 2009 at 2:49 PM, Nicolas Mailhot wrote: > > > Le Ven 4 décembre 2009 13:50, Matěj Cepl a écrit : > > > > Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): > >> Since the patents covering the TrueType bytecode interpreter expired at > >> the end of October, I've now built FreeType in rawhide with that part of > >> code enabled. > > > > can we hope for the update in F12 as well, please? > > Given how any font rendering changes seems to degrade font rendering for > some > users, I'd very much prefer it went through a full release testing cycle > before hitting unsuspecting users. > > -- > Nicolas Mailhot > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning gnome-common
On Fri, 2009-12-04 at 05:39 -0800, Toshio Kuratomi wrote: > This is a heads up that I'm going to orphan gnome-common. I don't do any > gtk programming anymore so it doesn't make sense for me to keep this > package. mclasen has done several of the recently needed updates to this > package; if he and the desktop team would like to take it over let me know; > I'll do the packagedb magic to hand it over to them. I'll find someone to own it, probably not before fudcon though... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Le Ven 4 décembre 2009 13:50, Matěj Cepl a écrit : > > Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): >> Since the patents covering the TrueType bytecode interpreter expired at >> the end of October, I've now built FreeType in rawhide with that part of >> code enabled. > > can we hope for the update in F12 as well, please? Given how any font rendering changes seems to degrade font rendering for some users, I'd very much prefer it went through a full release testing cycle before hitting unsuspecting users. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning gnome-common
This is a heads up that I'm going to orphan gnome-common. I don't do any gtk programming anymore so it doesn't make sense for me to keep this package. mclasen has done several of the recently needed updates to this package; if he and the desktop team would like to take it over let me know; I'll do the packagedb magic to hand it over to them. -Toshio pgpIAog1FpZ8K.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): > Since the patents covering the TrueType bytecode interpreter expired at > the end of October, I've now built FreeType in rawhide with that part of > code enabled. can we hope for the update in F12 as well, please? > Note that the subpixel stuff remains disabled as it was. What does this exactly mean? If I have freetype-freeworld installed can I get rid of it now (well, when this comes to F12)? Will we have also cairo and pango (whichever is relevant) upgraded to use it? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He can compress the most words into the smallest idea of any man I know. -- Abraham Lincoln -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning some packages...
I'd like to turn over the following packages to someone else to maintain since I have no time or interest in keeping up with them going forward: * rubygem-activeldap -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpy8XPHDlZtn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
On Fri, Dec 04, 2009 at 07:04:12AM -0200, Itamar Reis Peixoto wrote: >> - glibc32, glibc64 (dead packages?) >yes No. They are needed in the build system. They just havent been updated since FC6 or so. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
On Fri, 04 Dec 2009 09:57:47 +0100, Panu Matilainen wrote:
> handful of package still using %{PACKAGE_VERSION} and
> %{PACKAGE_RELEASE} macros.
...
> - libunwind
Fixed:
libunwind-0.99-0.13.20090430betagit4b8404d1.fc13
Jan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
On Fri, Dec 4, 2009 at 6:57 AM, Panu Matilainen
wrote:
>
> Grepping through spec files from CVS devel/ shows there are a handful of
> package still using %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} macros. These
> were considered "backwards compatibility stuff" in 1998 (yes, eleven years
> ago) already, please change them to use the %{version} and %{release} macros
> instead.
>
> The packages using these ancient macros are:
> - kernel
> - kernel-xen-2.6 (dead package?)
yes
> - glibc32, glibc64 (dead packages?)
yes
> - fmt-ptrn
> - libunwind
>
> Rpm >= 4.8.x removes the support for the ancient %{PACKAGE_*} macros so
> packages still using them will fail to build with it.
>
> - Panu -
>
I think a proven packager or someone with chuck norris power can fix
the other's packager's
--
Itamar Reis Peixoto
e-mail/msn/google talk/sip: ita...@ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
Grepping through spec files from CVS devel/ shows there are a handful of
package still using %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} macros.
These were considered "backwards compatibility stuff" in 1998 (yes, eleven
years ago) already, please change them to use the %{version} and
%{release} macros instead.
The packages using these ancient macros are:
- kernel
- kernel-xen-2.6 (dead package?)
- glibc32, glibc64 (dead packages?)
- fmt-ptrn
- libunwind
Rpm >= 4.8.x removes the support for the ancient %{PACKAGE_*} macros so
packages still using them will fail to build with it.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
