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.

[gentoo-user] Why are these files restricted?

[Ian Zimmerman]

$ for f in /etc/at/at.deny /etc/cron.hourly/0anacron
/etc/default/useradd ; do
  ls -l $f ; qfile $f ;
done
-rw-r- 1 root at 166 Dec 10 16:57 /etc/at/at.deny
sys-process/at (/etc/at/at.deny)
-rwxr-x--- 1 root root 392 Nov  4 21:04 /etc/cron.hourly/0anacron
sys-process/cronie (/etc/cron.hourly/0anacron)
-rw--- 1 root root 96 Aug 14 10:57 /etc/default/useradd
sys-apps/shadow (/etc/default/useradd)

None of these seem sensitive to me, and restricting them like this looks
like a case of SBO.  On a debian system at.deny has similarly restricted
perms; I can't check 0anacron because my debian system has no such
package installed; and default/useradd has normal 644 mode.

-- 
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, fetch the TXT record for the domain.

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

[Ian Zimmerman]

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?

-- 
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, fetch the TXT record for the domain.

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

[R0b0t1]

Against my better judgement,

On Sun, Dec 10, 2017 at 9:31 PM, Canek Peláez Valdés  wrote:
> Up to a point, the same can be said about systemd; although many of its
> programs can be and are used by end users, most of it is for distro
> builders, programmers and administrators. And having a couple of Gentoo
> boxes running Apache doesn't make anyone an administrator, BTW.
>

I have met Gentoo users who maintain, for fun, far more complex and
capable systems than some system administrators who are paid for their
work. There is no reason you are any more credible than a random
mailing list user.

> That's why most of Gentoo systemd users (and we are *a lot*; Gentoo has
> great systemd support with several Gentoo devs collaborating with the
> project) usually just ignore this kind of threads. Most of the time is a lot
> of people which don't use it badmouthing a really cool piece of technology
> that has been adopted by all large (and heavily used) Linux distributions
> because the people that understand its technical merits realize that, for
> the *general case*, its benefits outweigh whatever costs (in many cases
> imaginary) it may have. And besides, for us it just works™, quietly running
> in the background.
>

If you are saying this then you are choosing to ignore the technical
arguments against systemd. You can claim you don't care and that is
fine, but you've ignored what people are talking about and have
injected your opinion into the discussion with a false air of
superiority.

The complaints in this thread may be a little extreme, but ultimately
I agree these closely connected binary systems are not easily
maintainable and are opaque to users.

Cheers,
 R0b0t1

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

[Rich Freeman]

On Sun, Dec 10, 2017 at 4:00 PM, Wols Lists  wrote:
>
> So the OP needs to be aware that, if his file is smaller than  the chunk
> size, then it *will* be recoverable from a disk pulled from an array, be
> it md-raid or zfs.
>
> The question is, then, how big is a chunk? And if zfs is anything like
> md-raid, it will be a lot bigger than the 512B or 4KB that a naive user
> would think.
>

I suspect the data is striped/chunked/etc at a larger scale.

However, I'd really go a step further.  Unless a filesystem or block
layer is explicitly designed to prevent the retrieval of data without
a key/etc, then I would not rely on something like this for security.
Even actual encryption systems can have bugs that render them
vulnerable.  Something that at best provides this kind of security "by
accident" is not something you should rely on.  Data might be stored
in journals, or metadata, or unwiped free space, or in any number of
ways that makes it possible to retrieve even if it isn't obvious from
casual inspection.

If you don't want somebody recovering data from a drive you're
disposing of, then you should probably be encrypting that drive one
way or another with a robust encryption layer.  That might be built
into the filesystem, or it might be a block layer.  If you're
desperate I guess you could use the SMART security features provided
by your drive firmware, which probably work, but which nobody can
really vouch for but the drive manufacturer.  Any of these are going
to provide more security that relying on RAID striping to make data
irretrievable.

If you really care about security, then you're going to be paranoid
about the tools that actually are designed to be secure, let alone the
ones that aren't.

-- 
Rich

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

[Canek Peláez Valdés]

On Sun, Dec 10, 2017 at 3:55 PM, Jorge Almeida  wrote:
[...]
> Yes, it seems appropriate for Windows refugees and linuxers suffering
> from Apple-envy. When I said I didn't understand why it would be
> useful, I meant that the documentation in the site is all but clear
> about the goodness of its product. Lots of freedesktop/dbus
> mumbo-jumbo, though.

The documentation for udisks is not intended for end-users; it's intended
for developers that whish to use its benefits for their projects, GNOME and
KDE included. When used right (which implies a good integration done by the
distro), the software depending on it just works™, which makes
documentation for the end user program also redundant. 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. For the
*general case*, its benefits outweigh the almost negligible amount of
resources it consumes (BTW, build time of udisks in Gentoo is about 21
seconds).

Up to a point, the same can be said about systemd; although many of its
programs can be and are used by end users, most of it is for distro
builders, programmers and administrators. And having a couple of Gentoo
boxes running Apache doesn't make anyone an administrator, BTW.

