Re: [gentoo-user] KDEPIM-4.4.2015.06 blockages

[Petric Frank]

Hello Andreas,

Am Samstag, 2. Januar 2016, 12:17:18 schrieb Andreas K. Huettel:
> Am Freitag, 1. Januar 2016, 15:30:37 schrieb Mick:
> > I am updating an old machine which does not see much usage these 
days.  I
> > came across this blockage, which seems is caused by retaining the
> 
> > pre-Kmail2 KDEPIM version on this PC:
> Wheee, another kmail1 user. :)
> 
> Don't despair, it will get fixed (since I'm maintaining it and my own
> machines are blocking too).
> 
> However, since I'm really busy with other stuff it may sadly take a bit of
> time.

Meanwhile i use a local mail server (courier-imap). The culprit with kmail2 is 
its bebaviour when it comes to a bigger number of mails (about > 3000) in 
an folder.
Due courier-imap does not give a UIDNEXT kmail2 re-scans the folders 
(nearly) forever - and i have folders containing > 5 mails. That takes a 
long time.

I use the same imap acount from differen machines which results in a 
second failure of kmail2. If mails are deleted (there seems to exist a 
threshold of deleted mails) - for example via webmail - kmail2 insists in 
getting invalid mail ids.

> (Backstory, the kde team guys asked me several times if they can go 
ahead
> with the package move from kde-base to kde-apps, I had no time for 
testing,
> and at some point I said, just do it, noone except me will notice anyway,
> and if something goes wrong I'll fix it afterwards...)

Recognized the move also. Had to adapt the package.mask accordingly.

kind regards
  Petric

Re: [gentoo-user] QEMU/distcc combination question64-

[Andrew Savchenko]

On Sat, 2 Jan 2016 10:42:31 + Neil Bothwick wrote:
> On Fri, 1 Jan 2016 22:11:34 -0500, waltd...@waltdnes.org wrote:
> 
> >   I'm trying to run a distccserver in a 32-bit VM on a 64-bit host, for
> > the benefit of my ancient 32-bit-only netbook.  Yeah, "it'll work" using
> > the native 64-bit host OS.  But any stuff that links against 32-bit
> > libraries is going to be sent back to the netbook to compile locally.
> > That defeats the whole purpose of distcc.  This is why I want the 32-bit
> > VM to compile for the 32-bit Atom.  Here's the launch script for the
> > 32-bit VM on the i3 machine...
> 
> I used to take a different approach. Instead of a VM I used a chroot
> that was a clone of the netbook, except that make.conf in the chroot
> included buildpkg in FEATURES and the netbook's make.conf have --usepkg in
> DEFAULT_OPTs. PKGDIR was an NFS share accessible to both.

Similar solution here, but instead of cloning, I NFS-mount root
from slow system using filescached to speedup I/O process and
placing all volatile data (/tmp, /var/tmp) either in local memory
or on fast local storage. This way there is no need to make manual
modifications twice or synchronize them somehow (e.g. when
modification of package.use or package.license during update is
needed).

I must warn that such approach should not be used for packages
using build-time profiling, like sci-libs/atlas or any ebuild with
USE="pgo" enabled; otherwise profiling will be wrong and targeted
on helper system instead of target box. In such cases distcc may be
used.

For 32-bit distcc on 64-bit host there is no need to chroot or
create VM (hey, they're hellishly slow!). Just add -m32 to your
*FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
{C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
can be worked around on distcc server by forcing -m32 for each
gcc call.

Best regards,
Andrew Savchenko


pgpDx8p1e6tpV.pgp
Description: PGP signature

Re: [gentoo-user] KDEPIM-4.4.2015.06 blockages

[Mick]

On Saturday 02 Jan 2016 12:17:18 Andreas K. Huettel wrote:
> Am Freitag, 1. Januar 2016, 15:30:37 schrieb Mick:
> > I am updating an old machine which does not see much usage these days.  I
> > came across this blockage, which seems is caused by retaining the
> 
> > pre-Kmail2 KDEPIM version on this PC:
> Wheee, another kmail1 user. :)
> 
> Don't despair, it will get fixed (since I'm maintaining it and my own
> machines are blocking too).
> 
> However, since I'm really busy with other stuff it may sadly take a bit of
> time.
> 
> (Backstory, the kde team guys asked me several times if they can go ahead
> with the package move from kde-base to kde-apps, I had no time for testing,
> and at some point I said, just do it, noone except me will notice anyway,
> and if something goes wrong I'll fix it afterwards...)
> 
> 
> --
> Andreas K. Huettel
> Gentoo Linux developer (council, perl, libreoffice)
> dilfri...@gentoo.org
> http://www.akhuettel.de/

Thank you Andreas for letting me know and thank you for looking after kmail1.  

I don't mind waiting for it to be fixed when you get some time.   :-)
-- 
Regards,
Mick

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

Re: [gentoo-user] Full system encryption on Gentoo

[Frank Steinmetzger]

On Wed, Dec 30, 2015 at 08:22:22PM -0500, Alex Corkwell wrote:
> On Wed, Dec 30, 2015 at 07:34:52AM +1000, Hans wrote:
> > Hi,
> > 
> > Is it possible to fully encrypt a Gentoo system as can be done with 
> > Fedora, Suse, Arch Linux, Debian and Ubunto without using a unencrypted 
> > USB boot stick or unencrypted /boot partition?
> > 
> > If yes, where can I find instructions that really work on a BIOS only 
> > box without UEFI, EFI, systemd using EXT4 file system?
> > 
> > Hans
> 
> I can confirm that it's entirely possible, as I've managed to do it with
> my laptop.
> I don't remember exactly how I did everything, but here are the main
> points of my setup.
> […]

Thank you very much for this documentation. I was about to start a thread
with this topic myself because I’m in the market for a new laptop before too
soon. But Hans beat me to it.
Since I will install an after-market SSD in it, I want to encrypt
everything. With a little luck, your information is all I need. I will
practice it in a VM.

@Neil:
you seem to know your way around booting with EFI. I don’t suppose you could
add your mustard (as we say here-abouts) regarding booting an encrypted
system with an EFI bootloader. I was hoping to quicken my boot procedure
because Grub seems slow to load and I find its UI to be not very responsive.

Cheers
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

You can’t fire me, slaves must be sold.


signature.asc
Description: Digital signature

Re: [gentoo-user] Full system encryption on Gentoo

[Neil Bothwick]

On 2 January 2016 12:01:08 GMT+00:00, Frank Steinmetzger  wrote:
> On Wed, Dec 30, 2015 at 08:22:22PM -0500, Alex Corkwell wrote:
> > On Wed, Dec 30, 2015 at 07:34:52AM +1000, Hans wrote:
> > > Hi,
> > > 
> > > Is it possible to fully encrypt a Gentoo system as can be done
> with 
> > > Fedora, Suse, Arch Linux, Debian and Ubunto without using a
> unencrypted 
> > > USB boot stick or unencrypted /boot partition?
> > > 
> > > If yes, where can I find instructions that really work on a BIOS
> only 
> > > box without UEFI, EFI, systemd using EXT4 file system?
> > > 
> > > Hans
> > 
> > I can confirm that it's entirely possible, as I've managed to do it
> with
> > my laptop.
> > I don't remember exactly how I did everything, but here are the main
> > points of my setup.
> > […]
> 
> Thank you very much for this documentation. I was about to start a
> thread
> with this topic myself because I’m in the market for a new laptop
> before too
> soon. But Hans beat me to it.
> Since I will install an after-market SSD in it, I want to encrypt
> everything. With a little luck, your information is all I need. I will
> practice it in a VM.
> 
> @Neil:
> you seem to know your way around booting with EFI. I don’t suppose you
> could
> add your mustard (as we say here-abouts) regarding booting an
> encrypted
> system with an EFI bootloader. I was hoping to quicken my boot
> procedure
> because Grub seems slow to load and I find its UI to be not very
> responsive.
> 
> Cheers
> -- 
> Gruß | Greetings | Qapla’
> Please do not share anything from, with or about me on any social
> network.
> 
> You can’t fire me, slaves must be sold.

I use systemd's version of gummiboot with /boot on the ESP. Everything else is 
on a single btrfs filesystem, on a luks-encrypted partition and dracut takes 
care of everything. I don't have my laptop with me, but I'll post the dracut 
options I use later. 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[gentoo-user] Could not link test program to Python

[Hung Dang]

Hi,

I could not update my system because of "Could not link test program to 
Python ..." error. I have attached the build log with this email and you 
can find the output of emerge --info command below. Please let me know 
if you have any suggestion?


Thanks a lot,
Hung

Portage 2.2.26 (python 3.4.3-final-0, 
default/linux/amd64/13.0/desktop/plasma/systemd, gcc-5.3.0, 
glibc-2.22-r1, 4.2.5-gentoo-i920 x86_64)

=
System uname: 
Linux-4.2.5-gentoo-i920-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.2

KiB Mem:24678796 total,   6067472 free
KiB Swap:  0 total, 0 free
Timestamp of repository gentoo: Fri, 01 Jan 2016 06:00:01 +
sh bash 4.3_p42
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:  4.3_p42::gentoo
dev-java/java-config: 2.2.0::gentoo
dev-lang/perl:5.22.1::gentoo
dev-lang/python:  2.7.11-r1::gentoo, 3.3.5-r7::gentoo, 
3.4.3-r7::gentoo, 3.5.1-r2::gentoo

dev-util/cmake:   3.4.1::gentoo
dev-util/pkgconfig:   0.29::gentoo
sys-apps/baselayout:  2.2::gentoo
sys-apps/openrc:  0.19.1::gentoo
sys-apps/sandbox: 2.10-r1::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69-r1::gentoo
sys-devel/automake:   1.11.6-r1::gentoo, 1.13.4::gentoo, 
1.14.1::gentoo, 1.15-r1::gentoo

sys-devel/binutils:   2.25.1-r1::gentoo
sys-devel/gcc:4.9.3::gentoo, 5.3.0::gentoo
sys-devel/gcc-config: 1.8::gentoo
sys-devel/libtool:2.4.6-r1::gentoo
sys-devel/make:   4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:   2.22-r1::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000

ROKO__
location: /var/lib/layman/ROKO__
masters: gentoo
priority: 50

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc 
/usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d 
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release 
/etc/php/apache2-php5.5/ext-active/ /etc/php/apache2-php5.6/ext-active/ 
/etc/php/cgi-php5.5/ext-active/ /etc/php/cgi-php5.6/ext-active/ 
/etc/php/cli-php5.5/ext-active/ /etc/php/cli-php5.6/ext-active/ 
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo 
/etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d 
/etc/texmf/web2c"

CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--quiet-build=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs collision-protect 
config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync 
metadata-transfer news parallel-fetch preserve-libs protect-owned 
sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs 
unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org;
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j7"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages"

PORTAGE_TMPDIR="/tmp/"
USE="X a52 aac acl acpi alsa amd64 apache2 asyncns bazaar berkdb blas 
bluetooth boost branding bzip2 cairo caps cdda cdr clang cli cmake 
colord corefonts cracklib crypt cups curl cxx dbus declarative djvu dri 
dts dvd dvdr emacs emboss encode equalizer exif extraengine fam fftw 
firefox flac fontconfig fortran fpm ftp fuse gd gdbm gif git glamor glib 
gphoto2 gpm graphviz gtk gtk3 gudev hdf5 iconv icu imagemagick 
introspection ios ipv6 jpeg jpeg2k json kde kipi lapack latex lcms ldap 
legacy-systray libatomic libav libmpv libnotify libxml2 lldb llvm lua 
luajit lximage lxqt lzma lzo mad mediawiki mercurial minizip mkv mmx 
mmxext mng modules mongodb mp3 mp4 mpeg mtp multilib mysql ncurses 
networkmanager nls nptl ogg opencl opengl openmp orc pam pango pcre pdf 
pdo phonon php plasma plugins png policykit postproc postscript ppds ptp 
ptp2 pulseaudio python qml qt3support qt4 qt5 rar readline script sdl 
seccomp semantic-desktop session skype sound spell sql sqlite sqlite3 
sse sse2 ssl ssse3 startup-notification svg systemd tbb tcpd threads 
tiff truetype udev udisks unicode unrar upower usb v4l video vorbis vpn 
wav wavpack webkit webp webrtc-aec widgets wma wmf wxwidgets x264 x265 
xattr xcb xcomposite xft xinerama xml xmlreader xmlwriter xmp 
xscreensaver xv xvid zip zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 
als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 
es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 

Re: [gentoo-user] QEMU/distcc combination question.

[Neil Bothwick]

On Fri, 1 Jan 2016 22:11:34 -0500, waltd...@waltdnes.org wrote:

>   I'm trying to run a distccserver in a 32-bit VM on a 64-bit host, for
> the benefit of my ancient 32-bit-only netbook.  Yeah, "it'll work" using
> the native 64-bit host OS.  But any stuff that links against 32-bit
> libraries is going to be sent back to the netbook to compile locally.
> That defeats the whole purpose of distcc.  This is why I want the 32-bit
> VM to compile for the 32-bit Atom.  Here's the launch script for the
> 32-bit VM on the i3 machine...

I used to take a different approach. Instead of a VM I used a chroot
that was a clone of the netbook, except that make.conf in the chroot
included buildpkg in FEATURES and the netbook's make.conf have --usepkg in
DEFAULT_OPTs. PKGDIR was an NFS share accessible to both.

Then I would simply emerge whatever I wanted in the chroot, then emerge it
on the netbook. No messing around with distcc, which will always run some
stuff on the local system, instead everything but unpacking the package
tarballs was done in the VM.

This approach meant that I could easily script the build process for
several systems, including a 486 box was running at the time. I later
switched to using systemd containers instead of chroots.


-- 
Neil Bothwick

Is it true that cannibals don't eat clowns because they taste funny?


pgpbgFNsCh0se.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Qt5 - should I worry?

[Frank Steinmetzger]

On Thu, Dec 31, 2015 at 01:23:28PM +, Peter Humphrey wrote:

> > > you see here. And the qt5 screen shot is half as big again as the qt4.
> > 
> > I don't quite get that.
> 
> ??

Both images are the same size. The usable content area in the qt5 screenshot
is far from just half. Maybe the word “again” tips me off b/c I try to
interpret a meaning into every word, being a pedantic non-native. ;-)

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

5 of 4 people have problems with subsets.


signature.asc
Description: Digital signature

[gentoo-user] Darme de baja.

[Julio Garcia Merlano]

Please unsusbcribe...
Por favor darme de baja...

Julio

Re: [gentoo-user] Qt5 - should I worry?

[Alan McKinnon]

On 02/01/2016 13:45, Frank Steinmetzger wrote:
> On Thu, Dec 31, 2015 at 01:23:28PM +, Peter Humphrey wrote:
> 
 you see here. And the qt5 screen shot is half as big again as the qt4.
>>>
>>> I don't quite get that.
>>
>> ??
> 
> Both images are the same size. The usable content area in the qt5 screenshot
> is far from just half. Maybe the word “again” tips me off b/c I try to
> interpret a meaning into every word, being a pedantic non-native. ;-)
> 


