Re: [gentoo-user] ebuild : how to check for python version

[Mike Gilbert]

On Tue, Aug 11, 2020 at 9:38 AM Helmut Jarausch  wrote:
>
> On 08/11/2020 03:08:16 PM, Mike Gilbert wrote:
> > On Sun, Aug 2, 2020 at 10:47 AM Helmut Jarausch
> > <_ j_ a_ r_ a_ u_ s_ c_ h_ @_ s_ k_ y_ n_ e_ t_ ._ b_ e> wrote:
> >  Hi,
> >  in an ebuild I have to apply a patch only if this package is
> >  installed
> >  for python3.9.
> >  The ebuild should work for PYTHON_COMPAT=( python3_{8,9} )
> >
> >  How can I check for Pythons version in src_prepare or similar
> >  functions.
> >
> >  Many thanks for a hint,
> >  Helmut
> >
> > I would suggest creating a patch that can be applied unconditionally
> > instead.
> >
>
> That would imply different function definitions within an 'if / else'
> clause.
> I don't like this.
>

What will you do when someone wants/needs to install it for both
python3.8 and python3.9 simultaneously?

If you want to support both versions, it's better to have code that
actually works with both of them.

Re: [gentoo-user] ebuild : how to check for python version

[Mike Gilbert]

On Sun, Aug 2, 2020 at 10:47 AM Helmut Jarausch  wrote:

> Hi,
> in an ebuild I have to apply a patch only if this package is installed
> for python3.9.
> The ebuild should work for PYTHON_COMPAT=( python3_{8,9} )
>
> How can I check for Pythons version in src_prepare or similar functions.
>
> Many thanks for a hint,
> Helmut
>
> I would suggest creating a patch that can be applied unconditionally
instead.

Re: [gentoo-user] How can I force emerge to use python 3.6?

[Mike Gilbert]

On Fri, May 15, 2020 at 10:17 PM William Kenworthy  wrote:
>
> Hi Victor,
>
> emerge crashes when it tries to add metadata during the merge stage
> in an emerge installed python module using 3.7 when the PKGDIR is on a
> moosefs share.  When PKGDIR is local its fine.

I have never heard of moosefs. It probably returns an error when
portage tries to use some of the more advanced file syscalls. Please
file a bug report.

Re: [gentoo-user] How can I force emerge to use python 3.6?

[Mike Gilbert]

On Fri, May 15, 2020 at 10:17 PM William Kenworthy  wrote:
>
> Hi Victor,
>
> emerge crashes when it tries to add metadata during the merge stage
> in an emerge installed python module using 3.7 when the PKGDIR is on a
> moosefs share.  When PKGDIR is local its fine.
>
> I am rebuilding some systems now with 3.6 as the PYTHON_SINGLE_TARGET
> but I was hoping for some way to specify emerge use 3.7 or 3.6 without
> having to rebuild portage and all its dependencies everytime I want to
> switch and test ...

Set PYTHON_TARGETS=pytthon3_6. This will ensure portage and its
dependencies are built for python3.6.

You can then set python3.6 as the default interpreter globally by
putting it first in /etc/python-exec/python-exec.conf. There's a
comment with instructions at the top of that file.

If you only want emerge to use python3.6, put it in
/etc/python-exec/emerge.conf instead.

Re: [gentoo-user] complete switch from openssl to libressl on gentoo

[Mike Gilbert]

On Fri, Apr 17, 2020 at 1:50 PM Francesco Turco  wrote:
>
> > However, is there a good reason for opting for libressl instead of the
> > ubiquitous openssl?
>
> I haven't tried libressl yet, but the main reason I'm interested in trying it 
> is due to the fact it doesn't have a "bindist" USE flag. In fact some 
> packages require openssl to be built with the "-bindist" USE flag, but I 
> don't like that. By switching to libressl I hope to work around that problem.

That is a terrible reason for switching. libressl likely has the same
issue with patents, it just doesn't bother to give you the choice of
opting out.

Re: [gentoo-user] Per package /bin/sh selection

[Mike Gilbert]

On Wed, Apr 8, 2020 at 1:17 PM Joerg Schilling
 wrote:
>
> Mike Gilbert  wrote:
>
> > Wikipedia says that dash is a fork of NetBSD's ash, and I do see tests
> > in their CVS repo. That might be worth looking into.
> >
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/bin/sh/
>
> I see this is the variant from Rihard Elz, so it may make sense.
> The original ash is too buggy as a reference.
>
> > > When ever I change something in bosh, I run the unit tests to verify that 
> > > I did
> > > not introduce a bug. One of the unit tests is to run a configure and 
> > > compare
> > > the results with the results frm a reference shell.
> > >
> > > BTW: Did you ever think about replacing dash by bosh?
> >
> > We use bash as the default /bin/sh, but users are free to replace it
> > with whatever shell they like, so long as it is reasonably
> > POSIX-compliant. Other shells are obviously less tested in Gentoo.
>
> Well, bosh has been tested to work as /bin/sh on Gentoo.
> BTW: On Solaris, bosh is faster than dash (because Solaris has a fully working
> vfork()). On Linux bosh is "only" of the same speed as dash since vfork() on
> Linux does not borrow the parents address space description but copies it.

Is that also true of clone(CLONE_VM|CLONE_VFORK)? Recent versions of
glibc use this to implement the posix_spawn() function.

Re: [gentoo-user] CHOST for Celeron J4105 processor

[Mike Gilbert]

On Wed, Apr 8, 2020 at 7:50 AM William Kenworthy  wrote:
>
>
> On 8/4/20 7:19 pm, Michael wrote:
> > On Tuesday, 7 April 2020 06:43:44 BST William Kenworthy wrote:
> >> Hi,
> >>
> >>   I have an Odroid H2 with a Celeron J4105 processor which appears to
> >> be a Gemini Lake, Goldmont Plus architecture
> >>
> >> Any idea what CHOST this should be?
> >>
> >> BillK
> > I don't have one of those, but it is an x86_64 Quad core SoC.  This should 
> > do
> > it:
> >
> > CHOST="x86_64-pc-linux-gnu"
> >
> > Useful links:
> >
> > https://wiki.gentoo.org/wiki/CHOST
> > https://wiki.gentoo.org/wiki/Safe_CFLAGS
>
> Hi, yes that is what the reference pages give - but I am hoping there is
> something that is evidence backed as being a better choice - what you
> quote is their example, no details on whether it matches my architecture
> or not.  The installation default is "i686-pc-linux-gnu" which is a
> catch-all lowest common type.

If your installation defaults to i686-pc-linux-gnu, you picked the
wrong stage3 tarball. You want amd64, not x86.

CHOST for amd64 is always x86_64-pc-linux-gnu. You can specialize that
by adding -march=foo to CFLAGS in make.conf.

Re: [gentoo-user] Per package /bin/sh selection

[Mike Gilbert]

On Wed, Apr 8, 2020 at 8:44 AM Joerg Schilling
 wrote:
>
> Michael Orlitzky  wrote:
>
> > Thanks, this will be a PITA for a while (again). Another developer had
> > patched /bin/dash so that it was effectively broken, to the point where
> > ./configure scripts would decide on their own use bash instead (even if
> > you set /bin/sh to point to dash). This "fixed" the errors, but meant
>
> Are there no unit tests for dash?

There do not appear to be any tests in the dash source repo.

https://git.kernel.org/pub/scm/utils/dash/dash.git/

Wikipedia says that dash is a fork of NetBSD's ash, and I do see tests
in their CVS repo. That might be worth looking into.

http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/bin/sh/

> When ever I change something in bosh, I run the unit tests to verify that I 
> did
> not introduce a bug. One of the unit tests is to run a configure and compare
> the results with the results frm a reference shell.
>
> BTW: Did you ever think about replacing dash by bosh?

We use bash as the default /bin/sh, but users are free to replace it
with whatever shell they like, so long as it is reasonably
POSIX-compliant. Other shells are obviously less tested in Gentoo.

Re: [gentoo-user] Per package /bin/sh selection

[Mike Gilbert]

On Tue, Apr 7, 2020 at 2:48 PM Alessandro Barbieri
 wrote:
>
> I already filed bugs here:
>
> https://bugs.gentoo.org/716504
> https://bugs.gentoo.org/716496
>
> I need the workaround for the two above plus this 
> https://bugs.gentoo.org/714094

In the future, please mention you are using dash as /bin/sh and block
bug 714092 when you file bugs about this kind of issue. The fontforge
bug report doesn't mention anything about it.

Re: [gentoo-user] Re: How to configure keyboard layout for X11 libinput?

[Mike Gilbert]

On Mon, Apr 6, 2020 at 11:12 AM Grant Edwards  wrote:
>
> On 2020-04-06, Grant Edwards  wrote:
> > On 2020-04-06, Michael  wrote:
> >
> >> Did you try '/etc/X11/xorg.conf.d/10-evdev.conf' ?
> >
> > My keyboard config is in /etc/X11/xorg.conf.d/30-keyboard.conf
> >
> > The control/capslock key mapping still works, but the keyboard layout
> > is borked.  If I remove that file, the control/capslock mapping stops
> > working (as expected), and the kayboard layout is OK.
> >
> > Next, I tried just removing 'Option "XkbLayout'", and that made no
> > difference.  Here is what I started with:
> >
> > Section "InputClass"
> > Identifier "keyboard-all"
> > Driver "libinput"
> > Option "XkbLayout" "us"
> > Option "XkbRules" "xorg"
> > Option "XkbOptions" "ctrl:nocaps,compose:ralt"
> > MatchIsKeyboard "on"
> > EndSection
>
> I also had to remove the "XkbRules" option.  Now the keyboard mapping
> is back to "normal".  'Twould be nice if things like that were
> documented somewhere, but I'm not sure where it would be...

Take a look at the libinput(4) man page, which is installed by
x11-drivers/xf86-input-libinput.

Re: [gentoo-user] Still questions concerning a reasonable setup of a new system: UEFI &&/|| MTBR

[Mike Gilbert]

