Re: [gentoo-user] Binary package server questions

[Mick]

On Tuesday 21 Feb 2017 21:26:20 Walter Dnes wrote:
> On Tue, Feb 21, 2017 at 10:19:16PM +, Mick wrote
> 
> > Perhaps I do not understand ... why should the chrooted system need
> > to use different flags?
> 
> See
> https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html#i
> 386-and-x86-64-Options
> 
>   The desktop is "-march=ivybridge" and the netbook is "-march=bonnell".
> Neither of them can run the other's "-march=native" code.  "ivybridge"
> does not have MOVBE, while "bonnell" does not have SSE4.1, SSE4.2,
> POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C.  gcc will gladly
> build for whatever Intel cpu you tell it to.  I can build "bonnell" code
> on the "ivybridge".  But I can't run it on the "ivybridge" machine.
> 
>   As a compromise, I suppose I could declare the chroot "-march=core2".
> "core2" is "bonnell" minus MOVBE, so both the netbook and the desktop
> could run that code, with the netbook getting some, but not all, of the
> possible optimization.
> 
>   I have a "hot backup" to my desktop, which has a "silvermont" cpu.
> That's a newer Atom cpu, and it can run "bonnell" code, no problem.  But
> the "ivybridge" machine is not that old, and I prefer to keep my
> machines until they start dying.

I probably misunderstood your intent.  I thought you have 3 PCs and want to 
build binary packages for the oldest/slowest PC only, within a chroot on the 
fastest PC.  The 2 faster PCs build their own packages and do not need a 
chroot build environment.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Binary package server questions

[Walter Dnes]

On Tue, Feb 21, 2017 at 10:19:16PM +, Mick wrote

> Perhaps I do not understand ... why should the chrooted system need
> to use different flags?

See 
https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options

  The desktop is "-march=ivybridge" and the netbook is "-march=bonnell".
Neither of them can run the other's "-march=native" code.  "ivybridge"
does not have MOVBE, while "bonnell" does not have SSE4.1, SSE4.2,
POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C.  gcc will gladly
build for whatever Intel cpu you tell it to.  I can build "bonnell" code
on the "ivybridge".  But I can't run it on the "ivybridge" machine.

  As a compromise, I suppose I could declare the chroot "-march=core2".
"core2" is "bonnell" minus MOVBE, so both the netbook and the desktop
could run that code, with the netbook getting some, but not all, of the
possible optimization.

  I have a "hot backup" to my desktop, which has a "silvermont" cpu.
That's a newer Atom cpu, and it can run "bonnell" code, no problem.  But
the "ivybridge" machine is not that old, and I prefer to keep my
machines until they start dying.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Binary package server questions

[Mick]

On Tuesday 21 Feb 2017 16:31:31 Walter Dnes wrote:
>   To repeat, the basic question I'm asking is how do I set up a "dual
> mode" in the chroot so that...
> - when the chroot is updating *ITSELF* it builds stuff "-march=native"
>   and with its own CPU_FLAGS_X86, etc
> - when the chroot is building for the Atom, it uses "-march=bonnell" and
>   the Atom's CPU_FLAGS_X86 and stashes binaries in /usr/portage/packages

Perhaps I do not understand ... why should the chrooted system need to use 
different flags?  Does it have a purpose other than building binpkg for the 
Atom?

>   Right now, I think the easiest approach is to go with 2 versions of
> make.conf, and a wrapper script that copies in the appropriate one
> before launching "emerge".

Well, yes if the the chroot is used to other things and it is not meant to 
merely duplicate a build environment for the Atom, but on more powerful 
hardware.

I use a chroot on a modern 64bit PC with 8 cores and 16GB RAM, to build 32bit 
binaries for a really old 32bit Pentium 4 PC. The CFLAGS in the chroot are:

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

while the host OS is nothing of the sort.  This set up has served me nicely 
without an NFS, because the host OS is not always on when the Pentium 4 PC is 
in use.  I use rsync/cp for moving the built binaries over to the old PC 
before I install them there.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Binary package server questions

[Neil Bothwick]

On Tue, 21 Feb 2017 16:31:31 -0500, Walter Dnes wrote:

>   To repeat, the basic question I'm asking is how do I set up a "dual
> mode" in the chroot so that...
> - when the chroot is updating *ITSELF* it builds stuff "-march=native"
>   and with its own CPU_FLAGS_X86, etc
> - when the chroot is building for the Atom, it uses "-march=bonnell" and
>   the Atom's CPU_FLAGS_X86 and stashes binaries in /usr/portage/packages
> 
>   Right now, I think the easiest approach is to go with 2 versions of
> make.conf, and a wrapper script that copies in the appropriate one
> before launching "emerge".

So you want to build packages for two different architectures? In that
case, you should set up two chroots, or containers.


-- 
Neil Bothwick

Whats the difference between a magician and a brothel?
One has a cunning array of stunts,


