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

2016-04-20 Thread Mike Frysinger 
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 you submit a patch that is not extremely obvious, you must provide
> > details/justification in the commit message.  otherwise we're forced to
> > try and guess what/why it is you want to do things, and ultimately we
> > tend to start of just saying "no".
> >
> 
> Sorry, We describes details/justification in  Gentoo Bugzilla#580614
> . Explain here again.

that bug hadn't been reassigned yet to toolchain@ so i didn't see it.
i'll follow up there.
-mike


signature.asc
Description: Digital signature

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

2016-04-20 Thread Leno Hou 
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 extremely obvious, you must provide
> details/justification in the commit message.  otherwise we're forced to
> try and guess what/why it is you want to do things, and ultimately we
> tend to start of just saying "no".
>

Sorry, We describes details/justification in  Gentoo Bugzilla#580614
. Explain here again.

1) When use CHOST="powerpc64le-unknown-linux-gnu" (active host?) to build
binutils. there is no birch support.
See current supported emulations#powerpc64le-unknown-linux-gnu-ld -V

leno@localhost ~ $ powerpc64le-unknown-linux-gnu-ld -V

GNU ld (Gentoo 2.25.1 p1.1) 2.25.1

  Supported emulations:

   elf64lppc

   elf32lppc

   elf32lppclinux

   elf32lppcsim

   But we want elf64ppc for building grub2. If we there is no elf64ppc
emulation, we can't compiling grub2 and grub2-install
for ppc64le platform.

2) Following are the emulations what we want

leno@localhost ~ $ powerpc64le-unknown-linux-gnu-ld -V

GNU ld (Gentoo 2.25.1 p1.1) 2.25.1

  Supported emulations:

   elf64lppc

   elf32lppc

   elf32lppclinux

   elf32lppcsim

   elf32ppclinux

   elf32ppc

   elf32ppcsim

   elf64ppc

3) Linda Jiang found that *--enable-targets=all *make on sense to build the
above emulations what we want.
But *--enable-targets="powerpc-linux-gnu" *built the targets we want.
If there is no other arch-specific
handled like this, Is there another can handle this case? where is the
file you attached ?

and indeed, when i query a default ppc64 linker, it says it already
> supports both 32bit & 64bit targets:
> $ powerpc64-unknown-linux-gnu-ld --help | grep supported
> powerpc64-unknown-linux-gnu-ld: supported targets: elf64-powerpc
> elf64-powerpcle elf32-powerpc elf32-powerpcle aixcoff-rs6000
> aixcoff64-rs6000 aix5coff64-rs6000 elf64-little elf64-big elf32-little
> elf32-big plugin srec symbolsrec verilog tekhex binary ihex
> powerpc64-unknown-linux-gnu-ld: supported emulations: elf64ppc elf32ppc
> elf32ppclinux elf32ppcsim
>
> it would have to of course in order for biarch support (which works)
> which is how we build 64-bit kernels in a 32-bit userland.
> -mike
>

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

2016-04-20 Thread Ian Stakenvicius 

> 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 random *.exe file in my
 /usr/i686-w64-mingw32/usr/bin
> 
> That is because Mingw is for making native executables for Windows, not
> ELF files.

I believe blueness' point here was that with Windows 10's support of ELF, one 
might be able to build a say, winapi toolkit gtk+:3 directly in Linux without 
needing a mingw cross-toolchain.  That is, linking this back to the original 
point, it's best to not mix up the meaning of this use flag with the executable 
file format.

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

2016-04-20 Thread Andrew Udvare 
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 for making native executables for Windows, not
ELF files. I do not recall Gentoo Prefix supporting Mingw in a
meaningful way (it supports Cygwin IIRC). It sounds like a bit of work,
but I sure would like to see it. The problem is still that on Windows,
cmd is terrible and mintty only gives a partial solution to having such
bad terminals. Viability seems very low as every one who uses Mingw
seems to have mostly their own undocumented ways to get things to work.
You can find this pattern among many open source projects.

>> yes and while it is reported by `file` as PE32, it is sometimes referred
>> to as just win32.  its proper name, if i recall correctly is "Win32
>> Portable Executable File Format".  it is the equivalent of ELF, COFF and
>> a.out in the Linux world and Mach-O in the Mac world.  basically its the
>> format the linker/loader is looking for.

