Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
On 22/05/12 07:58, Hans de Graaff wrote: > On Mon, 2012-05-21 at 21:50 -0500, Donnie Berkholz wrote: >> On 16:27 Sun 13 May , Mike Gilbert wrote: >>> To make ebuilds utilizing python-distutils-ng.eclass usable >> >> I didn't read any farther because I couldn't stop laughing. What will >> the next version of this eclass be called, -ng-ng? -really-ng? =) > > Given that Diego named the original ruby-ng eclass I would assume it > would be ruby-voyager, or python-distutils-voyager. ruby-enterprise and python-distutils-enterprise ;) We can also go the Borland way and have ruby-turbo & python-disutils-turbo. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category for (libre)office extensions: office-ext ?
On 05/05/12 21:01, Michael Orlitzky wrote: > On 05/05/12 14:40, Andreas K. Huettel wrote: >> >> Hiya, >> >> there's a growing culture of libreoffice extensions, and (with the help of >> an >> eclass prepared by scarabeus) it would be nice to get some of them into the >> portage tree. Now we have to decide where to put them. >> >> Suggestion: new category office-ext >> >> What do you think? > > No preference myself, but we already have e.g. app-emacs and www-apache > which (I guess?) reflect the fact that emacs lies under app-foo and > apache under www-bar. > > That would suggest app-libreoffice? +1 on app-libreoffice if they are only for LibreOffice. Can those extensions work with app-office/openoffice-bin? -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 01/05/12 14:36, Brian Harring wrote:
> On Mon, Apr 30, 2012 at 03:36:17PM +0200, Ulrich Mueller wrote:
>>>>>>> On Mon, 30 Apr 2012, Thomas Sachau wrote:
>>
>>> Krzysztof Pawlik schrieb:
>>>> On 30/04/12 10:39, Ulrich Mueller wrote:
>>>>>>> If the eclass doesn't work with FEATURES="collision-protect"
>>>>>>> then it needs to be fixed.
>>>>>
>>>>>> Long story short: older eclass compiled Python byte code in live
>>>>>> file system, new one does it in src_install so .pyo/.pyc gets
>>>>>> properly recorded, so the package *has to overwrite* files that
>>>>>> are not owned by anyone (no package owns them).
>>>>>
>>>>> The usual approach to this problem was to have some cleanup code
>>>>> in pkg_setup or pkg_preinst that would remove the old files.
>>>>
>>>> Interesting idea - I see two problems:
>>>> - how I would get the list of files for already installed version
>>>> (the file list can (and will) differ between versions)
>>
>>> Simple workaround in pkg_preinst (just example code, nothing to
>>> copy/paste):
>>
>>> if has_version < first_good_version ; then
>>> for i in $(find ${D} -name *.{pyc,pyo}) ; do
>>> [[ -e ${i/${D}/${ROOT}/} ]] && rm ${i/${D}/${ROOT}/}
>>> done
>>> fi
>>
>> This wouldn't work, because collision protection runs _before_
>> pkg_preinst.
>>
>> However, one could imagine a (somewhat dirty) workaround:
>> - At the end of src_install, rename all *.pyc and *.pyo in ${D} to
>> names that don't collide with the ones in ${ROOT}, so that collision
>> protection won't be triggered.
>> - At the beginning of pkg_preinst, rename them back to their original
>> names.
>> - Run above code.
>>
>>> Alternatively, you could take all .py files of the installed
>>> versions and blindly remove the pyo/pyc files for them in
>>> pkg_preinst (this should also prevent leaving dead files around).
>>
>> s/preinst/setup/ otherwise the same argument as above would apply.
>
> The checks above can misbehave.
>
> Pretty sure I've already suggested this route for this specific issue,
> but QA vars in the ebuild that portage can use for hints is a sane,
> non-cluster-fucky way to deal with this. Something along the lines of
> QA_COLLISION_PROTECT_IGNORE='*.pyc'
>
> Still has the potential for things going boom, but warnings can be
> setup for when collision-protect is on, and the portage version
> doesn't look new enough (those being details; point is the general
> approach).
I've sent an e-mail to gentoo-portage-dev@g.o with a patch that adds a new
variable that causes collision-protect/protect-owned to ignore specific file
patterns for unowned files. Behaviour is similar to already existing
COLLISION_IGNORE.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 11:47, Michał Górny wrote:
> On Mon, 30 Apr 2012 11:40:26 +0200
> Krzysztof Pawlik wrote:
>
>> On 30/04/12 11:30, Michał Górny wrote:
>>> On Mon, 30 Apr 2012 10:24:58 +0200
>>> Krzysztof Pawlik wrote:
>>>
>>>> On 30/04/12 08:57, Michał Górny wrote:
>>>>> Hello,
>>>>>
>>>>> Since lately Gentoo devs force you to replace collision-protect
>>>>> with protect-owned [1] and sometimes packages just spit out files
>>>>> randomly on the filesystem due to random errors, I thought it may
>>>>> be a good idea to provide a new feature limiting the locations
>>>>> where packages can install.
>>>>
>>>> You're not forced to do anything.
>>>
>>> I am not? How come random ebuilds die in pkg_pretend() for me then?
>>>
>>>>
>>>>> In order to do that, we should first compose a complete
>>>>> include/exclude list where packages can install. I'd suggest the
>>>>> following:
>>>>>
>>>>> + /bin
>>>>> + /boot (but maybe just subdirectories so packages can't overwrite
>>>>> kernels?)
>>>>> [potentially + /dev? but that's useful only when tmpfs isn't
>>>>> mounted]
>>>>> + /etc
>>>>> + /lib, /lib32, /lib64
>>>>> + /opt
>>>>> + /sbin
>>>>> [potentially + /service for ugly daemontools]
>>>>> + /usr
>>>>> + /var
>>>>> - /usr/local
>>>>> - /usr/portage
>>>>>
>>>>> What are your thoughts on this?
>>>>>
>>>>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=410691#c4
>>>>
>>>> I think it's feature creep - you can just set
>>>> INSTALL_MASK="/usr/local /usr/portage", no need for new features.
>>>>
>>>> PS. I (and few other folks) don't have /usr/portage.
>>>
>>> INSTALL_MASK won't make committing such an ebuild a fatal error. It
>>> will just hide problems.
>>
>> How would your proposed feature prevent ebuilds that install
>> something to /usr/local from being committed?
>
> If we enable this by default, devs will get errors for that.
Could it be added instead to repoman? I'm testing all ebuilds before committing
like this:
$ ebuild xhtml2pdf-0.0.3.ebuild manifest clean install
repoman could look at build.log or ${D} and warn if it can't do those checks.
>> Other valid case are private repos - I have a few ebuilds that
>> install stuff to / (proprietary stuff).
>
> Feel free to disable it. That's what FEATURES are for.
Yes, I could.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 10:39, Ulrich Mueller wrote: >>>>>> On Mon, 30 Apr 2012, Krzysztof Pawlik wrote: > >> On 30/04/12 10:12, Ulrich Mueller wrote: >>> If the eclass doesn't work with FEATURES="collision-protect" then it >>> needs to be fixed. > >> Long story short: older eclass compiled Python byte code in live >> file system, new one does it in src_install so .pyo/.pyc gets >> properly recorded, > > That's a good change. :) >> so the package *has to overwrite* files that are not owned by anyone >> (no package owns them). > > The usual approach to this problem was to have some cleanup code in > pkg_setup or pkg_preinst that would remove the old files. Interesting idea - I see two problems: - how I would get the list of files for already installed version (the file list can (and will) differ between versions) - PM has a manifest file that lists all installed file, it can check against it, not against live file system, so just removing the files may not be enough (just my speculations - I'm not sure of this) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 11:30, Michał Górny wrote: > On Mon, 30 Apr 2012 10:24:58 +0200 > Krzysztof Pawlik wrote: > >> On 30/04/12 08:57, Michał Górny wrote: >>> Hello, >>> >>> Since lately Gentoo devs force you to replace collision-protect with >>> protect-owned [1] and sometimes packages just spit out files >>> randomly on the filesystem due to random errors, I thought it may >>> be a good idea to provide a new feature limiting the locations >>> where packages can install. >> >> You're not forced to do anything. > > I am not? How come random ebuilds die in pkg_pretend() for me then? > >> >>> In order to do that, we should first compose a complete >>> include/exclude list where packages can install. I'd suggest the >>> following: >>> >>> + /bin >>> + /boot (but maybe just subdirectories so packages can't overwrite >>> kernels?) >>> [potentially + /dev? but that's useful only when tmpfs isn't >>> mounted] >>> + /etc >>> + /lib, /lib32, /lib64 >>> + /opt >>> + /sbin >>> [potentially + /service for ugly daemontools] >>> + /usr >>> + /var >>> - /usr/local >>> - /usr/portage >>> >>> What are your thoughts on this? >>> >>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=410691#c4 >> >> I think it's feature creep - you can just set INSTALL_MASK="/usr/local >> /usr/portage", no need for new features. >> >> PS. I (and few other folks) don't have /usr/portage. > > INSTALL_MASK won't make committing such an ebuild a fatal error. It > will just hide problems. How would your proposed feature prevent ebuilds that install something to /usr/local from being committed? Other valid case are private repos - I have a few ebuilds that install stuff to / (proprietary stuff). -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 11:28, Michał Górny wrote:
> On Mon, 30 Apr 2012 10:23:03 +0200
> Krzysztof Pawlik wrote:
>
>> On 30/04/12 10:12, Ulrich Mueller wrote:
>>>>>>>> On Mon, 30 Apr 2012, Michał Górny wrote:
>>>> Since lately Gentoo devs force you to replace collision-protect
>>>> with protect-owned [1] and sometimes packages just spit out files
>>>> randomly on the filesystem due to random errors, I thought it may
>>>> be a good idea to provide a new feature limiting the locations
>>>> where packages can install.
>>>
>>> If the eclass doesn't work with FEATURES="collision-protect" then it
>>> needs to be fixed.
>>
>> Long story short: older eclass compiled Python byte code in live file
>> system, new one does it in src_install so .pyo/.pyc gets properly
>> recorded, so the package *has to overwrite* files that are not owned
>> by anyone (no package owns them). I've talked to Zac and:
>>
>>>>>
>> There's not much else you can do. However, FEATURES="protect-owned" is
>> enabled by default, and it will work fine if the .pyo and .pyc files
>> are not owned by anything. I don't know why people use
>> FEATURES="collision-protect", but at least you can tell them that
>> they'll still have a reasonable level of protection from
>> FEATURES="protect-owned" (it protect against file collisions between
>> packages).
>> <<<
>>
>> If you want to help feel free to suggest *how* to fix it, patches are
>> especially welcomed :)
>
> Just make it warn or something like that. Or even fail but only when
> such files exist. There is no point in forcing me to disable
> collision-protect when the ebuilds were migrated already.
Does this work for you:
$ cvs diff python-distutils-ng.eclass
Index: python-distutils-ng.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/python-distutils-ng.eclass,v
retrieving revision 1.12
diff -u -r1.12 python-distutils-ng.eclass
--- python-distutils-ng.eclass 30 Apr 2012 08:25:31 - 1.12
+++ python-distutils-ng.eclass 30 Apr 2012 09:36:48 -
@@ -304,11 +304,10 @@
# Phase function: pkg_pretend
python-distutils-ng_pkg_pretend() {
if has "collision-protect" ${FEATURES}; then
- eerror "Due to previous eclass compiling Python files outside of
src_install"
- eerror "(and not recording resulting .pyc and .pyo files as
owned by any package)"
- eerror "merging this package with \"collision-protect\" in
FEATURES will result"
- eerror "in an error, please switch to using \"protect-owned\"
instead."
- die "\"collision-protect\" in FEATURES detected"
+ ewarn "Due to previous eclass compiling Python files outside of
src_install"
+ ewarn "(and not recording resulting .pyc and .pyo files as owned
by any package)"
+ ewarn "merging this package with \"collision-protect\" in
FEATURES may result"
+ ewarn "in an error, please switch to using \"protect-owned\"
instead."
fi
}
(it's s/eerror/ewarn/ & die removal).
I'm still wondering how many people will read this warning when they hit
collision error.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 08:57, Michał Górny wrote: > Hello, > > Since lately Gentoo devs force you to replace collision-protect with > protect-owned [1] and sometimes packages just spit out files randomly > on the filesystem due to random errors, I thought it may be a good idea > to provide a new feature limiting the locations where packages can > install. You're not forced to do anything. > In order to do that, we should first compose a complete include/exclude > list where packages can install. I'd suggest the following: > > + /bin > + /boot (but maybe just subdirectories so packages can't overwrite > kernels?) > [potentially + /dev? but that's useful only when tmpfs isn't mounted] > + /etc > + /lib, /lib32, /lib64 > + /opt > + /sbin > [potentially + /service for ugly daemontools] > + /usr > + /var > - /usr/local > - /usr/portage > > What are your thoughts on this? > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=410691#c4 I think it's feature creep - you can just set INSTALL_MASK="/usr/local /usr/portage", no need for new features. PS. I (and few other folks) don't have /usr/portage. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On 30/04/12 10:12, Ulrich Mueller wrote: >>>>>> On Mon, 30 Apr 2012, Michał Górny wrote: >> Since lately Gentoo devs force you to replace collision-protect with >> protect-owned [1] and sometimes packages just spit out files randomly >> on the filesystem due to random errors, I thought it may be a good idea >> to provide a new feature limiting the locations where packages can >> install. > > If the eclass doesn't work with FEATURES="collision-protect" then it > needs to be fixed. Long story short: older eclass compiled Python byte code in live file system, new one does it in src_install so .pyo/.pyc gets properly recorded, so the package *has to overwrite* files that are not owned by anyone (no package owns them). I've talked to Zac and: >>> There's not much else you can do. However, FEATURES="protect-owned" is enabled by default, and it will work fine if the .pyo and .pyc files are not owned by anything. I don't know why people use FEATURES="collision-protect", but at least you can tell them that they'll still have a reasonable level of protection from FEATURES="protect-owned" (it protect against file collisions between packages). <<< If you want to help feel free to suggest *how* to fix it, patches are especially welcomed :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: location of portage tree
On 27/03/12 21:17, Ian Stakenvicius wrote:
> On 27/03/12 03:05 PM, William Hubbs wrote:
>> All,
>
>> I know this has come up before, but I don't really recall what the
>> specific objections were.
>
>> IMO the portage directory doesn't belong under /usr at all. I was
>> chatting with another developer who uses
>> /var/cache/portage/{tree,distfiles}, and I'm thinking about
>> switching my default setup to do this.
>
>> I realize that historically the portage tree has been installed
>> under /usr, but Can we consider changing this default for new
>> installations and providing instructions for users for how to get
>> the portage tree out of /usr? William
>
>
> IIRC, 'cache' can be a volatile storage area, that is, anything in it
> can be removed. One's system is b0rked (or at least, portage is) if
> /path/to/portage/profiles goes missing. I wholeheartedly agree that
> distfiles should be moved to /var , but I think the portage tree
> shouldn't be there..
>
> (at least, shouldn't be in /var/cache/ ; maybe /var/lib/ ? of course
> then we're colliding with the existing use of /var/lib/portage ...)
Portage tree is a kind of database (I know, I know -- long shot), so maybe
/var/db/portage for the tree and /var/cache/portage/distfiles (or drop portage
from that path) for distfiles?
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 26/03/12 18:11, Krzysztof Pawlik wrote:
> On 26/03/12 09:20, justin wrote:
>> On 25/03/12 20:56, Krzysztof Pawlik wrote:
>>> On 28/02/12 22:13, Krzysztof Pawlik wrote:
>>>> If there are no objections then during the weekend (March 3, 4) I will add
>>>> this
>>>> to portage (after finishing remaining TODO items, PyPy requires 4G of
>>>> RAM(!!)).
>>>
>>> Hello,
>>>
>>> Slightly late due to Real Life™ but finally it's in the main tree :)
>>>
>>> (and yes - I've tested it with pypy - works as expected :)
>>>
>>
>> Hi,
>>
>> is there any documentation beside the man page somewhere?
>
> No.
>
>> I tried to port some ebuilds but as soon I set
>>
>> PYTHON_COMPAT="python2_7 python2_6 python2_5 pypy1_8"
>>
>> inherit python-distutils-ng
>>
>> I get
>>
>> REQUIRED_USE: USE flag 'python_targets_python3_1' is not in IUSE
>>
>> Did I do something wrong, or is there something not straight in the eclass?
>
> Can you send me the whole ebuild off-list?
>
> There are two ebuilds using the eclass that I've used as tests:
> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=tree;f=dev-python;h=f1a8e00e3e6df33806d8972c8898f1187163bd3d;hb=HEAD
Ok, found a bug: REQUIRED_USE can't contain elements not in USE, so if you
excluded python3_1 from PYTHON_COMPAT it didn't appear in IUSE too ->
REQUIRED_USE contained invalid value. Fixed by below patch:
nelchael@s-lappy ~/.../gentoo-x86/eclass$ cvs diff
Index: python-distutils-ng.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/python-distutils-ng.eclass,v
retrieving revision 1.2
diff -u -r1.2 python-distutils-ng.eclass
--- python-distutils-ng.eclass 26 Mar 2012 06:12:53 - 1.2
+++ python-distutils-ng.eclass 26 Mar 2012 16:20:52 -
@@ -105,11 +105,11 @@
esac
}
-required_use_str=" || (
- python_targets_python2_5 python_targets_python2_6
python_targets_python2_7
- python_targets_python3_1 python_targets_python3_2
- python_targets_jython2_5
- python_targets_pypy1_7 python_targets_pypy1_8 )"
+required_use_str=""
+for impl in ${PYTHON_COMPAT}; do
+ required_use_str="${required_use_str} python_targets_${impl}"
+done
+required_use_str=" || ( ${required_use_str} )"
if [[ "${PYTHON_OPTIONAL}" = "yes" ]]; then
IUSE+="python"
REQUIRED_USE+=" python? ( ${required_use_str} )"
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 26/03/12 09:20, justin wrote: > On 25/03/12 20:56, Krzysztof Pawlik wrote: >> On 28/02/12 22:13, Krzysztof Pawlik wrote: >>> If there are no objections then during the weekend (March 3, 4) I will add >>> this >>> to portage (after finishing remaining TODO items, PyPy requires 4G of >>> RAM(!!)). >> >> Hello, >> >> Slightly late due to Real Life™ but finally it's in the main tree :) >> >> (and yes - I've tested it with pypy - works as expected :) >> > > Hi, > > is there any documentation beside the man page somewhere? No. > I tried to port some ebuilds but as soon I set > > PYTHON_COMPAT="python2_7 python2_6 python2_5 pypy1_8" > > inherit python-distutils-ng > > I get > > REQUIRED_USE: USE flag 'python_targets_python3_1' is not in IUSE > > Did I do something wrong, or is there something not straight in the eclass? Can you send me the whole ebuild off-list? There are two ebuilds using the eclass that I've used as tests: http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=tree;f=dev-python;h=f1a8e00e3e6df33806d8972c8898f1187163bd3d;hb=HEAD -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 26/03/12 09:21, justin wrote: > On 25/03/12 20:56, Krzysztof Pawlik wrote: >> On 28/02/12 22:13, Krzysztof Pawlik wrote: >>> If there are no objections then during the weekend (March 3, 4) I will add >>> this >>> to portage (after finishing remaining TODO items, PyPy requires 4G of >>> RAM(!!)). >> >> Hello, >> >> Slightly late due to Real Life™ but finally it's in the main tree :) >> >> (and yes - I've tested it with pypy - works as expected :) >> > > Hi, > > is it okay if I start fixing things for prefix? Yes, by all means - please send the diff to this thread. > jusitn ^^ your e-mail says "justin" -- typo? -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 28/02/12 22:13, Krzysztof Pawlik wrote: > If there are no objections then during the weekend (March 3, 4) I will add > this > to portage (after finishing remaining TODO items, PyPy requires 4G of > RAM(!!)). Hello, Slightly late due to Real Life™ but finally it's in the main tree :) (and yes - I've tested it with pypy - works as expected :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 22:57, Alexandre Rostovtsev wrote:
> On Wed, 2012-02-29 at 21:24 +0100, Krzysztof Pawlik wrote:
>> On 29/02/12 20:51, Alexandre Rostovtsev wrote:
>>> The proposed eclass omits three features from python.eclass which are
>>> heavily used in the gnome stack.
>>
>> Correct me if I'm wrong, but Gnome doesn't use standard distutils?
>
> Gnome is mostly written in C and therefore uses standard autotools :)
Ok, thank you for this information.
>>> Second, there doesn't seem to be any support for packages that do not
>>> install in python's site-packages and do not allow multiple python ABIs.
>>> If I have, for example, a package that installs python modules
>>> in /usr/lib/appname or /usr/share/appname, how can I specify that
>>> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but
>>> something like PYTHON_TARGETS="python2.7 python3.2" is not?
>>
>> You're correct, note that I've stressed that this eclass is mainly for
>> distutils-based packages. I'm not using Gnome, so can you provide some
>> package
>> examples that I can look at?
>>
>>
>> If package decides to use given language then please, please play by the
>> rules
>> set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN,
>> PHP
>> -> PEAR).
>>
>> I don't like installing Python code outside of site-packages, the only
>> exception
>> to that rule is portage (at least for now).
>>
>
> Some non-python packages allow python-based plugins. Obviously these
> plugins live in the package's plugin directory (not in python's
> site-packages) and use the package's main build system (not distutils),
> and multiple python ABIs cannot be supported because that would result
> in colliding plugins. Typical examples are app-editors/gedit,
> media-gfx/gimp, media-sound/rhythmbox, or media-video/totem.
>
> Some packages install a C library that links to a specific version of
> libpython or that defines a particular python version string at compile
> time, making it impossible to use the package with multiple python ABIs.
> Examples I know are dev-libs/libpeas and dev-python/nautilus-python.
>
> And then there are packages which could support e.g. multiple python2
> ABIs in theory, but doing so in practice would require a fair bit of
> patching, taking substantial effort with no real benefit for end users.
> An example that springs to mind here is gnome-extra/zeitgeist.
I see - so it's the same case as with KDE (like Andreas wrote) - it's actually
not a "python package" but rather an embedded Python. That's very different case
than I'm targeting with this eclass (at least for now).
>> I'd be happy to hear how to solve this - what prefix or suffix to use? One
>> way
>> would be quite trivial: if only one implementation is enabled do not create
>> script-${impl}, go with single file, does that sound good?
>
> That would be the ideal solution.
Ok, I've implemented this solution, now if one implementation is enabled there
will be only one script, no foo-IMPL mangling. I've added also ability to
install the script in other directory than /usr/bin. Hope this solves this case.
Thank you for your comments and suggestions :)
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 22:08, Andreas K. Huettel wrote: > Am Mittwoch 29 Februar 2012, 21:24:49 schrieb Krzysztof Pawlik: >>> Second, there doesn't seem to be any support for packages that do not >>> install in python's site-packages and do not allow multiple python ABIs. >>> If I have, for example, a package that installs python modules >>> in /usr/lib/appname or /usr/share/appname, how can I specify that >>> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but >>> something like PYTHON_TARGETS="python2.7 python3.2" is not? >> >> You're correct, note that I've stressed that this eclass is mainly for >> distutils-based packages. I'm not using Gnome, so can you provide some >> package examples that I can look at? >> >> >> If package decides to use given language then please, please play by the >> rules set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> >> CPAN, PHP -> PEAR). >> >> I don't like installing Python code outside of site-packages, the only >> exception to that rule is portage (at least for now). >> > > We will hit the same problem with KDE (actually we already hit it): it has > various types of scripting support, and each installs a KDE library linked to > whatever language interpreter. > > (Now, that library- is it a Python/Ruby library or a KDE library? Because it > is at the proper place for KDE stuff :) > > It's not just about calling an external language but also about embedding the > interpreter for in-app scripting... and KDE rather heavily relies on python. I agree with last sentence - it's about embedding Python/Ruby/Foo, *this eclass is about installing packages for Python*. Compiling against an implementation is something completely different -- for example try building against Jython. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 20:51, Alexandre Rostovtsev wrote:
> On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote:
>> Hello,
>>
>> After some work during weekend on Python packages I've decided to start a
>> rewrite of Python/distutils eclass for installing Python packages. My main
>> goal
>> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team
>> for
>> your great work!). Python team members already contributed comments and
>> suggestions and helped me to make the eclass better, thank you!
>>
>> Highlights:
>> - *SIMPLE*next
>> - uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
>> - EAPI4 required, uses REQUIRED_USE
>> - <400 lines of code including documentation
>> - should work for >95% of packages (my educated guess)
>> - did I mention it's *SIMPLE*?
>> - easy to maintain & read so it's also easy to use
>>
>> Important thing: I'm not aiming at having 100% functionality of current
>> python.eclass+distutils.eclass in the new one, I think that simplicity is
>> more
>> important that supporting every possible, obscure case that's out there.
>>
>> I'm attaching the eclass itself and two ebuilds using it, code is also
>> available
>> in my overlay at
>> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
>>
>> If there are no objections then during the weekend (March 3, 4) I will add
>> this
>> to portage (after finishing remaining TODO items, PyPy requires 4G of
>> RAM(!!)).
>
> The proposed eclass omits three features from python.eclass which are
> heavily used in the gnome stack.
Correct me if I'm wrong, but Gnome doesn't use standard distutils?
Regardless of this eclass you can still use python.eclass, it not going anywhere
anytime soon (just like I wrote in one of previous e-mails).
> First, it does not set EPYTHON, which is a problem for the many packages
> whose build systems execute /usr/bin/python and assume that it's a
> generic python2 or the same version of python2.x for which the package
> is being built.
Setting EPYTHON is not a problem -- just another variable.
> Second, there doesn't seem to be any support for packages that do not
> install in python's site-packages and do not allow multiple python ABIs.
> If I have, for example, a package that installs python modules
> in /usr/lib/appname or /usr/share/appname, how can I specify that
> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but
> something like PYTHON_TARGETS="python2.7 python3.2" is not?
You're correct, note that I've stressed that this eclass is mainly for
distutils-based packages. I'm not using Gnome, so can you provide some package
examples that I can look at?
If package decides to use given language then please, please play by the rules
set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP
-> PEAR).
I don't like installing Python code outside of site-packages, the only exception
to that rule is portage (at least for now).
> Third, python-distutils-ng_doscript() installs only one file at a time
> (no built-in support for multiple files at a time or for recursing
> through a directory tree),
Yes, that why bash has `for' loop ;)
> installs it only in /usr/bin (a package might
> want it in e.g. /usr/libexec or /usr/share/appname/scripts)
Yes, I might add --destdir (or something like that) later on.
> and always
> creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin
> for the common case of programs that do not support multiple python
> ABIs). As a result, it is far less useful than python.eclass's
> python_convert_shebangs().
Yes, that "pollutes" this name space, but I'm not buying this argument. Do you
know how CVS and .svn "pollute" my tab-completion list? I even set FIGNORE so I
can live with it.
I'd be happy to hear how to solve this - what prefix or suffix to use? One way
would be quite trivial: if only one implementation is enabled do not create
script-${impl}, go with single file, does that sound good?
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python
On 29/02/12 09:11, Dirkjan Ochtman wrote: > On Tue, Feb 28, 2012 at 22:13, Krzysztof Pawlik wrote: >> If there are no objections then during the weekend (March 3, 4) I will add >> this >> to portage (after finishing remaining TODO items, PyPy requires 4G of >> RAM(!!)). > > Can we perhaps just name it python-r2 rather than python-distutils-ng? > Seems descriptive enough... Yes and no - it's named python-distutils because main focus was this combination, it can work for other cases too, it's just that it combines functionality from both old eclasses. Besides I like the name, but I can be convinced to name it python-r2.eclass. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 08:49, "Paweł Hajdan, Jr." wrote: > On 2/28/12 10:13 PM, Krzysztof Pawlik wrote: >> Highlights: >> - <400 lines of code including documentation >> - should work for >95% of packages (my educated guess) >> - did I mention it's *SIMPLE*? >> - easy to maintain & read so it's also easy to use > > This is awesome! Compare that to over 3000 LOC of python.eclass. :) Count distutils.eclass too: $ wc -l python-distutils-ng.eclass python.eclass distutils.eclass 364 python-distutils-ng.eclass 3168 python.eclass 592 distutils.eclass >> Important thing: I'm not aiming at having 100% functionality of current >> python.eclass+distutils.eclass in the new one, I think that simplicity is >> more >> important that supporting every possible, obscure case that's out there. > > Exactly. > >> If there are no objections then during the weekend (March 3, 4) I will add >> this >> to portage (after finishing remaining TODO items, PyPy requires 4G of >> RAM(!!)). > > I second this so much (didn't review the eclass in detail, but it's > obviously better than python.eclass). Thank you :) > What's the plan to retire python.eclass? I'm not entirely sure - there's no pressure to migrate off it, both can coexist happily. I don't think it can be retired until be have all functionality from python.eclass+distutils.eclass somewhere (especially tests!). If the package is distutils-based then migration should be pretty painless and new packages (or version/revision bumps) can start using it as soon as it hits portage. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python
On 29/02/12 06:13, Mike Gilbert wrote:
> On Tue, Feb 28, 2012 at 4:13 PM, Krzysztof Pawlik wrote:
>> Hello,
>>
>> After some work during weekend on Python packages I've decided to start a
>> rewrite of Python/distutils eclass for installing Python packages. My main
>> goal
>> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team
>> for
>> your great work!). Python team members already contributed comments and
>> suggestions and helped me to make the eclass better, thank you!
>>
>> Highlights:
>> - *SIMPLE*next
>> - uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
>> - EAPI4 required, uses REQUIRED_USE
>> - <400 lines of code including documentation
>> - should work for >95% of packages (my educated guess)
>> - did I mention it's *SIMPLE*?
>> - easy to maintain & read so it's also easy to use
>>
>> Important thing: I'm not aiming at having 100% functionality of current
>> python.eclass+distutils.eclass in the new one, I think that simplicity is
>> more
>> important that supporting every possible, obscure case that's out there.
>>
>> I'm attaching the eclass itself and two ebuilds using it, code is also
>> available
>> in my overlay at
>> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
>>
>> If there are no objections then during the weekend (March 3, 4) I will add
>> this
>> to portage (after finishing remaining TODO items, PyPy requires 4G of
>> RAM(!!)).
>>
>> --
>> Krzysztof Pawlikkey id: 0xF6A80E46
>> desktop-misc, java, vim, kernel, python, apache...
>>
>
> # Phase function: src_unpack
> python-distutils-ng_src_unpack() {
> [[ "${PYTHON_OPTIONAL}" = "yes" ]] && { use python || return; }
>
> if type python_unpack &> /dev/null; then
> # This should not run anything specific to any single Python
> # implementation, keep it generic:
> python_unpack_all
> else
> [[ -n ${A} ]] && unpack ${A}
> fi
> }
>
> I think you meant to write "if type python_unpack_all".
>
> More to the point, I don't actually understand why this function
> exists. It doesn't actually do anything that default_src_unpack does
> not do already. Exporting it will clobber any vcs eclasses if the
> inherit order is wrong.
You're right, I've killed the python-distutils-ng_src_unpack() function.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 04:21, Sergei Trofimovich wrote:
> On Tue, 28 Feb 2012 22:13:36 +0100
> Krzysztof Pawlik wrote:
>
>> I'm attaching the eclass itself and two ebuilds using it, code is also
>> available
>> in my overlay at
>> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
> Nice!
>
>> eclass/python-distutils-ng.eclass
>> 236 # TODO: Pick default implementation
>> 237 for impl in python{2_7,2_6,2_5,3_2,2_1} pypy{1_8,1_7}
>> jython2_5; do
>
> Looks like 2_1 should be 3_1
Yes! Thank you.
> minor suggestion:
> s/_python-distutils-ng_run_for_all_impls/_python-distutils-ng_run_for_each_impl/g
LGTM, changed.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 09:17, Fabian Groffen wrote:
> On 28-02-2012 22:13:36 +0100, Krzysztof Pawlik wrote:
> [good stuff]
>
> Much appreciated!
>
> From 2nd example ebuild:
>> python_install_all() {
>> rm -f "${D}/usr/bin"/*.py || die
>
> s/D/ED/ here for Prefix :)
>
> I haven't checked the eclass in detail, but did you intend to make it
> Prefix aware at all? I guess someone from us should test your work.
Yes, please - take a look at my overlay (it always has the latest version) and
check for prefix related issues. Take a look also at xlwt and xlrd in dev-python
in the same overlay.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] New eclass for Python
Hello,
After some work during weekend on Python packages I've decided to start a
rewrite of Python/distutils eclass for installing Python packages. My main goal
was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team for
your great work!). Python team members already contributed comments and
suggestions and helped me to make the eclass better, thank you!
Highlights:
- *SIMPLE*next
- uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
- EAPI4 required, uses REQUIRED_USE
- <400 lines of code including documentation
- should work for >95% of packages (my educated guess)
- did I mention it's *SIMPLE*?
- easy to maintain & read so it's also easy to use
Important thing: I'm not aiming at having 100% functionality of current
python.eclass+distutils.eclass in the new one, I think that simplicity is more
important that supporting every possible, obscure case that's out there.
I'm attaching the eclass itself and two ebuilds using it, code is also available
in my overlay at
http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
If there are no objections then during the weekend (March 3, 4) I will add this
to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)).
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header$
EAPI="4"
inherit python-distutils-ng
DESCRIPTION="Python library to create spreadsheet files compatible with Excel"
HOMEPAGE="http://pypi.python.org/pypi/xlwt";
SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
LICENSE="BSD"
SLOT="0"
KEYWORDS="~amd64 ~ppc-aix ~hppa-hpux ~ia64-hpux ~x86-interix ~x86-linux
~sparc-solaris ~x86-solaris"
IUSE="examples"
DEPEND=""
RDEPEND=""
python_prepare_all() {
sed -i \
-e "s,'doc,# 'doc,g" \
-e "s,'exa,# 'exa,g" \
setup.py || die
}
python_install_all() {
dohtml xlwt/doc/*.html
if use examples; then
insinto "/usr/share/doc/${PF}"
doins -r xlwt/examples
fi
}
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header$
EAPI="4"
inherit python-distutils-ng
DESCRIPTION="Library for developers to extract data from Microsoft Excel (tm)
spreadsheet files"
HOMEPAGE="http://pypi.python.org/pypi/xlrd";
SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
LICENSE="BSD"
SLOT="0"
KEYWORDS="~amd64 ~ppc-aix ~hppa-hpux ~ia64-hpux ~x86-interix ~x86-linux
~sparc-solaris ~x86-solaris"
IUSE="examples"
DEPEND=""
RDEPEND=""
python_prepare_all() {
sed -i \
-e "s,'doc,# 'doc,g" \
-e "s,'exa,# 'exa,g" \
setup.py || die
}
python_install_all() {
rm -f "${D}/usr/bin"/*.py || die
python-distutils-ng_doscript scripts/runxlrd.py
dohtml xlrd/doc/*.html
if use examples; then
insinto "/usr/share/doc/${PF}"
doins -r xlrd/examples
fi
}
# Copyright 2009-2012 Gentoo Foundation.
# Distributed under the terms of the GNU General Public License v2
# $Header$
# This file contains descriptions of PYTHON_TARGETS USE_EXPAND flags.
python2_5 - Build with Python 2.5
python2_6 - Build with Python 2.6
python2_7 - Build with Python 2.7
python3_1 - Build with Python 3.1
python3_2 - Build with Python 3.2
jython2_5 - Build with Jython 2.5
pypy1_7 - Build with PyPy 1.7
pypy1_8 - Build with PyPy 1.8
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header$
# @ECLASS: python-distutils-ng
# @MAINTAINER:
# Python herd
# @AUTHOR:
# Author: Krzysztof Pawlik
# @BLURB: An eclass for installing Python packages using distutils with proper
# support for multiple Python slots.
# @DESCRIPTION:
# The Python eclass is designed to allow an easier installation of Python
# packages and their incorporation into the Gentoo Linux system.
#
# TODO: Document implementations!
# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
# This variable contains a space separated list of implementations (see above) a
# package is compatible to. It must be set before the `inherit' call. The
# default is to enable all implementations.
if [[ -z "${PYTHON_COMPAT}" ]]; then
# Default: pure python, support all implementations
PYTHON_COMPAT=" python2_5 python2_6 python2_7"
PYTHON_COMPAT+=" python3_1 python3_2"
PYTHON_COMPAT+=" jython2
[gentoo-dev] Last rites: dev-python/pisa
# Krzysztof Pawlik (27 Jan 2012) # Deprecated, please migrate your code to dev-python/xhtml2pdf. # Removal by end of February. dev-python/pisa -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06/08/11 16:13, Fabian Groffen wrote: > There probably are drawbacks to this system as well. I, however, only > see big advantages for the moment. > Comments, thoughts, ideas welcome. To be honest I don't like that idea. I don't see any benefits from doing so: - history per package - huh? git log for specific path/file works, pulling all the history for whole repository is one-time thing, does not happen often, Nirbheek already pointed out some history-sharing issues - tree generation is dynamic - actually I think this is a disadvantage, it has a nice potential to eat a lot of resources on master rsync server, also having different "flavours" of the tree only brings in added complexity - per package branches - I like overlays, I couldn't care less about branches for single packages :) So: - having it all in single repository means that I need to care only about one thing, not around 14956 of them - git was designed to be efficient with large repositories, use this ability - KISS -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I'm looking for a mentor
On 04/08/11 21:14, Kfir Lavi wrote: [ snip ] > Hi Markos, > I'm contacting you to let you know that I'm still interested in your > mentoring. > I find it very hard to concentrate on the quizzes you sent me, as I'm deeply > at work. > I'm returning home everyday at ~22:00. > I also have a family and a small 1 year old child, that needs my attention > ;-) > I did small part of the test. > Do you want me to send you the test as is and we'll take it few questions at > a time, or you need it full? Please take if off-list, contact Markos directly. Thank you. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due bangert retirement
On 20/07/11 19:39, Pacho Ramos wrote: > Due bangert retirement the following packages need a new maintainer: > > net-misc/openntpd I'll take openntpd. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-process/acct/files: acct.initd-r1 acct.logrotate-r1
On 31/05/11 15:28, Jeroen Roovers wrote: > On Tue, 31 May 2011 11:00:27 +0100 > Markos Chandras wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 30/05/2011 12:39 μμ, Jeroen Roovers (jer) wrote: >>> jer 11/05/30 11:39:21 >>> >>> Removed: acct.initd-r1 acct.logrotate-r1 >>> Log: >>> Move to stable since there was no functional difference anyway. >>> >>> (Portage version: 2.2.0_alpha37/cvs/Linux x86_64) >>> >> >> Hi Jer, >> >> I've noticed you did not update the ChangeLog in this commit. The new >> policy[1] requires to update the ChangeLog on every commit no matter >> how important or trivial it is. Please keep that in mind on your >> future commits. >> >> Regards, >> >> [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html > > You are joking right? Nope, check out thread 'Council May Summary: Changes to ChangeLog handling' (archives.g.o seems to be missing the whole thread). -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Resigning from apache herd
On 02/18/11 19:02, Benedikt Böhm wrote: > due to work and family related time shortage i'm not able to lead the > apache team any longer and have removed myself from the herd. there > are a lot of open bugs, many of them results from the various > autotools/libtool hacks added by upstream. any help is appreciated i > guess and a new apache team lead should be found/elected by the > remaining two members nelchael and trapni if they desire to still work > on apache ebuilds. Thanks to Benedikt's work we're in pretty good shape overall with regards to Apache. Nevertheless we need more manpower -- there are 52 open bugs right now - some quite easy (version bump), some slightly harder (LDFLAGS issues), we have even some cryptic ones (hard to reproduce, etc). If you have some time and would like to devote to keeping Apache in good shape on Gentoo join the Apache team :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
On 02/14/11 07:13, Jacob Godserv wrote: > On Thu, Feb 10, 2011 at 14:36, Diego Elio Pettenò wrote: >> Remember that for *all* QA masking, the rule is simple > > Could you point me to the Q/A policies and rules? I'm curious now, > seeing this intense discussion about what's right for Q/A, what the > official Q/A docs say. > It's available here: http://www.gentoo.org/proj/en/qa/index.xml -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
On 02/10/11 21:09, Samuli Suominen wrote: > On 02/10/2011 10:01 PM, Krzysztof Pawlik wrote: >> I don't exactly see how what you've written is of any relevance to the main >> point of this - the original issue was *extremely* simple: whenever >> maintainer's >> (active, inactive, last maintainer, whatever) ACK should be mentioned in the >> message that ends up in p.mask -- according to me and Andreas: yes. Look at >> it >> as a kind of 'Signed-Off'. > > it's already ack'd by 185475, 211262, 247268, 276220, 287751, 293501, > 298109, 301729, 308801, 311763, 311765, 328691, 340605, 348483, 352506, > 237366, and 250054. no futher justification is required. No. *None* of those bugs even *mentions* QA, the only thing I see is that peper@ really wants to be spanked (possibly with a sledgehammer or something else of appropriate size and mass). If Piotr doesn't want to maintain those packages he should send out an e-mail that there are a few packages up for grabs, not sit on those bugs for >12 months. If we can't get new maintainer (or proxy-maintainer) then you're free to kill them. Anyway: looks like Ryan wants to take a look at those packages. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Lastrite: app-pda/libopensync and reverse dependencies
On 02/10/11 20:36, Diego Elio Pettenò wrote: > Il giorno gio, 10/02/2011 alle 19.44 +0100, Krzysztof Pawlik ha scritto: >> >> I don't agree with that - QA doesn't give anyone a silver bullet for >> killing >> whatever you want (or whatever you think should die). Maintainer must >> be >> *always* notified/pinged/mailed/im'ed/phoned/poked when his package is >> going to >> be masked & removed, if he's responsive then getting his ACK on the >> matter >> shouldn't be a problem, if not... at least you've tried. > > Please make up your mind on what you don't agree with. You've just removed the relevant quote, so let me add it again: Diego: Sorry but it really matters very little whether maintainer acks at all, *if the package fails to build*. Andreas: Me: I don't agree with that ... [cut] Is that clear enough? > We don't need the ACK but we don't go around masking packages just > because we feel like it. What gets the "Masked for removal by QA" > treatment doesn't need an ACK because it's always stuff that was left > untouched for months if not years. > > To rephrase it so that you can get it: > > WE DON'T GO AROUND REMOVING ACTIVELY MAINTAINED PACKAGES. (your caps lock is on, please turn it off, thank you) > But when the package is unmaintained for months, we don't _need_ the > ACK, nor we'd have to say "we're given the go by the maintainer" or > "maintainer timeout". We simply don't do that if there *is* an active, > interested maintainer. [cut] I don't exactly see how what you've written is of any relevance to the main point of this - the original issue was *extremely* simple: whenever maintainer's (active, inactive, last maintainer, whatever) ACK should be mentioned in the message that ends up in p.mask -- according to me and Andreas: yes. Look at it as a kind of 'Signed-Off'. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Lastrite: app-pda/libopensync and reverse dependencies
On 02/10/11 19:02, Andreas K. Huettel wrote: >> Sorry but it really matters very little whether maintainer acks at all, *if >> the package fails to build*. I don't agree with that - QA doesn't give anyone a silver bullet for killing whatever you want (or whatever you think should die). Maintainer must be *always* notified/pinged/mailed/im'ed/phoned/poked when his package is going to be masked & removed, if he's responsive then getting his ACK on the matter shouldn't be a problem, if not... at least you've tried. >> We're not talking about a single problem with a single package. > > Yes, you are completely right regarding the ebuilds. I do not dispute at all > that masking them is a correct way of action. > > However we are talking about interaction of human beings here. > > What I was trying to say: _If_ you have coordinated this with the maintainer, > it should be worth the effort to add two words to the email just to mention > this. It would even strengthen your argumentative position! > > In general, we have had the discussion a few times here already whether > briefness/conciseness or politeness/additional information is more important. > I agree that this may be a cultural thing. But then, normally the consensus > is to rather err on the side of caution... It's usually better to be overly verbose in such cases, so yes: if maintainer said it's ok then please mention that in mask message - it's just few keystrokes more. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 11/08/10 00:08, Krzysztof Pawlik wrote:
> On 11/07/10 13:07, Mike Auty wrote:
>> On 07/11/10 02:40, Donnie Berkholz wrote:
>>> I read it more closely and realized I was a little confused by the way
>>> you listed all the bullet points mixing together benefits and problems.
>>
>>> So I'll try again: if you really want to do this change, you might want
>>> to consider adding a mercurial-2.eclass instead. Eclasses of this nature
>>> (svn, git, hg, etc) tend to be broadly used outside the tree as well as
>>> within, so breaking backwards compatibility can be a real problem. A new
>>> versioned eclass allows for a much more gradual transition.
>>
>>
>> I've only just jumped into the conversation, but the obvious question
>> is, why not just use ${S} as the location of the working directory
>> (rather than "${WORKDIR}/${workdir}")? That way, if it's set old
>> ebuilds still work, and if it's not set, new ebuilds get the benefit of
>> using ${S}? I can only see a problem with this if there's somewhere
>> that the value of the working directory needs to be known before any of
>> the phases...
>
> Hm.. good idea :) I'm attaching modified patch that uses ${S} by default, so
> it
> will improve the situation and at the same time it won't break existing
> ebuilds.
> Thanks Mike for this suggestion.
I've just committed this version.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 11/10/10 18:16, William Hubbs wrote:
> On Mon, Nov 08, 2010 at 10:05:17PM +0200, Petteri R??ty wrote:
>> On 11/08/2010 06:17 AM, Donnie Berkholz wrote:
>>> On 16:42 Sun 07 Nov , Petteri R??ty wrote:
>>>> On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
>>>>> Hello,
>>>>>
>>>>> I'm sending this patch for discussion, what it changes? The change is to
>>>>> where
>>>>> the final clone of repository will be placed, it used to be
>>>>> ${WORKDIR}/${module}
>>>>> (where module usually is the last component of source URI) to
>>>>> ${WORKDIR}/${P}
>>>>> (essentially ${S}). This has few effects:
>>>>> - ebuilds using mercurial.eclass don't need to set S any longer
>>>>> - mercurial.eclass behaves more like git.eclass
>>>>> - it breaks all existing ebuilds using this eclass
>>>>
>>>> Which means that the doing the chance is not allowed as eclasses must
>>>> remain backwards compatible.
>>>
>>> Is that really still the case now that full environments have been saved
>>> for a number of years? Clearly breaking things is unacceptable, but I
>>> could envision someone simultaneously updating the eclass and all
>>> consumers.
>>>
>>
>> There's no full environment saved before the package is installed and I
>> don't see why we should break overlays.
>
> I didn't think we had to care about overlays since they aren't the main
> tree? After all, how can we be sure what is happening in all overlays
> out there?
Annoying a lot of users is not a good idea anyway :)
> I could see this, like Donnie says, if he wasn't going to fix all of the
> ebuilds. However I don't see a problem with it since he said he is
> going to fix all of the ebuilds.
Yes, but let's drop the issue - last version of patch doesn't break anything -
it uses ${S} which means it will work equally well for old ebuilds and also will
achieve what I want (to respect ${S}).
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 11/07/10 13:07, Mike Auty wrote:
> On 07/11/10 02:40, Donnie Berkholz wrote:
>> I read it more closely and realized I was a little confused by the way
>> you listed all the bullet points mixing together benefits and problems.
>
>> So I'll try again: if you really want to do this change, you might want
>> to consider adding a mercurial-2.eclass instead. Eclasses of this nature
>> (svn, git, hg, etc) tend to be broadly used outside the tree as well as
>> within, so breaking backwards compatibility can be a real problem. A new
>> versioned eclass allows for a much more gradual transition.
>
>
> I've only just jumped into the conversation, but the obvious question
> is, why not just use ${S} as the location of the working directory
> (rather than "${WORKDIR}/${workdir}")? That way, if it's set old
> ebuilds still work, and if it's not set, new ebuilds get the benefit of
> using ${S}? I can only see a problem with this if there's somewhere
> that the value of the working directory needs to be known before any of
> the phases...
Hm.. good idea :) I'm attaching modified patch that uses ${S} by default, so it
will improve the situation and at the same time it won't break existing ebuilds.
Thanks Mike for this suggestion.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.14
diff -u -r1.14 mercurial.eclass
--- mercurial.eclass26 Oct 2010 19:04:44 - 1.14
+++ mercurial.eclass7 Nov 2010 23:05:22 -
@@ -68,12 +68,12 @@
EHG_OFFLINE="${EHG_OFFLINE:-${ESCM_OFFLINE}}"
# @FUNCTION: mercurial_fetch
-# @USAGE: [repository_uri] [module]
+# @USAGE: [repository_uri] [module] [sourcedir]
# @DESCRIPTION:
# Clone or update repository.
#
-# If not repository URI is passed it defaults to EHG_REPO_URI, if module is
-# empty it defaults to basename of EHG_REPO_URI.
+# If repository URI is not passed it defaults to EHG_REPO_URI, if module is
+# empty it defaults to basename of EHG_REPO_URI, sourcedir defaults to S.
function mercurial_fetch {
debug-print-function ${FUNCNAME} ${*}
@@ -81,6 +81,7 @@
[[ -z "${EHG_REPO_URI}" ]] && die "EHG_REPO_URI is empty"
local module="${2-$(basename "${EHG_REPO_URI}")}"
+ local sourcedir="${3-${S}}"
# Should be set but blank to prevent using $HOME/.hgrc
export HGRCPATH=
@@ -116,19 +117,19 @@
fi
# Checkout working copy:
- einfo "Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})"
+ einfo "Creating working directory in ${sourcedir} (target revision:
${EHG_REVISION})"
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev="${EHG_REVISION}" \
"${EHG_STORE_DIR}/${EHG_PROJECT}/${module}" \
- "${WORKDIR}/${module}" || die "hg clone failed"
+ "${sourcedir}" || die "hg clone failed"
# An exact revision helps a lot for testing purposes, so have some
output...
# id num branch
# fd6e32d61721 6276 default
- local HG_REVDATA=($(hg identify -b -i "${WORKDIR}/${module}"))
+ local HG_REVDATA=($(hg identify -b -i "${sourcedir}"))
export HG_REV_ID=${HG_REVDATA[0]}
local HG_REV_BRANCH=${HG_REVDATA[1]}
- einfo "Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}"
+ einfo "Work directory: ${sourcedir} global id: ${HG_REV_ID} branch:
${HG_REV_BRANCH}"
}
# @FUNCTION: mercurial_src_unpack
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] mercurial.eclass: change clone destination
Hello,
I'm sending this patch for discussion, what it changes? The change is to where
the final clone of repository will be placed, it used to be ${WORKDIR}/${module}
(where module usually is the last component of source URI) to ${WORKDIR}/${P}
(essentially ${S}). This has few effects:
- ebuilds using mercurial.eclass don't need to set S any longer
- mercurial.eclass behaves more like git.eclass
- it breaks all existing ebuilds using this eclass
The last effect is really, really nasty :( At the same time I think it's worth
fixing this now, not when we have even more ebuilds using mercurial.eclass.
Thankfully the fix to this is trivial: just remove the line where S is being set
(or adjust it to match as is in case of one ebuild in the tree).
Following ebuilds in tree use mercurial.eclass:
dev-python/django-piston/django-piston-.ebuild
dev-vcs/mercurial/mercurial-.ebuild
media-radio/radiotray/radiotray-.ebuild
media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r3.ebuild
media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r2.ebuild
www-client/dillo/dillo-.ebuild
x11-misc/sselp/sselp-.ebuild
x11-wm/parti/parti-.ebuild
If there are no objections my plan is as follows:
- in a week commit the change to eclass
- fix all above ebuilds
- send a small announcement to gentoo-dev-announcement
Bug: https://bugs.gentoo.org/343993
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.14
diff -u -r1.14 mercurial.eclass
--- mercurial.eclass26 Oct 2010 19:04:44 - 1.14
+++ mercurial.eclass6 Nov 2010 09:05:37 -
@@ -68,12 +68,14 @@
EHG_OFFLINE="${EHG_OFFLINE:-${ESCM_OFFLINE}}"
# @FUNCTION: mercurial_fetch
-# @USAGE: [repository_uri] [module]
+# @USAGE: [repository_uri] [module] [workdir]
# @DESCRIPTION:
# Clone or update repository.
#
-# If not repository URI is passed it defaults to EHG_REPO_URI, if module is
-# empty it defaults to basename of EHG_REPO_URI.
+# If repository URI is not passed it defaults to EHG_REPO_URI, if module is
+# empty it defaults to basename of EHG_REPO_URI, workdir defaults to P. workdir
+# argument is a directory name under WORKDIR where sources will be available.
If
+# you change workdir note that you will need to adjust S to match.
function mercurial_fetch {
debug-print-function ${FUNCNAME} ${*}
@@ -81,6 +83,7 @@
[[ -z "${EHG_REPO_URI}" ]] && die "EHG_REPO_URI is empty"
local module="${2-$(basename "${EHG_REPO_URI}")}"
+ local workdir="${3-${P}}"
# Should be set but blank to prevent using $HOME/.hgrc
export HGRCPATH=
@@ -116,19 +119,19 @@
fi
# Checkout working copy:
- einfo "Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})"
+ einfo "Creating working directory in ${WORKDIR}/${workdir} (target
revision: ${EHG_REVISION})"
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev="${EHG_REVISION}" \
"${EHG_STORE_DIR}/${EHG_PROJECT}/${module}" \
- "${WORKDIR}/${module}" || die "hg clone failed"
+ "${WORKDIR}/${workdir}" || die "hg clone failed"
# An exact revision helps a lot for testing purposes, so have some
output...
# id num branch
# fd6e32d61721 6276 default
- local HG_REVDATA=($(hg identify -b -i "${WORKDIR}/${module}"))
+ local HG_REVDATA=($(hg identify -b -i "${WORKDIR}/${workdir}"))
export HG_REV_ID=${HG_REVDATA[0]}
local HG_REV_BRANCH=${HG_REVDATA[1]}
- einfo "Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}"
+ einfo "Work directory: ${WORKDIR}/${workdir} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}"
}
# @FUNCTION: mercurial_src_unpack
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eshowkw
On 10/26/10 21:42, Tomáš Chvátal wrote: > Dne 26.10.2010 20:38, Krzysztof Pawlik napsal(a): > >> nelch...@s-lappy ~$ time eshowkw gcc > /dev/null > > Could you compare speed of your and mine script Sure: nelch...@s-lappy ~/tmp$ time eshowkw gcc > /dev/null real0m1.025s user0m0.924s sys 0m0.092s nelch...@s-lappy ~/tmp$ time ./eshowkwng.py gcc > /dev/null real0m1.203s user0m1.124s sys 0m0.072s nelch...@s-lappy ~/tmp$ time /usr/bin/eshowkw gcc > /dev/null real0m4.697s user0m0.584s sys 0m0.368s nelch...@s-lappy ~/tmp$ time eshowkw wine > /dev/null real0m1.310s user0m0.952s sys 0m0.092s nelch...@s-lappy ~/tmp$ time ./eshowkwng.py wine > /dev/null real0m1.425s user0m1.344s sys 0m0.076s nelch...@s-lappy ~/tmp$ time /usr/bin/eshowkw wine > /dev/null real0m7.048s user0m1.596s sys 0m1.032s 0.1~0.2 sec is not noticeable much, so I can say that both versions are significantly faster than eshowkw from gentoolkit-dev :) (results for mine version of eshowkw are worse than previous because I'm running on the battery right now and have powersave governor set) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eshowkw
On 10/26/10 20:53, Tomáš Chvátal wrote: > Dne 26.10.2010 18:34, Krzysztof Pawlik napsal(a): >> On 10/26/10 17:39, Tomáa Chvátal wrote: >>> Hello guys, >>> I took last few days to rewrite our eshowkw script from bash to python >>> and enhance its functionality. > >> I did the same some time ago, check it: >> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=blob;f=scripts/eshowkw.py. > > Hehe was not aware of that, thats why i hate when people put their > scripts into overlays and not to some common repo :) Yeah - I know :) > Also it does not work for me at all: > > sca...@ugly-elf: ~ $ eshowkw.py kdelibs > Traceback (most recent call last): > File "/usr/local/bin/eshowkw.py", line 174, in > showMe(myArch, portage.portdbapi(portage.settings['PORTDIR']), pkg) > File "/usr/lib64/portage/pym/portage/dbapi/porttree.py", line 95, in > __init__ > self.repositories = self.settings.repositories > AttributeError: 'config' object has no attribute 'repositories' Works for me :P But I'm guessing - portage 2.2_rc, right? -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eshowkw
On 10/26/10 20:24, Daniel Pielmeier wrote: > Krzysztof Pawlik schrieb am 26.10.2010 18:34: >> On 10/26/10 17:39, Tomáš Chvátal wrote: >>> Hello guys, >>> I took last few days to rewrite our eshowkw script from bash to python >>> and enhance its functionality. >> >> I did the same some time ago, check it: >> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=blob;f=scripts/eshowkw.py. >> > > Why didn't you you introduce this to the community like Tomáš did? That > would have saved some time and both of you and everyone interested could > have worked on it. It is a perfect addition to gentoolkit-dev. Good question, it was written quite a while ago, I had plans to add some nice features and announce it to wider audience. Then 'Real Life (TM)' came into play and... it ended up the way it is currently. The only three 'features' that I managed to pack into it so far are: more usage of colors/bold fonts, slot display and acceptable performance. nelch...@s-lappy ~$ time eshowkw gcc > /dev/null real0m0.965s user0m0.900s sys 0m0.060s nelch...@s-lappy ~$ time /usr/bin/eshowkw gcc > /dev/null real0m2.559s user0m0.544s sys 0m0.416s nelch...@s-lappy ~$ time eshowkw wine > /dev/null real0m0.980s user0m0.876s sys 0m0.096s nelch...@s-lappy ~$ time /usr/bin/eshowkw wine > /dev/null real0m6.873s user0m1.732s sys 0m0.896s > I wonder how many cool tools float around in the dev-spaces none is > aware of. I remember a thread here which tried to collect those and > place them somewhere public. Instead doing so why not adding them to > gentoolkit[-dev]. I guess most of them try to make Gentoo [development] > work easier. I think that there's a lot of tools around for various reasons. Some folks don;t publish them just because, others disagree with "current versions" (that was my motive for writing my version of eshowkw). For example check this (extremely simple) wrapper around echangelog+repoman: http://dev.gentoo.org/~nelchael/ecommit One way of improving this situation: make gentoolkit svn repository more visible, basically improve documentation/knowledge about what to do with useful tools. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eshowkw
On 10/26/10 17:39, Tomáš Chvátal wrote: > Hello guys, > I took last few days to rewrite our eshowkw script from bash to python > and enhance its functionality. I did the same some time ago, check it: http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=blob;f=scripts/eshowkw.py. -- Krzysztof Pawlikkey 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 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 Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reassignments of closed bugs / clus...@gentoo.org use as bugzilla user
On 09/15/10 00:03, Jeroen Roovers wrote: > Hello, whoever you are, clus...@gentoo.org, > > > please be aware that it's customary to not reassign bugs once they have > been definitively CLOSED or RESOLVED. Just stop doing it. > > Also, don't use the clus...@gentoo.org user at bugs.gentoo.org to make > changes in bug reports: we have no idea who is making these changes > and we might at some point need to know. Kacper - care to explain? Jeroen: you've sent similar mail on Saturday too - Kacper responded to it stating that it won't happen again. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.
On 08/23/10 23:23, Robin H. Johnson wrote:
> The existing EHG_REVISION is the target revision, usually 'tip', so it
> doesn't help us reproduce a bug if the upstream tree has moved since log
> creation.
>
> Example output:
> * Work directory: /var/tmp/portage/ global id: 44cff02c8042 branch:
> default
>
> Signed-off-by: Robin H. Johnson
>
> Index: mercurial.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
> retrieving revision 1.12
> diff -p -w -b -B -u -r1.12 mercurial.eclass
> --- mercurial.eclass 2 Apr 2010 18:29:39 - 1.12
> +++ mercurial.eclass 23 Aug 2010 21:20:41 -
> @@ -116,12 +116,20 @@ function mercurial_fetch {
> fi
>
> # Checkout working copy:
> - einfo "Creating working directory in ${WORKDIR}/${module} (revision:
> ${EHG_REVISION})"
> + einfo "Creating working directory in ${WORKDIR}/${module} (target
> revision: ${EHG_REVISION})"
> hg clone \
> ${EHG_QUIET_CMD_OPT} \
> --rev="${EHG_REVISION}" \
> "${EHG_STORE_DIR}/${EHG_PROJECT}/${module}" \
> "${WORKDIR}/${module}" || die "hg clone failed"
> + # An exact revision helps a lot for testing purposes, so have some
> output...
> + # id num branch
> + # fd6e32d61721 6276 default
> + local HG_REVDATA=($(hg identify -n -b -i "${WORKDIR}/${module}"))
> + local HG_REV_ID=${HG_REVDATA[0]}
> + local HG_REV_NUM=${HG_REVDATA[1]}
> + local HG_REV_BRANCH=${HG_REVDATA[2]}
> + einfo "Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
> branch: ${HG_REV_BRANCH}"
> }
>
> # @FUNCTION: mercurial_src_unpack
>
+1 Robin :) Ship it!
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Locale check in python_pkg_setup()
On 07/30/10 01:16, Arfrever Frehtes Taifersar Arahesis wrote: > We received too many invalid bugs caused by unsupported locales. > python_pkg_setup() needs to check > locale and print error (using eerror(), without die()), when unsupported > locale has been detected. ewarn then instead of eerror - both are nicely visible, and you're actually *warning* against potential issues. > + eerror "See http://www.gentoo.org/doc/en/utf-8.xml for > information on how to fix locale." I'm with Brian on this one - my locale (C/POSIX) is not broken, it's the code that has bugs. Can you please change wording here to read something along "... for information on switching to Unicode locale." instead of suggesting that users locale is broken. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] zlib ebuild from OSS-QM
On 07/06/10 22:04, Enrico Weigelt wrote: > * Jeremy Olexa schrieb: >> On Mon, 5 Jul 2010 18:48:43 +0200, Enrico Weigelt >> wrote: >>> Hi folks, >>> >>> please refer my recent postings on details what the oss-qm >>> project is all about. just a few words: the main idea is to >>> >> >> Enrico, There are actually so many 404s on your homepage (including >> both links in your email signature) that it quickly loses my attention >> span. > > Which ones ? Almost all from your signature: - http://wiki.metux.de/public/OpenSource_QM_Taskforce - http://patches.metux.de/ (main www.metux.de works) > (I know, some old stuff is broken, I didnt have the time to > clean it all up yet ;-o) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/26/10 20:59, Ciaran McCreesh wrote: > On Sat, 26 Jun 2010 21:46:39 +0200 > Enrico Weigelt wrote: >> BTW: if upstream has an proper VCS and an canonical tagging >> scheme, they don't actually have to create release tarballs, >> just hack up a little script which creates them on-the-fly >> from an canonical URL scheme (eg. oss-qm does exactly that). > > Down that path lies madness. There's no guarantee that you'll get the > same tarball if you request the same URL twice in a row, particularly > if you're using one of those new-fangled new compression schemes. I agree with Ciaran here, to add one more thing: tags can be mutable. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/26/10 19:51, Enrico Weigelt wrote: > * Krzysztof Pawlik schrieb: > >> Take a look at this page: >> http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is >> Java >> specific mostly, but some general points can be reused :) > > Hmm, this document suggests something, I just forgot to prohibit: > > "Release the source archives along with whatever binary archives you may > have." > ^ You intend to "prohibit" releasing binary packages for upstream? Thats... something you don't see everyday. Why would you do that? It's quite common for Java projects to release pre-built JAR files or for C/C++ (or other) based projects to release debs or rpms - it's standard practice. What's important in quoted sentence is: "Release the source archives along with binary archives" - the "with" is very important - in short: don't release only binary versions and force us to grab them from VCS. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/25/10 21:17, Enrico Weigelt wrote: > I'm currently collecting a set of rules which upstream developers > should follow to make distro maintainer's life easier. > > Comments welcomed :) Take a look at this page: http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is Java specific mostly, but some general points can be reused :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A policy to support random superuser account names
On 05/02/10 16:13, Stefan Behte wrote: > Hi, > > in some environments you have to rename "root" to something else, just > to be compliant to a (maybe dumb) security policy. This might be the > case for PCI, and as far as I remember, it is necessary (not just > "recommended") for a BSI Grundschutz certification (meaning something > like "basic security protection") [1]. Unfortunately I didn't find the > exact link. Interesting... to me that's not only stupid but also kinda useless - there's no difference between brute-forcing a password for user named 'foo' or 'root' - user name doesn't matter much. Actually according to my ssh logs attackers usually don't even try root, they try other user account names way more often. Keep in mind that most compromised systems are used to send spam, take part in DoS attacks, etc - you don't need root to do that. Breaking into root account may actually be harmful as it may trip some security measures. It's better to disable password-based remote login altogether in sshd_config. Security by obscurity is a nice way to make pseudo-sys-admins feel warm and fuzzy :] > This might prevent or make usage of gentoo more complicated in those > environments, but is only a problem for a small fraction of our user base. > > Best regards, > > Craig > > > [1] > https://www.bsi.bund.de/cln_183/ContentBSI/EN/Publications/Bsi_standards/standards.html > > 30.04.2010 20:07, Michał Górny wrote: >> Hello, >> >> I would like to put an emphasis on the fact that many eclasses >> and ebuilds in gx86 are relying on an assumption that the superuser >> account is always supposed to be named 'root'. >> >> In fact, no such constraint exists. Although most users will never even >> think of changing the superuser account name, it is perfectly legit >> to do so, and to use any name for that account. Moreover, it is >> perfectly legit to name an unprivileged user 'root' too. >> >> Thus, the above assumption is clearly incorrect and may result in many >> issues with ebuilds using it. These range from builds failing because >> of chown 'invalid user' error to packages being installed with >> incorrect file ownership. >> >> From what I've heard already, similar problem has hit Gentoo/*BSD users >> already, with superuser group not being named 'root'. Although some >> files were fixed to properly use numeric GID in the specific case, >> no UID-related changes were done. >> >> Moreover, not all developers agree with the case being an issue, >> and they even refuse patches clearly fixing it [1]. Thus, I guess that >> a clear policy regarding referencing the superuser account should be >> enforced. >> >> In my opinion, that policy should clearly indicate that the numeric >> UID/GID should be always used for referencing the superuser account >> as they are fixed unlike the names. >> >> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779 >> > > > -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] package.mask-ed ebuilds
On 04/09/10 08:10, Nirbheek Chauhan wrote: > Hello! > > So, I can't find any documentation about this; nor can I find a > best-practices list. Can we add broken ebuilds in-tree as long as they > are package.masked? automagic deps, wrong deps, missing deps, file > collisions, etc etc? Even if it makes the ebuild completely unusable > by itself? > > If yes: > > So we can add completely broken and useless stuff to tree as long as > it's package.masked? > > If no: > > What's the minimum amount of "working-ness" that an ebuild must have > to be added to tree? Who decides this? The QA team? Use common sense: if it's work in progress then committing a broken ebuild which is p.masked is IMHO acceptable (especially if you need to bump/add more ebuilds to get this one working). At the same time if you don't plan on improving it and just want to get it committed somewhere - use overlay. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/10 11:09, "Paweł Hajdan, Jr." wrote: > On 4/3/10 12:03 PM, Krzysztof Pawlik wrote: >> On 04/03/10 10:50, Petteri Räty wrote: >>> I don't think later is valid resolution. If there's a valid bug it just >>> means it's never looked at again. If the bug is not valid then a >>> different resolution should be used. So what do you think about >>> disabling later? I would like to avoid things like this: >>> >>> https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 >>> >>> Not applicable to the bug above but in general our social contract says: >>> "We will not hide problems" >> >> Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are >> not valid anymore due to changed situation, RESOLVED INVALID isn't >> applicable in >> this case as it implies the bug is and was invalid from the begining). > > Wouldn't WORKSFORME apply in that case? Just renaming the resolutions > doesn't gain us much. Reducing the number of possible resolutions does, > I'd say. In my opinion: no. WORKSFORME is for a problems that can't be reproduced. OBSOLETE would be: yes, this bug has been applicable, but situation changed, ignore it. One of the examples could be stabilization bugs: you have an open stabilization bug, but new version comes out with important security fix and it needs to go stable ASAP. You mark the old stabilization bug as OBSOLETE and continue in the one opened for security issue (as it usually happens). To summarize: I'm suggesting axing two resolutions (LATER and REMIND) and introduce OBSOLETE. If OBSOLETE doesn't sound like a good idea I'm ok with not having it -- removing two resolutions is a nice achievement too :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/10 10:50, Petteri Räty wrote: > I don't think later is valid resolution. If there's a valid bug it just > means it's never looked at again. If the bug is not valid then a > different resolution should be used. So what do you think about > disabling later? I would like to avoid things like this: > > https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 > > Not applicable to the bug above but in general our social contract says: > "We will not hide problems" Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). When we kill RESOLVED LATER maybe we could also kill RESOLVED REMIND? I don't remember it being very useful. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unification of variables used within SCM eclasses
On 03/24/10 11:28, Michał Górny wrote:
> As suggested by ssuominen on bug #311101, I am posting the issue
> to the mailing list.
>
> Currently, various SCM eclasses differ very much in the subset
> of features and control variables implemented. The idea is to establish
> a single subset of such variables and rules for all SCM eclasses
> to follow, and maybe even develop a common scm.eclass which would be
> sourced by other SCM eclasses.
Overall: I like the idea of common vcs.eclass - that would make easier not only
to use/write ebuilds using various VCS'es but also to maintain the eclasses.
> Variables suggested by me:
>
> a) Common variables - the variables which would have to be used by
> various SCM eclasses as default/fallback values.
>
> 1. ESCM_DISTDIR (defaulting to PORTAGE_ACTUAL_DISTDIR/PORTDIR)
> - an alternate parent dir to all SCM stores. It would be useful
> if user would like to use an small file-inefficient filesystem
> for main DISTDIR or rsync it with other machine (where SCM
> files are not as important as the tarballs are).
>
> 2. ESCM_OFFLINE (most eclasses use it already)
> - a common switch to easily switch off all network interaction.
>
> 3. ESCM_LIVE_FAIL_IF_REPO_NOT_UPDATED (similar to the one in git.eclass)
> - a common switch to force unpack() phase to fail if no updates
> were found during the pull/update.
What about ESCM_REVISION defaulting to empty value meaning to use head/tip/etc
revision?
> b) Common eclass-specific variables - these ones should allow user to
> override above variables for single SCM.
>
> 1. E*_STORE_DIR (defaulting to ${ESCM_DISTDIR}/*-src)
> - already used by few eclasses, allowing user to change
> the location where SCM-specific clones are stored.
Is it really necessary? Can't we switch to one, common vcs-src/ (or something
like this) directory?
> 2. E*_OFFLINE (defaulting to ${ESCM_OFFLINE})
> - allowing user to override global 'offline switch'. Thus, it
> should also support setting 'false' value to enable network
> interaction for single SCM.
If there's a ESCM_OFFLINE is it necessary to copy the information again to
vcs-specific eclasses? I don't think so. In other words: I don't think that
copying variables from parent eclass to vcs-specific one has any point.
> 3. E*_LIVE_FAIL_...
> - another override for the global one.
>
> 4. E*_REPO_URI
> - the URI to the main repository. It might be extended to support
> multiple URIs.
>
> 5. E*_REVISION
> - explicit expected-revision/tag specification, preferably along
> with implicit one (e.g. in ESVN_REPO_URI) deprecation.
> This would allow applications to easily distinguish
> between 'real' live ebuilds and snapshot ones fetching directly
> from the repo.
>
> c) Common export variables - these ones should be exported by SCM eclass
> and stored in environment.bz2 after successful emerge.
>
> 1. E*_VERSION (or _REVISION, or ...)
> - the version/revision to which the package was updated. This would
> be useful to determine whether the current repo is newer
> than one used when merging package.
>
> 2. E*_WC_PATH
> - the absolute path to the last-used clone dir (i.e.
> ${E*_STORE_DIR}/sth) and thus the most probable location
> to perform further updates in.
>
> d) Other:
>
> 1. ESCM_CUSTOM_FETCH
> - this one is not directly related to eclasses but for use of ebuild
> authors. Setting this in an ebuild should notice applications
> that the ebuild does use custom fetching procedures
> (i.e. fetches from multiple repositories in a manner
> unsupported directly by the eclass) and thus external
> applications should not try to update the repository themselves.
Overall: looks good. It would be extremely helpful if we could discuss an actual
implementation, setting up a repo and starting work there may be an awesome
idea.
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...
signature.asc
Description: OpenPGP digital signature
