[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty wrote: > On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: > > Members of Gentoo Python Project have agreed to deprecate the following > > functions > > in EAPI <=2: > > - python_version() > > - python_mod_exists() > > - python_tkinter_exists() > > - distutils_python_version() > > - distutils_python_tkinter() > > > > These functions are already banned in EAPI >=3. > > > > 1. In this week, these functions will start printing deprecation warnings > > in older EAPIs. > > 2. On 2010-07-01, these functions will start calling die(). > >(If any ebuilds in gentoo-x86 still call any of these functions on > > 2010-07-01, > > then addition of calls to die() will be delayed.) > > 3. On 2011-01-01, these functions will be removed. > > > > Removing eclass functions like this is not allowed by current policy. If > you want to do it, you should discuss about changing policy. ?! since when? -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: > Members of Gentoo Python Project have agreed to deprecate the following > functions > in EAPI <=2: > - python_version() > - python_mod_exists() > - python_tkinter_exists() > - distutils_python_version() > - distutils_python_tkinter() > > These functions are already banned in EAPI >=3. > > 1. In this week, these functions will start printing deprecation warnings in > older EAPIs. > 2. On 2010-07-01, these functions will start calling die(). >(If any ebuilds in gentoo-x86 still call any of these functions on > 2010-07-01, > then addition of calls to die() will be delayed.) > 3. On 2011-01-01, these functions will be removed. > Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Marking bugs for bugday?
I propose a value that you can set at runtime. We do this at work with the gflags package (already in the tree) or a config file. -A On Tue, Mar 2, 2010 at 1:05 PM, Sebastian Pipping wrote: > On 03/02/10 21:47, Alec Warner wrote: >> I would recommend not hardcoding 10 seconds; but otherwise caching is good ;) > > What do you propose? > > > > Sebastian > >
Re: [gentoo-dev] Last rites: net-misc/tipcutils
On 03/02/2010 10:49 PM, Alec Warner wrote: > Why make the fixes when we can announce package-death on -dev and get > the fixes for free from concerned users? :) Exactly. :-) > > On Tue, Mar 2, 2010 at 11:29 AM, malc wrote: >> Markos, >> >> Provided trivial debug/fix on bug. I'm an ex-dev so I know the >> workload - but I'd love to see QA be looking to make these minor >> fixes, rather than simply mask/remove? >> >> Cheers, >> malc. >> >> On Tue, Mar 2, 2010 at 5:23 PM, Markos Chandras wrote: >>> # Markos Chandras (02 Mar 2010) >>> # Fails to build. Unmaintained. Bug #298143. It will be removed in >>> # 2010-05-02 >>> net-misc/tipcutils >>> -- >>> Markos Chandras (hwoarang) >>> Gentoo Linux Developer >>> Web: http://hwoarang.silverarrow.org >>> >> >> >
Re: [gentoo-dev] Marking bugs for bugday?
On 03/02/10 21:47, Alec Warner wrote: > I would recommend not hardcoding 10 seconds; but otherwise caching is good ;) What do you propose? Sebastian
Re: [gentoo-dev] Marking bugs for bugday?
When am I getting control over that? Can infra help me? On Tue, Mar 2, 2010 at 8:36 PM, Sebastian Pipping wrote: > On 03/01/10 22:17, Ioannis Aslanidis wrote: >> getting control of bugday.gentoo.org and be able to upload our own >> content would be great. > > The current page is said to generate one XML request per bug listed on > the page for each request. From my experience trying to remove bugs > from that page yesterday(?) (through clicking on "remove" buttons) I > have the impression that it's true: Du to page reload times the site in > it's current form is unusable in the very sense of the word. > > Ideas I have on a rather simple rewrite: > > - Split the bugday website into two pages: > - Page "Open bugs" showing > - open bugday-keyworded bugs (with date of the latest bugday) > in randomized order > - Page "Closed bugs" showing > - closed bugday-keyworded bugs (with date of the latest bugday) > in some sorted order > - a ranking with closed bugs per participant > (as that may not be the assignee such information could > maybe be encoding into the status whiteboard, somewhere > we can query it from easily if whiteboard fits for that) > > - Do one search request to bugzilla internally, only. > Should be possible as we're now asking bugzilla for the list > of bugs instead of asking for details on a list we pass in. > > - Simple caching of bugzilla requests for 10 seconds or so. > Should not hurt the bugday experience much and reduce load > further. > > I could imagine that an ugly prototype with rough-edges of that could > take two days in plain Python. At the moment I cannot say when and if I > have these two days, but maybe someone else with time is fire and flame > for it by now? > > > > Sebastian > > -- Ioannis Aslanidis http://www.deathwing00.org 0x47F370A0
Re: [gentoo-dev] Last rites: net-misc/tipcutils
Why make the fixes when we can announce package-death on -dev and get the fixes for free from concerned users? :) On Tue, Mar 2, 2010 at 11:29 AM, malc wrote: > Markos, > > Provided trivial debug/fix on bug. I'm an ex-dev so I know the > workload - but I'd love to see QA be looking to make these minor > fixes, rather than simply mask/remove? > > Cheers, > malc. > > On Tue, Mar 2, 2010 at 5:23 PM, Markos Chandras wrote: >> # Markos Chandras (02 Mar 2010) >> # Fails to build. Unmaintained. Bug #298143. It will be removed in >> # 2010-05-02 >> net-misc/tipcutils >> -- >> Markos Chandras (hwoarang) >> Gentoo Linux Developer >> Web: http://hwoarang.silverarrow.org >> > >
Re: [gentoo-dev] Marking bugs for bugday?
On Tue, Mar 2, 2010 at 11:36 AM, Sebastian Pipping wrote: > On 03/01/10 22:17, Ioannis Aslanidis wrote: >> getting control of bugday.gentoo.org and be able to upload our own >> content would be great. > > The current page is said to generate one XML request per bug listed on > the page for each request. From my experience trying to remove bugs > from that page yesterday(?) (through clicking on "remove" buttons) I > have the impression that it's true: Du to page reload times the site in > it's current form is unusable in the very sense of the word. > > Ideas I have on a rather simple rewrite: > > - Split the bugday website into two pages: > - Page "Open bugs" showing > - open bugday-keyworded bugs (with date of the latest bugday) > in randomized order > - Page "Closed bugs" showing > - closed bugday-keyworded bugs (with date of the latest bugday) > in some sorted order > - a ranking with closed bugs per participant > (as that may not be the assignee such information could > maybe be encoding into the status whiteboard, somewhere > we can query it from easily if whiteboard fits for that) > > - Do one search request to bugzilla internally, only. > Should be possible as we're now asking bugzilla for the list > of bugs instead of asking for details on a list we pass in. > > - Simple caching of bugzilla requests for 10 seconds or so. > Should not hurt the bugday experience much and reduce load > further. I would recommend not hardcoding 10 seconds; but otherwise caching is good ;) > > I could imagine that an ugly prototype with rough-edges of that could > take two days in plain Python. At the moment I cannot say when and if I > have these two days, but maybe someone else with time is fire and flame > for it by now? > > > > Sebastian > >
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 02/03/10 13:39, Sebastian Pipping wrote: > On 03/02/10 20:28, Nathan Zachary wrote: > >>> This looks like overkill to me. One keyword should be enough, and for >>> supplementary information "Status Whiteboard" could be used. >>> >>> >> I agree. Simply having the BUGDAY keyword should be sufficient, and >> more information can be provided elsewhere in the report. >> > If more than one keyword is commonly considered overkill I would at > least request the whiteboard for it: "somewhere in the report" involves > more than zero searching for it. > > > > Sebastian > > Point taken, and I agree. --Zach
Re: [gentoo-dev] Last rites: net-misc/tipcutils
On Tuesday 02 March 2010 21:31:39 Markos Chandras wrote: > On Tuesday 02 March 2010 21:29:00 malc wrote: > > Markos, > > > > Provided trivial debug/fix on bug. I'm an ex-dev so I know the > > workload - but I'd love to see QA be looking to make these minor > > fixes, rather than simply mask/remove? > > > > Cheers, > > malc. > > > > On Tue, Mar 2, 2010 at 5:23 PM, Markos Chandras wrote: > > > # Markos Chandras (02 Mar 2010) > > > # Fails to build. Unmaintained. Bug #298143. It will be removed in > > > # 2010-05-02 > > > net-misc/tipcutils > > > -- > > > Markos Chandras (hwoarang) > > > Gentoo Linux Developer > > > Web: http://hwoarang.silverarrow.org > > I 've seen the bug. I will take care of it :) Since you are an ex-dev you > are aware of our policy on maintainer-needed bugs. We simply dont have the > free time to take care of their bugs :/ > Thanks for stepping up and help me with this > > I really appreciate it Fixed The package will stay on tree Thanks -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 03/02/10 20:28, Nathan Zachary wrote: >> This looks like overkill to me. One keyword should be enough, and for >> supplementary information "Status Whiteboard" could be used. >> > I agree. Simply having the BUGDAY keyword should be sufficient, and > more information can be provided elsewhere in the report. If more than one keyword is commonly considered overkill I would at least request the whiteboard for it: "somewhere in the report" involves more than zero searching for it. Sebastian
Re: [gentoo-dev] Marking bugs for bugday?
On 03/01/10 22:17, Ioannis Aslanidis wrote: > getting control of bugday.gentoo.org and be able to upload our own > content would be great. The current page is said to generate one XML request per bug listed on the page for each request. From my experience trying to remove bugs from that page yesterday(?) (through clicking on "remove" buttons) I have the impression that it's true: Du to page reload times the site in it's current form is unusable in the very sense of the word. Ideas I have on a rather simple rewrite: - Split the bugday website into two pages: - Page "Open bugs" showing - open bugday-keyworded bugs (with date of the latest bugday) in randomized order - Page "Closed bugs" showing - closed bugday-keyworded bugs (with date of the latest bugday) in some sorted order - a ranking with closed bugs per participant (as that may not be the assignee such information could maybe be encoding into the status whiteboard, somewhere we can query it from easily if whiteboard fits for that) - Do one search request to bugzilla internally, only. Should be possible as we're now asking bugzilla for the list of bugs instead of asking for details on a list we pass in. - Simple caching of bugzilla requests for 10 seconds or so. Should not hurt the bugday experience much and reduce load further. I could imagine that an ugly prototype with rough-edges of that could take two days in plain Python. At the moment I cannot say when and if I have these two days, but maybe someone else with time is fire and flame for it by now? Sebastian
Re: [gentoo-dev] Last rites: net-misc/tipcutils
On Tuesday 02 March 2010 21:29:00 malc wrote: > Markos, > > Provided trivial debug/fix on bug. I'm an ex-dev so I know the > workload - but I'd love to see QA be looking to make these minor > fixes, rather than simply mask/remove? > > Cheers, > malc. > > On Tue, Mar 2, 2010 at 5:23 PM, Markos Chandras wrote: > > # Markos Chandras (02 Mar 2010) > > # Fails to build. Unmaintained. Bug #298143. It will be removed in > > # 2010-05-02 > > net-misc/tipcutils > > -- > > Markos Chandras (hwoarang) > > Gentoo Linux Developer > > Web: http://hwoarang.silverarrow.org I 've seen the bug. I will take care of it :) Since you are an ex-dev you are aware of our policy on maintainer-needed bugs. We simply dont have the free time to take care of their bugs :/ Thanks for stepping up and help me with this I really appreciate it -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: net-misc/tipcutils
Markos, Provided trivial debug/fix on bug. I'm an ex-dev so I know the workload - but I'd love to see QA be looking to make these minor fixes, rather than simply mask/remove? Cheers, malc. On Tue, Mar 2, 2010 at 5:23 PM, Markos Chandras wrote: > # Markos Chandras (02 Mar 2010) > # Fails to build. Unmaintained. Bug #298143. It will be removed in > # 2010-05-02 > net-misc/tipcutils > -- > Markos Chandras (hwoarang) > Gentoo Linux Developer > Web: http://hwoarang.silverarrow.org >
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 02/03/10 13:17, Ulrich Mueller wrote: >> On Tue, 02 Mar 2010, Sebastian Pipping wrote: >> > >> To make naming a bit more consistent, how about: >> - BUGDAY-CANDIDATE >> - BUGDAY-ACCEPTED >> - BUGDAY-REFUSED >> > >> They're a bit long but I think it's worth to not have them crippled >> down to stuff like "BDYES", "BDNO" and "BDMAYBE". >> > This looks like overkill to me. One keyword should be enough, and for > supplementary information "Status Whiteboard" could be used. > > Ulrich > > I agree. Simply having the BUGDAY keyword should be sufficient, and more information can be provided elsewhere in the report. --Zach
Re: [gentoo-dev] Re: Marking bugs for bugday?
> On Tue, 02 Mar 2010, Sebastian Pipping wrote: > To make naming a bit more consistent, how about: > - BUGDAY-CANDIDATE > - BUGDAY-ACCEPTED > - BUGDAY-REFUSED > They're a bit long but I think it's worth to not have them crippled > down to stuff like "BDYES", "BDNO" and "BDMAYBE". This looks like overkill to me. One keyword should be enough, and for supplementary information "Status Whiteboard" could be used. Ulrich
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 03/02/10 02:32, Alec Warner wrote: >> BUGDAY (nomination) >> BUGDAY-ACCEPTED (or whatever is thought appropriate) >> NOBUGDAY(or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...) > > I think the last one is over-engineering a bit; bugzilla keywords are > not permanent How are they not permanent? Sebastian
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 03/02/10 02:09, Duncan wrote: > ... And here I'm proposing three: > > BUGDAY(nomination) > BUGDAY-ACCEPTED (or whatever is thought appropriate) > NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...) > > The latter would be for nominated bugs that were declined as inappropriate > for whatever reason, to help prevent them being nominated again. > Presumably there'd be a comment added explaining why as well, but the > keyword would be what shows up in someone's face if they're thinking about > keywording it BUGDAY. I agree that it would be useful. Especially if we have bugs where an assignee wants to take care of the bug himself (including his own scheduling), we could run into bugday-keyword wars: 1) add keyword 2) remove keyword 3) overlook previous removal 4) goto <1> To make naming a bit more consistent, how about: - BUGDAY-CANDIDATE - BUGDAY-ACCEPTED - BUGDAY-REFUSED They're a bit long but I think it's worth to not have them crippled down to stuff like "BDYES", "BDNO" and "BDMAYBE". Sebastian
[gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
Members of Gentoo Python Project have agreed to deprecate the following
functions
in EAPI <=2:
- python_version()
- python_mod_exists()
- python_tkinter_exists()
- distutils_python_version()
- distutils_python_tkinter()
These functions are already banned in EAPI >=3.
1. In this week, these functions will start printing deprecation warnings in
older EAPIs.
2. On 2010-07-01, these functions will start calling die().
(If any ebuilds in gentoo-x86 still call any of these functions on
2010-07-01,
then addition of calls to die() will be delayed.)
3. On 2011-01-01, these functions will be removed.
I will also send the announcement to gentoo-dev-announce mailing list to ensure
that developers not subscribed to gentoo-dev mailing list will notice the
deprecation.
The attached patch shows text of deprecation warnings.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -1980,6 +1980,15 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ if [[ "${FUNCNAME[1]}" != "distutils_python_version" ]]; then
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}"
+ ewarn
+ fi
+
[[ -n "${PYVER}" ]] && return 0
local tmpstr
python="${python:-${EPREFIX}/usr/bin/python}"
@@ -2011,6 +2020,13 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use USE dependencies and/or has_version() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+
if [[ "$#" -ne 1 ]]; then
die "${FUNCNAME}() requires 1 argument"
fi
@@ -2027,6 +2043,15 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ if [[ "${FUNCNAME[1]}" != "distutils_python_tkinter" ]]; then
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON_USE_WITH=\"xml\" and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+ fi
+
if ! "$(PYTHON ${PYTHON_ABI})" -c "from sys import version_info
if version_info[0] == 3:
import tkinter
--- distutils.eclass
+++ distutils.eclass
@@ -382,6 +382,13 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}"
+ ewarn
+
python_version
}
@@ -394,5 +401,12 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON_USE_WITH=\"xml\" and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+
python_tkinter_exists
}
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Last rites: net-misc/tipcutils
# Markos Chandras (02 Mar 2010) # Fails to build. Unmaintained. Bug #298143. It will be removed in # 2010-05-02 net-misc/tipcutils -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/rhythmbox: metadata.xml ChangeLog rhythmbox-0.12.7.ebuild
"Gilles Dartiguelongue (eva)" said: > eva 10/03/01 23:31:32 > > Modified: metadata.xml ChangeLog > Added:rhythmbox-0.12.7.ebuild > Log: > Version bump. Lots of fixes, add rdepend for context panel plugin. Kill > *.la files for plugins. > (Portage version: 2.2_rc63/cvs/Linux x86_64, RepoMan options: --force) This seems to be a growing trend, so let me address it here...Do not use --force to get an ebuild into the tree that has unsatisfiable dependencies. --force should only be used in circumstances where it is the only option. Breaking deps for an arch is not what it is intended for. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