PE is essentially COFF with extensions applied. On top of that PE+ came
around the time of Windows Vista, and the format is not readable by
prior Windows versions like XP. Interestingly, even on a non-x86
platform the file will still have the MS-DOS stub (you can see this in
an XEX for Xbox 360).

Realistically, you only need to call it PE since XP is so dead.

>> with gentoo portage in there, i think
>> we'll expand in to a whole new market.

It is not easy. Ubuntu has always had trouble with Gentoo Prefix due to
a 'broken' toolchain that is kind of Debian-specific. A Debian-specific
bootstrap has to be made for this to work.

Andrew



signature.asc
Description: OpenPGP digital signature

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

2016-04-20 Thread Göktürk Yüksek 
-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
outside the tag as in "sys-boot/grub:2". Will fix and resubmi
t.

- --
gokturk

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXF/SvAAoJEIT4AuXAiM4z7EUH/R+QfIIOZljx4Pf7/093zhAF
jOjV689/UYDW8ZPvOCJA2JPg+UJMhqr2mBaflIcztO/SxGNPeeIlGXip3D7gCb5h
jcv4uyprJ7kWtbNcEOmvL3TwqjDiuHAwZtpVHUFnrryIGT8uv3kE6d5aUK1SHUQG
X0/fl/40QmlNHwFhpPsHa5aQbe1eLNCozI3DjzejbC3fBa3uc+15xow+G2Ox2tfz
EGlsYs3/nUVyW10mlJUBnx23agvZMQStnzwnmzYzgHjOvVSr7gXlWJkMqL7o3i1U
1PRrUooZCZTn0oejC4GC07wTiv+41mDnHtYMrBLJooArfGNWrRCICMpKARlSggM=
=Vcqu
-END PGP SIGNATURE-

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

2016-04-20 Thread Ian Stakenvicius 
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 binary format
>>> = win32
>>
>>> I don't know that we need an executable binary format flag, but
>>> we might because they're working on windows 10 so it can natively
>>> run ELF.
>>
>>
>>
>> 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
>>
>> I assume PE32 would be the label one would use if comparing to ELF ?
>>
> 
> yes and while it is reported by `file` as PE32, it is sometimes referred
> to as just win32.  its proper name, if i recall correctly is "Win32
> Portable Executable File Format".  it is the equivalent of ELF, COFF and
> a.out in the Linux world and Mach-O in the Mac world.  basically its the
> format the linker/loader is looking for.
> 
> if i've understood the plans for windows 10, its kernel will be able to
> link/load native ELF and execute Linux system calls, at least for amd64
> arch/abi.  I saw a demonstration with ubuntu userland, but i'm sure it
> will be able to handle gentoo.  with gentoo portage in there, i think
> we'll expand in to a whole new market.
> 
> not meaning to steal your thread, but i think keeping the namespace
> precise here will help us avoid collisions in the future.
> 
> 

Right, so a +1 for USE="winapi" then?



signature.asc
Description: OpenPGP digital signature

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

2016-04-20 Thread Anthony G. Basile 
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 need an executable binary format flag, but
>> we might because they're working on windows 10 so it can natively
>> run ELF.
> 
> 
> 
> 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
> 
> I assume PE32 would be the label one would use if comparing to ELF ?
> 

yes and while it is reported by `file` as PE32, it is sometimes referred
to as just win32.  its proper name, if i recall correctly is "Win32
Portable Executable File Format".  it is the equivalent of ELF, COFF and
a.out in the Linux world and Mach-O in the Mac world.  basically its the
format the linker/loader is looking for.

if i've understood the plans for windows 10, its kernel will be able to
link/load native ELF and execute Linux system calls, at least for amd64
arch/abi.  I saw a demonstration with ubuntu userland, but i'm sure it
will be able to handle gentoo.  with gentoo portage in there, i think
we'll expand in to a whole new market.

not meaning to steal your thread, but i think keeping the namespace
precise here will help us avoid collisions in the future.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

