Re: [gentoo-user] Failed builds of kbuild and cdrdao with "undefined reference to `__alloca'"

2018-02-09 Thread tuxic 
On 02/09 10:02, Andreas K. Huettel wrote:
> Am Sonntag, 4. Februar 2018, 15:03:28 CET schrieb tu...@posteo.de:
> > Hi,
> > 
> > I still have the problem of failed builds due to an
> > 'undefined reference to `__alloca''. I recompiled
> > gcc/glibc and I am using linux-4.15.1 (from kernel.org)
> > with linux-headers 4.15. .
> > 
> > Affected are (at least) cdrdao and kbuild.
> > 
> 
> What's your sys-libs/glibc ?!
> 
> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)


[I] sys-libs/glibc
 Available versions:  (2.2) [M](~)2.18-r1^s [M]2.19-r1^s [M]2.20-r2^s 
[M]2.21-r2^s [M]2.22-r4^s [M]2.23-r4^s [M](~)2.24-r4^s 2.25-r9^s 2.25-r10^s 
(~)2.26-r5^s **2.26-r6^s **2.27-r1^s (**)^s
   {audit caps compile-locales debug doc gd hardened headers-only multilib 
nscd profile +rpc selinux suid systemtap vanilla}
 Installed versions:  (2.2)^s(09:54:43 AM 02/04/2018)(-audit -caps 
-compile-locales -debug -doc -gd -hardened -headers-only -multilib -nscd 
-profile -selinux -suid -systemtap -vanilla)
 Homepage:https://www.gnu.org/software/libc/
 Description: GNU libc C library

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Grant Taylor 

On 02/09/2018 03:30 AM, gevisz wrote:
May be, it is not a good idea to put /mnt on tmpfs at the time of Spector 
and Meltdown?


I wouldn't put /mnt on tmpfs as I routinely create mount points there 
in.  As such they would be lost on reboot.


What difference does Spector or Meltdown (or the next big security 
thing) have on using tmpfs for /mnt or not?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [gentoo-user] Failed builds of kbuild and cdrdao with "undefined reference to `__alloca'"

2018-02-09 Thread Andreas K. Huettel 
Am Sonntag, 4. Februar 2018, 15:03:28 CET schrieb tu...@posteo.de:
> Hi,
> 
> I still have the problem of failed builds due to an
> 'undefined reference to `__alloca''. I recompiled
> gcc/glibc and I am using linux-4.15.1 (from kernel.org)
> with linux-headers 4.15. .
> 
> Affected are (at least) cdrdao and kbuild.
> 

What's your sys-libs/glibc ?!

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

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

[gentoo-user] kernel 4.14.15-gentoo breaks Dell Wireless 370 Bluetooth Mini-card device

2018-02-09 Thread Mick 
I just noticed I can no longer use bluetooth with the 4.14.15 kernel.  This 
laptop has a shared bluetooth and WiFi mini card, which has never worked 
properly (see attached hardware details).

Although MWindows has no problem, in Linux I have to disable WiFi when I need 
to use bluetooth!  O_o

Anyway, I now discovered that bluetooth won't work and /lib/systemd/systemd-
udevd --daemon is pegged at 100% of CPU time.  Switching off the mini-card 
using a keyboard button does not stop udevd from running hot.  It just drops 
from 100% to 45% until I kill the process manually.


udevadm monitor shows:

KERNEL[281.040708] bind /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.040855] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
UDEV  [281.041192] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.044485] bind /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.044596] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
UDEV  [281.044969] bind /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.048056] bind /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.048257] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
UDEV  [281.048534] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.051754] bind /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)
KERNEL[281.051995] unbind   /devices/pci:00/:00:1d.0/
usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0 (usb)

non stop.  Syslog does not show anything unusual.

Has anyone noticed something similar?  How do I troubleshoot this?
-- 
Regards,
Mick # lsusb -v

Bus 002 Device 011: ID 413c:8156 Dell Computer Corp. Wireless 370 Bluetooth 
Mini-card
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x8156 Wireless 370 Bluetooth Mini-card
  bcdDevice4.56
  iManufacturer   1 Dell Computer Corp
  iProduct2 Dell Wireless 370 Bluetooth Mini-card
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  216
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize

Re: [gentoo-user] Re: /var/tmp on tmpfs

2018-02-09 Thread gevisz 
2018-02-09 4:15 GMT+02:00 Ian Zimmerman :
> On 2018-02-09 01:15, Wol's lists wrote:
>
>> > Care to cite an example of such a program in the Gentoo repo?  I
>> > certainly can't think of any, and I've been running with /var/tmp on
>> > tmpfs for over a decade.
>>
>> I don't know of any.
>
> vim?
>
> Although that choice was recently criticized on the oss-security list,
> Bram the BDFL seems to be sticking with it.

