Re: [gentoo-user] Dynamically change PORTAGE_TMPDIR via bashrc?

[Florian Gamböck]

Hi James,

thank you for your reply.

On Sat, Sep 26, 2015 at 02:08:19PM +, James wrote:
> I have been following 'bcache' as an interesting addition to complex
> compiling scenarios. I'm not certain how it will help your 'wild ideas',
> but it is worth a look, imho

Yes, I have also heard of bcachefs, but unless I am terribly mistaken, it
doesn't offer me anything to solve my actual problem, which is "setting
portage environment variables according to MERGE_TYPE".

I am aware that my setup might not be ideal and that approaches like bcachefs
might help me creating a better compile-install-workflow. But for now -- just
for the fun of it -- let's assume that the underlying basis is fixed and all
that is left is finding a way to dynamically change variables like
PORTAGE_TMPDIR.

That could also be used for scenarios like "if the package needs to be
compiled, then use every single machine in the local network as a distcc
server; if there is already a tbz2 file for the given package, then just
install it without searching for potential servers".

Portage's bashrc can be a powerful script for several use-cases, but at the
moment I am quite sad that I can't change environment variables in there.

So, any other ideas?

Regards,
--Flo

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Mike Gilbert]

On Sun, Sep 27, 2015 at 11:07 AM, Alan McKinnon  wrote:
> So, my question: wtf are dynamic deps? How do I find the records they
> must leave behind in portage?

For the latter question, you can rebuild affected packages like so:

emerge --with-bdeps=y @changed-deps.

You can also add --changed-deps to your emerge command line for world updates.

Re: [gentoo-user] /dev/shm in a Linux container

[Poison BL.]

On Sun, Sep 27, 2015 at 11:06 AM, Mike Gilbert  wrote:
> On Sun, Sep 27, 2015 at 10:38 AM, lee  wrote:
>> Hi,
>>
>> when updating a guest in an LXC, emerging python pointed out a problem
>> with a broken /dev/shm.  So I found out how to mount /dev/shm in the
>> container and updated.
>>
>> However, I'm wondering how secure that is, and I wonder if I should
>> leave it mounted or disable the mount.  It might be a very bad idea to
>> leave it mounted, and there's probably good reasons not to have it
>> mounted by default, yet I don't know if anything in the container might
>> use or need this mount after updating.
>
> There are a few glibc functions that require it:
>
> - Shared memory
> - Semaphores
>
> As a developer, I consider your system to be mis-configured if it is
> not mounted properly, and I would immediately close any related bug
> reports. I don't see how it could possibly be a security problem.
>

By itself it's not, but there are a number of off the shelf exploits
in other code (primarily webapps) that tend to depend on it being a
trusty, reliable, writable path, even for processes running under
accounts with very low privileges. Making it noexec narrows down the
list a little, but it's far from foolproof. Avoiding it is less a
proper security measure, and more a bandaid to try to cover real
security issues you don't (yet) know you have, but the effectiveness
is really up there with obfuscation (like making your lamp stack look
like IIS to the casual passer-by).

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] CMYK comparison to sRGB between platforms

[Mick]

On Sunday 27 Sep 2015 11:50:54 Peter Humphrey wrote:
> On Sunday 27 September 2015 10:47:51 Mick wrote:
> > On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> > > I do have the two .icc files in .local/share/icc:
> > > 
> > > $ ls -l .local/share/icc
> > > total 28K
> > > -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> > > edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep
> > > 10 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10)
> > > [04-58-44].icc
> > > 
> > > /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know
> > > why there are two, nor why they have such different sizes.
> > 
> > I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was
> > extracted from your monitor's EEPROM chip through the i2c bus and saved
> > on disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H -
> > unknown (2015-09-10) [04-58-44].icc' was generated by the colorimeter
> > during your calibration exercise.
> > 
> > I'm also guessing that the smaller size of the first file is because your
> > monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such,
> > which used to only contain a 128-byte data structure.  I seem to recall
> > that very early EDID versions didn't even contain colospace and Gamma
> > data, but may be wrong.
> 
> I've just visited the Taxi site you mentioned to see what's there for my
> monitor. Nothing! So I tried uploading my ColorHug data. The page asked for
> a metadata file and a profile data file, from which I supposed that my
> smaller file is metadata about the content of the larger one. But when I
> tried to upload the two files on that assumption I got a server error.
> Same when I tried them the other way round.
> 
> Looking at the larger file with less, I find eight lines of binary data at
> the head followed by 400-odd lines of legible textual data. Interesting
> stuff, though of course I don't know what to do with it myself.
> 
> > These are [Mick's] sizes :
> > 
> > ls -n ~/.local/share/color/icc/devices/Display/
> > total 800
> > -rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239
> > EALMTF200702_edid.icc
> > -rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L
> > MP82K0712EJL_edid.icc
> > -rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ
> > 3xCurve+MTX.icc
> > -rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S
> 
> XYZLUT+MTX.icc
> 
> > The first two are from the monitors' EDID content, the latter are the
> > profiles I downloaded from the Taxi DB.  Some of these contributors'
> > profiles were created with spyder or other expensive colorimeters, so I
> > am surmising that they capture more data points and contain more
> > information, than the manufacturers EDID which is primarily contains
> > other than colorspace and Gamma data.
> 
> Lucky you! As I said, my monitor hasn't made it into the database yet. And
> it seems I can't contribute to it either.


Contributing is more involved than simply downloading a profile.  I think you 
have to use the TaxiDB API:

http://sourceforge.net/p/openicc/taxi/ci/master/tree/docs/api_doc.txt

I you are interested then you can contact the OpenICC project to ask for 
details:

 http://www.freedesktop.org/wiki/OpenIcc/

-- 
Regards,
Mick


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

Re: [gentoo-user] update problems

[Alan McKinnon]

On 26/09/2015 17:00, lee wrote:
> Alan McKinnon  writes:
> 
>> On 20/09/2015 17:28, lee wrote:
>>> Neil Bothwick  writes:
>>>
 On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
> 
>> [...]
> !!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:
>> [...]
 These are unimportant, it is simply portage telling you it is not
 updating some packages to the latest available and why. Personally, I
 believe this sort of output should only be shown when using --verbose. 
>>>
>> [...]
>>> Should I always ignore such messages?
>>
>> No, you should not ignore such messages. They are printed for a reason.
> 
> Well, what can I do other than ignore them?  With dependencies as they
> are, and given that I don't want to remove packages, some of the
> packages that could be upgraded to newer versions won't be upgraded
> because otherwise things might be broken.  There's nothing I could do
> about that, or is there?

Look, you are over-complicating this and making it way more difficult
than it needs to be.

We all agree portage would be easier to use if it was less wordy, and if
it drew a better distinction between debug, info, error and warning
messages. But right now it's not there, so unless you can step up with a
high quality patch to improve matters, you have to deal with what is there.

Look at the output, take each thing portage is saying and eveluate it on
it's own merits. Maybe you need to do something, maybe not. But you have
to read them and decide.

Your question was should you always ignore such messages, and I forget
what the such was. Obviously, no, you must not globally ignore what
software is telling you.

So clam down, take a chill pill or whatever and deal with portage on
it's own terms

> 
>> You have a SLOT conflict and whether that prevents you from proceeding
>> or not doesn't change the fact that portage knows you have that conflict.
> 
> Is it possible to solve this conflict without removing packages?

NO. YOU DO NOT JUST REMOVE PACKAGES WILLY-NILLY.

Neil already explained what a slot conflict is. Portage wants to install
two versions from the same slot. Find out why and deal with that.
Oftentimes the message is a mere info, telling you why portage won't
install the latest. This is actually the same thing as yesterday's
question on nvidia-drivers that I already answered. You treat SLOTs and
packages the same way, a SLOT is just a subset of all versions of a
packages.

> 
>> In your specific case today, I believe portage will simply install the
>> lesser version and be done with it, but it will only do that when you
>> fix the USE issue (a whole separate issue)
> 
> Probably --- yet it tells me about conflicts, makes them appear to be
> important, and leaves me wondering how to solve them.

A conflict is just a conflict, doesn't have to be serius. Maybe portage
can solve it, maybe not. Either way, you get to read and understand the
output.

> 
>> [...]
>> The USE conflict for sure. Maybe the SLOT conflict but I think portage
>> will just deal with that one
>> [...]
>>> This one doesn't look very important, or does it?
>>
>> Chill dude, seriously. The sky is not about to fall on your head and the
>> bits on your disk are not going to miraculously re-arrange themselves
>> into Windows just because you can't do this update.
> 
> Sure, yet why make unimportant messages look important and important
> ones unimportant?

Because the devs are human. Ask them.

> 
>> Portage is what it is, deal with it.
>>
>> The portage team are all unpaid volunteers just liek everyone else and
>> none of us have any right at all to make demands of them. Especially not
>> you and I who are not active contribution solutions.
> 
> I know --- however, making a suggestion to improve the messages is a
> contribution.

But freaking out and complaining helps no-one.

You appear to not fully understand the nature of the problem and your
emotional outbursts are not helping. You keep going round the same
circle, complaining about how the output doesn't suit you, but I don;t
see evidence yet that you are actually reading it. You need to read it.

> 
>> [...]
>>> How about adding comments to such messages, like "You don't need to do
>>> anything to be able to proceed." and "You need to fix this before you
>>> could proceed."?
>>
>> If emerge exited then you need to fix something in your config.
>> If emerge does not exit then your config can be used as-is.
> 
> Messages more helpful could make it easier to figure out what needs to
> be fixed.

Learn python, submit a high-quality patch.

> 
>> [...]
>>> The last sync I did before the one yesterday wasn't the day before
>>> yesterday but over three months ago, so don't ask me today (or next
>>> weekend or whenever I give it another try) when that exactly was.  See
>>> what I mean?  Asking me to mask all packages to a certain point in time

