Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Fri, 29 Jun 2012 14:07:58 +1200 Kent Fredric wrote: > On 27 June 2012 19:51, Federico "fox" Scrinzi wrote: > > The main question is: what would you like to have on this dashboard? > > Currently (in the development version) there's the possibility to > > login and watch/unwatch packages/categories/herds/... and see the > > watched stuff in the account dashboard. We're planning on > > implementing a weekly(?) custom newsletter based on the packages > > you're watching, which features would you like? > > > > The project repo for the GSoC is here: > > https://github.com/volpino/euscan > > > > Thanks! > > > > For the most part it seems to get upstream / portage versioning right, > but occasionally you get miss-matches for some reason. > > It would be nice to allow to provide some mapping mechanism that > existed on the overlay itself to inform euscan how to map upstream > versions to downstream ones, but implementing that would be far too > complex I feel. > > Instead, it would be nice to have a mechanism in the interface to set > a "Upstream version is" value for each package if euscan can't tell. > > Ie: > > http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ > > Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these > are in fact the same version. So in 0.710.0 , it would be nice to be > able to set the upstream version manually to 0.71 so that euscan no > longer reported it as outdated. I think we could actually handle perl pretty easily. I believe euscan will start using CPAN API to check the package versions, and we can embed the normalization there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger wrote: > On Monday 25 June 2012 00:15:59 Mike Gilbert wrote: >> An official release of grub-2.00 should be coming pretty soon. I would >> like to keyword this for ~amd64 and ~x86 shortly after it hits the tree. >> I don't do much work on base system packages, so I would like some >> advice on how to make this as smooth as possible. >> >> My main concern is that many people probably have sys-boot/grub in >> @world. If grub:2 is made visible, portage will install it, and will >> remove grub-0.97 on the next depclean. This could be a little confusing, >> but should not cause any immediate damage since the copy of grub-0.97 >> installed in the MBR and /boot would remain intact. >> >> Is this worthy of a news item? Or I just blog about it? >> >> Anything else I need to think about here? > > do we have automatic migration/updating in place like with grub1 ? that was > the biggest reason i didn't unleash it for automatic installing on people's > systems. > -mike No, the grub2 ebuild does not automatically install the files in /boot. grub2-install performs this step, and must be run by the user. It also installs the MBR and embeds the core image in unused disk sectors. This way the MBR/core image is always kept in sync with the files in /boot/grub2. I don't really see a way to reliably call grub2-install from the ebuild, and I think this would be a bit unfriendly to the user anyway.
[gentoo-dev] Re: grub:2 keywords
Mike Frysinger posted on Fri, 29 Jun 2012 01:12:38 -0400 as excerpted: > On Tuesday 26 June 2012 00:04:35 Duncan wrote: >> I could have sworn there was a virtual/bootloader or some such, that >> was a part of @system and that thus would have likely had a default in >> the profiles packages file, but either there was but it's long gone, or >> I'm mis-remembering entirely. > > long gone when we threw out old style virtuals -mike Thanks. I'm /not/ going senile and "remembering" things that were never there, then! Relief! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 19 June 2012 23:59:02 Mike Gilbert wrote:
> On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger wrote:
> > On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
> >> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
> >> > i've noticed a growing trend where people put setup of variables into
> >> > pkg_setup that only matter to src_* funcs presumably so they don't
> >> > have to call the respective src_* func from an inherited eclass.
> >> > unfortunately this adds pointless overhead to binpkgs. can we please
> >> > move away from this practice ?
> >>
> >> Like this?
> >
> > not quite
> >
> >> * ERROR: cat/pkg-version failed (prepare phase):
> >> * python_set_active_version() can be used only in pkg_setup() phase
> >> *
> >> * Call stack:
> >> * ebuild.sh, line 85: Called src_prepare
> >> * environment, line 5885: Called python_set_active_version '2'
> >> * environment, line 5603: Called die
> >> * The specific snippet of code:
> >> * die "${FUNCNAME}() can be used only in pkg_setup() phase";
> >> *
> >>
> >> Shouldn't that be in src_prepare already, or does python.eclass do
> >> something rather important here while installing a binpkg?
> >
> > Gentoo's python integration is an ugly beast. in this case, i believe
> > it's screwing with your $ROOT which means it has to be in pkg_* (let's
> > quietly ignore what happens if you try to emerge two ebuilds which need
> > conflicting versions of python active).
>
> python_set_active_version basically just sets the EPYTHON and
> PYTHON_ABI variables; nothing in ${ROOT} is modified.
good to know
> The variables are used in python_pkg_setup to implement use-flag
> checks for PYTHON_USE_WITH, and also in python_mod_optimize which is
> called in pkg_postinst.
thx for the details
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 19 June 2012 23:27:06 Samuli Suominen wrote: > On 06/20/2012 06:19 AM, Mike Frysinger wrote: > > On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: > >> On 06/15/2012 06:10 PM, Mike Frysinger wrote: > >>> On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: > On 06/13/2012 06:02 AM, Mike Frysinger wrote: > > i've noticed a growing trend where people put setup of variables into > > pkg_setup that only matter to src_* funcs presumably so they don't > > have to call the respective src_* func from an inherited eclass. > > unfortunately this adds pointless overhead to binpkgs. can we please > > move away from this practice ? > > Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, > DOCS for src_install, PATCHES for src_prepare > >>> > >>> these are static variables, so defining them in a func is pointless > >> > >> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used > >> before, not sure if it's used in tree right now or not > > > > as we've always said, USE conditional patches are to be highly > > discouraged > > I agree BUT there are cases where it's OK to use conditional patching: > > For example, libfoo-0.1.1 is broken and is fixed in git for master which > will be in next release. The fix doesn't apply to 0.1.1 cleanly without > heavy modifications. > Then you would take the easiest possible route to get 0.1.1 working > again, with the comfort of knowing it's properly fixed for the next > version. hypothetical situations are great and all, but how many of those apply to the ebuilds you're worried about ? i'd wager most do not. can we please fix the majority here ? i'd be significantly less grumpy if we treated this as the exception instead of the rule. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: euscan GSoC project - requesting feedback
Kent Fredric posted on Fri, 29 Jun 2012 14:07:58 +1200 as excerpted: > For the most part it seems to get upstream / portage versioning right, > but occasionally you get miss-matches for some reason. > > It would be nice to allow to provide some mapping mechanism that existed > on the overlay itself to inform euscan how to map upstream versions to > downstream ones, but implementing that would be far too complex I feel. > > Instead, it would be nice to have a mechanism in the interface to set a > "Upstream version is" value for each package if euscan can't tell. > > Ie: > > http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ > > Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these are > in fact the same version. So in 0.710.0 , it would be nice to be able to > set the upstream version manually to 0.71 so that euscan no longer > reported it as outdated. What about a simple variable that can be set in the ebuild? Say for the above example something like: EUSCAN_VERSION=0.71 I don't know how difficult that would be for euscan to pickup on, but since this would have no bearing on actual package behavior, only on euscan, I'd guess it shouldn't require going thru the formal PMS process, tho specifying it well enough to know whether it can be a function or must be a straight variable assignment, etc, as well as whether quotes are required or not, would be useful, and that's normally part of the PMS process so at least getting input from them would be useful. Alternatively, define some formula that can be placed in the package's metadata.xml. That's perhaps a better functionality match (we're talking about metadata, after all), but getting a formula that can deal with all the corner-cases is likely to be more difficult (and take longer) than simply specifying a variable to be defined for each ebuild that euscan can't immediately get correct. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] My wishlist for EAPI 5
On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote: > In case you're not aware, the first time Gentoo did multilib, it was > done as a series of random changes to Portage that no-one really > thought through or understood. As you can see, that didn't work... yes yes, it's very easy to throw rocks in hindsight at developers who, quite literally, were in completely new waters. not just in the Gentoo/PMS world, but in multilib *anywhere* (other distros, upstream packages, etc...). i'd say it's almost as easy as shooting fish in a barrel, but mythbusters proved that's actually kind of hard. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Thursday 21 June 2012 08:11:27 Homer Parker wrote: > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote: > > In case you're not aware, the first time Gentoo did multilib, it was > > done as a series of random changes to Portage that no-one really > > thought through or understood. As you can see, that didn't work... > > No, but paved the way for other distros as they had nothing even close. > I'm sure you remember back then. Don't be an ass. many distros still don't. ever try Debian on ppc64 ? :) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Wednesday 20 June 2012 16:25:30 Richard Yao wrote: > Multilib (and/or multiarch) support Thomas already has multilib documents put together for review. multiarch doesn't make sense for us, and even if it did, there's no way it'd be spec-ed out in a reasonable time frame for EAPI=5 (or even 6 or 7 or ...). > The current binaries cause a great deal of pain, particularly when a > user does not want to upgrade something. I had this problem with WINE > and glibc because I wanted to avoid the reverse memcpy() fiasco on my > systems. This situation would have been avoided entirely if the package > manager supported multilib. i don't buy this argument and makes me think when you say "multilib", you don't actually mean "multilib". > Automated epatch_user support > Users should be able to test patches without modifying their ebuilds. > This also saves developer time because we don't need to navigate the > portage tree (or an overlay), make a change and test it. We could just > dump the patch in the appropriate directory and build. putting forth an idea is one thing. working out the technical aspects is different. this sounds like something destined for EAPI=6: currently, epatch_user uses epatch, and that provides a lot of dynamic patch support that doesn't fit well with being spec-ed out / encoded in PMS. > Parallel make checks SGTM > POSIX Shell compliance > There has been a great deal of work done to give the user full control > of what is on his system and there is more that we can do there. In > particular, I think a lean Gentoo Linux system should be able to use > busybox sh and nothing else. That requires POSIX shell compliance. > OpenRC init scripts support this and the configure scripts support this. > The few exceptions are bugs that are addressed by the Gentoo BSD > developers. As such, I think we should make EAPI=5 use POSIX shell by > default. If an ebuild requires bash, we can allow the ebuild to declare > that (e.g. WANT_SH=bash), but that should be the exception and not the > rule. not a chance, and your logic about "choice" really makes no sense in the ebuild context. read the archives wrt Roy Maples (sadly) burning out for in- depth details as to why this is a no-go. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] My wishlist for EAPI 5
On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote: > On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote: > > Multilib (and/or multiarch) support > > Sorry for a possibly ignorant question. Does multilib support include > the ability to build Busybox against uclibc (on a glibc system)? i'm not sure Richard knows exactly what he is asking for. multilib does not cover different C libraries, but multiarch does. the former is what Thomas has been working on (multilib portage) while the later is basically cross- compiling (use crossdev) and is unrealistic for EAPI=5 integration (and i might even say isn't really a problem anymore that needs "solving"). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Patch: Linguas USE support for cmake-utils.eclass
On Sunday 24 June 2012 04:18:07 Ben de Groot wrote:
> On 24 June 2012 02:32, Mike Frysinger wrote:
> > On Saturday 23 June 2012 13:37:59 Michael Palimaka wrote:
> >> +for x in ${LANGS}; do
> >> + IUSE+=" linguas_${x}"
> >> +done
> >
> > if you don't want to make it into an array:
> > IUSE+=" $(printf 'linguas_%s ' ${LANGS})"
>
> What's wrong with the original? Why the subshell?
printf is faster than a for loop, and prettier imo
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] grub:2 keywords
On Monday 25 June 2012 00:15:59 Mike Gilbert wrote: > An official release of grub-2.00 should be coming pretty soon. I would > like to keyword this for ~amd64 and ~x86 shortly after it hits the tree. > I don't do much work on base system packages, so I would like some > advice on how to make this as smooth as possible. > > My main concern is that many people probably have sys-boot/grub in > @world. If grub:2 is made visible, portage will install it, and will > remove grub-0.97 on the next depclean. This could be a little confusing, > but should not cause any immediate damage since the copy of grub-0.97 > installed in the MBR and /boot would remain intact. > > Is this worthy of a news item? Or I just blog about it? > > Anything else I need to think about here? do we have automatic migration/updating in place like with grub1 ? that was the biggest reason i didn't unleash it for automatic installing on people's systems. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: grub:2 keywords
On Tuesday 26 June 2012 00:04:35 Duncan wrote: > Mike Gilbert posted on Mon, 25 Jun 2012 23:13:09 -0400 as excerpted: > > Profiles do not set a "default bootloader" so I have no idea what you > > are talking about. > > I could have sworn there was a virtual/bootloader or some such, that was > a part of @system and that thus would have likely had a default in the > profiles packages file, but either there was but it's long gone, or I'm > mis-remembering entirely. long gone when we threw out old style virtuals -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Orphaned packages
On Thursday 28 June 2012 04:22:22 Naohiro Aota wrote: > Diego Elio Pettenò writes: > > I'm going to give up maintainership of a few packages simply because I'm > > not using it any longer and thus I can't care about them as much as I > > should: > > > > dev-util/perf > > I take this one. i think this can go to kernel-misc herd since it's part of the kernel -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On 27 June 2012 19:51, Federico "fox" Scrinzi wrote: > The main question is: what would you like to have on this dashboard? > Currently (in the development version) there's the possibility to login > and watch/unwatch packages/categories/herds/... and see the watched > stuff in the account dashboard. We're planning on implementing a > weekly(?) custom newsletter based on the packages you're watching, which > features would you like? > > The project repo for the GSoC is here: https://github.com/volpino/euscan > > Thanks! > For the most part it seems to get upstream / portage versioning right, but occasionally you get miss-matches for some reason. It would be nice to allow to provide some mapping mechanism that existed on the overlay itself to inform euscan how to map upstream versions to downstream ones, but implementing that would be far too complex I feel. Instead, it would be nice to have a mechanism in the interface to set a "Upstream version is" value for each package if euscan can't tell. Ie: http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these are in fact the same version. So in 0.710.0 , it would be nice to be able to set the upstream version manually to 0.71 so that euscan no longer reported it as outdated. http://euscan.iksaif.net/package/dev-perl/Authen-SASL-Cyrus-server/ 0.13 == 0.13-serve http://euscan.iksaif.net/package/dev-perl/Module-Extract-Namespaces/ 0.140.200_rc == 0.14_0.2 http://euscan.iksaif.net/package/dev-perl/Math-BaseCnv/ http://euscan.iksaif.net/package/dev-perl/XML-Tidy/ 1.8 == 1.8.B59BrZ 1.8 == 1.8.B2AMvd ( Upstream for those 2 packages have a versioning scheme tantamount to intolerable cruelty. https://rt.cpan.org/Public/Bug/Display.html?id=60275 ) http://euscan.iksaif.net/package/dev-perl/Perl-Critic-Moose/ 0.999.2_rc == 0.999._002 http://euscan.iksaif.net/package/dev-perl/aliased/ 0.300.100_rc == 0.30_0.1 http://euscan.iksaif.net/package/dev-perl/EV/ 4.110.0 == 4.11 -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
[gentoo-dev] Feature Request/RFC : "Elective" virtuals
I was doing a fresh Gentoo install today, following the manual, and it appeared to me that the manual suggests to install a "logger" and a "cron", and gives some defacto suggestions. However, the available packages that provide this facility(s) are not overly obvious from a portage standpoint. The best index I can find presently for a list of things that provide these facilities are virtual/cron , and virtual/logger , and only then by perusing the source. And if you tell somebody to install "virtual/cron", you'll get the first thing in the ||( ) list, not an elective choice of which to install. It makes sense to me that there are some circumstances, where it makes sense to, instead of simply picking the first match, present the user with the option of one of them ( somehow ). ie: emerge -pv virtual/cron could, instead of the current behaviour of installing vixie-cron,show a list with the non-chosen alternatives: What we presently get is this: [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug (-selinux)" 0 kB [ebuild N ] virtual/cron-0 0 kB Where it might be nice to instead give: [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug (-selinux)" 0 kB [ebuild ? ] sys-process/cronie-1.4.8 USE="inotify pam" ( virtual/cron ) [ebuild ? ] sys-process/dcron-4.5 44 kB ( virtual/cron ) [ebuild ? ] sys-process/fcron-3.0.6-r1 USE="pam -debug (-selinux)" LINGUAS="-fr" 540 kB ( virtual/cron ) [ebuild ? ] sys-process/bcron-0.09 57 kB ( virtual/cron ) [ebuild N ] virtual/cron-0 0 kB As a way to show that vixie-cron is being chosen as the default, but there are other things that can optionally provide that virtual too. (* important: dependent children of the alternatives should not be computed or displayed, as this will only add confusion, not to mention headaches, as all the above crons have blockers on each other to stop them being installed together ) This is the "Simplest" option I could think of that made it more "User facing" that these virtuals exist to provide a given feature using a mechanism of the users choice. You could take this further and make an interactive choice system, which was only presented in certain conditons, ie: if the ||( ) condition was not already satisfied, or if the users command indicated they want to choose virtuals themselves: emerge --virtuals=auto # current behaviour emerge --virtuals=pick-missing # interactive choice only if the conditionals are not already satisfied emerge --virtuals=pick-specified # interactive choice only for virtuals listed on the invocation line emerge --virtuals=pick-all # interactive choice every time Theres possibly other avenues I haven't thought of that might also be useful. The pick interface could be something like virtual/cron can be provided by one of the following 1) sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a fully featured crond implementation 2) sys-process/bcron (0.09): A new cron system designed with secure operations in mind by Bruce Guenter 3) sys-process/cronie (1.4.8): Cronie is a standard UNIX daemon cron based on the original vixie-cron. 4) sys-process/dcron (4.5): A cute little cron from Matt Dillon 5) sys-process/fcron (3.0.6-r1): A command scheduler with extended capabilities over cron and anacron choice[1]: *( list taken liberally from eix -c ) Then the documentation could be updated to simply tell the user emerge --virtuals=pick-specified virtual/cron virtual/logger And they could then just use the defaults ( by pressing enter ), or choosing their favourite. Also, perhaps "Virtuals" is a poor name for what mechanism I am describing. There are potentially many things that want an elective process like this on many packages, but it seems a mechanism more prevalent in virtuals. Especially as this facility is mostly provided by the "USE" mechanism in most other places. However, in VIRTUALS where you have a list of mutually exclusive alternates, a long list of USE flags with one of them defaulted via IUSE seems bad. Not to mention, the mechanism for displaying what each individual USE flag will get you is a bit messy at present. ( Being, you have to invoke some other portage command, and this requires you finding applicable documentation for that command, to work out how to query what each individual USE flag means , and then run a different command for each package you want to consider to see its description ) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] bug XXXXXX sys-libs/tdb fail check for building library support
BTW this is bug 379837, so there was no hurry :-P Il 25/06/2012 14:55, Samuli Suominen ha scritto: Open a bug at http://bugs.gentoo.org/ instead of mailing here. Yeah, I know bugzilla is down but it's only temporary. - Samuli On 06/25/2012 02:54 PM, Francesco Riosa wrote: neither stable tdb-1.2.9 nor tdb-1.2.10 install any shared library when build with distcc, because of a failing chech @ configure time Checking for building library support: not found setting MAKEOPTS=-j1 does not suffice FEATURES=-distcc is needed FYI the check is inside buildtools/wafsamba/samba_conftests.py def CHECK_LIBRARY_SUPPORT(conf, rpath=False, version_script=False, msg=None): bld.compile() except with a file not found Portage 2.2.0_alpha111 (default/linux/amd64/10.0, gcc-4.6.3, glibc-2.15-r2, 3.4.1-vs2.3.3.4 x86_64) = System uname: Linux-3.4.1-vs2.3.3.4-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.1 Timestamp of tree: Sun, 24 Jun 2012 19:30:01 + distcc 3.1 x86_64-pc-linux-gnu [enabled] ccache version 3.1.7 [disabled] app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2 dev-util/ccache: 3.1.7 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.10.3 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.22-r1 sys-devel/gcc:4.5.3-r2, 4.6.3, 4.7.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool:2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.4 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo vivovl mysql ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload -fpredictive-commoning -ftree-vectorize -funswitch-loops -fgraphite-identity -floop-block -floop-interchange -floop-strip-mine -ggdb -gdwarf-4 -fvar-tracking-assignments" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=corei7-avx -pipe -frecord-gcc-switches -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7-avx -fgcse-after-reload -fpredictive-commoning -ftree-vectorize -funswitch-loops -fgraphite-identity -floop-block -floop-interchange -floop-strip-mine -ggdb -gdwarf-4 -fvar-tracking-assignments -fvisibility-inlines-hidden" DISTDIR="/g/distfiles" EMERGE_DEFAULT_OPTS="--ask-enter-invalid --quiet-build=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg compress-build-logs compressdebug config-protect-if-modified distcc distlocks ebuild-locks fail-clean fixlafiles installsources metadata-transfer news noinfo notitles parallel-fetch parallel-install parse-eapi-ebuild-head sandbox sfperms splitdebug strict test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.netcologne.de/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.lagis.at/ http://mirror.qubenet.net/mirror/gentoo/"; INSTALL_MASK="/usr/lib64/libogrove.la /usr/lib64/libospgrove.la /usr/lib64/libostyle.la /usr/lib64/vlc/plugins/codec/libdirac_plugin.la /usr/lib64/vlc/plugins/demux/libdirac_plugin.la /bin/systemd /bin/systemctl /usr/lib64/elektra/libelektra-filesys.la /usr/lib64/elektra/libelektra-hosts.la /usr/lib64/elektra/libelektra-ini.la /usr/lib64/elektra/libelektra-passwd.la /usr/lib64/libelektra-cpp.la /usr/lib64/libelektra.la /usr/lib64/libelektratools.la " LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--sort-common -Wl,--no-copy-dt-needed-entries -Wl,--build-id " LINGUAS="it" MAKEOPTS="-j36" PKGDIR="/g/packages" PORTAGE_COMPRESS="lzma" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/g/portage" PORTDIR_OVERLAY="/g/ovl/tmp /g/ovl/mysql" SYNC="rsync://rsync.gentoo.or
Re: [gentoo-dev] prune_libtool_files is NOT a direct replacement for, example, find "${D}" -name '*.la' -delete
El jue, 28-06-2012 a las 10:26 +0200, Michał Górny escribió: > On Wed, 27 Jun 2012 22:12:34 +0300 > Samuli Suominen wrote: > > > The logic in prune_libtool_files is not perfect[1]. > > Define 'perfect'. > > > To clarify: > > > > Use `prune_libtool_files --all` instead of plain > > `prune_libtool_files` if you don't test the package with the USE > > flags. > > Sounds like abuse of '--all' to me. It's like calling 'rm -r' for > single file... > > > [1] http://bugs.gentoo.org/421197 > But we will need to use "--all" in cases like pointed in that bug report, no? :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Wed, 27 Jun 2012 11:29:49 +0200 Michael Weber wrote: > - - a Report problem machanism. >i.e. on http://euscan.iksaif.net/maintainers/48/ there's an >inconsistency between both "upstream" and "version in gentoo" >being 2012.2.0 but there's still a light red marker. And in the same spirit, a way to report when the scans generate false positives in version matching. jer
Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback
> I'd like to see the information regarding current tree state updated > more regularly than the full upstream scan. Especially when looking at > the herd view, it can be hard to keep track of which bumps have already > been completed. Good idea- it should be much cheaper to do the tree update than to re-scan upstream... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: euscan GSoC project - requesting feedback
On 2012-06-27 17:51, Federico "fox" Scrinzi wrote: Hi everybody! I'm working on a GSoC project for enhancing Euscan (http://euscan.iksaif.net/). Euscan allows to check if a given package/ebuild has new upstream versions or not. It uses different heuristic to scan upstream and grab new versions and related urls. Euscan has a web interface for surfing data but for now is only possible to see the scan results per package/category/herd/maintainers/overlay. We're working now on the possibility to register and provide a cool dashboard for maintainers, so that they can easily keep an eye on the upstream versions of the packages they maintain. The main question is: what would you like to have on this dashboard? Currently (in the development version) there's the possibility to login and watch/unwatch packages/categories/herds/... and see the watched stuff in the account dashboard. We're planning on implementing a weekly(?) custom newsletter based on the packages you're watching, which features would you like? The project repo for the GSoC is here: https://github.com/volpino/euscan Thanks! Looking forward to seeing the improvements. :) I'd like to see the information regarding current tree state updated more regularly than the full upstream scan. Especially when looking at the herd view, it can be hard to keep track of which bumps have already been completed.
Re: [gentoo-dev] Orphaned packages
Diego Elio Pettenò writes: > Hi all, > > I'm going to give up maintainership of a few packages simply because I'm > not using it any longer and thus I can't care about them as much as I > should: > > dev-util/perf I take this one. Regards, pgprI0AlBjP3H.pgp Description: PGP signature
Re: [gentoo-dev] prune_libtool_files is NOT a direct replacement for, example, find "${D}" -name '*.la' -delete
On Wed, 27 Jun 2012 22:12:34 +0300 Samuli Suominen wrote: > The logic in prune_libtool_files is not perfect[1]. Define 'perfect'. > To clarify: > > Use `prune_libtool_files --all` instead of plain > `prune_libtool_files` if you don't test the package with the USE > flags. Sounds like abuse of '--all' to me. It's like calling 'rm -r' for single file... > [1] http://bugs.gentoo.org/421197 -- Best regards, Michał Górny signature.asc Description: PGP signature