Ok, thank you for the information.

You have convinced me to stick with the standard. :)

Re: [gentoo-user] Re: /var/tmp on tmpfs

2018-02-09 Thread gevisz 
2018-02-09 3:50 GMT+02:00 Dale :
> gevisz wrote:
>>
>> You probably will be surprised, but the main reason I am trying to use
>> tmpfs for /var/tmp/ is not because I want to make emerging chromium
>> faster (I have no hope about that because read somewhere that it will
>> make compilation only 10 percent faster) but because I have not too
>> much free space on / (sometimes in the past chromium refused to build
>> in the similar conditions) and because of that either have to move /var/tmp
>> to the separate partition anyway or try to use tmpfs + swap and, if it fails,
>> to move to the separate partition only /var/tmp/portage/notmpfs
>>
>
>
> I think you can tell emerge/portage to build that specific program on
> another disk.  You just have to tell it where, sort of the same way you
> tell it to build on disk instead of tmpfs.  I've never done it but it
> should work the same way.  Just make sure the permissions are right.
>
> My thinking.  Let's say you have chromium that won't fit on the usual
> disk.  Tell emerge/portage to build chromium in another directory that
> is on another disk.
>
> /etc/portage/env/largedisk.conf
> PORTAGE_TMPDIR="/var/tmp/largedisk"
>
> /etc/portage/package.env/package.env
> www-client/chromium  ../env/largedisk.conf
>
> Once you have those files set up to work, then make sure you have your
> large disk mounted at /var/tmp/largedisk and I would think it would
> work.  Anytime you emerge chromium, it should do that in
> /var/tmp/largedisk.  Only question is, do you have another disk to try
> this on???

Yes. I still have an unused 4th primary partition on the same hard disk.
I am going to make it extended and create 3 more partitions on it:
one — for /var/tmp/notmfs, another — for /var/log and the 3rd one —
for some unpredictable purposes like installing a rescue system.
Still have not decided on their size, file system and mount options
but it would be another question in a separate thread, when I come to it.

I am currently building a new and shiny :) Gentoo system on the
1st primery partion of this disk, that actually contained old /var/tmp,
because I am a bit afraid to update my old and still working Gentoo
system on the same hard disk that I have not updated for about 9 months.

Moreover, I have changed profile from not used for a long time
default/linux/amd64/13.0/desktop/gnome
one to
default/linux/amd64/17.0/desktop/
and already found out a lot of not wise solutions like alsa + pulseaudio
with initrc and the likes that I currently trying to avoid.

> Anyone think that wouldn't work???  Basically, you are just telling
> emerge/portage to build somewhere else and it shouldn't care where that
> is, tmpfs or disk.  Right?

It is exactly what suggested in the "Per-package choices at compile time"
section of the "Portage TMPDIR on tmpfs” Gentoo wiki. So it should work. :)

Re: [gentoo-user] Re: /var/tmp on tmpfs

2018-02-09 Thread Neil Bothwick 
On Thu, 8 Feb 2018 22:50:58 +, Tsukasa Mcp_Reznor wrote:

> Just adding my 2 cents EMERGE_DEFAULT_OPTS="--fail-clean" helps a ton
> with tmpfs.

But it doesn't help much when your chromium build fails with 30 minutes to
go and a quick(ish) "ebuild path/to/ebuild merge" would have fixed it, as
has happened to me a few times recently :(


-- 
Neil Bothwick

Top Oxymorons Number 4: Diet ice cream


pgpm6zcGQni4J.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Gerrit Kühn 
On Fri, 9 Feb 2018 12:30:21 +0200 gevisz  wrote about
Re: [gentoo-user] /var/tmp on tmpfs:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!
> 
> It is an interesting idea. But why it is not done by default then?
> 
> Can somebody think of a situation when it should not be done?

/var/tmp/portage may take up quite some space, and not everybody will want
to have that on a RAM-based fs.


cu
  Gerrit

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Neil Bothwick 
On Fri, 09 Feb 2018 10:12:01 +, Peter Humphrey wrote:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!  
> 
> Acting on the advice of various Gentoo guides, I have this:
> 
> # grep tmp /etc/fstab
> tmpfs   /var/tmp/portagetmpfs
> noatime,uid=portage,gid=portage,mode=0775  0 0
> tmpfs   /tmptmpfs
> noatime,nosuid,nodev,noexec,mode=1777   0 0
> 
> Are you saying I don't gain anything from it?

I can't see any benefit from the added complexity. If you want portage to
use a tmpfs for its temporary directory, why not use one that is already
there?


-- 
Neil Bothwick

Fragile. Do not turn umop ap1sdn!


pgpS5xWLB7e3x.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Neil Bothwick 
On Fri, 9 Feb 2018 12:30:21 +0200, gevisz wrote:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!  
> 
> It is an interesting idea. But why it is not done by default then?
> 
Because when the defaults were picked neither /tmp nor /var/tmp used
tmpfs but /tmp was cleared at boot. Some of the default for portage are
curious, to say the least, like using /usr for dynamic data.


-- 
Neil Bothwick

667 - The FAX number of the beast


pgpguP3vBXdwN.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread gevisz 
2018-02-09 3:24 GMT+02:00 Dale :
>
> In my experience, once swap starts getting used, it gets slow, sometimes
> to the point that a response may take several seconds or more.  When I
> compile without tmpfs at all, which means everything is on disk, it's
> rare that I can even tell it is using that IO for the drive.

Thank you for the information. It is always good to know the downside
of your decision. In this case, of using the swap.

So far, I never saw my swap busy, even when running VirtualBox with
half of my RAM assigned to it.

> The catch is, take advice from different folks and weigh all the
> options, then test things to see what works best.  It may be that one
> part of your post helps, another part from mine, another part from
> someone else and in the end, it leaves settings that work.  Well, on
> that system and for that person at least.  ;-)