Re: [gentoo-user] /dev/shm in a Linux container

[Mike Gilbert]

On Sun, Sep 27, 2015 at 10:38 AM, lee  wrote:
> Hi,
>
> when updating a guest in an LXC, emerging python pointed out a problem
> with a broken /dev/shm.  So I found out how to mount /dev/shm in the
> container and updated.
>
> However, I'm wondering how secure that is, and I wonder if I should
> leave it mounted or disable the mount.  It might be a very bad idea to
> leave it mounted, and there's probably good reasons not to have it
> mounted by default, yet I don't know if anything in the container might
> use or need this mount after updating.

There are a few glibc functions that require it:

- Shared memory
- Semaphores

As a developer, I consider your system to be mis-configured if it is
not mounted properly, and I would immediately close any related bug
reports. I don't see how it could possibly be a security problem.

[gentoo-user] dynamic deps, wtf are they exactly

[Alan McKinnon]

Does anyone here know what dynamic deps are exactly, how they work and
can describe them?

There's lots of talk over on -dev about getting rid of them and the
closest description is from Ciaran, something like:

"ancient shit that never worked right, involving phases of the moon"

10 days ago I switched to --dynamic-deps=m in make.conf, had to emerge
-e world to get around all the resulting kde hard blocks, and all was
good till today, kio-extras was blocking plasma-workspace in impossible
ways, noticeably that the block wasn't in the ebuild at all :-)

kio-extras and dolphon were to be upgraded, plasma-workspace was not.
I've fixed it (remerge plasma-workspace to clean up cruft).

I would have thought emerge -e would have cleaned all that stuff out,
maybe it's related to removing the kde overlay.

So, my question: wtf are dynamic deps? How do I find the records they
must leave behind in portage?
-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Mike Gilbert]

On Sun, Sep 27, 2015 at 11:28 AM, Alan McKinnon  wrote:
> On 27/09/2015 17:12, Mike Gilbert wrote:
>> On Sun, Sep 27, 2015 at 11:07 AM, Alan McKinnon  
>> wrote:
>>> So, my question: wtf are dynamic deps? How do I find the records they
>>> must leave behind in portage?
>>
>> For the latter question, you can rebuild affected packages like so:
>>
>> emerge --with-bdeps=y @changed-deps.
>>
>> You can also add --changed-deps to your emerge command line for world 
>> updates.
>>
>
>
> Thanks. Running that gives surprising and unexpected results. I'm now
> curious what changed-deps really does, and the man page is terse on this.
>
> I would have thought portage already does that automatically, but I see
> a difference. If a package's deps change, but everything is still
> satisfied, portage will do nothing. Does @changed-deps rebuild
> everything that changed anyway, regardless is portage thinks it still OK?

Basically, yes. If [R]DEPEND in /var/db/pkg is different from the
values in the ebuilds in the tree, @changed-deps will select it.

> Also, these two similar commands return different results (I have
> bdeps=y in DEFAULT_OPTS btw):
>
> emerge -uND --changed-deps=y world (51 packages)
> emerge @changed-deps   (11 packages)
>
> Do you know why those commands give different results?
> The smaller list is a strict subset of the longer one.