2016-04-20 Thread Austin English 
-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 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 using the flag to indicate "works on win32" as 
>> such, but instead "compile using Win32 Widgets instead of 
>> something else", wouldn't a better name indicate that somehow?
>> 
>> The simplest thing I can think of that clears this confusion is
>> a few extra characters:
>> 
>> "win32gui", "win32ui"
>> 
>> Or something along those lines.
>> 
>> It doesn't require us to know what the exact binding keywords in
>>  microsoft terminology is used, and it clearly communicates
>> "This is something to do with User Interfaces" as opposed to
>> "Just linking/compiling slightly differently".
> 
> win32 is what the base API seems to be called all over in the wild.
> The GTK+ configure flag is also --enable-win32-backend in gtk3 and
> --with-backend=win32 in gtk2 (didn't personally check the latter).
> Note that gtk configure actually also tracks platform_win32 and
> os_win32 in there, which are different things (and just
> configure.ac internal names). Former is true when host contains
> mingw, latter when host contains mingw or cygwin. When win32 gdk
> backend is enabled (which the propose USE flag would do), then it
> will depend on a matching cairo backend of that, to be able to do
> its own drawing on Windows. There's actually some stuff about 
> pangowin32 as well, not sure Ian has noticed that yet.
> 
> The GDK win32 backend uses what is called the win32 API. See e.g 
> https://en.wikipedia.org/wiki/Windows_API#Versions For example a 
> GdkWindow is created via CreateWindowExW, root of that 
> documentation is apparently at
> 
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.8
5).aspx
> 
> It doesn't use the Windows API higher level UI stuff, like 
> wxWidgets does, but only the low-level stuff, and then emulating 
> the themeing as best as it can right now, like Qt does. So in that 
> way win32gui might be misleading. win32 or win32api or winapi or I 
> dunno.
> 
> Theoretically you can also build this stuff for consumption with 
> wine. Or maybe ReactOS? Basically the only real point I have is 
> that anything kernel_* to control this probably doesn't make 
> sense.

Wine's dlls and programs (notepad/winemine/etc.) can be cross compiled
using mingw. It's mostly only useful for testing purposes (e.g.,
verifying that a certain wine dll also breaks an application the same
way on windows to confirm where the problem lies).

I used to build them regularly and upload to sourceforge, but haven't
in a while, as it seems there's little interest.

In addition, wine does use mingw if available for cross compiling its
test suite, but most users don't need/want that.

- -Austin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXF9kJAAoJEACzKVe5S/Ph+JIP/3l/spsw9AuanEbmKsYVIjg3
ErBs0omQ191mAPpovJWH0qejJaTAzneNbhXNIne8AE00L745rxensj4vtEunL9YU
QZ//nBNr2jGxX/SKmZqYn7A7+kgW9qXOVvYFWQebbyXy/DxhzMoTtP02Lvd/THyW
20W9kBS766/iuW6x6/qRRptbENMs2t3aR1B+JjB8OH/e/eAzU4RfnwuWI36D227S
56MgzuVbaY1ON+su9n/WhqjEdPitj9WaUDyxDNgglPfAcn6yVvlbXgN8CjsGo0cf
TleJhc2Kw0AYvt9V68D5oSt9l66ndC1/Zoy3r2fsboioCwqhhYI5SHWTC290iRc+
KbXOZJiCUIDahZ6YgiktkwmpODG9vb6hc9qVB7gKvX9gMZa6d9BFLxbs7lsvJ7eG
W/5ShV998tDSd63g1iKPtlyichUMQPCm5cmTVt4M3d0L19qadq4AKPr5Ap8N7dPC
YPpm8+m2FnC2iV4fFot7MTQSoJEmvWhXG8P50M/bKXyyzqRQqp+ntTE13hGILAsk
oeTdCJ/QyJrCMgJdhtjKXHcWcpAXjD0j3LbL8pRgVLiR7JtKoWOCEXvTzQRVixEz
rddxj+US3PUOFaEOLuJro7mNHHhUQanISeNQV2hOop0vBYdW9I8mL0UkfRWyjxR7
DPsjXwQYODQoJl1uWt/j
=MRRF
-END PGP SIGNATURE-

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

2016-04-20 Thread Ian Stakenvicius 
-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 an executable binary format flag, but
> we might because they're working on windows 10 so it can natively
> run ELF.
> 


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

I assume PE32 would be the label one would use if comparing to ELF ?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX2OEACgkQAJxUfCtlWe1mQQD/QrwFeMpuh0spKgwmA7d5Khhw
LpZ1RFtG2anVsyMrYn0A/Rmde/6Tw2ufvARI2+nCnKShVxDtrU3JbREr2KYrnLYI
=Cja7
-END PGP SIGNATURE-

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