Yes. I am greatfull to all who wrote to this thread. :)

[gentoo-user] Re: Forced rebuild of a package...how?

2018-02-09 Thread Kai Krakow 
Am Fri, 09 Feb 2018 11:39:25 +0100 schrieb Kai Krakow:

> Am Sun, 04 Feb 2018 05:20:03 +0100 schrieb tuxic:
> 
>> after installing linux-4.15.1 (downloaded from kernel.org) I want to
>> reinstall (beside others) nvidia drivers.
>> 
>> Emerge told me:
>> |>emerge nvidia-drivers
>> |Calculating dependencies... done!
>> |>>> Jobs: 0 of 0 complete   Load avg: 1.05, 
>> 0.65, 0.34
>> |>>> Auto-cleaning packages...
>> |
>> |>>> No outdated packages were found on your system.
>> 
>> 
>> That is valid for the previous installed kernel...but not for the one 
>> 
>> This was updated just before
>> Sun Feb  4 04:21:46 2018 <<< sys-apps/portage-2.3.23
>> Sun Feb  4 04:21:51 2018 >>> sys-apps/portage-2.3.24
>> 
>> My make.conf has this options:
>> EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4 --changed-deps-report=n 
>> --changed-deps"
>> 
>> 
>> Thanks for any help in advance!
> 
> I'm using this script to automate the process:
> 
> $ cat /etc/kernel/postinst.d/70-emerge-module-rebuild
> #!/bin/bash
> exec env -i PATH=$PATH /usr/bin/emerge -1v --usepkg=n @module-rebuild
> 
> (I don't know why "env -i PATH=$PATH" is needed but otherwise it won't
> work correctly sometimes)

After reading the rest of the thread, it is now:

$ cat /etc/kernel/postinst.d/70-emerge-module-rebuild
#!/bin/bash
exec env -i PATH=$PATH /usr/bin/emerge -1v --usepkg=n --selective=n 
@module-rebuild


> You could add "--changed-deps=n" there because otherwise it won't play
> well with using "--changed-deps" as a default.
> 
> Now, when you run "make modules_install install", it will automatically
> rebuild kernel modules.
> 
> BTW, I have another script to also install the kernel in systemd-boot
> which also rebuilds initramfs (dracut here):
> 
> $ cat /etc/kernel/postinst.d/zz-systemd-boot
> #!/bin/bash
> /usr/bin/kernel-install remove $1 $2
> /usr/bin/kernel-install add $1 $2





-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Forced rebuild of a package...how?

2018-02-09 Thread Kai Krakow 
Am Sun, 04 Feb 2018 05:20:03 +0100 schrieb tuxic:

> after installing linux-4.15.1 (downloaded from kernel.org) I want to
> reinstall (beside others) nvidia drivers.
> 
> Emerge told me:
> |>emerge nvidia-drivers
> |Calculating dependencies... done!
> |>>> Jobs: 0 of 0 complete   Load avg: 1.05, 
> 0.65, 0.34
> |>>> Auto-cleaning packages...
> |
> |>>> No outdated packages were found on your system.
> 
> 
> That is valid for the previous installed kernel...but not for the one 
> 
> This was updated just before
> Sun Feb  4 04:21:46 2018 <<< sys-apps/portage-2.3.23
> Sun Feb  4 04:21:51 2018 >>> sys-apps/portage-2.3.24
> 
> My make.conf has this options:
> EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4 --changed-deps-report=n 
> --changed-deps"
> 
> 
> Thanks for any help in advance!

I'm using this script to automate the process:

$ cat /etc/kernel/postinst.d/70-emerge-module-rebuild
#!/bin/bash
exec env -i PATH=$PATH /usr/bin/emerge -1v --usepkg=n @module-rebuild

