[gentoo-dev] Re: Packages up for grabs
Hi, Thomas Anderson <[EMAIL PROTECTED]>: > On Sun, Jul 20, 2008 at 08:44:24AM +0200, Christian Faulhammer wrote: > > app-admin/tmpwatch -- low maintenance > > > I can take this one. Please add yourself and reassing bugs. > > dev-cpp/libthrowable, > > app-portage/gatt -- very cooperative upstream for both (mlangc for > > both) > > > > I can also take these two as well, as I use them for arch testing. Also great. Please see above for actions. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: Packages up for grabs
Hi, Alexis Ballier <[EMAIL PROTECTED]>: > > dev-lang/erlang (lang-misc) -- a version bump now and then (four > > times a year), seldomly but then obscure bugs, cooperative upstream > > I would appreciate if you could take care of my fbsd problem ;p Done. > > media-sound/cmus -- low maintenance > > can probably be dropped to sound Great. Done. > I hope that doesn't mean you're planning to retire ;p Kind of. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-07-20 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-07-20 23h59 UTC. Removals: Additions: sci-astronomy/wcslib2008-07-15 15:16:24 bicatali net-irc/irssi-otr 2008-07-16 14:10:55 armin76 dev-python/Babel2008-07-16 17:14:08 cedk profiles/default/linux/x86 2008-07-16 18:30:37 armin76 dev-libs/protobuf 2008-07-17 23:16:44 spock dev-java/slf4j-api 2008-07-18 19:06:00 serkan dev-java/slf4j-nop 2008-07-18 19:11:21 serkan dev-java/mina-core 2008-07-18 19:20:26 serkan dev-java/libmatthew-java2008-07-18 19:31:15 serkan dev-java/dbus-java 2008-07-18 19:37:49 serkan app-text/zemberek-server2008-07-18 19:51:04 serkan dev-java/java-dep-check 2008-07-18 22:06:04 betelgeuse app-text/zpspell2008-07-18 22:32:15 serkan -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: Added Packages: sci-astronomy/wcslib,added,bicatali,2008-07-15 15:16:24 net-irc/irssi-otr,added,armin76,2008-07-16 14:10:55 dev-python/Babel,added,cedk,2008-07-16 17:14:08 profiles/default/linux/x86,added,armin76,2008-07-16 18:30:37 dev-libs/protobuf,added,spock,2008-07-17 23:16:44 dev-java/slf4j-api,added,serkan,2008-07-18 19:06:00 dev-java/slf4j-nop,added,serkan,2008-07-18 19:11:21 dev-java/mina-core,added,serkan,2008-07-18 19:20:26 dev-java/libmatthew-java,added,serkan,2008-07-18 19:31:15 dev-java/dbus-java,added,serkan,2008-07-18 19:37:49 app-text/zemberek-server,added,serkan,2008-07-18 19:51:04 dev-java/java-dep-check,added,betelgeuse,2008-07-18 22:06:04 app-text/zpspell,added,serkan,2008-07-18 22:32:15 Done.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap: openldap-2.4.7.ebuild openldap-2.4.10.ebuild openldap-2.3.41.ebuild
On Sunday 20 July 2008, Robin H. Johnson wrote: > On Sun, Jul 20, 2008 at 10:19:10AM +, Peter Alfredsen (loki_val) wrote: > > loki_val08/07/20 10:19:10 > > > > Modified: openldap-2.4.7.ebuild > > openldap-2.4.10.ebuild openldap-2.3.41.ebuild > > Log: > > Propagate fix for glibc-2.8 to more versions, including masked > > ones. (Portage version: 2.2_rc1/cvs/Linux 2.6.25.8 i686) > > Why didn't you touch ChangeLog? Please remember to do so in future? Because the commit just did what the latest entry in the changelog said I would do. I of course now, having done it, realize that it won't state which files I changed. Mea maxima culpa. Sincerely, Peter Alfredsen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposal: Make developer profiles more difficult to select
On Sat, Jul 19, 2008 at 11:39 AM, Nikos Chantziaras <[EMAIL PROTECTED]> wrote: > Reading around on the net, it amazes me how many people are using developer > profiles for their Gentoo because they think it's for software developers > and don't see that it's for Gentoo developers and not intended for end > users. They know the "Developer" installation profiles of other distros and > think Gentoo's profiles are just the same (on those distros, selecting a dev > profile just means it installs GCC + dev libs + IDEs by default.) > > Some kind of warning or other mechanism that does selecting this profile > without knowing what you're doing would be a good idea. I don't think the profiles are not intended for end users; if they are only intended for developers we could just exclude them from the rsync tree. That being said I think it is fairly trivial to rename it to 'ebuild-developer'. Screw all these stupid warnings and VARS_IN_ALL_CAPS> Just name shit properly and I'm sure folks can probably figure it out. I feel very badly for the 'developers' running with 'stricter' or other insane portage features that basically make the distro unusable ;p -Alec > > -- > gentoo-dev@lists.gentoo.org mailing list > >
Re: [gentoo-dev] Packages up for grabs
On Sun, Jul 20, 2008 at 08:44:24AM +0200, Christian Faulhammer wrote: > app-admin/tmpwatch -- low maintenance > I can take this one. > dev-cpp/libthrowable, > app-portage/gatt -- very cooperative upstream for both (mlangc for > both) > I can also take these two as well, as I use them for arch testing. pgp3tCSB9jUdf.pgp Description: PGP signature
[gentoo-dev] call for maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I am looking for someone who would be interested in taking maintainership of the following: app-accessibility/festival app-accessibility/speech-tools There are several open bugs against festival and requests to add some new voices as well which I will assign to you. I don't recommend doing the voices as parts of the festival package itself though since you would need to do a rev bump every time one of the voices does another release. If you are interested in maintaining these, please let me know. Thanks, - -- William Hubbs gentoo accessibility team lead [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiDd24ACgkQblQW9DDEZTjYIQCfem5odjxI4hOjmJna33PPEUkf ZagAn2ZXaK7e444EKsQkLd8ikyVtjCOE =vcf9 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Peter Volkov wrote:
> This means that every ebuild which uses 'unpack ${A}' should have in
> DEPEND a program which is selected by filename extension of sources. So
> as I understood your initial suggestion was to make this happen
> automatically. And this is very logical as makes ebuilds cleaner and
> more terse. So why did you changed your mind and try to write another
> eclass (which then should sit in the tree forever), to create duplicate
> unpack function instead of just making step you suggested initially? Is
> there any intension to remove unpack logic from package manager? And if
> yes, why?
++
I also was wondering this. And if we add "unpack2()", which could be a
little hard to explain in the documentation, it will need to be there at
least until ebuilds stop using it (when portage gets this functionality
ultimately).
For my uses, I'd rather do deps manually and use the official portage
unpack() until portage has such features in order to keep my ebuilds
looking a bit more clean.
-Joe
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap: openldap-2.4.7.ebuild openldap-2.4.10.ebuild openldap-2.3.41.ebuild
On Sun, Jul 20, 2008 at 10:19:10AM +, Peter Alfredsen (loki_val) wrote: > loki_val08/07/20 10:19:10 > > Modified: openldap-2.4.7.ebuild openldap-2.4.10.ebuild > openldap-2.3.41.ebuild > Log: > Propagate fix for glibc-2.8 to more versions, including masked ones. > (Portage version: 2.2_rc1/cvs/Linux 2.6.25.8 i686) Why didn't you touch ChangeLog? Please remember to do so in future? -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpr9WIDSJ30k.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Hi, > dev-lang/erlang (lang-misc) -- a version bump now and then (four > times a year), seldomly but then obscure bugs, cooperative upstream I would appreciate if you could take care of my fbsd problem ;p > mail-client/claws-mail and all plugins (net-mail) -- a version bump > is some work, but low rate of bugs, ken69267 is there to maintain, > but he maybe needs a helping hand Never had any problem with it, I'm using it as my mail client on several boxes, if you or Kenneth need any specific help, feel free to poke me/cc me on bugs. > media-sound/cmus -- low maintenance can probably be dropped to sound I hope that doesn't mean you're planning to retire ;p Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
On Sun, 20 Jul 2008 17:41:58 +0400
Peter Volkov <[EMAIL PROTECTED]> wrote:
> В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
> > At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
> > to implement this feature.
>
> Marius, although it's possible to do this things in eclass why is
> eclass better? As I see portage's unpack() already has extension <->
> "program to unpack" relation. Basically unpack() in ebuild.sh has the
> following code:
>
> unpack() {
> [snip]
> case "${x##*.}" in
> tar)
> tar xof "${srcdir}${x}" ${tar_opts} || die "$myfail"
> ;;
> tgz)
> tar xozf "${srcdir}${x}" ${tar_opts} || die "$myfail"
> [snip and so on...]
>
> This means that every ebuild which uses 'unpack ${A}' should have in
> DEPEND a program which is selected by filename extension of sources.
> So as I understood your initial suggestion was to make this happen
> automatically. And this is very logical as makes ebuilds cleaner and
> more terse. So why did you changed your mind and try to write another
> eclass (which then should sit in the tree forever), to create
> duplicate unpack function instead of just making step you suggested
> initially? Is there any intension to remove unpack logic from package
> manager? And if yes, why?
The eclass is provided as a proof-of-concept implementation that can be
used without adding additional infrastructure and implementing and
defining a new EAPI version. PM-based solutions would be nicer
long-term, but are also more tricky to "get right" (mainly a question
of where to inject the deps). Also the eclass approach has the benefit
that the whole unpack logic can be maintained in one location vs. being
split between multiple places in the package manager and the tree, and
is easier to extend (no need for an EAPI change just to add a new unpack
format).
And as you ask, there have been plans to move quite a bit of
the bash code from portage into the tree (transparently to ebuilds
though) as that's the better place to maintain many helper functions
like do* or new* that are only used by ebuilds/eclasses and not portage.
But those plans have already existed for years (long before EAPI
existed) without anything happening, and they've never been very
specific wrt what exactly could be moved.
Even with a PM-based solution it might be useful, depending on the
actual implementation, to have the unpack() funtion in the tree, for
the reasons outlined in the first paragraph.
Marius
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On 2008-07-20 17:38, Peter Volkov uttered these thoughts: > В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: > > Which part of the 'Problem' section in the GLEP didn't you understand? > > Do you seriously consider not being able to add or change global scope > > functions in future EAPIs to be a non-issue, or were you ignoring those > > two bullet points? > > I've read all previous discussions but still miss answer to the > question: Why is it impossible to state that .ebuild extension is for > bash based ebuild make package manager get and filter EAPIs based on > EAPI variable? Because that would still not allow global scope changes, because in order to get to know which EAPI the ebuild is written in, you have to actually source the ebuild, and by then it's too late. Unless you introduce some inane requirement that the EAPI variable has to be the first thing stated in the ebuild and force the PMs to extract that value before actually starting to parse the ebuild. Now, if _that's_ not an ugly solution, i don't know what is... You have to know _how_ to interpret an ebuild _before_ you actually start doing it. > Note, I assume that we can do not backward-compatible changes in PM, we > just need to wait enough time to start using it. But taking into account > that the features that will make use of this GLEP55 are still not so > evident I don't see any problem to wait. In any case I'd like to > understand why should we start support this hell of extensions. Reasons for the change has been stated before, and the one i just explained is the main one so far as i know. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpG4XHQmlNIp.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 20 Jul 2008 17:38:32 +0400 Peter Volkov <[EMAIL PROTECTED]> wrote: > В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: > > Which part of the 'Problem' section in the GLEP didn't you > > understand? Do you seriously consider not being able to add or > > change global scope functions in future EAPIs to be a non-issue, or > > were you ignoring those two bullet points? > > I've read all previous discussions but still miss answer to the > question: Why is it impossible to state that .ebuild extension is for > bash based ebuild make package manager get and filter EAPIs based on > EAPI variable? I think your question is missing a word or something. I'm not entirely sure what you're trying to ask... But if you're asking why we can't use the EAPI variable, it's because we can't get the EAPI variable unless we already know what it is. It's only possible currently because all EAPIs have identical global scope functions and environment requirements, but future EAPIs want to change things there. > In any case I'd like to understand why should we start support this > hell of extensions. Why do you think it's hell? It's just as easy as having an EAPI variable inside the ebuild, and has the added advantage that your editor of choice can start doing EAPI-aware syntax highlighting for you. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
В Чтв, 17/07/2008 в 04:51 +0200, Marius Mauch пишет:
> At dev.gentoo.org/~genone/unpack.eclass is the draft for an eclass
> to implement this feature.
Marius, although it's possible to do this things in eclass why is eclass
better? As I see portage's unpack() already has extension <-> "program
to unpack" relation. Basically unpack() in ebuild.sh has the following
code:
unpack() {
[snip]
case "${x##*.}" in
tar)
tar xof "${srcdir}${x}" ${tar_opts} || die "$myfail"
;;
tgz)
tar xozf "${srcdir}${x}" ${tar_opts} || die "$myfail"
[snip and so on...]
This means that every ebuild which uses 'unpack ${A}' should have in
DEPEND a program which is selected by filename extension of sources. So
as I understood your initial suggestion was to make this happen
automatically. And this is very logical as makes ebuilds cleaner and
more terse. So why did you changed your mind and try to write another
eclass (which then should sit in the tree forever), to create duplicate
unpack function instead of just making step you suggested initially? Is
there any intension to remove unpack logic from package manager? And if
yes, why?
--
Peter.
Re: [gentoo-dev] Council meeting summary for 10 July 2008
В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: > Which part of the 'Problem' section in the GLEP didn't you understand? > Do you seriously consider not being able to add or change global scope > functions in future EAPIs to be a non-issue, or were you ignoring those > two bullet points? I've read all previous discussions but still miss answer to the question: Why is it impossible to state that .ebuild extension is for bash based ebuild make package manager get and filter EAPIs based on EAPI variable? Note, I assume that we can do not backward-compatible changes in PM, we just need to wait enough time to start using it. But taking into account that the features that will make use of this GLEP55 are still not so evident I don't see any problem to wait. In any case I'd like to understand why should we start support this hell of extensions. -- Peter.
[gentoo-dev] Re: Proposal: Make developer profiles more difficult to select
Ben de Groot <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 20 Jul 2008 02:48:48 +0200: > Jeremy Olexa wrote: >> Nikos Chantziaras wrote: >>> Some kind of warning or other mechanism that does selecting this >>> profile without knowing what you're doing would be a good idea. >> >> This isn't enough? >> >> %% grep KNOW * >> make.defaults:I_KNOW_WHAT_I_AM_DOING="yes" >> > Nobody ever reads make.defaults... The point is... well, take a look at for example, amd64/2008.0/server/profile.bashrc . During the dev phase there's normally similarly scary warnings about all the dev profiles. Sometimes they don't just warn, either, but stop, unless the appropriate var is set correctly. While Gentoo in general does try to take reasonable precautions and this would seem a case in point, it has never been about keeping those determined to work without safety nets as it were, from cutting down those very safety nets. If that's the way they want to run (and potentially break), so be it. OTOH, it could also be argued that either the tested var or the tested value of that var should include the profile version (say 2008.0), so someone who chooses to test one development profile doesn't find the next one auto-enabled when they set it accidentally, just because they never removed the var. IOW, what about: I_KNOW_WHAT_I_AM_DOING="2008.0" or alternatively I_KNOW_WHAT_I_AM_DOING_2008_0="yes" Or even the arch/version, so in the case above I_KNOW_WHAT_I_AM_DOING_amd64_2008_0="yes" or I_KNOW_WHAT_I_AM_DOING="amd64/2008.0" -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: Installation of static libraries, USE=static-libs proposal
В Втр, 01/07/2008 в 05:05 +0300, Mart Raudsepp пишет:
> Over a year or two ago, it was communicated that it supposedly a policy
> that USE=static
Well, I don't have web-reference at hand now, but there was a thread in
gentoo-dev with the subject: "Say no to static libraries!". Summarizing
some ideas from there:
1. Some packages will break if you build their deps with USE=static.
This can be fixed when we start to use USE-deps in the tree.
2. We already have mechanism to make what you want. Just drop
EXTRA_ECONF="--disable-static" into your make.conf and to workaround
problem stated in point 1 use
EXTRA_ECONF="${EXTRA_ECONF/--disable-static}"
in /etc/portage/env/cat/pkg. (For those who interested list of packages
for which I have to filter --disable-static is in attachment).
Well, I'm using EXTRA_ECONF for more then year now and I'd like to say
that it's not perfect solution. Not all packages are autotools based and
ignore --disable-static and now I have 103M of static libs on my
desktop. So now I'm all for having static-libs USE flag. But please,
don't do that on per-package base. Make an eclass for that. Think about
not-autotools packages, and don't put it in the tree until we start
using USE deps.
Thanks for reiterating this discussion. I wanted to return to it soon as
seems that USE deps are really about to enter our life.
And BTW, seems that all gnome packages obey EXTRA_ECONF ;)
--
Peter.
dev-libs/popt
dev-libs/lzo
dev-libs/libpcre
dev-libs/xmlrpc-c
dev-libs/libol
media-libs/pdflib
media-sound/audacity
sys-devel/gdb
sys-devel/libtool
sys-apps/ed
sys-apps/ed
sys-fs/fuse
dev-ruby/rcairo
dev-ruby/rcairo