2016-04-20 Thread Ian Stakenvicius 
-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 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 using the flag to indicate "works on win32" as
>> such, but instead "compile using Win32 Widgets instead of
>> something else", wouldn't a better name indicate that somehow?
>> 
>> The simplest thing I can think of that clears this confusion is
>> a few extra characters:
>> 
>> "win32gui", "win32ui"
>> 
>> Or something along those lines.
>> 
>> It doesn't require us to know what the exact binding keywords
>> in microsoft terminology is used, and it clearly communicates
>> "This is something to do with User Interfaces" as opposed to
>> "Just linking/compiling slightly differently".
> 
> win32 is what the base API seems to be called all over in the
> wild. The GTK+ configure flag is also --enable-win32-backend in
> gtk3 and --with-backend=win32 in gtk2 (didn't personally check
> the latter). Note that gtk configure actually also tracks
> platform_win32 and os_win32 in there, which are different things
> (and just configure.ac internal names). Former is true when host
> contains mingw, latter when host contains mingw or cygwin. When
> win32 gdk backend is enabled (which the propose USE flag would 
> do), then it will depend on a matching cairo backend of that, to
> be able to do its own drawing on Windows. There's actually some
> stuff about pangowin32 as well, not sure Ian has noticed that
> yet.
> 
> The GDK win32 backend uses what is called the win32 API. See e.g 
> https://en.wikipedia.org/wiki/Windows_API#Versions For example a
> GdkWindow is created via CreateWindowExW, root of that 
> documentation is apparently at 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=
vs.85).aspx
>
>  It doesn't use the Windows API higher level UI stuff, like
> wxWidgets does, but only the low-level stuff, and then emulating
> the themeing as best as it can right now, like Qt does. So in
> that way win32gui might be misleading. win32 or win32api or
> winapi or I dunno.


USE="winapi" is likely a better flag name, if others agree (and also
agree to the necessity of the flag) then I'll switch to that.


> 
> Theoretically you can also build this stuff for consumption with
> wine. Or maybe ReactOS? Basically the only real point I have is
> that anything kernel_* to control this probably doesn't make
> sense.


I can confirm what I've built with my mingw-crossdev works under
wine; no idea on ReactOS but I don't see why it wouldn't.  That
said, I expect anything built to run on a 'kernel_Winnt' would run
on both anyways so I may well have undone your point. :)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX134ACgkQAJxUfCtlWe1g1gD9GlVY1GlsHSkOhBtR3RTJKpqp
pgE3HtSptJpb9gz7zQoA/21XSnNGzs3+/UOagD+R3pRe5cHaUGRSv8m0MN7wAcYF
=4Uoi
-END PGP SIGNATURE-

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

2016-04-20 Thread Mart Raudsepp 
Ü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 others in the future), which is why I saw the
> > parallel.
> 
> 
> Given you're not using the flag to indicate "works on win32" as such,
> but instead "compile using Win32 Widgets instead of something else",
> wouldn't a better name indicate that somehow?
> 
> The simplest thing I can think of that clears this confusion is a few
> extra characters:
> 
>   "win32gui", "win32ui"
> 
> Or something along those lines.
> 
> It doesn't require us to know what the exact binding keywords in
> microsoft terminology is used, and it clearly communicates "This is
> something to do with User Interfaces" as opposed to "Just
> linking/compiling slightly differently".

