Re: [gentoo-user] preparing for profile switch -- major problem

[John Covici]

On Sat, 09 Dec 2017 18:20:40 -0500,
Daniel Frey wrote:
> 
> On 12/09/17 08:18, John Covici wrote:
> > On Sat, 09 Dec 2017 10:28:25 -0500,
> > Daniel Frey wrote:
> >> 
> >> I had a lot of problems with the perl updates as well, and could
> >> not get it to resolve. I wasted over an hour trying to resolve it
> >> (my poor Celeron would take 5-10 minutes trying to calculate
> >> dependencies, and I had to do this 6-7 times.)
> >> 
> >> Note, what I did worked for me and may not work for you, so use
> >> this advice at your own risk: I emerged the new perl with
> >> --nodeps, and invoked `perl-cleaner all` to fix the mess
> >> afterwards. It had everything resolved in < 10 minutes. I didn't
> >> suffer any system breakage from using the sledgehammer approach,
> >> but others may not be so lucky... so, as I said, try it at your
> >> own risk.
> > 
> > I was thinking of just that myself, I may try that  later today.  I am
> > using zfs, and do snapshots frequently, so it might be possible to get
> > back if things are a disaster, but it might work at that.   Did you
> > emerge perl again without the --nodeps afterwards to make sure?
> > 
> > 
> 
> Well, due to the long compile times I was trying to get the
> dependencies resolved so I could run `emerge -auDNe world
> --exclude sys-devel/gcc --exclude sys-devel/llvm --exclude
> sys-devel/libtool --exclude sys-devel/binutils --exclude
> sys-libs/glibc --keep-going world` so it would recompile
> everything and update as it went along. (I had already built the
> excluded packages under the new profile with gcc6.)
> 
> While I didn't remerge perl immediately after, it was included in
> the rebuild process of --emptytree.
> 
> And it was successful! I only had perl blocking everything, so
> once I sledgeammered that update, it was able to calculate its
> dependency list, and it rebuilt all 500 installed packages (well,
> less the ones I excluded) successfully - no failed packages or
> anything, while upgrading as needed. It did take almost 30 hours
> though.
> 
> When trying to get perl blockers to resolve I even tried
> --backtrack=200 and it still failed. That was try 5 or 6 and at
> that point I was getting annoyed and tried the sledgehammer
> technique.

OK, thanks, I think I will try that.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

[gentoo-user] Make failed to compile: symbol __alloca not found...

[tuxic]

Hi,

sys-devel/make-4.2.1-r1 failed to compile with this:

x86_64-pc-linux-gnu-gcc -DLOCALEDIR=\"/usr/share/locale\" 
-DLIBDIR=\"/usr/lib64\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I.  
-I./glob-march=native -O2 -pipe -c -o vpath.o vpath.c
x86_64-pc-linux-gnu-gcc -DLOCALEDIR=\"/usr/share/locale\" 
-DLIBDIR=\"/usr/lib64\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I.  
-I./glob-march=native -O2 -pipe -c -o hash.o hash.c
x86_64-pc-linux-gnu-gcc -DLOCALEDIR=\"/usr/share/locale\" 
-DLIBDIR=\"/usr/lib64\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I.  
-I./glob-march=native -O2 -pipe -c -o remote-stub.o remote-stub.c
x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -Wl,--export-dynamic -Wl,-O1 
-Wl,--as-needed -o make ar.o arscan.o commands.o default.o dir.o expand.o 
file.o function.o getopt.o getopt1.o guile.o implicit.o job.o load.o loadapi.o 
main.o misc.o posixos.o output.o read.o remake.o rule.o signame.o strcache.o 
variable.o version.o vpath.o hash.o remote-stub.o glob/libglob.a   -ldl 
glob/libglob.a(glob.o): In function `glob_in_dir':
glob.c:(.text+0x2ed): undefined reference to `__alloca'
glob.c:(.text+0x46e): undefined reference to `__alloca'
glob.c:(.text+0x628): undefined reference to `__alloca'
glob.c:(.text+0x680): undefined reference to `__alloca'
glob/libglob.a(glob.o): In function `glob':
glob.c:(.text+0x99b): undefined reference to `__alloca'
glob/libglob.a(glob.o):glob.c:(.text+0x104a): more undefined references to 
`__alloca' follow
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:656: make] Error 1
make[2]: Leaving directory 
'/var/tmp/portage/sys-devel/make-4.2.1-r1/work/make-4.2.1'
make[1]: *** [Makefile:798: all-recursive] Error 1
make[1]: Leaving directory 
'/var/tmp/portage/sys-devel/make-4.2.1-r1/work/make-4.2.1'
make: *** [Makefile:534: all] Error 2
 * ERROR: sys-devel/make-4.2.1-r1::gentoo failed (compile phase):
 *   emake failed


Online I found articles which explain, why it is not recommended to
use alloca() at all:
RETURN VALUE The alloca() function returns a pointer to the beginning of the 
allocated space. If the allocation causes stack overflow, program behaviour is 
undefined.
(https://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-considered-good-practice)

How can I recompile make -- it is still non-PIE and one of those
application which I cant convince to be friendly to gcc :)

How serious is this alloca-thingy at all?

Cheers
Meino

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[R0b0t1]

On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey  wrote:
> On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
>> On Sat, Dec 9, 2017 at 10:45 AM, Mick  wrote:
>> > Thank you all for detailed and clear replies.  You'd forgive me for
>> > being (a little) paranoid about Poettering's fingers getting anywhere
>> > near my systems.>
>> > :-p
>>
>> Are you sure you need udisks? And policykit?
>
> I'm pretty sure Mick runs KDE, which requires both of those.
>

Eventually emerging @world will just pull in the entirety of the
Gentoo package repository, and we won't have to worry about what is or
isn't necessary.

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Peter Humphrey]

On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
> On Sat, Dec 9, 2017 at 10:45 AM, Mick  wrote:
> > Thank you all for detailed and clear replies.  You'd forgive me for
> > being (a little) paranoid about Poettering's fingers getting anywhere
> > near my systems.> 
> > :-p
> 
> Are you sure you need udisks? And policykit?

I'm pretty sure Mick runs KDE, which requires both of those.

-- 
Regards,
Peter.

Re: [gentoo-user] OT: btrfs raid 5/6

[Rich Freeman]

On Sat, Dec 9, 2017 at 1:28 PM, Wols Lists  wrote:
> On 09/12/17 16:58, J. Roeleveld wrote:
>> On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote:
>>> On 07/12/17 22:35, Frank Steinmetzger wrote:
> (Oh - and md raid-5/6 also mix data and parity, so the same holds true
>
>> there.)

 Ok, wasn’t aware of that. I thought I read in a ZFS article that this were
 a special thing.
