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
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 (
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 co
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 b
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 repor
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 a
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?
>>
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 p
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
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
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::gento
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
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-dr
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 wor
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
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,
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
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
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 swi
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
> le
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
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 depende
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 bc
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:
> [
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
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-
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 a
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
28 matches
Mail list logo