That difference is surprising; you would probably need to ask the
portage developers to get a real answer.

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 20/09/2015 17:28, lee wrote:
>> Neil Bothwick  writes:
>> 
>>> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:

> [...]
 !!! Multiple package instances within a single package slot have been
 pulled !!! into the dependency graph, resulting in a slot conflict:
> [...]
>>> These are unimportant, it is simply portage telling you it is not
>>> updating some packages to the latest available and why. Personally, I
>>> believe this sort of output should only be shown when using --verbose. 
>> 
> [...]
>> Should I always ignore such messages?
>
> No, you should not ignore such messages. They are printed for a reason.

Well, what can I do other than ignore them?  With dependencies as they
are, and given that I don't want to remove packages, some of the
packages that could be upgraded to newer versions won't be upgraded
because otherwise things might be broken.  There's nothing I could do
about that, or is there?

> You have a SLOT conflict and whether that prevents you from proceeding
> or not doesn't change the fact that portage knows you have that conflict.

Is it possible to solve this conflict without removing packages?

> In your specific case today, I believe portage will simply install the
> lesser version and be done with it, but it will only do that when you
> fix the USE issue (a whole separate issue)

Probably --- yet it tells me about conflicts, makes them appear to be
important, and leaves me wondering how to solve them.

> [...]
> The USE conflict for sure. Maybe the SLOT conflict but I think portage
> will just deal with that one
> [...]
>> This one doesn't look very important, or does it?
>
> Chill dude, seriously. The sky is not about to fall on your head and the
> bits on your disk are not going to miraculously re-arrange themselves
> into Windows just because you can't do this update.

Sure, yet why make unimportant messages look important and important
ones unimportant?

> Portage is what it is, deal with it.
>
> The portage team are all unpaid volunteers just liek everyone else and
> none of us have any right at all to make demands of them. Especially not
> you and I who are not active contribution solutions.

I know --- however, making a suggestion to improve the messages is a
contribution.

> [...]
>> How about adding comments to such messages, like "You don't need to do
>> anything to be able to proceed." and "You need to fix this before you
>> could proceed."?
>
> If emerge exited then you need to fix something in your config.
> If emerge does not exit then your config can be used as-is.

Messages more helpful could make it easier to figure out what needs to
be fixed.

> [...]
>> The last sync I did before the one yesterday wasn't the day before
>> yesterday but over three months ago, so don't ask me today (or next
>> weekend or whenever I give it another try) when that exactly was.  See
>> what I mean?  Asking me to mask all packages to a certain point in time
>> is like asking me to do much of the package management by myself.
>
> Exactly. You DO need to do the package management yourself. The Gentoo
> devs provide useful tools in the form of portage and the tree with it's
> ebuilds and eclasses, plus some amazing automation.
>
> But, are here's the bit where so many people move away from Gentoo:
>
> You are required to do the management yourself, including most of the
> thinking and all of the sweeping up of broken pieces. That's what you
> signed up for when using Gentoo.

Perhaps not so many people would move away if the messages were
improved.

> If you want to roll back the tree, then you need to implement a
> solution that will let you do it as Gentoo does nto provide one. Git
> now makes this easier.

Converting to btrfs might work for that, if I can boot from it.

> However, tree rollbacks are inadvisable for excellent technical reasons
> - see if you can figure them out. Better to snapshot your entire system
> and revert the snapshot if it goes south.

That's not even advisable with sources, though IIRC, the reasons for
that might not apply here.  However, it's weird that a system like git
makes it inadvisable to undo something, considering that being able to
undo something very easily, is one important reason to invent and use
such a system in the first place.

Using snapshots for undoing things git is quite an application of
overengineering.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Alan McKinnon]

On 27/09/2015 17:12, Mike Gilbert wrote:
> On Sun, Sep 27, 2015 at 11:07 AM, Alan McKinnon  
> wrote:
>> So, my question: wtf are dynamic deps? How do I find the records they
>> must leave behind in portage?
> 
> For the latter question, you can rebuild affected packages like so:
> 
> emerge --with-bdeps=y @changed-deps.
> 
> You can also add --changed-deps to your emerge command line for world updates.
> 


Thanks. Running that gives surprising and unexpected results. I'm now
curious what changed-deps really does, and the man page is terse on this.

I would have thought portage already does that automatically, but I see
a difference. If a package's deps change, but everything is still
satisfied, portage will do nothing. Does @changed-deps rebuild
everything that changed anyway, regardless is portage thinks it still OK?

Also, these two similar commands return different results (I have
bdeps=y in DEFAULT_OPTS btw):

emerge -uND --changed-deps=y world (51 packages)
emerge @changed-deps   (11 packages)

Do you know why those commands give different results?
The smaller list is a strict subset of the longer one.

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

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Michael Orlitzky]

On 09/27/2015 11:07 AM, Alan McKinnon wrote:
> Does anyone here know what dynamic deps are exactly, how they work and
> can describe them?
> 
> There's lots of talk over on -dev about getting rid of them and the
> closest description is from Ciaran, something like:
> 
> "ancient shit that never worked right, involving phases of the moon"
> 

"Dynamic dependencies" is a portage option. The abridged version is:
whenever you go to install/update something, some of its dependencies
may already exist on your machine. For example, if I go to install gimp
right now, gtk is already there.

With dynamic deps, portage will scan (that is, execute) all of the
ebuilds for installed packages that could affect the dependency graph.
If any of those ebuilds have changed, portage will use the new
information rather than the info present when you originally installed
the package. So if the gtk ebuild (that I installed a month ago) has
been altered, portage will re-read it on the fly, ignoring what was in
there a month ago.

too short; didn't explain?

When you install a package, its dependencies are recorded in the VDB:

  $ cat /var/db/pkg/app-editors/nano-2.3.6/RDEPEND
  >=sys-libs/ncurses-5.9-r1[unicode] sys-apps/file

That's nice, because now if you want to install or update something
else, portage doesn't have to re-execute every ebuild/eclass that could
possibly affect the new thing -- it only has to check the VDB.