That's why most of Gentoo systemd users (and we are *a lot*; Gentoo has
great systemd support with several Gentoo devs collaborating with the
project) usually just ignore this kind of threads. Most of the time is a
lot of people which don't use it badmouthing a really cool piece of
technology that has been adopted by all large (and heavily used) Linux
distributions because the people that understand its technical merits
realize that, for the *general case*, its benefits outweigh whatever costs
(in many cases imaginary) it may have. And besides, for us it just works™,
quietly running in the background.

Just my two cents. I will not answer any reply to my little contribution to
this thread; but of course don't hesitate to explain to me why I'm
completely wrong, or a Lennart fanboi, or that I don't know what I'm
talking about. I just will not partake in such a joyful and enlightening
"discussion" (sadly the same conclusion I have arrived for the lasts few
years regarding this mailing list).

Enjoy your echo chamber.

Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[gentoo-user] PerlEmbed?

[tuxic]

Hi,

I am trying to compile the github clone of the Prusa Edition
of Slic3r.

It complains of not finding "PerlEmbed"...

I asked eix but it does not find anything directly.

Is this part of a package with a totally different name?

Thanks a lot for any help in advancee!
:)

Cheers
Meino

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

[Jorge Almeida]

On Sun, Dec 10, 2017 at 6:12 AM, R0b0t1  wrote:
> On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey  wrote:
>> On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
>>> On Sat, Dec 9, 2017 at 10:45 AM, Mick  wrote:
>>> > Thank you all for detailed and clear replies.  You'd forgive me for
>>> > being (a little) paranoid about Poettering's fingers getting anywhere
>>> > near my systems.>
>>> > :-p
>>>
>>> Are you sure you need udisks? And policykit?
>>
>> I'm pretty sure Mick runs KDE, which requires both of those.
>>
>
> Eventually emerging @world will just pull in the entirety of the
> Gentoo package repository, and we won't have to worry about what is or
> isn't necessary.
>
Not that I would object much to have gnome-common if I needed it (I
don't), but it is a bit
shocking that installing kde stuff pulls gnome stuff. After all,
they're supposed to be alternative worldviews, er, desktop
environments. Maybe the relevant people should stop and think whether
unbridled complexity is a good idea?

(Of course, this is not a Gentoo-specific issue.)

Jorge

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

[Wols Lists]

On 09/12/17 23:36, Rich Freeman wrote:
> you instead compute 5 sets of parity so that now you have 9 sets of
> data that can tolerate the loss of any 5, then throw away the sets
> containing the original 4 sets of data and store the remaining 5 sets
> of parity data across the 5 drives.  You can still tolerate the loss
> of one more set, but all 4 of the original sets of data have been
> tossed already.

Is that how ZFS works?

Cheers,
Wol

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

[Wols Lists]

On 09/12/17 12:08, Alan McKinnon wrote:
> I'm all in favour of Lennart-bashing, but let's keep the bashing to what
> he's responsible for.



As far as I can tell, the most egregious thing he's responsible for is
for wanting a well-designed system that works!

Face it, linux is a hodge-podge of things thrown together, and held
together with baling wire and sealing wax. Lennart doesn't want a system
where a small failure in one place cascades and brings down a load of
stuff elsewhere.

Granted he's not necessarily the most politic of people, and has ruffled
a lot of feathers, but I'd much rather a system he's cleaned up, than a
system where everything hangs together on a knife-edge.

Cheers,
Wol

[gentoo-user] Re: Pentium 4, 32bit fails to update media-gfx/uniconvertor-2.0_pre379-r1

[Nikos Chantziaras]

On 10/12/17 10:51, Mick wrote:

Any idea were that "MagickWand" went hiding?
[...]

Should I file a bug, or am I missing some other package?


This was fixed in 2.0_pre379-r2, so you should temporarily keyword that 
version until it goes stable.

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

[Alan McKinnon]

On 10/12/2017 13:55, Mart Raudsepp wrote:
> On P, 2017-12-10 at 08:56 +, Jorge Almeida wrote:
>> On Sun, Dec 10, 2017 at 6:12 AM, R0b0t1  wrote:
>>> On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey >> uk> wrote:
 On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
> On Sat, Dec 9, 2017 at 10:45 AM, Mick  m> wrote:
>> Thank you all for detailed and clear replies.  You'd forgive
>> me for
>> being (a little) paranoid about Poettering's fingers getting
>> anywhere
>> near my systems.>
>> :-p
>
> Are you sure you need udisks? And policykit?

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

>>>
>>> Eventually emerging @world will just pull in the entirety of the
>>> Gentoo package repository, and we won't have to worry about what is
>>> or
>>> isn't necessary.
>>>
>> Not that I would object much to have gnome-common if I needed it (I
>> don't), but it is a bit
>> shocking that installing kde stuff pulls gnome stuff. After all,
>> they're supposed to be alternative worldviews, er, desktop
>> environments. Maybe the relevant people should stop and think whether
>> unbridled complexity is a good idea?
> 
> So you are suggesting that each desktop environment must NIH
> everything?
> 
> Want an auto-mounter and disk monitor and more for a modern desktop
> experience - reimplement udisks.
> Want a secure permissions handling framework for the desktop -
> reimplement polkit.
> Want a user account service handler for desktop logins - reimplement
> accountsservice.
> Want color profiles handling for monitors and co, and other associated
> stuff - reimplement colord.
> And so on.
> 
> That's all "GNOME stuff" by your definition, with GNOME Foundation
> members being the project leaders or starters.
> 
> Meanwhile gnome-common is just a package for m4 macros for the older
> autotools using world, and is deprecated in favor of autoconf-archive,
> which had the good things of gnome-common integrated into it. Please
> remove that package too, if you want to NIH.
> 
> 
> People, this is open source. Stop advocating NIH and make use of the
> benefits of open source and let the people actually doing stuff
> collaborate on things and re-use/share projects as they see fit, for
> less time waste and more making GNU/Linux (desktops) great over the
> proprietary others.
> 
> 

Let's say we renamed the package:

s/gnome-common/useful-build-stuffs/g

No other change, just a package rename. And suddenly this entire thread
never ever happens at all.

People, you all need to step back, sleep on it, and knock off the
knee-jerking. It is 4 useful m4 files, utterly dwarfed by any package
you can mention that installs even a single man page.

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

[gentoo-user] Pentium 4, 32bit fails to update media-gfx/uniconvertor-2.0_pre379-r1

[Mick]

Any idea were that "MagickWand" went hiding?

i686-pc-linux-gnu-gcc -march=prescott -O2 -pipe -fomit-frame-pointer -fPIC -
DMAJOR_VERSION=1 -DMINOR_VERSION=0 -I/usr/include/python2.7 -c src/uc2/
formats/sk1/sk1objs/curvemisc.c -o /var/tmp
/portage/media-gfx/uniconvertor-2.0_pre379-r1/work/uniconvertor-2.0_pre379-
python2_7/temp.linux-i686-2.7/src/uc2/formats/sk1/sk1objs/curvemisc.o   
   
In file included from /usr/include/python2.7/Python.h:8:0,  

  
 from src/uc2/formats/sk1/sk1objs/skpoint.h:26, 

  
 from src/uc2/formats/sk1/sk1objs/sktrafo.h:27, 

  
 from src/uc2/formats/sk1/sk1objs/curvemisc.c:21:   

  
/usr/include/python2.7/pyconfig.h:1193:0: warning: "_POSIX_C_SOURCE" redefined  

  
 #define _POSIX_C_SOURCE 200112L

  


  
In file included from /usr/include/bits/libc-header-start.h:33:0,   

  
 from /usr/include/math.h:27,   

  
 from src/uc2/formats/sk1/sk1objs/curvemisc.c:19:   

  
/usr/include/features.h:257:0: note: this is the location of the previous 
definition  

 # define _POSIX_C_SOURCE 200809L   

  


  
i686-pc-linux-gnu-gcc -march=prescott -O2 -pipe -fomit-frame-pointer -fPIC -
DMAJOR_VERSION=1 -DMINOR_VERSION=0 -I/usr/include/python2.7 -c src/uc2/
formats/sk1/sk1objs/skaux.c -o /var/tmp/po$
tage/media-gfx/uniconvertor-2.0_pre379-r1/work/uniconvertor-2.0_pre379-
python2_7/temp.linux-i686-2.7/src/uc2/formats/sk1/sk1objs/skaux.o   
   
In file included from /usr/include/python2.7/Python.h:8:0,  

  
 from src/uc2/formats/sk1/sk1objs/skaux.c:21:   

  
/usr/include/python2.7/pyconfig.h:1193:0: warning: "_POSIX_C_SOURCE" redefined  

  
 #define _POSIX_C_SOURCE 200112L

  


  
In file included from /usr/include/bits/libc-header-start.h:33:0,   

  
 from /usr/include/math.h:27,   

  
 from src/uc2/formats/sk1/sk1objs/skaux.c:19:   

  
/usr/include/features.h:257:0: note: this is the location of the previous 
definition   

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

[karl]

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

No, we don't have to, this is gentoo after all. You can still use a
static dev if you wish even if some packages do insists on udev even
though some of thoose dependancies are bogus.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57

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

[Kent Fredric]

On Sun, 10 Dec 2017 02:17:09 -0500
John Covici  wrote:

> OK, thanks, I think I will try that.

The problem you're facing is that you masked dev-lang/perl, but not any
virtual/perl-* or perl-core/-* to compensate.

These 3 components work in concert like a single component, as a sort
of bodge to compensate for the fact portage has no working "provides" feature,
and to compensate for the dependency-system missmatch between how
Gentoo works and how CPAN works.

Theres' no easy way of fixing this atm, but the short of it is if you're using
an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
and if you're using an "arch" dev-lang/perl, you should be using only
"arch" versions of virtual/perl-*

Once you do this, portage may still scream at you, because portage is
very much optimised for upgrading, and it tends to think downgrading is
an error.

So once you get all your masks/keyword changes in place, you should do:

  emerge -C virtual/perl-*
  emerge -C perl-core/*

(or something to that effect)

This looks scary, but generally isn't, because you're not actually removing
anything with this, just juggling a few balls and making only older
versions of certain things available ( as they're alls shipped in
dev-lang/perl )

And then after you do this, portage is more likely to be persuadable
into doing the right thing.

You can additionally abuse my tool, gentoo-perl-helpers for doing some of this,
and some of the steps I've described are automated because they're just
that safe and useful.

https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers


After putting the right masks in place, do:

gentoo-perl gen-upgrade-sets 5.26 5.24

And if you're really lucky, the sets it generates will work the first time :)

( I actually tested this scenario when developing it, but its still an
undocumented use on purpose )

GLHF.


pgp7qA19Q_4VT.pgp
Description: OpenPGP digital signature

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

[Mart Raudsepp]

On P, 2017-12-10 at 08:56 +, Jorge Almeida wrote:
> On Sun, Dec 10, 2017 at 6:12 AM, R0b0t1  wrote:
> > On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey  > uk> wrote:
> > > On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:
> > > > On Sat, Dec 9, 2017 at 10:45 AM, Mick  > > > m> wrote:
> > > > > Thank you all for detailed and clear replies.  You'd forgive
> > > > > me for
> > > > > being (a little) paranoid about Poettering's fingers getting
> > > > > anywhere
> > > > > near my systems.>
> > > > > :-p
> > > > 
> > > > Are you sure you need udisks? And policykit?
> > > 
> > > I'm pretty sure Mick runs KDE, which requires both of those.
> > > 
> > 
> > Eventually emerging @world will just pull in the entirety of the
> > Gentoo package repository, and we won't have to worry about what is
> > or
> > isn't necessary.
> > 
> Not that I would object much to have gnome-common if I needed it (I
> don't), but it is a bit
> shocking that installing kde stuff pulls gnome stuff. After all,
> they're supposed to be alternative worldviews, er, desktop
> environments. Maybe the relevant people should stop and think whether
> unbridled complexity is a good idea?

So you are suggesting that each desktop environment must NIH
everything?

Want an auto-mounter and disk monitor and more for a modern desktop
experience - reimplement udisks.
Want a secure permissions handling framework for the desktop -
reimplement polkit.
Want a user account service handler for desktop logins - reimplement
accountsservice.
Want color profiles handling for monitors and co, and other associated
stuff - reimplement colord.
And so on.

That's all "GNOME stuff" by your definition, with GNOME Foundation
members being the project leaders or starters.

Meanwhile gnome-common is just a package for m4 macros for the older
autotools using world, and is deprecated in favor of autoconf-archive,
which had the good things of gnome-common integrated into it. Please
remove that package too, if you want to NIH.


People, this is open source. Stop advocating NIH and make use of the
benefits of open source and let the people actually doing stuff
collaborate on things and re-use/share projects as they see fit, for
less time waste and more making GNU/Linux (desktops) great over the
proprietary others.

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

[Mick]

On Sunday, 10 December 2017 06:12:07 GMT R0b0t1 wrote:
> On Sat, Dec 9, 2017 at 5:36 PM, Peter Humphrey  
wrote:
> > On Saturday, 9 December 2017 12:00:12 GMT Jorge Almeida wrote:

> >> Are you sure you need udisks? And policykit?
> > 
> > I'm pretty sure Mick runs KDE, which requires both of those.
> 
> Eventually emerging @world will just pull in the entirety of the
> Gentoo package repository, and we won't have to worry about what is or
> isn't necessary.

Yes, I run the plasma profile.  Also I understand the udisks package is 
necessary to allow mounting disks by clicking on the GUI.

-- 
Regards,
Mick

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

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

[Alan Mackenzie]

Hello, Wols

On Sun, Dec 10, 2017 at 09:55:45 +, Wols Lists wrote:
> On 09/12/17 12:08, Alan McKinnon wrote:
> > I'm all in favour of Lennart-bashing, but let's keep the bashing to what
> > he's responsible for.

> 



> As far as I can tell, the most egregious thing he's responsible for is
> for wanting a well-designed system that works!

No, he's done far worse than that.

> Face it, linux is a hodge-podge of things thrown together, and held
> together with baling wire and sealing wax.

It's a hodge-podge, yes, but held together with robust protocols.

> Lennart doesn't want a system where a small failure in one place
> cascades and brings down a load of stuff elsewhere.

Neither do I, and neither does anybody.  GNU/Linux is not like that, and
never has been.  It has traditionally been a massive pain to set up,
though, something which has improved dramatically over the last ten or
twenty years.

> Granted he's not necessarily the most politic of people, and has ruffled
> a lot of feathers, but I'd much rather a system he's cleaned up, than a
> system where everything hangs together on a knife-edge.

His motivation seems to be ego.  To force everybody to use his software.
He did this by, amongst other things, abusing the trust placed in him to
maintain udev.  Early on he abandoned support for udev for everybody but
users of his new init system, systemd, in an attempt (sadly successful)
to force "everybody" into using systemd.

I've no idea how good systemd is.  It's not been through the normal
process of choice and selection that other successful packages have.  It
was forced on people.  But being forced to have a binary system log,
being forced (so I have heard) to have an http server running, ,
doesn't make it an attractive package for me.

> Cheers,
> Wol

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Jorge Almeida]

On Sun, Dec 10, 2017 at 9:55 AM, Wols Lists  wrote:
> On 09/12/17 12:08, Alan McKinnon wrote:
>> I'm all in favour of Lennart-bashing, but let's keep the bashing to what
>> he's responsible for.
>
> 
>
> As far as I can tell, the most egregious thing he's responsible for is
> for wanting a well-designed system that works!
>
> Face it, linux is a hodge-podge of things thrown together, and held
> together with baling wire and sealing wax. Lennart doesn't want a system
> where a small failure in one place cascades and brings down a load of
> stuff elsewhere.
>

And, of course, a system of his doing will not have a single point of
failure. At all, at all. And it is well-designed, to boot.

Why not get rid of all the bazaar stuff altogether? They could just
fork linux. Minus the name, of course. I could suggest a name, but
won't. But maybe it is more appealing to grab something that is
already there? Not to mention that it is way more friendly to the
interests of a certain corporation.
Regards

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

[John Covici]

On Sun, 10 Dec 2017 07:36:19 -0500,
Kent Fredric wrote:
> 
> [1  ]
> On Sun, 10 Dec 2017 02:17:09 -0500
> John Covici  wrote:
> 
> > OK, thanks, I think I will try that.
> 
> The problem you're facing is that you masked dev-lang/perl, but not any
> virtual/perl-* or perl-core/-* to compensate.
> 
> These 3 components work in concert like a single component, as a sort
> of bodge to compensate for the fact portage has no working "provides" feature,
> and to compensate for the dependency-system missmatch between how
> Gentoo works and how CPAN works.
> 
> Theres' no easy way of fixing this atm, but the short of it is if you're using
> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> and if you're using an "arch" dev-lang/perl, you should be using only
> "arch" versions of virtual/perl-*
> 
> Once you do this, portage may still scream at you, because portage is
> very much optimised for upgrading, and it tends to think downgrading is
> an error.
> 
> So once you get all your masks/keyword changes in place, you should do:
> 
>   emerge -C virtual/perl-*
>   emerge -C perl-core/*
> 
> (or something to that effect)
> 
> This looks scary, but generally isn't, because you're not actually removing
> anything with this, just juggling a few balls and making only older
> versions of certain things available ( as they're alls shipped in
> dev-lang/perl )
> 
> And then after you do this, portage is more likely to be persuadable
> into doing the right thing.
> 
> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> this,
> and some of the steps I've described are automated because they're just
> that safe and useful.
> 
> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> 
> 
> After putting the right masks in place, do:
> 
>   gentoo-perl gen-upgrade-sets 5.26 5.24
> 
> And if you're really lucky, the sets it generates will work the first time :)
> 
> ( I actually tested this scenario when developing it, but its still an
> undocumented use on purpose )
> 
> GLHF.

I went ahead and did the upgrade which worked, but the emerge from
perl-cleaner --all did not.  I am using ~amd64 and have done so for
years, so I don't think I need to maks off anything.  I seem now to be
stuck with dev-python/setuptools, so I am now trying to figure out why
I can't emerge that -- it was triggered by the perl-cleaner --all .

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

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

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

[Alan McKinnon]

On 10/12/2017 14:54, John Covici wrote:
> On Sun, 10 Dec 2017 07:36:19 -0500,
> Kent Fredric wrote:
>>
>> [1  ]
>> On Sun, 10 Dec 2017 02:17:09 -0500
>> John Covici  wrote:
>>
>>> OK, thanks, I think I will try that.
>>
>> The problem you're facing is that you masked dev-lang/perl, but not any
>> virtual/perl-* or perl-core/-* to compensate.
>>
>> These 3 components work in concert like a single component, as a sort
>> of bodge to compensate for the fact portage has no working "provides" 
>> feature,
>> and to compensate for the dependency-system missmatch between how
>> Gentoo works and how CPAN works.
>>
>> Theres' no easy way of fixing this atm, but the short of it is if you're 
>> using
>> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
>> and if you're using an "arch" dev-lang/perl, you should be using only
>> "arch" versions of virtual/perl-*
>>
>> Once you do this, portage may still scream at you, because portage is
>> very much optimised for upgrading, and it tends to think downgrading is
>> an error.
>>
>> So once you get all your masks/keyword changes in place, you should do:
>>
>>   emerge -C virtual/perl-*
>>   emerge -C perl-core/*
>>
>> (or something to that effect)
>>
>> This looks scary, but generally isn't, because you're not actually removing
>> anything with this, just juggling a few balls and making only older
>> versions of certain things available ( as they're alls shipped in
>> dev-lang/perl )
>>
>> And then after you do this, portage is more likely to be persuadable
>> into doing the right thing.
>>
>> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
>> this,
>> and some of the steps I've described are automated because they're just
>> that safe and useful.
>>
>> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
>>
>>
>> After putting the right masks in place, do:
>>
>>  gentoo-perl gen-upgrade-sets 5.26 5.24
>>
>> And if you're really lucky, the sets it generates will work the first time :)
>>
>> ( I actually tested this scenario when developing it, but its still an
>> undocumented use on purpose )
>>
>> GLHF.
> 
> I went ahead and did the upgrade which worked, but the emerge from
> perl-cleaner --all did not.  I am using ~amd64 and have done so for
> years, so I don't think I need to maks off anything.  I seem now to be
> stuck with dev-python/setuptools, so I am now trying to figure out why
> I can't emerge that -- it was triggered by the perl-cleaner --all .
> 

How recent is your tree?

I had issues with setuptools doing the first run through the 17.0
upgrade. I never looked into it too closely, I used --keep-going, but
setuptools seemed to think I had a useable python-3.4

After the first run through emerge -e world, nuking-python-3.4 and
re-syncing, setuptols worked normally again.

YMMV of course where you are
-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[Kent Fredric]

On Sun, 10 Dec 2017 07:54:59 -0500
John Covici  wrote:

> I am using ~amd64 and have done so for
> years, so I don't think I need to maks off anything. 

Sorry, I may have gotten my wires crossed.

The impression I got was you were trying to stick with perl 5.24

The point is *if* you're sticking with perl 5.24 ( which is current
stable ) then by design, you need the set of virtuals that specify perl
5.24.

If you try to use "~amd64" virtuals with an "amd64" perl, portage will
try to install the newest versions of those virtuals, which in turn
force installing perl 5.26

Hence, you need to use a paired combination of dev-lang/perl and
virtuals.

Just the mechanism by which we make this pairing happens is via
stability levels.

Hence, if you wanted to use Perl 5.24, you would need to do more than
merely mask perl 5.26, you would need to mask the virtuals that tell
portage to install perl 5.26 as well.



pgplYBN3na4dI.pgp
Description: OpenPGP digital signature

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

[John Covici]

On Sun, 10 Dec 2017 08:13:09 -0500,
Alan McKinnon wrote:
> 
> On 10/12/2017 14:54, John Covici wrote:
> > On Sun, 10 Dec 2017 07:36:19 -0500,
> > Kent Fredric wrote:
> >>
> >> [1  ]
> >> On Sun, 10 Dec 2017 02:17:09 -0500
> >> John Covici  wrote:
> >>
> >>> OK, thanks, I think I will try that.
> >>
> >> The problem you're facing is that you masked dev-lang/perl, but not any
> >> virtual/perl-* or perl-core/-* to compensate.
> >>
> >> These 3 components work in concert like a single component, as a sort
> >> of bodge to compensate for the fact portage has no working "provides" 
> >> feature,
> >> and to compensate for the dependency-system missmatch between how
> >> Gentoo works and how CPAN works.
> >>
> >> Theres' no easy way of fixing this atm, but the short of it is if you're 
> >> using
> >> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> >> and if you're using an "arch" dev-lang/perl, you should be using only
> >> "arch" versions of virtual/perl-*
> >>
> >> Once you do this, portage may still scream at you, because portage is
> >> very much optimised for upgrading, and it tends to think downgrading is
> >> an error.
> >>
> >> So once you get all your masks/keyword changes in place, you should do:
> >>
> >>   emerge -C virtual/perl-*
> >>   emerge -C perl-core/*
> >>
> >> (or something to that effect)
> >>
> >> This looks scary, but generally isn't, because you're not actually removing
> >> anything with this, just juggling a few balls and making only older
> >> versions of certain things available ( as they're alls shipped in
> >> dev-lang/perl )
> >>
> >> And then after you do this, portage is more likely to be persuadable
> >> into doing the right thing.
> >>
> >> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> >> this,
> >> and some of the steps I've described are automated because they're just
> >> that safe and useful.
> >>
> >> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> >>
> >>
> >> After putting the right masks in place, do:
> >>
> >>gentoo-perl gen-upgrade-sets 5.26 5.24
> >>
> >> And if you're really lucky, the sets it generates will work the first time 
> >> :)
> >>
> >> ( I actually tested this scenario when developing it, but its still an
> >> undocumented use on purpose )
> >>
> >> GLHF.
> > 
> > I went ahead and did the upgrade which worked, but the emerge from
> > perl-cleaner --all did not.  I am using ~amd64 and have done so for
> > years, so I don't think I need to maks off anything.  I seem now to be
> > stuck with dev-python/setuptools, so I am now trying to figure out why
> > I can't emerge that -- it was triggered by the perl-cleaner --all .
> > 
> 
> How recent is your tree?
> 
> I had issues with setuptools doing the first run through the 17.0
> upgrade. I never looked into it too closely, I used --keep-going, but
> setuptools seemed to think I had a useable python-3.4
> 
> After the first run through emerge -e world, nuking-python-3.4 and
> re-syncing, setuptols worked normally again.
> 
> YMMV of course where you are

My tree maybe 30 days old or thereabouts.  I could not run  the emerge
from perl-cleaner because of setup-tools problems.  I will see what
happens if I run a regular update, but I hate to do that if I am going
to do an -e world.

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

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

Re: [gentoo-user] Re: Pentium 4, 32bit fails to update media-gfx/uniconvertor-2.0_pre379-r1

[Mick]

On Sunday, 10 December 2017 10:11:41 GMT Nikos Chantziaras wrote:
> On 10/12/17 10:51, Mick wrote:
> > Any idea were that "MagickWand" went hiding?
> > [...]
> > 
> > Should I file a bug, or am I missing some other package?
> 
> This was fixed in 2.0_pre379-r2, so you should temporarily keyword that
> version until it goes stable.

Thanks for this suggestion Nikos, uniconvertor-2.0_pre379-r2 emerged 
successfully.
-- 
Regards,
Mick

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

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

[Rich Freeman]

On Sun, Dec 10, 2017 at 4:45 AM, Wols Lists  wrote:
> On 09/12/17 23:36, Rich Freeman wrote:
>> you instead compute 5 sets of parity so that now you have 9 sets of
>> data that can tolerate the loss of any 5, then throw away the sets
>> containing the original 4 sets of data and store the remaining 5 sets
>> of parity data across the 5 drives.  You can still tolerate the loss
>> of one more set, but all 4 of the original sets of data have been
>> tossed already.
>
> Is that how ZFS works?
>

I doubt it, hence why I wrote "most parity RAID systems seem to
operate just as you describe."

-- 
Rich

Re: [gentoo-user] emerge -e @world failed

[Andrew Savchenko]

On Tue, 5 Dec 2017 01:08:12 +0100 tu...@posteo.de wrote:
> HHi,
> 
> I did it,
> 
> I started emerge -e @world --keep-going.
> 
> And it failed while installing linux-gazette:
> >>> Emerging (370 of 2114) app-doc/linux-gazette-117::gentoo
> >>> Installing (360 of 2114) app-doc/linux-gazette-31::gentoo
> >>> Emerging (371 of 2114) app-doc/linux-gazette-69::gentoo
> >>> Installing (361 of 2114) app-doc/linux-gazette-74::gentoo
> >>> Jobs: 341 of 2114 complete, 5 running   Load avg: 1.48, 1.61, 1.82
> Traceback (most recent call last):
>   File "/usr/lib64/python3.5/site-packages/portage/dbapi/vartree.py", line 
> 740, in aux_get
> mydir_stat = os.stat(mydir)
>   File "/usr/lib64/python3.5/site-packages/portage/__init__.py", line 250, in 
> __call__
> rval = self._func(*wrapped_args, **wrapped_kwargs)
> FileNotFoundError: [Errno 2] No such file or directory: 
> b'/var/db/pkg/app-doc/linux-gazette-74'

Apparently your /var/db/pkg database is broken. What bothers me
here is that you have two likely parallel installs here. Maybe you
just hit a race condition bug.

Try to emerge required linux-gazette slots manually, one by one. If
this helps, report the bug on portage to bugzilla.

Best regards,
Andrew Savchenko


pgpjTVN5boSFh.pgp
Description: PGP signature

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

[Wols Lists]

On 10/12/17 15:07, Rich Freeman wrote:
>> > Is that how ZFS works?
>> >
> I doubt it, hence why I wrote "most parity RAID systems seem to
> operate just as you describe."

So the OP needs to be aware that, if his file is smaller than  the chunk
size, then it *will* be recoverable from a disk pulled from an array, be
it md-raid or zfs.

The question is, then, how big is a chunk? And if zfs is anything like
md-raid, it will be a lot bigger than the 512B or 4KB that a naive user
would think.

Cheers,
Wol

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

[Ian Zimmerman]

On 2017-12-09 12:00, Jorge Almeida wrote:

> Are you sure you need udisks? And policykit? I'm guessing you have
> some default USE variables which if removed would contribute to a
> cleaner system. I just checked the documentation about udisks in the
> freedesktop site. I didn't manage to understand why it would be useful
> (my fault, probably) but I understood enough to decide I wouldn't want
> such stuff in my system.

AFAIK there are 2 main reasons for udisks:

1. automounting everything that moves, and even things that do not move.
   By automounting I mean fully automatic mounting, ie. without any
   click or other user action.  Leaving aside the desirability of this,
   it can be mostly replaced by a set of udev rules, even though udev
   authors frown of such usage.

2. tracking media availability of optical drives, which maddeningly do
   not provide any interrupt-driven way to do that.  In spite of my
   advancing age I can still remember when I insert a disc into my
   drive, so if I don't need 1. above I don't need this either.

Ergo, I avoid udisks.

-- 
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, fetch the TXT record for the domain.

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

[Nikos Chantziaras]

On 10/12/17 11:55, Wols Lists wrote:

On 09/12/17 12:08, Alan McKinnon wrote:

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




As far as I can tell, the most egregious thing he's responsible for is
for wanting a well-designed system that works!

Face it, linux is a hodge-podge of things thrown together, and held
together with baling wire and sealing wax. Lennart doesn't want a system
where a small failure in one place cascades and brings down a load of
stuff elsewhere.

Granted he's not necessarily the most politic of people, and has ruffled
a lot of feathers, but I'd much rather a system he's cleaned up, than a
system where everything hangs together on a knife-edge.


I feel like I'm the only one who doesn't care :-P

This is me:

"Seems like KDE and Gnome prefer/recommend or require systemd. OK. 
Install that instead. I don't actually care what it does or how it works."

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

[Wols Lists]

On 10/12/17 10:13, Alan Mackenzie wrote:
> I've no idea how good systemd is.  It's not been through the normal
> process of choice and selection that other successful packages have.  It
> was forced on people.  But being forced to have a binary system log,
> being forced (so I have heard) to have an http server running, ,
> doesn't make it an attractive package for me.

Oddly enough, although the details are different, that passage I've
quoted pretty accurately describes how I feel about Gnome ... :-)

Cheers,
Wol

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

[John Covici]

On Sun, 10 Dec 2017 07:36:19 -0500,
Kent Fredric wrote:
> 
> [1  ]
> On Sun, 10 Dec 2017 02:17:09 -0500
> John Covici  wrote:
> 
> > OK, thanks, I think I will try that.
> 
> The problem you're facing is that you masked dev-lang/perl, but not any
> virtual/perl-* or perl-core/-* to compensate.
> 
> These 3 components work in concert like a single component, as a sort
> of bodge to compensate for the fact portage has no working "provides" feature,
> and to compensate for the dependency-system missmatch between how
> Gentoo works and how CPAN works.
> 
> Theres' no easy way of fixing this atm, but the short of it is if you're using
> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> and if you're using an "arch" dev-lang/perl, you should be using only
> "arch" versions of virtual/perl-*
> 
> Once you do this, portage may still scream at you, because portage is
> very much optimised for upgrading, and it tends to think downgrading is
> an error.
> 
> So once you get all your masks/keyword changes in place, you should do:
> 
>   emerge -C virtual/perl-*
>   emerge -C perl-core/*
> 
> (or something to that effect)
> 
> This looks scary, but generally isn't, because you're not actually removing
> anything with this, just juggling a few balls and making only older
> versions of certain things available ( as they're alls shipped in
> dev-lang/perl )
> 
> And then after you do this, portage is more likely to be persuadable
> into doing the right thing.
> 
> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> this,
> and some of the steps I've described are automated because they're just
> that safe and useful.
> 
> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> 
> 
> After putting the right masks in place, do:
> 
>   gentoo-perl gen-upgrade-sets 5.26 5.24
> 
> And if you're really lucky, the sets it generates will work the first time :)
> 
> ( I actually tested this scenario when developing it, but its still an
> undocumented use on purpose )

OK, so I am doing the usual update of world and portage figured out
about hundreds of perl modules and even  thepython setuptools, so I
will do that and then think about doing the -e world, but I may wait
awhile on that -- this one will take at least 48 hours.

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

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

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

[Jorge Almeida]

On Sun, Dec 10, 2017 at 1:01 PM, Ian Zimmerman  wrote:
> On 2017-12-09 12:00, Jorge Almeida wrote:
>
>> Are you sure you need udisks? And policykit? I'm guessing you have
>> some default USE variables which if removed would contribute to a
>> cleaner system. I just checked the documentation about udisks in the
>> freedesktop site. I didn't manage to understand why it would be useful
>> (my fault, probably) but I understood enough to decide I wouldn't want
>> such stuff in my system.
>
> AFAIK there are 2 main reasons for udisks:
>
> 1. automounting everything that moves, and even things that do not move.
>By automounting I mean fully automatic mounting, ie. without any
>click or other user action.  Leaving aside the desirability of this,
>it can be mostly replaced by a set of udev rules, even though udev
>authors frown of such usage.
>
> 2. tracking media availability of optical drives, which maddeningly do
>not provide any interrupt-driven way to do that.  In spite of my
>advancing age I can still remember when I insert a disc into my
>drive, so if I don't need 1. above I don't need this either.
>
> Ergo, I avoid udisks.
>
Yes, it seems appropriate for Windows refugees and linuxers suffering
from Apple-envy. When I said I didn't understand why it would be
useful, I meant that the documentation in the site is all but clear
about the goodness of its product. Lots of freedesktop/dbus
mumbo-jumbo, though.

Regards

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

[Walter Dnes]

On Sun, Dec 10, 2017 at 09:02:24PM +, Wols Lists wrote
> On 10/12/17 10:13, Alan Mackenzie wrote:
> > I've no idea how good systemd is.  It's not been through the normal
> > process of choice and selection that other successful packages have.
> > It was forced on people.  But being forced to have a binary system log,
> > being forced (so I have heard) to have an http server running, ,
> > doesn't make it an attractive package for me.
> 
> Oddly enough, although the details are different, that passage I've
> quoted pretty accurately describes how I feel about Gnome ... :-)

  I can't find it right now on Google, but I vaguely remember that
Lennart asked the Gnome people to make systemd a hard dependancy.  Not
much later logind, which is required by Gnome, picks up systemd as a
hard dependancy.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[Alexey Eschenko]

Hi. Thank you for your attention. Try to remove the blocker in blueman, see if files collide or notHow can I remove the blocker in blueman? AFAIK it's not like adding package constraint to the package.unmask or something like that. I have no experience with writing ebuilds though.But I can check "equery f" for one package and then remove it, install another and check the same for it and then look for repeating file paths. Will it be enough? 09.12.2017, 17:08, "Mart Raudsepp" :On R, 2017-12-08 at 19:39 +0700, Vadim A. Misbakh-Soloviov wrote: > > Is it really necessary to block one package when another installed? Most of the time, the reason to make packages to block each other is  collisions (if they they contain files (like binaries or libraries) with same  install paths). Although, I can't guarantee that it was the case here.There was a blocker in blueman against gnome-bluetooth due to a filecollision with gnome-bluetooth. This was removed with 2.0-r1, back inOct 2015, as blueman upstream solved it.To me it looks like the change didn't make it to the live ebuild andthen eventually sometime after 2.0.3 a bump was made via copying from, not the latest version, thus reinstating the blocker, possibly byaccident. Or maybe on purpose, but I don't see an explanation for it inlogs.Try to remove the blocker in blueman, see if files collide or not, andif not file a bug against blueman, possibly with info that it mighthave been accidental reintroduction due to..., etc.  I've noticed that Gnome Team makes some decisions, that doesn't looks logical  for a few times already.Something not looking logical for you doesn't mean there isn't soundlogic. In this case, it's not us who have a blocker possibly wronglyreintroduced here.Best,Mart RaudseppGentoo GNOME team lead