Re: [gentoo-user] remove gnome/systemd

[Daniel Campbell]

On 09/12/2017 03:07 PM, Heiko Baums wrote:
> Am Tue, 12 Sep 2017 17:28:40 -0400
> schrieb Mike Gilbert :
> 
>> I would advise against this INSTALL_MASK setting. It is quite likely
>> to break things (like sys-fs/udev).
> 
> No, it's not.
> 
> I'd consider it a bug if systemd is not installed and
> another package that doesn't depend on systemd relies on something that
> is installed in a systemd subdirectory.
> 
> And for me nothing was broken since several years now.
> 
> And, like I said, I'm using eudev instead of udev.
> 
> Heiko
> 
You may be using eudev (and thus don't need to worry about it), but if a
person blindly copies that into their make.conf and sys-fs/udev breaks,
they'll get to keep the pieces because they deliberately screwed
themselves. It's not a use case we can support. It doesn't mean
INSTALL_MASK is always a bad idea; it's simply meant to be used by
people who are fully aware of its effects.

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] remove gnome/systemd

[Heiko Baums]

Am Tue, 12 Sep 2017 17:28:40 -0400
schrieb Mike Gilbert :

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

No, it's not.

I'd consider it a bug if systemd is not installed and
another package that doesn't depend on systemd relies on something that
is installed in a systemd subdirectory.

And for me nothing was broken since several years now.

And, like I said, I'm using eudev instead of udev.

Heiko

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] remove gnome/systemd

[Heiko Baums]

Am Tue, 12 Sep 2017 17:55:22 +0200
schrieb Raffaele Belardi :

> 2. emerge -C gnome networkmanager

You don't need to uninstall networkmanager except you want to uninstall
it for some other reasons. It doesn't need gnome or systemd.

> 5. emerge -N lxde-meta

I'd prefer Xfce, but that's a matter of taste. As far as I know LXDE
isn't developed any more in favor of LXQt.

> 6. emerge -N xdm openrc anacron sysklogd sysvinit

You don't need to install sysvinit explicitly. It's a dependency of
openrc.

Instead of anacron I'd suggest fcron. It has all the features of both
cron and anacron.

Instead of sysklogd I would use syslog-ng. I don't remember the reasons.

Instead of xdm you'd better try slim or lightdm. Lightdm doesn't need
systemd either, except if you want to use multiseat with it.

Then you should replace udev by eudev and put USE="-gnome -systemd"
into your USE flags in /etc/portage/make.conf.

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"

Heiko

[gentoo-user] Re: remove gnome/systemd

[Nikos Chantziaras]

On 12/09/17 18:55, Raffaele Belardi wrote:

After several months of Gnome3 I decided it is too heavy for my old
workstation and would like to go back to LXDE. The flow could be:

1. rebuild kernel with openRC support and install
2. emerge -C gnome networkmanager
3. emerge -C systemd
4. change profile to generic desktop (non-Gnome)
5. emerge -N lxde-meta  
6. emerge -N xdm openrc anacron sysklogd sysvinit
7. reboot

I doubt it will be this easy... anything I'm missing, suggestions?


You can just keep systemd and only remove Gnome. Switch to another, 
non-Gnome systemd profile and unmerge Gnome, then do a --depclean. Also 
look in your world file to see if you have anything in there that 
prevents depclean from removing it.

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] Downgrading glibc prevented by emerge/portage...but why initiated?

[tuxic]

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


Cheers
Meino

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

[tuxic]

On 09/12 04:50, Andreas K. Huettel wrote:
> Am Dienstag, 12. September 2017, 05:43:59 CEST schrieb tu...@posteo.de:
> > Hi,
> > 
> > got a problem this morning:
> > >>> Verifying ebuild manifests
> > >>> Running pre-merge checks for sys-libs/glibc-2.24-r4
> > 
> >  * Sanity check to keep you from breaking your system:
> >  *  Downgrading glibc is not supported and a sure way to destruction
> 
> ... because I accidentally removed 2.24-r4 instead of 2.24-r3. 
> 
> Got fixed a few hours later as soon as someone filed a bug. 
> (I wanted to keep the last 2.24 revision.)
> 
> --> so, file bugs! :)
> 
> That said, 2.24 won't go stable; the current stable candidate is 2.25-r5. 
> 
> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)
> 