win32 is what the base API seems to be called all over in the wild.
The GTK+ configure flag is also --enable-win32-backend in gtk3 and
--with-backend=win32 in gtk2 (didn't personally check the latter).
Note that gtk configure actually also tracks platform_win32 and
os_win32 in there, which are different things (and just configure.ac
internal names). Former is true when host contains mingw, latter when
host contains mingw or cygwin.
When win32 gdk backend is enabled (which the propose USE flag would
do), then it will depend on a matching cairo backend of that, to be
able to do its own drawing on Windows. There's actually some stuff
about pangowin32 as well, not sure Ian has noticed that yet.

The GDK win32 backend uses what is called the win32 API. See e.g
https://en.wikipedia.org/wiki/Windows_API#Versions
For example a GdkWindow is created via CreateWindowExW, root of that
documentation is apparently at
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

It doesn't use the Windows API higher level UI stuff, like wxWidgets
does, but only the low-level stuff, and then emulating the themeing as
best as it can right now, like Qt does. So in that way win32gui might
be misleading. win32 or win32api or winapi or I dunno.

Theoretically you can also build this stuff for consumption with wine.
Or maybe ReactOS?
Basically the only real point I have is that anything kernel_* to
control this probably doesn't make sense.


Mart

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

2016-04-20 Thread Anthony G. Basile 
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 for
>> aix/solaris/freebsd etc...
> 
> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think
> those represent a mingw environment (vs a cygwin env).

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 an executable binary format flag, but we might
because they're working on windows 10 so it can natively run ELF.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

2016-04-20 Thread Zac Medico 
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
index 1a9ee7b..5af2784 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -806,7 +806,7 @@ __eapi4_src_install() {
 
 __eapi6_src_prepare() {
if [[ $(declare -p PATCHES 2>/dev/null) == "declare -a"* ]]; then
-   eapply "${PATCHES[@]}"
+   [[ -n ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
elif [[ -n ${PATCHES} ]]; then
eapply ${PATCHES}
fi
-- 
2.7.4

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

2016-04-20 Thread 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 others in the future), which is why I saw the parallel.


Given you're not using the flag to indicate "works on win32" as such,
but instead "compile using Win32 Widgets instead of something else",
wouldn't a better name indicate that somehow?

The simplest thing I can think of that clears this confusion is a few
extra characters:

  "win32gui", "win32ui"

Or something along those lines.

It doesn't require us to know what the exact binding keywords in
microsoft terminology is used, and it clearly communicates "This is
something to do with User Interfaces" as opposed to "Just
linking/compiling slightly differently".

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

2016-04-20 Thread Ian Stakenvicius 
-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 out-of-date and potentially
> confusing flag? Can't we migrate to a win32 and win64 as
> pertaining to current/recent architectures, and directly relating
> to mingw32 and mingw64 or such-like?!
> 
> Sooner or later win32 is going to be EOL (as the operating
> systems themselves soon will be) ...
> 

kernel_Winnt may seem old but it's accurate in comparison with
kernel_DOS, which would be its predecessor if we had ever attempted
to support it -- the executable is still NTKRNL*.exe or NTOSKRNL.exe
after all, right?

Recall this isn't the ARCH, which can still be either x86 or amd64
(ie x86_64).

The win32 flag I was proposing here was relating to the UI toolkit,
which is likely (i'm guessing) called win32 for legacy reasons
rather than explicitly being 32bit, given I expect the 64bit toolkit
has more or less the same API -- again, not 32bit-windows vs
64-bit-windows related.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcXzvUACgkQAJxUfCtlWe2ezQEAyWMp3J7msrHqQbqZH/Ww1bXe
pXY0rkEcC0nW7nq6TiUA/Ry56nWOGVobygHia+4bP7b9fomnPha39GdLLZyvafS5
=SEOj
-END PGP SIGNATURE-

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

2016-04-20 Thread Ian Stakenvicius 
-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 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 adding a
>>> new global flag 'win32', modelled after the 'aqua' flag, that
>>> can be used instead to provide this configuration directly in
>>> ebuilds.
>>> 
>>> Just like USE="aqua", the flag will be use.mask'ed in base/
>>> so that users don't erroneously enable it.  I didn't
>>> un-use.mask it anywhere yet since (A) I don't have a
>>> prefix/windows environment to test, and (B) the mingw-based
>>> crossdev environments use profiles/embedded by default, which
>>> doesn't inherit from profiles/base and so doesn't have the
>>> use.mask restriction.
>>> 
>>> The attached patch lists the necessary changes to profile/ as
>>> well as the addition of USE=win32 to *ONE VERSION* of gtk+:2,
>>> gtk+:3 and cairo (the actual commit will include more
>>> versions).
>>> 
>>> 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 for aix/solaris/freebsd etc...
> 
> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think 
> those represent a mingw environment (vs a cygwin env).
> 
> i don't think a parallel to aqua makes sense.  aqua is a specific
> UI toolkit in OS X.  it's more parallel to something like GTK+ or
> QT.
> 
> further, nesting aqua/win32 doesn't make sense as there is no
> valid profile where both flags would be available.  USE=aqua can
> only be turned on in an OS X profile where your proposed
> USE=win32 would be masked (and vice versa). -mike
> 

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.

For my specific needs (mingw cross-compilation), yes leveraging
elibc_mingw would more than suffice, however there may be other
cases where configuring for the 'win32' or 'windows' UI toolkit
makes sense too -- apparently someone's built gtk+ for the win32
toolkit instead of X in cygwin and is distributing binaries (both
KERNEL and ELIBC differ there iirc), and I expect both the
prefix/windows/winnt or prefix/windows/Interix profiles would likely
benefit from this configuration too, but both of those iirc use
different ELIBC values compared to mingw.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcXzJ0ACgkQAJxUfCtlWe0fkQEAugAyzxifYKxh+R8ocgZoL1nB
3SdR9gfDjlOqkBsqBO0A/2ZdubaDowXVg7bVrfkVfZWJF5/c8aZ+5I9wyHkjKHzd
=6/5H
-END PGP SIGNATURE-

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

2016-04-20 Thread M. J. Everitt 
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 current/recent
architectures, and directly relating to mingw32 and mingw64 or such-like?!

Sooner or later win32 is going to be EOL (as the operating systems
themselves soon will be) ...



signature.asc
Description: OpenPGP digital signature

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

2016-04-20 Thread Alon Bar-Lev 
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
> configured appropriately.  In order to support this situation better,
> I propose adding a new global flag 'win32', modelled after the 'aqua'
> flag, that can be used instead to provide this configuration directly
> in ebuilds.
>
> Just like USE="aqua", the flag will be use.mask'ed in base/ so that
> users don't erroneously enable it.  I didn't un-use.mask it anywhere
> yet since (A) I don't have a prefix/windows environment to test, and
> (B) the mingw-based crossdev environments use profiles/embedded by
> default, which doesn't inherit from profiles/base and so doesn't have
> the use.mask restriction.
>
> The attached patch lists the necessary changes to profile/ as well as
> the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo
> (the actual commit will include more versions).
>
> 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 for
aix/solaris/freebsd etc...

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

2016-04-20 Thread Ian Stakenvicius 
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 adding a new global flag 'win32', modelled after the 'aqua'
flag, that can be used instead to provide this configuration directly
in ebuilds.

Just like USE="aqua", the flag will be use.mask'ed in base/ so that
users don't erroneously enable it.  I didn't un-use.mask it anywhere
yet since (A) I don't have a prefix/windows environment to test, and
(B) the mingw-based crossdev environments use profiles/embedded by
default, which doesn't inherit from profiles/base and so doesn't have
the use.mask restriction.

The attached patch lists the necessary changes to profile/ as well as
the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo
(the actual commit will include more versions).

Comments?
commit 120335a6721cbcee6f92303c8a6d7cb6cc77b36e
Author: Ian Stakenvicius 
Date:   Tue Apr 19 15:00:07 2016 -0400

Add USE="win32" to profile, x11-libs/cairo, and x11-libs/gtk+

Similar to USE="aqua", the addition of the win32 use flag allows easier
prefix and crossdev-based building of packages targeting windows (win32)
environments.

This commit adds the flag to profiles/use.desc, and masks it for all
profiles via profiles/base/use.mask.  This leaves the flag available
to be used optionally via the embedded profile, which does not inherit
from base.

Additionally, the commit adds IUSE="win32" support to x11-libs/gtk+ and
its depenency, x11-libs/cairo.  Other packages may follow in future commits.

Package-Manager: portage-2.2.26

diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 3127dad..f5bd582 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -2,6 +2,10 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
+# Ian Stakenvicius  (19 Apr 2016)
+# USE flag(s) specific to Windows (for mingw, cygwin, etc)
+win32
+
 # Brian Evans  (2 Dec 2015)
 # php 5.4 is end of life, masked for removal
 php_targets_php5-4
diff --git a/profiles/use.desc b/profiles/use.desc
index 6acf19f..49eb30f 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -371,6 +371,7 @@ wavpack - Add support for wavpack audio compression tools
 wddx - Add support for Web Distributed Data eXchange
 webkit - Add support for the WebKit HTML rendering/layout engine
 wifi - Enable wireless network functions
+win32 - Include support for the Windows GUI (for mingw or cygwin)
 wmf - Add support for the Windows Metafile vector image format
 wxwidgets - Add support for wxWidgets/wxGTK GUI toolkit
 x264 - Enable h264 encoding using x264
diff --git a/x11-libs/cairo/cairo-1.14.2-r1.ebuild b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
index 12d34b3..3f8aa88 100644
--- a/x11-libs/cairo/cairo-1.14.2-r1.ebuild
+++ b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
@@ -19,7 +19,7 @@ DESCRIPTION="A vector graphics library with cross-device output support"
 HOMEPAGE="http://cairographics.org/;
 LICENSE="|| ( LGPL-2.1 MPL-1.1 )"
 SLOT="0"
-IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind xcb xlib-xcb"
+IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind win32 xcb xlib-xcb"
 # gtk-doc regeneration doesn't seem to work with out-of-source builds
 #[[ ${PV} == ** ]] && IUSE="${IUSE} doc" # API docs are provided in tarball, no need to regenerate
 
@@ -128,6 +128,7 @@ multilib_src_configure() {
 		$(use_enable static-libs static) \
 		$(use_enable svg) \
 		$(use_enable valgrind) \
+		$(use_enable win32) \
 		$(use_enable xcb) \
 		$(use_enable xcb xcb-shm) \
 		$(use_enable xlib-xcb) \
 		$(use_enable xlib-xcb) \
diff --git a/x11-libs/gtk+/gtk+-2.24.29.ebuild b/x11-libs/gtk+/gtk+-2.24.29.ebuild
index bef80a7..5bfda5c 100644
--- a/x11-libs/gtk+/gtk+-2.24.29.ebuild
+++ b/x11-libs/gtk+/gtk+-2.24.29.ebuild
@@ -13,9 +13,10 @@ HOMEPAGE="http://www.gtk.org/;
 
 LICENSE="LGPL-2+"
 SLOT="2"
-IUSE="aqua cups examples +introspection test vim-syntax xinerama"
+IUSE="aqua cups examples +introspection test vim-syntax win32 xinerama"
 REQUIRED_USE="
-	xinerama? ( !aqua )
+	xinerama? ( !aqua !win32 )
+	aqua? ( !win32 )
 "
 
 KEYWORDS="~alpha amd64 ~arm ~arm64 hppa ~ia64 ~mips ~ppc ppc64 ~s390 ~sh ~sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-freebsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
@@ -25,14 +26,14 @@ COMMON_DEPEND="
 	>=dev-libs/atk-2.10.0[introspection?,${MULTILIB_USEDEP}]
 	>=dev-libs/glib-2.34.3:2[${MULTILIB_USEDEP}]
 	>=media-libs/fontconfig-2.10.92[${MULTILIB_USEDEP}]
-	>=x11-libs/cairo-1.12.14-r4:=[aqua?,svg,${MULTILIB_USEDEP}]
+

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

2016-04-20 Thread Mike Frysinger 
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 we're forced to
try and guess what/why it is you want to do things, and ultimately we
tend to start of just saying "no".

> --- a/eclass/toolchain-binutils.eclass
> +++ b/eclass/toolchain-binutils.eclass
> @@ -271,6 +271,7 @@ toolchain-binutils_src_configure() {
>   # We used to do it for everyone, but it's slow on 32bit arches. #438522
>   case $(tc-arch) in
>   ppc|sparc|x86) myconf+=( --enable-64-bit-bfd ) ;;
> + ppc64) myconf+=( --enable-targets="powerpc-linux-gnu" ) ;;
>   esac

why ?  we don't normally do this (as you can see in the file, there is no
other arch-specific handling like this).  instead, binutils itself handles
things by selecting a default set of supported targets based on the active
host.  and when i glance in there, this seems to already be done for you.

bfd/config.bfd:
  powerpc64-*-elf* | powerpc-*-elf64* | powerpc64-*-linux* | \
  powerpc64-*-*bsd*)
targ_defvec=powerpc_elf64_vec
targ_selvecs="powerpc_elf64_le_vec powerpc_elf32_vec powerpc_elf32_le_vec 
rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec"
want64=true
;;
  powerpc64le-*-elf* | powerpcle-*-elf64* | powerpc64le-*-linux* | \
  powerpc64le-*-*bsd*)
targ_defvec=powerpc_elf64_le_vec
targ_selvecs="powerpc_elf64_vec powerpc_elf32_le_vec powerpc_elf32_vec 
rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec"
want64=true
;;

ld/configure.tgt:
powerpc*-*-elf* | powerpc*-*-eabi* | powerpc*-*-sysv* \
  | powerpc*-*-linux* | powerpc*-*-netbsd* | powerpc*-*-openbsd* \
  | powerpc*-*-solaris* | powerpc*-*-kaos* | powerpc*-*-vxworks*)
 case "${targ}" in
*64*)   targ_emul=elf64ppc
targ_extra_emuls="elf32ppc elf32ppclinux elf32ppcsim"
targ_extra_libpath="elf32ppc elf32ppclinux"
td=tdir_elf32ppc
case "${targ}" in
powerpc*le-*) td=tdir_elf32lppc;;
esac
eval ${td}=`echo "${targ_alias}" | sed -e 's/64//'`
eval ${td}linux=\$${td}
eval ${td}sim=\$${td}
;;

