Duncan wrote:
> David Leverton posted on Thu, 26 Nov 2009 12:35:53 + as excerpted:
>
>> If we're not going to insist on preserving nanoseconds as far as
>> possible, then package managers should be required to explcitly clear
>> the nanoseconds part.
>
> While I'm not sure what it's going to
On Thursday 26 November 2009 13:21:43 Brian Harring wrote:
> It was always on the todo to convert portage over to preserving mtime-
> this long predates PMS and even EAPI.
Like, for example, use deps? Yet somehow we managed to introduce those in a
new EAPI, instead of retroactively adding them t
On Thu, 26 Nov 2009 08:33:03 -0800
Brian Harring wrote:
> > "Provide proof that all existing and future caches that would rely
> > upon this validation mechanism are functions purely and exclusively
> > dependent upon the VDB content, and I shall be happy to make the
> > change."
>
> First I've s
On Thu, Nov 26, 2009 at 03:31:17PM +, Ciaran McCreesh wrote:
> On Wed, 25 Nov 2009 17:34:38 -0800
> Brian Harring wrote:
> > I'd like
> > http://archives.gentoo.org/gentoo-dev/msg_6b3e00049a1bf35fbf7a5e66d1449553.xml
> > to be discussed, specifically zacs form of forced mtime updating of
> >
On Wed, 25 Nov 2009 17:34:38 -0800
Brian Harring wrote:
> I'd like
> http://archives.gentoo.org/gentoo-dev/msg_6b3e00049a1bf35fbf7a5e66d1449553.xml
> to be discussed, specifically zacs form of forced mtime updating of
> /var/db/pkg on vdb modifications
I've still not had an answer to:
"Provide
On Thu, 26 Nov 2009 08:59:44 +0100
Ulrich Mueller wrote:
> >> Not non-preservation. Partial and inconsistent corruption.
>
> > Wouldn't "loss of precision" be a more accurate description?
>
> Yes. Or even "rounding".
No, corruption, including of the seconds part, is the right way to
describe it
On 26-11-2009 12:36:47 +, Duncan wrote:
> > I think there's unfortunately no simple way to tell what should be in
> > and what unfortunately has to be out. It depends a lot on the host
> > system. I feel -- but I can't back this up with hard evidence -- that
> > it are usually the libs that a
On Wed, 25 Nov 2009 17:14:27 -0800
Brian Harring wrote:
> This discussion in generall is daft. No package can rely on
> nanonsecond resolution for installation because the most common FS
> out there (ext3) does *second* level resolution only. As such, I can
> pretty much gurantee there is *zer
On Wed, 25 Nov 2009 16:49:17 -0800
Zac Medico wrote:
> > Not non-preservation. Partial and inconsistent corruption.
>
> Wouldn't "loss of precision" be a more accurate description? Of the
> known packages which require timestamp preservation, do any of them
> use sub-second precision in their tim
On Wed, 25 Nov 2009 17:28:33 -0800
Brian Harring wrote:
> > It's not in the least bit nasty. It's requiring people to be
> > explicit about special requirements.
>
> I honestly wish that explicitness you're pushing for mtime were
> applied to all parts of mtime.
>
> Why is this one special? Tw
On 25-11-2009 16:43:32 -0700, Denis Dupeyron wrote:
> > Yes, I agreed coming up with some patch. I admit I haven't yet even
> > looked into it.
>
> Great, thanks. If you can have it ready some time before the meeting
> so that all devs can get a chance to review it before the council
> members vo
On Thu, Nov 26, 2009 at 12:35:53PM +, David Leverton wrote:
> 2009/11/26 Brian Harring :
> > It's an academic discussion, and pointless. We don't mandate the
> > filesystems PMS implementations are run on- as such we cannot make a
> > gurantee to ebuilds that nanosecond resolution is available
Potentially just being a tool and taking the bait..
On Thu, Nov 26, 2009 at 12:41:55PM +, David Leverton wrote:
> 2009/11/26 Brian Harring :
> > Why is this one special? Two out of three do this already, and it
> > works.
>
> You mean "two out of three blatently ignored long-standing behavio
David Leverton posted on Thu, 26 Nov 2009 12:35:53 + as excerpted:
> If we're not going to insist on preserving nanoseconds as far as
> possible, then package managers should be required to explcitly clear
> the nanoseconds part.
While I'm not sure what it's going to do to install-times and t
2009/11/26 Brian Harring :
> Why is this one special? Two out of three do this already, and it
> works.
You mean "two out of three blatently ignored long-standing behaviour
and added a new feature without discussion or an EAPI bump".
> Paludis doesn't preserve mtime
You mean "Paludis carefully
Fabian Groffen posted on Thu, 26 Nov 2009 11:51:06 +0100 as excerpted:
>> Are there any less obvious ones
>
> Some that you may find are:
> /lib/libm.so
> /lib/libsocket.so
> /lib/libpthread.so
> /lib/libnsl.so
>
> On a side note, we have a question about this in our
> prefix-ebuild-quiz[1] (que
2009/11/26 Brian Harring :
> This discussion in generall is daft. No package can rely on
> nanonsecond resolution for installation because the most common FS out
> there (ext3) does *second* level resolution only. As such, I can
> pretty much gurantee there is *zero* packages out there that requi
> On Thu, 26 Nov 2009, Łukasz Michalik wrote:
>> I can speak for Emacs only, where the comparison code (in fileio.c) is
>> as follows:
>>
> [snip]
>>
>> It uses stat(2), therefore nanoseconds are ignored.
> So, when that is updated to require nanosecond resolution where
> supported, we're o
On 26-11-2009 10:37:10 +, Duncan wrote:
> Fabian Groffen posted on Thu, 26 Nov 2009 11:10:09 +0100 as excerpted:
>
> > Gentoo Prefix tries to be as much self-sufficient as possible, and hence
> > applications *must* not reference the host system, unless absolutely
> > necessary, such as for e.
Fabian Groffen posted on Thu, 26 Nov 2009 11:10:09 +0100 as excerpted:
> Gentoo Prefix tries to be as much self-sufficient as possible, and hence
> applications *must* not reference the host system, unless absolutely
> necessary, such as for e.g. /lib/libc.so.
Thanks. Host libc /does/ make sense
On 26-11-2009 10:01:24 +, Duncan wrote:
> > required dependencies for. Hence, ekeyword should be installed such
> > that it references the perl from the offset installation, e.g.
> > "/home/joe/gentoo/usr/bin/perl".
> >
> > "/bin/sh" is another nice one.
>
> At least here, that it would ordi
Fabian Groffen posted on Thu, 26 Nov 2009 09:53:04 +0100 as excerpted:
>> > Next to that, it is part of the Prefix team's job to make sure that
>> > whatever is installed, does not reference the host system when this
>> > is not absolutely necessary.
>>
>> Could you give some examples of when it
On 08:59 2009-11-26 +0100, Ulrich Mueller wrote:
>
> I can speak for Emacs only, where the comparison code (in fileio.c) is
> as follows:
>
[snip]
>
> It uses stat(2), therefore nanoseconds are ignored.
>
So, when that is updated to require nanosecond resolution where
supported, we're off to h
* "Joe Peterson (lavajoe)" :
> 1.1
> media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/squeezeboxserver/squeezeboxserver-7.4.1.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewc
> On Thu, 26 Nov 2009, Ulrich Mueller wrote:
> On Wed, 25 Nov 2009, Zac Medico wrote:
>> Of the known packages which require timestamp preservation, do any
>> of them use sub-second precision in their timestamp comparisons?
> I can speak for Emacs only, where the comparison code (in filei
On 25-11-2009 17:01:19 -0700, Denis Dupeyron wrote:
> It looks like this question is still unanswered:
>
> On Thu, Nov 19, 2009 at 5:26 PM, Denis Dupeyron wrote:
> >> How are dynamically linked set*id programs going to work?
Depends on how the host OS/libc handles this :)
If you're root, you ca
On 25-11-2009 16:43:32 -0700, Denis Dupeyron wrote:
> Things seem to be progressing nicely on this front. We have answers to
> the questions people had and they look satisfactory to me.
>
> One thing that I think would be valuable is a document that explains
> the average dev how to make his/her e
> On Wed, 25 Nov 2009, Zac Medico wrote:
>> Not non-preservation. Partial and inconsistent corruption.
> Wouldn't "loss of precision" be a more accurate description?
Yes. Or even "rounding".
> Of the known packages which require timestamp preservation, do any
> of them use sub-second precis
28 matches
Mail list logo