[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/rhythmbox: metadata.xml ChangeLog rhythmbox-0.12.7.ebuild
Gilles Dartiguelongue (eva) e...@gentoo.org 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
[gentoo-dev] Last rites: net-misc/tipcutils
# Markos Chandras hwoar...@gentoo.org (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] 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.
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
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 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 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] 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 hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (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] 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 hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (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] 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] 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] 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 hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (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 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] Marking bugs for bugday?
On Tue, Mar 2, 2010 at 11:36 AM, Sebastian Pipping sp...@gentoo.org 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] 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 mlash...@gmail.com 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 hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (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?
When am I getting control over that? Can infra help me? On Tue, Mar 2, 2010 at 8:36 PM, Sebastian Pipping sp...@gentoo.org 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 deathwing00[at]gentoo.org 0x47F370A0
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] 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 mlash...@gmail.com 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 hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (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?
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 sp...@gentoo.org 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] 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
[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 betelge...@gentoo.org 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-portage-dev] VCS used for development of portage
Hello!
I've been playing with Git conversions of the portage repository.
The current demo conversion from anon SVN is up here:
http://git.goodpoint.de/?p=portage.git;a=summary
NOTE: Do not use it for development, yet - it's a demo!
At the end you can find the script I made for the conversion.
Notes on the script:
- An author map portage-author-map.txt is required, get from [1]
(Note to zmedico/robbat2: fixed version, do not use the older one)
- If updated, the latest version of this script is up at [2]
- It works with anon SVN and rsync. For the final run
- use developer SVN instead
- be sure to remove --rewrite-root !
- The final repository will be about 22MB in size
- Main conversion takes about two hours on my machine
Next we need to decide on
- a final location (git.overlays.gentoo.org/proj/portage?)
- when we convert (and freeze SVN)
- who runs the final conversion (zmedico, roobat2, me?)
Sebastian
[1] http://www.hartwork.org/public/portage-author-map.txt
[2] http://www.hartwork.org/public/portage-svn-to-git.sh
=
#!/usr/bin/env bash
starttime=$(date +'%Y-%m-%d--%H-%M-%S')
output_dir=portage-git-repo--${starttime}
# Open logged subshell
(
# Print executed bash commands
set -x
# Rip/sync anon SVN using rsync
rsync -r rsync://anonvcs.gentoo.org/vcs-public-svnroot/portage/ \
portage-anon-svn-repo-dump/ || exit 1
# Init git-svn repo, note double use of --trunk
[ -d ${output_dir} ] exit 1
git svn init file://${PWD}/portage-anon-svn-repo-dump/ \
--rewrite-root=svn://anonsvn.gentoo.org/portage/ \
--trunk=main/trunk --tags=main/tags --branches=main/branches \
${output_dir}
cd ${output_dir} || exit 1
# Convert commits
git config svn.authorsfile ../portage-author-map.txt
time git svn fetch || exit 1
# Make real Git tags from remotes/tags/* (two special cases)
for branch_tag in $(git branch -r | grep 'tags/' \
| fgrep -v 'tags/portage-2.1_pre5'); do
tag=$(sed 's|^tags/||' ${branch_tag})
git tag v${tag} remotes/${branch_tag} || exit 1
done
git tag 'tr...@1888' 'remotes/tr...@1888' || exit 1
# Make local branches from remotes/* (excluding tags and trunk)
for branch in $(git branch -r | grep -v 'tags\|trunk'); do
git checkout -b ${branch} remotes/${branch} || exit 1
done
git checkout master || exit 1
# Reduce size of repository
dotgitsize() { du --human --total .git | tail -n 1; }
dotgitsize
git gc --aggressive
dotgitsize
# Wipe all traces of SVN
git config --remove-section 'svn-remote.svn'
git config --remove-section 'svn'
rm -R .git/svn
rm -R .git/logs/refs/remotes
for file in .git/info/refs .git/packed-refs ; do
sed -e '/remotes\//d' -i ${file}
done
# Hide executed bash commands
set +x
cat INFO
DONE.
NEXT STEPS:
# cd ${output_dir}
Verify that branches and tags
1. make sense
2. are unambiguous
3. are free of SVN
# git branch -a
# git show-branch --list
# git tag -l
Push full repository
# git remote add \${remote_name} \${push_url}
# git push --mirror \${remote_name}
INFO
) | tee conversion--${starttime}.log
#