and indeed, when i query a default ppc64 linker, it says it already
supports both 32bit & 64bit targets:
$ powerpc64-unknown-linux-gnu-ld --help | grep supported
powerpc64-unknown-linux-gnu-ld: supported targets: elf64-powerpc 
elf64-powerpcle elf32-powerpc elf32-powerpcle aixcoff-rs6000 aixcoff64-rs6000 
aix5coff64-rs6000 elf64-little elf64-big elf32-little elf32-big plugin srec 
symbolsrec verilog tekhex binary ihex
powerpc64-unknown-linux-gnu-ld: supported emulations: elf64ppc elf32ppc 
elf32ppclinux elf32ppcsim

it would have to of course in order for biarch support (which works)
which is how we build 64-bit kernels in a 32-bit userland.
-mike


signature.asc
Description: Digital signature

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

2016-04-20 Thread Sam Jorna 
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 Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

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

2016-04-20 Thread Michał Górny 
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
>> > Author: Patrice Clement  gentoo  org>
>> > AuthorDate: Mon Apr 18 06:35:31 2016 +
>> > Commit: Patrice Clement  gentoo  org>
>> > CommitDate: Mon Apr 18 07:58:13 2016 +
>> > URL:   
>https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca
>
>...
>
>> > -  CC on bugs
>> 
>> You're discarding important information here. This also has been
>> covered in the GLEP. The suggested solution is to copy the person
>into
>> downstream maintainers with appropriate explanatory description (like
>> 'upstream developer wishing to be CC-ed on bugs').
>
>Just an FYI:
>Members of the Proxy Maintainers project decided that the inclusion of
>the
> element was superfluous and that the ordering of
>
>elements was sufficient for determining bug assignment/CC'ing based on
>the
>bug-wranglers policy[0] (which does not explicitly mention />).