Hi Andreas,

...and it was also a configuration bug on my side (see my last
posting).

Do you know how to solve this long lasting texinfo problem on my side?

Cheers
Meino

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

[Andreas K. Huettel]

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

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

[Andreas K. Huettel]

Am Dienstag, 12. September 2017, 05:43:59 CEST schrieb tu...@posteo.de:
> Hi,
> 
> got a problem this morning:
> >>> Verifying ebuild manifests
> >>> Running pre-merge checks for sys-libs/glibc-2.24-r4
> 
>  * Sanity check to keep you from breaking your system:
>  *  Downgrading glibc is not supported and a sure way to destruction

... because I accidentally removed 2.24-r4 instead of 2.24-r3. 

Got fixed a few hours later as soon as someone filed a bug. 
(I wanted to keep the last 2.24 revision.)

--> so, file bugs! :)

That said, 2.24 won't go stable; the current stable candidate is 2.25-r5. 

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

Re: [gentoo-user] remove gnome/systemd

[Nils Freydank]

Am Dienstag, 12. September 2017, 17:55:22 CEST schrieb Raffaele Belardi:
> After several months of Gnome3 I decided it is too heavy for my old
> workstation and would like to go back to LXDE. The flow could be:
> 
> 1. rebuild kernel with openRC support and install
> 2. emerge -C gnome networkmanager
> 3. emerge -C systemd
> 4. change profile to generic desktop (non-Gnome)
> 5. emerge -N lxde-meta
> 6. emerge -N xdm openrc anacron sysklogd sysvinit
> 7. reboot
> 
> I doubt it will be this easy... anything I'm missing, suggestions?
Hi, I’d run it a bit differently:
- change profile
- force-remove gnome (emerge -aC)
- double checking USE flags and updating @world as usual
- cleanup (emerge --ask --verbose --clean)
- install services that aren’t already installed as a dep (maybe anacron or 
ntpd/chrony)
- Adding the services to appropriate runlevels (e.g. rc-update add xdm default)

- If necessary, replacing udev with eudev. I don’t remember if it got changed 
automatically
a while ago on one of my systems due the switch.

If you didn’t explicitly removed OpenRC you have it already installed, (removal 
is possible though),
and sysvinit gets pulled in by OpenRC ;-)

BTW, I personally like elogind (a standalone "cut off" of systemd-logind) and 
can suggest it
as a surrogate for consolekit2. Support by the upstream is incredible fast.

Have fun :)
Nils
> thanks,
> 
> raffaele

-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

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

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

[tuxic]

Hi,

WRONG! :) :) :)

I did something different, but it was the same amount of "wrong".

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.

As suggested I run perl-cleaner, I checked my environment for
suspicious entrie...but looks fine (at least for me).

I really wnat to get rid of this damn texinfo problem and I 
desperately aksing for help, since I didn't found the problem myself.

But before bombarding the mailinglist with TONS of logs I would like
to ask, what logging to post first?

Cheers and thanks for the support in advance!
Meino





