(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
___
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 gnu/libc-version.h
# define may_use_getgrouplist() \
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 to
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 the new
Hello,
On Fri, 22 Jul 2005, Roland Illig wrote:
But another question arises: Do we want to keep this variable and the
patch forever? Or will we remove it in one or two years?
Does it make any difference ?
___
Mc-devel mailing list
Why do we use getgrouplist(3) at all? What we're interested in are the
permissions of the current process, not what's in the system-wide database.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Pavel Tsekov wrote:
Hello,
On Fri, 22 Jul 2005, Roland Illig wrote:
But another question arises: Do we want to keep this variable and the
patch forever? Or will we remove it in one or two years?
Does it make any difference ?
Yes, it bloats the code.
Roland
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
Roland Illig wrote:
Why do we use getgrouplist(3) at all? What we're interested in are the
permissions of the current process, not what's in the system-wide database.
After applying this patch, everything works as usual.
Why have we used a GTree for storing the group IDs of the process? In my
Roland Illig wrote:
Roland Illig wrote:
Why do we use getgrouplist(3) at all? What we're interested in are the
permissions of the current process, not what's in the system-wide
database.
After applying this patch, everything works as usual.
and here's a more readable variant of the
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 got
Hello,
On Fri, 22 Jul 2005, Roland Illig wrote:
Roland Illig wrote:
Why do we use getgrouplist(3) at all? What we're interested in are the
permissions of the current process, not what's in the system-wide database.
This question seems reasonable.
After applying this patch, everything
On Fri, Jul 22, 2005 at 10:23:27AM +0200, Roland Illig wrote:
+/* Return the index of the permissions triplet */
+int
+get_user_permissions (struct stat *buf) {
+static gboolean initialized = FALSE;
+static gid_t groups[NGROUPS_MAX];
NGROUPS_MAX can be fairly large, plus it is max
Jakub Jelinek wrote:
But, IMHO far better would be to:
static gid_t *groups;
if (!groups) {
uid = getuid ();
n = getgroups (0, NULL);
if (n 0) error_handling;
groups = malloc (n * sizeof (gid_t));
if (groups == NULL) error_handling;
n = getgroups (n, groups);
if (n 0)
Roland Illig wrote:
Vitja Makarov wrote:
Hi, all!
When I press f1 twice I mc receives sig11. The problem is in help_show():
Fixed in HEAD. Will port that to PRE, too.
It does not occur in PRE, because the [How to use help] node is always
found there. In HEAD it was not found because I
Jakub Jelinek wrote:
But, IMHO far better would be to:
static gid_t *groups;
if (!groups) {
uid = getuid ();
n = getgroups (0, NULL);
if (n 0) error_handling;
groups = malloc (n * sizeof (gid_t));
if (groups == NULL) error_handling;
n = getgroups (n, groups);
if (n 0)
On Fri, 22 Jul 2005, Roland Illig wrote:
I updated the patch.
Seems nice. How about removing the configure bits related to
getgrouplist() too ?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Hi Roland,
On Fri, 2005-07-22 at 09:27, Roland Illig wrote:
Arpad Biro wrote:
The first of should be or IMHO. This string is in src/ext.c
Fixed. Thanks.
Does that mean the translations also need to be updated to reflect the
change in the original string?
Leonard.
--
mount -t life -o ro
Pavel Tsekov wrote:
On Fri, 22 Jul 2005, Roland Illig wrote:
I updated the patch.
Seems nice. How about removing the configure bits related to
getgrouplist() too ?
That's obvious. ;)
Roland
___
Mc-devel mailing list
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. Working
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() is used
Leonard den Ottolander wrote:
Does that mean the translations also need to be updated to reflect the
change in the original string?
Yes, but it only applies to HEAD. In PRE, there's still the old string,
which was so ugly to translate.
Roland
___
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
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 would not allow
Hi,
Does that mean the translations also need to be updated to reflect
the
change in the original string?
Yes, but it only applies to HEAD. In PRE, there's still the old
string,
which was so ugly to translate.
Will the release be based on PRE? If yes, how can the current PRE be
downloaded?
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's
Hi Arpad,
On Fri, 2005-07-22 at 14:47, Arpad Biro wrote:
Will the release be based on PRE? If yes, how can the current PRE be
downloaded? (I guess cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/mc
co
mc gets the HEAD branch.)
Yes. Add -r MC_4_6_1_PRE.
Leonard.
--
mount -t life -o ro /dev/dna
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 for HEAD,
Hi,
Will the release be based on PRE? If yes, how can the current PRE
be
downloaded?
Yes. Add -r MC_4_6_1_PRE.
Thanks.
In this case, I'd like to ask the list admins to remove my
new translation letter from the mail queue (it's currently
waiting for approval because of its 20K size), because
Roland Illig wrote:
+if (!initialized) {
+ uid = getuid ();
+ ngroups = getgroups (0, NULL);
+ if (ngroups != -1) {
/* allocate space for one more element
* than will be filled by getgroups(). */
+ groups = g_new (gid_t, ngroups + 1);
+
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
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 PRE.
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
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
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
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
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
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
Dear translators of mc,
in the current version of mc, some translatable strings start with
ButtonBar|. These strings are those that will appear in the button bar
at the bottom of the screen. The special thing about them is that they
can have at most 6 characters. The remainder of the string
Hi,
Updated hu.po (based on the current CVS) attached.
Translations seem to be in bad shape, so translators
please update your po files. This is how to do it:
1. download the pot file attached to this letter
2. merge your current po file to this pot file:
msgmerge
Arpad Biro wrote:
Hi,
Updated hu.po (based on the current CVS) attached.
Thank you. I committed it.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Hi,
You should always say which current you mean. HEAD or PRE? ;)
Didn't realize 4.6.1 is not from HEAD, sorry.
Both the po and pot file in the new translation letter are for the
HEAD branch. The po can be committed to that branch, and the pot can
be used by translators to translate for HEAD.
Tomasz Kłoczko wrote:
On Tue, 5 Jul 2005, Roland Illig wrote:
Leonard den Ottolander wrote:
Regenerated and committed to PRE. How does one generate the status
table?
manually. ;)
As of now, it can be generated automatically. I just committed
po/statistics.pl.
I have small script
Nerijus Baliunas wrote:
On Fri, 22 Jul 2005 11:16:27 +0200 Roland Illig [EMAIL PROTECTED] wrote:
When I press f1 twice I mc receives sig11. The problem is in help_show():
Fixed in HEAD. Will port that to PRE, too.
It does not occur in PRE, because the [How to use help] node is always
autogenerated by po/statistics.pl:
language translated fuzzy untranslated
---
az 872 5557
be 883 4754
bg 882 5052
ca 873 5556
Hi Nerijus,
On Fri, 2005-07-22 at 18:16, Nerijus Baliunas wrote:
Hmm, it occurs in mc from FC4, and I believe it is based on some snapshot
of PRE.
Nope. Jindrich has been using HEAD for FC4. Hence the name mc-4.6.1a.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
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 nice.
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 can be
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 statement
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 the
Here's a little testcase that can be used for confidence tests and for
portability tests.
You can define FIRST_GETGROUPS_FAILS and/or SECOND_GETGROUPS_FAILS and
see what's the result.
In addition to the code used in utilunix.c, there's a check that the
result of the second call to
Please accept this patch to perl.syntax file.
Rationale:
warnings is Perl pragma to control optional warnings. It is used in almost
all serious Perl scripts.
Krzysztof Duleba
--- perl.syntax.old 2005-07-22 23:22:36.528739200 +0200
+++ perl.syntax 2005-07-22 23:22:27.876297600 +0200
@@
Pavel Roskin wrote:
Hi, Roland!
On Thu, 2005-07-21 at 23:43 +0200, Roland Illig wrote:
Currently, all releases will be built with line numbers stripped. That's
why I wanted to have the translation files available separately. Or
maybe we should switch the line numbers on for releases.
If
Some build logs are available here:
http://www.roland-illig.de/mc/build-logs/
You can find _many_ warnings inside, most of which need to be fixed
before the 4.6.2 release.
Roland
___
Mc-devel mailing list
54 matches
Mail list logo