(I don't know why "env -i PATH=$PATH" is needed but otherwise it won't
work correctly sometimes)


You could add "--changed-deps=n" there because otherwise it won't play
well with using "--changed-deps" as a default.

Now, when you run "make modules_install install", it will automatically
rebuild kernel modules.

BTW, I have another script to also install the kernel in systemd-boot
which also rebuilds initramfs (dracut here):

$ cat /etc/kernel/postinst.d/zz-systemd-boot
#!/bin/bash
/usr/bin/kernel-install remove $1 $2
/usr/bin/kernel-install add $1 $2


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread gevisz 
2018-02-09 10:11 GMT+02:00 Neil Bothwick :
> On Thu, 8 Feb 2018 23:18:19 +, Wol's lists wrote:
>
>> > More specifically, /var/tmp is traditionally supposed to be
>> > non-volatile (across reboots).
>> >
>> > Comparatively the contents of /tmp can be volatile (across reboots).
>> >
>> > I would advise against mounting /var/tmp on tmpfs.
>> >
>> EMPHATICALLY YES.
>>
>> /tmp is defined as being volatile - stuff can disappear at any time.
>>
>> /var/tmp is defined as the place where programs store stuff like crash
>> recovery files. Mounting it tmpfs is going to screw up any programs
>> that reply on that *defined* behaviour to recover after a crash.
>>
>> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know -
>> I do it myself.
>
> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> make.conf. Job done!

It is an interesting idea. But why it is not done by default then?

Can somebody think of a situation when it should not be done?

My /tmp is not on tmpfs currently. Only /run

May be, it is not a good idea to put /mnt on tmpfs at the time of
Spector and Meltdown?

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Peter Humphrey 
On Friday, 9 February 2018 08:11:29 GMT Neil Bothwick wrote:
> On Thu, 8 Feb 2018 23:18:19 +, Wol's lists wrote:
> > > More specifically, /var/tmp is traditionally supposed to be
> > > non-volatile (across reboots).
> > > 
> > > Comparatively the contents of /tmp can be volatile (across reboots).
> > > 
> > > I would advise against mounting /var/tmp on tmpfs.
> > 
> > EMPHATICALLY YES.
> > 
> > /tmp is defined as being volatile - stuff can disappear at any time.
> > 
> > /var/tmp is defined as the place where programs store stuff like crash
> > recovery files. Mounting it tmpfs is going to screw up any programs
> > that reply on that *defined* behaviour to recover after a crash.
> > 
> > Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know -
> > I do it myself.
> 
> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> make.conf. Job done!

Acting on the advice of various Gentoo guides, I have this:

# grep tmp /etc/fstab
tmpfs   /var/tmp/portagetmpfs   
noatime,uid=portage,gid=portage,mode=0775  0 0
tmpfs   /tmptmpfs   
noatime,nosuid,nodev,noexec,mode=1777   0 0

Are you saying I don't gain anything from it?

-- 
Regards,
Peter.

Re: [gentoo-user] Re: /var/tmp on tmpfs

2018-02-09 Thread gevisz 
2018-02-09 0:50 GMT+02:00 Tsukasa Mcp_Reznor :
> From: freemanr...@gmail.com  on behalf of Rich
> Freeman 
> Sent: Thursday, February 8, 2018 5:38 PM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] Re: /var/tmp on tmpfs
>
> Just adding my 2 cents EMERGE_DEFAULT_OPTS="--fail-clean" helps
> a ton with tmpfs.

Thank you for the suggestion! Already added it to my make.conf.

> As for the athlon x2 system, consider using distcc, I've been using it for
> quite awhile, I don't think it helps with the ram usage

I am using -march=native in CFLAGS/CXXFLAGS and because of this
reluctant to use distcc, but it is a good idea too.

Re: [gentoo-user] /var/tmp on tmpfs

2018-02-09 Thread Neil Bothwick 
On Thu, 8 Feb 2018 23:18:19 +, Wol's lists wrote:

> > More specifically, /var/tmp is traditionally supposed to be
> > non-volatile (across reboots).
> > 
> > Comparatively the contents of /tmp can be volatile (across reboots).
> > 
> > I would advise against mounting /var/tmp on tmpfs.
> >   
> EMPHATICALLY YES.
> 
> /tmp is defined as being volatile - stuff can disappear at any time.
> 
> /var/tmp is defined as the place where programs store stuff like crash 
> recovery files. Mounting it tmpfs is going to screw up any programs
> that reply on that *defined* behaviour to recover after a crash.
> 
> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know - 
> I do it myself.

Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
make.conf. Job done!


-- 
Neil Bothwick

Why do Kennedy's cry after sex? . Mace!


pgpHiNxNbQjnk.pgp
Description: OpenPGP digital signature