On 09/12 07:32, Franz Fellner wrote:
> My guess: You have glibc-2.24-r4 and one of the 2.25 with revision <-r4
> listed WITH EXACT VERSION AND REVISiON in your package.accept_keywords. The
> recent glibc-cleanp remove those 2.25 revisions and only left 2.25-r4 and
> 2.24-r4 Leaving you with the downgrade as only option to get the most
> recent available version.
> 
> 2017-09-12 9:17 GMT+02:00 Alan McKinnon :
> 
> > On 12/09/2017 05:43, tu...@posteo.de wrote:
> > > Hi,
> > >
> > > got a problem this morning:
> > >
> >  Verifying ebuild manifests
> >  Running pre-merge checks for sys-libs/glibc-2.24-r4
> > >  * Sanity check to keep you from breaking your system:
> > >  *  Downgrading glibc is not supported and a sure way to destruction
> > >  * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase):
> > >  *   aborting to save your system
> > >  *
> > >  * Call stack:
> > >  *ebuild.sh, line 115:  Called pkg_pretend
> > >  *ebuild.sh, line 348:  Called
> > toolchain-glibc_pkg_pretend
> > >  *   toolchain-glibc.eclass, line 507:  Called die
> > >  * The specific snippet of code:
> > >  *die "aborting to save your system"
> > >  *
> > >  * If you need support, post the output of `emerge --info
> > '=sys-libs/glibc-2.24-r4::gentoo'`,
> > >  * the complete build log and the output of `emerge -pqv
> > '=sys-libs/glibc-2.24-r4::gentoo'`.
> > >  * The complete build log is located at '/var/tmp/portage/sys-libs/
> > glibc-2.24-r4/temp/build.log'.
> > >  * The ebuild environment file is located at '/var/tmp/portage/sys-libs/
> > glibc-2.24-r4/temp/die.env'.
> > >  * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir'
> > >  * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24'
> >  Running pre-merge checks for media-sound/pulseaudio-11.0
> > >  * Determining the location of the kernel source code
> > >  * Found kernel source directory:
> > >  * /usr/src/linux
> > >  * Found sources for kernel version:
> > >  * 4.13.1-RT
> > >  * Checking for suitable kernel configuration options...
> > >  [ ok ]
> > >  * A preallocated buffer-size of 2048 (kB) or higher is recommended for
> > the HD-audio driver!
> > >  * CONFIG_SND_HDA_PREALLOC_SIZE=64
> > >
> > > I would interpret this as:
> >
> > Looks to me like you are assuming the glibc maintainer has more
> > knowledge of the future that he/she actually has.
> >
> > >
> > > In the past emerge had updated glibc to a higher version as it want it
> > > to install now and prevented the latter becayse it would be downgrade,
> > > which in turn would render my box useless.
> >
> > No, not useless. It's a safety check for just in case. And now you must
> > bypass the checks
> >
> > >
> > > But why updateing to higher version in the first step
> >
> > Because you had a valid ebuild in the tree that said to do it ?
> > >
> > or attempting
> > > to downgrade now?
> >
> > Because now you don't have that valid ebuild anymore?
> >
> >
> > >
> > > And finally...ANy update is blocked for now it seems...how can I get
> > > out of this?
> >
> > Why is glibc wanting to downgrade? What is your current version?
> >
> > both of these versions are in the tree: (~)2.24-r4^s (~)2.25-r4^s
> > so there is at least 1 glibc higher than what portage wants to downgrade
> > to.
> >
> > You need to find out why 2.25-r4 is not being used. Usual tools, e.g.:
> >
> > grep -r glibc /etc/portage
> > and any other methods you prefer
> >
> > As a last resort if the ebuld maintainer screwed up, you can bypass the
> > safety check. Edit ${PORTDIR}/eclass/toolchain-glibc.eclass and comment
> > out the check in
> > toolchain-glibc_pkg_pretend()
> >
> > This is unlikely to destroy the system. Cause a problem - maybe. Destroy
> > it? No. The wording of the safety check is hugely over-dramatic to
> > discourage people from downgrading willy-nilly without thinking
> >
> > --
> > Alan McKinnon
> > alan.mckin...@gmail.com
> >
> >
> >

[gentoo-user] remove gnome/systemd

[Raffaele Belardi]

After several months of Gnome3 I decided it is too heavy for my old
workstation and would like to go back to LXDE. The flow could be:

1. rebuild kernel with openRC support and install
2. emerge -C gnome networkmanager
3. emerge -C systemd
4. change profile to generic desktop (non-Gnome)
5. emerge -N lxde-meta  
6. emerge -N xdm openrc anacron sysklogd sysvinit
7. reboot

I doubt it will be this easy... anything I'm missing, suggestions?

thanks,

raffaele

Re: [gentoo-user] Is anyone using Scaleway VM hosting?

[Stroller]

> On 12 Sep 2017, at 12:47, Alexey Eschenko  wrote:
> 
>> is it merely that "images" are copied when they're deployed, whereas 
>> "snapshots" are resumed and any changes overwrite the old filesystem? Are 
>> there any other differences?
> Yes, like that. Snapshot is backup for one volume. It can be converted to the 
> image for creation of new VM's or to the volume and then mounted to one of 
> your machines. As far as I understand, "snapshot" is raw data which can be 
> used in several ways.
> (and much more)

Many thanks for your help.

