[gentoo-dev] Packages from rox herd up for grabs
Due: http://gentoo.2317880.n4.nabble.com/rox-herd-looks-inactive-for-a-long-time-td257264.html This is the list: rox-base/mime-editor rox-base/oroborox rox-base/pager rox-base/rox-autostart rox-base/rox-clib rox-base/rox-launch rox-base/rox-lib rox-base/rox-media rox-base/rox-session rox-base/rox rox-base/systemtrayn rox-base/tasklist rox-base/tasktray rox-base/thumbs rox-base/traylib rox-base/volume rox-base/xdg-menu rox-base/zeroinstall-injector rox-extra/archive rox-extra/clock rox-extra/comicthumb rox-extra/contacts rox-extra/diff rox-extra/downloadmanager rox-extra/edit rox-extra/fetch rox-extra/find rox-extra/gnome-thumbnailer rox-extra/lithium rox-extra/magickthumbnail rox-extra/memo rox-extra/mp3ogg2wav rox-extra/musicbox rox-extra/picky rox-extra/resolution rox-extra/reticker rox-extra/ripper rox-extra/rox-rename rox-extra/rox-tail rox-extra/rox-wifi rox-extra/rox-xplanet rox-extra/roxcd rox-extra/roxdao rox-extra/roxget rox-extra/roxiso rox-extra/songer rox-extra/videothumbnail rox-extra/wallpaper rox-extra/weather x11-terms/roxterm signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog
On Wed, 27 Feb 2013 22:08:45 +0100 Thomas Sachau wrote: > Alexis Ballier schrieb: > > On Wed, 27 Feb 2013 18:10:30 +0100 > > hasufell wrote: > > > >> The other thing is: > >> We still have the conflict with eclass-solution vs PM-solution > >> (multilib-portage) and I propose not to convert ANYTHING else until > >> that conflict is solved, even if it means a council vote (that's > >> what I actually think makes sense here). > >> I understand both sides and somehow find it appealing to have a > >> quicker solution, but since this could damage years of work on a > >> portage fork I think we should slow down here. > > > > except there _has_ been a discussion: > > http://article.gmane.org/gmane.linux.gentoo.devel/80330 > > > > where, at least for me, it appeared that the eclass solution was the > > right way and portage-multilib had its defects that could not be > > solved without such an eclass solution. > > Long story short: portage-multilib does not handle deps needing > > multilib and deps not needing them. Only packages maintainers know > > that, you cannot guess it at the PM level. Doing unpack twice, while > > bearable, is also suboptimal. portage-multilib already disables its > > multilib support for multilib-enabled packages, thus there is not > > even a conflict there. > > So you discussed with mgorny (who does not like multilib-portage) and > not me and then assume that all details have been written in > there? :-) It is probably rather that mgorny's approach is much more transparent: He sends his ideas to the ml, ask for comments, etc. while the multilib-portage approach is not clear to anybody. "All details" are, in fact, what I understood from the list of commands and pseudo-algorithm you sent as a spec some time ago :) [...] > Anyway, in short: the current implementation does add dependencies so > that all dependencies need the same ABIs enabled as the package you > want. If we move the features into a future EAPI, we can of course > drop this and leave the dependency part to the ebuild maintainer. How do you achieve that currently? We _do_ need to leave the dependency part to the ebuild maintainer: How will you achieve that? cat/pkg[$MULTIlIB_USE_DEP] ? :) I don't think we need a future EAPI for this. If you spec it, do we need a new EAPI everytime we want to introduce a new ABI? > > On the other hand, Michal has been doing the work and got things > > done when portage-multilib has never reached mainline after several > > years of development. So, while breaking the tree like the freetype > > case is really bad, please do not use this for killing his efforts, > > esp. when it is now masked. > > If you did not know it: anyone can add an eclass, while adding new > features via package manager requires a new EAPI. > I have written about it on this list for many months, if not years. > And every time i solved a request, a new one was raised. And you want > to blaim me for multilib-portage not reaching the main tree? I don't blame multilib-portage for not reaching mainline. From what I've seen, the only needed change I've understood is changing how the ebuild phases are called. The rest is obscure and not precise enough to me, unfortunately. You always claimed that multilib-portage works on the current tree, so I do not see what eapi part you need, just change your pm to do multilib and be done, no ? > Anyway, if there is a sane and easy to use eclass created, which does > just multilib and does it properly for all multilib arches also > supporting per ABI headers and binaries, i am not opposed against it. Good. > I just see issues the way a work-in-progress is pushed into the main > tree without prior discussion and additional hacks for issues > (freetype headers) forcing other devs to do more work instead of > asking for another solution not needing any additional work for > depending packages. He sent all is changes over the ml for review. Everybody was happy, he committed them. Nothing wrong here. The freetype issue is different, and IMHO the solution is wrong there. Let me check bgo and file a bug if not. Alexis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog
On Wed, 27 Feb 2013 22:12:25 +0100 Thomas Sachau wrote: > Pacho Ramos schrieb: > > El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió: > > [...] > >>> The reason I bring this up again is that there was a strong > >>> argument yesterday in #gentoo-dev, so it seems the situation is > >>> NOT clear. > >> > >> What are these arguments ? The IRC conspiracy is hard to follow :) > >> > > > > I also read that argument... but it looked to turn more in a > > "personal" flame war than anything "technical". For example, I > > couldn't see how multilib-portage solves the issue of different > > headers provided for different arches (that looks to be the key > > problem that mgorny tried to solve in freetype) > > > > multilib-portage has no issues with abi-specific headers, since those > are installed into a seperate abi-specific location > inside /usr/include with a wrapper in the original location to not > break depending packages. yes, thats the kind of solution that should be implemented for freetype too. putting all headers under /usr/lib doesnt seem sane. There exist default locations for headers for a reason, leveraging the issue to using pkg-config seems wrong.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog
On Wed, 27 Feb 2013 20:05:58 +0100 hasufell wrote: > This is just my own view on this and NOT complete, Tommy[D] will > probably have a more complete list what the eclasses currently lack > and where they will fail. > Mgorny will have a more complete list why multilib-portage is a bad > hack. > > > PM level: > pro: > - one-blow solution, tree-wide > - _much_ less modification on ebuilds needed > - will be properly documented in the spec, something people can > rely on > - multilib-portage has years of experience on ABI issues > con: > - difficult to maintain (please count the number of people who > understand portage code) > - slower fixes > - still no merge into mainline in sight, could very well take > another few months, if at all - suboptimal (run all the src_* phases twice) - from what i've understood it does not deal with nolib packages properly: what happens for eg coreutils or texlive-latexextra ? Do we unpack, build and install them twice ? Really ? Try to install tl-latexextra on a 5400rpm laptop disk, you'll see you do not want that time to double :) - the spec will likely include specificities: e.g. setting PKG_CONFIG_PATH what happens if I want a multilib ocaml install (stupid idea btw but that's an example): the pkgconfig equivalent for ocaml is findlib. You will likely want to override OCAMLFIND_CONF for doing a multilib install. You will need to change the spec. > eclass level: > pro: > - easier to maintain (eclasses are generally easy understandable) > - quicker to fix and to extend > - solution is NOW available > con: > - more likely to break stuff as all eclass based solutions, because > there are no eclass-APIs and no spec if done correctly this should not happen, but that's true the eapi barrier is not there. > - needs much more modification on ebuilds, especially for weird > build systems the eclass you proposed implements more or less the multilib-portage solution without much changes. if you want to do it cleanly (out of source build, etc) then yes you need much more changes but also get something you cannot do from the PM side. > - not tree-wide, slow per-package migration it is a pro rather than a con for me: do we really want lib32 to be the 32bits copy of lib64? or do we want here only what actually makes sense, on a per-package and per-need basis? (see also the tl-latexextra example above) Alexis.
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
02.03.13 07:54, Ben de Groot написав(ла): > app-admin/keepassx > app-text/goldendict If these two packages need a maintainer, I could proxy-maintain them. I'm not a developer, but I have some experience with ebuild writing. Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 02/03/13 08:54, Ben de Groot wrote: The Gentoo Qt Project wants your help! sci-calculators/qalculator This project died after the first betas. I propose treecleaning it. We have plenty of more maintained calculators in tree.
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, 2 Mar 2013 14:54:22 +0800 Ben de Groot wrote: > > == We could also use a hand with: == [...] > app-text/cb2bib [...] > dev-tex/qtexengine > dev-tex/texamator you can add tex@g.o as second maintainer there if you wish
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, 2 Mar 2013 14:54:22 +0800 Ben de Groot wrote: > media-video/avidemux (bundled libs) I like this application, but am not so sure about maintaining this... =/ Would it be reasonable to create a new package avidemux-ffmpeg in which we create a version of ffmpeg with their patches applied? Perhaps we can also remove the parts of ffmpeg that aren't used by avidemux to keep the overhead of having ffmpeg twice on the system low. I don't see any other reliable solution, unless upstream is willing to stop bundling ffmpeg and get their patches incorporated on that. But upon reading the progress on Debian, there is barely any progress on that as far as I am aware of; and I'm not willing to maintain a package that has 1) an unpatched ffmpeg that breaks it for people or 2) a bundled ffmpeg that keeps it from getting unmasked / reliable / ... The other approach is for someone to attempt to try to get all these patches upstream, but some of them are undocumented which makes it hard to understand what the changes actually are done for; and at this point in time it is not guaranteed that ffmpeg would take these patches. So, what is the Qt herd's opinion on creating a avidemux-ffmpeg package? With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 02/03/13 15:08, Tom Wijsman wrote: On Sat, 2 Mar 2013 14:54:22 +0800 Ben de Groot wrote: media-video/avidemux (bundled libs) I like this application, but am not so sure about maintaining this... =/ Would it be reasonable to create a new package avidemux-ffmpeg in which we create a version of ffmpeg with their patches applied? Perhaps we can also remove the parts of ffmpeg that aren't used by avidemux to keep the overhead of having ffmpeg twice on the system low. I don't see any other reliable solution, unless upstream is willing to stop bundling ffmpeg and get their patches incorporated on that. But upon reading the progress on Debian, there is barely any progress on that as far as I am aware of; and I'm not willing to maintain a package that has 1) an unpatched ffmpeg that breaks it for people or 2) a bundled ffmpeg that keeps it from getting unmasked / reliable / ... The other approach is for someone to attempt to try to get all these patches upstream, but some of them are undocumented which makes it hard to understand what the changes actually are done for; and at this point in time it is not guaranteed that ffmpeg would take these patches. So, what is the Qt herd's opinion on creating a avidemux-ffmpeg package? The embedded FFmpeg in avidemux is only patched to convert UNIX line endings to DOS line endings to match rest of the avidemux source tree There should be a script in the repository and/or the tarball to convert orig. FFmpeg source tree to this. Even if that wasn't the case, separate package doesn't make sense, USE="+system-libs" might
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, 2 Mar 2013 14:08:28 +0100 Tom Wijsman wrote: > On Sat, 2 Mar 2013 14:54:22 +0800 > Ben de Groot wrote: > > > media-video/avidemux (bundled libs) > > I like this application, but am not so sure about maintaining this... > =/ > > Would it be reasonable to create a new package avidemux-ffmpeg in > which we create a version of ffmpeg with their patches applied? > Perhaps we can also remove the parts of ffmpeg that aren't used by > avidemux to keep the overhead of having ffmpeg twice on the system > low. > > I don't see any other reliable solution, unless upstream is willing to > stop bundling ffmpeg and get their patches incorporated on that. > But upon reading the progress on Debian, there is barely any progress > on that as far as I am aware of; and I'm not willing to maintain a > package that has 1) an unpatched ffmpeg that breaks it for people or > 2) a bundled ffmpeg that keeps it from getting unmasked / > reliable / ... > > The other approach is for someone to attempt to try to get all these > patches upstream, but some of them are undocumented which makes it > hard to understand what the changes actually are done for; and at > this point in time it is not guaranteed that ffmpeg would take these > patches. > > So, what is the Qt herd's opinion on creating a avidemux-ffmpeg > package? In the end if you dump their ffmpeg version and use it only for avidemux, the end result is the same as bundling it. If you want to do things correctly, you'd try to get the patches merged upstream. Maybe some are not even necessary these days. First you'd need to have an option to use system ffmpeg. Then you could work on porting patches. That is what xbmc is doing: they have a bundled copy with a couple of patches they try to get merged upstream (mainly windows patches btw) but allow using system version. That way it is easier to work on fixing bugs rather than trusting avidemux for adding random undocumented fixes...
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, 02 Mar 2013 15:29:38 +0200 Samuli Suominen wrote: > The embedded FFmpeg in avidemux is only patched to convert UNIX line > endings to DOS line endings to match rest of the avidemux source tree Nope, it does various patches: $ ls -1 avidemux_core/ffmpeg_package/patches common.mak.diff config.mak.diff config.mak.mac.diff createPatches.sh libavcodec_avcodec.h.patch libavcodec_ff_spsinfo.h.patch libavcodec_golomb.h.patch libavcodec_h263dec.c.patch libavcodec_h264_parser.c.patch libavcodec_libavcodec.v.patch libavcodec_mathops.h.patch libavcodec_mpeg12enc.c.patch libavcodec_mpegvideo_enc.c.patch libavcodec_put_bits.h.patch libavcodec_vdpau.h.patch libavcodec_x86_fmtconvert_init.c.patch libavformat_isom.c.patch libavformat_matroskaenc.c.patch libavformat_mpegtsenc.c.patch libavutil_avutil.h.patch libavutil_common.h.patch libavutil_lfg.c.patch libavutil_lfg.h.patch I first thought it was a binary, but now that I see it is actually compiled from source in the avidemux build process, we have control over it. Therefore, I'll step up to be the primary maintainer. Do you want me to keep the Qt herd in the metadata.xml as secondary? > Even if that wasn't the case, separate package doesn't make sense, > USE="+system-libs" might Agreed, an USE flag makes much more sense! I didn't consider this because I thought it was a binary. Sadly the system library doesn't work well with avidemux because it doesn't have any of these useful patches; but indeed, together with mantainers of this package on other distributions we should be able to push some patches upstream... Therefore, I think we should keep USE="system-libs" until avidemux is properly tested to make USE="+system-libs" appropriate. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 02/03/13 16:35, Tom Wijsman wrote: On Sat, 02 Mar 2013 15:29:38 +0200 Samuli Suominen wrote: The embedded FFmpeg in avidemux is only patched to convert UNIX line endings to DOS line endings to match rest of the avidemux source tree Nope, it does various patches: $ ls -1 avidemux_core/ffmpeg_package/patches common.mak.diff config.mak.diff config.mak.mac.diff createPatches.sh ^ That one should generate all of the others :P libavcodec_avcodec.h.patch libavcodec_ff_spsinfo.h.patch libavcodec_golomb.h.patch libavcodec_h263dec.c.patch libavcodec_h264_parser.c.patch libavcodec_libavcodec.v.patch libavcodec_mathops.h.patch libavcodec_mpeg12enc.c.patch libavcodec_mpegvideo_enc.c.patch libavcodec_put_bits.h.patch libavcodec_vdpau.h.patch libavcodec_x86_fmtconvert_init.c.patch libavformat_isom.c.patch libavformat_matroskaenc.c.patch libavformat_mpegtsenc.c.patch libavutil_avutil.h.patch libavutil_common.h.patch libavutil_lfg.c.patch libavutil_lfg.h.patch
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, 2 Mar 2013 14:32:47 +0100 Alexis Ballier wrote: > In the end if you dump their ffmpeg version and use it only for > avidemux, the end result is the same as bundling it. Yeah, I thought they bundled a binary; as it appears they just compile ffmpeg as well I can manipulate it in the avidemux package itself and don't need a separate package for that. Nevermind that suggestion. > If you want to do things correctly, you'd try to get the patches > merged upstream. Maybe some are not even necessary these days. I'll try to see what I can do... > First you'd need to have an option to use system ffmpeg. Then you > could work on porting patches. Yeah, we can work bug-based instead of patch-based; instead of trying to contribute undocumented patches upstream, we could base ourselves upon found problems and report those as bugs upstream. And only attach one of their patches if it is clear that it fixed that problem. As said in the other reply, I'll take this package and work on getting it fixed over the next days. Thank you both for your advice! With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog
On 03/02/2013 12:08 PM, Alexis Ballier wrote:
>
>> eclass level:
>> pro:
>> - easier to maintain (eclasses are generally easy understandable)
>> - quicker to fix and to extend
>> - solution is NOW available
>> con:
>> - more likely to break stuff as all eclass based solutions, because
>> there are no eclass-APIs and no spec
>
> if done correctly this should not happen, but that's true the eapi
> barrier is not there.
>
>> - needs much more modification on ebuilds, especially for weird
>> build systems
>
> the eclass you proposed implements more or less the multilib-portage
> solution without much changes. if you want to do it cleanly (out of
> source build, etc) then yes you need much more changes but also get
> something you cannot do from the PM side.
>
>> - not tree-wide, slow per-package migration
>
> it is a pro rather than a con for me: do we really want lib32 to be the
> 32bits copy of lib64? or do we want here only what actually makes
> sense, on a per-package and per-need basis? (see also the tl-latexextra
> example above)
>
IMO we should go on with eclass development. Tommy has already offered
to help with that, but would appreciate if we implement a check/switch
that will disable all multilib-eclass related magic and allowing
multilib-portage to still work tree-wide as it did before we invented
these eclasses.
I think that's a fair trade.
And at least for my eclass I already have implemented a solution,
basically doing:
if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
DISABLE_MULTILIB="ON"
fi
which will disable multilib-behavior if only the default abi is set.
Alternatively we could simply introduce DISABLE_MULTILIB as an eclass
variable which can be set by multilib-portage then.
Mgorny still has not replied to this proposition.
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On Sat, 02 Mar 2013 03:50:11 +0100 hasufell wrote: > On 02/28/2013 09:30 AM, Michał Górny wrote: > > > > Setting that variable would invalidate metadata cache. > > > > different approach attached I'm afraid you are doing too much, too fast and I simply can't follow. I don't think you should introduce workarounds in your eclass. I think multilib-build should be the place to do that. And please don't attach patches to patched version since that's too hard to follow. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-multilib-minimal
On 03/02/2013 04:07 PM, Michał Górny wrote:
> I don't think you should introduce workarounds in your eclass. I think
> multilib-build should be the place to do that.
Feel free to implement a solution. I think an explicit variable might
even be better instead of some magical checks which could cause
unexpected behavior for in-source builds or ebuilds that do a lot of
additional stuff on top of these eclasses.
So in case that solution breaks something, it would only be for
multilib-portage and they could still handle that via masking those
packages.
>
> And please don't attach patches to patched version since that's too
> hard to follow.
>
I didn't. However, here is the full version.
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald
# @BLURB: wrapper for multilib builds providing convenient multilib_src_*
functions
# @DESCRIPTION:
#
# src_configure, src_compile, src_test and src_install are exported
# use multilib_src_* instead of src_* which runs this phase for
# all enabled ABIs
# multilib-minimal should _always_ go last in inherit order!!
#
# If you are using in-source builds, then you must run multilib_copy_sources
# at the end of src_prepare!!
#
# If you need generic install rules, use multilib_src_install_all function.
# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
5) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
inherit multilib-build
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
unset DISABLE_MULTILIB
_multilib-minimal_set_globals() {
if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
DISABLE_MULTILIB="ON"
fi
}
_multilib-minimal_set_globals
multilib_copy_sources() {
_abi_copy_sources() {
einfo "${ABI}: copying to ${BUILD_DIR}"
cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
}
if [[ -z ${DISABLE_MULTILIB} ]] ; then
einfo "Will copy sources to abi-specific dirs"
multilib_foreach_abi _abi_copy_sources
fi
}
multilib-minimal_src_configure() {
_common_src_configure() {
if declare -f multilib_src_configure >/dev/null ; then
multilib_src_configure
else
default_src_configure
fi
}
_abi_src_configure() {
einfo "${ABI}: Configuring"
mkdir -p "${BUILD_DIR}" || die
pushd "${BUILD_DIR}" >/dev/null || die
_common_src_configure
popd >/dev/null || die
}
if [[ -z ${DISABLE_MULTILIB} ]] ; then
multilib_foreach_abi _abi_src_configure
else
_common_src_configure
fi
}
multilib-minimal_src_compile() {
_common_src_compile() {
if declare -f multilib_src_compile >/dev/null ; then
multilib_src_compile
else
default_src_compile
fi
}
_abi_src_compile() {
einfo "${ABI}: Compiling"
pushd "${BUILD_DIR}" >/dev/null || die
_common_src_compile
popd >/dev/null || die
}
if [[ -z ${DISABLE_MULTILIB} ]] ; then
multilib_foreach_abi _abi_src_compile
else
_common_src_compile
fi
}
multilib-minimal_src_test() {
_common_src_test() {
if declare -f multilib_src_test >/dev/null ; then
multilib_src_test
else
default_src_test
fi
}
_abi_src_test() {
einfo "${ABI}: Testing"
pushd "${BUILD_DIR}" >/dev/null || die
_common_src_test
popd >/dev/null || die
}
if [[ -z ${DISABLE_MULTILIB} ]] ; then
multilib_foreach_abi _abi_src_test
else
_common_src_test
fi
}
multilib-minimal_src_install() {
_common_src_install() {
if declare -f multilib_src_install >/dev/null ; then
multilib_src_install
else
default_src_install
fi
}
_abi_src_install() {
einfo "${ABI}: Installing"
pushd "${BUILD_DIR}" >/dev/null || die
_common_src_install
multilib_check_headers
popd >/dev/null || die
}
if [[ -z ${DISABLE_MULTILIB} ]] ; then
multilib_foreach_abi _abi_src_install
else
_common_src_install
fi
if declare -f multilib_src_install_all >/dev/null ; then
multilib_src_in
[gentoo-dev] New eclass: multilib-minimal (was New eclass: autotools-multilib-minimal)
Since mgorny is working on compatibility with multilib-portage I
stripped all of the related code.
So this should be the final version. If there are no objections I would
like to commit.
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald
# @BLURB: wrapper for multilib builds providing convenient multilib_src_*
functions
# @DESCRIPTION:
#
# src_configure, src_compile, src_test and src_install are exported
# use multilib_src_* instead of src_* which runs this phase for
# all enabled ABIs
# multilib-minimal should _always_ go last in inherit order!!
#
# If you are using in-source builds, then you must run multilib_copy_sources
# at the end of src_prepare!!
#
# If you need generic install rules, use multilib_src_install_all function.
# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
5) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
inherit multilib-build
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
multilib_copy_sources() {
multilib-minimal_abi_copy_sources() {
einfo "${ABI}: copying to ${BUILD_DIR}"
cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
}
multilib_foreach_abi multilib-minimal_abi_copy_sources
}
multilib-minimal_src_configure() {
multilib-minimal_abi_src_configure() {
mkdir -p "${BUILD_DIR}" || die
pushd "${BUILD_DIR}" >/dev/null || die
if declare -f multilib_src_configure >/dev/null ; then
multilib_src_configure
else
default_src_configure
fi
popd >/dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_configure
}
multilib-minimal_src_compile() {
multilib-minimal_abi_src_compile() {
pushd "${BUILD_DIR}" >/dev/null || die
if declare -f multilib_src_compile >/dev/null ; then
multilib_src_compile
else
default_src_compile
fi
popd >/dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_compile
}
multilib-minimal_src_test() {
multilib-minimal_abi_src_test() {
pushd "${BUILD_DIR}" >/dev/null || die
if declare -f multilib_src_test >/dev/null ; then
multilib_src_test
else
default_src_test
fi
popd >/dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_test
}
multilib-minimal_src_install() {
multilib-minimal_abi_src_install() {
pushd "${BUILD_DIR}" >/dev/null || die
if declare -f multilib_src_install >/dev/null ; then
multilib_src_install
else
default_src_install
fi
multilib_check_headers
popd >/dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_install
if declare -f multilib_src_install_all >/dev/null ; then
multilib_src_install_all
fi
}
Re: [gentoo-dev] New eclass: multilib-minimal (was New eclass: autotools-multilib-minimal)
On Sat, 02 Mar 2013 17:43:52 +0100 hasufell wrote: > Since mgorny is working on compatibility with multilib-portage I > stripped all of the related code. > > So this should be the final version. If there are no objections I would > like to commit. Please wait for the multibuild patches to be applied, then i will add multilib_copy_sources(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On 2 March 2013 22:35, Tom Wijsman wrote: > I first thought it was a binary, but now that I see it is actually > compiled from source in the avidemux build process, we have control > over it. Therefore, I'll step up to be the primary maintainer. > > Do you want me to keep the Qt herd in the metadata.xml as secondary? No, I don't think that's necessary. Keeping it in video herd makes more sense. >> Even if that wasn't the case, separate package doesn't make sense, >> USE="+system-libs" might > > Agreed, an USE flag makes much more sense! I didn't consider this > because I thought it was a binary. Sadly the system library doesn't > work well with avidemux because it doesn't have any of these useful > patches; but indeed, together with mantainers of this package on other > distributions we should be able to push some patches upstream... > > Therefore, I think we should keep USE="system-libs" until avidemux is > properly tested to make USE="+system-libs" appropriate. If avidemux keeps patching ffmpeg (beyond line-endings), I don't think it is wise to make system-libs the default. I originally took on this package when I became a Gentoo dev ~5 years ago, but I hardly use it anymore and I don't have the time to maintain this. Thanks for stepping up. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] PSA: Rsync updates (from CVS) suspended until 01:00 UTC (6 hours from now)
The QT team has requested an rsync suspension while they re-categorize their qt packages. During this window, fixes made in CVS will not be pushed to rsync users. The suspension began at ~18:37 UTC and will continue until they are done, or until ~01:00. Feel free to follow along on https://bugs.gentoo.org/show_bug.cgi?id=460026 for status. -A
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
On Sat, Mar 2, 2013 at 6:35 AM, Tom Wijsman wrote: > On Sat, 02 Mar 2013 15:29:38 +0200 > Samuli Suominen wrote: > >> The embedded FFmpeg in avidemux is only patched to convert UNIX line >> endings to DOS line endings to match rest of the avidemux source tree > > Nope, it does various patches: > > $ ls -1 avidemux_core/ffmpeg_package/patches > common.mak.diff > config.mak.diff > config.mak.mac.diff > createPatches.sh > libavcodec_avcodec.h.patch > libavcodec_ff_spsinfo.h.patch > libavcodec_golomb.h.patch > libavcodec_h263dec.c.patch > libavcodec_h264_parser.c.patch > libavcodec_libavcodec.v.patch > libavcodec_mathops.h.patch > libavcodec_mpeg12enc.c.patch > libavcodec_mpegvideo_enc.c.patch > libavcodec_put_bits.h.patch > libavcodec_vdpau.h.patch > libavcodec_x86_fmtconvert_init.c.patch > libavformat_isom.c.patch > libavformat_matroskaenc.c.patch > libavformat_mpegtsenc.c.patch > libavutil_avutil.h.patch > libavutil_common.h.patch > libavutil_lfg.c.patch > libavutil_lfg.h.patch > > I first thought it was a binary, but now that I see it is actually > compiled from source in the avidemux build process, we have control > over it. Therefore, I'll step up to be the primary maintainer. > > Do you want me to keep the Qt herd in the metadata.xml as secondary? No. video or media-video or whatever it's called makes more sense. And thanks a lot for stepping up to maintain avidemux! Best, Pesa
[gentoo-dev] Further changes to multibuild.eclass
Four more patches so far: 1) print only 'public' part of command-line That is, shift over all the arguments starting with an underscore for einfo. multibuild_foreach_variant _python_multibuild_wrapper foo will be printed as: pythonX.Y: foo 2) add a function to run the command for the 'best' (default, preferred) variant. 3) use it to implement multilib_for_best_abi(). A few ebuilds will happily use it instead of the current hacks. 4) use it to run *_all() phases in distutils-r1. This fixes bug 460016 (python_configure_all() doesn't have best-impl if there's no python_configure()).
[gentoo-dev] [PATCH 1/4] multibuild: print only 'public' part of command-line.
Shift the unnecessary 'private' commands from the printed commands when
executing.
That is:
python_parallel_foreach_impl foo
will print:
* pythonX.Y: foo
rather than:
* pythonX.Y: _multibuild_parallel _python_multibuild_wrapper ...
---
gx86/eclass/multibuild.eclass | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index 1c9058a..1cc33a9 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -118,12 +118,23 @@ multibuild_foreach_variant() {
# redirect_alloc_fd accepts files only. so we need to open
# a random file and then reuse the fd for logger process.
redirect_alloc_fd log_fd /dev/null
+
+ _multibuild_run() {
+ # find the first non-private command
+ local i=1
+ while [[ ${!i} == _* ]]; do
+ (( i += 1 ))
+ done
+
+ einfo "${v}: running ${@:${i}}"
+ "${@}"
+ }
+
# bash can't handle ${log_fd} in redirections,
# we need to use eval to pass fd numbers directly.
eval "
exec ${log_fd}> >(exec tee -a
\"\${T}/build-\${MULTIBUILD_ID}.log\")
- einfo \"\${v}: running \${@}\" >&${log_fd} 2>&1
- \"\${@}\" >&${log_fd} 2>&1
+ _multibuild_run \"\${@}\" >&${log_fd} 2>&1
lret=\${?}
exec ${log_fd}>&-
"
--
1.8.1.4
[gentoo-dev] [PATCH 3/4] multilib-build: introduce multilib_for_best_abi().
---
gx86/eclass/multilib-build.eclass | 12
1 file changed, 12 insertions(+)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index b6409d8..0fe46a0 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -139,6 +139,18 @@ multilib_parallel_foreach_abi() {
multibuild_parallel_foreach_variant _multilib_multibuild_wrapper "${@}"
}
+# @FUNCTION: multilib_for_best_abi
+# @USAGE: ...
+# @DESCRIPTION:
+# Runs the given command with setup for the 'best' (usually native) ABI.
+multilib_for_best_abi() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+
+ multibuild_for_best_variant _multilib_multibuild_wrapper "${@}"
+}
+
# @FUNCTION: multilib_check_headers
# @DESCRIPTION:
# Check whether the header files are consistent between ABIs.
--
1.8.1.4
[gentoo-dev] [PATCH 4/4] distutils-r1: reuse multibuild_for_best_variant.
---
gx86/eclass/distutils-r1.eclass | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 40dae36..ba48a35 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -549,11 +549,6 @@ distutils-r1_run_phase() {
then
popd >/dev/null || die
fi
-
- # Store them for reuse.
- _DISTUTILS_BEST_IMPL=(
- "${EPYTHON}" "${PYTHON}" "${BUILD_DIR}" "${PYTHONPATH}"
- )
}
# @FUNCTION: _distutils-r1_run_common_phase
@@ -567,23 +562,11 @@ distutils-r1_run_phase() {
_distutils-r1_run_common_phase() {
local DISTUTILS_ORIG_BUILD_DIR=${BUILD_DIR}
- local EPYTHON=${_DISTUTILS_BEST_IMPL[0]}
- local PYTHON=${_DISTUTILS_BEST_IMPL[1]}
- local BUILD_DIR=${_DISTUTILS_BEST_IMPL[2]}
- local PYTHONPATH=${_DISTUTILS_BEST_IMPL[3]}
-
- export EPYTHON PYTHON PYTHONPATH
-
- if [[ ${DISTUTILS_IN_SOURCE_BUILD} ]]; then
- pushd "${BUILD_DIR}"/.. >/dev/null || die
- fi
+ local MULTIBUILD_VARIANTS
+ _python_obtain_impls
- einfo "common: running ${1}"
- "${@}"
-
- if [[ ${DISTUTILS_IN_SOURCE_BUILD} ]]; then
- popd >/dev/null || die
- fi
+ multibuild_for_best_variant _python_multibuild_wrapper \
+ distutils-r1_run_phase "${@}"
}
# @FUNCTION: _distutils-r1_run_foreach_impl
--
1.8.1.4
[gentoo-dev] [PATCH 2/4] multibuild: add multibuild_for_best_variant().
---
gx86/eclass/multibuild.eclass | 20
1 file changed, 20 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index 1cc33a9..3ffe9e8 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -185,6 +185,26 @@ multibuild_parallel_foreach_variant() {
return ${ret}
}
+# @FUNCTION: multibuild_for_best_variant
+# @USAGE: [...]
+# @DESCRIPTION:
+# Run the passed command once, for the best of the enabled package
+# variants.
+#
+# The run will have a proper, variant-specificBUILD_DIR set, and output
+# teed to a separate log in ${T}.
+#
+# The function returns command exit status.
+multibuild_for_best_variant() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ ${MULTIBUILD_VARIANTS} ]] \
+ || die "MULTIBUILD_VARIANTS need to be set"
+
+ local MULTIBUILD_VARIANTS=( "${MULTIBUILD_VARIANTS[-1]}" )
+ multibuild_foreach_variant "${@}"
+}
+
# @FUNCTION: run_in_build_dir
# @USAGE: ...
# @DESCRIPTION:
--
1.8.1.4
Re: [gentoo-dev] [PATCH 1/4] multibuild: print only 'public' part of command-line.
On Sat, Mar 2, 2013 at 1:42 PM, Michał Górny wrote:
> Shift the unnecessary 'private' commands from the printed commands when
> executing.
>
> That is:
>
> python_parallel_foreach_impl foo
>
> will print:
>
> * pythonX.Y: foo
>
> rather than:
>
> * pythonX.Y: _multibuild_parallel _python_multibuild_wrapper ...
> ---
> gx86/eclass/multibuild.eclass | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
> index 1c9058a..1cc33a9 100644
> --- a/gx86/eclass/multibuild.eclass
> +++ b/gx86/eclass/multibuild.eclass
> @@ -118,12 +118,23 @@ multibuild_foreach_variant() {
> # redirect_alloc_fd accepts files only. so we need to open
> # a random file and then reuse the fd for logger process.
> redirect_alloc_fd log_fd /dev/null
> +
> + _multibuild_run() {
> + # find the first non-private command
> + local i=1
> + while [[ ${!i} == _* ]]; do
> + (( i += 1 ))
> + done
> +
> + einfo "${v}: running ${@:${i}}"
So this is an einfo with an assignment side-effect? Can we perhaps
make the assignment explicit?
-A
> + "${@}"
> + }
> +
> # bash can't handle ${log_fd} in redirections,
> # we need to use eval to pass fd numbers directly.
> eval "
> exec ${log_fd}> >(exec tee -a
> \"\${T}/build-\${MULTIBUILD_ID}.log\")
> - einfo \"\${v}: running \${@}\" >&${log_fd} 2>&1
> - \"\${@}\" >&${log_fd} 2>&1
> + _multibuild_run \"\${@}\" >&${log_fd} 2>&1
> lret=\${?}
> exec ${log_fd}>&-
> "
> --
> 1.8.1.4
>
>
[gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs
Hello, With the introduction of support for x32 ABI it has become necessary to enhance the multilib-build eclass with some kind of support for specifying the supported/unsupported ABIs. In this particular context, tetromino has noted that many packages don't support the x32 ABI. From the ones currently using the eclass, the one is app-emulation/wine. I would like to enhance the eclass with the ability to specify supported and unsupported ABIs. For that reason, I'd like to gather your opinion on what would be the best solution. Preferably, I'd see one that could work both for the eclass and multilib-portage so that we wouldn't need to duplicate the same information. 1) opt-in or opt-out? So far, the multilib-capable packages did get support for all multilib ABIs on given architecture enabled (assuming that the package is keyworded for the arch). As a next step from that, I think an opt-out solution be the simplest and most consistent one. In this particular context: MULTILIB_RESTRICT_ABIS=( ... ) which would be an optional variable disabling support for problematic ABIs in the packages which need it. An alternative solution would be an opt-in like in python-r1: MULTILIB_COMPAT=( ... ) but so far, that would mean that all current packages will have to be updated to list the currently supported ABIs. And it all sucks a bit due to the gray zone between amd64/x86 keyword and ABIs. And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of opt-in and opt-out which is just awful. 2) USE flag names or ABI names? Next thing to decide would be: whether the restrict should specify USE flag names (like the eclass solution) or ABI names (like portage-multilib and profiles). The advantage of USE flags is that they are guaranteed to be unique and clear. As in, two arches won't ever have the same USE flag for ABI with the same name. MULTILIB_RESTRICT_ABIS=( abi_x86_x32 ) The advantage of ABI names is that multilib-portage is aware of them. So, it's mostly about supporting a poor choice done without consulting other developers. MULTILIB_RESTRICT_ABIS=( x32 ) The problem with that is that a new arch can define an ABI with exactly the same name (since all ABI variables are profile-local). In that case, the restriction will unexpectedly apply to that arch. By the way, maybe we should move the flag -> ABI mapping from the eclass to some global location in profiles? That would make it possible to use the global flags from multilib-portage as well. What are your thoughts? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] multibuild: print only 'public' part of command-line.
On Sat, 2 Mar 2013 14:52:25 -0800
Alec Warner wrote:
> On Sat, Mar 2, 2013 at 1:42 PM, Michał Górny wrote:
> > Shift the unnecessary 'private' commands from the printed commands when
> > executing.
> >
> > That is:
> >
> > python_parallel_foreach_impl foo
> >
> > will print:
> >
> > * pythonX.Y: foo
> >
> > rather than:
> >
> > * pythonX.Y: _multibuild_parallel _python_multibuild_wrapper ...
> > ---
> > gx86/eclass/multibuild.eclass | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
> > index 1c9058a..1cc33a9 100644
> > --- a/gx86/eclass/multibuild.eclass
> > +++ b/gx86/eclass/multibuild.eclass
> > @@ -118,12 +118,23 @@ multibuild_foreach_variant() {
> > # redirect_alloc_fd accepts files only. so we need to open
> > # a random file and then reuse the fd for logger process.
> > redirect_alloc_fd log_fd /dev/null
> > +
> > + _multibuild_run() {
> > + # find the first non-private command
> > + local i=1
> > + while [[ ${!i} == _* ]]; do
> > + (( i += 1 ))
> > + done
> > +
> > + einfo "${v}: running ${@:${i}}"
>
> So this is an einfo with an assignment side-effect? Can we perhaps
> make the assignment explicit?
Assignment side-effect? I don't understand.
Maybe I'm missing something but by design it was supposed to print ${@}
starting from ${i}-th item.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 8/8] fftw: example use of multibuild in ebuild.
+1, feel free to commit, when multibuild.eclass was added.
2013/2/27 Michał Górny :
> Just a quick, dirty example. Not even tested thoroughly ;).
> ---
> gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild | 38
> +
> 1 file changed, 15 insertions(+), 23 deletions(-)
>
> diff --git a/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> b/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> index 18554f0..ddca8e4 100644
> --- a/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> +++ b/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
> @@ -7,7 +7,7 @@ EAPI=5
> #AUTOTOOLS_AUTORECONF=1
> FORTRAN_NEEDED=fortran
>
> -inherit autotools-multilib eutils flag-o-matic fortran-2 toolchain-funcs
> versionator
> +inherit autotools-multilib eutils flag-o-matic fortran-2 multibuild
> toolchain-funcs versionator
>
> DESCRIPTION="Fast C library for the Discrete Fourier Transform"
> HOMEPAGE="http://www.fftw.org/";
> @@ -24,6 +24,8 @@ DEPEND="${RDEPEND}
> test? ( dev-lang/perl )"
>
> pkg_setup() {
> + # XXX: this looks like it should be used with BUILD_TYPE!=binary
> +
> if use openmp; then
> if [[ $(tc-getCC) == *gcc ]] && ! tc-has-openmp; then
> ewarn "OpenMP is not available in your current
> selected gcc"
> @@ -32,13 +34,13 @@ pkg_setup() {
> FORTRAN_NEED_OPENMP=1
> fi
> fortran-2_pkg_setup
> - FFTW_DIRS="single double longdouble"
> + MULTIBUILD_VARIANTS=( single double longdouble )
> if use quad; then
> if [[ $(tc-getCC) == *gcc ]] && ! version_is_at_least 4.6
> $(gcc-version); then
> ewarn "quad precision only available for gcc >= 4.6"
> die "need quad precision capable gcc"
> fi
> - FFTW_DIRS+=" quad"
> + MULTIBUILD_VARIANTS+=( quad )
> fi
> }
>
> @@ -57,7 +59,9 @@ src_configure() {
> # filter -Os according to docs
> replace-flags -Os -O2
>
> - for x in ${FFTW_DIRS}; do
> + my_configure() {
> + local x=${MULTIBUILD_VARIANT}
> +
> myeconfargs=(
> $(use_enable fma)
> $(use_enable fortran)
> @@ -93,42 +97,30 @@ src_configure() {
> die "${x} precision not implemented in this ebuild"
> fi
>
> - einfo "Configuring for ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_configure
> - done
> + autotools-multilib_src_configure
> + }
> +
> + multibuild_foreach my_configure
> }
>
> src_compile() {
> - for x in ${FFTW_DIRS}; do
> - einfo "Compiling for ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_compile
> - done
> + multibuild_foreach autotools-multilib_src_compile
> }
>
> src_test () {
> - do_smalltest() { cd "${BUILD_DIR}" && emake -C tests smallcheck; }
> # We want this to be a reasonably quick test, but that is still
> hard...
> ewarn "This test series will take 30 minutes on a modern 2.5Ghz
> machine"
> # Do not increase the number of threads, it will not help your
> performance
> #local testbase="perl check.pl --nthreads=1 --estimate"
> # ${testbase} -${p}d || die "Failure: $n"
> - for x in ${FFTW_DIRS}; do
> - einfo "Testing ${x} precision"
> - BUILD_DIR="${S}-${x}" \
> - multilib_foreach_abi do_smalltest
> - done
> + multibuild_foreach autotools-multilib_src_compile -C tests smallcheck
> }
>
> src_install () {
> local u x
> DOCS=( AUTHORS ChangeLog NEWS README TODO COPYRIGHT CONVENTIONS )
> HTML_DOCS=( doc/html/ )
> - for x in ${FFTW_DIRS}; do
> - BUILD_DIR="${S}-${x}" \
> - autotools-multilib_src_install
> - done
> + multibuild_foreach autotools-multilib_src_install
>
> if use doc; then
> dodoc doc/*.pdf
> --
> 1.8.1.4
>
>
--
Christoph Junghans
http://dev.gentoo.org/~ottxor/
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/busybox: busybox-1.21.0.ebuild busybox-9999.ebuild ChangeLog
On Wednesday 27 February 2013 05:01:08 Markos Chandras wrote:
> On 27 February 2013 05:44, Mike Frysinger wrote:
> > vapier 13/02/27 05:44:01
> >
> > # patches go here!
> > epatch "${FILESDIR}"/${PN}-1.19.0-bb.patch
> >
> > - epatch "${FILESDIR}"/${P}-*.patch
> > + #epatch "${FILESDIR}"/${P}-*.patch
> >
> > cp "${FILESDIR}"/ginit.c init/ || die
>
> Was this expected? Because it seems you omit the
> busybox-1.21.0-mdev.patch patch right now.
fixed
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Friday 01 March 2013 07:45:28 Markos Chandras wrote: > On 1 March 2013 08:16, Mike Frysinger (vapier) wrote: > > vapier 13/03/01 08:16:02 > > > > Modified: confuse-2.7.ebuild ChangeLog > > Log: > > Add arm lovin. > > > > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 > > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 > > > > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd > > ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos > > ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc > > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > ~ppc-macos ~x86-macos ~x86-solaris" > > straight to stable? Not even keeping it to testing just for a week or so? looks that way -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mar 3, 2013 1:43 AM, "Mike Frysinger" wrote: > > On Friday 01 March 2013 07:45:28 Markos Chandras wrote: > > On 1 March 2013 08:16, Mike Frysinger (vapier) wrote: > > > vapier 13/03/01 08:16:02 > > > > > > Modified: confuse-2.7.ebuild ChangeLog > > > Log: > > > Add arm lovin. > > > > > > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 > > > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 > > > > > > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd > > > ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos > > > ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc > > > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > > ~ppc-macos ~x86-macos ~x86-solaris" > > > > straight to stable? Not even keeping it to testing just for a week or so? > > looks that way > -mike Ok good to know you break the rules on purpose
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Saturday 02 March 2013 20:50:17 Markos Chandras wrote: > On Mar 3, 2013 1:43 AM, "Mike Frysinger" wrote: > > On Friday 01 March 2013 07:45:28 Markos Chandras wrote: > > > On 1 March 2013 08:16, Mike Frysinger wrote: > > > > vapier 13/03/01 08:16:02 > > > > > > > > Modified: confuse-2.7.ebuild ChangeLog > > > > Log: > > > > Add arm lovin. > > > > > > > > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 > > > > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 > > > > > > > > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 > > > > ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > > > ~ppc-macos ~x86-macos ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa > > > > ia64 ~mips ppc ppc64 sparc > > > > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > > > ~ppc-macos ~x86-macos ~x86-solaris" > > > > > > straight to stable? Not even keeping it to testing just for a week or > > so? > > > > looks that way > > Ok good to know you break the rules on purpose complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mar 3, 2013 1:55 AM, "Mike Frysinger" wrote: > > On Saturday 02 March 2013 20:50:17 Markos Chandras wrote: > > On Mar 3, 2013 1:43 AM, "Mike Frysinger" wrote: > > > On Friday 01 March 2013 07:45:28 Markos Chandras wrote: > > > > On 1 March 2013 08:16, Mike Frysinger wrote: > > > > > vapier 13/03/01 08:16:02 > > > > > > > > > > Modified: confuse-2.7.ebuild ChangeLog > > > > > Log: > > > > > Add arm lovin. > > > > > > > > > > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 > > > > > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 > > > > > > > > > > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 > > > > > ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > > > > ~ppc-macos ~x86-macos ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa > > > > > ia64 ~mips ppc ppc64 sparc > > > > > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux > > > > > ~ppc-macos ~x86-macos ~x86-solaris" > > > > > > > > straight to stable? Not even keeping it to testing just for a week or > > > so? > > > > > > looks that way > > > > Ok good to know you break the rules on purpose > > complain to me when all these arm systems that totally had confuse already > installed go down in fire. it literally makes 0 difference here. > -mike Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Markos Chandras wrote: > it just feels strange I hear they call it "getting stuff done".. //Peter
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Saturday 02 March 2013 21:01:39 Markos Chandras wrote: > On Mar 3, 2013 1:55 AM, "Mike Frysinger" wrote: > > complain to me when all these arm systems that totally had confuse > > already installed go down in fire. it literally makes 0 difference > > here. > > Why would they have it installed (in stable) if it had no keywords? and if > it is such an important package why it didn't have testing keywords in the > first place? I did't say it broke something, it just feels strange and this > is why I asked sounds like there's no further clarification necessary -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: GCC 4.7 unmasking
On Sun, 24 Feb 2013 23:03:01 -0600 Ryan Hill wrote: > I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs > blocking the 4.7 tracker, so if any are yours now would be a good time > to take a look at them. > > https://bugs.gentoo.org/390247 4.7 is now unmasked. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On 02/03/13 18:02, Doug Goldstein (cardoe) wrote:
cardoe 13/03/02 16:02:57
Modified: nvidia-drivers-313.18.ebuild ChangeLog
Log:
Revert non-maintainer changes per bug #447566.
(Portage version: 2.1.11.52/cvs/Linux x86_64, signed Manifest commit with
key D7DFA8D318FA9AEF!)
Revision ChangesPath
1.6 x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?r1=1.5&r2=1.6
Index: nvidia-drivers-313.18.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- nvidia-drivers-313.18.ebuild2 Mar 2013 11:30:39 - 1.5
+++ nvidia-drivers-313.18.ebuild2 Mar 2013 16:02:57 - 1.6
@@ -1,6 +1,6 @@
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
1.5 2013/03/02 11:30:39 ssuominen Exp $
+# $Header:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
1.6 2013/03/02 16:02:57 cardoe Exp $
EAPI=5
@@ -156,9 +156,6 @@
epatch "${FILESDIR}"/nvidia-drivers-pax-usercopy.patch
fi
- epatch "${FILESDIR}"/${PN}-313.18-builddir-config.patch
- epatch "${FILESDIR}"/${PN}-313.18-linux-3.{7,8}+.patch #447566
-
# Allow user patches so they can support RC kernels and whatever else
epatch_user
}
1.427x11-drivers/nvidia-drivers/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?r1=1.426&r2=1.427
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
retrieving revision 1.426
retrieving revision 1.427
diff -u -r1.426 -r1.427
--- ChangeLog 2 Mar 2013 11:30:39 - 1.426
+++ ChangeLog 2 Mar 2013 16:02:57 - 1.427
@@ -1,6 +1,12 @@
# ChangeLog for x11-drivers/nvidia-drivers
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
1.426 2013/03/02 11:30:39 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
1.427 2013/03/02 16:02:57 cardoe Exp $
+
+ 02 Mar 2013; Doug Goldstein
+ -files/nvidia-drivers-313.18-builddir-config.patch,
+ -files/nvidia-drivers-313.18-linux-3.7+.patch,
+ -files/nvidia-drivers-313.18-linux-3.8+.patch, nvidia-drivers-313.18.ebuild:
+ Revert non-maintainer changes per bug #447566.
02 Mar 2013; Samuli Suominen
nvidia-drivers-313.18.ebuild, +files/nvidia-drivers-313.18-linux-3.8+.patch:
There was no reason for this commit and for reverting you have to
justify your commit in technical terms.
I'll wait for your reply before restoring the patches in the ebuild.
- Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On Sat, Mar 2, 2013 at 11:01 PM, Samuli Suominen wrote:
> On 02/03/13 18:02, Doug Goldstein (cardoe) wrote:
>>
>> cardoe 13/03/02 16:02:57
>>
>>Modified: nvidia-drivers-313.18.ebuild ChangeLog
>>Log:
>>Revert non-maintainer changes per bug #447566.
>>
>>(Portage version: 2.1.11.52/cvs/Linux x86_64, signed Manifest commit
>> with key D7DFA8D318FA9AEF!)
>>
>> Revision ChangesPath
>> 1.6
>> x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild
>>
>> file :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&view=markup
>> plain:
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&content-type=text/plain
>> diff :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?r1=1.5&r2=1.6
>>
>> Index: nvidia-drivers-313.18.ebuild
>> ===
>> RCS file:
>> /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
>> retrieving revision 1.5
>> retrieving revision 1.6
>> diff -u -r1.5 -r1.6
>> --- nvidia-drivers-313.18.ebuild2 Mar 2013 11:30:39 -
>> 1.5
>> +++ nvidia-drivers-313.18.ebuild2 Mar 2013 16:02:57 -
>> 1.6
>> @@ -1,6 +1,6 @@
>> # Copyright 1999-2013 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> -# $Header:
>> /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
>> 1.5 2013/03/02 11:30:39 ssuominen Exp $
>> +# $Header:
>> /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
>> 1.6 2013/03/02 16:02:57 cardoe Exp $
>>
>> EAPI=5
>>
>> @@ -156,9 +156,6 @@
>> epatch "${FILESDIR}"/nvidia-drivers-pax-usercopy.patch
>> fi
>>
>> - epatch "${FILESDIR}"/${PN}-313.18-builddir-config.patch
>> - epatch "${FILESDIR}"/${PN}-313.18-linux-3.{7,8}+.patch #447566
>> -
>> # Allow user patches so they can support RC kernels and whatever
>> else
>> epatch_user
>> }
>>
>>
>>
>> 1.427x11-drivers/nvidia-drivers/ChangeLog
>>
>> file :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&view=markup
>> plain:
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&content-type=text/plain
>> diff :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?r1=1.426&r2=1.427
>>
>> Index: ChangeLog
>> ===
>> RCS file: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
>> retrieving revision 1.426
>> retrieving revision 1.427
>> diff -u -r1.426 -r1.427
>> --- ChangeLog 2 Mar 2013 11:30:39 - 1.426
>> +++ ChangeLog 2 Mar 2013 16:02:57 - 1.427
>> @@ -1,6 +1,12 @@
>> # ChangeLog for x11-drivers/nvidia-drivers
>> # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
>> -# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
>> 1.426 2013/03/02 11:30:39 ssuominen Exp $
>> +# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
>> 1.427 2013/03/02 16:02:57 cardoe Exp $
>> +
>> + 02 Mar 2013; Doug Goldstein
>> + -files/nvidia-drivers-313.18-builddir-config.patch,
>> + -files/nvidia-drivers-313.18-linux-3.7+.patch,
>> + -files/nvidia-drivers-313.18-linux-3.8+.patch,
>> nvidia-drivers-313.18.ebuild:
>> + Revert non-maintainer changes per bug #447566.
>>
>> 02 Mar 2013; Samuli Suominen
>> nvidia-drivers-313.18.ebuild,
>> +files/nvidia-drivers-313.18-linux-3.8+.patch:
>
>
> There was no reason for this commit and for reverting you have to justify
> your commit in technical terms.
>
> I'll wait for your reply before restoring the patches in the ebuild.
There was a big ole' chat on #gentoo-dev regarding this. My
understanding of the summary is that the nvidia-driver Gentoo team
only supports kernels that nvidia themselves (upstream) support. The
Kernels > 3.4 are not supported by upstream, so they are also not
supported in Gentoo. I believe the ebuild contains instructions on
using user_patches to get these patches. The nvidia maintainers in
Gentoo do not want to be responsible for those patches though; this is
why they are not included (and why your commit was reverted.)
I do not find their stance wholly unreasonable. They offered to point
users at an overlay, if someone was willing to maintain the patches
there (in lieu of user_patches.) The end result is that if users apply
the patches, they will get an unsupported setup. There is a fear as
well, that the patches may damage cards (since the patches are not
supported by the vendor.)
-A
>
> - Samuli
>
>
[gentoo-dev] Re: PSA: Rsync updates (from CVS) suspended until 01:00 UTC (6 hours from now)
On Sat, Mar 2, 2013 at 10:53 AM, Alec Warner wrote: > The QT team has requested an rsync suspension while they re-categorize > their qt packages. During this window, fixes made in CVS will not be > pushed to rsync users. The suspension began at ~18:37 UTC and will > continue until they are done, or until ~01:00. Feel free to follow > along on https://bugs.gentoo.org/show_bug.cgi?id=460026 for status. Rsync resumed at 02:06 UTC. -A > > -A
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On 03/03/13 09:11, Alec Warner wrote:
On Sat, Mar 2, 2013 at 11:01 PM, Samuli Suominen wrote:
On 02/03/13 18:02, Doug Goldstein (cardoe) wrote:
cardoe 13/03/02 16:02:57
Modified: nvidia-drivers-313.18.ebuild ChangeLog
Log:
Revert non-maintainer changes per bug #447566.
(Portage version: 2.1.11.52/cvs/Linux x86_64, signed Manifest commit
with key D7DFA8D318FA9AEF!)
Revision ChangesPath
1.6
x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?r1=1.5&r2=1.6
Index: nvidia-drivers-313.18.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- nvidia-drivers-313.18.ebuild2 Mar 2013 11:30:39 -
1.5
+++ nvidia-drivers-313.18.ebuild2 Mar 2013 16:02:57 -
1.6
@@ -1,6 +1,6 @@
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
1.5 2013/03/02 11:30:39 ssuominen Exp $
+# $Header:
/var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
1.6 2013/03/02 16:02:57 cardoe Exp $
EAPI=5
@@ -156,9 +156,6 @@
epatch "${FILESDIR}"/nvidia-drivers-pax-usercopy.patch
fi
- epatch "${FILESDIR}"/${PN}-313.18-builddir-config.patch
- epatch "${FILESDIR}"/${PN}-313.18-linux-3.{7,8}+.patch #447566
-
# Allow user patches so they can support RC kernels and whatever
else
epatch_user
}
1.427x11-drivers/nvidia-drivers/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?r1=1.426&r2=1.427
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
retrieving revision 1.426
retrieving revision 1.427
diff -u -r1.426 -r1.427
--- ChangeLog 2 Mar 2013 11:30:39 - 1.426
+++ ChangeLog 2 Mar 2013 16:02:57 - 1.427
@@ -1,6 +1,12 @@
# ChangeLog for x11-drivers/nvidia-drivers
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
1.426 2013/03/02 11:30:39 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
1.427 2013/03/02 16:02:57 cardoe Exp $
+
+ 02 Mar 2013; Doug Goldstein
+ -files/nvidia-drivers-313.18-builddir-config.patch,
+ -files/nvidia-drivers-313.18-linux-3.7+.patch,
+ -files/nvidia-drivers-313.18-linux-3.8+.patch,
nvidia-drivers-313.18.ebuild:
+ Revert non-maintainer changes per bug #447566.
02 Mar 2013; Samuli Suominen
nvidia-drivers-313.18.ebuild,
+files/nvidia-drivers-313.18-linux-3.8+.patch:
There was no reason for this commit and for reverting you have to justify
your commit in technical terms.
I'll wait for your reply before restoring the patches in the ebuild.
There was a big ole' chat on #gentoo-dev regarding this. My
understanding of the summary is that the nvidia-driver Gentoo team
only supports kernels that nvidia themselves (upstream) support. The
Kernels > 3.4 are not supported by upstream, so they are also not
supported in Gentoo. I believe the ebuild contains instructions on
using user_patches to get these patches. The nvidia maintainers in
Gentoo do not want to be responsible for those patches though; this is
why they are not included (and why your commit was reverted.)
I do not find their stance wholly unreasonable. They offered to point
users at an overlay, if someone was willing to maintain the patches
there (in lieu of user_patches.) The end result is that if users apply
the patches, they will get an unsupported setup. There is a fear as
well, that the patches may damage cards (since the patches are not
supported by the vendor.)
We have discussed this before,
21 Mar 2012; Samuli Suominen
nvidia-drivers-295.20-r1.ebuild:
Fix building with Linux 3.3.x wrt #408841
and agreed when the change is only trivial, like adding -I flag for
missing include, a change that doesn't change API/ABI, it's fine to add
to the ebuild
Apparently Cardoe doesn't remember this discussion. I do
