Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Wed, 7 Mar 2012 21:41:02 +0100 Ulrich Mueller wrote: > Hi all, > > The way how we currently specify the EAPI in ebuilds has some > problems. For example, there is no sane way to allow usage of features > of a new bash version in a new EAPI. So we are currently stuck with > bash 3.2. Also changes of global scope behaviour, like addition of new > global scope functions (similar to "inherit") are not possible. > > These flaws are outlined in GLEP 55 [1]: > | In order to get the EAPI the package manager needs to source the > | ebuild, which itself needs the EAPI in the first place. Otherwise it > | imposes a serious limitation, namely every ebuild, using any of the > | future EAPIs, will have to be source'able by old package managers > | [...] > > The council has voted down GLEP 55 more than a year ago, but at the > same time requested that a solution for the mentioned issues should be > found. [2] However, there was no progress since then. > > The issue arose again in bug 402167 [3] where several solutions have > been discussed. Below, I try to summarise the possible options > resulting from that discussion. > > > *** Proposal 1: "Parse the EAPI assignment statement" *** > > This first proposal would require that the syntax of the EAPI > assignment statement in ebuilds matches a well defined regular > expression. A scan of the Portage tree shows that the statement only > occurs in the following variations (using EAPI 4 as example): > >EAPI=4 >EAPI="4" >EAPI='4' > > Sometimes this is followed by whitespace or a comment (starting with > a # sign). Also, with very few exceptions the EAPI assignment occurs > within the first few lines of the ebuild. For the vast majority of > ebuilds it is in line 5. > > Written in a more formal way, appropriate for a specification: > - Ebuilds must contain at most one EAPI assignment statement. > - It must occur within the first N lines of the ebuild (N=10 and N=30 > have been suggested). > - The statement must match the following regular expression (extended > regexp syntax): > ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ > > Note: The first and the third point are already fulfilled by all > ebuilds in the Portage tree. The second point will require very few > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). > > The package manager would determine the EAPI by parsing the assignment > with above regular expression. A sanity check would be added. Citing > Zac Medico in [3]: "The fact that we can compare the probed EAPI to > the actual EAPI variable after the ebuild is sourced seems like a > perfect sanity check. We could easily detect inconsistencies and flag > such ebuilds as invalid, providing a reliable feedback mechanism to > ebuild developers." > > This proposal comes in two variants: > 1a) The change is applied retroactively for all EAPIs. > 1b) It is only applied for EAPI 5 and later (which means that the > result of the EAPI parsing would be discarded for earlier EAPIs). > > > *** Proposal 2: "EAPI in header comment" *** > > A different approach would be to specify the EAPI in a specially > formatted comment in the ebuild's header. No syntax has been suggested > yet, but I believe that the following would work as a specification: > - The EAPI must be declared in a special comment in the first line of > the ebuild's header, as follows: > - The first line of the ebuild must contain the word "ebuild", > followed by whitespace, followed by the EAPI, followed by > end-of-line or whitespace. > > Again, the proposal comes in two variants: > 2a) It is combined with a one time change of the file extension, like > .ebuild -> .eb. > 2b) The usual EAPI assignment statement in the ebuild is still > required, at least for a transition period. > > In the 2a case, the EAPI variable could be made read-only in bash > before sourcing the ebuild. In the 2b case, a sanity check similar to > the one mentioned above would be added. > > > What do you think? > > (I really hope for a constructive discussion here. So, if you want > to comment that all of the above proposals suck and GLEP 55 is much > superior, then please open a new thread for it.) > > Ulrich > Currently 5 proposals are listed on the wiki. [4] While all of them have some temptations the actual goal is to make obtaining the EAPI the very first step so everything else can be defined in terms of EAPI and so immediately deployable in future. This are changes in atom syntax like needed for GLEP 54 or those bash feature often mentioned besides many other things one can think of. GLEP 55 requires changing ebuild extensions on a regular basis but doesn't impose any limit on the ebuild format or atom syntax, only the file extensions would be imposed. The ebuild extensions for GLEP 55 would likely always be ebuild- as integers are reserved for future use by Gentoo. While for example .ebuild-5 is still recognised as an ebuild; .eb .ebld .ebd .bld .
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs wrote:
> On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> > On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > > New udev and separate /usr partition
> > >
> > > Decide on whether a separate /usr is still a supported
> > > configuration. If it is, newer udev can not be stabled and
> > > alternatives should be investigated. If it isn't, a lot of
> > > documentation will have to be updated. (And an alternative should
> > > likely still be provided.)
>
> There is no disagreement about whether or not separate /usr will be
> supported. No one has said that you can't have a separate /usr
> partition.
>
Isn't meant /usr without initramfs, independent of how "broken" some
people precieve it?
> Was the council aware of the tracker bug we have open where we are
> tracking the documentation changes explaining how to build an
> initramfs if you have a separate /usr partition [1]?
>
That's an effort I welcome either way. So thanks for that.
> Also, I am going to reiterate what Greg said. This is not an issue
> with udev, but with the entire linux ecosystem.
> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.
>
With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?
> Also, with the appropriate documentation changes, which are being
> worked on (see [1]), I feel that the statement above that newer udev
> can't be stabled should be re-evaluated.
>
Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)
There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.
Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.
Cheers
Ralph
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959
signature.asc
Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny wrote: > d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Also, there still should be a bug at b.g.o and git format-patch works just fine for that. Maybe it's only github now but how many places is a developer supposed to monitor? signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On Tue, 29 May 2012 18:27:51 +0200 hasufell wrote: > Well then let my clarify: I'm against too many pre-set (meaning > "activated") features/useflags. Think of it as nouserpriv feature. ;) Either way, to disable userpriv is kind of working against QA as a package really should be build-able as non root user but then. Have userpriv and usersandbox enabled since it's became available, no issues to report. signature.asc Description: PGP signature
[gentoo-dev] [java-utils-2.eclass] - removal of java-pkg_ensure-test and java-pkg_ensure-gcj
Both java-pkg_ensure-test and java-pkg_ensure-gcj will be removed from
java-utils-2.eclass after the 4 of July 2012. See attached patch.
java-pkg_ensure-test: [1]
Was used to enforce USE=test if FEATURES=test. For quite some time this
is handled by package managers. Relies on the env var FEATURES [2].
There are no known consumers any more.
Solution: Remove the call to java-pkg_ensure-test and rely on the
package manager handling this.
java-pkg_ensure-gcj:
Uses built_with_use [3] and ebeep [4] and is no longer needed with EAPI
2 or later. There are no known consumers for quite some time.
Solution: Migrate to EAPI 2 or later and depend on sys-devel/gcc[gcj]
instead.
[1] https://bugs.gentoo.org/show_bug.cgi?id=278965
[2] https://bugs.gentoo.org/show_bug.cgi?id=174335
[3] https://bugs.gentoo.org/show_bug.cgi?id=261562
[4] https://bugs.gentoo.org/show_bug.cgi?id=377943
Index: java-utils-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/java-utils-2.eclass,v
retrieving revision 1.150
diff -u -b -B -r1.150 java-utils-2.eclass
--- java-utils-2.eclass 13 Mar 2012 10:05:46 - 1.150
+++ java-utils-2.eclass 4 Jun 2012 10:15:57 -
@@ -1686,23 +1686,13 @@
}
java-pkg_ensure-gcj() {
- if ! built_with_use sys-devel/gcc gcj ; then
- ewarn
- ewarn "You must build gcc with the gcj support to build with gcj"
- ewarn
- ebeep 5
- die "No GCJ support found!"
- fi
+ # was enforcing sys-devel/gcc[gcj}
+ die "${FUNCNAME} was removed. Use use-deps available as of EAPI 2 instead. #261562"
}
java-pkg_ensure-test() {
- if has test ${FEATURES} && ! has -test ${FEATURES} \
- && has test ${IUSE} && ! use test;
- then
- eerror "You specified FEATURES=test, but USE=test is needed"
- eerror "to pull in the additional dependencies for testing"
- die "Need USE=test enabled"
- fi
+ # was enforcing USE=test if FEATURES=test
+ die "${FUNCNAME} was removed. Package mangers handle this already. #278965"
}
# --
signature.asc
Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico wrote: > On 06/07/2012 01:24 AM, Brian Harring wrote: > > On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: > >> On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > >>> On Wed, 06 Jun 2012 21:16:05 +0200 > >>> Pacho Ramos wrote: > Well, I think reading this thread is more or less clear what it > would be supposed to do, also Zac suggested it and looks to have > an idea about what should it do. > >>> > >>> There's a big leap from "more or less clear" and "an idea" to the > >>> kind of knowledge we want to have. Think REQUIRED_USE for how > >>> this can go wrong... > >>> > >>> If you think ABI_SLOT is essential, why not try implementing it > >>> and trying it out in a large number of packages, and reporting > >>> your results? > >> > >> It's pretty close to the SLOT operator model, and it seems like it > >> should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, > >> and test it in an overlay before we include it in the final EAPI 5. > > > > I'd prefer you nailing down the details a bit more before slipping > > it into an EAPI called "5_pre1"; aside from usual complaints, > > frankly I'd rather not have to figure out the design of it via > > raiding the patches out of portage history ;) > > Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe > we can convince him to change it to ABI_SLOT operators. > Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. > > If we're going to do this, there should be a way to represent > > the direction of compatibility. Might be overthinking it, but > > consider upgrades where new API is added; this does *not* break > > ABI, it extends it. Going in reverse however *would* break ABI for > > anything that was using the new additions. This issue can be > > avoided via usage of version operators w/ appropriate slot binding > > deps, just seems hanky in light of what we're talking about. > > That might be nice, but it also complicates things a bit. We might > stand a better chance of getting Ciaran to cooperate if we keep it > simpler and stay closer to the SLOT operator model. > Again, it's not about getting someone to cooperate. Something that you comment with "that might be nice" isn't ready for inclusion into EAPI 5. > > I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing > > in '06/'07); I'd however suggest ensuring there is some buy in from > > devs on that one since that was the main argument against it in the > > past. > > I can imagine that ABI_SLOT operator deps will be a lot more popular > than SLOT operator deps, since ABI_SLOT operator deps will accommodate > the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. Cheers. signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh wrote: > Can we all agree to just stop this and just restrict the arguing to > being between SDEPEND and DEPENDENCIES? Cheers. I clearly favour going with SDEPEND now as this fits better what people are used to and the move to DEPENDENCIES is also a chance to clean up dep-specs after we added all quirks we need(*). Let's name GLEP 54 here which we hopefully can add to EAPI 6. (*) or for when we run out of special chars ;) signature.asc Description: PGP signature
Re: [gentoo-dev] ewarn and package upgrades
On Sat, 23 Jun 2012 07:40:02 -0400 Rich Freeman wrote: > On Sat, Jun 23, 2012 at 7:32 AM, wrote: > > WARN: postinst > > Please rebuild both libxcb and xcb-util if you are upgrading from > > version 1.6 > > > > I've read enough warnings like this (many packages use them) that it > occurred to me that perhaps there should be some better way of dealing > with this. > > I realize we have a huge discussion going on about suggested depends > and such which could resolve it long-term. If that really doesn't > work out, then perhaps at least it would be useful if it were obvious > in ELOG messages what the old and new version were, or some other > stopgap measure. Bonus points if the ebuild can figure it out and > only generate the warning conditionally, but I'd be happy if I could > just delete the message without having to figure out what version I > was previously running... > > Rich > REPLACING_VERSIONS and REPLACED_BY_VERSION added in EAPI 4 can be used to do this things with elog messages.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 20:33:35 +0200 "Andreas K. Huettel" wrote: > Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: > > On 06/30/2012 04:07 AM, Pacho Ramos wrote: > > > I would like to discuss a bit more issues like: > > > https://bugs.gentoo.org/show_bug.cgi?id=423087 > > > > > > Even if there are "a lot" of packages that can cause this > > > breakage when downgraded, I think it should be prevented and > > > package managers shouldn't try to downgrade this kind of packages > > > as they will later cause a total breakage. People is not supposed > > > to know that downgrading some package system will, for example, > > > have an unusable gcc. > > > > It seems like a die in pkg_pretend would serve pretty well. > > As a comparatively simple, user-oriented workaround, since this only > happens at downgrades and these should be pretty rare, I have the > following suggestion: > > Make a portage feature that is **on by default**, which causes > portage to generate a binpkg of the version to be unmerged, in the > case of a downgrade. > > Rationale: > * if you know what you are doing, you can switch this off easily > * does not take much space since downgrades are rare > * should help our users a lot, whenever someone accidentally or > not-knowingly downgrades something critical. > > Thoughts? > That might be neat, but it would already help if you had to add --allow-downgrades or similar to emerge in case Portage wants to downgrade one or more packages. Besides preventing an accidental downgrade it would raise the awareness of the problem. > Cheers, > Andreas > signature.asc Description: PGP signature
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 13:01:52 -0700 Zac Medico wrote: > On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: > > That might be neat, but it would already help if you had to add > > --allow-downgrades or similar to emerge in case Portage wants to > > downgrade one or more packages. > > Besides preventing an accidental downgrade it would raise the > > awareness of the problem. > > I think people would just put it in EMERGE_DEFAULT_OPTS and forget > about it, since downgrades are a fairly common occurrence, due to > changes in version numbering schemes or buggy versions being dropped > from the tree. Maybe a RESTRICT="downgrade" metadata setting would > help to reduce the noise so that people would be less likely to > enable --allow-downgrades by default. Nothing wrong with people putting --allow-downgrades into EMERGE_DEFAULT_OPTS if they choose to do so. At least people who'd like this protection could make use of it. Usually both upstream and maintainer put quite a bit of thought into an upgrade path but hardly the other way around. On a system with mixed keywords it's far more common to see downgrades because the unmasked version was removed before stable did catch up than pseudo downgrades because we have no epochs or alike. signature.asc Description: PGP signature
[gentoo-dev] Last rite: app-misc/jbidwatcher
# Ralph Sennhauser (13 Jul 2012 # Mask for removal in 30 days. Fails to build with java 7 #421917. # QA issues #298701. Ceased to be useful long ago. #235124. Thanks # to Michael Weber #235124 for maintaining a # binary package in his overlay. (layman -a xmw) =app-misc/jbidwatcher-1* signature.asc Description: PGP signature
Re: [gentoo-dev] DESCRIPTION in eclasses
On Thu, 19 Jul 2012 08:57:09 +0200
Ulrich Mueller wrote:
> Thanks, this explains why these DESCRIPTIONs are there.
>
> But history left aside, are they still useful today? If not, then they
> should be removed.
DESCRIPTION="Based on the ${ECLASS} eclass" is never a sufficient
description for a package. So clearly pointless here.
Currently only KEYWORDS are banned from eclasses. I would add
DESCRIPTION and LICENSE to this list as well. DESCRIPTION is individual
to the package and it should never be to much work to come up with a
short description and LICENSE in eclasses greatly increases the chances
for the final listed licenses to be wrong. We have seen the latter
happening with the enlightenment.eclass.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot wrote:
> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
>
> In order to keep the code simple, and prevent double loops and extra
> variables (such as currently used in the media-video/smplayer ebuild),
> I am proposing that we should add any missing long-form locales to
> profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
> This also means that users may have to expand their LINGUAS setting in
> make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
> cover the different variants used in packages.
>
> If you have any comments, spot any mistakes, or have proposals for
> improvement, I would love to hear it! I would especially love from
> maintainers of complicated packages such as libreoffice-l10n, if there
> is any additional functionality that we could include in this eclass
> to make their job simpler.
>
> 1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.
Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.
for locale in ${PLOCALES}; do
if use linguas_${locale}; then
enabled_locales+=" ${locale}"
else
disabled_locales+=" ${locale}"
fi
done
First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot wrote:
> I got a few more suggestions on IRC, and I have updated the eclass
> accordingly. Please check the attached new version, also available at
> https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
Pseudo inlining
> # Add linguas useflags
> if [[ -n "${PLOCALES}" ]]; then
> for u in ${PLOCALES}; do
> IUSE+=" linguas_${u}"
> done
> fi
no need to guard the loop against empty $PLOCALES.
> l10n_for_each_locale_do() {
> local locs x
> locs=$(l10n_get_locales)
> if [[ -n "${locs}" ]]; then
> for x in ${locs}; do
> ${@} ${x} || die "failed to process enabled
> ${x} locale" done
> fi
> }
same here, no guarding required and "${@}" should be quoted as it may
contain args with spaces. Also in l10n_for_each_disabled_locale_do.
> # ones. This function is normally used internally in this eclass, not
> by # l10n.eclass consumers.
> l10n_get_locales() {
I'd mark this function @INTERNAL then, at least until someone can
presents a use case.
If you are sufficiently sure this function shouldn't be used by
consumers you could remove the function in favour of 'use linguas_${x}
|| continue' in l10n_for_each_locale_do resp 'use linguas_${x}
&& continue' in l10n_for_each_disabled_locale_do.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Mon, 23 Jul 2012 20:29:44 +0800
Ben de Groot wrote:
> >> # ones. This function is normally used internally in this eclass,
> >> not by # l10n.eclass consumers.
> >> l10n_get_locales() {
> >
> > I'd mark this function @INTERNAL then, at least until someone can
> > presents a use case.
> > If you are sufficiently sure this function shouldn't be used by
> > consumers you could remove the function
>
> There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have
> an editted -r10 revision in my dev overlay. I'm sure it could be
> handled with l10n_for_each_locale_do, but the migration is more
> straight-forward by simply using l10n_get_locales in this case.
>
> This is why I worded it "normally" instead of "only". Maybe the
> wording could be improved?
The primary concern should be expressiveness. That said, qttwitter
looks like a good example use case. You have convinced me.
src_configure() {
qmake4 PREFIX="/usr" LANGS="$(l10n_get_locales)"
}
Maybe l10n_get_enabled_locales would read even more natural here?
Either way I'd drop the internal entirely as it also provides a simple
way to "sanitize" LINGUAS without relying on the package manager. ie.
setting 'LINGUAS="$(l10n_get_locales)"' in an ebuild would enable the
possible EAPI 5 behaviour described later in this thread, which would
allow direct use of LINGUAS. The only difference being the backup
locale.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, 24 Jul 2012 08:48:52 + Sven Vermeulen wrote: > Can current users also already use the /etc/portage location? If so, > I can already update the docs now (since I'll need to describe both > of the locations for a while anyhow). I moved my make.conf to the new location about a year ago.
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Tue, 24 Jul 2012 12:29:14 +0300 Maxim Kammerer wrote: > On Tue, Jul 24, 2012 at 3:07 AM, Jorge Manuel B. S. Vicetto > wrote: > > I propose to commit this news item in 2 or 3 days. Does anyone have > > any comments about it? > > Several comments: > > 1. Maybe note that /etc/portage/make.conf takes precedence > over /etc/make.conf? > > 2. New make.conf location (although supported) is not mentioned in > portage(5) man page for currently stable sys-apps/portage (2.1.10.65). > man 5 portage about files in /etc/portage make.conf The global custom settings for Portage. See make.conf(5). If present, this file will over‐ ride settings from /etc/make.conf. > 3. This news item is really useful, since the change has a potential > to break automated builds. We aren't discussing dropping support for the old locations here but about makeing the new location the default.
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Sat, 28 Jul 2012 14:27:49 +0800 Ben de Groot wrote: > On 28 July 2012 13:59, Nikos Chantziaras wrote: > > On 28/07/12 08:22, Ben de Groot wrote: > >> > >> In preparation for that, we want to ask maintainers of all ebuilds > >> in the tree with dependencies on Qt4, to make sure that they have > >> the proper slot. Otherwise your package may pull in Qt5 while it > >> may not in fact support it. > > > > > > This can be trouble if the application actually works with Qt5. It > > might depend on Qt4 but has no problems with Qt5 (contrary to Qt3 > > vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code), > > needlessly pulling-in Qt4. Many applications simply build and run > > as-is and no code changes are necessary. > > > > So what would be the methodology of making sure a package has the > > proper slot? > > Obviously you would need to make sure that the package actually does > support Qt5. Then, as I see it, we could do either: > > || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 ) Never prefer an old version in an || ( ) block, this makes for a poor update experience. Also the || ( ) construct can only be used if they are runtime switchable, which I really doubt here, as otherwise you build against one, the user install the other and portage depcleans the one you have built against. > > or: > > qt4? ( x11-libs/qt-gui:4 ) > qt5? ( x11-libs/qt-gui:5 ) > A qt5 useflag will do more harm than good. If I enable qt, I do not care which version, I just want the gui for the particular app. If the app works with qt:5 the usflag qt means qt:5, if it only works with qt:4 the useflags means qt:4. In case it works with both and the maintainer thinks it's worth to let the user choose, use the useflag qt4 to let the user opt out of the latest and greatest. > Other thoughts?
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot wrote: > We do not have (nor want to support) a qt useflag. We have opted > for "qt4" and "qt5" useflags as the most straightforward and least > confusing. Indeed, the flag qt has almost disappeared from the tree. Good to know.
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Sun, 16 Sep 2012 19:41:14 -0700
Brian Harring wrote:
> On Sun, Sep 16, 2012 at 10:10:47PM -0400, Mike Frysinger wrote:
> > On Sunday 16 September 2012 03:51:04 Brian Harring wrote:
> > > + if ! has $EAPI 0 1 2 3; then
> > > + eqawarn "built_with_use should not be used in
> > > $EAPI; use USE deps."
> > > + elif has $EAPI 2 3; then
> > > + if [[ $hidden == yes ]] || $missing_was_set; then
> > > + eqawarn "built_with_use in EAPI=$EAPI
> > > without --missing or --
> > hidden
> > > usage, should use USE deps instead." +else
> > > + eqawarn "built_with_use should not be
> > > used; upgrade to EAPI=4
> > instead"
> > > + fi
> > > + fi
> >
> > i'd do:
> > case ${EAPI:-0} in
> > # No support in these EAPIs, so don't warn.
> > 0|1) ;;
> > # Maybe warn as some functionality exist.
> > 2|3) [[...]] && eqawarn "..." ;;
> > # Assume EAPI=4 or newer where all functionality exists.
> > *) eqawarn "..." ;;
> > esac
>
> I'd be fine w/ it; worth noting, that was a 4am patch, so I'm not
> claiming perfect implementatoin there. :)
>
> My main focus here is switching built_with_use to actively nagging
> people to stop using it; this includes nagging EAPI0/1 users of it.
>
> Sans the implementation details, anyone got complaints with the
> intent?
How about raising the EAPI baseline from 0 to 2 - ie. every package may
use EAPI 2; not the same as deprecating 0 1 - and do:
case ${EAPI:-0} in
0|1|2|3|4) eqawarn "From onwards this will die" ;;
*) die ... ;;
esac
as EAPI 2 supports the --missing case via constructs as:
|| (
>=foo/bar-1
https://bugs.gentoo.org/show_bug.cgi?id=261562
> ~brian
>
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 08:45:22 +0200 Ralph Sennhauser wrote: > The aim would be to get rid of built_with_use not only in a distant > future. The corresponding bug [1] is from 2009 and can't be fixed ... without something like "increasing EAPI baseline".
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 00:58:02 -0700
"Gregory M. Turner" wrote:
>
> > My main focus here is switching built_with_use to actively nagging
> > people to stop using it; this includes nagging EAPI0/1 users of it.
> > Sans the implementation details, anyone got complaints with the
> > intent?
>
> I have a concern about it, yes. But, maybe there's a good answer to
> my concern, so please consider this a friendly ebuild development
> question disguised as a complaint :)
>
> Unless I'm missing something, it seems that once we deprive the
> ebuild developer of this feature, there is no simple, supported way
> to retrieve the information except to depend on it.
>
> The issue is that calculating dependencies is not the only reason we
> might want to know if a package was built with a particular USE-flag,
> and if we get rid of built_with_use, we literally cut ourselves off
> from retrieving this information in any officially sanctioned way
> (except to DEPEND on it, which may not be semantically correct).
>
> I can think of all kinds of legitimate reasons we might want to know
> if the installed such-and-such package was built with so-and-so
> use-flags without depending on it. i.e.:
>
> o if the current gcc falls within a certain range of version
> numbers and was built with graphite, we are going to trigger
> a compiler bug. Suppose that there is no graphite support
> or dependency in ${P}, and that we can apply a patch which will
> work around the bug, but at a performance cost in ${P} we'd rather not
> pay unless we have to.
>
> o We need to modify a Makefile based on how a package we
> BDEPEND on was built -- but suppose there is no BDEPEND
> /limitation/ to enforce -- in other words, either way, our package
> will build, and there is no correlating reverse dependency to
> worry about at runtime.
>
> Such needs are fairly unusual, but they do come up in real life.
>
> My concern is that this will lead to people doing things like:
>
> o cut-pasting the old implementation of built_with_use into ebuilds,
> -- but that implementation will break if the portage database
> layout changes
>
> o creating bogus one-off use-flags as a way of performing these
> queries (and, thanks to the upcoming requirement that USE flags
> always appear in IUSE, exposing those flags to the end-user,
> perhaps with some confusing description like "whether such-and-such
> was built with so-and-so").
>
> o creating BDEPENDs of -- and sketchy parsers for -- portage-utils
> or similar suites, just to ask this question.
>
> Admittedly, it's hard to prevent people from doing
>
>built-with-use foo/bar baz || die "${P} needs foo/bar with baz"
>
> since, once upon a time, that was SOP, and we'd have to parse the
> bash code or something to qa warn for it automatically.
>
> But any number of similar prohibitions are simply documented in the
> developer handbook, including this one.
>
> Am I missing something, here? I kinda think we should go the
> opposite direction and un-deprecate the API. It seems like we are
> cutting off our nose to spite our face here.
>
> -gmt
>
has_version foo/bar[baz] can be used in EAPI 2 and later.
[gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
From time to time the topic of deprecating EAPIs comes up and usually one suggestion is to keep 0 and start with converting EAPI 1 ebuilds. Then someone comes along and asks what is the point? Indeed, a fair question. The following tries to take a different approach to the topic. It's not all thought through in detail, but that wont happen anytime soon, after all it's on my TODO for long enough. So I present it in the hope others will try to poke holes into it or even pick it up. EAPI=0 requirement pointless? - The EAPI=0 requirement comes from having to provide an update path for systems with a package manager without EAPI support. By now we are talking about really ancient systems and it's questionable if there is any merit in supporting such. Further the situation is that some of the maintainers of must be EAPI 0 ebuilds already moved on as the majority of users will profit from a bump. As a result the clean upgrade path is already borked and the value of keeping others at EAPI=0 deteriorates further and further. Forcing EAPI 0 on some maintainers for all eternity doesn't strike me as brilliant, quite the opposite frankly. After all new EAPIs are supposed to contain bug fixes and new features required to write better ebuilds. If all installed PMs supported EAPI? The issue of an update path is reduced to keeping intermediate versions in tree. Those PMs also support EAPI=1, rendering EAPI=0 obsolete. Base EAPI - Systems without having a package manager installed that supports at least the 'Base EAPI' aren't considered supported any longer. Maintainers of system packages can use the Base EAPI without worrying. Maintainers of system packages can use more recent EAPIs but need to take special care. Value of Base EAPI -- Maintainers of system packages need to be able to use newer EAPIs after some time. They can wait but not forever. built_with_use removal is one example, strong vs weak blockers an other. The value can be based on time ( i.e. after 3 years ) or set by council decision. A combination is fine as well. The value should be kept low enough so the rule "maintainers don't have to care about using it" holds. The need of derived distributions / package managers should be considered, ie. let them catch up if necessary. Security updates should be possible for some time without full updates. This extends to other packages as well. So maintainers of critical non system packages can use this EAPI as well if they want. Guess EAPI=2 would be a reasonable compromiss. Deprecation? EAPIs below the base EAPI can be considered deprecated if one desires. References in devmanual can be removed and so the document be simplified. Once there are only few ebuild of a deprecated EAPI left, it might make sense to convert them and add a repoman check so the number of used EAPIs is kept reasonable. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 12 Oct 2012 21:10:23 -0600 Ryan Hill wrote: > I'd argue against deprecating EAPI 0 any time soon though. Killing > EAPI 1 would be a better idea. I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be gone from tree in 3-5 years once the EAPI=0 requirement is lifted. Currently we have only 6 official EAPIs which is still manageable to remember the details of each. Though it might be confusing for new developers. Once we are at 20 EAPIs it will be an issue also for seasoned folks. Therefore deprecation is a given, how to go about it is certainly up to discussion. What do you see as an acceptable path here? signature.asc Description: PGP signature
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On Thu, 29 Nov 2012 17:09:34 +0100 justin wrote: > On 29/11/12 16:51, Ian Stakenvicius wrote: [...] > > ..ok remind me again what the .pc files provide you? this is so > > that you can have slotted blas providers and various packages can > > choose their preferred one instead of having to use the eselected > > one? or... > > > > Not exactly. > The user can choose for each package newly by eselecting the wanted > implementation. This is the user side. From the pm side we ensure that > the choice is really respected by linking against package specific > names [1] instead of the generic ones e.g. libblas.so. And this can be > achieved in an easy way by using pkg-config. > > justin > > 1) > # eselect blas set atlas-threads > # pkg-config --libs blas > -lptf77blas -lm -latlas -lpthread > > # eselect blas set reference > # pkg-config --libs blas > -lrefblas > This immediately bears the following questions: * How do you ensure the linked against implementation doesn't get depcleaned? revdep-rebuild maybe? * How do you let users configure the implementation to be used on a per package basis? Interrupt an emerge world to set the appropriate implementation for the next few packages? signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, 14 Dec 2012 12:02:40 -0800 Greg KH wrote: > On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: > > On 14/12/12 01:28 PM, Greg KH wrote: > > > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: > > >> Handling separate /usr support == > > >> After the discussion on [1] during the previous meeting, a delay > > >> of one month due to a new fork of udev was requested. We need an > > >> update on what's happened. > > >> > > >> Chainsaw reported udev and eudev have moved on, and for both it > > >> is now possible to have a separate /usr. The follow-up > > >> discussion related to the /usr-merge is necessary. > > > > > > udev was never the problem of having a separate /usr without an > > > initrd. Have all of the other packages been properly fixed to > > > resolve this issue correctly? > > > > > > Also, what's the plan for eudev going forward? > > > > > > > > > Eudev's project announcement is coming soon, should answer your > > questions. > > Ok, when is "soon"? I'm guessing that the result of the council > meeting ment that things are progressing, right? If so, in what way? Why would it matter if soon meant a week or a month from now? > > > In terms of udev's dependencies, yes, the few dependencies that were > > installing only to /usr (ie, kmod and xz-utils) have been switched > > to install to /, and then fixed again due to issues with they way > > they were done the first time so that they also work. I believe > > however they are still ~arch keyworded. > > I am not referring to udev's dependancies, that was never the real > issue with a separate /usr/ partition as those could easily be fixed > with a configuration option for the package. > If some vocal upstream and otherwise respected maintainers claim it to be broken and calls everyone a fool for not following suite, that's what we get. ;) > > There may of course be other entirely independent packages needed at > > boot time prior to localmount, I do not know that status of those. > > That's the big problem, those need to be fixed. But there is no hurry as separate /usr is broken for years, right? > > > Once eudev (the gentoo package) fully supports separate-/usr (which > > it doesn't at this time as it uses the same init scripts as > > udev-196), we will be sure to resolve them. > > Again, udev itself was never an issue, it could work just fine with a > separate /usr/ partition. Now perhaps our ebuild didn't build it in > that matter, but that's a configuration/ebuild issue, not a upstream > package issue. > udev not only could work just fine with a separate /usr but potentially make it a non issue. Let's see if eudev succeeds here. If it's the right place to solve it is another question, though the right place for udev isn't in systemd either. > > It should be noted that sys-fs/udev (the package) since .. 186 I > > think? whichever version dropped support for the failed-rules queue > > (and whichever package dropped the udev-postmount init script) does > > not support booting with a separate /usr. This has more to do with > > how the package installs than the upstream code itself, though; as > > such (WilliamH please correct me if I'm wrong) the plan is still to > > require an initramfs if using sys-fs/udev with a separate-/usr. > > If the plan is still to require an initramfs (hint, it's the only way > it can work), then why was the eudev package forked and created? > sys-fs/udev is systemd-udev, hope we don't have to rename the package to make this clear. > Please, I'm totally confused now, especially after reading the commits > in the eudev repo, I see nothing that fixed any /usr/ problems, what > am I missing? > The sentence in the very same mail that it's currently not working / implemented maybe? > Oh, you also slowed the build time of the package down in eudev > compared to udev, but I'm sure you realized that already, and did it > for a good reason. That's always the last straw, spd! > > confused, > > greg k-h > Seriously, while I agree the eudev fork had an ivory tower start, I don't get what you gain by running around like an elephant in a porcelain shop. I for one welcome yet another fork. Time will tell if it can prevail. Regards Ralph
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Fri, 4 Jan 2013 23:34:59 -0600 Donnie Berkholz wrote: > On 10:26 Sat 22 Dec , Pacho Ramos wrote: > > Hello > > > > After seeing: > > https://bugs.gentoo.org/show_bug.cgi?id=440214 > > > > Looking to a lot of its blockers shows that we are using "elog" > > messages for informing people about configuration (like pointing > > people to external links to get proper way of configuring things, > > tell them to add to some system groups...). I thought that maybe > > this kind of information could be simply included in a canonical > > file under /usr/share/doc/ package dir called, for example, > > CONFIGURATION or SETUP. We would them point people (now with a news > > item, for the long term provably a note to handbook to newcomers > > would be nice) to that file to configure their setups. The main > > advantages I see: > > - We will flood less summary.log ;) > > - The information to configure the package is always present while > > package is installed, now, if we remove merge produced logs, people > > will need to reemerge the package or read directly the ebuild > > > > What do you think? > > Bikeshedding ... would go with README.gentoo, because people are > already used to looking for README files. Every time we can eliminate > Gentoo-specific weirdness, we should. > See the documentation for README.Debian[1], most importantly the example. ;) I'd say we should handle it the same as Debian does. What could we possibly gain from doing it differently? [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme signature.asc Description: PGP signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Mon, 21 Jan 2013 13:27:18 +0800 Ben de Groot wrote: > On 21 January 2013 12:16, Peter Stuge wrote: > > Panagiotis Christopoulos wrote: > >> I don't build server machines every day, others do and it would be > >> much appreciated if they could respond here. > > > > I build catalyst stage4s. Any default profiles are kindof pointless > > for me; I have USE=-* and the flags that I want. > > > > Anything else seems a bit too random. > > This is why I think we do need something like a truly minimal profile > to start building from. Too many people are doing this. > -* will still be required by those same people for EAPI 1 package defaults. Cleaning a profile won't change that. signature.asc Description: PGP signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Tue, 29 Jan 2013 22:47:26 +0100
Pacho Ramos wrote:
> Also, autoformatting will help to prevent every package setting
> messages with different lines length (in some cases really long lines
> that I finally reported some bugs in the past to get them fitting in
> "standard" 80 characters per line).
I agree with you, there should be consistency as far as reasonable.
Formatting certainly is a valid means. Some sort of tags could
be used if formatting isn't desired. Ie similar to eclass-manpages.
The eclass blurb:
readme.gentoo - An eclass for installing a README.gentoo doc file
recording tips
I know it started out as CONFIGURATION, but README.gentoo is generic
enough to contain other package specific info a user or upstream
developer might be interested in. What I have in mind right now are
patches.
This could look like the following in an ebuild:
README_GENTOO_PATCHES=( "${FILESDIR}"/*.patch )
epatch "${README_GENTOO_PATCHES[@]}"
Then the eclass generates for each patch in README_GENTOO_PATCHES a
note within a standard section containing patch name, author, subject
line. This needs something similar enough to a git format patch to
magically work though, but might be a nice addition and would help the
goal of consistency. Also git-format-patch like patches are anyway
preferable to dangling patches with maybe a bug number in the ebuild
at best.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Add "test" to IUSE_IMPLICIT
On Sat, 2 Feb 2013 23:33:26 + "Aaron W. Swenson" wrote: > After years of "if use test ; then ..." just working when > FEATURES="test" is declared, it isn't working with EAPI5. I think we > could save some bytes and headaches if we just add "test" to > IUSE_IMPLICIT. > > Portage's emerge's "--newuse" option won't be affected by this. From > `man emerge`: > > NOTE: This option ignores the state of the "test" USE flag, since > > that flag has a special binding to FEATURES="test" (see make.conf(5) > > for more information about FEATURES settings). > > What say you? > That test shouldn't be a useflag in the first place, that there should be a TESTDEPEND and a dedicatated function defined in PMS to let the ebuild check if src_test will be executed. 'test' as we use it is pretty much a hack. Another note, 'if use test; then' is often very similar in nature to conditional patching and should be avoided where reasonably possible. Either way, I'm against adding test to IMPLICIT_IUSE on the basis of 'I was lazy and want to continue to do so'. Regards Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On Sun, 03 Feb 2013 13:46:52 +0100 Pacho Ramos wrote: > dev-libs/boehm-gc Will take this one in a few days if no one else grabs it first. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On Mon, 04 Feb 2013 09:16:32 +0800 Patrick Lauer wrote: > On 02/03/2013 09:45 PM, Ralph Sennhauser wrote: > > On Sun, 03 Feb 2013 13:46:52 +0100 > > Pacho Ramos wrote: > > > >> dev-libs/boehm-gc > > > > Will take this one in a few days if no one else grabs it first. > > > Since it's a dependency of one package I maintain > (dev-lang/opendylan) I have a marginal interest in keeping it around. > Feel free to add me to metadata too if I forget. > Added both of us. signature.asc Description: PGP signature
Re: [gentoo-dev] January stabilization candidates
On Sun, 10 Feb 2013 12:22:13 +0100 ""Paweł Hajdan, Jr."" wrote: > I can actually batch invalidate all of them. This will generate some > further bug spam (I apologize), but can save your time dealing with > the mess. Please let me know what's your preference. The URL field is likely not filled out as intended either. So you might want to do that anyway. signature.asc Description: PGP signature
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On Tue, 19 Feb 2013 14:10:33 +0100 Thomas Kahle wrote: > ... if it is used in the ebuild? > > It is a system package here on amd64, but is it everywhere? > > Cheers, > Thomas > Gnu sed version 4 is guaranteed by pms [1] [1] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12500011.3.1 signature.asc Description: PGP signature
[gentoo-dev] New license - adobe-pcfi
Hi, I'm querying this list out of the need of adding a new license[1] for adobe-pcfi[2]. Suggested name for the license is adobe-pcfi. An other possibility could be Adobe-PCFI to better match other Adobe* licenses. The license would be added to the MISC-FREE license group. If you have any doubts let me know before I proceed in about a week. Thanks to ssuominen and robbat2 for their initial guidance. Cheers, Ralph. [1] https://github.com/jukka/pcfi/blob/master/src/main/resources/META-INF/LICENSE.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=448532 A in-lined copy of the license follows: -- = PDF Core Font Information = This package contains PDF font information files downloaded from http://www.adobe.com/devnet/font/#pcfi and elsewhere. See the individual files and the summary below for related copyright and licensing information. Any Adobe patents covering information in these files should be included in the patent pledge they have made to ISO for the PDF 1.7 standard. Here's what Adobe legal wrote when asked about this: "Adobe has provided a patent pledge to ISO which states that Adobe will grant a fee and royalty free license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and under other reasonable terms and conditions to make, use, and sell implementations of PDF 1.7 (ISO 32000-1)." (private communication to Jukka Zitting, 2008-12-03) See also the following page for more information about patents related to PDF: http://partners.adobe.com/public/developer/support/topic_legal_notices.html Font Metrics for PDF Core 14 Fonts -- The files in com/adobe/pdf/pcfi/afm were downloaded from http://www.adobe.com/devnet/font/pdfs/Core14_AFMs.zip on 2009-06-14. The MustRead.html file contains the following license: This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. The individual AFM files contain further copyright notices. The aggregate of these notices is: Copyright (c) 1985, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved. Helvetica and Times are trademarks of Linotype-Hell AG and/or its subsidiaries. ITC Zapf Dingbats is a registered trademark of International Typeface Corporation. CMaps for PDF CJK Fonts --- The CMap files in com/adobe/pdf/pcfi/*/ were downloaded from http://www.adobe.com/devnet/font/pdfs/ and elsewhere. All the individual CMap files in these directories contain copyright sections with a license for redistribution. The aggregate of this information is: Copyright 1990-2007 Adobe Systems Incorporated. All Rights Reserved. Patents Pending NOTICE: All information contained herein is the property of Adobe Systems Incorporated. Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. PostScript and Display PostScript are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. Adobe Glyph List The glyph list in com/adobe/pdf/pcfi/glyphlist.txt was downloaded from http://www.adobe.com/devnet/opentype/archives/glyphlist.txt on 2010-08-06. Copyright (c) 1997,1998,2002,2007 Adobe Systems Incorporated Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file to use, copy, publish, distribute, sublicense, and/or sell copies of the documentation, and to permit others to do the same, provided that: - No modification, editing or other alteration of this document is allowed; and - The above copyright notice and this permission notice shall be included in all copies of the documentation. Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file, to create their own derivative works from the content of this document to use, copy, publish, distribute, sublicense, and/or sell the derivative works, and to permit others to do the same, provided that the derived work is not represented as being a copy or version of this document. Adobe shall not be liable to any party for any loss of revenue or profit or for indirect, incident
Re: [gentoo-dev] New license - adobe-pcfi
On Sun, 10 Mar 2013 11:10:38 + "Robin H. Johnson" wrote: > On Sun, Mar 10, 2013 at 11:01:55AM +0100, Ulrich Mueller wrote: > > > CMaps for PDF CJK Fonts > > > --- > > > [...] > > > Permission is granted for redistribution of this file > > > provided this copyright notice is maintained intact and > > > that the contents of this file are not altered in any > > > way from its original form. > > This would imply that the license cannot be added to the MISC-FREE > > group. > Ok, I think @BINARY-REDISTRIBUTABLE may be workable instead for this > license. > Thanks to both of you. So the current plan is: license name: Adobe-PCFI license group: BINARY-REDISTRIBUTABLE If there are no further objections within a week I'll commit the license. signature.asc Description: PGP signature
Re: [gentoo-dev] Handling of tests (was: GCC USE flag changes)
On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill wrote: > I'm also going to rename the "test" flag to "regression-test" or > something similar to get it out of FEATURES="test" control. The > testsuite is a huge time-suck and only useful to developers IMO > (always expected to fail and primarily meant to be used to check for > regressions between patchsets). I'm a big supporter of > FEATURES="test" by default and I think this is a small step towards > that. This step is so tiny that we wont ever reach the goal like this. Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) ... and improve on how to configure Portage whether to run tests of any given category. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC USE flag changes
On Wed, 01 May 2013 01:29:05 -0400 "Rick \"Zero_Chaos\" Farina" wrote: > Sadly it is so > bad that we have a FEATURES=test-fail-continue I can't really say > anything negative, that fact really says it all... My beef is not with the existence of this FEATURE but that it's enabled in the dev profile. I was lucky once to not commit a broken testsuite.
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, 8 May 2013 13:37:51 -0400 Rich Freeman wrote: > Bottom line is that none of this should really be inconveniencing > maintainers much - nobody is required to create unit files. However, > if a friendly user submits a bug with one attached, then the > maintainer should strongly consider adding them to the package at the > next convenient time. Indeed no maintainer should be bothered with having his package install a unit file, though two points. A maintainer usually dislikes adding something contributed by a user that he doesn't know about / can't verify . So letting systemd herd picking unit files and committing them I think is reasonable. The chance for screwing with a package by just adding the unit file are close to zero even if not familiar with the package. The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wed, 1 May 2013 19:18:52 -0600 Ryan Hill wrote: > On Wed, 1 May 2013 10:14:02 +0200 > Ralph Sennhauser wrote: > > > On Tue, 30 Apr 2013 21:25:40 -0600 > > Ryan Hill wrote: > > > > > I'm also going to rename the "test" flag to "regression-test" or > > > something similar to get it out of FEATURES="test" control. The > > > testsuite is a huge time-suck and only useful to developers IMO > > > (always expected to fail and primarily meant to be used to check > > > for regressions between patchsets). I'm a big supporter of > > > FEATURES="test" by default and I think this is a small step > > > towards that. > > > > This step is so tiny that we wont ever reach the goal like this. > > I was hoping it would set a precedent and then people would start > thinking of splitting up test into categories, maybe even start a > thread about it ;). Hehe, yes, you forced me to speak up with trying to set a precedent I think will get in the way of solving it in a more complete way. Though for that we have to agree on - split is desirable - which categories and how to classify tests - how to implement the splitting (EAPI support?) [...] > > ... and improve on how to configure Portage whether to run tests of > > any given category. > > Yeah I'd love to be able to do something like emerge TESTS="dev qa > system -extradeps -expensive" @world. > > I was thinking about a /etc/portage/package.test that works more like package.use. So most users will want to have something like: # package.test */* cheap Others might use: # package.test */* cheap normal */*::sunrise expensive my-pkg/foo * # broken test suite, bug XXX =dev-foo/bar-1.1 -* This would also be pretty similar to what your regression-tests useflag for gcc would have been. Even though Portage allows you to configure FEATURES=test on a per package basis since a couple years it doesn't seem to have become a common practice. While Portages mechanism is powerful it might be just to complex or tedious for the average user. As for your example command line 'emerge TESTS="dev qa system -extradeps -expensive" @world', could you elaborate on what the categories dev qa system are about? signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH FIXED] Introduce edefault() as a friendly default sub-phase wrapper.
On Sat, 11 May 2013 11:51:39 -0400 Mike Gilbert wrote: > On Sat, May 11, 2013 at 5:30 AM, Michał Górny > wrote: > > Fixed naming the proper default sub-phase and declaring 'edefault' > > in python_prepare_all(). > > --- > > I think I prefer to explicitly name the function I want to call, so I > don't really see any great benefit here. I'm not strongly opposed to > it, but I don't see myself using it either. Same here for the reason you mention below. Long term I expect it to be more of a hassle than typing a few additional letters now. > Also, how would this interact with other eclasses which may define a > similar "edefault" function? Packages using distutils-r1 don't often > utilize other phase-happy eclasses, but I'm sure it will happen > eventually. >
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Fri, 10 May 2013 06:09:32 -0400 Rich Freeman wrote: > On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser > wrote: > > The other thing is those unit files really should come from upstream > > and other distributions urge their developers to work with upstream > > [1] Therefore I'd require an upstream bug for each unit that we add. > > Makes sense, though I wouldn't necessarily make it a hard requirement. > Also, upstream units may not be usable as-is. They might reference > incorrect file locations (though I'd hope not for the most part), and > in particular dependency naming will always be a challenge. Adopting a package to distribution specifics is perfectly valid. But here it's about adding functionality to a package that wasn't there before. The usual reaction in such situations is to tell users to bug upstream about it first. > > Upstream rejection of a unit should certainly not lead to Gentoo > rejection of a unit, any more than their rejection of a script for > OpenRC should. Upstreams will likely be slow to embrace the > init-scripts-aren't-just-for-distros thing. > > Rich > If an upstream bug is filed and upstream says fuck off there is still a bug report which would meet the requirement. Maybe some other distro even filed the bug already for us.
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, 13 May 2013 00:24:09 +0200 Alexander Berntsen wrote: > On 13/05/13 00:21, Peter Stuge wrote: > > There is no problem if github is only used for hosting, but if it > > is the primary point of contact, or if pull requests are accepted, > > then github is also writing to repositories, and merge commits are > > enforced for all external contributions. That does not scale at > > all. > > Users can still send patches via email even if the project is hosted > on GitHub. And for the record I have not had problems with messy > merges when commiting pull requests. Once I was asked if I could look into a package. I spent a day writing a couple of ebuilds including fixing the build system of the target package. When I presented a first git-format-patch I was ask to do a github pull request instead. So I asked why not git-am? The answer was - don't be a *beep*. As a result the package never got fixed and I outright ignore any repo not hosted on Gentoo infra.
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, 13 May 2013 09:07:21 +0200 Alexander Berntsen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 13/05/13 08:32, Ralph Sennhauser wrote: > > Once I was asked if I could look into a package. I spent a day > > writing a couple of ebuilds including fixing the build system of > > the target package. When I presented a first git-format-patch I was > > ask to do a github pull request instead. So I asked why not git-am? > > The answer was - don't be a *beep*. As a result the package never > > got fixed and I outright ignore any repo not hosted on Gentoo > > infra. > Who was this? Don't know why it would be relevant. Also I intentionally didn't mention any names and wont do so on this list. Feel free to ask me in private if you have a good reason.
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, 28 May 2013 17:15:40 -0500 William Hubbs wrote: > On Tue, May 28, 2013 at 09:07:37PM +0200, Michał Górny wrote: > > For the others, how large is the benefit of having them switchable? > > At least some of them look like something that wouldn't hurt people > > if it was always-built. > > The dev manual states that use flags are to control optional > dependencies and _settings_ which a user may reasonably want to select > [1]. William, each time this comes up you overred the _reasonably_. Controlling dependencies is always reasonable but beyond that it's case by case. Just because you can is never a valid reason. Often there are options you clearly only want to toggle if you are a developer or options meant for porting to alternative operating systems which lack some bells and whistles and the like. Another example is configuring a library for bundling with an app. The world is bigger than linux distros. > Since the developer gives us the ability to control this with > configure switches, I feel pretty strongly that we should give the > user that control. Useless options within the given context are an usability issue and those who want to toggle stuff for it's own sake still have EXTRA_ECONF. Ralph > > William > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
On Tue, 1 Apr 2014 15:31:56 -0700 Tim Harder wrote: > Currently the java-utils-2 eclass refers to $DESTTREE in the > java-pkg_init_paths_ function that gets run during pkg_setup (via the > java-pkg-2 eclass that calls java-pkg_init). The java-pkg_init_paths_ > function also gets called again for most src_install java-utils-2 > eclass functions that use the related variables but the current > implementation doesn't allow the variables to be reset. > > This is an issue for pkg managers that try to follow the spec and > don't define DESTTREE outside of src_install. Note that DESTTREE was > recently added to pms so you'll probably have to view the live > version to see the DESTTREE related info. > > The attached patch fixes the situation by adding java-pkg_init_paths_ > calls to a couple src_install related functions that use the related > variables and removes the call to it during pkg_setup (no related > variables appear to be used before src_install but I could be missing > something). People familiar with various java pkgs should test it to > make sure those variables aren't used before src_install. > > Thoughts or comments welcome, > Tim Tim, java-utils-2 does it like that since before PMS, since around the time Portage gained support for EAPIs. PMS leaves it open whether using DESTREE in pkg_setup is allowed or not. Neither Portage, Paludis nor earlier version of Pkgcore did mind this use. Well, one could argue that using DESTREE in pkg_setup is allowed. I would welcome PMS clearly defining the scope of DESTREE and the most logical choice of course would be src_install only where it is currently explicitly required. If we fix java-utils-2 we should fix PMS as well. After all, java-utils-2 is a prime suspect for the different handling of DESTREE and for instance INSDESTREE in PMS. This asymmetry is why I didn't touch java-utils-2 when I looked into exactly this usage of DESTREE 2+ years ago. Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] Removing a blocker from a stable package
On Mon, 13 Oct 2014 14:02:55 -0400 "Anthony G. Basile" wrote: > On 10/13/14 12:58, Michael Orlitzky wrote: > > I've got two obsolete packages masked currently: app-text/unix2dos > > and app-doc/djbdns-man. Both of them block other stable packages, > > app-text/dos2unix and net-dns/djbdns respectively. > > > > Fortunately, both of them have had version/revision bumps since the > > blocker so we can remove the blocker from the newer ebuild and then > > stabilize that, at which point there's no problem. But I wonder, > > what would be the best way to handle the situation if no > > version/revision bump had occurred? > > > > In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. > > In -r29, I have, > > > >KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" > >DEPEND="!app-doc/djbdns-man" > > > > and app-doc/djbdns-man is now hard masked. Suppose I remove > > djbdns-man from the tree -- what do I do about the blocker? I see a > > couple of options: > > > >a) Edit the stable ebuild with ones fingers crossed > > > >b) Do a revbump and wait it out > > > >c) Do a revbump and file a stablereq immediately > > > >d) Do nothing, will repoman tolerate that? > > > > > > (b) is obviously safest, but (c) seems reasonable as well all things > > considered. Will the answer change when portage drops dynamic deps? > > > > You might be okay with rev bumping then then stabilizing yourself on > the arches since the package has been already tested on them. The > rev bump doesn't change any files on the system but just gets past > the blocker. I don't want to speak for all arch teams, but I would be > okay with that on the arches I take care of: arm, ppc, ppc64. In > other words, go with C and do the stablereq yourself. > The only right answer is d), carrying the block over to future versions for some time might even be appropriate.
[gentoo-dev] Last Rites of dev-java/jrockit-jdk-bin
# Ralph Sennhauser (04 Jan 2012) # Outdated Java version, fails to fetch, no upstream. #228929 # Removal in 30 days. dev-java/jrockit-jdk-bin
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 20:05:47 +0100 Michał Górny wrote: [snip] > > You should consider taking like 1 or 2 hours of your precious time to > read about the use and meaning of various directories in the > filesystem. > The FHS gives different meaning to directories than the systemd folks like it to be. Yes, it's unpleasant how far that sort of breakage already progressed. However, by definition software not adhering to the current standard is what is broken and not the other way around. There is nothing wrong with changing an old standard if there is a need, though until a new standard is approved / accepted there is no ground to change anything and breaking the current standard on purpose is plain stupid. Btw, do you happen to know what is going on with FHS-3.0 and why there are delays. Wasn't it supposed to be announced in summer 2011? Then do you happen to know a technical paper which actually discuss the advantage / disadvantages of changing the current standard. All I have read on this topic so far looks like propaganda material only or lists non arguments like "less top level directories". signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Fri, 20 Jan 2012 07:49:07 -0500 Rich Freeman wrote: > On Thu, Jan 19, 2012 at 10:33 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: > > > >> Maybe it would be enough to add a suggestion about --exclude in the > >> --newuse section of the emerge man page? I don't think this is > >> confusing enough to qualify for an interactive suggestion. > > > > However, it could be argued that the various boilerplate > > "handholding" we're already doing has set the precedent. > > I think the manpage is the right place to fix it. Users would find > out about -N from the manpage or from following -dev. Fixing it in > that place seems appropriate. Right now I think experienced users are > more likely to be using it. > > I'd still like to see our handbook include a recommended workflow for > keeping gentoo up-to-date. Perhaps that should include a few options > with the pros/cons of each. I'd think that emerge -auDNv world would > be one of those options. Perhaps another might be including build > deps. One advantage of having people running a uniform update command > that tends to keep everything up to date (even if not strictly > necessary), is that it would cut down on the diversity of our install > base. Right now a stable user could be running various versions of > various libraries based on when they first merged them and whether > they use -D, and so on. Keeping everybody moving along to newer > versions (and more freshly compiled ones) could help to cut down on > the bugs. Bugs filed with older versions still in portage would still > be legitimate, but unless somebody really needs the older version > there is no sense making more work for ourselves. > > Perhaps this is worth its own thread, as this one is already drifting > way off topic. > > Rich > I'm sure there is already such a thread on *-dev and the only sane thing would be to introduce an option along the line of "emerge --update world" which condenses all best practice options into a single one and which can change over time together with the best practices. Though this doesn't change the fact that messing with stable ebuilds is dangerous and clearly labelled a "don't do" in the dev-manual even so it is sometimes unavoidable.
[gentoo-dev] Lastrite: dev-java/sun-j2ee
# Ralph Sennhauser (28 Jan 2012) # Hopelessly outdated, contains broken jars. #91484 # Removal in 30 days. dev-java/sun-j2ee signature.asc Description: PGP signature