Stroller.

Re: [gentoo-user] wireless software config problem

[allan gottlieb]

On Thu, Sep 07 2017, allan gottlieb wrote:

> On Thu, Sep 07 2017, Canek Peláez Valdés wrote:
>
>> On Wed, Sep 6, 2017 at 6:31 PM, allan gottlieb  wrote:
>>>
>>> My system runs gnome3/systemd.  I use NetworkManager, which is mostly
>>> working fine.
>>>
>>> At work the desired network is named "nyu".  The sysadmins say I need to
>>> change at least one security parameter.  When I open the gui it shows
>>> the network configuration parameters (by clicking the gear) and lets me
>>> select different values.  However the "Apply" button never becomes
>>> active so I can only "Cancel".
>>>
>>> If I try to select the "nyu" network it asks for the password, which I
>>> know and enter. I then click the appropriate button (something like
>>> "apply" or "ok").  As expected the window goes away but I am not
>>> connected and the window reappears.
>>>
>>> A "tip" from the sys admins at work is to somehow tell my system to
>>> forget all it knows about the network "nyu", but neither I nor they know
>>> how to do it (they don't "fully support" linux).
>>
>> I would try this:
>>
>> 1. Select the system menu (top right corner)
>> 2. Select settings (lower left corner of the menu)
>> 3. Select Network
>> 4. Click the gears icon for the wireless network
>> 5. Select the "Reset" option (last option available)
>> 6. Click the "Forget" button
>>
>> This should allow you to start from the beginning. You should not need to
>> muck around  around with permissions, it should Just Work™.
>>
>> Regards.
>> --
>> Dr. Canek Peláez Valdés
>
> Thank you canek!
>
> It is a little embarrassing since I got to the same screen as you see in
> step 5 via a different path but didn't think of "reset".  Instead I
> tried "security" and "identity", made my changes but could not "apply"
> them.  I am back at nyu on tuesday and will definitely try your
> suggestion.
>
> Thank you again.
> allan

Worked Perfectly!
thanks again,
allan

Re: [gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[Mick]

On Tuesday, 12 September 2017 13:13:32 BST Michael Palimaka wrote:
> On 09/12/2017 05:04 AM, Daniel Frey wrote:
> > According to a comment in the bug, you can try to figure out which
> > session it is (ck-list-sessions) and look for the X11 display property
> > set. This will not work (or could be difficult) if you have several
> > users using KDE at the same time and can't tell the sessions apart.
> > 
> > Once you figure that out, remember the session name and:
> > 
> > # su -c 'dbus-send --system --print-reply \
> > --dest="org.freedesktop.ConsoleKit" \
> > 
> >  /org/freedesktop/ConsoleKit/ \
> > 
> > org.freedesktop.ConsoleKit.Session.Unlock'
> 
> If there a nice way to wrap this up in a script I'd be interesting in
> shipping this for non-logind systems.
> 
> Another option is sys-auth/elogind, which provides the logind interface
> and tools (like loginctl) for non-systemd systems. This is what I've
> been testing with OpenRC for some time.
> 
> I read that ConsoleKit is also supporting the logind dbus interface now.
> This would in theory make it easy to create a tool to unlock the
> session, but I haven't had a chance to test it yet.

I think if Plasma shipped with screenlock unset as a default this problem 
would not exist for non-systemd set ups.  I disabled Plasma's screenlock and 
after after some time of inactivity eventually DPMS kicks in and the monitors 
go into power saving mode.  This negates for needing special scripts elogind 
or anything else KDE/Plasma never needed before now.

Nevertheless, the suggestions for using dbus-send were useful for getting me 
out of a hole.  Thanks again! :-)
-- 
Regards,
Mick

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

[gentoo-user] qt4 app's icons

[Raymond Jennings]

I noticed something strange.

When I downgraded VLC to use qt4 after a bug...the icon turned from the
familiar orange traffic cone ot an ugly B version.

That's when I realized the same thing had happned to classic skype.

Did someone apply code to deliberately grayscale the icons of qt4 apps?

No bugs that I know of...but it does seem like a pattern and I have a hunch
something fishy is going on.

[gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[Michael Palimaka]

On 09/12/2017 05:04 AM, Daniel Frey wrote:
> According to a comment in the bug, you can try to figure out which
> session it is (ck-list-sessions) and look for the X11 display property
> set. This will not work (or could be difficult) if you have several
> users using KDE at the same time and can't tell the sessions apart.
> 
> Once you figure that out, remember the session name and:
> 
> # su -c 'dbus-send --system --print-reply \
> --dest="org.freedesktop.ConsoleKit" \
>  /org/freedesktop/ConsoleKit/ \
> org.freedesktop.ConsoleKit.Session.Unlock'
> 

If there a nice way to wrap this up in a script I'd be interesting in
shipping this for non-logind systems.

Another option is sys-auth/elogind, which provides the logind interface
and tools (like loginctl) for non-systemd systems. This is what I've
been testing with OpenRC for some time.

I read that ConsoleKit is also supporting the logind dbus interface now.
This would in theory make it easy to create a tool to unlock the
session, but I haven't had a chance to test it yet.

Re: [gentoo-user] Is anyone using Scaleway VM hosting?

[Alexey Eschenko]

Hi.


is it merely that "images" are copied when they're deployed, whereas 
"snapshots" are resumed and any changes overwrite the old filesystem? Are there any other 
differences?
Yes, like that. Snapshot is backup for one volume. It can be converted 
to the image for creation of new VM's or to the volume and then mounted 
to one of your machines. As far as I understand, "snapshot" is raw data 
which can be used in several ways.



but I lack confidence because this doesn't seem to be explained anywhere
I think it would  be better if you ask Scaleway support too. At least 
you will be sure that they know exactly what they are saying.



That sounds reasonable, but when I go to shutdown the VM and see this scary 
message - https://i.imgur.com/1E02DrP.png
That's one of their user-unfriendly interfaces. "Archive" will not 
destroy your data and make you able to create snapshots. On the other 
hand "Terminate" will actually destroy almost all resources of your VM 
(excluding IP, snapshots and images).



I assume that "Archive" is the same as shutting down my PC - the contents of 
the VM are saved, and I can start it up again later.
AFAIK only for LSSD. I didn't used DSSD and can't tell you anything 
about it.

I don't understand the warning about the DSSD being "totally erased without any 
possible recovery"
Me too. I'd recommend you to create support ticket and then post their 
response about it here.

I don't feel confident in what I'm asking at the moment - I feel like these 
kind of questions ought to be covered in the first pages of a beginners' FAQ, 
but I don't immediately find them on Scaleway's site. I.E. I'm asking dumb 
questions, or I don't know the right questions to ask.
Your questions is pretty relevant and logical. Their FAQ is far from 
ideal. When I was moving my VM's from dedicated server to Scaleway I had 
questions too. Don't hesitate and write them a message. After all you're 
going to pay them money and answering your questions is their work.



I can't help but wondering if I should have spent the extra €2 a month and gone 
for Linode.
I chosen Scaleway only to cut the costs of my not very important 
resources. If you don't mind to pay a little more then it probably may 
be not such a bad idea to use more friendly hosting company if you're 
confident in them.



are customers always billed on an hourly basis?

Yes. You will be billed in the begining of each month.


if I have a have VM that I only spin up when I need it, an hour or two at a 
time, for a few hours a month, am I right in thinking I pay only pennies for 
that?
Not quite. You're billed for many things separately. It's not only CPU 
usage that you pay for. Read this page: 
https://www.scaleway.com/faq/billing/


I thing it can contain answers for most of your questions about billing.

In other words if you stop your VM then you stop paying for CPU but 
don't stop to pay for IP, volumes, snapshots, etc.



Is this charging model common amongst VM hosting providers?
I've seen some other providers with such billing rules. Can't say that 
it's industrial standard but I think it's popular.



On 09/11/2017 02:40 PM, Stroller wrote:

On 11 Sep 2017, at 00:08, Alexey Eschenko  wrote:

I'm using Scaleway with Gentoo VM for two months. You can try to ask here but I 
don't know if I can answer to you properly.

Thanks.

I signed up for an account there a day or two ago, and set up a VM running 
Gentoo.

Scaleway provide a Gentoo VM image x86_64-gentoo-latest-2016-04-06_16:15, so I 
added a user account and a handful of essential tools and started updating it 
to latest.

Having updated the VM to the current tree, I want to make an image of the 
system so that I have my Gentoo minimal 9-2017 VM that I can copy and deploy 
any time.

The VM admin interface has sections for "volumes", "snapshots" and "images" - I 
assume they're all kinds of disc images, but I don't think I fully understand the difference.

I think:

• Volumes are active disc images, currently deployed in a VM.
• Snapshots are VM disc images, which are saved once the VM has been shutdown.
• Images are VM disk images which can be used as the basis for new VMs?

If my understanding is correct, I don't really see the difference between a "snapshot" and an 
"image" - is it merely that "images" are copied when they're deployed, whereas 
"snapshots" are resumed and any changes overwrite the old filesystem? Are there any other differences?

I'm used to running Linux on physical hardware, so I tend to think of disc images as being created if I boot 
from SystemRescueCD and `dd if=/dev/sda of=/mnt/usb-drive/old-pc.dd.img`. I can understand that, running a VM 
farm, one would probably want to have a bunch of disk images available to use - some of these I might label 
"my-gentoo-basic-master-2017" and "my-gentoo-webserver-master-2017", which I would mark 
as read-only, whilst others would be "my-webserver-www.something.com", and which would be current, 
active 

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

[Franz Fellner]

My guess: You have glibc-2.24-r4 and one of the 2.25 with revision <-r4
listed WITH EXACT VERSION AND REVISiON in your package.accept_keywords. The
recent glibc-cleanp remove those 2.25 revisions and only left 2.25-r4 and
2.24-r4 Leaving you with the downgrade as only option to get the most
recent available version.

2017-09-12 9:17 GMT+02:00 Alan McKinnon :

> On 12/09/2017 05:43, tu...@posteo.de wrote:
> > Hi,
> >
> > got a problem this morning:
> >
>  Verifying ebuild manifests
>  Running pre-merge checks for sys-libs/glibc-2.24-r4
> >  * Sanity check to keep you from breaking your system:
> >  *  Downgrading glibc is not supported and a sure way to destruction
> >  * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase):
> >  *   aborting to save your system
> >  *
> >  * Call stack:
> >  *ebuild.sh, line 115:  Called pkg_pretend
> >  *ebuild.sh, line 348:  Called
> toolchain-glibc_pkg_pretend
> >  *   toolchain-glibc.eclass, line 507:  Called die
> >  * The specific snippet of code:
> >  *die "aborting to save your system"
> >  *
> >  * If you need support, post the output of `emerge --info
> '=sys-libs/glibc-2.24-r4::gentoo'`,
> >  * the complete build log and the output of `emerge -pqv
> '=sys-libs/glibc-2.24-r4::gentoo'`.
> >  * The complete build log is located at '/var/tmp/portage/sys-libs/
> glibc-2.24-r4/temp/build.log'.
> >  * The ebuild environment file is located at '/var/tmp/portage/sys-libs/
> glibc-2.24-r4/temp/die.env'.
> >  * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir'
> >  * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24'
>  Running pre-merge checks for media-sound/pulseaudio-11.0
> >  * Determining the location of the kernel source code
> >  * Found kernel source directory:
> >  * /usr/src/linux
> >  * Found sources for kernel version:
> >  * 4.13.1-RT
> >  * Checking for suitable kernel configuration options...
> >  [ ok ]
> >  * A preallocated buffer-size of 2048 (kB) or higher is recommended for
> the HD-audio driver!
> >  * CONFIG_SND_HDA_PREALLOC_SIZE=64
> >
> > I would interpret this as:
>
> Looks to me like you are assuming the glibc maintainer has more
> knowledge of the future that he/she actually has.
>
> >
> > In the past emerge had updated glibc to a higher version as it want it
> > to install now and prevented the latter becayse it would be downgrade,
> > which in turn would render my box useless.
>
> No, not useless. It's a safety check for just in case. And now you must
> bypass the checks
>
> >
> > But why updateing to higher version in the first step
>
> Because you had a valid ebuild in the tree that said to do it ?
> >
> or attempting
> > to downgrade now?
>
> Because now you don't have that valid ebuild anymore?
>
>
> >
> > And finally...ANy update is blocked for now it seems...how can I get
> > out of this?
>
> Why is glibc wanting to downgrade? What is your current version?
>
> both of these versions are in the tree: (~)2.24-r4^s (~)2.25-r4^s
> so there is at least 1 glibc higher than what portage wants to downgrade
> to.
>
> You need to find out why 2.25-r4 is not being used. Usual tools, e.g.:
>
> grep -r glibc /etc/portage
> and any other methods you prefer
>
> As a last resort if the ebuld maintainer screwed up, you can bypass the
> safety check. Edit ${PORTDIR}/eclass/toolchain-glibc.eclass and comment
> out the check in
> toolchain-glibc_pkg_pretend()
>
> This is unlikely to destroy the system. Cause a problem - maybe. Destroy
> it? No. The wording of the safety check is hugely over-dramatic to
> discourage people from downgrading willy-nilly without thinking
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>

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

[Alan McKinnon]

On 12/09/2017 05:43, tu...@posteo.de wrote:
> Hi,
> 
> got a problem this morning:
> 
 Verifying ebuild manifests
 Running pre-merge checks for sys-libs/glibc-2.24-r4
>  * Sanity check to keep you from breaking your system:
>  *  Downgrading glibc is not supported and a sure way to destruction
>  * ERROR: sys-libs/glibc-2.24-r4::gentoo failed (pretend phase):
>  *   aborting to save your system
>  * 
>  * Call stack:
>  *ebuild.sh, line 115:  Called pkg_pretend
>  *ebuild.sh, line 348:  Called toolchain-glibc_pkg_pretend
>  *   toolchain-glibc.eclass, line 507:  Called die
>  * The specific snippet of code:
>  *die "aborting to save your system"
>  * 
>  * If you need support, post the output of `emerge --info 
> '=sys-libs/glibc-2.24-r4::gentoo'`,
>  * the complete build log and the output of `emerge -pqv 
> '=sys-libs/glibc-2.24-r4::gentoo'`.
>  * The complete build log is located at 
> '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/build.log'.
>  * The ebuild environment file is located at 
> '/var/tmp/portage/sys-libs/glibc-2.24-r4/temp/die.env'.
>  * Working directory: '/var/tmp/portage/sys-libs/glibc-2.24-r4/homedir'
>  * S: '/var/tmp/portage/sys-libs/glibc-2.24-r4/work/glibc-2.24'
 Running pre-merge checks for media-sound/pulseaudio-11.0
>  * Determining the location of the kernel source code
>  * Found kernel source directory:
>  * /usr/src/linux
>  * Found sources for kernel version:
>  * 4.13.1-RT
>  * Checking for suitable kernel configuration options...
>  [ ok ]
>  * A preallocated buffer-size of 2048 (kB) or higher is recommended for the 
> HD-audio driver!
>  * CONFIG_SND_HDA_PREALLOC_SIZE=64
> 
> I would interpret this as:

Looks to me like you are assuming the glibc maintainer has more
knowledge of the future that he/she actually has.

> 
> In the past emerge had updated glibc to a higher version as it want it
> to install now and prevented the latter becayse it would be downgrade,
> which in turn would render my box useless.

No, not useless. It's a safety check for just in case. And now you must
bypass the checks

> 
> But why updateing to higher version in the first step

Because you had a valid ebuild in the tree that said to do it ?
>
or attempting
> to downgrade now?

Because now you don't have that valid ebuild anymore?


> 
> And finally...ANy update is blocked for now it seems...how can I get
> out of this?

Why is glibc wanting to downgrade? What is your current version?

both of these versions are in the tree: (~)2.24-r4^s (~)2.25-r4^s
so there is at least 1 glibc higher than what portage wants to downgrade to.

You need to find out why 2.25-r4 is not being used. Usual tools, e.g.:

grep -r glibc /etc/portage
and any other methods you prefer

As a last resort if the ebuld maintainer screwed up, you can bypass the
safety check. Edit ${PORTDIR}/eclass/toolchain-glibc.eclass and comment
out the check in
toolchain-glibc_pkg_pretend()

This is unlikely to destroy the system. Cause a problem - maybe. Destroy
it? No. The wording of the safety check is hugely over-dramatic to
discourage people from downgrading willy-nilly without thinking

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