[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
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 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email 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
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
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-portage-dev] [API] First steps for creating an API for portage
Am 18.06.2010 11:20, schrieb Fabian Groffen: That said, if you design C APIs, please design them from a C point of view, initially implemented by your Python functionality doing the necessary wrapping to get a sane C structure. Then they can be replaced by native C code as RSI and time permits in the future. This has been the idea. Perhaps not made clearly enough in my initial mail :) - René signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [API] First steps for creating an API for portage
Ok guys :) I think it has been consensus, that we need to define the operations everyone wants to be in the API. The following is currently only my point of view, but I'll represent it here also: Then a python-API is created which should allow for this set of operations. From this one could go and implement the library to make the API do something useful :) In parallel (or thereafter), we build the C-bindings. The API for these bindings probably look different -- but I guess they should be implemented in terms of the library created above. By example: - Operation: get the list of categories - Python-API: portage.api.categories() : Category list - Implementation: def categories(): return - C-API: category * categories() - C-Implementation: some wrapper around portage.api.categories So ... first step: Which operations do we need? - René signature.asc Description: OpenPGP digital 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 patr...@gentoo.org 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: [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-
[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 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-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marijn Schouten (hkBst) schrieb: Why is a custom set less convenient? Well, instead of emerge --trialware package you would first have to edit your @trialware set and then emerge @trialware. The same goes for when you want to remove some trialware. Perhaps some generalization of --trialware along the lines of --add-to-set=trialware could be fleshed out as a useful extension of portage. Marijn Well - and you also need to keep in mind to clean the set from time to time ... instead of just having a --depclean run - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkomzK8ACgkQ4UOg/zhYFuCSVACdF2/W736RnNJGs4/opSkl0Ggt Hw8An0ygC3opVGMXTVFqDD825IqpgbvL =BBip -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan schrieb: Patrick Börjesson psychoti...@lavabit.com posted 20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009 22:17:41 +0200: Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it. I use -1 by default, here (via scriptlet), mainly so I don't have to worry about cluttering up my world file while emerging individual packages, just as I always use -NuD with my @system and @world runs. But for leaf packages, it serves as a sort of test install as well. Since I always do revdep-rebuild -p and emerge --depclean -p after every update (typically 2-3 times a week), then rebuild and clean as I need to, keeping the trial merges on the depclean list for a few days keeps me aware of them. If I know it's something I want to keep, I run a different scriptlet without the -1, but that's not often once a system is up and running with the normal working set merged. Meanwhile, I ultimately either emerge -C (or let depclean handle it) the trialware, or emerge --noreplace, thus adding it to world. But experimental installs and their deps typically sit in the --depclean list for anything from a few minutes to a few days, until I decide whether I want to keep or remove them. If he was testing how the switches under discussion here worked and has a similar policy, I could easily see him using -1 by habit, even if he didn't explicitly reason that it was a test and therefore something he didn't want in @world. Well ... as one can probably see from the package names, I was just testing whether portage actually checks RDEPENDs of installed packages or not ;) (if it does not, Portato does not need to either ;)) And I often use -1 w/o even thinking about it - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkomzV8ACgkQ4UOg/zhYFuDyjACdHFOgdT8FABw/j4ta6aqutl7i 7X8AnjQvuHwY3iddJC5d0zRzv3PKoujL =WOYx -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick schrieb: It looks different, if spam is installed and I try to install bacon additionally: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] What happens if you use emerge -1avD bacon Does not work either. This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Yeah, it does look wrong, but I don't think it is. Ideally, I suppose eggs-1 could depend on !=app-test/spam-1 and so on, but that requires coordination among developers. I suppose there is a bug in the ebuilds because they should be set up so that if you have spam installed, you can't install bacon and so on. I think, this would be the wrong way., as they block each other already because of the RDEPEND. Else one would have to check the whole tree for a conflicting RDEPEND and then adding a whole bunch of blocks. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofqzsACgkQ4UOg/zhYFuD4XQCeKUuemmNjWr7shtgsttc93sro 1U0An0SrsWexvLUmYtvzyjokpZiQyqSm =vvTO -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with - --oneshot, it won't work either. Unless --complete-graph is specified emerge won't pull in the entire dependency graph, thus won't notice the dependency-spec of app-test/spam. Using -D combined with the world set when updating your system yields the same result as that also pulls in the entire dependency graph. Unless the entire dependency graph is pulled in emerge only tries to satisfy the dependencies of the packages given on the commandline, and since there's no connection between app-test/spam and app-test/bacon, and emerge doesn't do reverse deps when adding something to the dep-graph, it doesn't notice that app-test/bacon and app-test/spam has conflicting dependencies Using --complete-graph is noticably slower since it slows down dependency calculations, but it should (IMHO) really be the default since these conflicts shows _before_ anything breaks. I agree. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv 6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y =Haya -END PGP SIGNATURE-
[gentoo-portage-dev] Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
(The following is done with portage-2.2_rc33)
I created some small test-packages for the following usecase:
Package spam rdepends on =eggs-2.
Package bacon rdepends on =eggs-1.
So in theory there should be no way of installing them together (given
that eggs is not slotted). This works if I try to install them in one go.
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
app-test/eggs:0
('ebuild', '/', 'app-test/eggs-2', 'merge') pulled in by
=app-test/eggs-2 required by ('ebuild', '/', 'app-test/spam-1', 'merge')
('ebuild', '/', 'app-test/eggs-1', 'merge') pulled in by
=app-test/eggs-1 required by ('ebuild', '/', 'app-test/bacon-1',
'merge')
It looks different, if spam is installed and I try to install bacon
additionally:
# emerge -1av bacon
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild UD] app-test/eggs-1 [2] 0 kB [1]
[ebuild N] app-test/bacon-1 0 kB [1]
This second behavior looks wrong to me, as it downgrades the RDEPEND of
spam and thus spam becomes unusable.
Regards,
René
P.S.: In case it matters: You can find the repository containing the
trivial ebuilds here: https://code.launchpad.net/~necoro/+junk/test_repo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkofH/QACgkQ4UOg/zhYFuDK/ACfegI2ylDDQV1/VZu+XAXUMUpL
9icAnRSvVxoK/XuZhOO3jWlXmXUjWV7p
=1RJK
-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] Re: bzr.eclass: The next level (this time with patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer schrieb: Hi, René 'Necoro' Neumann li...@necoro.eu: 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] 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] 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
-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-portage-dev] equery: RFC and code review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring schrieb:
On Wed, Feb 11, 2009 at 11:10:43PM -0800, Alec Warner wrote:
belongs.py has this gem:
q.append(('^' if query[0] == '/' else '/') + re.escape(query) + '$')
Also a python2.6 only feature...
~brian
python-2.5 it is ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmT83cACgkQ4UOg/zhYFuAnUQCeJs+JtVjJEs83xbffyEZTV7DE
j/MAnRo0hIynhEZUdrtF2FzJiW1Z3nB7
=zTDf
-END PGP SIGNATURE-
Re: [gentoo-portage-dev] search functionality in emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, has your project resulted in anything? :) Just curios about perhaps nice portage additions ;) Regards, Necoro Emma Strubell schrieb: Hi everyone. My name is Emma, and I am completely new to this list. I've been using Gentoo since 2004, including Portage of course, and before I say anything else I'd like to say thanks to everyone for such a kickass package management system!! Anyway, for my final project in my Data Structures Algorithms class this semester, I would like to modify the search functionality in emerge. Something I've always noticed about 'emerge -s' or '-S' is that, in general, it takes a very long time to perform the searches. (Although, lately it does seem to be running faster, specifically on my laptop as opposed to my desktop. Strangely, though, it seems that when I do a simple 'emerge -av whatever' on my laptop it takes a very long time for emerge to find the package and/or determine the dependecies - whatever it's doing behind that spinner. I can definitely go into more detail about this if anyone's interested. It's really been puzzling me!) So, as my final project I've proposed to improve the time it takes to perform a search using emerge. My professor suggested that I look into implementing indexing. However, I've started looking at the code, and I must admit I'm pretty overwhelmed! I don't know where to start. I was wondering if anyone on here could give me a quick overview of how the search function currently works, an idea as to what could be modified or implemented in order to improve the running time of this code, or any tip really as to where I should start or what I should start looking at. I'd really appreciate any help or advice!! Thanks a lot, and keep on making my Debian-using professor jealous :] Emma -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmUdZIACgkQ4UOg/zhYFuDRQQCfeVXb6uy+wBSKll4MHq54MiyX VawAn0TWrTBVKuxAPFWpQMvvO3yED5Fs =dBni -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Re: search functionality in emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emma Strubell schrieb: 2) does anyone really need to search an overlay anyway? Of course. Take large (semi-)official overlays like sunrise. They can easily be seen as a second portage tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk0YpEACgkQ4UOg/zhYFuD3jQCdG/ChDmyOncpgUKeMuqDxD1Tt 0mwAn2FXskdEAyFlmE8shUJy7WlhHr4S =+lCO -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-portage-dev] search functionality in emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Auty schrieb: Finally there are overlays, and since these can change outside of an emerge --sync (as indeed can the main tree), you'll have to reindex these before each search request, or give the user stale data until they manually reindex. Determining whether there has been a change to the ebuild system is a major point in the whole thing. What does a great index serves you, if it does not notice the changes the user made in his own local overlay? :) Manually re-indexing is not a good choice I think... If somebody comes up here with a good (and fast) solution, this would be a nice thing ;) (need it myself). Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkp0kAACgkQ4UOg/zhYFuAhTACfYDxNeQQG6dysgU5TrNEZGOiH 3CoAn2wV6g8/8uj+T99cxJGdQBxTtZjI =2I2j -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. snip 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-portage-dev] portage-py3k status report
What's the best way to send patches for the patches ;) ? For example in http://dev.gentoo.org/~hawking/portage-2to3/auto/11-portage-2to3-map.patch - there is the following hunk: hunk diff --git a/pym/portage/process.py b/pym/portage/process.py index f766d30..dc425af 100644 --- a/pym/portage/process.py +++ b/pym/portage/process.py @@ -21,7 +21,7 @@ except ImportError: if os.path.isdir(/proc/%i/fd % os.getpid()): def get_open_fds(): - return map(int, [fd for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()]) + return list(map(int, [fd for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()])) else: def get_open_fds(): return xrange(max_fd_limit) /hunk But the complete expression could be rewritten as: return [int(fd) for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()] This is more readable - and you don't need to traverse the list multiple times. Alternatively - if you like the functional style more: return list(map(int, filter(str.isdigit, os.listdir(/proc/%i/fd % os.getpid() Again more readable (if you are used to the functional style ;)) - and only one traversal (as iterators are used). /edit: I sent this mail twice, because Roundcube had chosen the wrong sender name and I guess, that this mail was blocked then. Excuses if you get the mail twice. Regards, Necoro
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-portage-dev] portage-2.2-rc3 parallel merges quit being parallel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan schrieb: Also, a little monitoring utility that could be run in another terminal and just list and update all the currently merging packages, and any that had failed to merge, so I could take a look at them while the system is still working on the rest, would be quite useful. A very basic thingy: watch qlop -cC qlop is part of portage-utils. And it seems to only work correctly here, when run as root :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiM2zoACgkQ4UOg/zhYFuBQwQCeOPut3WtWXQYZuvpRuf0HFqNk r4wAn3JUVV3HWb/OYooBTNxz5mqb9Skx =Wdte -END PGP SIGNATURE-
[gentoo-portage-dev] Exporting basic emerge/portage functionality in an API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think, this is already somewhere on the agenda of portage (perhaps with a low priority ;)), but I nevertheless wanted to ask for the possibility to have as much of emerge's functionality exported in an API as possible =). The reason behind this is, that for Portato (this GUI thingy ;)), I have to re-implement lots of things that portage does (update functionality, parts of dep-string parsing etc). This is kind of sisyphean, because one has to: - - notice/detect subtle changes (esp. the updating process often changes unnoticed in small points) - - support tons of portage versions Especially with larger bumps (2.1.1 - 2.1.2; - 2.2) there are lots of things breaking and showing another behavior. In the sum, this work takes quite a large part of the whole development process ... though showing no results for the user ;) Thus, it would be really great, if I only had to use an API (which might change over time - but API changes are easier to track and to work around). Perhaps - as you currently seem to be restructuring the whole thing - you can bundle some things and export them :). I bet there are more people out there besides me, that use or want to use the portage API and would be thankful, when they don't have to reinvent things :) Else - thank you guys for your great work :). It's very great to see portage's evolution over the last months. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiM4ToACgkQ4UOg/zhYFuBx8gCeMU+pZht4rosLNBU32YlSAex3 LyYAnRqVLpguj4i9ZHAcbQEYtTmvSNY+ =F398 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [RFC/PATCH] New objects cpv, pv and version to be used instead of raw strings.
On Fri, 18 Jul 2008 12:41:52 +0300, Ali Polatel [EMAIL PROTECTED] wrote: Hi, Attached patch adds objects cpv, pv and version to portage.versions. This is meant as a thin layer over functions vercmp(), pkgcmp(), pkgsplit() and catpkgsplit(). Using these objects instead of the mentioned functions allows us to write cleaner code and remove deprecated stuff like: list.sort(pkgcmp) which won't exist in py3k. Please comment. Is there a reason, why you are using __new__ instead of __init__? Regards, René -- gentoo-portage-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] 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
[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] 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
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] 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
[gentoo-portage-dev] Small patch for portage_dep.strip_empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, while looking through portage code, I saw, that portage_dep.strip_empty also modifies the passed list _in place_: | l = [0,1,2,3,4] | strip_empty(l) [1, 2, 3, 4] | l [1, 2, 3, 4] I don't know if this is wanted behavior - but as it is not documented, I doubt it :) Thus - a small patch: And now using filter for this task :). I hope nothing relies on the side-effect desribed above. Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2CUK4UOg/zhYFuARAp+PAJ9sLQ/M7OQGTLZN8RBaOwEdvKZ9tACeIq51 DqAXNQHuM9CqoFaR14EiRyQ= =Nb2a -END PGP SIGNATURE- --- portage_dep.py.old 2008-03-12 09:06:00.0 +0100 +++ portage_dep.py 2008-03-12 09:06:44.0 +0100 @@ -44,10 +44,7 @@ @rtype: Array @return: The array with empty elements removed - for x in range(len(myarr)-1, -1, -1): - if not myarr[x]: - del myarr[x] - return myarr + return filter(None, myarr) def paren_reduce(mystr,tokenize=1):
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: 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 USE
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] 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 USE flag [flag name]
- 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: [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.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-portage/portato/portato-0.8.6.ebuild?rev=1.1content-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] 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] 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=2219416view_id=235 http://www.spreadshirt.net/shop.php?op=articlearticle_id=311913p=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