On Sat, Mar 28, 2020 at 12:13 PM Mark Knecht  wrote:
>
>
>
> On Sat, Mar 28, 2020 at 8:41 AM Mike Gilbert  wrote:
> >
> > On Sat, Mar 28, 2020 at 5:06 AM  wrote:
> > > ...because I have experienced neither any restrictions nor any
> > > fragilities in the last 12 years of using a MTB setup with that
> > > "MS-DOS" setup (technically it is more a MTB-setup. MSDOS refers
> > > to V/FAT, which needs to be used with UEFI in the first partition
> > > as far as I know...isn't it?)
> > >
> > > In short: Never chance a runnig system.
> > >
> > > But let us better discuss on a more technical level, since I asked
> > > for technical help and not for more rethorical given question as
> > > an answer.
> >
> > Here's a technical reason to prefer GPT universally: it stores 2
> > copies of the partition table, one at the start of the disk and one at
> > the end of the disk. If either copy gets destroyed, you should be able
> > to recover the partition table from the other copy.
>
> Mike,
>What's the process for doing that in general? I assume it's fundamentally 
> to copy the one at the end (what tools) and then to place it back at the 
> beginning? (what tools?

The top hit on Google is this: https://www.rodsbooks.com/gdisk/repairing.html

It documents recovery options using the "gdisk" tool (sys-apps/gptfdisk).

Re: [gentoo-user] Still questions concerning a reasonable setup of a new system: UEFI &&/|| MTBR

[Mike Gilbert]

On Sat, Mar 28, 2020 at 5:06 AM  wrote:
> ...because I have experienced neither any restrictions nor any
> fragilities in the last 12 years of using a MTB setup with that
> "MS-DOS" setup (technically it is more a MTB-setup. MSDOS refers
> to V/FAT, which needs to be used with UEFI in the first partition
> as far as I know...isn't it?)
>
> In short: Never chance a runnig system.
>
> But let us better discuss on a more technical level, since I asked
> for technical help and not for more rethorical given question as
> an answer.

Here's a technical reason to prefer GPT universally: it stores 2
copies of the partition table, one at the start of the disk and one at
the end of the disk. If either copy gets destroyed, you should be able
to recover the partition table from the other copy.

Re: [gentoo-user] executing a file on a usb thumb drive

[Mike Gilbert]

On Sat, Mar 21, 2020 at 8:39 AM William Kenworthy  wrote:
>
> I have an encrypted usb thumb drive I use to transfer files from work
> (Win10) to home (gentoo) - the encryption and access is via a program
> that is stored and executed from the thumb drive.
>
> Some time back, it became impossible to execute files stored on the
> thumb drive.  I found I could get it to work if it was mounted within
> the users home directory.  Since the last round of updates that has
> become broken as well.

I'm aware of 2 things that would break this:

- The filesystem is mounted with the noexec flag set.
- For filesystems that don't have permissions natively (like FAT), the
filesystem is mounted with a umask that prevents the execute bit from
being set.

You could check both of these things in /proc/mounts when the
filesystem is mounted.

How to fix it depends on what is actually mounting the filesystem in
the first place. How do you access the drive after you plug it in?

Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions

[Mike Gilbert]

On Thu, Feb 6, 2020 at 10:23 PM Matt Connell  wrote:
>
> On 2020-02-06 11:40, Ian Zimmerman wrote:
> > 5.4 has just become the newest LTS.
>
> I see that now.  But my original question still stands as to why the
> stable version of gentoo-sources is consistently a few versions behind
> the latest LTS release.

Typically, Gentoo maintainers leave new versions in ~arch for some
time so they can be tested by a broad set of people. Stabilization
bugs are normally not filed until a given version has spent at least
30 days in ~arch.

See GLEP 40 for details on this process.

https://www.gentoo.org/glep/glep-0040.html

Re: [gentoo-user] /usr/portage/distfiles vs /var/cache/distfiles

[Mike Gilbert]

On Tue, Jan 14, 2020 at 5:05 PM Paul B. Henson  wrote:
>
> I recently installed a new server, and noticed that it is using
> /var/cache/distfiles rather than /usr/portage/distfiles. looking at the
> documentation, it seems that is the new default, and it says "new
> installations" will use it. I have older servers which are still using
> /usr/portage/distfiles. None of them have DISTDIR configured, so I am
> curious how portage is deciding between "old" and new"? If I wanted to
> migrate my older boxes to the new location without explicitly setting
> DISTDIR on them, what do I need to change?

The portage ebuild has some code that automatically patches
/usr/share/portage/config/make.globals for existing installs. You can
update the setting there.

Alternatively, you can perform the following steps to make the portage
ebuild update make.globals for you.

1. Set DISTDIR to anything other than /usr/portage/distfiles in
/etc/portage/make.conf
2. Re-install sys-apps/portage.
3. Remove the DISTDIR setting from /etc/portage/make.conf.

>From then on, portage will no longer patch the default DISTDIR setting
in make.globals.

Reference: 
https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/_compat_upgrade/default_locations.py?h=portage-2.3.84

Re: [gentoo-user] Gentoo's Python policy drives me crazy

[Mike Gilbert]

On Mon, Dec 16, 2019 at 2:07 PM Rich Freeman  wrote:
>
> On Mon, Dec 16, 2019 at 2:00 PM Helmut Jarausch  wrote:
> >
> > Today's updating involves some package which causes rebuilding
> > a package which needs Python2.7 and another one which needs
> > python_single_target_python3_8
> > required by that mysterious @__auto_slot_operator_replace_installed__
> >
> > To emerge the Python2.7 package (Scribus) I do need to set
> > PYTHON_SINGLE_TARGET="python2_7"
> > in /etc/portage/make.conf
> > which makes the whole update fail since the other packages needs
> > PYTHON_SINGLE_TARGET="python3_8"
> >
> > So, what can I brave Gentoo user do?
> >
>
> Set PYTHON_SINGLE_TARGET in package.env and not make.conf.  That is
> definitely a setting that can't be set globally.

Alternatively, you can set it in package.use:

app-office/scribus PYTHON_SINGLE_TARGET: python2_7

If the package supports several python versions, "-*" might come in handy.

app-editors/vim PYTHON_SINGLE_TARGET: -* python3_7

Re: [gentoo-user] Kernel option missing - very frustrating...

[Mike Gilbert]

On Sun, Dec 15, 2019 at 2:42 PM Daniel Frey  wrote:
>
> On 2019-12-15 09:36, Franz Fellner wrote:
> > I can't see CONFIG_VIDEO_DEV in your list.
>
> It's not supposed to be: "=n".

I think you are reading that incorrectly. VIDEO_DEV [=n] means the
VIDEO_DEV option is required, but you currently have it disabled.

Re: [EXTERNAL] [gentoo-user] Chromium on linux, build question

[Mike Gilbert]

On Tue, Sep 17, 2019 at 2:12 PM John Covici  wrote:
>
> On Tue, 17 Sep 2019 13:21:45 -0400,
> Laurence Perkins wrote:
> >
> > [1  ]
> >
> >
> > On Sun, 2019-09-15 at 05:45 -0400, John Covici wrote:
> > > Hi.  I want to have Chromium  on linux, but I want to build the
> > > Chrome
> > > OS version, so I can have their version of the accessibility plugin
> > > which is called Chrom next.  I did not see any use flags, so how can
> > > I
> > > do this on gentoo?  I am using the unstable version of gentoo.  It is
> > > my understanding that this can be done on Debian and other
> > > distributions.
> > >
> > > Thanks in advance for any suggestions.
> > >
> > I believe what you're probably looking for is the chrome-binary-plugins
> > package.  This downloads the binary version of Chrome and pulls all the
> > Google-proprietary bits out of it and loads them into your Chromium.
> >
> > Of course, at that point you might as well just use Chrome...  But I
> > suppose you could try whacking out the ones you don't want and see what
> > happens.
>
> What I am trying to do is to build chromium in such a way that I can
> use the assistive technology called Chrome next which requires chrome
> for chrome os.  Does that make sense?

If you can figure out what kind of flags we need to pass to the build
system, please file a bug and we can add a USE flag for it.

Re: [gentoo-user] systemd crashes when I try to mount a USB drive

[Mike Gilbert]

On Thu, Aug 1, 2019 at 9:59 AM Helmut Jarausch  wrote:
>
> Hi,
> since the upgrade from systemd-242-r6 to systemd-243_rc1 I cannot mount
> my (external) USB drive any more.
> I get
> kernel: sd 10:0:0:0: [sde] Assuming drive cache: write through
> kernel:  sde: sde1 sde2 sde3 sde4 sde5 sde6 sde7
> kernel: systemd-udevd[480887]:
> Assertion 'key' failed at src/libsystemd/sd-device/device-private.c:34,
> function device_add_property(). Aborting.
>
> The strange thing is, I don't use systemd on start-up (I'm using
> openrc) but I have systemd installed here.
> This configuration has been working for a very long time.
>
> Many thanks for a hint,
> Helmut

A failed assertion almost always means there is a programming error in
the software. Please report the issue to the systemd developers.

https://github.com/systemd/systemd/issues

Re: [gentoo-user] Re: Does root=PARTUUID=<> work with DOS partition table?

[Mike Gilbert]

On Thu, Jul 25, 2019 at 11:25 AM Grant Edwards
 wrote:
>
> On 2019-07-25, Grant Edwards  wrote:
>
> > All the examples I can find of people using root=PARTUUID=<> show the
> > longer PARTUUID values you get with a GPT parition table.  Does the
> > root=PARTUUID=<> mechanism only work with GPT and not with DOS
> > parition tables?
>
> The comments in the kernel source certinaly indicate that DOS PARTUUID
> values should work.  From init/do_mounts.c:
>
> /*
>  *  Convert a name into device number.  We accept the following variants:
> [...]
>  *  6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
>  * unique id of a partition if the partition table provides it.
>  * The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
>  * partition using the format -PP, where  is a zero-
>  * filled hex representation of the 32-bit "NT disk signature", and PP
>  * is a zero-filled hex representation of the 1-based partition 
> number.
>  [...]
>
> I've also tried just passing root=/dev/sdb1 (which in the current
> setup is consistently the device the root partition shows up on).
> That doesn't work either and I'm begining to suspect that the kernel
> simply isn't recognizing the USB storage device at all.
>
> I wish I could figure out how to get scrollback to work so I could see
> all of the kernel messages before the panic...

Do you have all the necessary USB drivers compiled into the kernel?
Check to make sure the following options are "y".

CONFIG_USB_EHCI_HCD -- USB 2.0
CONFIG_USB_OHCI_HCD -- USB 1.0 (non-Intel)
CONFIG_USB_UHCI_HCD -- USB 1.0 (Intel)
CONFIG_USB_XHCI_HCD -- USB 3.0

CONFIG_USB_STORAGE
CONFIG_BLK_DEV_SD

Re: [gentoo-user] Can't compile x11-libs/libXt

[Mike Gilbert]

On Tue, Jul 23, 2019 at 12:51 PM Jens Pelzetter
 wrote:
>
> Hallo all,
>
> Am 23.07.19 um 17:14 schrieb Mick:
> > On Tuesday, 23 July 2019 16:01:01 BST Raffaele Belardi wrote:
> >
> >>> Am 23.07.19 um 01:31 schrieb Jack:
> >
> > On multilib:
> >
> > $ ls -la /etc/env.d/gcc/
> > total 16
> > drwxr-xr-x 2 root root 4096 Jun 11 12:23 .
> > drwxr-xr-x 5 root root 4096 Jul 20 16:53 ..
> > lrwxrwxrwx 1 root root   25 Jun 11 12:23 .NATIVE -> 
> > x86_64-pc-linux-gnu-8.3.0
> > -rw-r--r-- 1 root root   34 Jun 11 12:23 config-x86_64-pc-linux-gnu
> > -rw-r--r-- 1 root root  358 Jun 11 12:23 x86_64-pc-linux-gnu-8.3.0
> >
> > The question must be why is emerge looking for config-i686-pc-linux-gnu?
> >
> > Has Jens messed about with CHOST= in /etc/portage/make.conf?
> >
> > Will the package build without complaining if emerged so:
> >
> > CHOST="x86_64-pc-linux-gnu" emerge -1aDv x11-libs/libXt
> >
>
> with CHOST="x86_64-pc-linux-gnu" emerge -1aDv x11-libs/libXt the ebuild
> produces the same error. CHOST in my make.conf is x86_64-pc-linux-gnu.
>
> env.d/gcc also looks fine:
>
> # ls -la /etc/env.d/gcc/
> total 16
> drwxr-xr-x 2 root root 4096 Jul 21 19:45 .
> drwxr-xr-x 7 root root 4096 Jul 22 19:21 ..
> lrwxrwxrwx 1 root root   25 Jul 21 19:45 .NATIVE ->
> x86_64-pc-linux-gnu-8.3.0
> -rw-r--r-- 1 root root   34 Jul 21 19:45 config-x86_64-pc-linux-gnu
> -rw-r--r-- 1 root root  358 Jul 19 21:18 x86_64-pc-linux-gnu-8.3.0
>
> Best regards
>
> Jens
>

You probably installed a (cross) toolchain with host=i686-pc-linux-gnu
at some point, and now you have stale symlinks leftover in /usr. Try
removing them.

Re: [gentoo-user] Re: Using UUID for root disk in grub requires initramfs?

[Mike Gilbert]

On Fri, Jul 19, 2019 at 12:37 PM Ian Zimmerman  wrote:
>
> On 2019-07-19 20:58, Adam Carter wrote:
>
> > I experimented found the following worked in /etc/default/grub;
> >
> > GRUB_DEVICE="PARTUUID=d3554d49-02"
> >
> > Which writes grub.cfg as;
> > linux /vmlinuz-5.2.0-gentoo root=PARTUUID=d3554d49-02 ro
> > init=/usr/lib/systemd/systemd iommu=pt raid=noautodetect
> >
> > PARTUUID looked up with blkid. No initramfs required :)
>
> I don't get this.  blkid is userspace.  The _kernel_ needs to know what
> the root fs device is, before it even starts pid 1.

The kernel init code is able to find a device given its PARTUUID.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/init/do_mounts.c?h=v4.19.59#n172

Re: [gentoo-user] Fdisk reports new HD as 10MiB

[Mike Gilbert]

On Fri, Jul 5, 2019 at 10:14 AM Vladimir Romanov  wrote:
>
> Fdisk can not work with drives larger than 2TB. Your drive may be slightly 
> (10 mb) larger than that, so the result. For such disks you need not Fdisk, 
> but GPT programs.

Correction: modern fdisk provided by util-linux supports
creating/modifying GPT disks, and emits a warning that MBR cannot be
used for disks over 2 TB. Just enter a "g" to switch to GPT mode.

That looks something like this:

% truncate -s 3T foo.img
% fdisk foo.img

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
The size of this disk is 3 TiB (3298534883328 bytes). DOS partition
table format cannot be used on drives for volumes larger than
2199023255040 bytes for 512-byte sectors. Use GUID partition table
format (GPT).

Created a new DOS disklabel with disk identifier 0x9a0d6a8c.

Command (m for help): g
Created a new GPT disklabel (GUID: 0B1A00C7-7E53-9644-ACD1-F9A4B67A34AA).

Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]

[Mike Gilbert]

On Wed, Jun 26, 2019, 7:30 PM Neil Bothwick  wrote:

> On Wed, 26 Jun 2019 18:00:22 -0500, »Q« wrote:
>
> > > In an OpenRC system there is no loginctl.  Consequently, unless we
> > > define a separate config in /etc/ to use shutdown (with sudo?) it
> > > won't work.  This systemd-ism may be worth a bug report.
> >
> > In /usr/share/sddm/sddm.conf.d/00default.conf I have
> >
> >   HaltCommand=/sbin/shutdown -h -P now
> >
> >   RebootCommand=/sbin/shutdown -r now
> >
> > I just checked it with sddm-0.18.0, then upgraded to 0.18.1-r1, and it
> > stayed the same, I guess because I have USE="-systemd".
>
> And on a systemd setup, I have
>
> HaltCommand=/usr/bin/systemctl poweroff
>
> so where did Mick's loginctl option come from?
>

elogind

>

Re: [gentoo-user] Systemd-boot not compiling

[Mike Gilbert]

On Mon, Apr 8, 2019 at 9:14 AM Peter Humphrey  wrote:
>
> Hello list,
>
> Is anyone else having trouble emerging systemd-boot-241? This machine has a
> small rescue system as an alternative boot, and I get a mysterious error when
> I emerge the package. The end of the log shows this:
>
> [248/248] x86_64-pc-linux-gnu-gcc  -o bootctl 'bootctl@exe/
> src_boot_bootctl.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-
> z,now -Wl,--gc-sections -O2 -march=haswell -pipe -Wl,-O1 -Wl,--as-needed -
> Wl,--start-group src/shared/libsystemd-shared-241.a src/libsystemd/
> libsystemd_static.a src/basic/libbasic.a /usr/lib64/libblkid.so -lrt /usr/
> lib64/libcap.so /usr/lib64/libmount.so -lrt -lm -Wl,--end-group -pthread '-
> Wl,-rpath,$ORIGIN/src/shared:$ORIGIN/src/libsystemd:$ORIGIN/src/basic' -Wl,-
> rpath-link,/var/tmp/portage/sys-boot/systemd-boot-241/work/systemd-boot-241-
> build/src/shared:/var/tmp/portage/sys-boot/systemd-boot-241/work/systemd-
> boot-241-build/src/libsystemd:/var/tmp/portage/sys-boot/systemd-boot-241/work/
> systemd-boot-241-build/src/basic
> stat: No such file or directory
>  * ERROR: sys-boot/systemd-boot-241::gentoo failed (compile phase):
>  *   (no error message)
>
> But it compiles just fine on the main system.
>
> Perhaps something is missing from the rescue system and hasn't been caught by
> the ebuild, but I can't think of what. If 'stat' had said what file or
> directory wasn't present, I'd be able to dig a bit deeper to find the problem.
>
> I see the same behaviour on another machine. Both are 64-bit, but only this
> one is ~amd64; the other one has a KEYWORD to enable systemd-boot.

The above log snippet is fairly useless. In the future, please make
sure to include the relevant log snippet, or attach/pastebin the
entire build log if in doubt.

The most important part of the log on bug 682908 was this:

Call stack:
 ebuild.sh, line 124:  Called src_compile
   environment, line 2145:  Called die
 The specific snippet of code:
  patchelf --remove-rpath bootctl || die

That tells me that the patchelf call in src_compile was failing and
gives a much better starting point than some cryptic "stat" error.

Re: [gentoo-user] Pick your hypothesis:

[Mike Gilbert]

On Thu, Jan 24, 2019 at 1:39 PM Alan Grimes  wrote:
> Some F-tard at Gentoo world headquarters left the portage tree in an
> inconsistient state, shrugged, and walked away.

Comments like this are very unwelcome, and your general attitude sucks.

If you continue to communicate this way, I will request you be banned
from this mailing list.

Re: [gentoo-user] march cflag for Intel Pentium Dual-Core E2160 SLA8Z Malay processor

[Mike Gilbert]

On Fri, Sep 28, 2018 at 5:33 AM Marc Joliet  wrote:
>
> Am Freitag, 28. September 2018, 06:04:29 CEST schrieb Walter Dnes:
> > mmxext does not have its own flag in /proc/cpuinfo.
>
> ???
>
> % cat /proc/cpuinfo
> [...]
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
> rdtscp lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid pni cx16 lahf_lm 
> cmp_legacy svm extapic cr8_legacy 3dnowprefetch vmmcall
>   
> ^^^ ^^
> (I hope the formatting doesn't get messed up, the point is that my 
> /proc/cpuinfo *does* show mmxext.)

That cpuid flag only appears on AMD processors. It is never set for
Intel processors.

cpuid2cpuflags makes a special exception for this case.

https://github.com/mgorny/cpuid2cpuflags/blob/master/src/x86.c#L71

Re: [gentoo-user] Cellphone VFAT datestamps versus linux datestamps

[Mike Gilbert]

On Mon, Aug 27, 2018 at 10:48 PM Walter Dnes  wrote:
>
>   So I went to an event on Friday August 24th, and snapped some pics on
> my cellphone.  Let's just say the datestamps were ridiculous.  Is there
> a conversion algorithm or program to correct it? This may be a Windows
> versus linux thing.  See attached listing...

A tip: gzipping a 7 KB text file before attaching it is not
particularly useful and makes it more difficult to view. If it were a
plain text attachment, I could just open it in Gmail without leaving
my web browser.

Re: [gentoo-user] python-3.6.5 rebuild fails on new install

[Mike Gilbert]

On Fri, Aug 17, 2018 at 8:58 PM Walter Dnes  wrote:
>
>   I'm re-purposing a Lenovo T400 notebook (CORE2 and 3 gigs ram) with a
> 32-bit Gentoo install.  I try to do "emerge -e @system" early in the
> install, when there's under 200 packages.  Anyhow, python 3.6.5 is not
> rebuilding. I've put in all the "final" USE flags for the system.  The
> buildlog is attached (gzipped).

The compiler was killed with signal SIGSEGV. You probably ran out of
memory or some similar problem. Check dmesg.

>   And a bit of a rant... WTF is the initial stage 3 built against PAM?
> I wasted an hour dicking around, trying to get ssh working, so that I
> could finish up the install.  I finally figured out that I had to set
> "usePAM no" in /etc/ssh/sshd_config as a temporary hack.  The root
> solution to the problem was to emerge openssh with USE="-pam".  I had
> that in my flags, but the "emerge -e @system" died before getting to
> openssh.

Most people want PAM. It's a good thing.

Re: [gentoo-user] Steam is still BROKEN

[Mike Gilbert]

On Sun, Jul 29, 2018 at 12:42 PM Daniel Salas Rodriguez
 wrote:
> Seems your iconv library is broken or just not there. Have you tried
> re-emerging it and then retrying?
>
> # emerge -v1 libiconv

On Linux, iconv is built into glibc. libiconv is only necessary if you
are using a different C library or different OS (like FreeBSD).

I assume Alan has done something weird that broke glibc in some funny
way. However, I would not bother trying to help him given his horrible
attitude.

Re: [gentoo-user] Setting PYTHON_TARGETS in make.conf is not supported?

[Mike Gilbert]

On Thu, Jul 26, 2018 at 10:57 AM Grand Duet  wrote:
>
> Just now I have tried to manually set
>
> PYTHON_TARGETS="python2_7 python3_6"
> PYTHON_SINGLE_TARGET="python3_6"
>
> in /etc/portage/make.conf and got the following error:
>
> # emerge --update --deep --with-bdeps=y --newuse --backtrack=120 --ask world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> !!! The ebuild selected to satisfy "app-text/asciidoc" has unmet requirements.
> - app-text/asciidoc-8.6.10::gentoo USE="-examples -graphviz -highlight
> -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="(-pypy) -python2_7"
> PYTHON_TARGETS="python2_7 (-pypy)"
>
>   The following REQUIRED_USE flag constraints are unsatisfied:
> exactly-one-of ( python_single_target_pypy python_single_target_python2_7 
> )
>
>   The above constraints are a subset of the following complete expression:
> exactly-one-of ( python_single_target_pypy
> python_single_target_python2_7 ) python_single_target_pypy? (
> python_targets_pypy ) python_single_target_python2_7? (
> python_targets_python2_7 )
>
> (dependency required by "app-text/dvisvgm-2.1.3::gentoo" [installed])
> (dependency required by "app-text/texlive-2017::gentoo[extra]" [installed])
> (dependency required by "@selected" [set])
> (dependency required by "@world" [argument])
>
> which is similar to those errors I got while trying to set
>
> PYTHON_TARGETS="python2_7 python3_5"
> PYTHON_SINGLE_TARGET="python3_5"
>
> before switching yesterday from python-3.5 to python-3.6 target.
>
> Does it mean that setting python targets in /etc/portage/make.conf is
> not supported any more?

No, setting PYTHON_TARGETS in make.conf should still work.

It looks like asciidoc only supports python2, and for some reason
portage is trying to disable python2_7. I'm not sure why that might
be; we enable python2_7 for asciidoc via profiles/base/package.use.

Have you made some odd change to your profile, or overridden something
in /etc/portage/package.use?

Re: [gentoo-user] Any real need to switch python targets back and forth every month?

[Mike Gilbert]

On Wed, Jul 25, 2018 at 7:58 AM Grand Duet  wrote:
>
> After today's emerge-webrsync, I have found that python_targets
> and python_single_targets use flags have been changed again
> from python3_5 to python3_6, which leads to a lot of recompilation.
>
> It already happened last month and a week later the both use flags
> was changed back, again with a lot of recompilations.
>
> And it was not the first time!
>
> Is any real need to switch python_targets and python_single_target
> back and forth every month?
>

It's very simple:

1. The default was switched to python3.6. This was probably a bit premature.
2. People complained that this broke their systems, so we reverted the
default back to python3.5.
3. The problems were fixed, so we switched the default back to python3.6.

Sorry to have wasted your precious computing time, but hey, people
make mistakes sometimes.

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Mike Gilbert]

On Sun, Jul 22, 2018 at 6:57 AM, Alan Mackenzie  wrote:
> The package was gnupg, which surely doesn't need to send email.

See bug 658164. It's not quite that straightforward. ;)

https://bugs.gentoo.org/658164

Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.

[Mike Gilbert]

On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie  wrote:
> Hello, Gentoo.
>
> Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
> a lot of restraint in avoiding the use of swear words in describing some
> Gentoo developer.
>
> ...
>
> nullmailer installs a file /usr/sbin/sendmail.  This masks out the
> correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
> installed by hand, not using emerge) because /usr/sbin is before
> /usr/bin in $PATH.
>
> ...
>
> But what's the proper method to tell my gentoo system that I don't want
> crud like nullmailer installed?  How can I guard myself against such
> presumptiousness on the part of the Gentoo devs in the future?

You must have installed a package that depends on virtual/mta,
presumably because it needs to send emails. Had you installed qmail
using portage, the virtual/mta dep would have been satisfied by it,
and nullmailer would not have been installed in the first place.
However, you didn't do that, and so portage had no idea qmail was
installed.

A possible workaround would be to add mail-mta/netqmail to
package.provided on your system. However, there's still no guarantee
that your custom-built qmail software will work with other packages
provided by Gentoo.

Regarding your accusations: Gentoo developers cannot anticipate every
possible thing you might do on your system, especially when you start
installing custom programs in paths that are traditionally managed by
our package manager. Using portage you can customize your system
extensively, without needing to custom build your own software. If
that's not good enough for you, go build a Linux from Scratch system
and enjoy the lack of any package management or support whatsoever.

Re: [gentoo-user] how to set python version for one user

[Mike Gilbert]

On Tue, Jul 10, 2018 at 4:23 AM,   wrote:
> Hi,
>
> I need to set specific python version to a user and I don't want to set it
> up for whole system. Is it possible? If so how to do it. All I found is
> about setting for whole system.

On Gentoo, you can set the EPYTHON environment variable.

floppym@naomi ~ % python --version
Python 3.6.6
floppym@naomi ~ % export EPYTHON=python2.7
floppym@naomi ~ % python --version
Python 2.7.15

Re: [gentoo-user] Problems updating glibc-2.26-r7

[Mike Gilbert]

On Sat, Jun 23, 2018 at 1:21 PM, wabe  wrote:
> "Andreas K. Huettel"  wrote:
>
>> Am Freitag, 22. Juni 2018, 20:11:51 CEST schrieb wabe:
>> > Hi folks,
>> >
>> > I have a problem and didn't find a solution yet.
>> >
>> > Upgrading glibc from 2.25-r11 to 2.26-r7 doesn't work. It says
>> >
>> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-lin
>> > ux-gnu-nptl/elf/sln
>> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li
>> > nux-gnu-nptl/elf/symlink.list
>> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li
>> > nux-gnu-nptl/elf/sln:
>> > /var/tmp/portage/portage/sys-libs/glibc-2.26-r7/work/build-x86-x86_64-pc-li
>> > nux-gnu-nptl/elf/sln: cannot execute binary file make[1]: ***
>> > [Makefile:106: install-symbolic-link] Error 126
>> >
>> > Compiling other packages is no problem. However when I try to
>> > reinstall glibc-2.25-r11 it also exits with an similar error at the
>> > end:
>>
>> [...]
>>
>> You're trying to make a multilib glibc, and your kernel does not
>> support one of the resulting ABIs (most likely CONFIG_IA32_EMULATION
>> needs to be turned on in the kernel configuration to be able to run
>> x86 binaries on an amd64 install).
>>
>> (That said, this is a rather stupid bug in the glibc build system and
>> needs to be fixed eventually.)
>
> Thank you very much for your answer.
>
> You are right. Compiling the kernel with CONFIG_IA32_EMULATION solved
> the problem. I switched from hardened kernel to gentoo standard kernel
> some time ago and just forget to compile it with that option.
>
> IIRC I build a multilib system many years ago because of grub. But maybe
> I don't need multilib anymore. How can I find out if I have x86 binaries
> installed?

This should give you a good start:

scanelf -M 32 /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt

Re: [gentoo-user] udev-238 and google?

[Mike Gilbert]

On Sat, May 19, 2018 at 3:53 AM, Mick  wrote:
> I noticed network related google variables being added in the compilation by
> emerge as udev was being updated to 238 today:
>
> ===
> Configuring systemd-update-done.service.tmp using configuration
> Configuring systemd-update-utmp-runlevel.service.tmp using configuration
> Configuring systemd-update-utmp.service.tmp using configuration
> Confi
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2907: WARNING: Trying to compare values of different types (bool,
> str) using ==.
> The result of this is undefined and will become a hard error in a future Meson
> release.
> meson.build:2
>  symbolic gateway hostnames:_gateway
>  default DNSSEC mode:   no
>  default cgroup hierarchy:  hybrid
>  default KillUserProcesses setting: true
>  default DNS servers:   8.8.8.8
> 8.8.4.4
> 2001:4860:4860::
> 2001:4860:4860::8844
>  default NTP servers:   time1.google.com
> time2.google.com
> time3.google.com
> time4.google.com
>  time epoch:1520288197
> (2018-03-05T22:16:37+00:00)
>
>  enabled features: PAM, IMA, SMACK, zlib, bzip2, ACL, qrencode,
> gnutls, libcurl, idn, nss-systemd, elfutils, binfmt, vconsole, quotacheck,
> tmpfiles, environment.d, sysusers, firstboot, randomseed, backlight, rfkill,
> logind, machined, hostnamed, timedated, timesyncd, localed, networkd, resolve,
> coredump, polkit, kmod, xkbcommon, pcre2, blkid, dbus, glib, nss-myhostname,
> hwdb, tpm, man pages, man page indices, SysV compat, utmp, ldconfig,
> hibernate, adm group, wheel group, gshadow
>
>  disabled features: libcryptsetup, AUDIT, AppArmor, SELinux, SECCOMP,
> xz, lz4, gcrypt, microhttpd, libidn2, libidn, libiptc, importd, legacy pkla,
> efi, gnu-efi, html pages, debug hashmap, debug mmap cache
> ==
>
> I don't know/understand why meson needs the above, but is there a reason
> google DNS and NTP servers take precedence over my system settings?

You are misinterpreting this output. Nothing is "taking precedence"
over your local settings.

systemd-udev is a component of systemd. To build it, we have to run
meson in the systemd source tree.

The DNS servers are used by systemd-resolved.
The NTP servers are used by systemd-timedated.

The meson build file defines default settings so that these programs
will work even on an unconfigured system.

systemd-udev does not utilize these settings, so they are completely
irrelevant for sys-fs/udev.

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

[Mike Gilbert]

On Mon, Apr 23, 2018 at 3:15 PM, Neil Bothwick  wrote:
> On Mon, 23 Apr 2018 08:37:42 -0700, Ian Zimmerman wrote:
>
>> > > Why did portage remove my python-3.5?
>> >
>> > Because nothing that depends on it isn't also satisfied by
>> > python-3.6?
>>
>> But doesn't the PYTHON_TARGETS with which a package is built create a
>> strict dependency on those pythons?  If native code extensions are
>> present, the compiled code won't in general be compatible with other
>> versions.
>
> AIUI PYTHON_TARGETS determines which python version extension modules are
> installed for. If you don't set PYTHON_TARGETS explicitly, portage sets
> it according to the versions you have installed.
>

You are incorrect; PYTHON_TARGETS is never calculated based on the
versions of python you have installed.

Re: [gentoo-user] shutdown: /run/initctl: No such file or directory ???

[Mike Gilbert]

On Fri, Mar 30, 2018 at 3:56 PM,   wrote:
> Hi,
>
> just a minute before I wanted to shutdown my Linux box...and...
> shutdown: /run/initctl: No such file or directory
>

See bug 651990. https://bugs.gentoo.org/651990

Either upgrade to sysvinit-2.89-r1, or run the following command
before rebooting or changing runlevels.

ln -s /dev/initctl /run/initctl

Re: [gentoo-user] The return of the dreaded "Cannot run C compiled programs"

[Mike Gilbert]

On Mon, Mar 26, 2018 at 9:19 AM, Peter Humphrey  wrote:
> I have a four-core 64-bit Celeron box with 4GB RAM, on which I've just
> installed a standard XFCE system on the desktop profile. It all went as
> expected, but when I ran an emerge -e world at the end I had two failures:
> both glibc and sandbox failed with the error in the subject line.
>
> It's some years since I last saw this error, and I'm stuck. I've looked
> through /etc hoping to find something skew-whiff, and I've compared the
> environment with this box's, but nothing stands out.
>
> Finally, following the hint in the portage output, I ran "FEATURES='-sandbox -
> usersandbox' emerge -1 --color n sandbox". It made no discernible difference.
>
> I've attached the logs etc from sandbox.
>
> Has anyone a clue?

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

Please take a look at the config.log file in the build directory; this
will probably have more detailed error information. Attach it here if
you would like me to take a look at it.

Re: [gentoo-user] Why does app-text/xmlto require a CLI web client?

[Mike Gilbert]

On Sun, Mar 11, 2018 at 9:24 AM, James Stevenson
 wrote:
> Hello,
>
> I was removing www-client/w3m the other day as I have recently switched
> over to emacs for my cli browser, however w3m was pulled in as a
> dependency of app-text/xmlto. xmlto, in turn is pulled in by
> sys-apps/dbus and x11-misc/xdg-utils. I decided to remove w3m with
> `emerge -C` before running a `change-use` command. xmlto began to
> merge www-client/lynx. I cannot find anything in the man pages about
> xmlto requiring a CLI web client but it apparently does. Does anyone
> have any idea what is going on? I do not have xmlto in my
> package.accept_keywords or package.use.

app-text/xmlto[text] depends on a text-based web browser to produce a
plain-text output from docbook XML.

See /usr/share/xmlto/format/docbook/txt for details.

Re: [gentoo-user] Is --changed-deps going to be *that* useless?

[Mike Gilbert]

On Mon, Feb 26, 2018 at 2:36 AM, Nikos Chantziaras  wrote:
> I've been using --changed-deps when doing a world upgrade ever since the
> news item that recommended it.
>
> However, today, this is what --changed-deps resulted in:
>
>   https://pastebin.com/raw/7RBx6zzt
>
> What... the actual... fuck.
>
> This is not OK. What the hell? This is just plain broken.

Someone probably changed a dependency in a commonly used eclass. I
would guess portage is operating as expected.

Re: [gentoo-user] Is ABI a portage variable?

[Mike Gilbert]

On Wed, Feb 14, 2018 at 7:10 PM, Ian Zimmerman  wrote:
> I am trying to package software whose build process (autotools based)
> depends on a variable "ABI" to determine (on x86 and amd64 arch at least)
> whether to build as 64 bit or 32 bit.  If it is not set externally, the
> configure script sets it by inspecting the native pointer size of the C
> compiler, to either "64" or "32".
>
> Naturally, I thought the cleanest way for a package was to leave it
> unset and let configure choose the native value.  But somehow it ends up
> with a setting "amd64" and then complains that it is not one of the
> expected values.  I am stuck determining where that value comes from.
> Is it portage?  If so, how to change or disable it?  Is it safe to just
> do the following?
>
> ABI='' ./configure

ABI is a profile variable. On an amd64 system it is defined in
profiles/arch/amd64/make.defaults.

The ABI variable is used by functions in multilib.eclass,
toolchain-funcs.eclass, and the econf function to determine the
correct libdir (lib, lib32, lib64, etc).

For an autotools build, you will probably want to call the econf
function, so unsetting ABI is a bad idea. Instead, you probably want
to "unexport" it (export -n). This will allow econf to see it, but the
value will not be inherited by configure.

src_configure() {
export -n ABI
econf
}

Re: [gentoo-user] preparing for the "systemd rootprefix migration"

[Mike Gilbert]

On Wed, Feb 7, 2018 at 3:28 PM, allan gottlieb  wrote:
> I run a stable system using gnome3 and hence systemd, specifically
> systemd-236-r5.  My bootloader is grub2.  I do *not* have an EFI
> platform and do *not* have an initramfs.
> I do *not* have a separate /usr filesystem.
>
> The news item says that, in preparation for the 237 release and the
> likely removal of the symlinks
>/usr/lib/systemd/systemd and
>/usr/lib/systemd/systemd-shutdown
> we should update our boot config to reference init=/lib/systemd/system
>
> 1.  Updating the boot config to reference init=/lib/systemd/system seems
> to mean a 1-line change in /etc/default/grub
>   GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" -->
>   GRUB_CMDLINE_LINUX="init=/lib/systemd/systemd"
> followed by the usual
>grub-mkconfig -o /boot/grub/grub.cfg
> Is that it?

Yes.

> 2.  What should I be doing to prepare for the removal of the
> /usr/lib/systemd/systemd-shutdown symlink?

You don't need to do anything specific here.

> 3.  "After upgrading, please run systemctl daemon-reexec".  Which
> upgrade is being referred to?  Is it the upgrade to the 237 release,
> with the likely removal of the two symlinks.

You should run that command after any systemd upgrade, but
specifically after upgrading from a version prior to 234.

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mike Gilbert]

On Mon, Jan 29, 2018 at 1:56 PM, Mick <michaelkintz...@gmail.com> wrote:
> On Monday, 29 January 2018 18:35:58 GMT Mike Gilbert wrote:
>> On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman <i...@very.loosely.org>
> wrote:
>> > On 2018-01-29 20:11, Adam Carter wrote:
>> >> Comparing the contents of
>> >> /sys/devices/system/cpu/vulnerabilities/spectre_v2
>> >>
>> >> With gcc 7.2 + kernel 4.14.15;
>> >> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>> >>
>> >> With gcc 7.3 + kernel 4.15.0;
>> >> Intel system shows; Mitigation: Full generic retpoline
>> >> AMD system shows' Mitigation: Full AMD retpoline
>> >
>> > Is there a simple way, with the upstream (kernel.org) sources, to force
>> > a compiler different from the system default?  If there is, it's not in
>> > the
>> > README, and a simple grep over the Makefiles also doesn't enlighten.
>> >
>> > I am not ready to activate a keyworded gcc for general use.
>>
>> You could pass CC=gcc-7.3.0 to the make command, like so:
>>
>> make -j6 CC=gcc-7.3.0
>
> Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0
> first?

I don't see any reason that would be necessary.

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mike Gilbert]

On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman  wrote:
> On 2018-01-29 20:11, Adam Carter wrote:
>
>> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2
>>
>> With gcc 7.2 + kernel 4.14.15;
>> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>>
>> With gcc 7.3 + kernel 4.15.0;
>> Intel system shows; Mitigation: Full generic retpoline
>> AMD system shows' Mitigation: Full AMD retpoline
>
> Is there a simple way, with the upstream (kernel.org) sources, to force
> a compiler different from the system default?  If there is, it's not in the
> README, and a simple grep over the Makefiles also doesn't enlighten.
>
> I am not ready to activate a keyworded gcc for general use.

You could pass CC=gcc-7.3.0 to the make command, like so:

make -j6 CC=gcc-7.3.0

Re: [gentoo-user] Cannot emerge gnome because openssl's bindist use flag

[Mike Gilbert]

On Sun, Jan 14, 2018 at 9:51 AM, Hung Dang  wrote:
> I cannot emerge gnome in a fresh build ~amd64 system. Basically, if I enable
> bindist use flag for openssl then emerge will ask me to disable it. However,
> if I disable bindist flag for openssl then it will ask me to enable it. How
> can I break this dependency loop?

Remove USE="bindist" from /etc/portage/make.conf.

Re: [gentoo-user] Re: LINGUAS make.conf variable being ignored?

[Mike Gilbert]

On Sat, Jan 6, 2018 at 11:00 AM, Peter Humphrey  wrote:
> On Saturday, 6 January 2018 15:50:56 GMT Neil Bothwick wrote:
>> On Sat, 6 Jan 2018 15:39:45 + (UTC), Grant Edwards wrote:
>> > > Ahem! American "English", I think you mean.
>> >
>> > Yes, though for most programs [spell-checkers being the obvious
>> > exception] and most non-US English speakers who expected en_GB, I
>> > doubt they'd have any problems using programs that were speaking US
>> > English instead of British English (are there others in use besides
>> > en_GB?).
>>
>> Indeed there are, there's a whole world out there beyond the borders of
>> the USA ;-)
>>
>> grep linguas_en /var/portage/profiles/use.desc
>> linguas_en - English locale
>> linguas_en_AU - English locale for Australia
>> linguas_en_CA - English locale for Canada
>> linguas_en_GB - English locale for Britain
>> linguas_en_US - English locale
>
> I object to that (not you, Neil, some dev or other). I live in England; I
> speak English. People who live in America speak their own version of it,
> adapted from the original. The list should be:
>
> linguas_en_AU - English locale for Australia
> linguas_en_CA - English locale for Canada
> linguas_en_GB - English locale
> linguas_en_US - English locale for USA

I updated the description for en_US.

linguas_en - English locale
linguas_en_AU - English locale for Australia
linguas_en_CA - English locale for Canada
linguas_en_GB - English locale for Britain
linguas_en_US - English locale for America

Re: [gentoo-user] dispatch-conf, the big pic?

[Mike Gilbert]

On Sat, Dec 30, 2017 at 1:10 PM, Ian Zimmerman  wrote:
> I realized I don't really understand it - I just repeat by rote some
> keystrokes.  In particular:
>
> What do the 'z' and 'n' commands do exactly, and what's the difference
> between them?

The 'z' command throws away the new config file, leaving the existing
config file in place. Use this when you don't care about the changes
in the new file at all.

The 'n' command skips over the current file, and does nothing. If you
quit and re-run dispatch-conf, you should be prompted to do something
with the file again.

> After I do a 'm', how do I actually use the result of the merge?  Is the
> merged file now the same as the 'new' one, or the same as the 'old' one?
> IOW, if I do 'm' and then 'z', will the merged version be the active
> one?

After completing the merge, use the 'u' command to use the merged
version. Use the 'z' command to throw away the merged version and
stick with the old file.

Re: [gentoo-user] after finally doing my emerge -e world successfully, my regular world update fails

[Mike Gilbert]

On Fri, Dec 22, 2017 at 5:02 AM, John Covici  wrote:
> Hi.  So, after two weeks, I finally got my emerge -e world finished.
> Now  I was trying my regular world update with --deep, etc., but I get
> an impossible situation.  It seems openrc is now blocking systemd, but
> I apparently need both.

sys-apps/openrc is probably in your world file. Either remove it, or
disable the "sysv-utils" USE flag on sys-apps/systemd.

Re: [gentoo-user] 'firmware_install' won't on 4.14.7-gentoo

[Mike Gilbert]

On Wed, Dec 20, 2017 at 12:39 PM, Mick  wrote:
> [1.072525] [drm] Loading RV730 Microcode
> [1.072679] radeon :02:00.0: Direct firmware load for radeon/
> RV730_pfp.bin failed with error -2
> [1.072859] r600_cp: Failed to load firmware "radeon/RV730_pfp.bin"
> [1.072974] [drm:rv770_init] *ERROR* Failed to load firmware!

Does this error occur before your root filesystem has been mounted?
You should see a message about mounting root further down in the dmesg
output.

If that's the case, and your kernel needs the firmware blob before
root has been mounted, you will probably need to start using an
initramfs, or add radeon/RV730_pfp.bin to CONFIG_EXTRA_FIRMWARE.

Re: [gentoo-user] 'firmware_install' won't on 4.14.7-gentoo

[Mike Gilbert]

On Wed, Dec 20, 2017 at 11:51 AM, Mick <michaelkintz...@gmail.com> wrote:
> On Wednesday, 20 December 2017 16:03:02 GMT Mike Gilbert wrote:
>> On Wed, Dec 20, 2017 at 9:26 AM, Mick <michaelkintz...@gmail.com> wrote:
>
>> > You are quite right, there is no firmware_install in the 4.14.7 release.
>> > What does this mean?  How are we meant to install firmware now?
>>
>> I believe all firmware has been removed from the kernel sources.
>>
>> You should install sys-kernel/linux-firmware, or grab just the files
>> you need from the git repo.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Thank you all, but I see to have a mental disconnect here:
>
> I already have sys-kernel/linux-firmware-20170314 installed.
>
> I have specified in the kernel which blobs I need and /lib/firmware/ as the
> path for the kernel to find any firmware it may need.
>
> I used to run make firmware_install and the kernel was able to load whatever
> firmware I had specified so that CPU/GPU can function properly at boot time.
>
> With 4.14.7 I (can) no longer do this;
>
> AND
>
> the newly compiled kernel does not load at boot time any of the needed
> firmware.
>
> What step am I missing to arrive at a bootable kernel with all necessary
> firmware?

Are you using an initramfs? Does the initramfs contain the necessary
firmware blobs?

Re: [gentoo-user] 'firmware_install' won't on 4.14.7-gentoo

[Mike Gilbert]

On Wed, Dec 20, 2017 at 9:26 AM, Mick  wrote:
> On Wednesday, 20 December 2017 12:52:16 GMT Floyd Anderson wrote:
>> On Wed, 20 Dec 2017 12:22:29 +
>>
>> Mick  wrote:
>> >Has something changed in 4.14.7-gentoo sources from its predecessors?
>> >
>> >I'm getting this on two systems:
>> >
>> >[snip ...]
>> >
>> >  INSTALL sound/pci/hda/snd-hda-codec-hdmi.ko
>> >  INSTALL sound/pci/hda/snd-hda-codec.ko
>> >  INSTALL sound/pci/hda/snd-hda-intel.ko
>> >  DEPMOD  4.14.7-gentoo
>> >
>> >make: *** No rule to make target 'firmware_install'.  Stop.
>>
>> Yes, there is a change to drop the target rule ‘firmware_install’ [1].
>> I’ve noticed also [2] but in the end it seems the rule is finally
>> dropped:
>>
>>   /usr/src/linux-4.12.12-gentoo/scripts/Makefile.fwinst...  exists
>>   /usr/src/linux-4.14.4-gentoo/scripts/Makefile.fwinst ...  no such file
>>
>> To check it’s there look for ‘Other generic targets’ in kernel dir:
>>
>> sudo make help
>>
>> or just grep:
>>
>> grep -q 'firmware_install' /usr/src/linux/Makefile
>>
>>
>> References:
>>   - [1] 
>>   - [2] 
>
> You are quite right, there is no firmware_install in the 4.14.7 release.  What
> does this mean?  How are we meant to install firmware now?

I believe all firmware has been removed from the kernel sources.

You should install sys-kernel/linux-firmware, or grab just the files
you need from the git repo.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

Re: [gentoo-user] CHOST missing in no-multilib stage3 make.conf

[Mike Gilbert]

On Mon, Dec 18, 2017 at 3:20 PM, Walter Dnes  wrote:
> On Mon, Dec 18, 2017 at 10:20:48AM -0500, Michael Orlitzky wrote
>> On 12/18/2017 10:00 AM, Walter Dnes wrote:
>> >
>> >   I tried a couple of different mirrors.  No CHOST line. The example
>> > file usr/share/portage/config/make.conf.example shows...
>> >
>> > ===
>> > CHOST="x86_64-pc-linux-gnu"
>> > ===
>> >
>> >   I could insert that, but I wonder if anything else is screwed up.
>>
>> This silently disappeared some time ago. It's set in the profiles now;
>> for example, the file "profiles/arch/amd64/make.defaults" sets
>>
>>   CHOST="x86_64-pc-linux-gnu"
>
>   Thanks.  That's good to know.  This could've used a brief news item to
> avoid scaring people.  I'll file a documentation bug because
> usr/share/portage/config/make.conf.example still shows an explicit CHOST
> setting line.  While I'm at it, I'll ask them to mention "-march=native"
> in CFLAGS/CXXFLAGS.

CHOST is still a valid setting in make.conf, so removing it from the
example is not necessary.

Setting CHOST is still necessary for archs like x86, on which you have
i486, i586 and i686 variants.

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

[Mike Gilbert]

On Sun, Dec 10, 2017 at 11:37 PM, Ian Zimmerman  wrote:
> On 2017-12-10 21:31, Canek Peláez Valdés wrote:
>
>> You just don't notice udisks, it's quietly running in the background
>> doing its thing without taking either much disk space, memory, nor CPU
>> usage.
>
> I know Dr. Valdés will not respond but maybe someone else will, as this
> is a factual question.
>
> Last time I met udisks in person, it polled all drives on the system
> every second.  Has that changed?

udisksd does not appear to poll devices. It waits for device change
events to be sent over a netlink socket from udev. udev waits for
events to be sent from the kernel.

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] CFLAGS for both AMD64 and Intel?

[Mike Gilbert]

On Sun, Dec 3, 2017 at 2:23 AM, Manuel McLure  wrote:
> Here's the situation. I have a system that's been running for many years
> with an Athlon 5050e processor. The system is built with
>
> CFLAGS="-march=k8-sse3 -O2 -pipe -msse3"
> CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"
>
> I have the possibility of upgrading the system to a first-generation Intel
> Core i5 which should give a nice speed boost, but of course the Intel chip
> doesn't understand 3dnow or 3dnowext, so I'll have to do a system rebuild
> before I switch out the motherboard/processor. It seems pretty obvious that
> I have to take "3dnow 3dnowext" out of CPU_FLAGS_X86, but what CFLAGS would
> be recommended for a system that will still run with the AMD processor but
> won't fall over when I switch to the Intel processor? Once I have the Intel
> in place I can rebuild with options more suited for that chip, but I want to
> make sure I don't end up in a catch-22 situation.

I would go with just "-O2 -pipe" for maximum compatibility. Remove the
-march option altogether, and add it back once the system is running
on the Intel chip.

Re: [gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Mike Gilbert]

On Sat, Dec 2, 2017 at 8:15 AM, Mick  wrote:
> app-cdr/cdrdao-1.2.3-r4 also fails to install:
>
> [snip ...]
> Making all in utils
> make[2]: Entering directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2cue.o toc2cue.cc
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o main.o main.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o cue2toc.o cue2toc.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o timecode.o timecode.c
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2cddb.o toc2cddb.cc
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2mp3-toc2mp3.o `test -f 'toc2mp3.cc' ||
> echo './'`toc2mp3.cc
> x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -pthread  -Wl,-O1 -Wl,--as-
> needed -o cue2toc main.o cue2toc.o timecode.o  -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1
> -Wl,--as-needed -o toc2cddb toc2cddb.o ../trackdb/libtrackdb.a -lmad -lm -
> lvorbisfile -lao -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1
> -Wl,--as-needed -o toc2mp3 toc2mp3-toc2mp3.o ../trackdb/libtrackdb.a  -
> lmp3lame -lmad -lm -lvorbisfile -lao -pthread
> [19/1535]
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in readonly
> section `.text.startup'
> toc2mp3-toc2mp3.o: In function `init_encoder(int)':
> toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2db): undefined reference to `bitrate_table'
> toc2mp3-toc2mp3.o: In function `main':
> toc2mp3.cc:(.text.startup+0x29a): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text.startup+0x2a1): undefined reference to `bitrate_table'
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: creating a DT_TEXTREL in a shared object.
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:487: toc2mp3] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> make[1]: *** [Makefile:436: all-recursive] Error 1
> make[1]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3'
> make: *** [Makefile:375: all] Error 2
>  * ERROR: app-cdr/cdrdao-1.2.3-r4::gentoo failed (compile phase):
>  *   emake failed
>
> Is there a solution for this?

There is a patch attached to this bug report.

https://bugs.gentoo.org/635014

Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

[Mike Gilbert]

On Mon, Nov 27, 2017 at 11:47 AM, Walter Dnes <waltd...@waltdnes.org> wrote:
> On Wed, Oct 11, 2017 at 10:15:50PM -0400, Walter Dnes wrote
>> On Wed, Oct 11, 2017 at 11:56:21AM -0400, Mike Gilbert wrote
>>
>> > I can reproduce the issue by adding -fopenmp to my CFLAGS. You can
>> > work around it by adding -fopenmp to LDFLAGS as well.
>>
>>   Thanks.  The following workaround makes python build properly.
>>
>> LDFLAGS="-fopenmp" emerge =dev-lang/python-2.7.12 =dev-lang/python-3.4.5
>>
>> > This is probably a bug in the Python build system; it should probably
>> > be passing CFLAGS to gcc when linking libpython.
>>
>>   Bug https://bugs.gentoo.org/634064 filed.
>
>   Bump; I had to...
>
> LDFLAGS="-fopenmp" emerge -1 =dev-lang/python-2.7.14 =dev-lang/python-3.5.4
>
> ..to get the latest pythons to build properly.

Just stick it in make.conf and call it fixed.

You can track further updates via the bug report.

Re: [gentoo-user] Help...can't decipher emerge oracle...

[Mike Gilbert]

On Wed, Nov 15, 2017 at 12:20 PM,   wrote:
> On 11/15 06:04, Jan Chren (rindeal) wrote:
>> net-libs/libnsl-1.1.0-r1 is blocking sys-libs/glibc versions lower
>> than 2.26 and you have sys-libs/glibc-2.25 installed. So try
>> installing glibc-2.26 manually first and then libnsl.
>>
>> On 15 November 2017 at 17:50,   wrote:
>> > Hi,
>> >
>> > From emerge I got this """info""":
>> >
>> >
>> >
>> >  * Error: The above package list contains packages which cannot be
>> >  * installed at the same time on the same system.
>> >
>> >   (sys-libs/glibc-2.25-r9:2.2/2.2::gentoo, installed) pulled in by
>> > >=sys-libs/glibc-2.23[multilib?] (>=sys-libs/glibc-2.23) required by 
>> > (dev-java/icedtea-bin-3.6.0:8/8::gentoo, installed)
>> > sys-libs/glibc[rpc(-)] required by (net-fs/autofs-5.1.3:0/0::gentoo, 
>> > installed)
>> > >=sys-libs/glibc-2.6.1 required by 
>> > (x11-drivers/nvidia-drivers-387.22:0/387::gentoo, installed)
>> > sys-libs/glibc required by (app-arch/rar-5.5.0_p20170811:0/0::gentoo, 
>> > installed)
>> > >=sys-libs/glibc-2.7 required by 
>> > (sys-apps/iproute2-4.14.0:0/0::gentoo, ebuild scheduled for merge)
>> > >=sys-libs/glibc-2.17 required by (dev-lang/ghc-8.0.2:0/8.0.2::gentoo, 
>> > installed)
>> > sys-libs/glibc:2.2 required by (virtual/libc-1:0/0::gentoo, installed)
>> > sys-libs/glibc required by 
>> > (app-office/openoffice-bin-4.1.3:0/0::gentoo, installed)
>> > sys-libs/glibc required by @selected
>> > >=sys-libs/glibc-2.8:2.2 required by 
>> > (media-video/vlc-2.2.6-r2:0/5-8::gentoo, installed)
>> > >=sys-libs/glibc-2.8 required by 
>> > (sys-devel/gcc-4.9.4:4.9.4/4.9.4::gentoo, installed)
>> > >=sys-libs/glibc-2.8 required by 
>> > (sys-devel/gcc-5.4.0-r3:5.4.0/5.4.0::gentoo, installed)
>> > >=sys-libs/glibc-2.13 required by 
>> > (sys-devel/gcc-6.4.0:6.4.0/6.4.0::gentoo, installed)
>> >
>> >   (net-libs/libnsl-1.1.0-r1:0/2::gentoo, ebuild scheduled for merge) 
>> > pulled in by
>> > net-libs/libnsl:0= required by 
>> > (app-emulation/hercules-3.12:0/0::gentoo, installed)
>> > net-libs/libnsl:0= required by (app-text/opensp-1.5.2-r6:0/0::gentoo, 
>> > ebuild scheduled for merge)
>> > net-libs/libnsl:0 required by @__auto_slot_operator_replace_installed__
>> >
>> > ...for me it seems, that I need a lot of different glibc versions and
>> > currently I dont know, how to get out of this mess...
>> >
>> > I would be happy, if someone could help me...
>> >
>> > Cheers
>> > Meino
>> >
>> >
>> >
>>
> Hi Jan,
>
> thanks for your help and your answer! :)
>
>
> Trying what you suggest leads into this:
>
> /root>emerge '=glibc-2.26-r3'
> Calculating dependencies... done!
> [ebuild U  ] sys-libs/glibc-2.26-r3 [2.25-r9]
>
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> sys-libs/glibc:2.2
>
>   (sys-libs/glibc-2.26-r3:2.2/2.2::gentoo, ebuild scheduled for merge) pulled 
> in by
> =sys-libs/glibc-2.26-r3 (Argument)
>
>   (sys-libs/glibc-2.25-r9:2.2/2.2::gentoo, installed) pulled in by
> sys-libs/glibc[rpc(-)] required by (net-fs/autofs-5.1.3:0/0::gentoo, 
> installed)
>
>  installed)
> ^   
>
> I would tend to remove autofs, install glibc-2.26, reinstall autofs
> and 
>
> Woyld that work, or do I kill my system with that...
>
> (I hate dependencies... :)
>

Removing autofs certainly can't hurt.

Maybe try upgrading glibc and libnsl together.

emerge --oneshot sys-libs/glibc net-libs/libnsl

Re: [gentoo-user] Why I can't I build systemd without ipv6?

[Mike Gilbert]

On Fri, Oct 13, 2017 at 1:29 PM, Daniel Frey  wrote:
> I switched ISPs a couple months back and have been struggling with
> networking issues (not LAN, just WAN.)
>
> I have discovered that something is broken with my ISP's ipv6 support, every
> time I go to a website there's a 10-second delay. When syncing portage today
> I saw what the delay is: apparently it tries ipv6 twice, fails, then resorts
> to ipv4 which works fine.
>
> Most of my systems now have ipv6 support removed, and viola! no more delays.
>
> Except for the three systems I have that run systemd. I went in the kernel
> config to disable ipv6, and it won't let me - looking at the dependency
> list, it's systemd blocking this.
>
> So *why* on earth is it a dependency when (from what I've been reading after
> discovering this) many ISPs don't seem to support it properly yet?
>
> And is there a way to build systemd without ipv6? Or am I going to have to
> revert these three systems back to openrc?

Instead of stripping IPv6 out of your kernel, I would suggest that you
simply disable it on any network interfaces. How you do this would
depend on the method you use to manager your network config.

If you really want to remove IPv6 from your kernel, simply disable the
GENTOO_LINUX_INIT_SYSTEMD config option, and enable the other other
dependencies manually.

https://gitweb.gentoo.org/proj/linux-patches.git/tree/4567_distro-Gentoo-Kconfig.patch#n106

Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

[Mike Gilbert]

On Wed, Oct 11, 2017 at 11:50 AM, Mike Gilbert <flop...@gentoo.org> wrote:
> On Wed, Oct 11, 2017 at 12:16 AM, Walter Dnes <waltd...@waltdnes.org> wrote:
>>   This is happening with both python 2.7.12 and 3.4.5 on a 32-bit x86
>> system.  Build logs are attached, along with "emerge --info" output.  I
>> can't find anything relevant in bugzilla.
>
> From the build log for 3.4.5:
>
> checking whether pthreads are available without options... yes
>
> This is clearly a lie; glibc requires that you pass "-pthread" to gcc
> to enable pthreads. For some reason, configure is mis-detecting this.
>
> I would try rebuilding with minimal CFLAGS.

I can reproduce the issue by adding -fopenmp to my CFLAGS. You can
work around it by adding -fopenmp to LDFLAGS as well.

This is probably a bug in the Python build system; it should probably
be passing CFLAGS to gcc when linking libpython.

Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

[Mike Gilbert]

On Wed, Oct 11, 2017 at 12:16 AM, Walter Dnes  wrote:
>   This is happening with both python 2.7.12 and 3.4.5 on a 32-bit x86
> system.  Build logs are attached, along with "emerge --info" output.  I
> can't find anything relevant in bugzilla.

>From the build log for 3.4.5:

checking whether pthreads are available without options... yes

This is clearly a lie; glibc requires that you pass "-pthread" to gcc
to enable pthreads. For some reason, configure is mis-detecting this.

I would try rebuilding with minimal CFLAGS.

Re: [gentoo-user] [OT] Block multiple IP addresses; iptables or route...reject?

[Mike Gilbert]

On Wed, Oct 4, 2017 at 1:28 AM, Walter Dnes  wrote:
>   I have some doubts about massive "hosts" files for adblocking.  I
> downloaded one that listed 13,148 sites.  I fed them through a script
> that called "host" for each entry, and saved the output to a text file.
> The result was 1,059 addresses.  Note that some adservers have multiple
> IP address entries for the same name.  A back-of-the-envelope analysis
> is that close to 95% of the entries in the large host file are invalid,
> amd return "not found: 3(NXDOMAIN)".
>
>   I'm not here to trash the people compiling the lists; the problem is
> that hosts files are the wrong tool for the job.  Advertisers know about
> hosts files and deliberately generate random subdomain names with short
> lifetimes to invalidate the hosts files.  Every week the sites are
> probably mostly renamed.  Further analysis of the 1,059 addresses show
> 810 unique entries, i.e. 249 duplicates.  It gets even better.  44
> addresses show up in 52.84.146.xxx; I should probably block the entire
> /24 with one entry.  There are multiple similar occurences, which could
> be aggregated into small CIDRs.  So the number of blocking rules is
> greatly reduced.
>
>   I'm not a deep networking expert.  My question is whether I'm better
> off adding iptables reject/drop rules or "reject routes", e.g...
>
> route add -net 10.0.0.0 netmask 255.0.0.0 metric 1024 reject
>
> (an example from the "route" man page).  iptables rules have to be
> duplicated coming and going to catch inbound and outbound traffic.  A
> reject route only needs to be entered once.  This excercise is intended
> to block web adservers, so another question is how web browsers react to
> route versus iptables blocking.

Using the routing table feels dirty.

I don't see any reason to create "inbound" (INPUT) iptables rules. You
really only care about rejecting the initial outbound request to the
web server.

If this is for a single host with iptables running locally, add rules
to the OUTPUT chain. If this is on a router, add them to the FORWARD
chain.

Re: [gentoo-user] /sys/fs/cgroup/unified/ missing

[Mike Gilbert]

On Mon, Sep 18, 2017 at 3:12 PM, Robin Atwood  wrote:
> I just logged off KF5 after an extensive update and XDM would not restart, I
> got a message about /sys/fs/cgroup/unified/ did not exist (which it
> doesn't). The /sys/fs/cgroup/ directory is there, it's the "unified"
> sub-directory that's missing. I have not rebooted for a long time so I did
> that and still got the messages. Fortunately the system still comes up. I
> must have missed a config update somewhere I guess but I cannot find any
> useful hits when I search. Any idea what I am missing?

Regarding the cgroup message: Are you running OpenRC or systemd?

OpenRC only gained support for the "unified" cgroup hierarchy within
the last week or so in version 0.31.

systemd has supported it for at least a year.

I'm doubtful it has anything to do with XDM failing to start, however.

Re: [gentoo-user] remove gnome/systemd

[Mike Gilbert]

On Tue, Sep 12, 2017 at 5:20 PM, Heiko Baums  wrote:
> Just to be absolutely sure put this line into
> your /etc/portage/make.conf, too:
> INSTALL_MASK="/lib/systemd /lib32/systemd /lib64/systemd /usr/lib/systemd 
> /usr/lib32/systemd /usr/lib64/systemd /etc/systemd"

I would advise against this INSTALL_MASK setting. It is quite likely
to break things (like sys-fs/udev).

Its only value is to give a warm and fuzzy feeling to people who have
an irrational hatred of systemd.

Re: [gentoo-user] Downgrading glibc prevented by emerge/portage...but why initiated?

[Mike Gilbert]

On Tue, Sep 12, 2017 at 12:57 PM,   wrote:
> On 09/12 04:52, Andreas K. Huettel wrote:
>> > I masked =sys-libs/glibc-2.25-r4.
>> >
>> > And now I remember why I did this: It gave a compilation error:
>> > (As some other packages) it has problems with my texinfo installation
>> > as it seems.
>> >
>>
>> bug number?
>>
>>
>> --
>> Andreas K. Hüttel
>> dilfri...@gentoo.org
>> Gentoo Linux developer (council, perl, libreoffice)
>>
>
> Hi Andreas,
>
> hrrrmmmno the problem is on my side...somewhere.
> It is not considered a Gentoo-bug...
>
>

Here are the previous ml threads on this topic.

https://archives.gentoo.org/gentoo-user/message/143c7501eedc377a72a98cdf5a1b4280

https://archives.gentoo.org/gentoo-user/message/e25e368978d10615346bd18a8b3740e8

Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda

[Mike Gilbert]

On Mon, Sep 4, 2017 at 11:00 AM, Grant  wrote:
>>> My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts
>>> with the script I use to manage about 12 similar laptops running
>>> Gentoo.  Is there a udev method for renaming the disk that will work
>>> well with any USB disks that happen to also be attached?
>>
>> I'm not certain what you mean by that, but I would guess that you want
>> the nvme disk to show up as /dev/sda, and the USB disk(s) to show up
>> as /dev/sd[b-z].
>>
>> It is not possible to accomplish this using udev; the kernel owns the
>> /dev/sdX device namespace, and will sequentially create devices nodes
>> for SCSI-like block devices using that namespace. There is no way to
>> change that using a udev rule.
>
>
> Can I rename /dev/sda to /dev/sd[b-z] if it's attached via USB, and
> then rename /dev/nvme0n1 to /dev/sda if /dev/nvme0n1 exists?
>
> Alternatively, can I rename /dev/sda to /dev/sd[b-z] if /dev/sda and
> /dev/nvme0n1 exist, and then rename /dev/nvme0n1 to /dev/sda if
> /dev/nvme0n1 exists?

 You might technically be able to do it, but I would guess it would
 cause some nasty race conditions between the kernel and udev. It's a
 bad idea.
>>>
>>>
>>> Is it the conditionals that cause this to be a bad idea?  Because I
>>> believe udev has functionality designed to rename devices exactly like
>>> this.
>>
>> udev doesn't provide any functionality to rename device nodes. You can
>> adjust their permissions, and create symlinks, but there is no direct
>> way to rename them.
>
>
> I use stuff like this to rename my USB devices and it works perfectly:
>
> SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp0s20u2u1",
> NAME="net0"
>
> Isn't this a true rename of the device node?

Network devices don't have device nodes. They have interface names,
which are a different concept entirely.

Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda

[Mike Gilbert]

On Sun, Sep 3, 2017 at 6:41 PM, Grant  wrote:
> My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts
> with the script I use to manage about 12 similar laptops running
> Gentoo.  Is there a udev method for renaming the disk that will work
> well with any USB disks that happen to also be attached?

 I'm not certain what you mean by that, but I would guess that you want
 the nvme disk to show up as /dev/sda, and the USB disk(s) to show up
 as /dev/sd[b-z].

 It is not possible to accomplish this using udev; the kernel owns the
 /dev/sdX device namespace, and will sequentially create devices nodes
 for SCSI-like block devices using that namespace. There is no way to
 change that using a udev rule.
>>>
>>>
>>> Can I rename /dev/sda to /dev/sd[b-z] if it's attached via USB, and
>>> then rename /dev/nvme0n1 to /dev/sda if /dev/nvme0n1 exists?
>>>
>>> Alternatively, can I rename /dev/sda to /dev/sd[b-z] if /dev/sda and
>>> /dev/nvme0n1 exist, and then rename /dev/nvme0n1 to /dev/sda if
>>> /dev/nvme0n1 exists?
>>
>> You might technically be able to do it, but I would guess it would
>> cause some nasty race conditions between the kernel and udev. It's a
>> bad idea.
>
>
> Is it the conditionals that cause this to be a bad idea?  Because I
> believe udev has functionality designed to rename devices exactly like
> this.

udev doesn't provide any functionality to rename device nodes. You can
adjust their permissions, and create symlinks, but there is no direct
way to rename them.

To rename a device node in a udev rule, you would have to call an
external command, which udev knows nothing about. After having renamed
it this way, the information in the udev device database would no
longer be consistent, and any future device events would not work
properly.

I would suggest you utilize the existing symlinks in one of the
/dev/disk/ sub-directories, or create some udev rules to create your
own symlinks based on whatever metadata you wish. I would also suggest
you read the udev(7) manual page.

Trying to coerce your nvme device to look like an sd device is really
the wrong approach to solving your problem.

Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda

[Mike Gilbert]

On Sun, Sep 3, 2017 at 2:11 PM, Grant  wrote:
>>> My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts
>>> with the script I use to manage about 12 similar laptops running
>>> Gentoo.  Is there a udev method for renaming the disk that will work
>>> well with any USB disks that happen to also be attached?
>>
>> I'm not certain what you mean by that, but I would guess that you want
>> the nvme disk to show up as /dev/sda, and the USB disk(s) to show up
>> as /dev/sd[b-z].
>>
>> It is not possible to accomplish this using udev; the kernel owns the
>> /dev/sdX device namespace, and will sequentially create devices nodes
>> for SCSI-like block devices using that namespace. There is no way to
>> change that using a udev rule.
>
>
> Can I rename /dev/sda to /dev/sd[b-z] if it's attached via USB, and
> then rename /dev/nvme0n1 to /dev/sda if /dev/nvme0n1 exists?
>
> Alternatively, can I rename /dev/sda to /dev/sd[b-z] if /dev/sda and
> /dev/nvme0n1 exist, and then rename /dev/nvme0n1 to /dev/sda if
> /dev/nvme0n1 exists?

You might technically be able to do it, but I would guess it would
cause some nasty race conditions between the kernel and udev. It's a
bad idea.

Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda

[Mike Gilbert]

On Fri, Sep 1, 2017 at 12:10 PM, Grant  wrote:
> My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts
> with the script I use to manage about 12 similar laptops running
> Gentoo.  Is there a udev method for renaming the disk that will work
> well with any USB disks that happen to also be attached?

I'm not certain what you mean by that, but I would guess that you want
the nvme disk to show up as /dev/sda, and the USB disk(s) to show up
as /dev/sd[b-z].

It is not possible to accomplish this using udev; the kernel owns the
/dev/sdX device namespace, and will sequentially create devices nodes
for SCSI-like block devices using that namespace. There is no way to
change that using a udev rule.

Re: [gentoo-user] efibootmgr "Could not prepare Boot variable: Read-only file system"

[Mike Gilbert]

On Thu, Aug 17, 2017 at 10:29 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote:
> On Tuesday 15 August 2017 22:12:41 Mick wrote:
>> On Tuesday 15 Aug 2017 16:02:19 Mike Gilbert wrote:
>> > On Tue, Aug 15, 2017 at 2:17 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> > > On Tue, Aug 15, 2017 at 11:04 AM, Mick <michaelkintz...@gmail.com>
> wrote:
>> > >> I can't recall if I did this myself in a moment of security induced
>> > >> inspiration.  I doubt I did.  So how did this happen?  What is
>> > >> responsible for mounting this fs?
>> > >
>> > > It looks like this never did turn into a news item:
>> > > https://archives.gentoo.org/gentoo-dev/message/35304b0db4de9e06fea3222
>> > > 7537 9fa81
>> > >
>> > > You can remount it as rw if your tools don't do it automatically.  It
>> > > might not hurt to file a bug if one doesn't already exist for the tool
>> > > that isn't remounting it.
>> >
>> > Please bother efibootmgr upstream about it, or bother the OpenRC
>> > maintainer who decided to break things.
>>
>> Thank you Rich, I suspected it was an intentional change and from a
>> security perspective it is to be commended.  However, it could cause
>> uninformed users like myself some lost time, thinking something may have
>> gone wrong on our system.
>>
>> I submitted bug #627964:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=627964
>>
>> I think a news item although useful, on its own is not sufficient.  If
>> remounting 'rw' and back again to 'ro' is not performed by the legit
>> commands which touch efivars (e.g. efibootmgr, GRUB, et al), the HandBook
>> should also be amended if it hasn't been already, because newbies will
>> have one more excuse to pack it in and go back to *buntu.
>
> That was an instructive conversation - thanks all. I had the same problem
> with systemd-boot while rebuild this box over the last few days. I don't
> know whether to raise a similar bug against systemd-boot now, after reading
> your bug report, Mick.

Given that systemd-boot is ripped out of systemd, and systemd always
mounts efivarfs as read/write, there is really no chance of them
altering bootctl to re-mount efivarfs on demand.

Reporting a bug against systemd-boot would probably be a waste of your
time since I will almost certainly close it as WONTFIX. ;-)

Re: [gentoo-user] efibootmgr "Could not prepare Boot variable: Read-only file system"

[Mike Gilbert]

On Tue, Aug 15, 2017 at 2:17 PM, Rich Freeman  wrote:
> On Tue, Aug 15, 2017 at 11:04 AM, Mick  wrote:
>>
>> I can't recall if I did this myself in a moment of security induced
>> inspiration.  I doubt I did.  So how did this happen?  What is responsible 
>> for
>> mounting this fs?
>>
>
> It looks like this never did turn into a news item:
> https://archives.gentoo.org/gentoo-dev/message/35304b0db4de9e06fea322275379fa81
>
> You can remount it as rw if your tools don't do it automatically.  It
> might not hurt to file a bug if one doesn't already exist for the tool
> that isn't remounting it.

Please bother efibootmgr upstream about it, or bother the OpenRC
maintainer who decided to break things.

Re: [gentoo-user] DNS resolver doesn't

[Mike Gilbert]

On Tue, Aug 8, 2017 at 12:32 PM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote:
> On Tuesday 08 Aug 2017 09:11:22 Mike Gilbert wrote:
>
>> The "order" directive in /etc/host.conf only works for very old
>> versions of glibc. Modern versions use /etc/nsswitch.conf. The default
>> nsswitch.conf will check /etc/hosts (files) before DNS anyway.
>>
>> How are you testing? I would guess you are probably using the wrong tool.
>
> nslookup -sil
>
>> The "host" command will always ignore /etc/hosts. It always does DNS
>> queries by design.
>>
>> Try using "getent hosts [hostname]".
>
> Yes, that works. Thanks Mike. I'll set up a nice short alias for it. Looks
> like I can get rid of net-dns/bind-tools.

bind-tools is quite useful for performing advanced DNS queries. The
'dig' command is especially useful if you want to see the full rrset
being returned. It also lets you set various flags on the DNS request,
and manually override the DNS server.

For casual usage, bind-tools is probably unnecessary.

Re: [gentoo-user] DNS resolver doesn't

[Mike Gilbert]

On Tue, Aug 8, 2017 at 6:19 AM, Peter Humphrey  wrote:
> Hello list,
>
> On two machines, I have my DSL modem set as DNS server, and it forwards to
> my ISP's servers. This works well for external hosts. I also have "order
> hosts, bind" in /etc/host.conf, but even though both machines have full LAN
> host names and addresses in their /etc/hosts, every DNS lookup goes straight
> to the modem, which of course knows nothing of the local layout.
>
> What else do I have to do to make host.conf effective? Would a hammer help?

The "order" directive in /etc/host.conf only works for very old
versions of glibc. Modern versions use /etc/nsswitch.conf. The default
nsswitch.conf will check /etc/hosts (files) before DNS anyway.

How are you testing? I would guess you are probably using the wrong tool.

The "host" command will always ignore /etc/hosts. It always does DNS
queries by design.

Try using "getent hosts [hostname]".

Re: [gentoo-user] Gnutls / Google Chrome

[Mike Gilbert]

On Thu, Aug 3, 2017 at 3:56 PM, siefke_lis...@web.de
 wrote:
> Hello,
>
> I have updated gnutls v. 3.5.13 and after rebuild google-chrome want not
> started.
>
> Okay link check
>
> sisibox lib64 # ldd /opt/google/chrome/chrome | grep gnu
> libstdc++.so.6 => 
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libstdc++.so.6 (0x7fd05e7db000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libgcc_s.so.1 
> (0x7fd05e5c4000)
> libgnutls.so.28 => not found
>
> So Gnutls missed, I reinstall chrome and become same. I understand not
> why because on my package Server:
>
> (amd64) ks3374456 www-client # ldd /opt/google/chrome/chrome | grep gnu
> libstdc++.so.6 => 
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libstdc++.so.6 (0x7f339c499000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libgcc_s.so.1 
> (0x7f339c282000)
> libgnutls.so.30 => /usr/lib64/libgnutls.so.30 (0x7f3399ac9000)
>
> all work. I have deinstall and install, I have use "Source" and Binary
> Package. What can do now?

google-chrome does not depend on gnutls directly.

Use the lddtree utility from app-misc/pax-utils to determine what
library is pulling it in.

% lddtree /opt/google/chrome/chrome

Re: [gentoo-user] Re: redoing grub-2 after emerge updates it

[Mike Gilbert]

On Fri, Jul 7, 2017 at 12:16 PM, Mick <michaelkintz...@gmail.com> wrote:
> On Friday 07 Jul 2017 11:49:11 Harry Putnam wrote:
>> Mike Gilbert <flop...@gentoo.org> writes:
>>
>> [...]
>>
>> > If you want to use the new version to boot your system, you should
>> > re-run grub-install, which will copy the modules to /boot/grub and
>> > will install the core image to your MBR or EFI system partition.
>>
>> Thanks for the info.
>>
>> I don't know what the update was but since its easy enough to run
>> `grub-install /dev/sda' and I guess also run
>> grub-mkconfig -o /boot/grub/grub.cfg
>>
>> Anyway, I did those two things... just being on the safe side.
>
> As has already stated you could stay put with your old version, provided you
> have no specific reason to stop using it.  GRUB2 can be installed and left
> unused.  I guess from a usability perspective as long as you have no need to
> employ GRUB2's new functionality/features, main difference between GRUB legacy
> and GRUB2 can be boiled down to what you need to do each time you install a
> new kernel.
>
> With GRUB legacy you edit on your own your /boot/grub/grub.conf to add the
> name and version of your newly installed kernel and initrd (if you use one of
> these).
>
> With GRUB2 you run a single command line and leave it to GRUB2's scripts to
> scan your boot and other drives, discover their contents and auto-complete
> /boot/grub/grub.cfg.

Harry made no mention of GRUB Legacy in his original email. I assume
he was upgrading from grub-2.02~beta3 to grub-2.02.

Also, it is perfectly acceptable to hand-write your GRUB2
configuration file; grub-mkconfig is not mandatory. It's just often
easier for new users with simple boot configurations, or for people
who don't want to worry about hand-editing the config for every kernel
upgrade.

Re: [gentoo-user] redoing grub-2 after emerge updates it

[Mike Gilbert]

On Fri, Jul 7, 2017 at 8:28 AM, Harry Putnam  wrote:
> Googling to find out if it is necessary to reinstall the bootloader
> and update grub.cfg afer update world installed grub2 update.
>
> I was buried in directions to install grub2, or move from old grub to
> grub2.  But not what I wanted to know short of reading all hits word
> for word.
>
> So, (sniveling over), do I need to reinstall the boot loader and
> update grub.cfg like when it was newly installed?

Good question(s).

You don't really *need* to reinstall; the old version will continue to
run/boot indefinitely.

If you want to use the new version to boot your system, you should
re-run grub-install, which will copy the modules to /boot/grub and
will install the core image to your MBR or EFI system partition.

You only need to re-generate grub.cfg if you make a change to your
kernel/initramfs images in /boot; your existing grub.cfg file will
continue to work otherwise.

Re: [gentoo-user] ...again compile problems due to texinfo...

[Mike Gilbert]

On Thu, Jun 29, 2017 at 12:44 PM,  <tu...@posteo.de> wrote:
> On 06/29 12:24, Mike Gilbert wrote:
>> On Wed, Jun 28, 2017 at 10:06 PM,  <tu...@posteo.de> wrote:
>> > Hi,
>> >
>> > previously the compilation of glibc failed, because docs
>> > cpuld not be build.
>> > This was caused in the context of texinfo.
>> > "Solved" was this by not building the docs via
>> > deinstallation of texinfo temporarily.
>> >
>> > No screen jumps over the edge and again texinfo seems
>> > to cause this:
>> >
>> >>>> Source configured.
>> >>>> Compiling source in 
>> >>>> /var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0 ...
>> > make -j6 comm.h term.h
>> > AWK=gawk CC="x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe 
>> > -D_GNU_SOURCE" srcdir=. sh ./comm.sh
>> > AWK=gawk srcdir=. sh ./term.sh
>> > make -j6 osdef.h
>> > CPP="x86_64-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK 
>> > -DETCSCREENRC='"/etc/screenrc"' 
>> > -DSCREENENCODINGS='"/usr/share/screen/utf8encodings"'" srcdir=. sh 
>> > ./osdef.sh
>> > make -j6 -C doc screen.info
>> > make: Entering directory 
>> > '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
>> > makeinfo ./screen.texinfo -o screen.info
>> > ./screen.texinfo:3154: `@end' expected `deffn', but saw `example'
>> > ./screen.texinfo:3154: unmatched `@end example'
>> > ./screen.texinfo:3156: unmatched `@end deffn'
>> > make: *** [Makefile:31: screen.info] Error 1
>> > make: Leaving directory 
>> > '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
>> >  * ERROR: app-misc/screen-4.6.0::gentoo failed (compile phase):
>> >  *   emake failed
>> >  *
>> >  * If you need support, post the output of `emerge --info 
>> > '=app-misc/screen-4.6.0::gentoo'`,
>> >  * the complete build log and the output of `emerge -pqv 
>> > '=app-misc/screen-4.6.0::gentoo'`.
>> >  * The complete build log is located at 
>> > '/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'.
>> >  * The ebuild environment file is located at 
>> > '/var/tmp/portage/app-misc/screen-4.6.0/temp/environment'.
>> >  * Working directory: 
>> > '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
>> >  * S: '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
>> >  *
>> >  * The following package has failed to build, install, or execute postinst:
>> >  *
>> >  *  (app-misc/screen-4.6.0:0/0::gentoo, ebuild scheduled for merge), Log 
>> > file:
>> >  *   '/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'
>> >  *
>> >
>> >  * GNU info directory index is up-to-date.
>> >  * After world updates, it is important to remove obsolete packages with
>> >  * emerge --depclean. Refer to `man emerge` for more information.
>> >
>> >
>> > How can I fix this ... by fixing it and not by uninstalling texinfo ?
>> > ;)
>>
>> Yeah, texinfo is very broken on your system. Some things to check for:
>>
>> Any oddly set USE flags on sys-apps/texinfo (maybe USE="-nls")?
>> Custom patches in /etc/portage/patches?
>> Run perl-cleaner --all
>>
>
> This is the contents of /etc/portage/patches
>
> /etc/portage/patches/sys-apps
> /etc/portage/patches/sys-apps/v86d-0.1.10
> /etc/portage/patches/sys-apps/v86d-0.1.10/v86d-atomic_t.patch
> /etc/portage/patches/sys-libs
> /etc/portage/patches/sys-libs/libcap
> /etc/portage/patches/sys-libs/libcap/libcap-patch
>
> My useflags are:
> USE="nvidia X lua sdl mp3 flac jack alsa gtk cairo sndfile qt3support 
> kpathsea gif tga jpeg png jpeg2k mad dvb dvdr encode lzo bzip2 ogg sox v4l 
> v4l2 vorbis x264 x265 zsh-completion -hal -lirc"
>
> Seems not to be THAT weird, isn't it?
>
> I am running perl-cleaner now...as I did several times in the attempt
> to fix the first ransomtexinfo;)

My only other guess is that you have some environment variable set
that causes makeinfo to behave differently than it normally would.

Re: [gentoo-user] ...again compile problems due to texinfo...

[Mike Gilbert]

On Wed, Jun 28, 2017 at 10:06 PM,   wrote:
> Hi,
>
> previously the compilation of glibc failed, because docs
> cpuld not be build.
> This was caused in the context of texinfo.
> "Solved" was this by not building the docs via
> deinstallation of texinfo temporarily.
>
> No screen jumps over the edge and again texinfo seems
> to cause this:
>
 Source configured.
 Compiling source in 
 /var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0 ...
> make -j6 comm.h term.h
> AWK=gawk CC="x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE" 
> srcdir=. sh ./comm.sh
> AWK=gawk srcdir=. sh ./term.sh
> make -j6 osdef.h
> CPP="x86_64-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK 
> -DETCSCREENRC='"/etc/screenrc"' 
> -DSCREENENCODINGS='"/usr/share/screen/utf8encodings"'" srcdir=. sh ./osdef.sh
> make -j6 -C doc screen.info
> make: Entering directory 
> '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
> makeinfo ./screen.texinfo -o screen.info
> ./screen.texinfo:3154: `@end' expected `deffn', but saw `example'
> ./screen.texinfo:3154: unmatched `@end example'
> ./screen.texinfo:3156: unmatched `@end deffn'
> make: *** [Makefile:31: screen.info] Error 1
> make: Leaving directory 
> '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0/doc'
>  * ERROR: app-misc/screen-4.6.0::gentoo failed (compile phase):
>  *   emake failed
>  *
>  * If you need support, post the output of `emerge --info 
> '=app-misc/screen-4.6.0::gentoo'`,
>  * the complete build log and the output of `emerge -pqv 
> '=app-misc/screen-4.6.0::gentoo'`.
>  * The complete build log is located at 
> '/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'.
>  * The ebuild environment file is located at 
> '/var/tmp/portage/app-misc/screen-4.6.0/temp/environment'.
>  * Working directory: 
> '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
>  * S: '/var/tmp/portage/app-misc/screen-4.6.0/work/screen-4.6.0'
>  *
>  * The following package has failed to build, install, or execute postinst:
>  *
>  *  (app-misc/screen-4.6.0:0/0::gentoo, ebuild scheduled for merge), Log file:
>  *   '/var/tmp/portage/app-misc/screen-4.6.0/temp/build.log'
>  *
>
>  * GNU info directory index is up-to-date.
>  * After world updates, it is important to remove obsolete packages with
>  * emerge --depclean. Refer to `man emerge` for more information.
>
>
> How can I fix this ... by fixing it and not by uninstalling texinfo ?
> ;)

Yeah, texinfo is very broken on your system. Some things to check for:

Any oddly set USE flags on sys-apps/texinfo (maybe USE="-nls")?
Custom patches in /etc/portage/patches?
Run perl-cleaner --all

Re: [gentoo-user] glibc-2.24-r2 failed (install phase)

[Mike Gilbert]

On Wed, Jun 21, 2017 at 1:10 PM,   wrote:
> On 06/21 05:38, Alexander Kapshuk wrote:
>> On Mon, Jun 19, 2017 at 7:43 PM,   wrote:
>> > On 06/19 11:55, Alexander Kapshuk wrote:
>> >> On Mon, Jun 19, 2017 at 6:21 AM,   wrote:
>> >> > On 06/15 05:56, tu...@posteo.de wrote:
>> >> >> Hi,
>> >> >>
>> >> >> While updateing glibc-2.24-r2 failed to install.
>> >> >>
>> >> >> These are the last few lines of that process:
>> >> >>
>> >> >> 
>> >> >> al/execinfo.c.texi 
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/add.c.texi
>> >> >>  
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/summary.texi
>> >> >>  
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/pkgvers.texi
>> >> >>  | sort;\
>> >> >>  echo "@end direntry") > 
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi.new
>> >> >> mv -f 
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi.new
>> >> >>  
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi
>> >> >> LANGUAGE=C LC_ALL=C makeinfo -P 
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/
>> >> >>  
>> >> >> --output=/var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/libc.info
>> >> >>  libc.texinfo
>> >> >> libc.texinfo:6: warning: @codequotebacktick should only appear at the 
>> >> >> beginning of a line
>> >> >> libc.texinfo:6: warning: @codequoteundirected should only appear at 
>> >> >> the beginning of a line
>> >> >> libc.texinfo:6: warning: @codequoteundirected should not appear in 
>> >> >> @codequotebacktick
>> >> >> libc.texinfo:6: expected @codequoteundirected on or off, not `on' 
>> >> >> require'
>> >> >> libc.texinfo:6: superfluous argument to @codequotebacktick
>> >> >> libc.texinfo:6: expected @codequotebacktick on or off, not `on' and ''
>> >> >> make[2]: *** [Makefile:144: 
>> >> >> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/libc.info]
>> >> >>  Error 1
>> >> >> make[2]: Leaving directory 
>> >> >> '/var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24/manual'
>> >> >> make[1]: *** [Makefile:215: manual/subdir_install] Error 2
>> >> >> make[1]: Leaving directory 
>> >> >> '/var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24'
>> >> >> make: *** [Makefile:12: install] Error 2
>> >> >>  * ERROR: sys-libs/glibc-2.24-r2::gentoo failed (install phase):
>> >> >>  *   emake failed
>> >> >>  *
>> >> >>
>> >> >> If anything more is wanted, I will be happy to post the wanted logs.
>> >> >> But I want to prevent to logbomnb the mailinglist in beforehand... ;)
>> >> >>
>> >> >> Cheers
>> >> >> Meino
>> >> >>
>> >> >
>> >> > Hi,
>> >> >
>> >> > Is there any solution for this problem ?
>> >> > Does anyone else has the same or similiar problems with this system
>> >> > update?
>> >> >
>> >> > Cheers
>> >> > Meino
>> >> >
>> >>
>> >> What is the version of your gcc compiler?
>> >> The ebuild has this info on the version of gcc:
>> >> https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-libs/glibc/glibc-2.24-r2.ebuild
>> >> src_prepare() {
>> >> ...
>> >>
>> >> case $(gcc-fullversion) in
>> >> 4.8.[0-3]|4.9.0)
>> >> eerror "You need to switch to a newer compiler; gcc-4.8.[0-3] and
>> >> gcc-4.9.0 miscompile"
>> >> eerror "glibc.  See https://bugs.gentoo.org/547420 for details."
>> >> die "need to switch compilers #547420"
>> >> ;;
>> >> esac
>> >> ...
>> >> }
>> >>
>> >
>> > The gcc on my system says:
>> >
>> > gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0
>> > Copyright (C) 2015 Free Software Foundation, Inc.
>> > This is free software; see the source for copying conditions.  There is NO
>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> >
>> > if asked...
>> >
>> > Cheers
>> > mcc
>> >
>> >
>> >
>>
>> See if this post [1] helps:
>> [1]. https://forums.gentoo.org/viewtopic-t-789652-start-0.html
>>
> "My" problem seem to be related to the syntax-fu of texinfo (see above) and 
> seem
> to not gcc related, since compilation itsself runs fine.
>
> How can I fix it instead of watching it over and over at each
> suncing...

Right, something is broken with your makeinfo command from texinfo.

As a workaround, you could uninstall texinfo, and then upgrade glibc.
If the makeinfo command is not found, it will simply skip that build
step and leave you without a "libc.info" documentation file.

Re: [gentoo-user] glibc-2.24-r2 failed (install phase)

[Mike Gilbert]

On Thu, Jun 15, 2017 at 11:56 AM,   wrote:
> Hi,
>
> While updateing glibc-2.24-r2 failed to install.
>
> These are the last few lines of that process:
>
> 
> al/execinfo.c.texi 
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/add.c.texi
>  
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/summary.texi
>  
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/pkgvers.texi
>  | sort;  \
>  echo "@end direntry") > 
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi.new
> mv -f 
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi.new
>  
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/dir-add.texi
> LANGUAGE=C LC_ALL=C makeinfo -P 
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/
>  
> --output=/var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/libc.info
>  libc.texinfo
> libc.texinfo:6: warning: @codequotebacktick should only appear at the 
> beginning of a line
> libc.texinfo:6: warning: @codequoteundirected should only appear at the 
> beginning of a line
> libc.texinfo:6: warning: @codequoteundirected should not appear in 
> @codequotebacktick
> libc.texinfo:6: expected @codequoteundirected on or off, not `on' require'
> libc.texinfo:6: superfluous argument to @codequotebacktick
> libc.texinfo:6: expected @codequotebacktick on or off, not `on' and ''
> make[2]: *** [Makefile:144: 
> /var/tmp/portage/sys-libs/glibc-2.24-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/manual/libc.info]
>  Error 1
> make[2]: Leaving directory 
> '/var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24/manual'
> make[1]: *** [Makefile:215: manual/subdir_install] Error 2
> make[1]: Leaving directory 
> '/var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24'
> make: *** [Makefile:12: install] Error 2
>  * ERROR: sys-libs/glibc-2.24-r2::gentoo failed (install phase):
>  *   emake failed
>  *
>
> If anything more is wanted, I will be happy to post the wanted logs.
> But I want to prevent to logbomnb the mailinglist in beforehand... ;)

What version of sys-apps/texinfo do you have installed?

Re: [gentoo-user] [OT] Tools for putting HDD back to new state

[Mike Gilbert]

On Mon, Apr 3, 2017 at 2:11 PM, Harry Putnam  wrote:
> I probably should know this, but off the top of my head I don't
> remember ever running into anything like this.
>
> I'd like to do what ever is done to set a used  disk back to the
> state it was in when new... Not sure what that state is, but at least
> no evidence of boot manager or fs having been installed.
>
> This if for something I'm doing on OS openindiana (a solaris offshoot)
> and the disks are for that OS.
>
> The solaris milieu is somewhat behind linux in development of tools at
> least in my opinion.  That is why I'm asking here.
>
> I am a gentoo user as well, but expect I may have to boot the solaris
> host with one or another linux boot ISO in order to have the tools
> required.

If you are not worried about securely removing all data and simply
want to fool fdisk into thinking your drive is empty, use the wipefs
utility. This will zero-out key bytes like the MBR, partition table,
filesystem magic numbers, etc.

You'll want to run it once for each partition, and then once for the
whole device.

wipefs -a /dev/sdx1
wipefs -a /dev/sdx2
wipefs -a /dev/sdx

If you ARE worried about securely removing data, see the other replies
in this thread for better options.

Re: [gentoo-user] Perhaps add "gentoo-" in beginning of file name for iso files

[Mike Gilbert]

On Tue, Feb 14, 2017 at 6:08 PM, Johannes Rosenberger  wrote:
>
> On 15.02.2017 00:00, scootergrisen wrote:
>> When i download Gentoo Linux the file name might be called something
>> like:
>> livedvd-amd64-multilib-20160704.iso
>>
>> This might be fine if you just want that file and want to use it
>> straight away.
>>
>> But lets say like i just did downloaded multiple linux distributions
>> because i want to test them out so i have like 10-20 iso files or what
>> ever.
>>
>> Then later one when i see the file name
>> livedvd-amd64-multilib-20160704.iso i have no idea what distribution
>> that was.
>>
>> The other distributions i have downloaded all seem to start with the
>> name of the distribution in the file name. I Think Gentoo Linux is the
>> only one yet that does not.
>>
> So you can identify it uniquely. ;-)
>> So would it not be better to use a file name like this?:
>> gentoo-livedvd-amd64-multilib-20160704.iso
>>
> Could be nice. But not important.
> You can always run 'wget -O  '.
>
> You could write a GLEP? But then, you could just file a bug/ask somebody
> responsible for the naming.

A GLEP seems like overkill for something like this. I would suggest
filing a bug for the release engineering team.

Re: [gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules

[Mike Gilbert]

On Mon, Feb 13, 2017 at 1:51 PM, Remy Blank  wrote:
> Daniel Frey wrote on 2017-02-13 17:34:
>> On 02/13/2017 03:34 AM, Rich Freeman wrote:
>>> Anytime you see something like root=UUID=* that is being handled by an
>>> initramfs.  And of course a UUID is more reliable than a device name,
>>> since the latter can change if you add/remove a device, or maybe even
>>> if your firmware is having a bad day.  Identifying devices by UUID
>>> ensures the right one gets found, assuming it is available.  If you're
>>> using something like mdadm/lvm there are alternatives to UUID, but the
>>> point is the same, you're using a logical identifier that is based on
>>> what is stored on the disks and not just what port it is connected to.
>>>
>>
>> Are you sure? When I set up my EFI stub kernel on my Surface tablet, I
>> did not use an initramfs and I use PARTUUID= in the kernel built in init
>> line and it boots.
>
> Note that Rich wrote "UUID=", but you used "PARTUUID=". The former
> requires an initramfs, the latter doesn't. The details why escape me: if
> the filesystem code is built into the kernel (as opposed to a module), I
> see no practical reason why the FS UUID couldn't be determined by the
> kernel directly.

Determining the FS UUID would require scanning all partitions of all
attached disks, and invoking filesystem-specific code to parse out the
UUID.

Determining the PARTUUID only requires scanning the partition table of
each drive, and is only supported for GPT and MBR partition tables.
It's a much simpler task.

Re: [gentoo-user] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?

[Mike Gilbert]

On Tue, Feb 7, 2017 at 3:08 PM, Rich Freeman  wrote:
> I suspect sticking something like this before the chroot command might
> do the trick:
> unshare -p -f --mount-proc -m -i -u
>
> That will create a new PID, mount, IPC, and UTS namespace for the
> chroot.

Using unshare may require another kernel config change. The following
options must be enabled for that unshare command to work:

CONFIG_NAMESPACES
CONFIG_UTS_NS
CONFIG_IPC_NS
CONFIG_PID_NS

Re: [gentoo-user] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?

[Mike Gilbert]

On Tue, Feb 7, 2017 at 10:13 AM, Walter Dnes  wrote:
> On Tue, Feb 07, 2017 at 08:24:40AM +, J. Roeleveld wrote
>
>> I used to do this to build packages for my old 32bit netbook.
>>
>> To start a 32bit chroot:
>> # linux32 chroot  /bin/bash
>
>   I transferred over the CentOS system.  It fails on my system with
> "Exec format error"
>
> [i660][root][~] chroot /home/misc/centos65/ /bin/bash
> chroot: failed to run command '/bin/bash': Exec format error
>
> [i660][root][~] linux32 chroot /home/misc/centos65/ /bin/bash
> chroot: failed to run command '/bin/bash': Exec format error
>
>   The error is usually due to stuff like trying to run 32-bit code in a
> 64-bit environment.
>

You probably have the CONFIG_IA32_EMULATION kernel option disabled.

Re: [gentoo-user] rdate -s timeout for 129.6.15.28

[Mike Gilbert]

On Mon, Feb 6, 2017 at 3:28 PM, Mick <michaelkintz...@gmail.com> wrote:
> On Monday 06 Feb 2017 14:52:22 Mike Gilbert wrote:
>> On Mon, Feb 6, 2017 at 1:37 AM,  <the...@sys-concept.com> wrote:
>> > I installed "rdate" and trying to sync time on my new box but I'm getting:
>> >
>> > /usr/bin/rdate -s 129.6.15.28
>> > rdate: timeout for 129.6.15.28
>> >
>> > Time setting works on my other boxes but new the new one :-/
>>
>> I suggest upgrading to NTP, especially if the systems are powered on
>> for days at a time.
>
> Or ... chronyd if they are offline frequently (e.g. laptops).

I was referring to NTP the protocol (which is what chrony speaks), not
NTP the software.

Re: [gentoo-user] rdate -s timeout for 129.6.15.28

[Mike Gilbert]

On Mon, Feb 6, 2017 at 1:37 AM,   wrote:
> I installed "rdate" and trying to sync time on my new box but I'm getting:
>
> /usr/bin/rdate -s 129.6.15.28
> rdate: timeout for 129.6.15.28
>
> Time setting works on my other boxes but new the new one :-/

I suggest upgrading to NTP, especially if the systems are powered on
for days at a time.

Re: [gentoo-user] UEFI is teh SNAFU!

[Mike Gilbert]

On Mon, Jan 30, 2017 at 10:56 AM, Alan Grimes  wrote:
> I had to reboot my system again due to video driver update.
>
> I had set up a new build of my kernel in a UEFI partition. The
> BIOS/firmware seemed to be happy with the location.
>
> The machine stops stone cold dead the instant the firmware tries to
> transfer control to the new kernel.
>
> I found a switch in the debugging menu which enables the EFI console
> output. Why does this option exist? I mean why is it possible to compile
> a kernel that doesn't use every possible method to communicate with the
> user?
>
> Well, anyway, even with this selected, it still stops stone cold dead
> without producing any output at all. I could turn on some more debugging
> options, but they seem more hardcore than what I'm trying to do...
> (simply boot!)

Do you really need to start a new thread about your problems every
day? It's getting quite excessive.

Re: [gentoo-user] Openconnect overwriting /etc/resolv.conf

[Mike Gilbert]

On Tue, Dec 13, 2016 at 6:05 AM, Alexander Kapshuk
 wrote:
> Been using openconnect for a few years now.
> I currently have net-misc/openconnect-7.06-r1 installed.
> This morning, when logged in at a remote site, I noticed that when
> clicking, or typing, nothing would happen. Which somehow seemed to
> result in a similar behavior back on the local system, i.e. attempting
> to type commands in terminal had stopped working.
>
> Having rebooted my system and poked around system log and config
> files, I noticed that my /etc/resolv.conf got overwritten by
> openconnect. Further investigation indicated that it is done by design
> via this script: /etc/openconnect/openconnect.sh.
> I do not know if this is a recent change in openconnect's behaviour, I
> had no trouble of this sort doing remote work on the same system
> yesterday.
>
> An ad-hoc solution I have found online and applied to my environment is this:
> http://serverfault.com/questions/331299/how-can-i-stop-openconnect-from-changing-etc-resolv-conf
> chattr +i /etc/resolv.conf
>
> This seems to have helped. I can click and type both on remote systems
> and the local one with no trouble at all.
>
> Anyone else experienced this?
> What are your thoughts and suggestions on the matter?

You could install net-dns/openresolv, and set resolvconf=NO in
/etc/resolvconf.conf. openconnect.sh will automatically utilize
openresolv if it is installed, and that config setting prevents
openresolve from making any updates.

An uglier solution is to edit /etc/openconnect/openconnect.sh, and
comment out the following lines:

In do_connect():

if [ -n "$INTERNAL_IP4_DNS" ]; then
$MODIFYRESOLVCONF
fi

In do_disconnect():

if [ -n "$INTERNAL_IP4_DNS" ]; then
$RESTORERESOLVCONF
fi

Re: [gentoo-user] preserved rebuild failure with python

[Mike Gilbert]

On Wed, Dec 7, 2016 at 12:30 PM, allan gottlieb  wrote:
> On Wed, Dec 07 2016, Neil Bothwick wrote:
>
>> On Wed, 07 Dec 2016 10:54:59 -0500, allan gottlieb wrote:
>>
>>> >>emerge: there are no ebuilds to satisfy "dev-lang/python:3.3".
>>> >>(dependency required by "@preserved-rebuild" [argument])
>>> >
>>> > Does "qdepends -r dev-lang/python:3.3" reveal anything helpful?
>>>
>>>allan ~ # qdepends -r dev-lang/python:3.3
>>>depends: no matches found for your query
>>>
>>> Looks like no.
>>
>> How about something a bit less subtle
>>
>> grep python:3.3 /var/db/pkg/*/*/*.ebuild
>>
>> although that won't help if the dependency is in an eclass.
>
> Looks like an even blunter instrument is needed
>
>allan ~ # grep python:3.3 /var/db/pkg/*/*/*.ebuild
>allan ~ #
>

Have you tried simply removing dev-lang/python:3.3? It was
masked/removed from the tree some time ago.

Re: [gentoo-user] eselect-python without effect

[Mike Gilbert]

On Thu, Nov 10, 2016 at 10:02 AM, Silvio Siefke  wrote:
> Hello,
>
> when I use eselect python set 2 have this no effect and on other machines
> is python linked with python-wrapperscript, but on the laptop is python
> linked with pyexec.
>
> Have someone an idea?

You are probably running ~arch on the laptop and stable on the other machines.

We are changing the way eselect-python works in newer versions -- we
just haven't stabilized it yet.

Re: [gentoo-user] several global use flags should be local

[Mike Gilbert]

On Sun, Oct 9, 2016 at 1:31 PM, Ayush  wrote:
> I've already raised a bug report about this issue over here [1]. There are
> several global USE flags defined here [2] that should be local according to
> the this [3] definition. Some of these USE flags are -
>
> 3dfx
> pcntl
> inifile
> sharedmem
> simplexml
> wddx
> oci8-instant-client
> qdbm
> tokenizer
>
> Shouldn't these USE flags be local? Most of them are applicable to only 2-3
> packages or sometimes even a single package.

This would be a reasonable topic for discussion on the gentoo-dev mailing list.

Re: [gentoo-user] How to use efibootmgr

[Mike Gilbert]

On Mon, Sep 19, 2016 at 10:23 AM, Peter Humphrey  wrote:
> Hello list,
>
> I'm trying to install a customised version of SysRescCD on a USB drive, and
> it's all uphill.
>
> The current stage has me trying to create a UEFI boot entry for it. I have
> several entries I no longer need and I'm trying to delete them with
> efibootmgr. This is what happens:
>
> # efibootmgr --remove-dups
> BootCurrent: 0002
> Timeout: 1 seconds
> BootOrder: 0003,0001,,0002,0008,0009,0010,0014
> Boot* SysRescCD
> Boot0001* SysRescCD
> Boot0002* Linux Boot Manager
> Boot0003* SysRescCD
> Boot0008* CD/DVD Drive
> Boot0009* Hard Drive
> Boot0010* UEFI OS
> Boot0014* UEFI: SanDisk
>
> # efibootmgr --delete-bootnum 0001
> You must specify an entry to delete (see the -b option).
>
> But I have - number 1. The manual says:
>
> -b | --bootnum 
> Modify Boot (hex)
>
> -B | --delete-bootnum
> Delete bootnum (hex)
>
> No variation of 1, 01, 0x1, 0x0001 etc. makes any difference. I know I'm not
> as bright as I used to be, but what on earth have I got wrong? /boot is
> mounted.

The manpage seems to be incorrect; -B/--delete-bootnum does not take
any argument. Instead, you must specify the entry number using the -b
option.

Try this:

efibootmgr -b 0001 -B

Re: [gentoo-user] ext4 root-partition mounted read-only as "type none"

[Mike Gilbert]

On Wed, Sep 14, 2016 at 4:31 PM, Holger Wünsche
 wrote:
> So /proc/mounts is the file giving the correct information.

Your issue is that /etc/mtab is stale. Recent versions of OpenRC
recommend that you replace it with a symlink to /proc/self/mounts.

Re: [gentoo-user] Not able to install ksh93

[Mike Gilbert]

On Fri, Sep 9, 2016 at 4:07 PM, Harry Putnam  wrote:
> Hopefully someone here will recognize what is happening and some idea
> what I should do about it.

Sorry, but I'm not going to troubleshoot a 5 year old version. Please
post build logs from the latest version of ksh in the tree. Preferably
attached to a bug report.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Mike Gilbert]

On Tue, Sep 6, 2016 at 6:03 PM, gevisz  wrote:
> 2016-09-07 0:32 GMT+03:00 Neil Bothwick :
>> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>>
>>> >> But it seems that GRUB does not read fstab... :(
>>> >
>>> > It does not, because it has not loaded the kernel yet, so it cannot do
>>> > anything on the system.
>>>
>>> Oh, poor little Grand Unified Boot Loader!
>>>
>>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>>
>> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
>> program to write grub.cfg. As you were asking whether you should run
>> grub-mkconfig again, it seems reasonable to assume that you haven't run
>> it since adding the disk, not that it should make a difference.
>>
>>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>>   And in my fstab all the disks are refered by UUID!
>>>
>>
>> grub-mkconfig doesn't care about the fstab of the running distro since it
>> scans your drives for all operating systems it can boot.
>>
>> Either look in grub.cfg to see what it going on or post it here along
>> with the exact error messages so others may try for you.
>>
>
> I have added the following line to the /etc/default/grub
>
> GRUB_CMDLINE_LINUX="root=UUID=44***"
>
> run
>
> # grub-mkconfig -o /boot/grub/grub.cfg
>
> and got in  the following entry
>
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
> load_video
> insmod gzio
> insmod part_msdos
> insmod ext2
> set root='hd1,msdos3'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
> else
>   search --no-floppy --fs-uuid --set=root 44***
> fi
> echo'Loading Linux 4.4.6-gentoo ...'
> linux/boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
> }
>
> wich, in my view, does not differ a lot from what was before.
>
> The 44*** denotes the UUID of my boot partition.
>
> Will try it tomorrow and report.
>

grub-mkconfig is not finding an initramfs, as evidenced by the lack of
an "initrd" in in grub.cfg.

If it is unable to find an initramfs, it will always output
root=/dev/sdX instead of root=UUID=...

Re: [gentoo-user] UEFI booting

[Mike Gilbert]

On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey  wrote:
> On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote:
>> On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote:
>> > I'd still like to know where the directory /usr/lib64/systemd/boot/efi
>> > came from though.
>>
>> Surely it's from systemd-boot, it is installed by systemd here. What does
>> qfile tell you?
>>
>> $ qfile /usr/lib/systemd/boot/efi
>
> Yes, it is. I was puzzling over the wrong thing. Here's part of the output
> of "bootctl status":
>
> Boot Loader Binaries:
>   ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5
>  File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231)
>  File: └─/EFI/BOOT/BOOTX64.EFI
>
> Those binaries have been built on my system: by what process?

When you run bootctl install, it copies
/usr/lib/systemd/boot/efi/systemd-bootx64.efi to
/boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI.

BOOTX64.EFI is only there as a fallback; if your EFI variables get
reset for some reason, most EFI firmwares will look for a file by that
name as a failsafe.

Re: [gentoo-user] UEFI booting

[Mike Gilbert]

On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey  wrote:
> In my search for a suitable boot method, I'm trying Mike G's systemd-boot
> ebuild. I've installed it with no problem, and now I reach the heart-in-
> mouth stage of actually replacing gummiboot with it. But first, the backup,
> including dd of what used to be called the MBR (what is it now?).

It should be basically a drop-in replacement, with a slightly
different name. It should not require any modification to your disk
layout.

Also, you should be able to configure your firmware to load either
gummiboot or systemd-boot, so you have a fallback if the new code
fails.