Hello,
On Fri, 22 Jul 2005, Roland Illig wrote:
> Leonard den Ottolander wrote:
> > On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
> >
> >>Roland's patch looks good and it is pretty straight-forward. I vote for
> >>its inclusion in PRE.
> >
> > And totally untested.
>
> I have tested it on NetB
Oswald Buddenhagen wrote:
no, only an instruction: try to understand my statement another way (the
way i meant it). :-)
clarification: "this patch" relates to "any freakin' getgroups problem
patch", not "your patch". quoting the above sentence without the
preceeding one does not exactly further t
On Fri, Jul 22, 2005 at 08:43:51PM +0200, Roland Illig wrote:
> Oswald Buddenhagen wrote:
> >i'd be opposed to this patch in general if it was not for the plainly
> >incorrect semantics of the old code.
>
> Why this? [...]
> Any questions left?
>
no, only an instruction: try to understand my stat
Oswald Buddenhagen wrote:
i'd be opposed to this patch in general if it was not for the plainly
incorrect semantics of the old code.
Why this? It gives us exactly the data we want (the effective and
supplementary group IDs of the current process) instead of something
which is only similar to
On Fri, Jul 22, 2005 at 03:24:37PM +0200, Leonard den Ottolander wrote:
> On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
> > Roland's patch looks good and it is pretty straight-forward. I vote
> > for its inclusion in PRE.
>
> And totally untested.
>
bah. there is no need to test a patch that
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
> Hi Roland,
>
> On Fri, 2005-07-22 at 16:24, Roland Illig wrote:
> > Indeed. That's still buggy. And "totally untested".
>
> Well, yes, if you'd give me a hand as you know I have no experience with
> patching configure.ac that would be ni
Hi Roland,
On Fri, 2005-07-22 at 16:24, Roland Illig wrote:
> Indeed. That's still buggy. And "totally untested".
Well, yes, if you'd give me a hand as you know I have no experience with
patching configure.ac that would be nice.
Still, if this is done correctly it is far less likely to cause bre
Leonard den Ottolander wrote:
if mc_glibc_ge_2_3_3 -eq 1; then
should read
if $mc_glibc_ge_2_3_3 -eq 1; then
well, after
mc_glibc_ge_2_3_3="test 1"
this makes even sense.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo
Leonard den Ottolander wrote:
Hi,
Of course you can't use strverscmp() like that. Another go. Probably
futile but hey.
Indeed. That's still buggy. And "totally untested".
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-dev
if mc_glibc_ge_2_3_3 -eq 1; then
should read
if $mc_glibc_ge_2_3_3 -eq 1; then
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Hi,
Of course you can't use strverscmp() like that. Another go. Probably
futile but hey.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
--- configure.ac.000 2005-07-02 12:40:58.0 +0200
+++ configure.ac 2005-07-22 16:04:51.0 +0200
@@ -169,7 +169,47 @@ dnl
AC_CHEC
Leonard den Ottolander wrote:
AC_CHECK_FUNCS([atoll cfgetospeed getsid initgroups memcpy memmove memset \
putenv setreuid setuid statfs strerror strftime \
- sysconf tcgetattr tcsetattr truncate getgrouplist])
+ sysconf tcgetattr tcsetattr truncate])
+
Leonard den Ottolander wrote:
On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
Roland's patch looks good and it is pretty straight-forward. I vote for
its inclusion in PRE.
And totally untested.
I have tested it on NetBSD/i386. The "normal" case works well, and I
have also simulated the si
Hi,
On Fri, 2005-07-22 at 15:24, Leonard den Ottolander wrote:
> And totally untested. From a standpoint of a proper release procedure
> and stabilizing the tree before a release instead of introducing
> untested code I vote against and once more suggest to go with a patch to
> configure.ac for PR
Hi Pavel,
On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
> Roland's patch looks good and it is pretty straight-forward. I vote for
> its inclusion in PRE.
And totally untested. From a standpoint of a proper release procedure
and stabilizing the tree before a release instead of introducing
untes
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
> Hi Pavel,
>
> On Fri, 2005-07-22 at 14:45, Pavel Tsekov wrote:
> > Well, Roland suggested a much better fix.
> >
> > http://mail.gnome.org/archives/mc-devel/2005-July/msg00282.html
>
> Yes, I read that and that is probably the way to go
Hi Pavel,
On Fri, 2005-07-22 at 14:45, Pavel Tsekov wrote:
> Well, Roland suggested a much better fix.
>
> http://mail.gnome.org/archives/mc-devel/2005-July/msg00282.html
Yes, I read that and that is probably the way to go for HEAD, but I
don't want that to go into PRE at this time. *Please* let
Hello,
On Fri, 22 Jul 2005, Pavel Tsekov wrote:
> Hello,
>
> On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
>
> > Hi Pavel,
> >
> > On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
> > > Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
> > > getgrouplist(). What you suggest wo
Hi Pavel,
On Fri, 2005-07-22 at 14:32, Pavel Tsekov wrote:
> How about reading the whole thread ?
I sort of did that but must have glanced too casually. What did I miss?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailin
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
> Hi Pavel,
>
> On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
> > Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
> > getgrouplist(). What you suggest would not allow them to use it .
>
> Whether or not getgrouplist() i
Hi Pavel,
On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
> Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
> getgrouplist(). What you suggest would not allow them to use it .
Whether or not getgrouplist() is used is currently a compile time
option, which I think is fine. Workin
On Fri, Jul 22, 2005 at 10:07:11AM +0200, Koblinger Egmont wrote:
> On Fri, Jul 22, 2005 at 09:30:11AM +0200, Roland Illig wrote:
>
> > Hmmm, you're right. As we are sure to have a glibc, there's also a
> > function strverscmp, which we can use. I had known this issue, but as
> > glibc-2.2 only
On Fri, Jul 22, 2005 at 09:30:11AM +0200, Roland Illig wrote:
> Hmmm, you're right. As we are sure to have a glibc, there's also a
> function strverscmp, which we can use. I had known this issue, but as
> glibc-2.2 only got upto 2.2.6, I thought it would suffice.
Also AFAIK current 2.3.5 is the
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
> Hi Pavel,
>
> On Thu, 2005-07-21 at 14:17, Pavel Tsekov wrote:
> > Well, this was already discussed. It is not good enough. Let's do this the
> > right way. Addin a new option to mc.lib is not really a big deal. I think
> > we can add th
Koblinger Egmont wrote:
(strcmp(gnu_get_libc_version(), "2.3.3") > 0)
Why not? Note the ">" comparison. Since 2.3.3, this should be definitely
fixed.
Please use strverscmp() or something similar. According to strcmp, 2.3.10 is
smaller than 2.3.3.
Hmmm, you're right. As we are sure
Hello,
On Thu, 21 Jul 2005, Roland Illig wrote:
> Pavel Tsekov wrote:
> > On Thu, 21 Jul 2005, Roland Illig wrote:
> >>What about this?
> >>
> >>#ifndef HAVE_GNU_GET_LIBC_VERSION
> >># define may_use_getgrouplist() (TRUE)
> >>#else
> >># include
> >># define may_use_getgrouplist() \
> >>
> >>(strcmp(gnu_get_libc_version(), "2.3.3") > 0)
> Why not? Note the ">" comparison. Since 2.3.3, this should be definitely
> fixed.
Please use strverscmp() or something similar. According to strcmp, 2.3.10 is
smaller than 2.3.3.
--
Egmont
___
Hi Pavel,
On Thu, 2005-07-21 at 14:17, Pavel Tsekov wrote:
> Well, this was already discussed. It is not good enough. Let's do this the
> right way. Addin a new option to mc.lib is not really a big deal. I think
> we can add the new option without adding a gui element to support it for
> now.
Co
Pavel Tsekov wrote:
On Thu, 21 Jul 2005, Roland Illig wrote:
What about this?
#ifndef HAVE_GNU_GET_LIBC_VERSION
# define may_use_getgrouplist() (TRUE)
#else
# include
# define may_use_getgrouplist() \
(strcmp(gnu_get_libc_version(), "2.3.3") > 0)
#endif
Well, this was already dis
Hello,
On Thu, 21 Jul 2005, Roland Illig wrote:
> Pavel Tsekov wrote:
> > Hello,
> >
> > On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
> >
> >
> >>How does one test for the availability of glibc in configure.ac, and for
> >>glibc's version next?
> >
> >
> > Please, don't do this. The check s
Pavel Tsekov wrote:
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
How does one test for the availability of glibc in configure.ac, and for
glibc's version next?
Please, don't do this. The check should be made at runtime and not
configure time. Andrew's approach seems better to
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
> How does one test for the availability of glibc in configure.ac, and for
> glibc's version next?
Please, don't do this. The check should be made at runtime and not
configure time. Andrew's approach seems better to me. And it is not only
Hi,
How does one test for the availability of glibc in configure.ac, and for
glibc's version next?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Hi Roland,
On Wed, 2005-07-20 at 21:08, Roland Illig wrote:
> and, in src/utilunix.c, write
>
> #if defined(HAVE_GETGROUPLIST) && !defined(HAVE_GLIBC_2_3_2)
> ...
> #endif
We shouldn't need to patch utilunix.c. Just don't do
AC_CHECK_FUNCS([getgrouplist]) in case of glibc version 2.3.2. Well,
th
and, in src/utilunix.c, write
#if defined(HAVE_GETGROUPLIST) && !defined(HAVE_GLIBC_2_3_2)
...
#endif
Roland
Index: configure.ac
===
RCS file: /cvsroot/mc/mc/configure.ac,v
retrieving revision 1.30
diff -u -p -r1.30 configure.ac
---
35 matches
Mail list logo
