Re: [gentoo-dev] What are blocks used for?

ignore the block, then manually uninstall mktemp straight afterwards. > User instead uninstalls mktemp, which is a moderately critical binary. Or user uninstalls coreutils - yes, a colleague of mine actually did... /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@list

Re: [gentoo-dev] New developer : Markus Duft (mduft)

s Gentoo on Win32. Yes, today isn't April, the first (remember geNToo). Heh - today is April, the last! > Please everybody, give a very warm welcome to mduft. Enjoy geVISToo ;) /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"

should just do it (tm). > > Why not default/linux? Just wanted to ask the same... /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

. This might seem confusing, but is the way HP does for various reasons. HP-UX is the only OS I know that does multilib on the ia64 CPU, and the default compiler output is 32bit without any additional switch. I can provide more details if necessary. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

esult in simple ${D}, which is "backwards > compatible". This is not all what is necessary, but a big deal of it. > > Question here, however, is whether this is worth it. Personally, I > prefer the shorthands, as they give a lot of readability. Could it also work to initialize t

Re: [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms

nta[1], which uses Debian's APT AFAICS. As "Gentoo Solaris" would not be the same as "Gentoo Prefix on Solaris", it should not share the *-solaris keywords used for Prefix via the same KEYWORDS-setting. For me, this is a (maybe strange, but valid) reason for something like PRE

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

stead... Never *unconditionally* switch back from libltdl to dlopen&co in source code, as it is likely to break many non-linux platforms (Darwin, AIX, HP-UX, ...). /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

the "local-scope" EAPI. May allow to not define "micro", assuming "$major.$minor.0" then. May disallow a "local-scope" EAPI, specifies it instead. local-scope EAPI: Think as "$major.$minor.micro" EAPI. Specifies which PM-functions are available for use in actions (fex 'doman' inside src_install). May be specified as part of "minor" EAPI. Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

rite in the ebuilds. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

e like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

zero on failure > > rather than splatting). > > Sounds useful to have less '|| die' all over the place. Whats wrong with 'set -e' and doing '|| true' behind? IMO this would feel more shell-ish. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

g *any* eapi at all. It just forces PM to provide inherit() as the only PM-defined global-scope function. So whatever we try, specifying an eapi inside an .ebuild *without* changing the extension *will* be a hack, just more ore less ugly. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] newins "-" for standard input?

On Mon, 2009-03-23 at 17:11 +0100, Timothy Redaelli wrote: > On Monday 23 March 2009 09:22:06 Ulrich Mueller wrote: > > > >newins - baz <<<$'# a short\n# file' > > Why can't you use "newins /dev/stdin foo" that it works out of the box? Nope, /dev/stdin isn't portable. While Linux and Solari

[gentoo-dev] Gentoo as Meta Distribution?

" with: ACCEPT_DISTRO_KEYWORDS='HARDENED ~GENTOO' What else would be needed for the whole topic: * helper scripts to manage/merge/update my private distro-tree. * helper scripts to set up my private distro's distfiles mirror. * repoman support for additional keyword variables * more thoughts * ... Thank you for your time reading until here! /haubi/ (-> weekend now) -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Preserving mtimes for EAPI3

file does exist already, and its content does change, set mtime to 'merge time'. Maybe this should be done for header files only, or with some black- or whitelisting mechanisms, or for files which have mtime<'build time'? /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop

especially what exactly). > > > > V-Li > > I like it. It's useful to me, at least, and I like having this > information available where I can find it in case I need it. +1 /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

licitly set the system-vm (whatever version it is or will be changed to), while leaving it unset would fall back to the user-vm? More toughts? Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

ke we have a similar job ;) Maybe it's the wording only, but in addition to the multi-user dimension I'm still missing the multi-project dimension for one user. /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

compatibility issues in the future. And when uselect settings can be read from stdin (stored in simple text files), this version number could occur multiple times there, as the stored files simply will be concatenated. And subsequent values might override previous ones then. Uh, so many stran

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote: > > This .uselect > > should not contain symlinks, but plain (text?) files only. > Do we really need more than one file? No, at least not to define the _values_ of a profile. > Checklist: > * Hostname > * Uname > * {$chost} > > Mmm...

[gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs

... done! !!! All ebuilds that could satisfy ">net-misc/mico-2.3.13" have been masked. !!! One of the following masked packages is required t

[gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote: > inherit eapi 4 > > Now when the PM is capable of pre-source EAPI detection, it will set > EAPI before sourcing, eapi.eclass can see EAPI already being set and not > do the 'exit' in global scope.

Re: [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

On Fri, 2009-05-29 at 10:42 +, Duncan wrote: > Michael Haubenwallner posted on Fri, 29 > May 2009 10:14:46 +0200: > > > Ohw, the latter would be necessary here, or '4.ebuild' would not be > > found. > > s/4.ebuild/4.eclass/ I assume. Indeed. > Exce

Re: [gentoo-dev] A new glep: Ebuild format and metadata handling

to ignore "eapi" as argument to 'inherit', or need to inform eapi.eclass somehow that the EAPI was parsed already. There might be a better name than 'eapi.eclass' here. With 'eapicompat.eclass' fex this would read: EAPI="4" inherit eapicompat Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] GLEP 55 Version 2

3df73d3d6804b7e.xml [2] http://archives.gentoo.org/gentoo-dev/msg_348f84690f03e597fb14d6602337c45f.xml Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Packages maintained by mduft need a co-maintainer

On 04/14/2012 01:30 PM, Pacho Ramos wrote: > Due long devaway, his packages need a co-maintainer, feel free to add to > metadata if you want. Thanks: > app-portage/prefix-chain-setup > sys-apps/prefix-chain-utils Even if prefix-chaining most likely is broken ATM in prefix-portage, (IMO) they sti

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

ble/ subdir for each selectable profile here, besides an extra buildbot/ subdir too... As a side effect, this wouldn't affect EAPI in any way. [1] http://archives.gentoo.org/gentoo-dev/msg_a69bee8bfa00146ee05e49adf722e791.xml my .02 /haubi/ -- Michael Haubenwallner Gentoo on a different level

[gentoo-dev] Re: [PATCH 1/4] profiles/prefix: Add arch/base to parent

On 02/13/2017 03:40 PM, Michał Górny wrote: > --- > profiles/prefix/parent | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/prefix/parent b/profiles/prefix/parent > index 8f0e9fd7471d..3eaf2c441360 100644 > --- a/profiles/prefix/parent > +++ b/profiles/prefix/parent > @@ -1 +1,2

[gentoo-dev] profiles/arch/amd64/no-multilib cleanup WAS: [PATCH 1/8] profiles/hardened: Include base amd64-multilib profile in subprofile

inherited multiple times - most prominent is the default/linux/amd64/13.0/no-multilib profile. So removing arch/amd64/no-multilib/parent would simplify things here. Thoughts? /haubi/ From 9457fd8eb330a94a15bb91decec522fe1c027986 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Thu, 2 M

[gentoo-dev] Re: Integrating Ada into toolchain.eclass, again

Hi Luke, On 05/19/2017 09:08 PM, Luke A. Guest wrote: > Hi, > > I posted a bug back in August, > https://bugs.gentoo.org/show_bug.cgi?id=592060, to discuss adding Ada > support into Gentoo's toolchain.eclass. > Thoughts? Did you have a look at https://bugs.gentoo.org/show_bug.cgi?id=592060 ? I

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

On 09/29/2017 03:36 AM, Marty E. Plummer wrote: > On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote: >> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer >> wrote: >>> arfrever suggests I send a mail here, as there are other packages which >>> may be affected by this issue and perhaps

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

On 09/29/2017 10:33 AM, Marty E. Plummer wrote: > On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner wrote: >> On 09/29/2017 03:36 AM, Marty E. Plummer wrote: >>> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote: >>>> On Wed, Sep 20, 2017

[gentoo-dev] Re: Open Build Service

Hi, another two cents: On 11/10/2017 12:03 AM, Samuel Bernardo wrote: > Hi, > > I send this email to know the devs opinion about Gentoo integration with > Open Build Service[1]. > > When creating specialized images and using an automated process for > testing before deployment, I think that Ope

[gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

Hi, HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining" portage patch I've carried in prefix-overlay all the time, thank you for that! However, a first thing being unclear already came up when bumping EAPI 6 to 7: For example, the current app-misc/ca-certificates ebuild (EA

Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

On 05/31/2018 12:58 AM, Zac Medico wrote: > On 05/30/2018 04:49 AM, Michael Haubenwallner wrote: >> Hi, >> >> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining" >> portage patch I've carried in prefix-overlay all the time, than

[gentoo-dev] Re: EAPI 7, BDEPEND and pkg_*inst

On 06/04/2018 01:40 PM, Michał Górny wrote: > W dniu śro, 30.05.2018 o godzinie 13∶49 +0200, użytkownik Michael > Haubenwallner napisał: >> Hi, >> >> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining" >> portage patch I've carr

[gentoo-dev] [PATCH 2/5] toolchain.eclass: D->ED for where to start cleanups

--- eclass/toolchain.eclass | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index fe41a80db28..a51d8e84f5e 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -1720,9 +1720,9 @@ toolchain_src_install

[gentoo-dev] [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

Hi, please review these patches we have in prefix-overlay, where patches 3-5 are for Gentoo Prefix on Cygwin. Thanks! /haubi/

[gentoo-dev] [PATCH 1/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

--- eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 68e4ce15b37..fe41a80db28 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -2207,7 +2207,7 @@ do_gcc_config() {

[gentoo-dev] [PATCH 3/5] toolchain.eclass: avoid leading double slash

Path starting with "//" is a Network path for Cygwin: As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}. --- eclass/toolchain.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index a51d8e84f5e..bc3a80

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

Upstream Cygwin does build their gcc with posix threads for ages, at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010). --- eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index bc3a80e0e8a..faf

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

Download and apply patches found in Cygwin's gcc.cygport, maintained at github/cygwinports/gcc, for a compiler running on cygwin. The ebuild can define the cygwinports' git commit id as CYGWINPORTS_GITREV. --- eclass/toolchain.eclass | 28 1 file changed, 28 insertion

[gentoo-dev] Re: [PATCH 3/5] toolchain.eclass: avoid leading double slash

On 06/21/2018 12:40 AM, Ulrich Mueller wrote: >>>>>> On Wed, 20 Jun 2018, Michael Haubenwallner wrote: > >> Path starting with "//" is a Network path for Cygwin: >> As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}. >> --- >>

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

On 06/20/2018 09:56 PM, Michał Górny wrote: > W dniu śro, 20.06.2018 o godzinie 19∶49 +0200, użytkownik Michael > Haubenwallner napisał: >> Download and apply patches found in Cygwin's gcc.cygport, maintained >> at >> github/cygwinports/gcc, for a compiler running

[gentoo-dev] Re: [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

On 06/20/2018 07:49 PM, Michael Haubenwallner wrote: > Hi, > > please review these patches we have in prefix-overlay, > where patches 3-5 are for Gentoo Prefix on Cygwin. Thanks for the reviews, will reorder to account for EAPI 7 paths first. One minor thing still unclear to m

[gentoo-dev] [PATCH 0/5]-r1 toolchain.eclass: Prefix patches, Cygwin related

Hi, now reordered for EAPI 7 first. Also, the downloaded cygwindist patches file now is renamed to gcc-cygwindist-.tar.gz rather than just .tar.gz. Thanks for the reviews, /haubi/

[gentoo-dev] [PATCH 1/5] toolchain.eclass: EAPI 7 aware for D,ED,ROOT,EROOT

These variables may or may not have the trailing slash. Additionally, avoid leading double slash (a network location for Cygwin) with ROOT and EROOT because they may be empty, while D and ED never should be empty and there is no reason so far to avoid double slashes in between. On the other hand, e

[gentoo-dev] [PATCH 2/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

--- eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 3916555cb21..36c9f8e78fc 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -2207,7 +2207,7 @@ do_gcc_config() {

[gentoo-dev] [PATCH 3/5] toolchain.eclass: D->ED for where to start cleanups

--- eclass/toolchain.eclass | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 36c9f8e78fc..4b94f78bfa9 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -1720,9 +1720,9 @@ toolchain_src_install

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

Upstream Cygwin does build their gcc with posix threads for ages, at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010). --- eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 4b94f78bfa9..aa6

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

Download and apply patches found in Cygwin's gcc.cygport, maintained at github/cygwinports/gcc, for a compiler running on cygwin. The ebuild can define the cygwinports' git commit id as CYGWINPORTS_GITREV. --- eclass/toolchain.eclass | 28 1 file changed, 28 insertion

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

On 06/22/2018 03:10 PM, Michael Haubenwallner wrote: > Download and apply patches found in Cygwin's gcc.cygport, maintained at > github/cygwinports/gcc, for a compiler running on cygwin. The ebuild > can define the cygwinports' git commit id as CYGWINPORTS_GITREV. > --- >

[gentoo-dev] Re: RFC: new USE="win32" flag for mingw and prefix/windows support

On 04/20/2016 09:01 PM, Anthony G. Basile wrote: > On 4/20/16 2:17 PM, Mike Frysinger wrote: >> On 20 Apr 2016 21:01, Alon Bar-Lev wrote: >>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote: Comments? >>> >>> You should be able to achieve similar behavior by looking at libc >>> and/or C

[gentoo-dev] Re: Empty project: ADA

On 08/22/2016 05:58 PM, Pacho Ramos wrote: > Now https://wiki.gentoo.org/wiki/Project:Ada is empty While not using any Ada thing myself, occasionally I'm in need to fully bootstrap upstream gcc, which requires C,C++,Ada compilers these days. There's some basically accepted patches in [1] already:

[gentoo-dev] [PATCH] multiprocessing.eclass: work around Cygwin FIFO shortcoming

Hi, same patch is about to be applied to portage: https://github.com/gentoo/portage/pull/86 Thanks for comments! /haubi/ >From dc80b87a87f407cece9abad81a5369e2ec5ae2a5 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Wed, 27 Apr 2016 15:21:52 + Subject: [PA

[gentoo-dev] Re: Unused profiles

On 01/22/2017 07:56 PM, Fabian Groffen wrote: > On 19-01-2017 20:47:46 +0100, Michał Górny wrote: >> prefix/aix/7.1.0.0/ppc This one I've added to profiles.desc, >> prefix/hpux/B.11.11/hppa2.0 while just dropping this one, silently. I've completely given up on HP-UX here already, and one would

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

On 12/10/2012 12:10 AM, "Paweł Hajdan, Jr." wrote: >> I propose that we say, once a year, schedule a tree-cleaning of old >> updates files. These updates files could be added to a tarball made >> available for download. That way if they are needed to update a system >> older than what the main t

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

On 01/23/13 19:29, Felix Kuperjans wrote: > Samuli Suominen wrote: >> please review this news item, seems we need one after all > > /dev/root is no longer available in this udev version, so people who put > this in their /etc/fstab might end up with an unbootable system. > > I suggest including

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

On 01/24/13 16:49, Michael Orlitzky wrote: > On 01/24/13 05:02, Michael Haubenwallner wrote: >> >> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and >> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to >> /dev/sda1

Re: [gentoo-dev] Automagic pax-mark

On 04/08/2013 12:08 AM, Anthony G. Basile wrote: > On 04/07/2013 05:20 PM, Mike Gilbert wrote: >> On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn >> wrote: >>> Hello All, >>> >>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call >>> no >>> longer has a || di

[gentoo-dev] [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

Hi all, as you might or might not be aware of, elibtoolize() originally was for applying patches to ltmain.sh, but now also applies patches to configure scripts. The problem is that finding configure scripts to be patched is based on where ltmain.sh is found in ${S}, wild guessing that ltmain.sh

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

On 11/13/2013 10:14 AM, Michael Haubenwallner wrote: > Hi all, > > as you might or might not be aware of, elibtoolize() originally was for > applying > patches to ltmain.sh, but now also applies patches to configure scripts. > Attached patch drops that wild guesses, e

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

On 11/15/2013 11:02 AM, Michael Haubenwallner wrote: >> as you might or might not be aware of, elibtoolize() originally was for >> applying >> patches to ltmain.sh, but now also applies patches to configure scripts. >> Attached patch drops that wild guesses, explicitl

Re: [gentoo-dev] mbox -- looks sort of interesting

On 02/11/14 01:36, Jason A. Donenfeld wrote: > Hey folks, > > Late night clicking-while-drooling, I came across something a few > minutes ago that mildly piqued my interest -- mbox > . It's a sandbox that uses a > combination of ptrace and seccomp bpf; neither our

Re: [gentoo-dev] new profile layout with flavors and mix-ins

On 07/03/2014 08:18 AM, Joshua Kinard wrote: > On 07/02/2014 13:54, Michał Górny wrote: >> Dnia 2014-07-02, o godz. 10:44:16 > [snip] >> >> I don't feel like we ought to vote on something like this without >> understanding most of the current profiles. And I'm afraid there are >> only few people w

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

Am 2014-07-30 14:33, schrieb Samuli Suominen: > > There is no need to package.mask if proper if -logic is used, like, for > example, > > if [[ ${PV} == * ]]; then > inherit git-r3 > KEYWORDS="" > else > KEYWORDS="~amd64 ~arm ~arm64 ~x86" > fi > > Then you can just `cp foo-.ebuild foo-1.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

Am 2014-07-30 19:33, schrieb Samuli Suominen: > > On 30/07/14 20:29, Michael Haubenwallner wrote: >> Am 2014-07-30 14:33, schrieb Samuli Suominen: >>> There is no need to package.mask if proper if -logic is used, like, for >>> example, >>> >>>

Re: [gentoo-dev] New staff : Elias Pipping (pipping)

t; > > Please everybody, give a very warm welcome to Elias. > > Yay! Welcome to my^W^Wthe team! Welcome team-colleague! /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] POSIX shell and "portable"

.. > > > It seems to me that you actually mean "more FreeBSD-able" or something, > > which is a high price to pay for a relatively small part of Gentoo as a > > whole. > > More embeddable. > More BSDable. > More Linuxable - bash isn't the only linux shell, there are plently of > others. More (generic) unix-able. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] POSIX shell and "portable"

On Mon, 2007-11-05 at 10:13 +, Roy Marples wrote: > While I still have access to the [EMAIL PROTECTED] email, I'll respond here. > > > On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote: > > On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote: > > &

Re: [gentoo-dev] POSIX shell and "portable"

is available as binary package without any dependencies for each "unix" I've seen. [1] http://sourceforge.net/projects/prefix-launcher/ [2] http://prefix-launcher.wiki.sourceforge.net/ /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

*) Or just spit a message "update your PM" (from profile.bashrc) ... Just want to show that using 'eapi-function' should be more flexible than 'EAPI-variable', and thus will not be subject to change too often and require 2) (see above). /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

ild Then you can do: ./foo.ebuild {digest,install,merge,whatever} /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

and PM could provide some 'ebuild.1' executable, at the bare mimimum doing nothing but #! /bin/sh exec ebuild --eapi 1 "$@" /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list

Re: [gentoo-dev] [RFC] Reducing the size of the system package set

Thoughts? /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Reducing the size of the system package set

On Thu, 2008-01-10 at 14:32 -0500, Mike Frysinger wrote: > On Thursday 10 January 2008, Michael Haubenwallner wrote: > > On Tue, 2008-01-08 at 14:37 -0800, Chris Gianelloni wrote: > > > Implicit dependencies waste more time than pretty much anything else. > > > Alm

Re: [gentoo-dev] Packages up for grabs

On Tue, 2007-12-25 at 18:19 +, Christian Heim wrote: > As usual you are free to pick them up, if you'd like to maintain them... > - app-admin/chrpath Late, but I should be able to take this one.. /haubi/ -- Michael Haubenwallner Gentoo on a different level --

Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays

something > > to > > keep in mind. > > -mike > > > > > > Just wanted to note this too... I am one of the affected ones... I'm also behind some firewall: +1 for keeping http. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] VDB access

e hackery in profile.bashrc, but this requires access to vdb/CONTENTS in pre_pkg_postrm() to clean up after unmerge. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

root once to register into host OS's init.d mechanism. For hpux fex this just is adding some symlinks: /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd /sbin/rc3.d/S990name -> /sbin/init.d/name # to start in runlevel 3 /sbin/rc2.d/K100name -> /sbin/init.d/name # to kill for

[gentoo-dev] stacking profile.bashrc?

them should be executed)? Or is there some defined way to handle this I just was unable to find? Thank you! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

orry, I've lost track on what's really going on here: Does 'symlink' mean symlinks on the filesystem like 'ln -s' does? Or, more important, does uselect create those symlinks itself? If yes, please don't forget that OS without symlinks... Thank you! /haubi/ -- Michael Haubenwallner Gentoo on a different level

[gentoo-dev] stacking profile.bashrc?

as as the former is not executed. Is this a portage bug (each of them should be executed)? Or is there some defined way to handle this I just was unable to find? Thank you! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

On Wed, 2009-07-15 at 16:43 +0100, Sérgio Almeida wrote: > On Tue, 2009-07-14 at 17:07 +0200, Michael Haubenwallner wrote: > > So it should be fine as long as 'symlink' can potentially be implemented > > as 'copy' for specific platforms. > ...

Re: [gentoo-dev] stacking profile.bashrc?

On Wed, 2009-07-15 at 11:39 -0700, Zac Medico wrote: > Michael Haubenwallner wrote: > > We do have post_src_install() hook in profiles/prefix/profile.bashrc ... > > In profiles/prefix/aix/profiles.bashrc, there is another > > post_src_install() hook ... > > The pro

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

Sérgio Almeida wrote: > On Thu, 2009-07-23 at 17:28 +0200, Robert Buchholz wrote: >> On Thursday 23 July 2009, Sérgio Almeida wrote: >>> You changedir, you call uprofile, and >>> voila, new profile. You login again, default profile. ..., change back to your home dir, call uprofile, and you have y

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

Sérgio Almeida wrote: > On Fri, 2009-07-24 at 10:22 +0200, Michael Haubenwallner wrote: >>> if cmd = 'chdir': >>> uprofile >> ..., the automatism for the 'cd' command feels like more >> confusing than useful... > Atm, cd just changes d

Re: [gentoo-dev] python-wrapper breaks init scripts

Arfrever Frehtes Taifersar Arahesis wrote: > 2009-10-04 20:32:17 Hanno Böck napisał(a): >> I just stepped over a problem with the new python-wrapper. If I interpreted >> the changelogs correctly, since eselect-python-20090801 /usr/bin/python is >> no >> longer a symlink, but a wrapper. > > Sin

[gentoo-dev] RFC: multilib and the compatibility to singlelib

Hi devs, while there is the appreciated multiple ABI portage support going on, a thought on the intentions of the multilib profiles. Some background: I do have to support building an older, but still maintained large application software, that simply does not work when built as 64bit. As it does

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

Mike Frysinger wrote: > On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote: >> As I'm building the toolchain myself too, I configure it with the >> 32bit host triplet on each platform, usually disabling multilib. > > this doesnt make any sense to me What

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

Mike Frysinger wrote: > On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote: >> Mike Frysinger wrote: >>> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote: >>>> As I'm building the toolchain myself too, I configure it with the >&

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

e-only" and we might need /var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*? /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

o in this case: src_prepare() { xorg-2_src_prepare --force-eautoreconf } -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

Tomáš Chvátal wrote: > Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a): >> PS: Just a suggestion what an ebuild could do in this case: >> src_prepare() { >> xorg-2_src_prepare --force-eautoreconf >> } > SNAPSHOT="yes" xorg-2_src_prepare >

Re: [gentoo-dev] [RFC] New eclass for x11 packages

Tomáš Chvátal wrote: > and renamed snapshot variable into saner XORG_EAUTORECONF. > Does it fit your needs? Sane enough for me ;), thank you! /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] RFC: fox.eclass update

utoreconf itself, which doesn't work right now[1] when elibtoolize was called before. [1] http://bugs.gentoo.org/show_bug.cgi?id=232820 /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree

eir workwork on Gentoo systems), /repoman/ isn't. So - would it make sense to split repoman into its own ebuild? /haubi/ -- Michael Haubenwallner Gentoo on a different level

Re: [gentoo-dev] libstdc++ compatibility and -bin packages

acceptable fix: Instead, gcc-config should sort available gcc's libdirs into /etc/ld.so.conf by /descending gcc-version independent of which one is currently selected/, as gcc libraries are backwards compatible AFAICS when they have the same SONAME. For linking, the selected compiler's libs are used anyway. /haubi/ -- Michael Haubenwallner Gentoo on a different level

[gentoo-dev] new glep draft: Portage as a secondary package manager

Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal "act as a secondary package manager" ... Comments welcome, haubi -- Michael HaubenwallnerSALOMON Automation GmbH Forschung & Entwicklung A-8114 Fries

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

t the whole ebuild-tree makes sence to install with a 2nd pkg mgr, fex baselayout, which is already virtualized for baselayout-lite (eh, what is Linux VServer ?). ~haubi -- Michael HaubenwallnerSALOMON Automation GmbH Forschung & Entwicklung A-8114 Fri

  1   2   >