[gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
I assume many of us have wrapper scripts to automatically generate matching ChangeLog and CVS commit messages. When we eventually move to git the plan is for the ChangeLog to be automatically generated from git. To unify developer practices and to ease the transition to git it has been proposed to make repoman automatically generate ChangeLog entries. If you have any objections or thought please raise them. One open question is what should repoman do if there is already a modification to the ChangeLog file. Regards, Petteri Bugzilla bug: http://bugs.gentoo.org/show_bug.cgi?id=337853 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
On 09/19/10 15:10, Petteri Räty wrote: I assume many of us have wrapper scripts to automatically generate matching ChangeLog and CVS commit messages. When we eventually move to git the plan is for the ChangeLog to be automatically generated from git. To unify developer practices and to ease the transition to git it has been proposed to make repoman automatically generate ChangeLog entries. If you have any objections or thought please raise them. One open question is what should repoman do if there is already a modification to the ChangeLog file. IMHO: die with an error message similar to: !!! ChangeLog has been modified, please revert the change or pass !!! --no-update-changelog to avoid automatic update. -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
On Sun, Sep 19, 2010 at 15:20, Krzysztof Pawlik nelch...@gentoo.org wrote: On 09/19/10 15:10, Petteri Räty wrote: I assume many of us have wrapper scripts to automatically generate matching ChangeLog and CVS commit messages. When we eventually move to git the plan is for the ChangeLog to be automatically generated from git. To unify developer practices and to ease the transition to git it has been proposed to make repoman automatically generate ChangeLog entries. If you have any objections or thought please raise them. One open question is what should repoman do if there is already a modification to the ChangeLog file. IMHO: die with an error message similar to: !!! ChangeLog has been modified, please revert the change or pass !!! --no-update-changelog to avoid automatic update. Sounds good to me (both the idea and dying explicitly on modified changelog). Cheers, Dirkjan
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
On 19-09-2010 16:10:15 +0300, Petteri Räty wrote: I assume many of us have wrapper scripts to automatically generate matching ChangeLog and CVS commit messages. When we eventually move to git the plan is for the ChangeLog to be automatically generated from git. To unify developer practices and to ease the transition to git it has been proposed to make repoman automatically generate ChangeLog entries. If you have any objections or thought please raise them. One open question is what should repoman do if there is already a modification to the ChangeLog file. I think this idea conflicts with the purpose of the ChangeLog, being that it should contain relevant information for users only. Technical details belong to the commit message, as you agreed upon yourself in one of the commit reviews we had earlier on this list. That said, I see the benefit of repoman being able to add a ChangeLog entry, but I think it should refrain if the ChangeLog has been modified. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It should be possible to still maintain this distinction, something like: Version bump. Added feature foo. - -- Feature foo required a complete rewrite of src_install. And then the ChangeLog generation can happen separately. The problem with this method is that if we later rely only on commit logs, users may see things developers hadn't intended them to see. So the question is, will we always generate changelogs from the version control system, or will we one day expect the user to directly read the commit logs? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyWKWsACgkQu7rWomwgFXoBoACcCAeaYpUzquKEyp09NHk7nrrK w9AAoKf8HtoAY68UMYSEwwvyqemV54M+ =iVC7 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
On Sun, 19 Sep 2010 16:10:15 +0300 Petteri Räty betelge...@gentoo.org wrote: One open question is what should repoman do if there is already a modification to the ChangeLog file. I suggest reverting the ChangeLog modification. That's what my sunrise-commit [1] does, and it works quite well. On the other side, shouldn't the git migration remove VCS-side ChangeLogs completely in favor of regenerating them on the rsync mirror? I think I'll implement ChangeLog generation feature in egencache in the near time. [1] http://github.com/mgorny/sunrise-commit -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] RFC: per package eclass GLEP
I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. GLEP: 62 Title: Per package eclasses Version: Last-Modified: Author: Matti Bickel m...@gentoo.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: Post-History: Abstract This document proposes a new kind of eclasses, which are specific to a certain package (hence per-package eclasses). It explains the current need for package specific eclasses, the proposed solution and a possible migration path. What is proposed is, in short, creation of eclasses in package directories for use by the ebuilds of the package in the same directory. Per-package eclasses can be thought of (broadly speaking) as normal eclasses used only by one package. Motivation and Rationale Gentoo currently provides 211 eclasses as of 14-08-2010, 36 of which are marked @DEAD and are scheduled for removal. At least three non-dead eclasses are specific to one package (mysql, php5_2-sapi and nvidia-drivers). The sheer number of eclasses makes it hard for old and new developers to quickly find the eclass they are looking for. Providing overlays and working on a single package also is not as easy as it should be. Last but not least, eclasses provided in the package directory could be part of the package's Manifest file, providing part of the eclass signing the Gentoo tree still lacks. Placing the package specific eclasses into the package directories themselves solves all of the problems mentioned (at least partly). It will reduce the clutter in the current eclass directory, provide a single directory to understand an ebuild and provides security benefits by including the eclasses in the Manifest file. Specification = The per-package eclasses are specified to be placed directly under the package directory (as described in [1]_). The eclass may have any name permissible for other eclasses (specifically, must end with .eclass). A per-package eclass is included in an ebuild by a new function ``pkg-inherit`` called in the global scope of the ebuild. The ``pkg-inherit`` function must be given zero or more arguments. If no argument is given, the function shall behave like it was called with the argument ``default``. It is specified to search the package directory of the calling ebuild (but no other directories) for eclasses with the names of the arguments and the suffix .eclass. If such files exist, they must be sourced by the function. If not specified otherwise below, the package manager shall treat the per-package eclass as a normal eclass in any other respect. It is made a requirement that per-package eclasses can not modify the ``EAPI`` variable. It is assumed ``EAPI``, if it set, is set before calling pkg-inherit. Backwards Compatibility === The current Package Manager Specification requires package managers to ignore anything in the top-level package directory that does not have a filename ending in .ebuild ([1]_). Thus package manager which do not implement the per-package eclass feature can ignore them. They, however, will fail to execute ebuilds making use of the new ``pkg-inherit`` function. It is therefore required this feature be made part of a new EAPI. Additionally, tools that regenerate the Manifest file should be aware of per-package eclasses. However, this is only of concern to developers regenerating Manifests in a specific package directory. It is assumed that whoever changes functionality in a package also uses tools capable of supporting features used in the package's ebuilds. Copyright = This document has been placed in the public domain. .. [1] http://distfiles.gentoo.org/distfiles/pms-3.pdf, Section 4.3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
Wouldn't it also make sense to have per-category eclasses? This seems much more useful for me. Examples where this would already make sense today: kde-meta, latex-package, ... Best, Andreas On Sunday 19 September 2010 21:14:56 Matti Bickel wrote: I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, sunrise dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: per package eclass GLEP
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel m...@gentoo.org wrote: I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) I've placed my immediate feedback in CVS: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1r2=1.2 I will split the remaining commentary up into two sections: General Idea Feedback (call these non-editor related) and editorial feedback (generally segments you should add to the GLEP for editorial reasons.) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. Feedback: I believe the biggest reason to have per-package eclasses is the following: 1) It limits how users can use an eclass. a) This makes mis-using eclasses harder to do; Interfaces that are hard to use incorrectly are good. b) It means changing an eclass affects fewer packages. It is currently difficult to control eclass consumers in the current model. (anyone can use any eclass.) c) It means eclass changes are easier to test. I think the GLEP attempts to over-blow the actual impact that its proposed changes may have. For instance I do not think per-package eclasses will drastically reduce the number of eclasses in the global eclass directory. It will not make overlays easier to use (possibly harder..actually.) Plus the number of eclasses that will move to per-package is likely few (the GLEP itself only notes three.) I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. Editorial: The proposal is vaguely similar to GLEP 33. There is also an existing implementation of per-package eclasses called eblits (used in glibc, possibly in other places.) The GLEP should refer to these (link to GLEP 33, if there is a page describing eblits; link to that as well.) The GLEP should also discuss why GLEP 33 and eblits are not the best implementation of this idea. If the GLEP makes claims such as 'The implementation will improve X or reduce Y by Z%' the GLEP should cite sources, data, or make some kind of argument as to why that is the case. For instance the GLEP refers to 'distributing ebuilds in overlays will be easier' but fails to discuss how it is easier in this new system. When thinking about these types of things; try to break them down into something measurable. For instance: With the old system there were 5 individual steps, the new system only has 3. The GLEP makes claims about how the per-package eclasses *could* be made part of the Manifest format. The GLEP should not focus on could. Either the per-package eclasses are part of the manifest code (per this GLEP) or they are not. If the GLEP dictates they are to be included in manifests the GLEP should discuss how exactly that will work (what types, checksums, etc..) If the eclasses are not required to be manifested then the GLEP should not tout that as an advantage over the status quo. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. Any dev can check stuff into other dev's individual CVS space. Feel free to edit the eclass in my devspace if you wish. I think there is some automation on the actual GLEP webspace now (that htmlifies GLEPS) so I am avoiding that space cause I forgot how exactly the automation works ;))
[gentoo-dev] Re: RFC: per package eclass GLEP
Matti Bickel posted on Sun, 19 Sep 2010 21:14:56 +0200 as excerpted: It is made a requirement that per-package eclasses can not modify the ``EAPI`` variable. It is assumed ``EAPI``, if it set, is set before calling pkg-inherit. Backwards Compatibility === The current Package Manager Specification requires package managers to ignore anything in the top-level package directory that does not have a filename ending in .ebuild ([1]_). Thus package manager which do not implement the per-package eclass feature can ignore them. They, however, will fail to execute ebuilds making use of the new ``pkg-inherit`` function. It is therefore required this feature be made part of a new EAPI. AFAIK these two paragraphs together contradict each other in regard to eapi. Given that no set eapi is taken to be eapi=0, and this is proposed as part of a new eapi, eapi MUST be set before pkg-inherit, if pkg-inherit and thus per-pkg eclasses are to be used at all. The last sentence of the top paragraph (of the two) should therefore be rewritten to reflect that requirement and avoid any confusion. -- 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
[gentoo-dev] omitting redirecting man pages from compression
many man pages exist merely as a redirect to another man page:
$ xzcat /usr/share/man/man1/zcat.1.xz
.so man1/gzip.1
compressing these tiny (always?) results in a larger file. that means we
arent saving space, and we're adding overhead at runtime.
two options which we can do transparently:
- rewrite the .so man pages into symlinks
- omit them from compression
the latter is pretty easy (see below). any preferences on which route to take
though as the former shouldnt be too hard either ...
--- a/bin/ebuild-helpers/ecompressdir
+++ b/bin/ebuild-helpers/ecompressdir
@@ -13,6 +13,7 @@ case $1 in
--ignore)
shift
for skip in $@ ; do
+ skip=${skip#${D}}
[[ -d ${D}${skip} || -f ${D}${skip} ]] \
touch ${D}${skip}.ecompress.skip
done
--- a/bin/ebuild-helpers/prepman
+++ b/bin/ebuild-helpers/prepman
@@ -27,6 +27,10 @@ for subdir in ${mandir}/man* ${mandir}/*/man* ; do
[[ -d ${subdir} ]] really_is_mandir=1 break
done
-[[ ${really_is_mandir} == 1 ]] exec ecompressdir --queue ${mandir#${D}}
+if [[ ${really_is_mandir} == 1 ]] ; then
+ ecompressdir --queue ${mandir#${D}} || exit 1
+ # compressing small files just adds overhead
+ find ${mandir} -type f '!' -size +100c -print0 | ${XARGS} -0
ecompressdir --ignore
+fi
exit 0
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] omitting redirecting man pages from compression
On 09/19/2010 04:43 PM, Mike Frysinger wrote: many man pages exist merely as a redirect to another man page: $ xzcat /usr/share/man/man1/zcat.1.xz .so man1/gzip.1 compressing these tiny (always?) results in a larger file. that means we arent saving space, and we're adding overhead at runtime. two options which we can do transparently: - rewrite the .so man pages into symlinks - omit them from compression the latter is pretty easy (see below). any preferences on which route to take though as the former shouldnt be too hard either ... It feels like an insignificant optimization to me, but I don't feel strongly either way. -- Thanks, Zac
Re: [gentoo-dev] omitting redirecting man pages from compression
On Sunday, September 19, 2010 19:50:57 Zac Medico wrote: On 09/19/2010 04:43 PM, Mike Frysinger wrote: many man pages exist merely as a redirect to another man page: $ xzcat /usr/share/man/man1/zcat.1.xz .so man1/gzip.1 compressing these tiny (always?) results in a larger file. that means we arent saving space, and we're adding overhead at runtime. two options which we can do transparently: - rewrite the .so man pages into symlinks - omit them from compression the latter is pretty easy (see below). any preferences on which route to take though as the former shouldnt be too hard either ... It feels like an insignificant optimization to me, but I don't feel strongly either way. ~19% of the man pages on my system appear to be forwarding files (glorified symlinks). in my case, that's almost 3000 files. considering things like `makewhatis` need to decompress read all of these, i think the difference is worth addressing. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-09-19 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-09-19 23h59 UTC. Removals: media-gfx/kst 2010-09-13 16:37:23 ayoy dev-libs/linux-fusion 2010-09-13 19:06:07 mr_bones_ dev-java/jmp2010-09-16 11:18:19 caster app-crypt/wxchecksums 2010-09-17 04:52:50 dirtyepic media-gfx/zphoto2010-09-17 04:55:28 dirtyepic Additions: sci-libs/getdata2010-09-13 16:25:29 ayoy sci-visualization/kst 2010-09-13 16:33:57 ayoy dev-ruby/rspec-core 2010-09-13 18:00:12 graaff dev-ruby/rspec-expectations 2010-09-13 18:01:51 graaff dev-ruby/rspec-mocks2010-09-13 18:03:15 graaff dev-perl/Module-Manifest2010-09-14 16:41:40 tove dev-ruby/rdiscount 2010-09-14 18:58:10 graaff dev-ruby/mustache 2010-09-14 19:03:11 graaff app-text/ronn 2010-09-14 19:04:53 graaff net-analyzer/thc-ipv6 2010-09-15 01:49:58 xmw net-libs/miniupnpc 2010-09-15 08:40:36 pva app-misc/golly 2010-09-16 15:53:09 xmw media-video/bombono-dvd 2010-09-16 22:04:32 dilfridge net-zope/externalmethod 2010-09-17 21:54:12 arfrever net-zope/mailhost 2010-09-17 21:57:18 arfrever net-zope/mimetools 2010-09-17 22:00:30 arfrever net-zope/ofsp 2010-09-17 22:03:07 arfrever net-zope/pythonscripts 2010-09-17 22:05:27 arfrever media-gfx/argyllcms 2010-09-17 22:06:06 dilfridge net-zope/standardcachemanagers 2010-09-17 22:08:17 arfrever net-zope/zctextindex2010-09-17 22:10:38 arfrever sci-misc/gcam 2010-09-18 12:54:18 dilfridge gnome-extra/panflute2010-09-18 21:17:32 eva dev-ruby/tilt 2010-09-19 06:57:49 graaff sys-fs/cachefilesd 2010-09-19 08:08:16 jlec dev-python/martian 2010-09-19 23:37:53 arfrever net-zope/grokcore-component 2010-09-19 23:41:28 arfrever net-zope/grokcore-annotation2010-09-19 23:43:30 arfrever net-zope/grokcore-security 2010-09-19 23:45:58 arfrever net-zope/grokcore-site 2010-09-19 23:47:38 arfrever net-zope/zope-login 2010-09-19 23:51:41 arfrever net-zope/grokcore-view 2010-09-19 23:52:42 arfrever net-zope/grokcore-viewlet 2010-09-19 23:54:37 arfrever net-zope/grokcore-formlib 2010-09-19 23:56:56 arfrever -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-gfx/kst,removed,ayoy,2010-09-13 16:37:23 dev-libs/linux-fusion,removed,mr_bones_,2010-09-13 19:06:07 dev-java/jmp,removed,caster,2010-09-16 11:18:19 app-crypt/wxchecksums,removed,dirtyepic,2010-09-17 04:52:50 media-gfx/zphoto,removed,dirtyepic,2010-09-17 04:55:28 Added Packages: sci-libs/getdata,added,ayoy,2010-09-13 16:25:29 sci-visualization/kst,added,ayoy,2010-09-13 16:33:57 dev-ruby/rspec-core,added,graaff,2010-09-13 18:00:12 dev-ruby/rspec-expectations,added,graaff,2010-09-13 18:01:51 dev-ruby/rspec-mocks,added,graaff,2010-09-13 18:03:15 dev-perl/Module-Manifest,added,tove,2010-09-14 16:41:40 dev-ruby/rdiscount,added,graaff,2010-09-14 18:58:10 dev-ruby/mustache,added,graaff,2010-09-14 19:03:11 app-text/ronn,added,graaff,2010-09-14 19:04:53 net-analyzer/thc-ipv6,added,xmw,2010-09-15 01:49:58 net-libs/miniupnpc,added,pva,2010-09-15 08:40:36 app-misc/golly,added,xmw,2010-09-16 15:53:09 media-video/bombono-dvd,added,dilfridge,2010-09-16 22:04:32 net-zope/externalmethod,added,arfrever,2010-09-17 21:54:12 net-zope/mailhost,added,arfrever,2010-09-17 21:57:18 net-zope/mimetools,added,arfrever,2010-09-17 22:00:30 net-zope/ofsp,added,arfrever,2010-09-17 22:03:07 net-zope/pythonscripts,added,arfrever,2010-09-17 22:05:27 media-gfx/argyllcms,added,dilfridge,2010-09-17 22:06:06 net-zope/standardcachemanagers,added,arfrever,2010-09-17 22:08:17 net-zope/zctextindex,added,arfrever,2010-09-17 22:10:38 sci-misc/gcam,added,dilfridge,2010-09-18 12:54:18 gnome-extra/panflute,added,eva,2010-09-18 21:17:32 dev-ruby/tilt,added,graaff,2010-09-19 06:57:49 sys-fs/cachefilesd,added,jlec,2010-09-19 08:08:16 dev-python/martian,added,arfrever,2010-09-19 23:37:53 net-zope/grokcore-component,added,arfrever,2010-09-19 23:41:28 net-zope/grokcore-annotation,added,arfrever,2010-09-19 23:43:30 net-zope/grokcore-security,added,arfrever,2010-09-19 23:45:58 net-zope/grokcore-site,added,arfrever,2010-09-19 23:47:38 net-zope/zope-login,added,arfrever,2010-09-19 23:51:41 net-zope/grokcore-view,added,arfrever,2010-09-19 23:52:42 net-zope/grokcore-viewlet,added,arfrever,2010-09-19 23:54:37 net-zope/grokcore-formlib,added,arfrever,2010-09-19 23:56:56 Done.
Re: [gentoo-dev] openrc stabilization update
On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs willi...@gentoo.org wrote: I suppose one question I need to ask is the oldnet vs newnet question. The git repository defaults to building and installing the newnet option, and we make oldnet the default in the ebuild. People migrating from stable will know the oldnet option, and this is the only way to configure the network scripts that is actually covered in our documentation. Do we want to switch the upstream repository to make oldnet the default? What about newnet. Should we keep it at all? If we do, should we put it behind a use flag which would be off by default? Is there any advantage to using newnet over oldnet? If there aren't any advantages, we should not attempt to support it (even as an optional feature). Old-net by default, no use-flag for newnet; people can use EXTRA_ECONF if they *really* want to use it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Patch for python.eclass
This patch for python.eclass has been divided into 3 subpatches to simplify
review.
Subpatch #1 fixes preservation of whitespace.
Subpatch #2 renames 2 local arrays in python_mod_optimize() function:
site_packages_absolute_dirs - dirs
site_packages_absolute_files - files
Subpatch #3 adds --allow-evaluated-non-sitedir-paths option to
python_mod_optimize() and
python_mod_cleanup() functions.
In rare cases, packages supporting installation for multiple Python ABIs
install .py files
outside of site-packages directories. python_mod_optimize() and
python_mod_cleanup()
functions currently don't support such paths. It's better to not allow such
paths by
default, so this subpatch adds new --allow-evaluated-non-sitedir-paths option
to these
functions. This option is disallowed in packages not supporting installation
for multiple
Python ABIs. Such paths are internally evaluated inside these functions. Such
paths work
correctly only if they contain '${PYTHON_ABI}' or '$(python_get_version)'
(probably with
'$(python_get_implementation)') or '$(custom_function)' (where
custom_function() uses
${PYTHON_ABI} or $(python_get_version) and prints appropriate output), so
there are
sanity checks, which ensure that such paths contain '$'.
Example usage:
pkg_postinst() {
python_mod_optimize --allow-evaluated-non-sitedir-paths
'/usr/share/package_name/${PYTHON_ABI}'
}
pkg_postrm() {
python_mod_cleanup --allow-evaluated-non-sitedir-paths
'/usr/share/package_name/${PYTHON_ABI}'
}
This functionality is needed by Zope 2.12 / 2.13.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -925,7 +925,7 @@
if [[ ${quiet} == 0 ]]; then
if [[ -n ${action_message_template} ]]; then
-action_message=$(eval echo -n ${action_message_template})
+eval action_message=\${action_message_template}\
else
action_message=${action} of ${CATEGORY}/${PF} with $(python_get_implementation) $(python_get_version)...
fi
@@ -959,7 +959,7 @@
if [[ ${return_code} -ne 0 ]]; then
if [[ -n ${failure_message_template} ]]; then
-failure_message=$(eval echo -n ${failure_message_template})
+eval failure_message=\${failure_message_template}\
else
failure_message=${action} failed with $(python_get_implementation) $(python_get_version) in ${function}() function
fi
@@ -1925,7 +1925,7 @@
python_test_function() {
local evaluated_PYTHONPATH
- evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+ eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
_python_test_hook pre
@@ -1989,7 +1989,7 @@
python_test_function() {
local evaluated_PYTHONPATH
- evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+ eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
_python_test_hook pre
@@ -2053,7 +2053,7 @@
python_test_function() {
local evaluated_PYTHONPATH
- evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+ eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
_python_test_hook pre
@@ -2223,7 +2223,7 @@
if ! has ${EAPI:-0} 0 1 2 || _python_package_supporting_installation_for_multiple_python_abis; then
# PYTHON_ABI variable cannot be local in packages not supporting installation for multiple Python ABIs.
- local dir file iterated_PYTHON_ABIS options=() other_dirs=() other_files=() previous_PYTHON_ABI=${PYTHON_ABI} return_code root site_packages_absolute_dirs=() site_packages_dirs=() site_packages_absolute_files=() site_packages_files=()
+ local allow_evaluated_non_sitedir_paths=0 dir dirs=() evaluated_dirs=() evaluated_files=() file files=() iterated_PYTHON_ABIS options=() other_dirs=() other_files=() previous_PYTHON_ABI=${PYTHON_ABI} return_code root site_packages_dirs=() site_packages_files=()
if _python_package_supporting_installation_for_multiple_python_abis; then
if has ${EAPI:-0} 0 1 2 3 [[ -z ${PYTHON_ABIS} ]]; then
@@ -2243,6 +2243,9 @@
while (($#)); do
case $1 in
+--allow-evaluated-non-sitedir-paths)
+ allow_evaluated_non_sitedir_paths=1
+ ;;
-l|-f|-q)
options+=($1)
;;
@@ -2264,6 +2267,10 @@
shift
done
+ if [[ ${allow_evaluated_non_sitedir_paths} == 1 ]] ! _python_package_supporting_installation_for_multiple_python_abis; then
+ die ${FUNCNAME}(): '--allow-evaluated-non-sitedir-paths' option cannot be used in ebuilds of packages not supporting installation for multiple Python ABIs
+ fi
+
if [[ $# -eq 0 ]]; then
ewarn
ewarn Deprecation Warning: Not passing of paths to ${FUNCNAME}() is deprecated and will be
@@ -2279,16 +2286,27 @@
die ${FUNCNAME}(): Paths of directories / files in site-packages directories must be relative to site-packages directories
elif [[ $1 =~ ^/ ]]; then
if _python_package_supporting_installation_for_multiple_python_abis; then
- die ${FUNCNAME}(): Absolute paths cannot be used in ebuilds of packages supporting installation for multiple Python ABIs
-fi
-if [[ -d ${root}$1 ]];
Re: [gentoo-dev] openrc stabilization update
On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote: On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs willi...@gentoo.org wrote: I suppose one question I need to ask is the oldnet vs newnet question. The git repository defaults to building and installing the newnet option, and we make oldnet the default in the ebuild. People migrating from stable will know the oldnet option, and this is the only way to configure the network scripts that is actually covered in our documentation. Do we want to switch the upstream repository to make oldnet the default? What about newnet. ??Should we keep it at all? ??If we do, should we put it behind a use flag which would be off by default? Is there any advantage to using newnet over oldnet? If there aren't any advantages, we should not attempt to support it (even as an optional feature). Old-net by default, no use-flag for newnet; people can use EXTRA_ECONF if they *really* want to use it. If I go this route, I'll probably just get rid of newnet in the next release entirely. newnet is a single script, network, which sets up all of the static routes and static interfaces. It is small and simple, but the disadvantage of it is that you can't stop/start a single interface. William pgprtAh1uP6kS.pgp Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
On Sunday, September 19, 2010 21:22:06 William Hubbs wrote: On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote: On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs wrote: I suppose one question I need to ask is the oldnet vs newnet question. The git repository defaults to building and installing the newnet option, and we make oldnet the default in the ebuild. People migrating from stable will know the oldnet option, and this is the only way to configure the network scripts that is actually covered in our documentation. Do we want to switch the upstream repository to make oldnet the default? What about newnet. ??Should we keep it at all? ??If we do, should we put it behind a use flag which would be off by default? Is there any advantage to using newnet over oldnet? If there aren't any advantages, we should not attempt to support it (even as an optional feature). Old-net by default, no use-flag for newnet; people can use EXTRA_ECONF if they *really* want to use it. If I go this route, I'll probably just get rid of newnet in the next release entirely. newnet is a single script, network, which sets up all of the static routes and static interfaces. It is small and simple, but the disadvantage of it is that you can't stop/start a single interface. i suggested in a previous thread that we depreciate newnet if not kill it off entirely. the oldnet stuff should become the default once again. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Patch for python.eclass
On Sunday, September 19, 2010 21:18:51 Arfrever Frehtes Taifersar Arahesis
wrote:
-evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
the quotes in the 2nd one are useless. this should work the same:
eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
while you're in the process of cleaning things up, i know we dont have a rule
anywhere in terms of line length, but python.eclass has always struck me as a
file with incredibly excessive line length. comparing to other eclasses, it
has multiple lines in it longer than any single line in any other eclass.
i normally develop in a terminal with 170 cols (which i think is larger than
average), so i'm pretty lenient, but even python.eclass exceeds that multiple
times if not running close to it.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Patch for python.eclass
2010-09-20 03:45:14 Mike Frysinger napisał(a):
On Sunday, September 19, 2010 21:18:51 Arfrever Frehtes Taifersar Arahesis
wrote:
-evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
the quotes in the 2nd one are useless. this should work the same:
eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
The quotes are required:
$ PYTHONPATH_template=/usr/share/a b
$ eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
$ echo ${evaluated_PYTHONPATH}
/usr/share/a b
$ eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
$ echo ${evaluated_PYTHONPATH}
/usr/share/a b
while you're in the process of cleaning things up, i know we dont have a rule
anywhere in terms of line length, but python.eclass has always struck me as a
file with incredibly excessive line length. comparing to other eclasses, it
has multiple lines in it longer than any single line in any other eclass.
i normally develop in a terminal with 170 cols (which i think is larger than
average), so i'm pretty lenient, but even python.eclass exceeds that multiple
times if not running close to it.
python.eclass has many nested checks, loops etc.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Patch for python.eclass
On Sunday, September 19, 2010 22:53:31 Arfrever Frehtes Taifersar Arahesis wrote: 2010-09-20 03:45:14 Mike Frysinger napisał(a): while you're in the process of cleaning things up, i know we dont have a rule anywhere in terms of line length, but python.eclass has always struck me as a file with incredibly excessive line length. comparing to other eclasses, it has multiple lines in it longer than any single line in any other eclass. i normally develop in a terminal with 170 cols (which i think is larger than average), so i'm pretty lenient, but even python.eclass exceeds that multiple times if not running close to it. python.eclass has many nested checks, loops etc. so what ? actually look at the long lines. none of them need to be so long: lines 33 802 2226 - a large number of local variables that could easily be line wrapped otherwise we get 344+ cols. good luck figuring out what vars are at the tail end of that. lines 274 290 - a lot of checks in a single if statement that too could easily be line wrapped line 2354 - a really long ebegin message that is shown to users line 489 - a single sed statement that can easily be line wrapped lines 1158 1184 - a single inline python command that can easily be line wrapped -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Last rites - media-fonts/cronyx-fonts
On Sat, 18 Sep 2010 23:49:29 -0600 Ryan Hill dirtye...@gentoo.org wrote: # Ryan Hill dirtye...@gentoo.org (19 Sep 2010) # Mask for removal 20101019 (bug #304621). # Use font-cronyx-cyrillic instead. media-fonts/cronyx-fonts Turns out font-cronyx-cyrillic isn't a suitable replacement. Reverted. -- fonts, gcc-porting, we hold our breath, we spin around the world toolchain, wxwidgetsyou and me cling to the outside of the earth @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
В Вск, 19/09/2010 в 16:17 +0100, Mike Auty пишет: It should be possible to still maintain this distinction, something like: Version bump. Added feature foo. - -- Feature foo required a complete rewrite of src_install. And then the ChangeLog generation can happen separately. The problem with this method [...] Another problem that there is no way to alter ChangeLog. Since ChangeLogs are intended for users it's good idea to be able fix typos / add credits there and thus it's impossible to generate them from git commit messages. -- Peter.
