Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

On 21 Apr 2016 13:16, Leno Hou wrote: > On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote: > > On 20 Apr 2016 13:52, Leno Hou wrote: > > > Authored-by: Linda Jiang > > > --- > > > eclass/toolchain-binutils.eclass | 1 + > > > 1 file changed, 1 insertion(+) > > > > when

Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote: > On 20 Apr 2016 13:52, Leno Hou wrote: > > Authored-by: Linda Jiang > > --- > > eclass/toolchain-binutils.eclass | 1 + > > 1 file changed, 1 insertion(+) > > when you submit a patch that is not

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

> On Apr 20, 2016, at 6:51 PM, Andrew Udvare wrote: > >> On 20/04/16 12:58, Ian Stakenvicius wrote: >> On 20/04/16 03:41 PM, Anthony G. Basile wrote: According to 'file' the binary format is actually "PE32 executable (console) Intel 80386, for MS Windows" for a

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

On 20/04/16 12:58, Ian Stakenvicius wrote: > On 20/04/16 03:41 PM, Anthony G. Basile wrote: >>> According to 'file' the binary format is actually "PE32 executable >>> (console) Intel 80386, for MS Windows" for a random *.exe file in my >>> /usr/i686-w64-mingw32/usr/bin That is because Mingw is

Re: [gentoo-dev] [PATCH v1 3/3] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Göktürk Yüksek: > +flag name="multislot" + Allow concurrent > installation of pkgsys-boot/grub:0/pkg and + > pkgsys-boot/grub:2/pkg by renaming all programs. + > /flag Please do not merge. I just realized that the slot operators should be

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

On 20/04/16 03:41 PM, Anthony G. Basile wrote: > On 4/20/16 3:30 PM, Ian Stakenvicius wrote: >> On 20/04/16 03:01 PM, Anthony G. Basile wrote: >> >>> The way I think of it is >> >>> the operating system (ie kernel) = kernel_Winnt the system >>> libraries (=~libc)= elibc_Winnt the executable

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

On 4/20/16 3:30 PM, Ian Stakenvicius wrote: > On 20/04/16 03:01 PM, Anthony G. Basile wrote: > >> The way I think of it is > >> the operating system (ie kernel) = kernel_Winnt the system >> libraries (=~libc)= elibc_Winnt the executable binary format >> = win32 > >> I don't know that we

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2016 02:18 PM, Mart Raudsepp wrote: > Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent > Fredric: >> On 21 April 2016 at 06:38, Ian Stakenvicius >> wrote: >>> Well so far the only needs I have run into for

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/04/16 03:01 PM, Anthony G. Basile wrote: > > The way I think of it is > > the operating system (ie kernel) = kernel_Winnt the system > libraries (=~libc)= elibc_Winnt the executable binary format > = win32 > > I don't know that we need

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/04/16 03:18 PM, Mart Raudsepp wrote: > Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent > Fredric: >> On 21 April 2016 at 06:38, Ian Stakenvicius >> wrote: >>> Well so far the only needs I have run into for the

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

Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent Fredric: > On 21 April 2016 at 06:38, Ian Stakenvicius wrote: > > Well so far the only needs I have run into for the win32 flag has > > been in relation to choosing UI toolkit support for cairo and gtk+ > > (and possibly

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

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 CHOST without introducing new USE flag, just like we do

[gentoo-portage-dev] [PATCH] __eapi6_src_prepare: handle empty PATCHES array (bug 579626)

Only call eapply with a non-empty PATCHES array, as specified by PMS. X-Gentoo-bug: 579626 X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=579626 --- bin/phase-helpers.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh

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

On 21 April 2016 at 06:38, Ian Stakenvicius wrote: > Well so far the only needs I have run into for the win32 flag has > been in relation to choosing UI toolkit support for cairo and gtk+ > (and possibly others in the future), which is why I saw the parallel. Given you're not

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/04/16 02:22 PM, M. J. Everitt wrote: > On 20/04/16 19:17, Mike Frysinger wrote: >> agreed ... we have kernel_Winnt & elibc_Winnt already. i >> think those represent a mingw environment (vs a cygwin env). > Surely 'winnt' is a somewhat

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/04/16 02: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: >>> After doing some experimentation with a mingw crossdev, I >>> found that I needed to do a lot of

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

On 20/04/16 19:17, Mike Frysinger wrote: > agreed ... we have kernel_Winnt & elibc_Winnt already. i think > those represent a mingw environment (vs a cygwin env). Surely 'winnt' is a somewhat out-of-date and potentially confusing flag? Can't we migrate to a win32 and win64 as pertaining to

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

On 20 April 2016 at 18:52, Ian Stakenvicius wrote: > > Hi everyone: > > After doing some experimentation with a mingw crossdev, I found that I > needed to do a lot of EXTRA_ECONF settings in combination with > USE="aqua" in order to get packages supporting a win32 API to be >

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

Hi everyone: After doing some experimentation with a mingw crossdev, I found that I needed to do a lot of EXTRA_ECONF settings in combination with USE="aqua" in order to get packages supporting a win32 API to be configured appropriately. In order to support this situation better, I propose

Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

On 20 Apr 2016 13:52, Leno Hou wrote: > Authored-by: Linda Jiang > --- > eclass/toolchain-binutils.eclass | 1 + > 1 file changed, 1 insertion(+) when you submit a patch that is not extremely obvious, you must provide details/justification in the commit message. otherwise

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

On Wed, Apr 20, 2016 at 08:57:52AM +0200, Michał Górny wrote: > Just FYI, we're talking about upstream maintainer elements which do not take > part in bug assignment. Ah, yes, I missed that; though it may have been done as something related to that - just putting it out there. Cheers; -- Sam

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

Dnia 20 kwietnia 2016 06:52:24 CEST, Sam Jorna napisał(a): >On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote: >> On Mon, 18 Apr 2016 08:13:34 + (UTC) >> "Patrice Clement" wrote: >> >> > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050

[gentoo-dev] [PATCH] ebuild-maintenance: information for updating metadata on package move/removal

The dtd for metadata.xml supports referencing other packages using the tag. It also allows package atoms to be specified as part of the "restrict" attribute for various tags. These references should be properly updated/removed upon package moves and removals. Reported-by: NP-Hardass