"half as big again" means "50% larger than".

i.e. calculate 50% and add it, making the total 150%.
It's an English idiom, so don;t try to figure it out from each word,
just recognize the whole phrase. English is full of that shit.




-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Getting rid of cups and physical printing ...

[Neil Bothwick]

On Sat, 2 Jan 2016 06:50:22 +0100, meino.cra...@gmx.de wrote:

> I am not using a physical printer. 
> 
> Is it possible to get completly rid of cups and 
> other "physical printing"-related stuff somehow?

You stipulate physical printing. Does that mean you want to retain th
ability to print to PDF or PS? If so, you would still need at least
Ghostscript and possibly CUPS too, although you should be able to get rid
of the PPD packages.


-- 
Neil Bothwick

Eye of newt, toe of frog, regular Coke and fries to go, please.


pgp_Z35nuzwKj.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] KDEPIM-4.4.2015.06 blockages

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 1. Januar 2016, 15:30:37 schrieb Mick:
> I am updating an old machine which does not see much usage these days.  I
> came across this blockage, which seems is caused by retaining the
> pre-Kmail2 KDEPIM version on this PC:

Wheee, another kmail1 user. :)

Don't despair, it will get fixed (since I'm maintaining it and my own machines 
are blocking too). 

However, since I'm really busy with other stuff it may sadly take a bit of 
time.