Just FYI, we're talking about upstream maintainer elements which do not take 
part in bug assignment.


-- 
Best regards,
Michał Górny (by phone)

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

2016-04-20 Thread Göktürk Yüksek 
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 
Signed-off-by: Göktürk Yüksek 
---
 ebuild-maintenance/text.xml | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 66d736f..7cbe755 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -441,8 +441,12 @@ Next is checking the files under profiles/ 
such as
 profiles/package.mask and update them to reflect the ebuild
 move. Various eclasses automatically provide some of the dependencies upon
 inherit, so the files under eclass/ should be checked and updated
-properly as well. Lastly, the titles of the open bugs related to the package
-should be updated.
+properly. If the package metadata.xml has tags with restrict
+attribute, they should be updated to reflect the move. The
+metadata.xml for various packages may contain references to the
+package being moved using the pkg tag which need to be
+updated accordingly as well. Lastly, the titles of the open bugs
+related to the package should be updated.
 
 
 
@@ -467,6 +471,12 @@ Here is an example where the package
   
   Check the eclasses that may be referencing the package
   
+Update all the
+metadata.xml
+files which contain a reference to this package using the
+pkg tag or the restrict attribute.
+  
+  
 Stage all the changed files using git add. For example: git add
 profiles/package.mask
   
@@ -554,6 +564,11 @@ When removing packages follow these steps:
   Wait 30 days (or more)
   Remove from the git tree unless the reason for removal has been 
fixed
   Remove package.mask entry
+  
+Remove the pkg tags referencing this package in the
+metadata.xml
+files of other packages.
+  
   Close open bugs as WONTFIX
  
 
-- 
2.7.3