Re: [gentoo-dev] Help offered - Portage tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not a gentoo-dev - and I did not read the whole thread, because it was too political for me (do I really have to read all these IRC quotes?). But I just had an idea for this topic (don't know if anyone had this already - or if it is not applicable here), that I want to share: Why not try to find someone, who does all the bug filing? - So lxnay can find and fix the bugs - and someone else files the bugs and does the discussing with the gentoo-devs. Then both sides have what they want. Of course, it still takes time to get things into the tree, but this shouldn't be a problem :) (I think). Just an idea - please don't eat me, if it's a silly one ^^ Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2X6a4UOg/zhYFuARAhiWAJ0WzGC6jzRODv9pjezsygRBAUoTWQCfQZro eCQ/dsAY+OZsMvg+ffLGCAc= =NqLb -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: bzr.eclass into Portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Christian Faulhammer schrieb: | We have a prior version for some time now in the Emacs overlay for two | live ebuilds...so we go and merge your changed (ulm already did), test | it and report any problems. I just copied the bzr.eclass from the desctop-effects overlay over to my own one. And I had to find out, that bzr fails when updating an ebuild which uses the "lp:" address scheme[1]. So perhaps, the support for this scheme should be removed until it is fixed. Regards, Necoro [1] https://bugs.launchpad.net/bzr/+bug/181945 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6FVC4UOg/zhYFuARAkmbAJ0cFEFGeZubvjhocmgPcTFXL6hdzACfYpGE WP5z9YJri1NZzdQkHQ/Nv7E= =YWvP -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: bzr.eclass into Portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: | Hi, | | Christian Faulhammer schrieb: | | We have a prior version for some time now in the Emacs overlay for two | | live ebuilds...so we go and merge your changed (ulm already did), test | | it and report any problems. | | I just copied the bzr.eclass from the desctop-effects overlay over to my | own one. And I had to find out, that bzr fails when updating an ebuild | which uses the "lp:" address scheme[1]. So perhaps, the support for this | scheme should be removed until it is fixed. | | Regards, | Necoro | | [1] https://bugs.launchpad.net/bzr/+bug/181945 Ok - seems like it got fixed in the meantime ... (bug is open for several months --- and then gets fixed minutes after I post here ... ;)) I guess this fix will make it into bzr-1.4. Should the eclass then depend on this version or should it still not allow the lp:-scheme? Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Rfv4UOg/zhYFuARAsgFAJoDn9csUloGQxZ4tHhInKxQ2LvkTwCeJRg0 xNqxCP0FbbgG22At64IcovU= =G5Er -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Freedesktop utils in ebuild
Hi list, I'm currently trying to update an ebuild (x11-misc/zim) to a new version. The old one uses a patch to disable running "update-desktop-database" and instead using the fdo-mime_desktop_database_update function. Now - the new ebuild also wants to call: - update-mime-database --> disable and use fdo-mime_mime_database_update ? - xdg-icon-resource install --> let it run? - or disable it (and replace it by what)? Would be glad, if someone could clarify the use here :) - Necoro -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Freedesktop utils in ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: > Hi list, > > I'm currently trying to update an ebuild (x11-misc/zim) to a new version. > The old one uses a patch to disable running "update-desktop-database" and > instead using the fdo-mime_desktop_database_update function. > > Now - the new ebuild also wants to call: > > - update-mime-database --> disable and use fdo-mime_mime_database_update ? > - xdg-icon-resource install --> let it run? - or disable it (and replace it > by what)? > > Would be glad, if someone could clarify the use here :) > > - Necoro > Ping? - Anyone? Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhO8b0ACgkQ4UOg/zhYFuBFSQCfXwsTyG+wgmwFRZeYDTYYu9IS 6FwAn0Vde7NSQkehB4T0BHymKGeC4b27 =SAW7 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Freedesktop utils in ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Samuli Suominen schrieb:
>>> - xdg-icon-resource install --> let it run? - or disable it (and
>>> replace it by what)?
>
> unsure (as i've neved touched it) but i'd say if it respects DESTDIR and
> doesn't have any file-collisions when installing, let it run
Seems like it does not ... moved it to post{inst,rm}
> plus it will be very likely ME who commits new zim, as usual.. so open
> up a bug for the new version & your suggested ebuild.
Done -> bug #226143
- - Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhRoZkACgkQ4UOg/zhYFuCaPQCeMC7MKf8HBN4rNH63xHmJ1ArE
+SoAnj+WH53MRi3s9xe01N3LEi1g6MDt
=hLU1
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico schrieb: > I chose "live" because I think it's easy for people to associate it > with "live ebuilds", which I believe is a common term used to refer > to ebuild that download live sources in src_unpack. What's in a name > though? I'll gladly use whatever name satisfies the most people. Why not rename "live" to something which makes more sense in the RESTRICT environment? Like the "constant-source" suggestion by Arfrever? Because for me 'RESTRICT="live"' reads like: "Live(-builds)" are not possible with this ebuild. Pushing random boolean flags in a variable, just because it already happens to be there, seems (for me) to be the wrongest possible approach. This would be quite similar to: We want to store the ebuild's author in the ebuild... Hmm - we would need an additional string variable for this ... Come - let's use the IUSE variable - there are already strings in there (perhaps add an '@' before the author so we can parse it). Just my 2ct, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiU6LkACgkQ4UOg/zhYFuBrVgCfRs/69DxNBy3TN0fsLr20gURW BxMAnie5SoBzbKN6n2oMhOJvMywV1ydf =aOCm -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico schrieb: > Well, RESTRICT has long since evolved into a rather generic set of > boolean flags and it's quite useful as such. I don't see any need > for artificial limitations on what types of flags go there. For you it is just "one variable amongst others" - and you really don't care about the relation between its name and its content. But perhaps just for the sake of easier understanding of ebuilds, this relation should be kept. Otherwise you'll read in future documentation: "The name is just for historical reasons and does not reflect the content." -- And this is nearly always a stumbling block for the non-experienced. Perhaps in a later EAPI RESTRICT might be renamed to something like FLAGS - and then can really be used as a pool of flags. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiU8p8ACgkQ4UOg/zhYFuBeSQCfaPCuNXk99lde0lvriV1GFDMu 6FgAnRetvxI1uHWnZH2lizEiTIB+7IOC =wStZ -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson schrieb: > On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: >> I am writing a tool that creates deb (as in Debian package format) based >> distributions from gentoo packages and that tool encodes the CVS >> revision as part of "debian revision" of the packages. So I need this >> part to be chronologically ordered, as opposed to have only the >> knowledge of whenever the file has changed or not. > > That is an interesting use case, and would that would present a problem > with any VCS migration. I don't see this problem ... I guess it is possible in all VCS to get the information, which global revision touched a specific file last. For example in bzr (these examples are conceived by me - so probably there is an easier way): bzr log -l1 --line $FILE | cut -f1 -d: - --or: to have the unique rev-id instead of the branch-local rev-number-- bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' ' And hg,svn,git sure have similar abilities. - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0hZQACgkQ4UOg/zhYFuBTrgCeJ/2gfygwUvWCB5QOibsYz0mN sGMAnRmqz/ChCg6zSAVrS4JljP1+DYRV =g5fE -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson schrieb: > On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote: >> - --or: to have the unique rev-id instead of the branch-local rev-number-- >> bzr log -l1 --show-ids $FILE | grep "revision-id" | cut -f2 -d' ' > IIRC, the revision-id is just like the Git $Id$, it's a hex string, not > an incremented counter like the revision number in CVS. > True ... it usually looks like [EMAIL PROTECTED] Though, if one enforces certain policies using the "main branch" located on the server like disallowing pushing and only allowing merges, one can safely use the branch-revno (which is incremental). Only oddity are revnos of merged branches (e.g. "193.1.10") Another approach would be to use the unix-timestamp of the last change. Though it is not a unique identifier per se, it should be sufficient here. It should be queriable in all VCS. Though it might be, that it is not possible using standard CLI and requires a plugin in some way (but I bet, an easy one ;)) - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0j3UACgkQ4UOg/zhYFuDZ+QCdGm7Sjew2+27KCUB06lWf8aLr XBsAoIbJSke4xHyPiucYEmkuNVd9GPJ3 =jTaO -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: > Only oddity are > revnos of merged branches (e.g. "193.1.10") Gnah - forget this issue.. from the main branch' viewpoint, the last change is always in the merge revision, and not in a revision being merged. So it is guaranteed to be an integer and not a combined thingy as above ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0kZMACgkQ4UOg/zhYFuDftQCfWHv+AvkqNJgZ/VwyIc1AV9WS kJcAoIMmvsPv48GO4ixM4KE25TQtBHkm =F3DM -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Some support for Sunrise Overlay :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan schrieb: > Tiziano Müller <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Mon, 24 Nov 2008 07:56:20 +: > >> Now, since the sunrise project gets bigger, we might also create a >> mailinglist to discuss ebuilds for people can't/do not want to use IRC. >> This would also make it possible to CC the mailinglist-address for bugs >> where the ebuilds are in sunrise. > > I'd be interested in a mailing list. What about the gentoo-devhelp mailinglist? :) As #gentoo-dev-help is also a support-channel for ebuild-concerning questions (if I'm not mistaken). And I can't see the reason for having just-another-ml (TM) ;) Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkqxvQACgkQ4UOg/zhYFuC3lACfcCwyJaYAWVZ+jPgxaD+sLmHh 5FwAn3uD9aXRopy+oA0nJ+zFahMcCMVY =eZ2E -END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jorge Manuel B. S. Vicetto schrieb:
> Hi.
>
> Christian Faulhammer wrote:
>> Hi,
>>
>> a user maintained a Bazaar overlay for some time now and introduced
>> some changes to bzr eclass, I would like to introduce into the tree.
>> Please review the attached patch.
>>
>> V-Li
>
> I'm attaching a revised patch that tries to improve some issues in the
> current version in the tree, incorporates your changes and Peter
> Volkov's (pva) patch about sftp URIs.
>
>
if [[ ${EBZR_REPO_URI} == */* ]]; then
repository="${EBZR_REPO_URI}/${EBZR_BRANCH}"
elif [[ -n ${EBZR_BRANCH} ]] ; then
...
else
...
fi
If I see this correctly, this appends EBZR_BRANCH if there is a slash in
the REPO_URI ... what kind of guess is this supposed to be? I think, the
second test (append iff EBZR_BRANCH is set) should be sufficient.
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmeon0ACgkQ4UOg/zhYFuCf7gCfWSyBZrzct0jvUl9W+yml52+K
7ToAmwRry/H/3ZlH0bjNNg82f+gIIzBZ
=cqx5
-END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Perhaps add "> /dev/null" to the pushd/popd calls? To get rid of unnecessary output. - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmxTBcACgkQ4UOg/zhYFuDlRgCfcTwOVG42RsKCfWv9dyaxFPTk ZSoAnAnARobr31NhI78sf6DwW2H9HkHy =HKj7 -END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have some doubts about the usage of "co --lightweight" instead of the plain "co". The only reason I can see is the reduced disk-space needed. Because concerning time, the lightweight checkouts take (way) longer... Just some bash-time tests done with the portage bzr-repo (lp:portage -- 6470 revisions). I used bzr-1.12: method fetch export == = == branch: ~47s / ~2s stacked branch: ~68s / ~49s checkout: ~46s / ~2s lightweight co: ~50s / ~51s As one can easily see: While the fetch time for co and lw-co are more or less equal, the export time is not. As one can say, that each package is at least exported as often as updated (if not more often), this makes the lw co operation more or less a no-no. (Waiting one minute to get a snapshot of a medium-sized project? ... ehm - NO) But for completeness: size with co: 24MB - with lw-co: 3,1MB So I'd vote for switching back to using normal checkouts (or branches - they don't really differ in bzr for that matter). Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm3CeIACgkQ4UOg/zhYFuAmmQCeL/BqnCClR5CBapvAvO3Og0Tu MBEAoINCwaNfnAYkFyxmaB2kR5BeHMsj =37WD -END PGP SIGNATURE-
Re: [gentoo-dev] bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: > As one can easily see: While the fetch time for co and lw-co are more or > less equal, the export time is not. As one can say, that each package is > at least exported as often as updated (if not more often), this makes > the lw co operation more or less a no-no. (Waiting one minute to get a > snapshot of a medium-sized project? ... ehm - NO) One note - just saw the following for the bzr-1.13_rc1 release notes: "Lightweight Checkouts and Stacked Branches should both be much faster over remote connections. Building the working tree now batches up requests into approx 5MB requests, rather than a separate request for each file. (John Arbash Meinel)" So perhaps it is improved for this new release. Have to retest soon. (I also wonder, why the hell the export of the lw-co takes so long ... it more or less just needs to copy the files... I cannot see the need to fetch each file again from the remote repo. Perhaps this is worth a bzr-bug.) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm3C9MACgkQ4UOg/zhYFuDAuwCePrNj2rQ4au99QziYZl7qpe9a PFYAn2ZuRqp3vpNLUwcASN6wk8NaqL/s =Li4s -END PGP SIGNATURE-
Re: [gentoo-dev] Re: bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer schrieb: > Hi, > > René 'Necoro' Neumann : >> So I'd vote for switching back to using normal checkouts (or branches >> - they don't really differ in bzr for that matter). > > My tests with Bazaar 1.13.1 show roughly the same time with and > without --lightweight. Although I am not sure what you mean by > export vs. fetch. fetch: bzr branch / bzr co export: bzr export And depending on the type of the repository, the export will take different times. And I see the export as quite important, as the number of exports is at least as high as the number of fetches. Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknRP2AACgkQ4UOg/zhYFuBunwCfQG03AEruswY0UX39LTL6jmmt ZWsAn06PRrCHaGMzoIneRVPLwzzYxrb2 =C9GU -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale schrieb: > As for people knowing about Gentoo and the forums, go to google and type > in Gentoo. First hit, Gentoo home page. Even includes links to the > docs and other pages that are handy. Allow me a short remark: Enter "gentoo forum" - and you won't find one important thing: The official Gentoo forums... Allowing Google to index the Gentoo Forums (again) looks like a quite handy way of making people not wanting to ask their questions elsewhere. Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUb0MACgkQ4UOg/zhYFuABCQCghUVyuin7eP8Znql7DqBZ1s0u E+oAnRgvMn8eX7Md/XMjUI5tIL7av2+N =kGjL -END PGP SIGNATURE-
Re: [gentoo-dev] Unpermitted distribution of Gentoo shirts and mugs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Samuli Suominen schrieb: > User posted me today these: > > http://www.spreadshirt.net/shop.php?article_id=2219416&view_id=235 > http://www.spreadshirt.net/shop.php?op=article&article_id=311913&p=1 > > Seems they are making money with products that has Gentoo or Gentoo > Linux in them, including our logo. > > Is that legal? > > - drac This is the shop of gentoo.de which holds the trademark in Germany :) So this should be ok :) - -- Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG66Gh4UOg/zhYFuARAjTYAJwLylyTZZL08tb+tZ0lFkwXO6EuVwCfdUHp uj7hm/QH5yxkbP+vH91l35U= =z+mY -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/ruby: ChangeLog ruby-1.8.6_p110.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger schrieb:
> On Monday 24 September 2007, Donnie Berkholz wrote:
>> On 09:38 Mon 24 Sep , Richard Brown (rbrown) wrote:
>>> if [ ! -n "$(readlink ${ROOT}usr/bin/ruby)" ] ; then
>>> ${ROOT}usr/sbin/ruby-config ruby${SLOT/./}
>>>
>>> if [ ! -n "$(readlink ${ROOT}usr/bin/ruby)" ] ; then
>>> ${ROOT}usr/sbin/ruby-config ruby${SLOT/./}
>>> fi
>> ROOT can have spaces in it too.
>
> this is why the form:
> [[ -n $(readlink "${ROOT}"usr/bin/ruby) ]]
> is preferred ... much easier to read and no nested quotes
> -mike
And: [[ ! -n ... ]] transforms to [[ -z ... ]]
Or am I wrong?
Regards,
- -- Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+A/04UOg/zhYFuARAg/dAJ9I5m/p7crLGG9JkIMu2vigtXlXVQCeLJwj
/zofTwO9Vtf+mu6EBYT8XiE=
=NIoO
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/portato: ChangeLog portato-0.8.6.ebuild portato-0.8.5.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz schrieb:
> On 17:03 Sat 20 Oct , Markus Ullmann (jokey) wrote:
>> 1.1 app-portage/portato/portato-0.8.6.ebuild
>>
>> file :
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-portage/portato/portato-0.8.6.ebuild?rev=1.1&view=markup
>> plain:
>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-portage/portato/portato-0.8.6.ebuild?rev=1.1&content-type=text/plain
>
>> apply_sed ()
>> {
>> cd "${S}/${PN}"
>>
>> }
>
> Uhh, what's this doing? It's not called anywhere in the ebuild. I'd
> guess it's an artifact from an older version.
>
> Thanks,
> Donnie
Someone has broken this ebuild - it is not working at all. (The body of
apply_sed has been moved into src_compile - and broken there). A current
version is waiting in sunrise/portage-review to be included in the tree.
Just ignore the current ebuild ^^
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHHHGD4UOg/zhYFuARAlJEAJ9QXgUNcfDKmoHmEmQ3Q4AeczF5GwCfZ8Zy
tm4+Ssa0xCNs5L1zrJngacQ=
=lwRg
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I just worked on a project using cmake. And I needed the cmake-utils_src_enable function... But it did not work as expected. This is because cmake arguments are in uppercase most of the time, and cmake is case sensitive. And unfortunately the cmake-utils_src_* functions just return the passed in flag literally: cmake-utils_src_enable python => -DENABLE_python=... Wanted would be that it returned -DENABLE_PYTHON=... I'm not into bash scripting that much, so I do not know a way to do so - but I guess someone else is ;) Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMzdk4UOg/zhYFuARAg92AJ4qpzuei0P+y+Wfy4dah/MWq4pBAACdG178 yEkbV4vpDx3CtFc9pdEfldw= =avlW -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long schrieb:
> René 'Necoro' Neumann wrote:
>> cmake-utils_src_enable python => -DENABLE_python=...
>>
>> Wanted would be that it returned -DENABLE_PYTHON=...
>>
>> I'm not into bash scripting that much, so I do not know a way to do so -
>> but I guess someone else is ;)
>>
> Unfortunately BASH doesn't support ksh93 or zsh style casting to uppercase.
> The best way really is via tr:
> alias toUpper='tr [[:lower:]] [[:upper:]]'
> alias toLower='tr [[:upper:]] [[:lower:]]'
>
> (er aliases don't normally work in scripts, but you get the idea.) Bear in
> mind that tr reads stdin and writes to stdout. It has the advantage of
> being locale-safe. Every other method I've looked at is much slower and
> only works with ASCII.
>
> A function wouldn't be too hard:
> toUpper() {
> for i; do
> echo "$i" |tr [[:lower:]] [[:upper:]]
> done
> }
>
> Usage depends on the parameters you pass.
> var=$(toUpper $var) # for single vars with no newlines in
This is right the version I've chosen ... so with the help of Steve: a
small patch ;)
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFHM5uv4UOg/zhYFuARAuELAJjnlDCFDMm3e2mJqYuyT4nkFoaaAJ4go9qp
Qca9r8Y7LpD0YSSylUh2BQ==
=517n
-END PGP SIGNATURE-
--- cmake-utils.eclass.old 2007-11-09 00:25:49.0 +0100
+++ cmake-utils.eclass 2007-11-09 00:14:47.0 +0100
@@ -23,11 +23,17 @@
EXPORT_FUNCTIONS src_compile src_test src_install
+# Internal funcion used by _use_me_now. Converts string to upper case.
+_to_upper() {
+ debug-print-function $FUNCNAME $*
+ echo "$1" | tr "[[:lower:]]" "[[:upper:]]"
+}
+
# Internal function use by cmake-utils_use_with and cmake-utils_use_enable
_use_me_now() {
debug-print-function $FUNCNAME $*
[[ -z $2 ]] && die "cmake-utils_use-$1 []"
- echo "-D$1_${3:-$2}=$(use $2 && echo ON || echo OFF)"
+ echo "-D$1_${3:-$(_to_upper $2)}=$(use $2 && echo ON || echo OFF)"
}
# @FUNCTION: cmake-utils_use_with
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingmar Vanhassel schrieb:
> 2007/11/9, René 'Necoro' Neumann <[EMAIL PROTECTED]>:
>> Steve Long schrieb:
>>> René 'Necoro' Neumann wrote:
>>>> cmake-utils_src_enable python => -DENABLE_python=...
>>>>
>>>> Wanted would be that it returned -DENABLE_PYTHON=...
>>>>
>>>> I'm not into bash scripting that much, so I do not know a way to do so -
>>>> but I guess someone else is ;)
>>>>
>>> Unfortunately BASH doesn't support ksh93 or zsh style casting to
>> uppercase.
>>> The best way really is via tr:
>>> alias toUpper='tr [[:lower:]] [[:upper:]]'
>>> alias toLower='tr [[:upper:]] [[:lower:]]'
>>>
>>> (er aliases don't normally work in scripts, but you get the idea.) Bear in
>>> mind that tr reads stdin and writes to stdout. It has the advantage of
>>> being locale-safe. Every other method I've looked at is much slower and
>>> only works with ASCII.
>>>
>>> A function wouldn't be too hard:
>>> toUpper() {
>>> for i; do
>>> echo "$i" |tr [[:lower:]] [[:upper:]]
>>> done
>>> }
>>>
>>> Usage depends on the parameters you pass.
>>> var=$(toUpper $var) # for single vars with no newlines in
>> This is right the version I've chosen ... so with the help of Steve: a
>> small patch ;)
>>
>> Regards,
>> Necoro
>
> Hi Necoro,
>
> You can just use 'cmake-utils_use_enable python PYTHON'
>
> It's mentioned in the cmake-utils.eclass manpage
> (app-portage/eclass-manpages),
> as well as in the patch you just sent: cmake-utils_use_enable flag> [flag name]
>
> :-)
>
> Regards,
> Ingmar Vanhassel
> ���^����(� ��X��X�t===
I know this :) ... and this is how I did this at the moment.
But as I think, that the uppercase version is the common behavior here,
it should not need this extra "PYTHON". :) That's why the patch ;)
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHNCQS4UOg/zhYFuARAmdhAJ9idOAgUEX7GIvQrkDIIOT8heg5YgCfdSAM
09YrI9Nky6kmKVNg4Egafgk=
=ZT15
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wulf C. Krueger schrieb: > On Friday, 09. November 2007 10:10:42 René 'Necoro' Neumann wrote: >> But as I think, that the uppercase version is the common behavior here, >> it should not need this extra "PYTHON". :) That's why the patch ;) > > Actually, the mixed-case is what we have encountered in most cases. > > Furthermore, as you stated correctly yourself, cmake is case-sensitive and > a patch that works around that fact only to have one parameter less for a > function doesn't really make much sense in my book. > Hmm ... ok - if you say, that more applications used the mixed case versions, the current version is ok :) I did not want to reduce one parameter, but when I first used this eclass function, I assumed, that it will do the right thing (that is: make it uppercase). It did not do so - that's why the patch ;). Another way would be to enhance the comment and state explicitly that it takes the useflag literally and does not do any case transition :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNIZt4UOg/zhYFuARAhuNAJ97EaX5W2ffNUrtPsFLLY1ZzTQFFQCffyCE mThno69KazBAWmnsifjxM8E= =7Xbk -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing
Wolfram Schlich schrieb: > * Hanno Böck <[EMAIL PROTECTED]> [2007-11-26 15:39]: >> [...] >> So I'd like to unmask it soon. Please, if you're using mailman test it, tell >> me if it suits your needs or just give me feedback like "worksforme", I >> actually don't have a clue how many people really use this ebuild. > > pkg_postinst() says... > --8<-- > * Please read /usr/share/doc/mailman-2.1.9-r2/README.gentoo.gz for additional > * Setup information, mailman will NOT run unless you follow > * those instructions! > --8<-- > ...but that README actually has .bz2 instead of .gz on my system :) Depends on what PORTAGE_COMPRESS is set to ;) (Don't know WHERE this is actually being set - but different systems seem to have different values here). - Necoro -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Problems with the current bzr eclass.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harley Peters schrieb: > I'm getting good numbers from the command line but in the ebuild it's > much different. > I haven't timed it but it takes about 25 minutes to do a full > checkout and about a third that to do the light weight checkout. > The update takes less than a minute with the full checkout. And it > takes ten's of minutes with a lightweight checkout. I guess, the "bzr export" is the problem here ... see https://bugs.launchpad.net/bzr-gentoo-overlay/+bug/343218 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXKGwACgkQ4UOg/zhYFuC5/ACcCbUxkcHW7ZuDm0eDvkIFB20a cIsAn1N7OUdxyKRbOYme/QtsBDo9E+SG =l+yv -END PGP SIGNATURE-
Re: [gentoo-dev] List of User projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 10:30, schrieb Luis Francisco Araujo: > himerge Hey :P - you are a gentoo dev :P I think probably most of the app-portage category falls in here (as portage is the only "gentoo-specific" thing one can develop stuff for): eix, etc-proposals, gpytage, ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvNxQACgkQ4UOg/zhYFuDVrACggJd2nxgymQxuYOyDtIPJyFlu doEAniynVE38AiCakLw2ASAGaGxHmuMb =O7Dv -END PGP SIGNATURE-
Re: [gentoo-dev] List of User projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 21:04, schrieb Brian Harring: > Instead, if the purpose is a "thanks", why not every once in a while > put up a news item discussing the tools in question? Such an > approach allows folk to focus in on whatever is useful/interesting > (regardless of origination) and give the same 'thanks' angle and > public exposure for the author in question. Like the "Gentoo Weekly/Monthly Newsletter" (R.I.P.)? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvtxgACgkQ4UOg/zhYFuDboQCaA7GzM15HcwYodI2J6CSio4iP +ukAnirlDoDkxwY2G+0ivxv3NneGGCjI =7fo7 -END PGP SIGNATURE-
[gentoo-dev] Proxying and bugzilla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
currently I am a maintainer for two packages -- and as a non-gentoo-dev
being proxied by guys who are.
Now a disadvantage of this position are the restricted rights in
bugzilla. In case a bug is filed for one of my maintained packages I
have to ask one of my proxies for each step ("could you mark this as a
dupe?", "could you mark this as fixed?", etc.). This is quite cumbersome
and puts just some load on the devs (which should have been avoided by
the proxy-solution in the first place).
So I am asking whether there would be a solution to allow people like me
to have full bugzilla rights on packages they are in charge for.
Two possibilities come to my mind:
1) Have an implicit restriction, i.e. give them full rights (where
"full" just means: everything they need for handling their bugs), but
make a policy, that they are only allowed to use this for their
packages. In other words: Enforce the correct usage by "legal" ways
instead of teachnically.
This approach is probably easier in terms of bureaucracy but might be
seen as dangerous.
2) Enforce the restriction technically. I do not know how this could be
done in bugzilla - perhaps by having "proxy-herds", i.e. one herd for
each proxied package and only give the user the full rights, if a bug is
assigned to a herd he is a member of.
The disadvantage is here, that there is quite some overhead of managing
a bunch of "proxy-herds".
Some sort of "bugzilla quiz" which needs to be taken by the maintainer
might be useful in both cases.
I'd be glad to hear some other opinions.
- - René
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuxH9sACgkQ4UOg/zhYFuAvogCfflrqjFg6iMq6OGEfp7Z4NHXS
ERUAnAonFFHRlGRYuKVSL12Vb2WinSAr
=1DOx
-END PGP SIGNATURE-
Re: [gentoo-dev] List of User projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.03.2010 01:47, schrieb Joshua Saddler: > 'Specially since they so often go defunct after a very short time -- I'm > thinking of all the Portage frontends in particular. Don't know what you are talking about :) ... Portato is now in its fourth year -- porthole is even older. Though I admit, that there is some kind of "functionality-oscillation". But if you ever tried to program against an undocumented API, with functionality that often changes in subtle ways, you'll know why ^^. - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuz1pcACgkQ4UOg/zhYFuBOUQCcCHrH9r/m5Hh6WNyq+fjFPQC+ Rw8An0QTv0S09N/Jpqg7cNgAjF03CKye =mA/r -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [Gentoo Phoenix] an official Gentoo wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.04.2010 20:11, schrieb Duncan: > William Hubbs posted on Sat, 10 Apr 2010 12:18:41 -0500 as excerpted: > >> - a phrase captcha (complete the phrase) > > The thing I've always read about these is that they tend to discriminate > against those for whom the language isn't their native language. [...] > Spelling captchas... > tend to run into problems with folks that can't spell. That's apparently > a big enough problem a lot of sites try and reject spelling captchas. Both points also apply to the audio captcha, as you have to a) understand the word and b) from this infer the correct writing. Which becomes even more difficult as English is a language, where the spelling/pronounciation-relation is quite loose (plus you have British/American spelling varieties). - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvAwsoACgkQ4UOg/zhYFuDM+wCbB+vkP+PnoTU8jnJv89Q2MdGk 46gAn1bsovc1aPbwWzP9A2g+iSGIf65r =SoEU -END PGP SIGNATURE-
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Am 03.04.2010 15:19, schrieb Ben de Groot: > On 3 April 2010 11:46, Patrick Lauer wrote: >> On 04/03/10 11:16, Tobias Scherbaum wrote: >>> People are constantly asking for a documentation wiki, but ... >> yeah, as long as no one just creates a wiki there won't be one. People >> are waiting on other people, who are waiting for Godot. Just do it. >> >> I remember the long and whiny road to get a blog aggregator - what >> killed the waiting deadlock was simply karltk setting up one (unofficial >> etc.etc.) and suddenly people saw that it was good. > > > Okay, so it seems a lot of people do want a wiki. So let's see what > we can do to make that happen. Just curious: Was something achieved here? Is there a wiki finally? - René signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New global USE flag: introspection
Am 21.06.2010 09:04, schrieb "Paweł Hajdan, Jr.": > I think that "introspection" is similarly too general. What about calling the useflag "GIR" (or "gir")? If the user does not know what it stands for, he will hopefully look up the description to see what it means. And in contrast to "introspection" the chance of getting a false sense of the meaning is low. Just as an idea (as I personally dislike awfully-long-useflag-names) - René signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
Am 23.11.2010 09:52, schrieb Branko Badrljica: > > My question is, could existing Portage infrastructure be ported to such > language with minimal effort and would it be worthwile to even try ? > > There are many operations that now take portage ages to complete, so it > seems that this could be benefitial... Don't forget, that Cobra compiles to C# which then is compiled to .NET CLI. I don't think, that anyone here feels really good about having the core package of Gentoo to require Mono. > Has anyone of Pythonistas tried to give Cobra a look or two ? One and a half year ago, yes. Looked nice, but the language then was still in a flow, and I didn't get used to mono and all the 'what libraries is he going to use from where?' stuff. I then even tried to make an ebuild, but this didn't work out. Might be different now. - Necoro signature.asc Description: OpenPGP digital signature
Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 15:30, schrieb Jeremy Olexa: > The tree has 679 m-n packages. > http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml If you cannot find someone else as a maintainer and someone is willing to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though only to manage my configs) and the current ebuild has been written by me (well - except the -r1-Diff). This would at least reduce the number of m-n packages to 678 :-) - René signature.asc Description: OpenPGP digital signature
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:47, schrieb Nirbheek Chauhan: > --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 > +++ metadata.xml 27 Mar 2011 20:46:54 - > @@ -3,7 +3,13 @@ > >no-herd > > -maintainer-nee...@gentoo.org > + Christopher Head > + hea...@gentoo.org That should be s/gentoo.org/gmail.com/, shouldn't it? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:44, schrieb Rich Freeman: > We shouldn't be punishing people for not becoming developers. I don't > want to use a distro that throws up warning messages every few months > because some package I've been using had its developer retire, and I'm > a developer. If it breaks and I care enough about it, I'll rescue it. > If I'm passionate about it, I'll step in before it breaks. Holding > users ransom is not the solution. Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). So, why not at least add some elog-like output at the end of an emerge run like "The following installed packages are without maintainer: $LIST. If you want to step up, please see $PROXY_MAINTAINER_URL." And before you state "well - it is enough if someone steps up when it breaks": Even then it might get unnoticed, that the package is unmaintained. I never check thoroughly where the package gets assigned to during bug-wrangling, and I suppose that I'm not alone here. So the only thing one notices is a bug which never gets any response. And this is frustrating. Regarding the pro-active masking/removal: As a user I'd object to this. Please try a less obtrusive path first, like the info output I mentioned above. Seeing that used packages gets masked quite often spawns bad mood (at least in my experience and seeing reactions in forum threads). - René signature.asc Description: OpenPGP digital signature
[gentoo-dev] Enabling the gmp-flag by default in profiles?
Hi all, I just noticed that the use flag "gmp" is not set by default, even though gmp is a mandatory dependency with gcc-4.x and should thus be installed on nearly every system. Are there reasons not to do so, or would it be more reasonable to specificly ask the package mantainers of the affected packages to enable this flag by default? Please note, that I'm just a user and by quickly looking over the description and homepage of gmp it striked me, that enabling gmp-support by default shouldn't be problematic but even an advantage. Thank you all, René signature.asc Description: OpenPGP digital signature