But, if I'm the maintainer of nano and I change that ncurses dependency
(let's say I drop it), then I have to make a revision bump on nano.
Otherwise, the wrong dependency would stay recorded on everyone's
system, and portage would happily use the recorded deps.

I guess at some point there were a bunch of devs who were messing with
dependencies and not bothering to make revision bumps. This can cause
users pain, so portage added a new option to ignore the cache and rescan
every single relevant ebuild/eclass for sneaky dependency changes. This
ensures that portage has the correct dependencies in its head while it's
doing resolution, but is much slower.

And then that mode was made default, which is where we are today. It
doesn't sound that bad so far -- just a tradeoff between speed and the
risk of using an incorrect cached dependency.

Buuutt dynamic-deps mode doesn't always kick in. It interacts
weirdly with subslots and other things. If portage can't find the same
ebuild to scan, it will find one that "looks like it." If that doesn't
work, it's supposed to fall back to the cache. Nobody has a flow chart
of exactly how this works. It's all in the code and there's no
specification.

And, there are other package managers besides portage. When developers
rely on dynamic deps and skip revision bumps, they're screwing users of
paludis and pkgcore (and you, now that you have dynamic deps disabled).
None of the magic is mentioned in the PMS, so you really can't rely on
it and revbumps are needed regardless.

Re: [gentoo-user] update problems

[lee]

Alan McKinnon  writes:

> On 26/09/2015 11:47, lee wrote:
>> Rich Freeman  writes:
>> 
>>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon  
>>> wrote:

> [...]
>> It gives the same results (after syncing again), plus a message that
>> wasn't there before:
>> 
>> 
>> ,
>> | x11-drivers/nvidia-drivers:0
>> | 
>> |   (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for 
>> merge) pulled in by
>> | (no parents that aren't satisfied by other packages in this slot)
>> | 
>> |   (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for 
>> merge) pulled in by
>> | ~x11-drivers/nvidia-drivers-340.93 required by 
>> (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge)
>> | ^   ^^
>> `
>> 
>> 
>> This looks kinda weird because I expect those drivers to be updated as
>> well, and if they aren't, I will have to remove nvidia-settings.
>> 
>> Let's try backtrack 500 ... same result, and doesn't take longer.
>
> That doesn't look like a block. It looks like an info message that
> portage is "helpfully" displaying (but really belongs only in -v output.
> Maybe even the non-existent -vvv...)
>
> Portage is telling you *why* it is not updating to latest stable
> nvidia-drivers even though a higher version is in the tree. It's because
> nvidia-settings is out of step with nvidia-drivers. Look at output of
> "eix nvidia":
>
> nvidia-drivers-355.11 is stable
> nvidia-settings-355.11 is unstable.
>
> The driver package will update to 355.11 when the settings package goes
> stable.
>
> A related question is "do you really need the latest nvidia drivers, or
> is 340.93 still good enough? It was good enough for the entire time you
> had it installed."

Do I need to update at all?  After all, the system has been running fine
all the time, except that I wanted the latest version of seamonkey and
that I tend to update every three months or so as time permits, and the
last update was almost haft a year ago or so.

Of course I want the latest nvidia drivers, so I removed
nvidia-settings.  (I have updated, and it took almost 2 days.)

Nvidia-settings is kinda weird anyway, like when you enable sync to
vblanc, apparently that is somehow being remembered, and the question is
"when is it applied":  When you start an X session or when you start
nvidia-settings.  Same goes for all the other settings you can make with
it.

And now, with nvidia drivers incompatible with nvidia-settings and
nvidia-settings not installed, what settings that have been made with it
are applied?

>>> If it is the rdepend issue then you can probably emerge -1 librevenge
>>> and whatever else is depending on the old version to fix it.
>>>
>>> Also, emerge running --changed-deps=y from time to time may make those
>>> kinds of problems less likely.  The first time you do it prepare to
>>> see a LOT of stuff get rebuilt - any of those packages could cause
>>> issues in the future but most probably will not.
>> 
>> Good to know, I'll keep that in mind.  I tried it and it's not too much
>> to rebuild, only a bit surprising:
> [...]
>> 
>> Should I do that before updating or after?  I guess I'm on the save side
>> doing it before, so I'll do that.
>
> Before, or just include the option in your emerge command. Portage will
> sort out the order to build them in.

Ok --- I did it before and after ...

> Remember something about portage - the only source of info it has about
> packages is what is in ebuilds. So if say a package from upstream now
> needs a different version of automake to build correctly, and the dev
> forgot to add that[1], portage can't take account of it and can't help.
>
> Portage also has many useful shortcuts, things like "you don't need to
> rebuild that package just yet as nothing in the current list needs it
> yet" so there are options to leave those packages out. But if "nothing
> needs it yet" is not true because it's missing from ebuilds, you run
> into a mess.
>
> And the really important thing is, portage cannot help resolve this.
> It's dumb software and has no clue why that build is failing.

Isn't that the same for all package management software?

 You fail to understand how gentoo works. At no time did Gentoo ever
 guarantee that updates would work like binary distros and the process
 would be trouble free. Quite the opposite - Gentoo is upfront in telling
 you that there will always be update issues and you are the person to
 solve them.

>>>
>>> While Gentoo doesn't do as much handholding as many distros, the
>>> portage output above should not be viewed as something we are proud
>>> of.
>> 
>> At least I'm learning here :)
>
> Good for you. Learning is always hard.

Some years ago I found out that the learning isn't the problem when I
was like "I don't want to do this (because I need to learn it)" and then
did and learned it.  The problem is bringing 

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Alan McKinnon]

On 27/09/2015 19:26, Michael Orlitzky wrote:
> On 09/27/2015 11:07 AM, Alan McKinnon wrote:
>> Does anyone here know what dynamic deps are exactly, how they work and
>> can describe them?
>>
>> There's lots of talk over on -dev about getting rid of them and the
>> closest description is from Ciaran, something like:
>>
>> "ancient shit that never worked right, involving phases of the moon"
>>
> 
> "Dynamic dependencies" is a portage option. The abridged version is:
> whenever you go to install/update something, some of its dependencies
> may already exist on your machine. For example, if I go to install gimp
> right now, gtk is already there.
> 
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
> If any of those ebuilds have changed, portage will use the new
> information rather than the info present when you originally installed
> the package. So if the gtk ebuild (that I installed a month ago) has
> been altered, portage will re-read it on the fly, ignoring what was in
> there a month ago.
> 
> too short; didn't explain?

Nope, I see a problem already :-)

If portage can't reliably tell if the ebuild changed, the cache may or
may not be valid and portage wouldn't know.


> When you install a package, its dependencies are recorded in the VDB:
> 
>   $ cat /var/db/pkg/app-editors/nano-2.3.6/RDEPEND
>   >=sys-libs/ncurses-5.9-r1[unicode] sys-apps/file
> 
> That's nice, because now if you want to install or update something
> else, portage doesn't have to re-execute every ebuild/eclass that could
> possibly affect the new thing -- it only has to check the VDB.
> 
> But, if I'm the maintainer of nano and I change that ncurses dependency
> (let's say I drop it), then I have to make a revision bump on nano.
> Otherwise, the wrong dependency would stay recorded on everyone's
> system, and portage would happily use the recorded deps.
> 
> I guess at some point there were a bunch of devs who were messing with
> dependencies and not bothering to make revision bumps. This can cause
> users pain, so portage added a new option to ignore the cache and rescan
> every single relevant ebuild/eclass for sneaky dependency changes. This
> ensures that portage has the correct dependencies in its head while it's
> doing resolution, but is much slower.
> 
> And then that mode was made default, which is where we are today. It
> doesn't sound that bad so far -- just a tradeoff between speed and the
> risk of using an incorrect cached dependency.
> 
> Buuutt dynamic-deps mode doesn't always kick in. It interacts
> weirdly with subslots and other things. If portage can't find the same
> ebuild to scan, it will find one that "looks like it." If that doesn't
> work, it's supposed to fall back to the cache. Nobody has a flow chart
> of exactly how this works. It's all in the code and there's no
> specification.
> 
> And, there are other package managers besides portage. When developers
> rely on dynamic deps and skip revision bumps, they're screwing users of
> paludis and pkgcore (and you, now that you have dynamic deps disabled).
> None of the magic is mentioned in the PMS, so you really can't rely on
> it and revbumps are needed regardless.


Now it all makes sense, as a bonus I now see why why so many senior devs
are so pedantic about revbumps (they have reason).

Now that I know what the symptom will be, are bug reports useful?


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

Re: [gentoo-user] update problems

[lee]

Rich Freeman  writes:

> On Sat, Sep 26, 2015 at 9:51 AM, lee  wrote:
>> |
>> |   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> | (no parents that aren't satisfied by other packages in this slot)
>> |
>> |   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) 
>> pulled in by
>> | dev-libs/boost:0/1.55.0= required by 
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>> |   ^^
>> | (and 2 more with the same problem)
>> |
>>>  (I wrote the below)
>>> that doesn't work just try running emerge -1 on the packages that are
>>> causing the block by depending on the older package version?
>>
>> I suppose the newer versions of the packages are the ones that are
>> causing the blocks.  You could argue that other versions of packages are
>> causing the blocks, but I would argue that there weren't any blocks
>> before the newer versions of the packages were available, hence the
>> newer versions obviously cause the blocks.  That is to say that I'm
>> unsure which packages you're referring to as those causing the blocks.
>
> Apologies if it was a bit unclear.

np :)

> In this example, I'd run emerge -1 =dev-libs/librevenge-0.0.2
>
> You also need to run it on the "2 more with the same problem" but we
> don't know what those are.  Adding --verbose might help.  It should be
> safe to run emerge -1 on anything you already have installed.  If this
> is a dynamic deps issue then emerge -1 pkg will probably help.
>
> Either way, after trying that can you post the output of this:
>
> emerge -j 8 -p --update --newuse --deep --with-bdeps=y --backtrack=500
> --verbose --tree @world
>
> That will show you what is pulling in updates to what.  I'm interested
> in the entire output of emerge, not just the parts you think are most
> relevant - feel free to attach a file containing it.

Well, what I did was basically:


emerge -a --changed-deps=y @world
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
[fix USE flag]
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
[remove nvidia-settings]
emerge -j 8 -a --update --newuse --deep --with-bdeps=y --backtrack=100 @world
emerge @preserved-rebuild


That took about 2 hours to update 233 packages.  Then I made the new
kernel and found that for unknown reasons, without warning, the zfs
startup scripts were disabled (very bad idea ...).  Today I updated the
LXC guest and went over the kernel settings and managed to get my
trackball not to work anymore, then took quite a while to figure out
what was missing (it needs a HID driver which, for unknown reasons, got
disabled ...).

So after two days, I finally got seamonkey 2.35 (and a cleaned-up
kernel) ... and I wonder why libreoffice hasn't been updated.  Not that
it matters, but why not?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] update problems

[Alan McKinnon]

On 27/09/2015 21:17, lee wrote:



[big snip]

>> Seems to me you are thinking like a human (because you are one) and not
>> > seeing portage's limits. Portage has no idea what would solve the issue
>> > so can't give any recommendations worth a damn. The best it can do is
>> > print some hardcoded logic that looks like it might apply.
> According to that, the human is even less able to figure out what might
> solve the problem than portage is: The human doesn't know anything about
> the huge number of dependencies involved, and even if they did, it would
> take them really really long to go through all of them to figure out
> anything at all.  Now if they do it right, the human would come to the
> same conclusion as portage, provided that portage does it right.
> 

[big snip]

Fellow, I'm done with you, really.

You hold onto your issues with portage like they were some treasured
memory of a long-since departed loved one, while all the time apparently
ignoring the correct valid solutions offeered by kind folks on this list.

Let it go. The devs know about portage output. I don't see you
submitting patches though.

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

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Rich Freeman]

On Sun, Sep 27, 2015 at 6:21 PM, Michael Orlitzky  wrote:
> On 09/27/2015 03:34 PM, Alan McKinnon wrote:
>>
>> Now it all makes sense, as a bonus I now see why why so many senior devs
>> are so pedantic about revbumps (they have reason).
>>
>> Now that I know what the symptom will be, are bug reports useful?
>>
>
> I don't think most developers are aware of the problem, so if you point
> out that the lack of a revbump causes pain, many will be glad to know
> and adjust their behavior.
>
> Or, you might just get yelled at. It's one of /those/ issues.

While working out the right way to handle dep changes in eclasses
might take a little longer, I suspect that we'll have a policy for
revbumping on dep changes in ebuilds and perhaps virtuals fairly soon.
There really wasn't much loud objection when the proposal came up
again last week - not nearly as much as the last time this came up.
With the increasing issues with subslots I think devs are appreciating
that the current state isn't really great.

-- 
Rich

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Michael Orlitzky]

On 09/27/2015 03:34 PM, Alan McKinnon wrote:
> 
> Now it all makes sense, as a bonus I now see why why so many senior devs
> are so pedantic about revbumps (they have reason).
> 
> Now that I know what the symptom will be, are bug reports useful?
> 

I don't think most developers are aware of the problem, so if you point
out that the lack of a revbump causes pain, many will be glad to know
and adjust their behavior.

Or, you might just get yelled at. It's one of /those/ issues.

Re: [gentoo-user] dynamic deps, wtf are they exactly

[Alan McKinnon]

On 28/09/2015 00:21, Michael Orlitzky wrote:
> On 09/27/2015 03:34 PM, Alan McKinnon wrote:
>>
>> Now it all makes sense, as a bonus I now see why why so many senior devs
>> are so pedantic about revbumps (they have reason).
>>
>> Now that I know what the symptom will be, are bug reports useful?
>>
> 
> I don't think most developers are aware of the problem, so if you point
> out that the lack of a revbump causes pain, many will be glad to know
> and adjust their behavior.
> 
> Or, you might just get yelled at. It's one of /those/ issues.



Oh, we're well used to deal with touchy issues around here. And we do
our fair share of yelling too :-)

Thanks for the feedback. Appreciated.


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

[gentoo-user] Re: dynamic deps, wtf are they exactly

[James]

Michael Orlitzky  gentoo.org> writes:


> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
> If any of those ebuilds have changed, portage will use the new
> information rather than the info present when you originally installed
> the package. So if the gtk ebuild (that I installed a month ago) has
> been altered, portage will re-read it on the fly, ignoring what was in
> there a month ago.

Seems reasonable from a  first glance point of view.


> That's nice, because now if you want to install or update something
> else, portage doesn't have to re-execute every ebuild/eclass that could
> possibly affect the new thing -- it only has to check the VDB.

I think that this is what GLEP-64 is all about. Enhancing the functional
utilityh of the VDB with a DAG (Directed Acyclic Graph)?


> But, if I'm the maintainer of nano and I change that ncurses dependency
> (let's say I drop it), then I have to make a revision bump on nano.
> Otherwise, the wrong dependency would stay recorded on everyone's
> system, and portage would happily use the recorded deps.

Basically from my point of view, something like TUP [1] is needed so
that at dependency check time you only list files that need
attention (linking, loading, compiling etc) thus speeding up the
update processes for the Package Manager (portage). I do not study
Palaudis or others.



> I guess at some point there were a bunch of devs who were messing with
> dependencies and not bothering to make revision bumps. This can cause
> users pain, so portage added a new option to ignore the cache and rescan
> every single relevant ebuild/eclass for sneaky dependency changes. This
> ensures that portage has the correct dependencies in its head while it's
> doing resolution, but is much slower.

There is no proper mechanism to accurately track all of these issue,
currently, or did I miss this point?


> And then that mode was made default, which is where we are today. It
> doesn't sound that bad so far -- just a tradeoff between speed and the
> risk of using an incorrect cached dependency.
> 
> Buuutt dynamic-deps mode doesn't always kick in. It interacts
> weirdly with subslots and other things. If portage can't find the same
> ebuild to scan, it will find one that "looks like it." If that doesn't
> work, it's supposed to fall back to the cache. Nobody has a flow chart
> of exactly how this works. It's all in the code and there's no
> specification.

It' a difficult subject so half baked measures abound, imho. A full DAG of
the things in the VDB that tracks and retains additional information, is
currently one possible solution. But the DAG only collects the data needed
to develop more robust tools, or at least that is my understanding. I have
read that Ninja, could implement a DAG, but the devs have not made that
commitment yet for Ninja. Neil posted a while back about "CheckInstall"
which addresses some of the problems that are related too. Thesre are not 
package managers but merely "tools" that could be employed to resolve some
of the related issues.


> And, there are other package managers besides portage. When developers
> rely on dynamic deps and skip revision bumps, they're screwing users of
> paludis and pkgcore (and you, now that you have dynamic deps disabled).
> None of the magic is mentioned in the PMS, so you really can't rely on
> it and revbumps are needed regardless.

The Package Management Specification [3] is also intertwined in this issue.
It's a very complicated issue and a problem everywhere you have complex
codes and large numbers of codes and packages that define a system. [[4] an
excellent read].  Please, folks with deeper understanding, do write as much
as you can. An updated gentoo dev blog post, at least framing the issues,
would be keen background for everyone, imho.


It becomes even more complicated  when you look at clusters, the resources
and the frameworks to solve problems, including Continuous Integration,
compiling across many languages and other goals of the cluster. I am far,
far away from possessing a sufficiently deep understanding on these issues.
I just peel back a bit of the onion most days and try to discern the issues
 I encounter:: designing a proper cluster for gentoo  does lead one down the
path of unravelling these aforementioned issues, and other issues, from the
myriad of codes, packages and strategies for distributed computing.


hth,
James

[1] http://gittup.org/tup/

[2] http://asic-linux.com.mx/~izto/checkinstall/

[3] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

[4] https://blogs.gentoo.org/blueness/2014/08/

Re: [gentoo-user] Re: dynamic deps, wtf are they exactly

[Michael Orlitzky]

On 09/27/2015 03:52 PM, James wrote:
> 
>> That's nice, because now if you want to install or update something
>> else, portage doesn't have to re-execute every ebuild/eclass that could
>> possibly affect the new thing -- it only has to check the VDB.
> 
> I think that this is what GLEP-64 is all about. Enhancing the functional
> utilityh of the VDB with a DAG (Directed Acyclic Graph)?
> 

AFAIK, that GLEP is just about standardizing what goes in the VDB. The
VDB isn't specified in the PMS either, but all package managers need to
record e.g. what files were installed by the package. The GLEP would
standardize some of that stuff, and in the future, the PMS would give
you a way to read it reliably.

The dynamic dependencies issue is more about the contents of the VDB
being wrong.


>> I guess at some point there were a bunch of devs who were messing with
>> dependencies and not bothering to make revision bumps. This can cause
>> users pain, so portage added a new option to ignore the cache and rescan
>> every single relevant ebuild/eclass for sneaky dependency changes. This
>> ensures that portage has the correct dependencies in its head while it's
>> doing resolution, but is much slower.
> 
> There is no proper mechanism to accurately track all of these issue,
> currently, or did I miss this point?

The proper mechanism is "don't do that." The rules for when (not) to
revbump could go on for pages, if there was anyone qualified to write
them -- and I'm not convinced there is. The only safe thing to do is
always revbump unless you're damned sure that you're an exception.

[gentoo-user] Re: dynamic deps, wtf are they exactly

[Martin Vaeth]

Michael Orlitzky  wrote:
>
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.

This is not correct. This data is already stored in metadata/
(or in /var/cache/edb, depending on the backend),
and just has to be read from there instead of /var/db

The difference between dynamic deps and static deps is
that in the latter case always the information from
/var/db is used, while in the former case the (usually more
up-to-date) version from metadata/ is preferred if it is available.

> Buuutt dynamic-deps mode doesn't always kick in. It interacts
> weirdly with subslots and other things.

That's the real problem: When an automatic (":=") subslot is
involved, portage did not check metadata/ but always took /var/db.
So it was necessary to either fix this inconsistent behaviour
of portage (which would not have been easy though possible),
or to switch to static deps completely which requires a
change of the dump policy.

Both approaches have advantages and disadvantages and
lead to different types of breakage in different situations -
see the lengthy and partly emotional discussion on the developers
list some years ago; I am not going to repeat the arguments.

The developers deciceded to go the way which is simplest for
them but perhaps less convenient for the user: For the user,
it means that in the future he has to rebuild *a lot* of packages
much more often than previously, for no other benefit than
updating /var/db (which would obviously not be necessary
at all for dynamic deps).

Re: [gentoo-user] Re: dynamic deps, wtf are they exactly

[Rich Freeman]

On Sun, Sep 27, 2015 at 8:33 PM, Martin Vaeth  wrote:
> Rich Freeman  wrote:
>> There really wasn't much loud objection when the proposal came up
>> again last week
>
> This does not mean that everybody agreed.
> However, all arguments had been exchanged before,
> so repeating them would just have been pointless:
> Eventually a decision had to be made, and I am confident
> that it was made by the portage team in the full awareness
> of the positive and negative consequences of that decision,
> because all portage developers had participated in the
> previous discussion.
>
>

Sure, but the portage team can really only dictate the upstream
defaults of portage, not tree policy.  I don't disagree with them, but
it wouldn't hurt to have the Council or QA weigh in just so that we're
not endlessly bickering about whether it is official or not.

-- 
Rich

[gentoo-user] Re: dynamic deps, wtf are they exactly

[Martin Vaeth]

James  wrote:
>
> Basically from my point of view, something like TUP [1] is needed so
> that at dependency check time you only list files that need
> attention (linking, loading, compiling etc) thus speeding up the
> update processes for the Package Manager (portage).

This is a misunderstanding (originally already from Michael).
The issue is not at all about speed of portage - reading one or
the other file takes the same amount of time.
(And having a dependency graph of files would help concerning
speed only in the very rare situation that no file involving
your current package dependency tree does change.)

The whole issue is only about the policy: If the dependency
information of the installed package and of the current
package differs - what is the "correct" information?

For each choice, it is possible to give examples where
the policy leads to a bad situation, so both,
static deps as well as dynamic deps can break in
certain situations. It is only a question which breakage
you consider more severe and/or harder to recognize/fix
by the user.

Making more revbumps will increase the chance of
no breakage - in case of static deps only for users
who sync and update sufficiently frequently -
of course at the cost of redundant recompiles.

>> I guess at some point there were a bunch of devs who were messing with
>> dependencies and not bothering to make revision bumps. This can cause
>> users pain, so portage added a new option to ignore the cache and rescan
>> every single relevant ebuild/eclass for sneaky dependency changes. This
>> ensures that portage has the correct dependencies in its head while it's
>> doing resolution, but is much slower.

This is historically not correct. Dynamic deps had always been
the only way portage treated dependencies - static deps have only
been used as a fallback and (unfortunately) with the introduction
of subslots.
Once more: It is not about speed, but about: What *are* the
"correct" dependencies? The ones referring to an historical tree
which - especially if you did not update for a long time -
might have almost nothing in common with the current tree
(static deps), or the ones referring to current tree
(dynamic deps)?

With static deps, you will have a strange mixture of historical
dependencies and current ones for the updates.
With dynamic deps, the tree might not be appropriate for your
installed packages.

> There is no proper mechanism to accurately track all of these issue,
> currently, or did I miss this point?

There is no way to automatically decide correctly which of
two differing informations should be used...

[gentoo-user] Re: dynamic deps, wtf are they exactly

[Martin Vaeth]

Rich Freeman  wrote:
> There really wasn't much loud objection when the proposal came up
> again last week

This does not mean that everybody agreed.
However, all arguments had been exchanged before,
so repeating them would just have been pointless:
Eventually a decision had to be made, and I am confident
that it was made by the portage team in the full awareness
of the positive and negative consequences of that decision,
because all portage developers had participated in the
previous discussion.

[gentoo-user] /dev/shm in a Linux container

[lee]

Hi,

when updating a guest in an LXC, emerging python pointed out a problem
with a broken /dev/shm.  So I found out how to mount /dev/shm in the
container and updated.

However, I'm wondering how secure that is, and I wonder if I should
leave it mounted or disable the mount.  It might be a very bad idea to
leave it mounted, and there's probably good reasons not to have it
mounted by default, yet I don't know if anything in the container might
use or need this mount after updating.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] CMYK comparison to sRGB between platforms

[Peter Humphrey]

On Saturday 26 September 2015 16:11:04 Mick wrote:

> Thank you all for your answers.  They guided me to do some reading in this
> field, which is quite a science all on its own!

--->8

> Peter's description does not mention which application loads the .icc file
> that the hughski creates, but I'm guessing there must be something that does
> read it, if the monitor settings are indeed altered.

As far as I remember, it's the colorhug's own program that sets the monitor at
the end of its calibration process. After that, the monitor has kept those
settings and hasn't needed any further tweaking.

I do have the two .icc files in .local/share/icc:

$ ls -l .local/share/icc
total 28K
-rw-r--r-- 1 prh prh 1.2K Sep  9 16:51 edid-fbec4f9c1804ea718b6e1b585fc234ad.icc
-rw-rw-r-- 1 prh prh  21K Sep 10 10:41 GCM - Samsung - SMS27A350H - unknown 
(2015-09-10) [04-58-44].icc

/usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why there
are two, nor why they have such different sizes.

Maybe I'm mistaken and KDE is reading what it needs at startup from those
Files. I'll try moving them and see what happens.

> With the monitors sorted as best as I could adjust them manually I loaded
> the icc files with Kolor-manager.  I could not see any change in the colors
> displayed by the monitors.  They are both wide gamut monitors, so perhaps
> the RGB changes were within the narrower RGB spectrum and that's why I did
> not notice a difference - not to mention that my eyes are not they used to
> be. :p
> 
> Having done all this, I revisited ImageMagick.  I ran identify -verbose and
> discovered that the original jpg image did not have an embedded icc profile.
> So I reran the command specifying a cmyk profile for the input file and an
> sRGB for the output file.  The result is now satisfactory and comparable on
> all operating systems.
> 
> I am still a bit unclear if on non-KDE dekstops xserver will pick up any icc
> files for the monitor from ~/.local/share/color/icc and load them at start
> up all on its own, or if any additional software is necessary to achieve
> this.

Yes, I'm also unclear on this.

-- 
Rgds
Peter

Re: [gentoo-user] CMYK comparison to sRGB between platforms

[Mick]

On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> On Saturday 26 September 2015 16:11:04 Mick wrote:
> > Thank you all for your answers.  They guided me to do some reading in
> > this field, which is quite a science all on its own!
> 
> --->8
> 
> > Peter's description does not mention which application loads the .icc
> > file that the hughski creates, but I'm guessing there must be something
> > that does read it, if the monitor settings are indeed altered.
> 
> As far as I remember, it's the colorhug's own program that sets the monitor
> at the end of its calibration process. After that, the monitor has kept
> those settings and hasn't needed any further tweaking.
> 
> I do have the two .icc files in .local/share/icc:
> 
> $ ls -l .local/share/icc
> total 28K
> -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep 10
> 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10) [04-58-44].icc
> 
> /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why
> there are two, nor why they have such different sizes.

I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was 
extracted from your monitor's EEPROM chip through the i2c bus and saved on 
disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H - unknown 
(2015-09-10) [04-58-44].icc' was generated by the colorimeter during your 
calibration exercise.

I'm also guessing that the smaller size of the first file is because your 
monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such, which 
used to only contain a 128-byte data structure.  I seem to recall that very 
early EDID versions didn't even contain colospace and Gamma data, but may be 
wrong.

These are the sizes :

ls -n ~/.local/share/color/icc/devices/Display/
total 800
-rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239 
EALMTF200702_edid.icc
-rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L 
MP82K0712EJL_edid.icc
-rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ 
3xCurve+MTX.icc
-rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S XYZLUT+MTX.icc

The first two are from the monitors' EDID content, the latter are the profiles 
I downloaded from the Taxi DB.  Some of these contributors' profiles were 
created with spyder or other expensive colorimeters, so I am surmising that 
they capture more data points and contain more information, than the 
manufacturers EDID which is primarily contains other than colorspace and Gamma 
data.


> Maybe I'm mistaken and KDE is reading what it needs at startup from those
> Files. I'll try moving them and see what happens.
> 
> > With the monitors sorted as best as I could adjust them manually I loaded
> > the icc files with Kolor-manager.  I could not see any change in the
> > colors displayed by the monitors.  They are both wide gamut monitors, so
> > perhaps the RGB changes were within the narrower RGB spectrum and that's
> > why I did not notice a difference - not to mention that my eyes are not
> > they used to be. :p
> > 
> > Having done all this, I revisited ImageMagick.  I ran identify -verbose
> > and discovered that the original jpg image did not have an embedded icc
> > profile. So I reran the command specifying a cmyk profile for the input
> > file and an sRGB for the output file.  The result is now satisfactory
> > and comparable on all operating systems.
> > 
> > I am still a bit unclear if on non-KDE dekstops xserver will pick up any
> > icc files for the monitor from ~/.local/share/color/icc and load them at
> > start up all on its own, or if any additional software is necessary to
> > achieve this.
> 
> Yes, I'm also unclear on this.

-- 
Regards,
Mick


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

Re: [gentoo-user] CMYK comparison to sRGB between platforms

[Peter Humphrey]

On Sunday 27 September 2015 10:47:51 Mick wrote:
> On Sunday 27 Sep 2015 09:58:43 Peter Humphrey wrote:
> > I do have the two .icc files in .local/share/icc:
> > 
> > $ ls -l .local/share/icc
> > total 28K
> > -rw-r--r-- 1 prh prh 1.2K Sep  9 16:51
> > edid-fbec4f9c1804ea718b6e1b585fc234ad.icc -rw-rw-r-- 1 prh prh  21K Sep 10
> > 10:41 GCM - Samsung - SMS27A350H - unknown (2015-09-10) [04-58-44].icc
> > 
> > /usr/bin/file shows them both as "ColorSync ICC Profile". I don't know why
> > there are two, nor why they have such different sizes.
> 
> I'm guessing that the 'edid-fbec4f9c1804ea718b6e1b585fc234ad.icc' was
> extracted from your monitor's EEPROM chip through the i2c bus and saved on
> disk by the LiveCD you ran, but the 'GCM - Samsung - SMS27A350H - unknown
> (2015-09-10) [04-58-44].icc' was generated by the colorimeter during your
> calibration exercise.
> 
> I'm also guessing that the smaller size of the first file is because your
> monitor's EDID is of an earlier version, e.g. EDID-v1.1 or some such, which
> used to only contain a 128-byte data structure.  I seem to recall that very
> early EDID versions didn't even contain colospace and Gamma data, but may be
> wrong.

I've just visited the Taxi site you mentioned to see what's there for my 
monitor. Nothing! So I tried uploading my ColorHug data. The page asked for a 
metadata file and a profile data file, from which I supposed that my smaller 
file 
is metadata about the content of the larger one. But when I tried to upload 
the two files on that assumption I got a server error. Same when I tried them 
the other way round.

Looking at the larger file with less, I find eight lines of binary data at the 
head followed by 400-odd lines of legible textual data. Interesting stuff, 
though of course I don't know what to do with it myself.

> These are [Mick's] sizes :
> 
> ls -n ~/.local/share/color/icc/devices/Display/
> total 800
> -rw-r--r-- 1 1001 1001   1944 Sep 18 18:16 ACI ASUS VS239
> EALMTF200702_edid.icc
> -rw-r--r-- 1 1001 1001   2016 Sep 18 18:16 Dell Computer DELL ST2320L
> MP82K0712EJL_edid.icc
> -rw-r--r-- 1 1001 1001  20884 Sep 18 19:01 P2311H 2012-06-20 2.2 MQ-HQ
> 3xCurve+MTX.icc
> -rw-r--r-- 1 1001 1001 783804 Sep 18 19:02 PA248 2015-04-18 S 
XYZLUT+MTX.icc
> 
> The first two are from the monitors' EDID content, the latter are the
> profiles I downloaded from the Taxi DB.  Some of these contributors'
> profiles were created with spyder or other expensive colorimeters, so I am
> surmising that they capture more data points and contain more information,
> than the manufacturers EDID which is primarily contains other than
> colorspace and Gamma data.

Lucky you! As I said, my monitor hasn't made it into the database yet. And it 
seems I can't contribute to it either.

-- 
Rgds
Peter