Re: [gentoo-user] Re: How to test package install?

[Andreas K. Huettel]

Am Freitag, 16. Februar 2018, 00:21:37 CET schrieb Ian Zimmerman:
> On 2018-02-15 23:39, Andreas K. Huettel wrote:
> > > I'm trying to test my package by running "ebuild /path/to/pkg.ebuild
> > > install".  Naturally (for me) I do this as an unprivileged user, not
> > > as root.  It fails because at least some steps such as dobin need to
> > > give away ownership of the files being installed.  I tried to run
> > > the whole thing including compilation under fakeroot but that
> > > doesn't help.
> > 
> > That should usually "just work".
> > 
> > Did you use fakeroot directly (bad), or did you add "fakeroot" to
> > FEATURES in make.conf (good)?
> 
> The former.  I didn't know about the feature.  Is it safe to enable it
> for "production" runs as well?

Yes, it should be safe. At least I have it on all the time and never noticed 
any problems.

-- 
Dr. Andreas K. Hüttel
e-mail m...@akhuettel.de
http://www.akhuettel.de/

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

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

[Ian Zimmerman]

On 2018-02-16 11:14, Mike Gilbert wrote:

> 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
> }

Thanks for this thorough and relevant answer.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: Can't restart or stop openvpn: it is "already started, but inactive"

[Grant Edwards]

On 2018-02-16, Neil Bothwick  wrote:
> On Fri, 16 Feb 2018 17:41:43 + (UTC), Grant Edwards wrote:
>
>> There must be something short of a reboot that will allow me to
>> restart a failed openvpn client?
>> 
>> # rc-service openvpn.wr7 stop
>>  * Stopping openvpn.wr7 ...
>>  *
>> VPNPID='/var/run/openvpn.wr7.pid'
>>   [ !! ]
>>  * ERROR: openvpn.wr7 failed to stop
>
> rc-service openvpn.wr7 zap?

Thanks.

I had resorted to just removing /var/run/openrc/inactive/

Now that I know what to look for, I find it's on the openrc-run man
page.  (I'd never heard of 'openrc-run' before, so had no idea to look
at that page.)

-- 
Grant Edwards   grant.b.edwardsYow! UH-OH!!  I put on
  at   "GREAT HEAD-ON TRAIN
  gmail.comCOLLISIONS of the 50's"
   by mistake!!!

Re: [gentoo-user] Boot Gentoo live iso from grub

[Ian Bloss]

Probably need to pass a uuid to the real root kernel param

On Fri, Feb 16, 2018, 11:34 AM zless  wrote:

> Hello all,
>
> I'm trying to have the Gentoo Live CD ISO as a recovery media in grub.
>
> I tried all the options I could think off in a custom grub menu entry like
> this:
>
> menuentry "Gentoo ISO" {
> set cmdline="root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs
> loop=/image.squashfs cdroot initrd=gentoo.igz BOOT_IMAGE=gentoo"
> loopback loop /path/to/iso/install-amd64-minimal-20180206T214502Z.iso
> linux  (loop)/isolinux/gentoo $cmdline isoloop=/image.squashfs
> initrd=gentoo.igz vga=791 BOOT_IMAGE=gentoo
> initrd (loop)/isolinux/gentoo.igz
> }
>
> It boots the live CD kernel, it even asks for the keymap but then it fails
> to mount the root device.
>
> Any idea how to properly boot the iso from grub?
>
>
>
>
>
>

[gentoo-user] Boot Gentoo live iso from grub

[zless]

Hello all,

I'm trying to have the Gentoo Live CD ISO as a recovery media in grub.

I tried all the options I could think off in a custom grub menu entry like 
this:

menuentry "Gentoo ISO" {
set cmdline="root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs 
loop=/image.squashfs cdroot initrd=gentoo.igz BOOT_IMAGE=gentoo"
loopback loop /path/to/iso/install-amd64-minimal-20180206T214502Z.iso
linux  (loop)/isolinux/gentoo $cmdline isoloop=/image.squashfs 
initrd=gentoo.igz vga=791 BOOT_IMAGE=gentoo
initrd (loop)/isolinux/gentoo.igz
}

It boots the live CD kernel, it even asks for the keymap but then it fails to 
mount the root device.

Any idea how to properly boot the iso from grub?

Re: [gentoo-user] Can't restart or stop openvpn: it is "already started, but inactive"

[Neil Bothwick]

On Fri, 16 Feb 2018 17:41:43 + (UTC), Grant Edwards wrote:

> There must be something short of a reboot that will allow me to
> restart a failed openvpn client?
> 
> # rc-service openvpn.wr7 stop
>  * Stopping openvpn.wr7 ...
>  *
> VPNPID='/var/run/openvpn.wr7.pid' 
>  [ !! ]
>  * ERROR: openvpn.wr7 failed to stop

rc-service openvpn.wr7 zap?


-- 
Neil Bothwick

Old hitchhikers never die-they just throw in the towel.


pgpIGNYnlZ6Q0.pgp
Description: OpenPGP digital signature

[gentoo-user] Can't restart or stop openvpn: it is "already started, but inactive"

[Grant Edwards]

I've got a couple different openvpn client configurations set up, and
if the fail to connect, the client apparently dies and then there's no
way to stop or restart it.  There is no openvpn process running.
There is no PID file. Yet rc-server insists that it's "already
started".  Why is it saying that?

There must be something short of a reboot that will allow me to
restart a failed openvpn client?

# rc-service openvpn.wr7 stop
 * Stopping openvpn.wr7 ...
 * VPNPID='/var/run/openvpn.wr7.pid'
  [ !! ]
 * ERROR: openvpn.wr7 failed to stop

# rc-service openvpn.wr7 start
 * WARNING: openvpn.wr7 has already started, but is inactive

# ls /var/run/openvpn*
ls: cannot access '/var/run/openvpn*': No such file or directory

# ps ax | grep openvpn
10127 pts/2S+ 0:00 grep --colour=auto openvpn
# 


-- 
Grant Edwards   grant.b.edwardsYow! Gibble, Gobble, we
  at   ACCEPT YOU ...
  gmail.com

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
}