(Backstory, the kde team guys asked me several times if they can go ahead with 
the package move from kde-base to kde-apps, I had no time for testing, and at 
some point I said, just do it, noone except me will notice anyway, and if 
something goes wrong I'll fix it afterwards...)


- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWh7G+AAoJEHRrah2soMK+O0UQAKNIctEqkhwLTU0raKB3/TgQ
tJhjU3kG+P04O4G2NoutP0Naz8L6uOOb0lEqqsVaBBf2UB3eZL16RZ9VW6ZLsbK6
6dWAhlgO3WtF0MfJVttsT1jeog0isteCgsYp8dSsbSfAJboqibJTDUIorlwygEfa
hwiZVo3XoTlfSRikmn9D12iuSjCuVmuRrU54OKRYrcla+EHixs0lIPAi8P7oGkZ+
V1iryeNV6TD3o4L5klVKVXqAUbmE+WV7xm7e1vPD5JO23UpigOhKHMiw81/M9jVp
R9P9cb9Xep2nvWIryxQM02kERI9XZKuUMuCtUxoPY3vkr0Hju8ug/B81B6/sAL6F
j+/fCtjlDfNguHFFrQtoZpjuRqh/TF4RAvtuKjP+KiW4u2oYIR6DrCj1y0Lpgpq0
e17zSlKlt46CVLACxw62i+rZEAew5CcMysuBrL1F/3fPFc45gxLp7ef+y/zg9V0W
uVvh9oJE0fY/Wl6KvQgCeXXwdIxoo6v8eNFKPmnwEDQVlsqEcOGVKckd5BBMsf7w
5w7VwwcuMKR2eQLOGh2wULNhazPcvJBiMevjdDXOD2DjEF0bpN/B/cG7ANkMak1A
9dOhGUNK6PLyrrGGdajaJRaO/GwUtKyKuNzK+HvOCXLjA3Yjy4WhhnwDHQx35thw
yma6Z0JmAiX3xmvPcJZR
=syIJ
-END PGP SIGNATURE-

Re: [gentoo-user] QEMU/distcc combination question64-

[Neil Bothwick]

On 2 January 2016 11:56:58 GMT+00:00, Andrew Savchenko  
wrote:
> On Sat, 2 Jan 2016 10:42:31 + Neil Bothwick wrote:
> > On Fri, 1 Jan 2016 22:11:34 -0500, waltd...@waltdnes.org wrote:
> > 
> > >   I'm trying to run a distccserver in a 32-bit VM on a 64-bit
> host, for
> > > the benefit of my ancient 32-bit-only netbook.  Yeah, "it'll work"
> using
> > > the native 64-bit host OS.  But any stuff that links against
> 32-bit
> > > libraries is going to be sent back to the netbook to compile
> locally.
> > > That defeats the whole purpose of distcc.  This is why I want the
> 32-bit
> > > VM to compile for the 32-bit Atom.  Here's the launch script for
> the
> > > 32-bit VM on the i3 machine...
> > 
> > I used to take a different approach. Instead of a VM I used a chroot
> > that was a clone of the netbook, except that make.conf in the chroot
> > included buildpkg in FEATURES and the netbook's make.conf have
> --usepkg in
> > DEFAULT_OPTs. PKGDIR was an NFS share accessible to both.
> 
> Similar solution here, but instead of cloning, I NFS-mount root
> from slow system using filescached to speedup I/O process and
> placing all volatile data (/tmp, /var/tmp) either in local memory
> or on fast local storage. This way there is no need to make manual
> modifications twice or synchronize them somehow (e.g. when
> modification of package.use or package.license during update is
> needed).
> 
> I must warn that such approach should not be used for packages
> using build-time profiling, like sci-libs/atlas or any ebuild with
> USE="pgo" enabled; otherwise profiling will be wrong and targeted
> on helper system instead of target box. In such cases distcc may be
> used.
> 
> For 32-bit distcc on 64-bit host there is no need to chroot or
> create VM (hey, they're hellishly slow!). Just add -m32 to your
> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
> can be worked around on distcc server by forcing -m32 for each
> gcc call.
> 
> Best regards,
> Andrew Savchenko

I tried that too.  I stuck with containers because I  could have a script that 
rsynced /etc/portage with the slow machine and then entered the container and 
ran emerge @world. That script ran on the build host in the early hours,  after 
the host had run emerge - - sync, so by the time I crawled out of bed, all the 
packages were ready to install, without requiring the slow machines to even be 
running. 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] QEMU/distcc combination question64-

[Jc García]

2016-01-02 12:27 GMT-06:00  :
> On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote
>
>> For 32-bit distcc on 64-bit host there is no need to chroot or
>> create VM (hey, they're hellishly slow!). Just add -m32 to your
>> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
>> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
>> can be worked around on distcc server by forcing -m32 for each
>> gcc call.
>
>   -m32 in a 64-environment works for "Hello World".  More complex code
> that requires arch-specific headers and libs will have problems.
Then why the recently introuced  multilib method of bulding 32bit
libraries for packages that need it on 64 bit works? I don't think the
devs would have bothered to introudce the variable ABI_X86 and a
mulitib eclass just to compile a  32bit Hello World.

I'm not trying to make a flame here, but don't blame the compiler,
when in this case is more likely you the user are doing something
wrong.
My guess is you are blaming the effects of  CPU_FLAGS_X86 on CFLAGS.

Re: [gentoo-user] QEMU/distcc combination question64-

[waltdnes]

On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote

> For 32-bit distcc on 64-bit host there is no need to chroot or
> create VM (hey, they're hellishly slow!). Just add -m32 to your
> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
> can be worked around on distcc server by forcing -m32 for each
> gcc call.

  -m32 in a 64-environment works for "Hello World".  More complex code
that requires arch-specific headers and libs will have problems.  It
"works" with Gentoo distcc.  Rather than erroring out, it sends the work
back to my Atom netbook, and says "Sorry, you have to do this yourself".
This defeats the point of distcc.  Outside of Gentoo distcc, the errors
stop the build.  So yes, I do need a 32-bit environment.

  I ran into this, trying to manually build Pale Moon (a Firefox fork)
for my Atom netbook from a 64-bit environment.  It doesn't work.
Mozilla and its derivatives all use the same weird build scripts.
See...https://forum.palemoon.org/viewtopic.php?f=37=10002

  I eventually re-installed 32-bit Gentoo on my ancient Core2 machine.
Since it only has 3 gigs of RAM, it's not losing anything.  It
successfully built the Atom-specific branch (a bunch of "web-developer"
stuff removed) for my netbook.  My netbook is actually "-march=bonnell"
https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29
I selected that instead of the generic "-march=atom".

  By the way, Atom-specific-source Pale Moon builds are really snappy on
a newer machine when built with "-march=native".  On the other hand, the
Firefox developers have utterly gone off the deep end.  The
Atrocious^H^H^H^H^H^H^H^H^H Australis GUI was the final straw that drove
me away.

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

Re: [gentoo-user] QEMU/distcc combination question64-

[waltdnes]

On Sat, Jan 02, 2016 at 12:55:56PM -0600, Jc García wrote

> Then why the recently introuced  multilib method of bulding 32bit
> libraries for packages that need it on 64 bit works? I don't think the
> devs would have bothered to introudce the variable ABI_X86 and a
> mulitib eclass just to compile a  32bit Hello World.
> 
> I'm not trying to make a flame here, but don't blame the compiler,
> when in this case is more likely you the user are doing something
> wrong.
> My guess is you are blaming the effects of  CPU_FLAGS_X86 on CFLAGS.

  The fact that I use "no-multilib" profiles on my 64-bit machines
probably doesn't help.  The example I was using involved a manual build
of Pale Moon from source.  I manually specified in the build script...

ac_add_options --enable-optimize="-O2 -march=bonnell -mfpmath=sse -pipe \
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables \
-mmmx -msse -msse2 -mssse3 -mmovbe -mfxsr"

...which are the options I use on my netbook client for outsourcing the
build process.  So the host's CPU_FLAGS_X86 setting should not be a
problem.

  I'd love to be proven wrong in my contention.  If you can run the
Mozilla-like build on a 64-bit OS, and produce a 32-bit binary, that's
the ultimate "torture-test".

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

[gentoo-user] Re: Splitting large audio files into tracks

[Grant Edwards]

On 2016-01-02, Alan McKinnon  wrote:

> I have quite a few large audio rip files that need to be split up
> into their respective tracks.
[...]
> I very seldom work with audio files directly, so I'm mostly clueless
> in this area and it's easier to ask folks who do this often what
> packages out there are good at it.

I have only done it a few times, but I used audacity.  It also allowed
me to mix the two channels down to one (it was an audio book, and
mixing the two channles reduced the tape hiss a little).

> Bonus points for packages that use musicbrainz or similar

Not sure how an an audio editor would use something like that.  After
you use something like audacity (or just plain sox commands) to split
the file into tracks, you'll have to use a separate program to set the
MP3 tags.

-- 
Grant

[gentoo-user] Splitting large audio files into tracks

[Alan McKinnon]

Hi all,

I have quite a few large audio rip files that need to be split up into
their respective tracks. They were wrongly ripped back when and the
original CDs aren't available anymore.

I very seldom work with audio files directly, so I'm mostly clueless in
this area and it's easier to ask folks who do this often what packages
out there are good at it.

Bonus points for packages that use musicbrainz or similar


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: Splitting large audio files into tracks

[Alan McKinnon]

On 02/01/2016 23:42, Grant Edwards wrote:
> On 2016-01-02, Alan McKinnon  wrote:
> 
>> I have quite a few large audio rip files that need to be split up
>> into their respective tracks.
> [...]
>> I very seldom work with audio files directly, so I'm mostly clueless
>> in this area and it's easier to ask folks who do this often what
>> packages out there are good at it.
> 
> I have only done it a few times, but I used audacity.  It also allowed
> me to mix the two channels down to one (it was an audio book, and
> mixing the two channles reduced the tape hiss a little).

Good to know, I'll give is a try

> 
>> Bonus points for packages that use musicbrainz or similar
> 
> Not sure how an an audio editor would use something like that.  After
> you use something like audacity (or just plain sox commands) to split
> the file into tracks, you'll have to use a separate program to set the
> MP3 tags.


I'm thinking that musicbrainz knows the tracks and how long they are. If
I supply the exact correct release, and editor could do the splitting at
the correct point (so I don't have to guess)

If the editor can't update the metadata, then beets can.

-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Re: QEMU/distcc combination question64-

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/02/2016 01:27 PM, waltd...@waltdnes.org wrote:
> On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote
> 
>> For 32-bit distcc on 64-bit host there is no need to chroot or 
>> create VM (hey, they're hellishly slow!). Just add -m32 to your 
>> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores 
>> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this 
>> can be worked around on distcc server by forcing -m32 for each 
>> gcc call.
> 
> -m32 in a 64-environment works for "Hello World".  More complex
> code that requires arch-specific headers and libs will have
> problems.  It "works" with Gentoo distcc.  Rather than erroring
> out, it sends the work back to my Atom netbook, and says "Sorry,
> you have to do this yourself". This defeats the point of distcc.
> Outside of Gentoo distcc, the errors stop the build.  So yes, I do
> need a 32-bit environment.
> 
> I ran into this, trying to manually build Pale Moon (a Firefox
> fork) for my Atom netbook from a 64-bit environment.  It doesn't
> work. Mozilla and its derivatives all use the same weird build
> scripts. See...
> https://forum.palemoon.org/viewtopic.php?f=37=10002
> 
> I eventually re-installed 32-bit Gentoo on my ancient Core2
> machine. Since it only has 3 gigs of RAM, it's not losing anything.
> It successfully built the Atom-specific branch (a bunch of
> "web-developer" stuff removed) for my netbook.  My netbook is
> actually "-march=bonnell" 
> https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29 I
> selected that instead of the generic "-march=atom".
> 
> By the way, Atom-specific-source Pale Moon builds are really snappy
> on a newer machine when built with "-march=native".  On the other
> hand, the Firefox developers have utterly gone off the deep end.
> The Atrocious^H^H^H^H^H^H^H^H^H Australis GUI was the final straw
> that drove me away.
> 


I think that you misunderstand how distcc works.  The distcc process
*only* sends preprocessed data to the remote machine, and *only* gets
back object code.  All preprocessing (headers) and linking (libraries,
combining *.o files) is *always* done on the host that the packages
will be used on, because slightly different versions would otherwise
cause problems.  So your problem with "arch-specific headers and
libraries" *always* causes that part to run on the netbook, even if
the remote distcc server is exactly the same arch, etc.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWiFzXAAoJEEIQbvYRB3mgwZIP/1bb2cJ5d5DselrzYQd48wXJ
LnftAoBgUtYjc866EYPMYJchW+xQtrSJzuHEPuWDjiwIbgRA7zQzHCYRwJWNXrry
iZPVKaxnTumU/ttUZHZHiBtga5HULwAPkSwCBPrFpFYXuvghNuGIG4Kdz+8a18Ef
hFIbY/qRIXJgNq8bIekoOY7ED1/27mPcNW1BReJoCOo+oTPp6QqbE/nZ+rDtQPBi
Gx8jtJptaHtQ7kCN4ddDfgYQry0/yU5QaScLwzExDXAIAw3I14ecMMu8AtSpacPx
UZ5HOb/iuV4tUcB5yEhbasFAgs7i36Cr0WtcbFZ4XaUA6m92ldwiQrAMMRMT3Vxm
X5Hemtckw9feFxvJw5SEupLbWTG13LZ/pZK03o8DgJIVaEkZcis6RhBZZCwZzuDq
erX3xcsS+vHRrIrZKIbA7Fwc3ronbToH45EcXfdobMLlUp5wx1W2lB1WcS/a8WtJ
L5+c3GmKbjg6HAarZ3kWTHhr0X20J8SLkx2pwUYn7kX6bZEgHpIsyb6I+2ZHkfq4
K1Jc96WVfFwQSu77TPhURUcFMPXlv1zjKnTtwesgLvSVxKSq5wZu/295dkmqeuyg
of2w5wrWaq7DZCPkNVemtknVXeFgAUglkpr9M4DWG8DN4vTlN5naG8D3XPxprT3B
KJCTrSGYoRe/V6Fk/pJ/
=mMUw
-END PGP SIGNATURE-

Re: [gentoo-user] QEMU/distcc combination question64-

[Jc García]

2016-01-02 22:31 GMT-06:00 Jc García :

> I serve the binpkg host from my
> desktop to my LAN with nginx but I'm considering git from the booted
> container
Correction:
* I'm considering doing it from the booted container

Re: [gentoo-user] Re: QEMU/distcc combination question64-

[wabenbau]

Jonathan Callen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 01/02/2016 01:27 PM, waltd...@waltdnes.org wrote:
> > On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote
> > 
> >> For 32-bit distcc on 64-bit host there is no need to chroot or 
> >> create VM (hey, they're hellishly slow!). Just add -m32 to your 
> >> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores 
> >> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this 
> >> can be worked around on distcc server by forcing -m32 for each 
> >> gcc call.
> > 
> > -m32 in a 64-environment works for "Hello World".  More complex
> > code that requires arch-specific headers and libs will have
> > problems.  It "works" with Gentoo distcc.  Rather than erroring
> > out, it sends the work back to my Atom netbook, and says "Sorry,
> > you have to do this yourself". This defeats the point of distcc.
> > Outside of Gentoo distcc, the errors stop the build.  So yes, I do
> > need a 32-bit environment.
> > 
> > I ran into this, trying to manually build Pale Moon (a Firefox
> > fork) for my Atom netbook from a 64-bit environment.  It doesn't
> > work. Mozilla and its derivatives all use the same weird build
> > scripts. See...
> > https://forum.palemoon.org/viewtopic.php?f=37=10002
> > 
> > I eventually re-installed 32-bit Gentoo on my ancient Core2
> > machine. Since it only has 3 gigs of RAM, it's not losing anything.
> > It successfully built the Atom-specific branch (a bunch of
> > "web-developer" stuff removed) for my netbook.  My netbook is
> > actually "-march=bonnell" 
> > https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29 I
> > selected that instead of the generic "-march=atom".
> > 
> > By the way, Atom-specific-source Pale Moon builds are really snappy
> > on a newer machine when built with "-march=native".  On the other
> > hand, the Firefox developers have utterly gone off the deep end.
> > The Atrocious^H^H^H^H^H^H^H^H^H Australis GUI was the final straw
> > that drove me away.
> > 
> 
> 
> I think that you misunderstand how distcc works.  The distcc process
> *only* sends preprocessed data to the remote machine, and *only* gets
> back object code.  All preprocessing (headers) and linking (libraries,
> combining *.o files) is *always* done on the host that the packages
> will be used on, because slightly different versions would otherwise
> cause problems.  So your problem with "arch-specific headers and
> libraries" *always* causes that part to run on the netbook, even if
> the remote distcc server is exactly the same arch, etc.

When you use distcc pump mode then also the preprocessing is done by 
the remote servers. This will cause problems when the include files on 
client and servers are not identical.

--
Regards
wabe

Re: [gentoo-user] QEMU/distcc combination question64-

[Jc García]

2016-01-02 14:25 GMT-06:00  :
> On Sat, Jan 02, 2016 at 12:55:56PM -0600, Jc García wrote
>
>> Then why the recently introuced  multilib method of bulding 32bit
>> libraries for packages that need it on 64 bit works? I don't think the
>> devs would have bothered to introudce the variable ABI_X86 and a
>> mulitib eclass just to compile a  32bit Hello World.
>>
>> I'm not trying to make a flame here, but don't blame the compiler,
>> when in this case is more likely you the user are doing something
>> wrong.
>> My guess is you are blaming the effects of  CPU_FLAGS_X86 on CFLAGS.
>
>   The fact that I use "no-multilib" profiles on my 64-bit machines
> probably doesn't help.  The example I was using involved a manual build
> of Pale Moon from source.  I manually specified in the build script...
>
> ac_add_options --enable-optimize="-O2 -march=bonnell -mfpmath=sse -pipe \
> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables \
> -mmmx -msse -msse2 -mssse3 -mmovbe -mfxsr"
>
> ...which are the options I use on my netbook client for outsourcing the
> build process.  So the host's CPU_FLAGS_X86 setting should not be a
> problem.
>
A bit unrelated to the thread, but not really as a solution, here's my
experience:
I use Gentoo on a netbook too, but I'm not using distcc, it won't help
much anyway, my approach is to make a 32 bit container(using
systemd-nspawn for the sake of booting it fot testing, but chroot can
get it done) and make sure to have the same world and /etc/portage/ in
both,  with the only difference that the container has
FEATURES="buildpkg", and the netbook has FEATURES="getbinpkg", I use
git to keep the changes in sync,  and source make.local.conf (ignored
by git) on each the container). I serve the binpkg host from my
desktop to my LAN with nginx but I'm considering git from the booted
container. I also mount $PORTDIR via NFS to have the same tree(
bandwidth is expensive for me, and I also don't want to have tons of
portage tree's around as I use the same method for another amd64 pc
with an older processor, that has only 2 threads)

PD: The next step is to make the upgrades be handled by ansible but I
haven't sat down to make it happen.