Re: [gentoo-dev] The Plethora of Patches
Andrew D Kirch wrote: Obviously the software needs to work, and therefore we need patches, but Gentoo has not done enough to date to get them pushed upstream. Lets look at some cringeworthy statistics on outstanding patches. Have you even _looked_ at the patches? Can you tell which ones are : - backports? - Gentoo-specific (for build issues)? - shared with other distros? Did you count the patches we apply because upstream is either dead, unresponsive or downright wrong? Yes, we have a lot of patches, but then again, we have a lot of open bugs too. I, for one, am much more worried about the latter. Please back this up with _real_ statistics. Thanks Rémi
Re: [gentoo-dev] The Plethora of Patches
On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: [...] Looks like you counted the number of files in the files/ subdirectories. Not all of these are patches. Also, you probably forgot to count seds, as some of us use sed more than patches. Oh, and like Jeremy was hinting, please contact QA. They need somebody like you. Denis.
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On 14:12 Fri 01 Aug , Ferris McCormick wrote: Required ethical disclaimer: I provide this only for information. It is not a legal opinion, nor am I qualified to give a legal opinion on international privacy laws. I will go so far as to say that the Freenode privacy statement looks as if it was drafted by a lawyer to ensure Freenode's users that (to quote): PDPC will not publish that information or provide it to any other third party without your explicit permission, except as required by law or as appropriate in the course of an investigation of criminal wrongdoing. PDPC will make a good faith effort to maintain the privacy of your personal information. Thus they are exposed to a law suit if they provide the information I think you are asking for. (Privacy policy at: http://freenode.net/group_privacy.shtml ) The only thing I have to add to this is the missing context. This policy applies only to contact information: PDPC may provide your personal or group contact information to its volunteers, employees or contractors, solely to allow them to contact you on its behalf or to verify the accuracy of the group or personal information you provide. PDPC will not publish that information or provide it to any other third party without your explicit permission, except as required by law or as appropriate in the course of an investigation of criminal wrongdoing. PDPC will make a good faith effort to maintain the privacy of your personal information. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpgsH7O1ejCa.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On 23:17 Thu 31 Jul , Donnie Berkholz wrote: This is your friendly reminder! Same bat time (typically the 2nd/4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Here's a rough agenda. I'll hash it out a bit more a few hours in advance of the meeting. Basically, council members haven't responded to these items on the mailing list, and that's what needs to happen. Ferris, I didn't list the CoC enforcement topic because as you suggest, there are lots of open questions. Perhaps we can spice up the thread on -council again. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com New topics == Reactions to dev banned from freenode - rane: I'd like to ask Council to discuss possible reactions to our developer being banned from Freenode without providing us with a reason. ... It would be good if Council officially protested against that ban and demanded a detailed explanation from Freenode staff. Moving meetings to a location we control rane: I want Council to consider moving their meetings somewhere where third parties can't control who in Gentoo can attend and who can't. Like our own small and created just for this purpose IRC server. Favor irc.gentoo.org alias in docs, etc --- rane: I want Council to consider creating and using irc.gentoo.org alias instead of irc.freenode.net in our docs, news items and so on. The alias would allow us to move out of the network more easily should we ever decide to do so. Why aren't fired developers banned from the channels where they displayed this behavior? --- yngwin: It really baffles me that some developers are forcefully retired for anti-social behavior, but are not consequently banned from the places where they display this behavior, such as our MLs and IRC channels. What good is it to retire developers, but allow them to continue to be disruptive? I would like the Council to decide for a change in our policy on this point. PMS as a draft standard of EAPI 0 - spb: It should be treated as a draft standard, and any deviations from it found in the gentoo tree or package managers should have a bug filed against either the deviator or PMS to resolve the differences. Alternatively, what (specific) changes are required to PMS before such a statement can be made? pgpMBLg7UHR5t.pgp Description: PGP signature
Re: [gentoo-dev] The Plethora of Patches
Andrew D Kirch wrote: [...patches...] Common practice is to work with upstream (if alive) and have the patches merged asap. Nothing _that_ strange IMHO. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Josh Saddler wrote: XML doesn't put a space between the attribute and the closing slash -- XHTML does. Common mistake. Also, use for attributes, rather than '. Nope, both is perfectly legal in XML (and illegal per the GDP coding style, which certainly doesn't apply to metadata.xml) :p. Cheers, -jkt
Re: [gentoo-dev] The Plethora of Patches
On Thu, Aug 14, 2008 at 12:00 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: Jeremy Olexa wrote: Andrew D Kirch wrote: snip all Good points, I take it that you have found a mentor and are becoming a dev to drive this project then? -Jeremy I've spoken in the past with both Elfyn McBratney, and Homer Parker. I have also submitted quite a few ebuilds via the bugs.gentoo.org system. I have decided that I'm pretty much not willing to fight the uphill battle with the red tape that presently exists at Gentoo. I found a problem, and wrote up a pretty sensible, and not difficult to implement solution for a problem that is both negatively affecting the code base Gentoo maintains, the quality of all FOSS code, and that has the potential to embarrass the Gentoo development community. Andrew Ok, well.. If you have extra time available to write up a solution for IMO, a non-issue, then you have time to devote to dev stuff - but, if you don't want to become a dev then I would rather you didn't anyway. Put it this way, maybe some of us have decided that our time could be better used fixing Gentoo than fighting the uphill battle with the red tape that presently exists at $UPSTREAM. It is a two-way street for everyone in the FOSS world. Like I said, I like your points. Personally, I try to submit everything upstream but I only maintain very few ebuilds. I think this is common practice amongst Gentoo devs. List replies preferred. Have a good day, -Jeremy
Re: [gentoo-dev] The Plethora of Patches
On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: Patches in the metadata.xml should have some sort of status tracking for each patch, repoman should flag any that don't, and warn on any that have not been submitted upstream unless the status is signed off on by a herd leader (such as Gentoo specific patches). This would provide visual feedback for users and developers with regard to a pretty important metric on how successful Gentoo is at getting patches pushed back to developers. It was proposed recently to add some standarized headers to all new patches for maintenance purposes. Something like: Source: patch by John Foo, backported from upstream, whatever. Upstream: In revision 245, rejected, foo. Reason: Build system sucks I think that's all we need in order to know how were things when the patch was added and if it needs to be pushed/tracked upstream, removed in the next version of the package, etc. Some of us already put these kind of headers, or at least an URL to upstream bug or a meaningful source of info about the patch. However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On 03:01 Thu 14 Aug , Donnie Berkholz wrote: On 23:17 Thu 31 Jul , Donnie Berkholz wrote: This is your friendly reminder! Same bat time (typically the 2nd/4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Here's a rough agenda. I'll hash it out a bit more a few hours in advance of the meeting. Basically, council members haven't responded to these items on the mailing list, and that's what needs to happen. Ferris, I didn't list the CoC enforcement topic because as you suggest, there are lots of open questions. Perhaps we can spice up the thread on -council again. Also: I opened bugs assigned to [EMAIL PROTECTED] for all the open issues that aren't part of this agenda. These bugs are for tracking status, _not_ for discussion, so please respect that. Please let me know if there's any topics I forgot. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpU2cDXYTJMJ.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On 03:01 Thu 14 Aug , Donnie Berkholz wrote: Here's a rough agenda. I'll hash it out a bit more a few hours in advance of the meeting. Basically, council members haven't responded to these items on the mailing list, and that's what needs to happen. For all of the items below, here's what I suggest we do at the meeting: - Collect any questions/opinions. Don't discuss them here, do that on-list. - Commit to the dates you'll respond to the threads - Should be in the next week, preferably sooner - The assumption is that if you don't respond by then, you're ready to make a decision and have nothing new to add to the discussion Reactions to dev banned from freenode Moving meetings to a location we control Favor irc.gentoo.org alias in docs, etc Why aren't fired developers banned from the channels where they displayed this behavior? PMS as a draft standard of EAPI 0 -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpPAYwYpfI37.pgp Description: PGP signature
Re: [gentoo-dev] The Plethora of Patches
Am Donnerstag, 14. August 2008 17:24:41 schrieb Santiago M. Mola: On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: Patches in the metadata.xml should have some sort of status tracking for each patch, repoman should flag any that don't, and warn on any that have not been submitted upstream unless the status is signed off on by a herd leader (such as Gentoo specific patches). This would provide visual feedback for users and developers with regard to a pretty important metric on how successful Gentoo is at getting patches pushed back to developers. It was proposed recently to add some standarized headers to all new patches for maintenance purposes. Something like: Source: patch by John Foo, backported from upstream, whatever. Upstream: In revision 245, rejected, foo. Reason: Build system sucks I think that's all we need in order to know how were things when the patch was added and if it needs to be pushed/tracked upstream, removed in the next version of the package, etc. Some of us already put these kind of headers, or at least an URL to upstream bug or a meaningful source of info about the patch. However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. i am using the lfs tool to create my patches: http://www.linuxfromscratch.org/patches/downloads/MAINTAINER/lfspatch it creates patches with patch version number: irtrans-irserver-5.11.08-arm_remotes-1.patch and the header it creates looks like this: Submitted By: Mario Fetka (mario-fetka at gmx dot at) Date: 2008-07-18 Initial Package Version: 5.11.08 Origin: me Upstream Status: unknown Description: add back remotes and correct makefile arm dir location i think some rules for patches would be a good thing. i would also suggest naming rules for the patches Mario
Re: [gentoo-dev] Gentoo Council Reminder for August 7
2008/8/14 Donnie Berkholz [EMAIL PROTECTED]: Why aren't fired developers banned from the channels where they displayed this behavior? Isn't this one effectively withdrawn? I asked yngwin which devs he was referring to, and he said there weren't any, so is there anything left to discuss?
[gentoo-dev] imlib/imlib2 useflag inconsistency
Hello everybody, I recently noticed, that there are two imlibs in the tree, media-libs/imlib and media-libs/imlib2. There are also two corresponding useflags, imlib and imlib2, while imlib is a global useflag and imlib2 a local one. At the moment of writing, a total of 48 ebuilds in the tree use one of these flags and none uses both. Many ebuilds use the imlib useflag to enable support for media-libs/imlib2, while only one uses imlib2. The problem is, that the last imlib release is over three years old and it's upstream is dead, so many people might not want to have it, but still want the features they get when compiling apps against imlib2. Here are some statistics: The 48 ebuilds consist of 19 packages. 24 ebuilds do imlib? ( media-libs/imlib2 ) 22 ebuilds do imlib? ( media-libs/imlib ) 1 ebuild does imlib2? ( media-libs/imlib2 ) (x11-misc/fbdesk) 1 ebuild does something completely different ( imlib? ( kde-base/kuickshow ) ) (kde-base/kdegraphics-meta-3.5.9) Possible solutions include: (sorted by necessary effort) 1. Leaving everything like it is (not a real solution) 2. Removing the imlib2 useflag 3. Changing the 24 ebuilds depending on imlib2 to use the imlib2 useflag (and possibly making it a global flag) In my opinion, making imlib2 a global useflag would be the best solution, as it gives users who do not want an ancient unmaintained library a fine grained control over their system. Please discuss! :) Attachments: [1] imlib.txt: ebuilds using imlib for imlib support [2] imlib2.txt: ebuilds using imlib for imlib2 support Greetings from a humble user app-office/magicpoint/magicpoint-1.12a-r1.ebuild app-office/magicpoint/magicpoint-1.13a.ebuild kde-base/kdegraphics/kdegraphics-3.5.9.ebuild media-gfx/gimageview/gimageview-0.2.27-r2.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r4.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r5.ebuild www-client/w3mmee/w3mmee-0.3.2_p24-r6.ebuild x11-misc/wmakerconf/wmakerconf-2.11.ebuild x11-terms/mlterm/mlterm-2.9.3-r1.ebuild x11-terms/mlterm/mlterm-2.9.4.ebuild x11-terms/mlterm/mlterm-2.9.4-r1.ebuild x11-wm/fvwm/fvwm-2.5.18-r1.ebuild x11-wm/fvwm/fvwm-2.5.19.ebuild x11-wm/fvwm/fvwm-2.5.21.ebuild x11-wm/fvwm/fvwm-2.5.25.ebuild x11-wm/fvwm/fvwm-2.5.26.ebuild x11-wm/icewm/icewm-1.2.30.ebuild x11-wm/icewm/icewm-1.2.30-r1.ebuild x11-wm/icewm/icewm-1.2.32.ebuild x11-wm/icewm/icewm-1.2.33.ebuild x11-wm/icewm/icewm-1.2.34.ebuild x11-wm/icewm/icewm-1.2.35.ebuild app-office/texmacs/texmacs-1.0.6.14.ebuild dev-libs/DirectFB-extra/DirectFB-extra-0.9.25.ebuild dev-libs/DirectFB-extra/DirectFB-extra-1.0.0.ebuild dev-libs/DirectFB-extra/DirectFB-extra-1.0.0-r1.ebuild dev-libs/DirectFB-extra/DirectFB-extra-1.1.0.ebuild media-libs/libcaca/libcaca-0.99_beta11.ebuild media-libs/libcaca/libcaca-0.99_beta13.ebuild media-libs/libcaca/libcaca-0.99_beta14.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20070616.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r1.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r20.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r2.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20070616-r3.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20080206.ebuild media-video/ffmpeg/ffmpeg-0.4.9_p20080326.ebuild www-client/w3m/w3m-0.5.2.ebuild www-client/w3m/w3m-0.5.2-r1.ebuild www-client/w3m/w3m-0.5.2-r2.ebuild x11-libs/libast/libast-0.7.ebuild x11-libs/libast/libast-.ebuild x11-misc/alock/alock-60-r3.ebuild x11-wm/awesome/awesome-3.0_rc2.ebuild x11-wm/fluxbox/fluxbox-1.0.0.ebuild x11-wm/fluxbox/fluxbox-1.0.0-r2.ebuild
Re: [gentoo-dev] Gentoo Council Reminder for August 7
David Leverton wrote: 2008/8/14 Donnie Berkholz [EMAIL PROTECTED]: Why aren't fired developers banned from the channels where they displayed this behavior? Isn't this one effectively withdrawn? I asked yngwin which devs he was referring to, and he said there weren't any, so is there anything left to discuss? I'll repeat on-list what I said on IRC: That's not what I said. So either you misunderstood, or you are twisting my words. What I want is a decision as to policy. I think it would be unhelpful to make this a discussion about individual cases. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: imlib/imlib2 useflag inconsistency
Benedikt Morbach [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 14 Aug 2008 21:56:16 +0200: Possible solutions include: (sorted by necessary effort) 1. Leaving everything like it is (not a real solution) 2. Removing the imlib2 useflag 3. Changing the 24 ebuilds depending on imlib2 to use the imlib2 useflag (and possibly making it a global flag) In my opinion, making imlib2 a global useflag would be the best solution, as it gives users who do not want an ancient unmaintained library a fine grained control over their system. Good catch/argument. Based on what was done with qt and gtk, option 2 above, removing the imlib2 USE flag and converting everything to use the imlib USE flag, is the most likely solution. Check the archives on gtk/gtk2 if you'd like. In the gtk/gtk2 case, where many packages could link against either, gtk was used to toggle the gtk general preference, while gtk2 if enabled indicated a preference for it over gtk(1). The solution was to deprecate the gtk2 flag and in general prefer gtk2 to gtk(1), if both could be linked. Individual package maintainers could of course decide to prefer gtk(1) if there was an overriding reason to do so. (qt had somewhat different details which I don't fully recall ATM, but I don't believe it's quite as direct a parallel in any case.) Since you mentioned that no imlib/imlib2 packages seem to use both flags, that solution would seem even more applicable here. Just do away with the imlib2 flag entirely, and prefer imlib2 in any cases where there is now or may be later a choice unless there's an overriding reason not to. But while I follow the discussion here regularly and have done so for some time, I'm just a user. We'll see what the devs have to say. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] The Plethora of Patches
Rémi Cardona wrote:
Andrew D Kirch wrote:
Obviously the software needs to work, and therefore we need patches, but
Gentoo has not done enough to date to get them pushed upstream. Lets
look at some cringeworthy statistics on outstanding patches.
Have you even _looked_ at the patches? Can you tell which ones are :
- backports?
- Gentoo-specific (for build issues)?
- shared with other distros?
Did you count the patches we apply because upstream is either dead,
unresponsive or downright wrong?
Yes, we have a lot of patches, but then again, we have a lot of open
bugs too. I, for one, am much more worried about the latter.
Please back this up with _real_ statistics.
Thanks
Rémi
Here's the script that I used to generate this. I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch in portage
which I personally don't have time to do.
for I in `ls`; do
PATCH=`ls -R ${I} | grep patch | wc -l`
DIFF=`ls -R ${I} | grep diff | wc -l`
COUNT=$(( ${PATCH} + ${DIFF} ))
if ! [ ${COUNT} == 0 ]
then
echo $I $COUNT
fi
done
Andrew
Re: [gentoo-dev] The Plethora of Patches
Denis Dupeyron wrote: On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: [...] Looks like you counted the number of files in the files/ subdirectories. Not all of these are patches. Also, you probably forgot to count seds, as some of us use sed more than patches. Oh, and like Jeremy was hinting, please contact QA. They need somebody like you. Denis. How would one get ahold of this QA? Andrew
Re: [gentoo-dev] The Plethora of Patches
On Fri, Aug 15, 2008 at 12:55:12AM -0400, Andrew D Kirch wrote: Here's the script that I used to generate this. I have not manually reviewed all of thousands of patches to determine the unique situation of each patch, however I would like a suggestion on how to demonstrate _real_ statistics short of auditing each and every patch in portage which I personally don't have time to do. Ok, even this misses lots of patches. As a suggestion on count improvements, look for invocations of epatch. They will take the following variations: 1. Use of a single file from $FILESDIR 2. Use of a single file from some distfile 3. Use of a directory from $FILESDIR 4. Use of a directory from some distfile Cases #1 and #2 will cover probably 95% of packages. Cases #3 and #4 will however contribute a lot to your stats. For MySQL as an example: http://git.overlays.gentoo.org/gitweb/?p=proj/mysql-extras.git;a=summary We carry 64 different patches. In some cases like 080_all_slot_script-*, it's 10 different versions of the same patch, that apply to different upstream releases. Lots of the patches are backports from upstream for bugs or security, because their release schedule isn't co-operative with often. 15 of the total 64 files have comment headers, esp. where the patch was a newer respin of some old one - I've been adding comment blocks. None of the patches in the mysql set are new features. Tracking epatch with grep (not hooking it, because of conditional patching) will get you a better count of overall patches, but not the distribution of patches in ebuilds. One other common case to watch for, is cases where we just borrow some of all of the debian patchset for a package. In general, I do see your interest in pushing patches upstream, but as both an upstream author and a downstream maintainer, I ask you to consider all distributions equally. Per my experiences as upstream (spanning 6+ packages I've written over the years): - Ubuntu seems to have a particularly bad track record with sending patches upstream. As the author of readahead-list (which is in a lot of distros), I've specifically mailed the Ubuntu maintainer and asked that he send me tidied up versions of the patches (I had some specific concerns) - and they totally ignored the newer version released a year later. I've heard precisely nothing back from them ever. In the case of readahead-list, they have two nice feature patches, and one bugfix. For a couple of my other packages, I have neither asked nor received anything from them, but I do see them carrying feature patches. - FreeBSD has a decent track record, I've received patches for a few different bugs and new features. RedHat/Fedora are pretty good as well. Negative experiences as a downstream maintainer: - Some upstreams ignored you - For Gitosis (see gitosis-gentoo and gitosis packages). Upstream has never accepted or even acknowledged any of the feature or bugfix patches I've sent him. This won't show up as a patch in your counts, because I now maintain gitosis-gentoo as a fork of the original because of the lack of upstream input. - Some upstreams attack you - For foo2zjs, I was outright textually assaulted by the author when I submitted a patch for a page rotation bug - he demands that nobody use any third-party packaging and install it entirely manually if they want any support - despite the fact I was submitting a bugfix and not asking for anything. - Stubborn upstreams - an upstream denied for a long time that one thing I suspected of being an issue was really at fault. It took me several months of detailed debugging to conclusively prove it (the upstream in question ran on a BSD system and didn't realize a subtle Linux difference). - Requirements of paperwork and contribution rules - Some GNU/FSF projects are pretty bad in this regard, wanting signed paperwork to have a patch included in the upstream, even if it's a bugfix. - Strenuous submission process, this is a less degree of a problem, but some larger upstreams are extremely picky about submissions. I've had to revise a bugfix 5-6 times before from using the style of the existing code to match the style of the new requirements instead. - Effective contribution channels - For MySQL, I've never had a patch that I submitted directly to the upstream bug tracking system accepted, but all the patches I addressed directly to a developer that I knew was reasonable for that portion of the codebase made it in. Some positive experiences as downstream: - Linux Kernel. Good patch submission review and ease of inclusion. I've got two good bugfixes you'll find in current kernels, plus I've done prototypes or spins of other patchsets that have been well received even if they weren't suitable for inclusion. - Danga (MogileFS). A couple of good patches then you get commit access. All commits are reviewed anyway. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail
[gentoo-portage-dev] [PATCH] fpformat is deprecated, use string interpolation
Hi, The fpformat module is deprecated and will be removed in py3k. The % string interpolation operator should be used instead. Attached patch fixes this. --- pym/_emerge/__init__.py |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/pym/_emerge/__init__.py b/pym/_emerge/__init__.py index 7a5c743..9bc06db 100644 --- a/pym/_emerge/__init__.py +++ b/pym/_emerge/__init__.py @@ -24,7 +24,6 @@ import array from collections import deque import fcntl import formatter -import fpformat import logging import select import shlex @@ -8674,7 +8673,7 @@ class JobStatusDisplay(object): avg = os.getloadavg() except OSError, e: return str(e) - return , .join(fpformat.fix(x, digits) for x in avg) + return , .join((%%.%df % digits ) % x for x in avg) def display(self): -- Regards, Ali Polatel
Re: [gentoo-portage-dev] [PATCH] fpformat is deprecated, use string interpolation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ali Polatel wrote: Hi, The fpformat module is deprecated and will be removed in py3k. The % string interpolation operator should be used instead. Attached patch fixes this. Thanks, applied. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkij/QkACgkQ/ejvha5XGaOI9wCgrEiI657jlDJ/RvC0qt0HDrpN 8PgAoNRmxE7i7O5LDUa/pZOtiSJoQydc =torE -END PGP SIGNATURE-
