Nice, thanks for leading on this. Still no clue whether "fix"
or "bug compatible" is preferred. One, not both, choices please.
73 de Jeff
On Oct 26, 2010, at 12:17 PM, Per Øyvind Karlsen wrote:
> RPM Package Manager, CVS Repository
> http://rpm5.org/cvs/
> _
2009/8/6 Jeff Johnson
>
> On Aug 6, 2009, at 4:09 AM, Per Øyvind Karlsen wrote:
>
> 2009/8/6 Jeff Johnson
>
>>
>> On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote:
>>
>> 2009/8/6 Jeff Johnson
>>
>>> Why are you reverting? The issue in the comment has already been fixed by
>>> committing to
On Aug 6, 2009, at 4:09 AM, Per Øyvind Karlsen wrote:
2009/8/6 Jeff Johnson
On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote:
2009/8/6 Jeff Johnson
Why are you reverting? The issue in the comment has already been
fixed by committing to
a representation for missing values.
hm, reall
2009/8/6 Jeff Johnson
>
> On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote:
>
> 2009/8/6 Jeff Johnson
>
>> Why are you reverting? The issue in the comment has already been fixed by
>> committing to
>> a representation for missing values.
>
> hm, really?
>
> I merely duplicated the hack used
On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote:
2009/8/6 Jeff Johnson
Why are you reverting? The issue in the comment has already been
fixed by committing to
a representation for missing values.
hm, really?
I merely duplicated the hack used otherwise in rpmEVRoverlap(), what
would
2009/8/6 Jeff Johnson
> Why are you reverting? The issue in the comment has already been fixed by
> committing to
> a representation for missing values.
hm, really?
I merely duplicated the hack used otherwise in rpmEVRoverlap(), what would
be the proper solution?
--
Regards,
Per Øyvind
Why are you reverting? The issue in the comment has already been fixed
by committing to
a representation for missing values.
73 de Jeff
On Aug 5, 2009, at 8:56 PM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
___
On Jan 10, 2009, at 10:54 AM, Ralf S. Engelschall wrote:
On Sat, Jan 10, 2009, Jeff Johnson wrote:
[...]
Since I don't wish to be supporting different and competing RPM
implementations, I will proceed pushing the changes all the way back
to the -r rpm-4_5 branch over the next week/month.
Bu
On Sat, Jan 10, 2009, Jeff Johnson wrote:
> [...]
> Since I don't wish to be supporting different and competing RPM
> implementations, I will proceed pushing the changes all the way back
> to the -r rpm-4_5 branch over the next week/month.
But at least do not rush with this. Instead please let th
This check-in is a watershed event because RPM is now using
*RE pattern matching on a critically important internal code path.
That means that a *RE implementation (rpm is currently using PCRE)
is now MANDATORY. RPM simply will not work if an EVR string cannot be
split into a tuple using some *RE
On Jan 3, 2009, at 6:06 PM, Per Øyvind Karlsen wrote:
Now the pcre beast needs to be dealt with next. :D
FYI: valgrind is b0rked up for me with -pie linkage. No fscking clue,
but
I reverted from -pie in order to use the only tool I trust, valgrind,
gdb is just too
messed up. I still don
2009/1/3 Jeff Johnson
> With this patch, the basics to introduce a precedence
> permutation into EVRD comparison should now be in place on HEAD.
>
> (aside)
> Yes, I'm still in denial about PCRE <-> ERE issues, and
> most certainly a gather operation to collect parsed
> sub-patterns is absolutely
With this patch, the basics to introduce a precedence
permutation into EVRD comparison should now be in place on HEAD.
(aside)
Yes, I'm still in denial about PCRE <-> ERE issues, and
most certainly a gather operation to collect parsed
sub-patterns is absolutely needed for "full generality".
Ther
13 matches
Mail list logo