pgpQSkrf7ahrS.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Binary package server questions

[Walter Dnes]

On Tue, Feb 21, 2017 at 03:50:41PM +, Grant Edwards wrote
> On 2017-02-21, Mick  wrote:

> > You'll need to run in 32bit mode when chrooting of course:
> 
> Why?
> 
> Is this some odd restriction in portage?
> 
> All of the normal development tools are quite capable of buildign
> 32-bit binaries on a 64-bit host running a 64-bit kernel.

  Building a 32-bit *STAND ALONE* program in a pure 64-bit environment
is easy.  Pale Moon links against various external libs (gtk, glibc,
dbus, etc).  Building 32-bit in a 64-bit environment can be done, but it
requires pulling in a bunch of 32-bit libraries.  For example see...
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS

  Rather than keeping track of a mish-mash of 32- and 64-bit libraries
on the same system, it's cleaner, simpler, and easier run a pure 32-bit
VM or chroot on a pure 64-bit host.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Binary package server questions

[Walter Dnes]

On Tue, Feb 21, 2017 at 06:02:24AM +, Mick wrote

> You'll need to run in 32bit mode when chrooting of course:
> 
> linux32 chroot /mnt/Atom_Build_env /bin/bash
> source /etc/profile
> export PS1="(Atom_Build) $PS1"

  I'm already doing something similar with a 32-bit CentOS 6 chroot on a
64-bit no-multilib Gentoo host.  No need to reboot.  I previously used a
QEMU VM.  It has disadvantages...

- you need dedicated extra space on the disk image for a safety margin
- the VM needs its own 5 gigabytes of swap space
- the VM has overhead.  Building Pale Moon from source took 35 minutes in
  the VM.  In the chroot, it gets done in 22 or 23 minutes.

  To repeat, the basic question I'm asking is how do I set up a "dual
mode" in the chroot so that...
- when the chroot is updating *ITSELF* it builds stuff "-march=native"
  and with its own CPU_FLAGS_X86, etc
- when the chroot is building for the Atom, it uses "-march=bonnell" and
  the Atom's CPU_FLAGS_X86 and stashes binaries in /usr/portage/packages

  Right now, I think the easiest approach is to go with 2 versions of
make.conf, and a wrapper script that copies in the appropriate one
before launching "emerge".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] puzzling behavior of USE flags with sys-apps/man-db

[J. Roeleveld]