>>>
>>> Say you've got a four-drive raid-6, it'll be something like
>>>
>>> data1   data2   parity1 parity2
>>> data3   parity3 parity4 data4
>>> parity5 parity6 data5   data6
>>>
>>> The only thing to watch out for (and zfs is likely the same) if a file
>>> fits inside a single chunk it will be recoverable from a single drive.
>>> And I think chunks can be anything up to 64MB.
>>
>> Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you 
>> use
>> compression)
>>
>> See:
>> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
>>
> Which explains nothing, sorry ... :-(
>
> It goes on about 4K or 8K database blocks (and I'm talking about 64 MEG
> chunk sizes). And the OP was talking about files being recoverable from
> a disk that was removed from an array. Are you telling me that a *small*
> file has bits of it scattered across multiple drives? That would be *crazy*.

I'm not sure why it would be "crazy."  Granted, most parity RAID
systems seem to operate just as you describe, but I don't see why with
Reed Solomon you couldn't store ONLY parity data on all the drives.
All that matters is that you generate enough to recover the data - the
original data contains no more information than an equivalent number
of Reed-Solomon sets.  Of course, with the original data I imagine you
need to do less computation assuming you aren't bothering to check its
integrity against the parity data.

In case my point is clear a RAID would work perfectly fine if you had
5 drives with the capacity to store 4 drives wort of data, but instead
of storing the original data across 4 drives and having 1 of parity,
you instead compute 5 sets of parity so that now you have 9 sets of
data that can tolerate the loss of any 5, then throw away the sets
containing the original 4 sets of data and store the remaining 5 sets
of parity data across the 5 drives.  You can still tolerate the loss
of one more set, but all 4 of the original sets of data have been
tossed already.


-- 
Rich

Re: [gentoo-user] Re: Again, emerge -e @world related questions...

[Michael Orlitzky]

On 12/08/2017 09:53 AM, Melleus wrote:
> I had moved to v 17.0 profile mostly painless, though it was a time
> consuming event. But I got one point anyway. Python in my system was
> updated from 3.4 to 3.5 and after 3.4 was removed with depclean, the
> option for v 3.4 in eselect python remains. It looks a bit weird to me
> when I can choose with eselect the version of python that is not
> currently present in the system. Is this intended behavior?

Guessing: no. (What happens if you select it?)

There might be some python-3.4 stuff left on your system that tricks
eselect into thinking that python-3.4 is installed. For example, in
eselect-php we do,

  find_targets() {
cd "@LIBDIR@" && echo php*.*
  }

and that is easily fooled by creating any file in /usr/lib/php-x.y.

You might have to dig through eselect-python to see how it works, or ask
somebody who knows.

Re: [gentoo-user] preparing for profile switch -- major problem

[Peter Humphrey]

On Saturday, 9 December 2017 23:20:40 GMT Daniel Frey wrote:

> I was trying to get the dependencies resolved so I could run
> `emerge - auDNe world ...

Really? Specifying -e overrules -uDN and makes them superfluous. Why would 
you want to do that?

-- 
Regards,
Peter.

Re: [gentoo-user] preparing for profile switch -- major problem

[Daniel Frey]

On 12/09/17 08:18, John Covici wrote:

On Sat, 09 Dec 2017 10:28:25 -0500,
Daniel Frey wrote:


I had a lot of problems with the perl updates as well, and could
not get it to resolve. I wasted over an hour trying to resolve it
(my poor Celeron would take 5-10 minutes trying to calculate
dependencies, and I had to do this 6-7 times.)

Note, what I did worked for me and may not work for you, so use
this advice at your own risk: I emerged the new perl with
--nodeps, and invoked `perl-cleaner all` to fix the mess
afterwards. It had everything resolved in < 10 minutes. I didn't
suffer any system breakage from using the sledgehammer approach,
but others may not be so lucky... so, as I said, try it at your
own risk.


I was thinking of just that myself, I may try that  later today.  I am
using zfs, and do snapshots frequently, so it might be possible to get
back if things are a disaster, but it might work at that.   Did you
emerge perl again without the --nodeps afterwards to make sure?




Well, due to the long compile times I was trying to get the dependencies 
resolved so I could run `emerge -auDNe world --exclude sys-devel/gcc 
--exclude sys-devel/llvm --exclude sys-devel/libtool --exclude 
sys-devel/binutils --exclude sys-libs/glibc --keep-going world` so it 
would recompile everything and update as it went along. (I had already 
built the excluded packages under the new profile with gcc6.)


While I didn't remerge perl immediately after, it was included in the 
rebuild process of --emptytree.


And it was successful! I only had perl blocking everything, so once I 
sledgeammered that update, it was able to calculate its dependency list, 
and it rebuilt all 500 installed packages (well, less the ones I 
excluded) successfully - no failed packages or anything, while upgrading 
as needed. It did take almost 30 hours though.


When trying to get perl blockers to resolve I even tried --backtrack=200 
and it still failed. That was try 5 or 6 and at that point I was getting 
annoyed and tried the sledgehammer technique.


Dan

Re: [gentoo-user] OT: btrfs raid 5/6

[Wols Lists]

On 09/12/17 16:58, J. Roeleveld wrote:
> On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote:
>> On 07/12/17 22:35, Frank Steinmetzger wrote:
 (Oh - and md raid-5/6 also mix data and parity, so the same holds true

> there.)
>>>
>>> Ok, wasn’t aware of that. I thought I read in a ZFS article that this were
>>> a special thing.
>>
>> Say you've got a four-drive raid-6, it'll be something like
>>
>> data1   data2   parity1 parity2
>> data3   parity3 parity4 data4
>> parity5 parity6 data5   data6
>>
>> The only thing to watch out for (and zfs is likely the same) if a file
>> fits inside a single chunk it will be recoverable from a single drive.
>> And I think chunks can be anything up to 64MB.
> 
> Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you 
> use 
> compression)
> 
> See:
> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
> 
Which explains nothing, sorry ... :-(

It goes on about 4K or 8K database blocks (and I'm talking about 64 MEG
chunk sizes). And the OP was talking about files being recoverable from
a disk that was removed from an array. Are you telling me that a *small*
file has bits of it scattered across multiple drives? That would be *crazy*.

If I have a file of, say, 10MB, and write it to an md-raid array, there
is a good chance it will fit inside a single chunk, and be written -
*whole* - to a single disk. With parity on another disk. How big does a
file have to be on ZFS before it is too big to fit in a typical chunk,
so that it gets split up across multiple drives?

THAT is what I was on about, and that is what concerned the OP. I was
just warning the OP that a chunk typically is rather more than just one
disk block, so anybody harking back to the days of 512byte sectors could
get a nasty surprise ...

Cheers,
Wol

Cheers,
Wol

Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd

[tuxic]

On 12/09 12:04, Mike Gilbert wrote:
> On Sat, Dec 9, 2017 at 11:54 AM,   wrote:
> > On 12/09 06:27, Alexander Kapshuk wrote:
> >> On Sat, Dec 9, 2017 at 6:03 PM,   wrote:
> >> > Hi,
> >> >
> >> > autofs-5.1.3 fails to compile:
> >> > solfire:/root>emerge -v autofs
> >> >
> >> > These are the packages that would be merged, in order:
> >> >
> >> > Calculating dependencies... done!
> >> > [ebuild   R] net-fs/autofs-5.1.3::gentoo  USE="libtirpc -dmalloc 
> >> > -hesiod -ldap -mount-locking -sasl" 0 KiB
> >> >
> >> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> >> >
> >>  Verifying ebuild manifests
> >>  Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo
> >>  Failed to emerge net-fs/autofs-5.1.3, Log file:
> >>   '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log'
> >>  Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 
> >>  0.88
> >> >  * Package:net-fs/autofs-5.1.3
> >> >  * Repository: gentoo
> >> >  * Maintainer: d...@gentoo.org
> >> >  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc 
> >> > userland_GNU
> >> >  * FEATURES:   preserve-libs sandbox userpriv usersandbox
> >> >  * Determining the location of the kernel source code
> >> >  * Found kernel source directory:
> >> >  * /usr/src/linux
> >> >  * Found sources for kernel version:
> >> >  * 4.14.4-RT
> >> >  * Checking for suitable kernel configuration options...
> >> >  [ ok ]
> >>  Unpacking source...
> >>  Unpacking autofs-5.1.3.tar.xz to 
> >>  /var/tmp/portage/net-fs/autofs-5.1.3/work
> >>  Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work
> >>  Preparing source in 
> >>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
> >> >  * Running eautoreconf in 
> >> > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ...
> >> >  * This package has a configure.in file which has long been deprecated.  
> >> > Please
> >> >  * update it to use configure.ac instead as newer versions of autotools 
> >> > will die
> >> >  * when it finds this file.  See https://bugs.gentoo.org/426262 for 
> >> > details.
> >> >  * Running autoconf --force ...
> >> >  [ ok ]
> >> >  * Running autoheader ...
> >> >  [ ok ]
> >> >  * Running elibtoolize in: autofs-5.1.3/
> >>  Source prepared.
> >>  Configuring source in 
> >>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
> >>  Working in BUILD_DIR: 
> >>  "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3"
> >> > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure 
> >> > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> >> > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
> >> > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 
> >> > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d 
> >> > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap 
> >> > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking 
> >> > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown 
> >> > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system 
> >> > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib
> >> > configure: loading site script /usr/share/config.site
> >> > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin
> >> > checking for Linux proc filesystem... yes
> >> > checking location of the init.d directory... /etc/init.d
> >> > checking for autofs configuration file directory... /etc/conf.d
> >> > checking for autofs maps directory... /etc/autofs
> >> > checking for autofs fifos directory... /run
> >> > checking for autofs flag file directory... /run
> >> > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
> >> > checking whether the C compiler works... yes
> >> > checking for C compiler default output file name... a.out
> >> > checking for suffix of executables...
> >> > checking whether we are cross compiling... no
> >> > checking for suffix of object files... o
> >> > checking whether we are using the GNU C compiler... yes
> >> > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
> >> > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none 
> >> > needed
> >> > checking if libtirpc is requested and available... yes
> >> > checking for getrpcbyname... yes
> >> > checking for getservbyname... yes
> >> > checking if malloc debugging is wanted... no
> >> > checking for mount... /bin/mount
> >> > checking for mount.nfs... /sbin/mount.nfs
> >> > checking for umount... /bin/umount
> >> > checking for fsck.ext2... /sbin/fsck.ext2
> >> > checking for fsck.ext3... /sbin/fsck.ext3
> >> > checking for fsck.ext4... /sbin/fsck.ext4
> >> > checking for modprobe... /sbin/modprobe
> >> > checking for flex... /usr/bin/flex
> >> > checking for bison... /usr/bin/bison
> >> > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib
> >> > checking for rpcgen... no
> >> > 

Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd

[Mike Gilbert]

On Sat, Dec 9, 2017 at 11:54 AM,   wrote:
> On 12/09 06:27, Alexander Kapshuk wrote:
>> On Sat, Dec 9, 2017 at 6:03 PM,   wrote:
>> > Hi,
>> >
>> > autofs-5.1.3 fails to compile:
>> > solfire:/root>emerge -v autofs
>> >
>> > These are the packages that would be merged, in order:
>> >
>> > Calculating dependencies... done!
>> > [ebuild   R] net-fs/autofs-5.1.3::gentoo  USE="libtirpc -dmalloc 
>> > -hesiod -ldap -mount-locking -sasl" 0 KiB
>> >
>> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>> >
>>  Verifying ebuild manifests
>>  Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo
>>  Failed to emerge net-fs/autofs-5.1.3, Log file:
>>   '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log'
>>  Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 
>>  0.88
>> >  * Package:net-fs/autofs-5.1.3
>> >  * Repository: gentoo
>> >  * Maintainer: d...@gentoo.org
>> >  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc 
>> > userland_GNU
>> >  * FEATURES:   preserve-libs sandbox userpriv usersandbox
>> >  * Determining the location of the kernel source code
>> >  * Found kernel source directory:
>> >  * /usr/src/linux
>> >  * Found sources for kernel version:
>> >  * 4.14.4-RT
>> >  * Checking for suitable kernel configuration options...
>> >  [ ok ]
>>  Unpacking source...
>>  Unpacking autofs-5.1.3.tar.xz to 
>>  /var/tmp/portage/net-fs/autofs-5.1.3/work
>>  Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work
>>  Preparing source in 
>>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
>> >  * Running eautoreconf in 
>> > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ...
>> >  * This package has a configure.in file which has long been deprecated.  
>> > Please
>> >  * update it to use configure.ac instead as newer versions of autotools 
>> > will die
>> >  * when it finds this file.  See https://bugs.gentoo.org/426262 for 
>> > details.
>> >  * Running autoconf --force ...
>> >  [ ok ]
>> >  * Running autoheader ...
>> >  [ ok ]
>> >  * Running elibtoolize in: autofs-5.1.3/
>>  Source prepared.
>>  Configuring source in 
>>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
>>  Working in BUILD_DIR: 
>>  "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3"
>> > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure 
>> > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
>> > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
>> > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 
>> > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d 
>> > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap 
>> > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking 
>> > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown 
>> > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system 
>> > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib
>> > configure: loading site script /usr/share/config.site
>> > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin
>> > checking for Linux proc filesystem... yes
>> > checking location of the init.d directory... /etc/init.d
>> > checking for autofs configuration file directory... /etc/conf.d
>> > checking for autofs maps directory... /etc/autofs
>> > checking for autofs fifos directory... /run
>> > checking for autofs flag file directory... /run
>> > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
>> > checking whether the C compiler works... yes
>> > checking for C compiler default output file name... a.out
>> > checking for suffix of executables...
>> > checking whether we are cross compiling... no
>> > checking for suffix of object files... o
>> > checking whether we are using the GNU C compiler... yes
>> > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
>> > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none 
>> > needed
>> > checking if libtirpc is requested and available... yes
>> > checking for getrpcbyname... yes
>> > checking for getservbyname... yes
>> > checking if malloc debugging is wanted... no
>> > checking for mount... /bin/mount
>> > checking for mount.nfs... /sbin/mount.nfs
>> > checking for umount... /bin/umount
>> > checking for fsck.ext2... /sbin/fsck.ext2
>> > checking for fsck.ext3... /sbin/fsck.ext3
>> > checking for fsck.ext4... /sbin/fsck.ext4
>> > checking for modprobe... /sbin/modprobe
>> > checking for flex... /usr/bin/flex
>> > checking for bison... /usr/bin/bison
>> > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib
>> > checking for rpcgen... no
>> > configure: error: required program RPCGEN not found
>> >
>> >
>> >
>> > configure misses rpcgen...and seems not to evaluate the USE of
>> > libtirpc.
>> >
>> > I didn't find any fix/patch online.
>> >
>> > What goes wrong here?
>> >
>> > Cheers
>> 

Re: [gentoo-user] OT: btrfs raid 5/6

[J. Roeleveld]

On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote:
> On 07/12/17 22:35, Frank Steinmetzger wrote:
> >> (Oh - and md raid-5/6 also mix data and parity, so the same holds true
> >> 
> >> > there.)
> > 
> > Ok, wasn’t aware of that. I thought I read in a ZFS article that this were
> > a special thing.
> 
> Say you've got a four-drive raid-6, it'll be something like
> 
> data1   data2   parity1 parity2
> data3   parity3 parity4 data4
> parity5 parity6 data5   data6
> 
> The only thing to watch out for (and zfs is likely the same) if a file
> fits inside a single chunk it will be recoverable from a single drive.
> And I think chunks can be anything up to 64MB.

Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you use 
compression)

See:
https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz

--
Joost

Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd

[tuxic]

On 12/09 06:27, Alexander Kapshuk wrote:
> On Sat, Dec 9, 2017 at 6:03 PM,   wrote:
> > Hi,
> >
> > autofs-5.1.3 fails to compile:
> > solfire:/root>emerge -v autofs
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild   R] net-fs/autofs-5.1.3::gentoo  USE="libtirpc -dmalloc 
> > -hesiod -ldap -mount-locking -sasl" 0 KiB
> >
> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> >
>  Verifying ebuild manifests
>  Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo
>  Failed to emerge net-fs/autofs-5.1.3, Log file:
>   '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log'
>  Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 
>  0.88
> >  * Package:net-fs/autofs-5.1.3
> >  * Repository: gentoo
> >  * Maintainer: d...@gentoo.org
> >  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc 
> > userland_GNU
> >  * FEATURES:   preserve-libs sandbox userpriv usersandbox
> >  * Determining the location of the kernel source code
> >  * Found kernel source directory:
> >  * /usr/src/linux
> >  * Found sources for kernel version:
> >  * 4.14.4-RT
> >  * Checking for suitable kernel configuration options...
> >  [ ok ]
>  Unpacking source...
>  Unpacking autofs-5.1.3.tar.xz to 
>  /var/tmp/portage/net-fs/autofs-5.1.3/work
>  Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work
>  Preparing source in 
>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
> >  * Running eautoreconf in 
> > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ...
> >  * This package has a configure.in file which has long been deprecated.  
> > Please
> >  * update it to use configure.ac instead as newer versions of autotools 
> > will die
> >  * when it finds this file.  See https://bugs.gentoo.org/426262 for details.
> >  * Running autoconf --force ...
> >  [ ok ]
> >  * Running autoheader ...
> >  [ ok ]
> >  * Running elibtoolize in: autofs-5.1.3/
>  Source prepared.
>  Configuring source in 
>  /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
>  Working in BUILD_DIR: 
>  "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3"
> > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure 
> > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
> > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 
> > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d 
> > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap 
> > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking 
> > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown 
> > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system 
> > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib
> > configure: loading site script /usr/share/config.site
> > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin
> > checking for Linux proc filesystem... yes
> > checking location of the init.d directory... /etc/init.d
> > checking for autofs configuration file directory... /etc/conf.d
> > checking for autofs maps directory... /etc/autofs
> > checking for autofs fifos directory... /run
> > checking for autofs flag file directory... /run
> > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... no
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
> > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
> > checking if libtirpc is requested and available... yes
> > checking for getrpcbyname... yes
> > checking for getservbyname... yes
> > checking if malloc debugging is wanted... no
> > checking for mount... /bin/mount
> > checking for mount.nfs... /sbin/mount.nfs
> > checking for umount... /bin/umount
> > checking for fsck.ext2... /sbin/fsck.ext2
> > checking for fsck.ext3... /sbin/fsck.ext3
> > checking for fsck.ext4... /sbin/fsck.ext4
> > checking for modprobe... /sbin/modprobe
> > checking for flex... /usr/bin/flex
> > checking for bison... /usr/bin/bison
> > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib
> > checking for rpcgen... no
> > configure: error: required program RPCGEN not found
> >
> >
> >
> > configure misses rpcgen...and seems not to evaluate the USE of
> > libtirpc.
> >
> > I didn't find any fix/patch online.
> >
> > What goes wrong here?
> >
> > Cheers
> > Meino
> >
> >
> >
> If I'm reading the ebuild quoted below right, if 'libtirpc' is set, it
> is net-libs/libtirpc that meets the dependency, otherwise it is glibc
> compiled with rpc 

Re: [gentoo-user] setuptools (python) - how to disable the sandbox ?

[Michael Orlitzky]

On 12/09/2017 11:43 AM, Michael Orlitzky wrote:
>>
>> I wouldn't mind the package to write to its own working directory  
> 
> That's not usually a problem... what phase is this in, and which command
> in the ebuild raised the error?
> 

And now that I've actually read the error message, these errors are
coming from setuptools, not from the Gentoo sandbox.

The last time that caused a problem, it was because of a missing
dependency. If your kernel supports it, you can set
FEATURES="network-sandbox" to catch those earlier.

Re: [gentoo-user] setuptools (python) - how to disable the sandbox ?

[Michael Orlitzky]

On 12/09/2017 11:17 AM, Helmut Jarausch wrote:
> Hi,
> I want to create an ebuild for a package that's not in the tree  
> (http://pypi.python.org/pypi/grako)
> 
> Unfortunately, this always fails due to
> 
>File "/usr/lib64/python3.6/site-packages/setuptools/sandbox.py",  
> line 411, in _violation
>  raise SandboxViolation(operation, args, kw)
> setuptools.sandbox.SandboxViolation: SandboxViolation:  
> open('/var/tmp/portage/dev-python/grako-3.99.9/work/grako-3.99.9-python3_6/lib/ptr.py',
>   
> 'wb') {}
> 
> I wouldn't mind the package to write to its own working directory  

That's not usually a problem... what phase is this in, and which command
in the ebuild raised the error?

Re: [gentoo-user] preparing for profile switch -- major problem

[Alan McKinnon]

On 09/12/2017 17:28, Daniel Frey wrote:
>> hmmm, nothing masked as far as perl modules,  I will look at
>> verbose-conflicts and maybe write down all those modules and start
>> unmerging and see if eventually portage can figure out something -- I
>> don't really want to  do that,  however I will look at the conflicts
>> and see what I can find.
>>
>>
> 
> I had a lot of problems with the perl updates as well, and could not get
> it to resolve. I wasted over an hour trying to resolve it (my poor
> Celeron would take 5-10 minutes trying to calculate dependencies, and I
> had to do this 6-7 times.)
> 
> Note, what I did worked for me and may not work for you, so use this
> advice at your own risk: I emerged the new perl with --nodeps, and
> invoked `perl-cleaner all` to fix the mess afterwards. It had everything
> resolved in < 10 minutes. I didn't suffer any system breakage from using
> the sledgehammer approach, but others may not be so lucky... so, as I
> said, try it at your own risk.

that is a very clever solution, one that never occured to me. Ought to
be at the end of the wiki page, titled "when all else fails, you can
always do it this way"

It's good advice of last resort, really


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

Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd

[Alexander Kapshuk]

On Sat, Dec 9, 2017 at 6:03 PM,   wrote:
> Hi,
>
> autofs-5.1.3 fails to compile:
> solfire:/root>emerge -v autofs
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild   R] net-fs/autofs-5.1.3::gentoo  USE="libtirpc -dmalloc -hesiod 
> -ldap -mount-locking -sasl" 0 KiB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
 Verifying ebuild manifests
 Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo
 Failed to emerge net-fs/autofs-5.1.3, Log file:
  '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log'
 Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 0.88
>  * Package:net-fs/autofs-5.1.3
>  * Repository: gentoo
>  * Maintainer: d...@gentoo.org
>  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc userland_GNU
>  * FEATURES:   preserve-libs sandbox userpriv usersandbox
>  * Determining the location of the kernel source code
>  * Found kernel source directory:
>  * /usr/src/linux
>  * Found sources for kernel version:
>  * 4.14.4-RT
>  * Checking for suitable kernel configuration options...
>  [ ok ]
 Unpacking source...
 Unpacking autofs-5.1.3.tar.xz to /var/tmp/portage/net-fs/autofs-5.1.3/work
 Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work
 Preparing source in /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 
 ...
>  * Running eautoreconf in 
> '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ...
>  * This package has a configure.in file which has long been deprecated.  
> Please
>  * update it to use configure.ac instead as newer versions of autotools will 
> die
>  * when it finds this file.  See https://bugs.gentoo.org/426262 for details.
>  * Running autoconf --force ...
>  [ ok ]
>  * Running autoheader ...
>  [ ok ]
>  * Running elibtoolize in: autofs-5.1.3/
 Source prepared.
 Configuring source in 
 /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
 Working in BUILD_DIR: 
 "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3"
> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure 
> --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
> --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 
> --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d 
> --with-mapdir=/etc/autofs --without-dmalloc --without-openldap 
> --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking 
> --disable-ext-env --enable-sloppy-mount --enable-force-shutdown 
> --enable-ignore-busy --with-systemd=/usr/lib/systemd/system 
> RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib
> configure: loading site script /usr/share/config.site
> checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin
> checking for Linux proc filesystem... yes
> checking location of the init.d directory... /etc/init.d
> checking for autofs configuration file directory... /etc/conf.d
> checking for autofs maps directory... /etc/autofs
> checking for autofs fifos directory... /run
> checking for autofs flag file directory... /run
> checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
> checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
> checking if libtirpc is requested and available... yes
> checking for getrpcbyname... yes
> checking for getservbyname... yes
> checking if malloc debugging is wanted... no
> checking for mount... /bin/mount
> checking for mount.nfs... /sbin/mount.nfs
> checking for umount... /bin/umount
> checking for fsck.ext2... /sbin/fsck.ext2
> checking for fsck.ext3... /sbin/fsck.ext3
> checking for fsck.ext4... /sbin/fsck.ext4
> checking for modprobe... /sbin/modprobe
> checking for flex... /usr/bin/flex
> checking for bison... /usr/bin/bison
> checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib
> checking for rpcgen... no
> configure: error: required program RPCGEN not found
>
>
>
> configure misses rpcgen...and seems not to evaluate the USE of
> libtirpc.
>
> I didn't find any fix/patch online.
>
> What goes wrong here?
>
> Cheers
> Meino
>
>
>
If I'm reading the ebuild quoted below right, if 'libtirpc' is set, it
is net-libs/libtirpc that meets the dependency, otherwise it is glibc
compiled with rpc that does that.
/usr/portage/net-fs/autofs/autofs-5.1.3.ebuild:41,42
libtirpc? ( net-libs/libtirpc )
!libtirpc? ( elibc_glibc? ( sys-libs/glibc[rpc(-)] ) )

equery -q u sys-libs/glibc | grep rpc
+rpc

On my system, rpc is included in glibc:
equery -q b /usr/bin/rpcgen

Re: [gentoo-user] preparing for profile switch -- major problem

[John Covici]

On Sat, 09 Dec 2017 10:28:25 -0500,
Daniel Frey wrote:
> 
> On 12/09/17 03:23, John Covici wrote:
> > On Sat, 09 Dec 2017 03:51:03 -0500,
> > Alan McKinnon wrote:
> >> 
> >> On 08/12/2017 21:12, John Covici wrote:
> >>> On Fri, 08 Dec 2017 11:42:16 -0500,
> >>> Alan McKinnon wrote:
>  
>  On 07/12/2017 17:46, John Covici wrote:
> > On Thu, 07 Dec 2017 09:37:56 -0500,
> > Alan McKinnon wrote:
> >> 
> >> On 07/12/2017 07:44, John Covici wrote:
> >>> Hi. In preparing for the profile switch and the emerge -e world, I
> >> 
> >> 
> >> [snip]
> >> 
> >> 
>  No, I don't think you should revert the profile change. I understood
>  from your mail than you had not done that yet, and typed accordingly.
>  
>  I think Michael is on the right track with backtrack - set it to
>  something very high like 1000, see if that gets to a solution.
> >>> 
> >>> 
> >>> I did switch back, but the only way I could do a "successful" update
> >>> was to mask off 5.26 and then it skipped the update and would have
> >>> been successful.  If I switch to the new profile, I can do nothing as
> >>> far as perl goes.  I will show the output of just trying to emerge
> >>> below, it seems there were many many packages still requiring 5.24.
> >> 
> >> No, that's not right. The tree is consistent and portage can figure out
> >> how to get from perl-5.24 to perl-5.26
> >> 
> >> You probably have a difference locally, I would search through
> >> /etc/portage looking for entries that mask some perl modules and peg
> >> them to 5.24 versions.
> >> 
> >> Failing that, maybe you have a package installed that depends on a 5.24
> >> version of some module and this is the ripple effect
> >> 
> >> Perhaps run emerge with "--verbose-conflicts" and also "emerge -e world"
> >> and post the results
> >> 
> >> 
> >>> This is with the new profile and backtrack set to 500.
> >>> 
> >>>   instances within a single package slot have been pulled
> >>>   !!! into the dependency graph, resulting in a slot conflict:
> >>> 
> >>> dev-lang/perl:0
> >>> 
> >>>(dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
> >>>pulled in by
> >>>=dev-lang/perl-5.26* required by
> >>>(virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
> >>>^  ^
> >>>dev-lang/perl (Argument)
> >>>   (and 13 more with the same problems)
> >>> 
> >>>(dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
> >>>=dev-lang/perl-5.24* required by
> >>>(virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
> >>>^  ^
> >>>   dev-lang/perl:0/5.24= required by
> >>>(dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
> >>> 
> >>>  (and 260 more with the same problems)
> >>> 
> >>> NOTE: Use the '--verbose-conflicts' option to display parents omitted
> >>> above
> >>> 
> >>> It may be possible to solve this problem by using package.mask to
> >>> prevent one of those packages from being selected. However, it is also
> >>> possible that conflicting dependencies exist such that they are
> >>> impossible to satisfy simultaneously.  If such a conflict exists in
> >>> the dependencies of two different packages, then those packages can
> >>> not be installed simultaneously.
> >>> 
> >>> For more information, see MASKED PACKAGES section in the emerge man
> >>> page or refer to the Gentoo Handbook.
> > 
> > hmmm, nothing masked as far as perl modules,  I will look at
> > verbose-conflicts and maybe write down all those modules and start
> > unmerging and see if eventually portage can figure out something -- I
> > don't really want to  do that,  however I will look at the conflicts
> > and see what I can find.
> > 
> > 
> 
> I had a lot of problems with the perl updates as well, and could
> not get it to resolve. I wasted over an hour trying to resolve it
> (my poor Celeron would take 5-10 minutes trying to calculate
> dependencies, and I had to do this 6-7 times.)
> 
> Note, what I did worked for me and may not work for you, so use
> this advice at your own risk: I emerged the new perl with
> --nodeps, and invoked `perl-cleaner all` to fix the mess
> afterwards. It had everything resolved in < 10 minutes. I didn't
> suffer any system breakage from using the sledgehammer approach,
> but others may not be so lucky... so, as I said, try it at your
> own risk.

I was thinking of just that myself, I may try that  later today.  I am
using zfs, and do snapshots frequently, so it might be possible to get
back if things are a disaster, but it might work at that.   Did you
emerge perl again without the --nodeps afterwards to make sure?


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

[gentoo-user] setuptools (python) - how to disable the sandbox ?

[Helmut Jarausch]

Hi,
I want to create an ebuild for a package that's not in the tree  
(http://pypi.python.org/pypi/grako)


Unfortunately, this always fails due to

  File "/usr/lib64/python3.6/site-packages/setuptools/sandbox.py",  
line 411, in _violation

raise SandboxViolation(operation, args, kw)
setuptools.sandbox.SandboxViolation: SandboxViolation:  
open('/var/tmp/portage/dev-python/grako-3.99.9/work/grako-3.99.9-python3_6/lib/ptr.py',  
'wb') {}


I wouldn't mind the package to write to its own working directory  
/var/tmp/portage/dev-python/grako-3.99.9/work

but I cannot find out how to disable setuptools.sandbox

I've tried addwrite "$S" and FEATURES=-usersandbox  -sandbox

but nothing helps.

Many thanks for a hint,
Helmut

[gentoo-user] autofs wants rpcgen despite libtirpc is USEd

[tuxic]

Hi,

autofs-5.1.3 fails to compile:
solfire:/root>emerge -v autofs

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R] net-fs/autofs-5.1.3::gentoo  USE="libtirpc -dmalloc -hesiod 
-ldap -mount-locking -sasl" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo
>>> Failed to emerge net-fs/autofs-5.1.3, Log file:
>>>  '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log'
>>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 0.88
 * Package:net-fs/autofs-5.1.3
 * Repository: gentoo
 * Maintainer: d...@gentoo.org
 * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
 * Determining the location of the kernel source code
 * Found kernel source directory:
 * /usr/src/linux
 * Found sources for kernel version:
 * 4.14.4-RT
 * Checking for suitable kernel configuration options...
 [ ok ]
>>> Unpacking source...
>>> Unpacking autofs-5.1.3.tar.xz to /var/tmp/portage/net-fs/autofs-5.1.3/work
>>> Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work
>>> Preparing source in /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 
>>> ...
 * Running eautoreconf in 
'/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ...
 * This package has a configure.in file which has long been deprecated.  Please
 * update it to use configure.ac instead as newer versions of autotools will die
 * when it finds this file.  See https://bugs.gentoo.org/426262 for details.
 * Running autoconf --force ...
 [ ok ]
 * Running autoheader ...
 [ ok ]
 * Running elibtoolize in: autofs-5.1.3/
>>> Source prepared.
>>> Configuring source in 
>>> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ...
>>> Working in BUILD_DIR: 
>>> "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3"
/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure --prefix=/usr 
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --libdir=/usr/lib64 
--docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d 
--with-mapdir=/etc/autofs --without-dmalloc --without-openldap --with-libtirpc 
--without-sasl --without-hesiod --disable-mount-locking --disable-ext-env 
--enable-sloppy-mount --enable-force-shutdown --enable-ignore-busy 
--with-systemd=/usr/lib/systemd/system 
RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib
configure: loading site script /usr/share/config.site
checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin
checking for Linux proc filesystem... yes
checking location of the init.d directory... /etc/init.d
checking for autofs configuration file directory... /etc/conf.d
checking for autofs maps directory... /etc/autofs
checking for autofs fifos directory... /run
checking for autofs flag file directory... /run
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking if libtirpc is requested and available... yes
checking for getrpcbyname... yes
checking for getservbyname... yes
checking if malloc debugging is wanted... no
checking for mount... /bin/mount
checking for mount.nfs... /sbin/mount.nfs
checking for umount... /bin/umount
checking for fsck.ext2... /sbin/fsck.ext2
checking for fsck.ext3... /sbin/fsck.ext3
checking for fsck.ext4... /sbin/fsck.ext4
checking for modprobe... /sbin/modprobe
checking for flex... /usr/bin/flex
checking for bison... /usr/bin/bison
checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib
checking for rpcgen... no
configure: error: required program RPCGEN not found



configure misses rpcgen...and seems not to evaluate the USE of
libtirpc.

I didn't find any fix/patch online.

What goes wrong here?

Cheers
Meino

Re: [gentoo-user] preparing for profile switch -- major problem

[Daniel Frey]

On 12/09/17 03:23, John Covici wrote:

On Sat, 09 Dec 2017 03:51:03 -0500,
Alan McKinnon wrote:


On 08/12/2017 21:12, John Covici wrote:

On Fri, 08 Dec 2017 11:42:16 -0500,
Alan McKinnon wrote:


On 07/12/2017 17:46, John Covici wrote:

On Thu, 07 Dec 2017 09:37:56 -0500,
Alan McKinnon wrote:


On 07/12/2017 07:44, John Covici wrote:

Hi. In preparing for the profile switch and the emerge -e world, I



[snip]



No, I don't think you should revert the profile change. I understood
from your mail than you had not done that yet, and typed accordingly.

I think Michael is on the right track with backtrack - set it to
something very high like 1000, see if that gets to a solution.



I did switch back, but the only way I could do a "successful" update
was to mask off 5.26 and then it skipped the update and would have
been successful.  If I switch to the new profile, I can do nothing as
far as perl goes.  I will show the output of just trying to emerge
below, it seems there were many many packages still requiring 5.24.


No, that's not right. The tree is consistent and portage can figure out
how to get from perl-5.24 to perl-5.26

You probably have a difference locally, I would search through
/etc/portage looking for entries that mask some perl modules and peg
them to 5.24 versions.

Failing that, maybe you have a package installed that depends on a 5.24
version of some module and this is the ripple effect

Perhaps run emerge with "--verbose-conflicts" and also "emerge -e world"
and post the results



This is with the new profile and backtrack set to 500.

  instances within a single package slot have been pulled
  !!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

   (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
   pulled in by
   =dev-lang/perl-5.26* required by
   (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
   ^  ^
 dev-lang/perl (Argument)
(and 13 more with the same problems)

   (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
   =dev-lang/perl-5.24* required by
   (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
 ^  ^
dev-lang/perl:0/5.24= required by
   (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
  
   (and 260 more with the same problems)

NOTE: Use the '--verbose-conflicts' option to display parents omitted
above

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


hmmm, nothing masked as far as perl modules,  I will look at
verbose-conflicts and maybe write down all those modules and start
unmerging and see if eventually portage can figure out something -- I
don't really want to  do that,  however I will look at the conflicts
and see what I can find.




I had a lot of problems with the perl updates as well, and could not get 
it to resolve. I wasted over an hour trying to resolve it (my poor 
Celeron would take 5-10 minutes trying to calculate dependencies, and I 
had to do this 6-7 times.)


Note, what I did worked for me and may not work for you, so use this 
advice at your own risk: I emerged the new perl with --nodeps, and 
invoked `perl-cleaner all` to fix the mess afterwards. It had everything 
resolved in < 10 minutes. I didn't suffer any system breakage from using 
the sledgehammer approach, but others may not be so lucky... so, as I 
said, try it at your own risk.


Dan

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Mart Raudsepp]

On R, 2017-12-08 at 19:39 +0700, Vadim A. Misbakh-Soloviov wrote:
> > 
> > Is it really necessary to block one package when another installed?
> 
> Most of the time, the reason to make packages to block each other is 
> collisions (if they they contain files (like binaries or libraries)
> with same 
> install paths).
> 
> Although, I can't guarantee that it was the case here.

There was a blocker in blueman against gnome-bluetooth due to a file
collision with gnome-bluetooth. This was removed with 2.0-r1, back in
Oct 2015, as blueman upstream solved it.
To me it looks like the change didn't make it to the live ebuild and
then eventually sometime after 2.0.3 a bump was made via copying from
, not the latest version, thus reinstating the blocker, possibly by
accident. Or maybe on purpose, but I don't see an explanation for it in
logs.
Try to remove the blocker in blueman, see if files collide or not, and
if not file a bug against blueman, possibly with info that it might
have been accidental reintroduction due to..., etc.

> I've noticed that Gnome Team makes some decisions, that doesn't looks
> logical 
> for a few times already.

Something not looking logical for you doesn't mean there isn't sound
logic. In this case, it's not us who have a blocker possibly wrongly
reintroduced here.


Best,
Mart Raudsepp
Gentoo GNOME team lead

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Alan McKinnon]

On 09/12/2017 14:04, taii...@gmx.com wrote:
> On 12/09/2017 05:45 AM, Mick wrote:
>> On Saturday, 9 December 2017 10:34:32 GMT Nikos Chantziaras wrote:
>>> On 09/12/17 11:51, Mick wrote:
 I've seen gnome-base/gnome-common pulled in on more than one
 systems, all
 of>
 which have USE="-gnome" set:
    # emerge -uaNDvt world

 These are the packages that would be merged, in reverse order:
 [...]
 Calculating dependencies... done!
 [ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo
 USE="autoconf-archive" 153 KiB
 [...]

 All systems are on profile:  default/linux/amd64/17.0/desktop/plasma

 Why is gnome-base/gnome-common needed?
>>> It's an extremely lightweight package. There seem to be some packages
>>> that need files from it. The package itself only installs these files:
>>>
>>>     $ qlist gnome-common
>>>     /usr/bin/gnome-autogen.sh
>>>     /usr/share/aclocal/gnome-common.m4
>>>     /usr/share/aclocal/gnome-compiler-flags.m4
>>>     /usr/share/aclocal/gnome-code-coverage.m4
>>>     /usr/share/doc/gnome-common-3.18.0-r1/ChangeLog.bz2
>>>     /usr/share/doc/gnome-common-3.18.0-r1/README.bz2
>>>
>>> So basically it only copies some small text files to /usr. It doesn't
>>> build anything.
>> Thank you all for detailed and clear replies.  You'd forgive me for
>> being (a
>> little) paranoid about Poettering's fingers getting anywhere near my
>> systems.
>> :-p
>>
> For now, only a few text files - tomorrow - many more.
> 
> You give poettering an inch he will take hundred miles.
> 


Why are you laying this at Poettering's door?

To the best of my knowledge, he is not behind udisks{,2} or
gnome-common, so why include him here?

I'm all in favour of Lennart-bashing, but let's keep the bashing to what
he's responsible for.

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

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[taii...@gmx.com]

On 12/09/2017 05:45 AM, Mick wrote:

On Saturday, 9 December 2017 10:34:32 GMT Nikos Chantziaras wrote:

On 09/12/17 11:51, Mick wrote:

I've seen gnome-base/gnome-common pulled in on more than one systems, all
of>
which have USE="-gnome" set:
   # emerge -uaNDvt world

These are the packages that would be merged, in reverse order:
[...]
Calculating dependencies... done!
[ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo
USE="autoconf-archive" 153 KiB
[...]

All systems are on profile:  default/linux/amd64/17.0/desktop/plasma

Why is gnome-base/gnome-common needed?

It's an extremely lightweight package. There seem to be some packages
that need files from it. The package itself only installs these files:

$ qlist gnome-common
/usr/bin/gnome-autogen.sh
/usr/share/aclocal/gnome-common.m4
/usr/share/aclocal/gnome-compiler-flags.m4
/usr/share/aclocal/gnome-code-coverage.m4
/usr/share/doc/gnome-common-3.18.0-r1/ChangeLog.bz2
/usr/share/doc/gnome-common-3.18.0-r1/README.bz2

So basically it only copies some small text files to /usr. It doesn't
build anything.

Thank you all for detailed and clear replies.  You'd forgive me for being (a
little) paranoid about Poettering's fingers getting anywhere near my systems.
:-p


For now, only a few text files - tomorrow - many more.

You give poettering an inch he will take hundred miles.

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Jorge Almeida]

On Sat, Dec 9, 2017 at 10:45 AM, Mick  wrote:


>
> Thank you all for detailed and clear replies.  You'd forgive me for being (a
> little) paranoid about Poettering's fingers getting anywhere near my systems.
> :-p
>
Are you sure you need udisks? And policykit? I'm guessing you have
some default USE variables which if removed would contribute to a
cleaner system. I just checked the documentation about udisks in the
freedesktop site. I didn't manage to understand why it would be useful
(my fault, probably) but I understood enough to decide I wouldn't want
such stuff in my system.

(Of course, the aforementioned fingers are exceedingly sticky. We all
have to live with udev, after all...)

Regards

Jorge Almeida

Re: [gentoo-user] CFLAGs change but no filter/strip/replace in ebuild

[Adam Carter]

>
> I would strongly advise against that, just on principle.
>
> yasm is an assembler, and as such it's right at the bottom of the stack.
> It's not unreasonable for such a package to use different FLAGS etc as
> it's not a userland app. It's an app that builds things you use to build
> a userland.
>
> I would recommend you touch base with the package maintainer for answers.
>
> btw, why is this situation a problem? Is something wrong with the yasm
> portage builds you?
>

I'm trying to avoid a reinstall. With profile 17, i found many packages
required -fPIC to build (probably due to some mucking around i've done with
hardened, and/or gentoo devs earlier force on of PIE in gcc that they later
backed out.). yasm build is failing and saying try -fPIC.

Re: [gentoo-user] preparing for profile switch -- major problem

[John Covici]

On Sat, 09 Dec 2017 03:51:03 -0500,
Alan McKinnon wrote:
> 
> On 08/12/2017 21:12, John Covici wrote:
> > On Fri, 08 Dec 2017 11:42:16 -0500,
> > Alan McKinnon wrote:
> >>
> >> On 07/12/2017 17:46, John Covici wrote:
> >>> On Thu, 07 Dec 2017 09:37:56 -0500,
> >>> Alan McKinnon wrote:
> 
>  On 07/12/2017 07:44, John Covici wrote:
> > Hi. In preparing for the profile switch and the emerge -e world, I
> 
> 
> [snip]
> 
> 
> >> No, I don't think you should revert the profile change. I understood
> >> from your mail than you had not done that yet, and typed accordingly.
> >>
> >> I think Michael is on the right track with backtrack - set it to
> >> something very high like 1000, see if that gets to a solution.
> > 
> > 
> > I did switch back, but the only way I could do a "successful" update
> > was to mask off 5.26 and then it skipped the update and would have
> > been successful.  If I switch to the new profile, I can do nothing as
> > far as perl goes.  I will show the output of just trying to emerge
> > below, it seems there were many many packages still requiring 5.24.
> 
> No, that's not right. The tree is consistent and portage can figure out
> how to get from perl-5.24 to perl-5.26
> 
> You probably have a difference locally, I would search through
> /etc/portage looking for entries that mask some perl modules and peg
> them to 5.24 versions.
> 
> Failing that, maybe you have a package installed that depends on a 5.24
> version of some module and this is the ripple effect
> 
> Perhaps run emerge with "--verbose-conflicts" and also "emerge -e world"
> and post the results
> 
> 
> > This is with the new profile and backtrack set to 500.
> > 
> >  instances within a single package slot have been pulled
> >  !!! into the dependency graph, resulting in a slot conflict:
> > 
> > dev-lang/perl:0
> > 
> >   (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
> >   pulled in by
> >   =dev-lang/perl-5.26* required by
> >   (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
> >   ^  ^
> >  dev-lang/perl (Argument)
> > (and 13 more with the same problems)
> > 
> >   (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
> >   =dev-lang/perl-5.24* required by
> >   (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
> >  ^  ^
> > dev-lang/perl:0/5.24= required by
> >   (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
> >   
> >(and 260 more with the same problems)
> > 
> > NOTE: Use the '--verbose-conflicts' option to display parents omitted
> > above
> > 
> > It may be possible to solve this problem by using package.mask to
> > prevent one of those packages from being selected. However, it is also
> > possible that conflicting dependencies exist such that they are
> > impossible to satisfy simultaneously.  If such a conflict exists in
> > the dependencies of two different packages, then those packages can
> > not be installed simultaneously.
> > 
> > For more information, see MASKED PACKAGES section in the emerge man
> > page or refer to the Gentoo Handbook.

hmmm, nothing masked as far as perl modules,  I will look at
verbose-conflicts and maybe write down all those modules and start
unmerging and see if eventually portage can figure out something -- I
don't really want to  do that,  however I will look at the conflicts
and see what I can find.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Mick]

On Saturday, 9 December 2017 10:34:32 GMT Nikos Chantziaras wrote:
> On 09/12/17 11:51, Mick wrote:
> > I've seen gnome-base/gnome-common pulled in on more than one systems, all
> > of> 
> > which have USE="-gnome" set:
> >   # emerge -uaNDvt world
> > 
> > These are the packages that would be merged, in reverse order:
> > [...]
> > Calculating dependencies... done!
> > [ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo
> > USE="autoconf-archive" 153 KiB
> > [...]
> > 
> > All systems are on profile:  default/linux/amd64/17.0/desktop/plasma
> > 
> > Why is gnome-base/gnome-common needed?
> 
> It's an extremely lightweight package. There seem to be some packages
> that need files from it. The package itself only installs these files:
> 
>$ qlist gnome-common
>/usr/bin/gnome-autogen.sh
>/usr/share/aclocal/gnome-common.m4
>/usr/share/aclocal/gnome-compiler-flags.m4
>/usr/share/aclocal/gnome-code-coverage.m4
>/usr/share/doc/gnome-common-3.18.0-r1/ChangeLog.bz2
>/usr/share/doc/gnome-common-3.18.0-r1/README.bz2
> 
> So basically it only copies some small text files to /usr. It doesn't
> build anything.

Thank you all for detailed and clear replies.  You'd forgive me for being (a 
little) paranoid about Poettering's fingers getting anywhere near my systems.  
:-p

-- 
Regards,
Mick

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

[gentoo-user] Re: Is gnome becoming obligatory?

[Nikos Chantziaras]

On 09/12/17 11:51, Mick wrote:

I've seen gnome-base/gnome-common pulled in on more than one systems, all of
which have USE="-gnome" set:

  # emerge -uaNDvt world

These are the packages that would be merged, in reverse order:
[...]
Calculating dependencies... done!
[ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo
USE="autoconf-archive" 153 KiB
[...]

All systems are on profile:  default/linux/amd64/17.0/desktop/plasma

Why is gnome-base/gnome-common needed?


It's an extremely lightweight package. There seem to be some packages 
that need files from it. The package itself only installs these files:


  $ qlist gnome-common
  /usr/bin/gnome-autogen.sh
  /usr/share/aclocal/gnome-common.m4
  /usr/share/aclocal/gnome-compiler-flags.m4
  /usr/share/aclocal/gnome-code-coverage.m4
  /usr/share/doc/gnome-common-3.18.0-r1/ChangeLog.bz2
  /usr/share/doc/gnome-common-3.18.0-r1/README.bz2

So basically it only copies some small text files to /usr. It doesn't 
build anything.

Re: [gentoo-user] Is gnome becoming obligatory?

[Alan McKinnon]

On 09/12/2017 11:51, Mick wrote:
> I've seen gnome-base/gnome-common pulled in on more than one systems, all of 
> which have USE="-gnome" set:
> 
>  # emerge -uaNDvt world
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> [nomerge   ] kde-apps/kdebase-meta-17.08.3:5::gentoo
> [nomerge   ]  kde-plasma/plasma-meta-5.10.5:5::gentoo  USE="bluetooth 
> display-manager handbook pam pulseaudio sddm wallpapers -grub -gtk -
> networkmanager -plymouth -sdk"
> [nomerge   ]   kde-plasma/powerdevil-5.10.5:5::gentoo  USE="consolekit 
> handbook wireless -debug"
> [nomerge   ]kde-frameworks/solid-5.37.0:5/5.37::gentoo  USE="nls -
> debug -doc {-test}"
> [ebuild U  ] sys-fs/udisks-2.7.4:2::gentoo [2.1.8:2::gentoo] USE="acl 
> gptfdisk introspection nls%* -cryptsetup -debug (-elogind) -lvm% (-selinux) -
> systemd" 1,257 KiB
> [ebuild  N ]  sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache -
> dmraid -doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 -
> python3_6" PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 268 KiB
> [ebuild  N ]   dev-libs/volume_key-0.3.9::gentoo  USE="{-test}" 
> PYTHON_SINGLE_TARGET="python3_5 -python3_4 -python3_6" 
> PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 435 KiB
> [ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo  
> USE="autoconf-archive" 153 KiB
> [nomerge   ] sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache 
> -dmraid 
> -doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 
> -python3_6" 
> PYTHON_TARGETS="python3_5 -python3_4 -python3_6"
> [ebuild  N ]  dev-libs/libbytesize-1.2::gentoo  USE="-doc {-test}" 
> PYTHON_SINGLE_TARGET="python3_5 -python2_7 -python3_4 -python3_6" 
> PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 69 KiB
> 
> Total: 5 packages (1 upgrade, 4 new), Size of downloads: 2,180 KiB
> 
> All systems are on profile:  default/linux/amd64/17.0/desktop/plasma
> 
> Why is gnome-base/gnome-common needed?
> 



Because sys-fs/udisks:2 depends on it.

It's NOT trying to install gnome, the package is gnome-common with this
description:

 Description: Common files for development of Gnome packages

The list of installed files are:

$ equery files gnome-common
 * Searching for gnome-common ...
 * Contents of gnome-base/gnome-common-3.18.0-r1:
/usr
/usr/bin
/usr/bin/gnome-autogen.sh
/usr/share
/usr/share/aclocal
/usr/share/aclocal/gnome-code-coverage.m4
/usr/share/aclocal/gnome-common.m4
/usr/share/aclocal/gnome-compiler-flags.m4
/usr/share/doc
/usr/share/doc/gnome-common-3.18.0-r1
/usr/share/doc/gnome-common-3.18.0-r1/ChangeLog
/usr/share/doc/gnome-common-3.18.0-r1/README

All they are is 4 small .m4 files to do useful stuff to let packages
build, very much like a few needed includes. They just happen to be
generically useful and just happen to be written by someone in the Gnome
team, and just happen to have names starting with this sequence of
letters: gee enn oh emm ee



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

Re: [gentoo-user] CFLAGs change but no filter/strip/replace in ebuild

[Alan McKinnon]

On 09/12/2017 11:37, Adam Carter wrote:
> On Sat, Dec 9, 2017 at 8:10 PM, Alan McKinnon  > wrote:
> 
> On 09/12/2017 11:10, Adam Carter wrote:
> > # grep -ic flags yasm-1.3.0.ebuild
> > 0
> >
> > However, emerge --info yasm shows me that only -march -O2 -pipe
> make it
> > through. Where is the code that strips the others?
> >
> 
> Have you checked yasm's Makefile?
> 
> 
> There's mentions of CFLAGS in there but I don't have the knowledge to
> understand it. Is there a way I can tweak what the makefiles have done?
> I tried adding;
> 
> append-flags 
> 
> in the src_configure() section, but  doesnt get added, according
> to emerge --info


I would strongly advise against that, just on principle.

yasm is an assembler, and as such it's right at the bottom of the stack.
It's not unreasonable for such a package to use different FLAGS etc as
it's not a userland app. It's an app that builds things you use to build
a userland.

I would recommend you touch base with the package maintainer for answers.

btw, why is this situation a problem? Is something wrong with the yasm
portage builds you?

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

Re: [gentoo-user] Is gnome becoming obligatory?

[Alexander Kapshuk]

On Sat, Dec 9, 2017 at 11:51 AM, Mick  wrote:
> I've seen gnome-base/gnome-common pulled in on more than one systems, all of
> which have USE="-gnome" set:
>
>  # emerge -uaNDvt world
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [nomerge   ] kde-apps/kdebase-meta-17.08.3:5::gentoo
> [nomerge   ]  kde-plasma/plasma-meta-5.10.5:5::gentoo  USE="bluetooth
> display-manager handbook pam pulseaudio sddm wallpapers -grub -gtk -
> networkmanager -plymouth -sdk"
> [nomerge   ]   kde-plasma/powerdevil-5.10.5:5::gentoo  USE="consolekit
> handbook wireless -debug"
> [nomerge   ]kde-frameworks/solid-5.37.0:5/5.37::gentoo  USE="nls -
> debug -doc {-test}"
> [ebuild U  ] sys-fs/udisks-2.7.4:2::gentoo [2.1.8:2::gentoo] USE="acl
> gptfdisk introspection nls%* -cryptsetup -debug (-elogind) -lvm% (-selinux) -
> systemd" 1,257 KiB
> [ebuild  N ]  sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache -
> dmraid -doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 -
> python3_6" PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 268 KiB
> [ebuild  N ]   dev-libs/volume_key-0.3.9::gentoo  USE="{-test}"
> PYTHON_SINGLE_TARGET="python3_5 -python3_4 -python3_6"
> PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 435 KiB
> [ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo
> USE="autoconf-archive" 153 KiB
> [nomerge   ] sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache -dmraid
> -doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 -python3_6"
> PYTHON_TARGETS="python3_5 -python3_4 -python3_6"
> [ebuild  N ]  dev-libs/libbytesize-1.2::gentoo  USE="-doc {-test}"
> PYTHON_SINGLE_TARGET="python3_5 -python2_7 -python3_4 -python3_6"
> PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 69 KiB
>
> Total: 5 packages (1 upgrade, 4 new), Size of downloads: 2,180 KiB
>
> All systems are on profile:  default/linux/amd64/17.0/desktop/plasma
>
> Why is gnome-base/gnome-common needed?
>
> --
> Regards,
> Mick

It's sys-fs/udisks that wants gnome-base/gnome-common.

[gentoo-user] Is gnome becoming obligatory?

[Mick]

I've seen gnome-base/gnome-common pulled in on more than one systems, all of 
which have USE="-gnome" set:

 # emerge -uaNDvt world

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[nomerge   ] kde-apps/kdebase-meta-17.08.3:5::gentoo
[nomerge   ]  kde-plasma/plasma-meta-5.10.5:5::gentoo  USE="bluetooth 
display-manager handbook pam pulseaudio sddm wallpapers -grub -gtk -
networkmanager -plymouth -sdk"
[nomerge   ]   kde-plasma/powerdevil-5.10.5:5::gentoo  USE="consolekit 
handbook wireless -debug"
[nomerge   ]kde-frameworks/solid-5.37.0:5/5.37::gentoo  USE="nls -
debug -doc {-test}"
[ebuild U  ] sys-fs/udisks-2.7.4:2::gentoo [2.1.8:2::gentoo] USE="acl 
gptfdisk introspection nls%* -cryptsetup -debug (-elogind) -lvm% (-selinux) -
systemd" 1,257 KiB
[ebuild  N ]  sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache -
dmraid -doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 -
python3_6" PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 268 KiB
[ebuild  N ]   dev-libs/volume_key-0.3.9::gentoo  USE="{-test}" 
PYTHON_SINGLE_TARGET="python3_5 -python3_4 -python3_6" 
PYTHON_TARGETS="python3_5 -python3_4 -python3_6" 435 KiB
[ebuild  N ]  gnome-base/gnome-common-3.18.0-r1:3::gentoo  
USE="autoconf-archive" 153 KiB
[nomerge   ] sys-libs/libblockdev-2.14::gentoo  USE="crypt -bcache -dmraid 
-doc -kbd -lvm {-test}" PYTHON_SINGLE_TARGET="python3_5 -python3_4 -python3_6" 
PYTHON_TARGETS="python3_5 -python3_4 -python3_6"
[ebuild  N ]  dev-libs/libbytesize-1.2::gentoo  USE="-doc {-test}" 
PYTHON_SINGLE_TARGET="python3_5 -python2_7 -python3_4 -python3_6" 
PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 69 KiB

Total: 5 packages (1 upgrade, 4 new), Size of downloads: 2,180 KiB

All systems are on profile:  default/linux/amd64/17.0/desktop/plasma

Why is gnome-base/gnome-common needed?

-- 
Regards,
Mick

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

Re: [gentoo-user] CFLAGs change but no filter/strip/replace in ebuild

[Adam Carter]

On Sat, Dec 9, 2017 at 8:10 PM, Alan McKinnon 
wrote:

> On 09/12/2017 11:10, Adam Carter wrote:
> > # grep -ic flags yasm-1.3.0.ebuild
> > 0
> >
> > However, emerge --info yasm shows me that only -march -O2 -pipe make it
> > through. Where is the code that strips the others?
> >
>
> Have you checked yasm's Makefile?
>

There's mentions of CFLAGS in there but I don't have the knowledge to
understand it. Is there a way I can tweak what the makefiles have done? I
tried adding;

append-flags 

in the src_configure() section, but  doesnt get added, according to
emerge --info

Re: [gentoo-user] install ebuilds from funtoo, zentoo distro overlay

[Alan McKinnon]

On 09/12/2017 11:15, Kruglov Sergey wrote:
> Hi!
> 
> 
> How can I install ebuilds from funtoo, zentoo distro overlays? I can't
> find any information about it.
> 

Find the URL for those overlays on the internet, then follow "man
layman" instructions to have them added to
/etc/portage/repos.conf/layman.conf.

The last time I did this, I simply added the overlay to reps.conf
manually, but I'm sure there's a convenience wrapper method in layman
somewhere

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

Re: [gentoo-user] CFLAGs change but no filter/strip/replace in ebuild

[Alan McKinnon]

On 09/12/2017 11:10, Adam Carter wrote:
> # grep -ic flags yasm-1.3.0.ebuild
> 0
> 
> However, emerge --info yasm shows me that only -march -O2 -pipe make it
> through. Where is the code that strips the others?
> 

Have you checked yasm's Makefile?


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

[gentoo-user] install ebuilds from funtoo, zentoo distro overlay

[Kruglov Sergey]

Hi!


How can I install ebuilds from funtoo, zentoo distro overlays? I can't find any 
information about it.

[gentoo-user] CFLAGs change but no filter/strip/replace in ebuild

[Adam Carter]

# grep -ic flags yasm-1.3.0.ebuild
0

However, emerge --info yasm shows me that only -march -O2 -pipe make it
through. Where is the code that strips the others?

Re: [gentoo-user] preparing for profile switch -- major problem

[Alan McKinnon]

On 08/12/2017 21:12, John Covici wrote:
> On Fri, 08 Dec 2017 11:42:16 -0500,
> Alan McKinnon wrote:
>>
>> On 07/12/2017 17:46, John Covici wrote:
>>> On Thu, 07 Dec 2017 09:37:56 -0500,
>>> Alan McKinnon wrote:

 On 07/12/2017 07:44, John Covici wrote:
> Hi. In preparing for the profile switch and the emerge -e world, I


[snip]


>> No, I don't think you should revert the profile change. I understood
>> from your mail than you had not done that yet, and typed accordingly.
>>
>> I think Michael is on the right track with backtrack - set it to
>> something very high like 1000, see if that gets to a solution.
> 
> 
> I did switch back, but the only way I could do a "successful" update
> was to mask off 5.26 and then it skipped the update and would have
> been successful.  If I switch to the new profile, I can do nothing as
> far as perl goes.  I will show the output of just trying to emerge
> below, it seems there were many many packages still requiring 5.24.

No, that's not right. The tree is consistent and portage can figure out
how to get from perl-5.24 to perl-5.26

You probably have a difference locally, I would search through
/etc/portage looking for entries that mask some perl modules and peg
them to 5.24 versions.

Failing that, maybe you have a package installed that depends on a 5.24
version of some module and this is the ripple effect

Perhaps run emerge with "--verbose-conflicts" and also "emerge -e world"
and post the results


> This is with the new profile and backtrack set to 500.
> 
>  instances within a single package slot have been pulled
>  !!! into the dependency graph, resulting in a slot conflict:
> 
> dev-lang/perl:0
> 
>   (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
>   pulled in by
>   =dev-lang/perl-5.26* required by
>   (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
>   ^  ^
>dev-lang/perl (Argument)
>   (and 13 more with the same problems)
> 
>   (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
>   =dev-lang/perl-5.24* required by
>   (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
>^  ^
>   dev-lang/perl:0/5.24= required by
>   (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
> 
>  (and 260 more with the same problems)
> 
> NOTE: Use the '--verbose-conflicts' option to display parents omitted
> above
> 
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously.  If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously.
> 
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
> 
> 
> 
> 


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

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Alan McKinnon]

On 09/12/2017 02:47, Alexey Eschenko wrote:
> Except that fact that I didn't unmasked it.

You must have had a tree checkout slightly newer than mine. I just
synced here and see that the mask has now been removed.

It's quite unusual to unmask an alpha version, maybe raise it on b.g.o ?

For the rest, that's just how blockers go unfortunately. There is no
easy way for the maintainer to communicate to you at emerge time *why*
the blocker is there, you just see the effect that it *is* there.

It's proper to block package B if new version of package A provides the
same features and they collide. But portage is stuck with nowhere to go
if you happen to have package B in world.

>> # fgrep -rni blueman /etc/portage
>> /etc/portage/package.use/blueman:1:#net-wireless/blueman
> But I understand other possible reasons.
> 
> On 12/08/2017 07:37 PM, Alan McKinnon wrote:
>> On 08/12/2017 15:22, Alexey Eschenko wrote:
>>> It can be the issue. But older version (2.0.4) which is currently
>>> installed works fine and has no conflicts.
>>>
>>> It's quite strange.
>>>
>>>
>>> On 12/08/2017 03:39 PM, Vadim A. Misbakh-Soloviov wrote:
> Is it really necessary to block one package when another installed?
 Most of the time, the reason to make packages to block each other is
 collisions (if they they contain files (like binaries or libraries)
 with same
 install paths).

 Although, I can't guarantee that it was the case here.

 I've noticed that Gnome Team makes some decisions, that doesn't looks
 logical
 for a few times already.

>>
>> It's not at all strange; it's quite ordinary actually.
>>
>> Keeping in mind that I do not use these packages, or gnome, look at the
>> available blueman packages:
>>
>> # eix net-wireless/blueman
>> * net-wireless/blueman
>>   Available versions:  (~)2.0.3 (~)2.0.4 [M](~)2.1_alpha1 **
>> {appindicator network nls policykit pulseaudio thunar
>> PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6"
>> PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
>>
>> 2.1 is still in an alpha state, and it is p.masked:
>>
>> /var/portage/profiles/package.mask:
>> # Michał Górny  (26 Jan 2017)
>> # Pre-release, masked for testing. Major changes since 2.0.4,
>> # including dropped support for BlueZ 4.
>>
>> It is not unreasonable to conclude that blueman-2.1 intends to add
>> features that conflict with gnome-bluetooth and they can't co-exist. As
>> Vadim said, file collisions are often the underlying cause.
>>
>> You unmasked an alpha package, clearly tagged as "for testing". Nothing
>> add abut the result you got at all.
>>
>>
>>
> 


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

Re: [gentoo-user] gambas-3.10.0 installed from jorgicio overlay can't run

[John Campbell]

On 12/08/2017 11:04 PM, Kruglov Sergey wrote:

> I installed the 'gambas-3.10.0' from the overlay 'jorgicio'
> (http://data.gpo.zugaina.org/jorgicio/dev-lang/gambas/)
> And I can't run it. In /usr/bin/gambas3 there is a link to
> 'gambas3.gambas' and 'gambas3.gambas' not found.
> Maybe somebody already fix it? 

I haven't tried to install but there are several things I noticed.

There are two sets of ebuilds for the same program.  "dev-lang/gambas"
which is the version you tried, and "dev-util/gambas" which seems to be
slightly less up to date but from a better class of repositories (Funtoo
is a distro in and of itself).

I'd suggest downloading the most recent ebuild from various repositories
and comparing them  One of the older versions might work, and you'd just
have to set up your own local overlay to pull in the latest 3.10.0 version.