On February 20, 2017 1:29:20 PM GMT+01:00, Harry Putnam  
wrote:
>Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) host
> Hardware: HP xw8600 - 2x Xeon  CPU X5450 @ 3.00GHz - 32 GB ram
>
>On first attempt at emerging sys-apps/man-db (in came up in a world
>update (including -N [--newuse])
>
>emerge's output indicated that one could not have both berkdb and gmdb
>so I put this in /etc/portage/package.use/man-db
>sys-app/man-db berkdb -gmdb

I never set either of these. Where did you override the defaults?
Do you have USE="-* ... ?

>That seemed to resolve that part of the problem
>
>On next attempted emerge -va sys-apps/man-db
>
>I started getting this:
>
>root # emerge -vaDN sys-apps/man-db
>
>  These are the packages that would be merged, in order:
>
>  Calculating dependencies... done!
>
>!!! The ebuild selected to satisfy "x11-libs/gtk+:3" has unmet
>requirements.
>
> - x11-libs/gtk+-3.22.5::gentoo USE="introspection -X (-aqua) -broadway
>  -cloudprint -colord -cups -examples -test -vim-syntax -wayland
>  -xinerama" ABI_X86="64 -32 -x32"
>
>  The following REQUIRED_USE flag constraints are unsatisfied: any-of
>( aqua wayland X )
>
>  The above constraints are a subset of the following complete
>expression: any-of ( aqua wayland X ) xinerama? ( X )
>
>Note the part: any-of (aqua wayland X)
>
>Ok so I did echo "xll-libs/gtk+ X" >  /etc/portage/package.use/gtk+
>
>Adding the X useflag to xll-libs/gtk+
>
> # cat /etc/portage/package.use/gtk+
>  xll-libs/gtk+ X

Please check the above.
It should be x11, not xll
(Eg. It reads C eleven)

>But emerge appears not to go by its own stipulation
>
>Same output and next attempt:
>
>  These are the packages that would be merged, in order:
>
>  Calculating dependencies... done!
>
>  !!! The ebuild selected to satisfy "x11-libs/gtk+:3" has unmet
>requirements.
>
> - x11-libs/gtk+-3.22.5::gentoo USE="introspection -X (-aqua) -broadway
>  -cloudprint -colord -cups -examples -test -vim-syntax -wayland
>  -xinerama" ABI_X86="64 -32 -x32"
>
>  The following REQUIRED_USE flag constraints are unsatisfied: any-of
>( aqua wayland X )
>
>  The above constraints are a subset of the following complete
>expression: any-of ( aqua wayland X ) xinerama? ( X )
>
>No change..
>
>if I insert `waylan' as use flag instead of X, same result and same
>output.

Try 'wayland' instead of 'waylan'

>I'm guessing I must be interpreting the emerge output wrong.  Can
>anyone offer a clue here?

Typos, see above.

And maybe sanitize your make.conf USE setting?

--
Joost


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] puzzling behavior of USE flags with sys-apps/man-db

[David Haller]

Hello,

On Mon, 20 Feb 2017, Harry Putnam wrote:
>sys-app/man-db berkdb -gmdb

This should be
sys-apps/man-db berkdb -gdbm

> # cat /etc/portage/package.use/gtk+
>  xll-libs/gtk+ X

This should be

x11-libs/gtk+ X

ex one one dash ... Not ex ell ell dash ...

HTH,
-dnh

-- 
Time is an illusion; lunchtime, doubly so.
-- Ford Prefect

[gentoo-user] Re: Binary package server questions

[Grant Edwards]

On 2017-02-21, Mick  wrote:
> On Tuesday 21 Feb 2017 00:22:51 Neil Bothwick wrote:
>> On Mon, 20 Feb 2017 18:34:47 -0500, Walter Dnes wrote:
>> >   Reading https://wiki.gentoo.org/wiki/Binary_package_guide still leaves
>> > 
>> > me uncertain.  I have an ancient 32-bit Atom netbook.  I've installed
>> > uclibc-ng Gentoo on it.  Building big packages on it is a pain.  I can
>> > do an identical install in a QEMU VM, and distcc into it.  But that
>> > doesn't catch all compiling work.
>> > 
>> >   What I'd like to do is build binaries in a chroot on my desktop,
>> > 
>> > assuming a 32-bit uclibc-ng chroot on a 64-bit glibc host is possible.
>> > Because the cpus are different, I would need to use different CFLAGS
>> > (and CXXFLAGS) variables for when the host updates its own files, versus
>> > when it builds files for the netbook.
>> 
>> If the chroot is identical to your netbooks's install in terms of
>> *FLAGS, USE, @world etc, then yes. I used to do it this way when I had an
>> Atom netbook. I even build for a low memory 486 system in the same way.
>
> You'll need to run in 32bit mode when chrooting of course:

Why?

Is this some odd restriction in portage?

All of the normal development tools are quite capable of buildign
32-bit binaries on a 64-bit host running a 64-bit kernel.

-- 
Grant Edwards   grant.b.edwardsYow! I am a traffic light,
  at   and Alan Ginzberg kidnapped
  gmail.commy laundry in 1927!

Re: [gentoo-user] Binary package server questions

[Neil Bothwick]

On Tue, 21 Feb 2017 02:38:21 -0500, Walter Dnes wrote:

> > Oh, and you don't need a package server, just export PKGDIR via NFS
> > and mount it on the netbook.  
> 
>   I see nfs as being more complex with kernel settings required for
> client and server, not to mention config files all over the place.
> Gentoo has python as part of the system.  To fire up a very simple
> binary package webserver from a commandline (xterm/whatever)...

That's a fair point. I use NFS because PKGDIR was on a fileserver that was
always on, the build host may not have been on at the time. Both
approaches have their merits, but an NFS client needs no extra config
files (and the server only has one) just a line in fstab.


-- 
Neil Bothwick

Macro: (n.) a series of keystrokes used to simulate a missing but
essential command.


pgpKmsBZZLATr.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Binary package server questions

[Neil Bothwick]

On Tue, 21 Feb 2017 06:02:24 +, Mick wrote:

> On Tuesday 21 Feb 2017 00:22:51 Neil Bothwick wrote:

> > If the chroot is identical to your netbooks's install in terms of
> > *FLAGS, USE, @world etc, then yes. I used to do it this way when I
> > had an Atom netbook. I even build for a low memory 486 system in the
> > same way.  
> 
> You'll need to run in 32bit mode when chrooting of course:
> 
> linux32 chroot /mnt/Atom_Build_env /bin/bash
> source /etc/profile
> export PS1="(Atom_Build) $PS1"

I'm pretty sure I didn't do this. CHOST was set to 32 bit so I got 32 bit
binaries, but full use of the 64 bits for compiling.

> > Oh, and you don't need a package server, just export PKGDIR via NFS
> > and mount it on the netbook.  
> 
> Or, if you can't be bothered with the extra work to set up NFS, copy
> the contents of the PKGDIR from the chroot'ed system to the Atom after
> you finished building all the chroot'ed binary packages, then emerge
> world in the Atom.

Setting up the NFS share is a one off task, copying PKGDIR would have to
be done every time. Also, the Atom netbooks usually had very limited
storage, and PKGDIR can get very big.


-- 
Neil Bothwick

The considered application of terror is also a form of communication.


pgpVbZ0tzpLXe.pgp
Description: OpenPGP digital signature