* Re: [mount] --bind -o suid/exec/...
From: Stephane Chazelas @ 2010-02-09 17:09 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux-ng
In-Reply-To: <20100209162305.GG6375@nb.net.home>
2010-02-09 17:23:05 +0100, Karel Zak:
[...]
> > mount --bind /here /there
> > mount -o remount,noexec /there
[...]
> >, or better, "mount" could
> > be changed so that one can do it in a single step with:
> >
> > mount --bind -o noexec /here /there
>
> this is unsupported by kernel, the "remount" and "bind" are two
> different operations.
[...]
Thanks Karel,
but what about changing mount(8) so that it does two mount(2)s
upon --bind -o?
One thing I've not mentionned is that it makes it quite awkward
to add it in /etc/fstab.
/here /there none bind 0 0
there-remount /there none remount,noexec 0 0
works with mount -a but not with Ubuntu's mountall(8) for
instance.
Cheers,
Stephane
^ permalink raw reply
* *fdisk doesn't check 2TB boundary
From: Michal Hocko @ 2009-05-07 14:43 UTC (permalink / raw)
To: util-linux-ng
[Please CC me as I am not subscribed to the list]
Hi,
we have received report from one of our customers that they have a
problem with sfdisk which doesn't check and shout loudly when 2TB
boundary is crossed when partition is created. This results in silent
ignoring of the new partition.
I have noticed a similar bug report in Debian bugzilla[1] but this one
is silent for more than 4 years.
I do understand that user should know what he is doing when creating a
partion and that msdos partitions are limited to 2TB, but is there any
special reason why this limit is not checked?
---
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324525
--
Michal Hocko
L3 team
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply
* [PATCH] flock.1: typo in man page
From: LaMont Jones @ 2007-08-29 13:08 UTC (permalink / raw)
To: util-linux-ng
[-- Attachment #1: Type: text/plain, Size: 36 bytes --]
This is from a user report.
lamont
[-- Attachment #2: 0001-flock.1-typo-in-man-page.patch --]
[-- Type: text/x-diff, Size: 775 bytes --]
>From d55e373cf5d4c9e6e39ce847f1563e0c8c5cc193 Mon Sep 17 00:00:00 2001
From: A. Costa <agcosta@gis.net>
Date: Wed, 29 Aug 2007 07:07:10 -0600
Subject: [PATCH] flock.1: typo in man page
Signed-off-by: LaMont Jones <lamont@debian.org>
---
sys-utils/flock.1 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sys-utils/flock.1 b/sys-utils/flock.1
index 3b13efb..237e44c 100644
--- a/sys-utils/flock.1
+++ b/sys-utils/flock.1
@@ -45,7 +45,7 @@ or
It locks a specified file, which is created (assuming appropriate
permissions), if it does not already exist.
.PP
-The second form is conveninent inside shell scripts, and is usually
+The second form is convenient inside shell scripts, and is usually
used the following manner:
.PP
\fC(
--
1.5.2.3
^ permalink raw reply related
* Re: what happend with hwclock patches?
From: David Brownell @ 2007-03-07 20:08 UTC (permalink / raw)
To: Karel Zak; +Cc: List util-linux-ng
In-Reply-To: <20070307190137.GA26835@petra.dvoda.cz>
On Wednesday 07 March 2007 11:01 am, Karel Zak wrote:
> On Wed, Mar 07, 2007 at 09:42:49AM -0800, David Brownell wrote:
> > > There is active development, see "log" in the devel branch:
> > >
> > > http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=log;h=devel
> >
> > Well, by active development I included "merging patches submitted" e.g. hwclock,
>
> Sure, but the util-linux-ng is still not in the condition when I'll
> merging patches ASAP. There are tons of others and more important
> patches, there wasn't any tests, there was broken build system ...
> Don't forget that the code has been unmaintained for almost 2 years.
I'd call some of that "catching up with the backlog", which is
of course one kind of development. OK, so I'm picky; shoot me!
I was pleased to see tests getting added. It's as if this were
becoming a real software project ... ;)
> Please, be patient at least for next 1-2 months.
>
> BTW, "active" also means that someone answers your mails. I hope you
> see the change :-)))
Yes indeedy!!
>
> Also see:
> http://userweb.kernel.org/~kzak/util-linux-ng/
>
>
> I believe there is more light now :-)
Yes. Worth posting a status update to LKML?
- Dave
^ permalink raw reply
* Re: what happend with hwclock patches?
From: Karel Zak @ 2007-03-07 19:01 UTC (permalink / raw)
To: David Brownell; +Cc: List util-linux-ng
In-Reply-To: <200703070942.49785.david-b@pacbell.net>
On Wed, Mar 07, 2007 at 09:42:49AM -0800, David Brownell wrote:
> > There is active development, see "log" in the devel branch:
> >
> > http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=log;h=devel
>
> Well, by active development I included "merging patches submitted" e.g. hwclock,
Sure, but the util-linux-ng is still not in the condition when I'll
merging patches ASAP. There are tons of others and more important
patches, there wasn't any tests, there was broken build system ...
Don't forget that the code has been unmaintained for almost 2 years.
Please, be patient at least for next 1-2 months.
BTW, "active" also means that someone answers your mails. I hope you
see the change :-)))
> but it's also rather conventional to have patches show up on mainline instead of
> only on branches. See for example the kernel tree, or essentially any other tree...
>
> It stiil doesn't *show* that development in the usual way. Attributing the issue
> to gitweb isn't relevant; lots of people don't know more than "git pull", and if
> that doesn't give them updates, they effectively didn't happen.
$ git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng
$ git checkout -f devel
$ git log
Well, we're very exotic. We use branches.
There is:
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/devel:refs/heads/devel
after "git clone", so I don't see any problem with "git pull". You
should see updates in the 'devel' branch as well.
Also see:
http://userweb.kernel.org/~kzak/util-linux-ng/
I believe there is more light now :-)
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: what happend with hwclock patches?
From: David Brownell @ 2007-03-07 17:42 UTC (permalink / raw)
To: Karel Zak; +Cc: List util-linux-ng
In-Reply-To: <20070307104257.GC25806@petra.dvoda.cz>
On Wednesday 07 March 2007 2:42 am, Karel Zak wrote:
> Thanks for this link. The patch is not applied yet. Maybe I should
> release a snapshot (at least) with urgent things like hwclock or some
> mount patches.
Something like that would probably be a good thing. The visibility that
patches are finally getting released will help restart machinery that's had
sand in its gears for way too long.
> But I think you should ask downstream (your distribution) maitainer
> to apply these kind of patches. They have pretty stable util-linux
> packages now. I'll need few weeks to prepare useful util-linux-ng release.
>
> (I'm going to add the patch to Fedora tree.)
Thing is, distros are more likely to notice an updated util-linux package
than Yet Another Patch That Should Have Come From Upstream ... and the issue
is not _my_ distro (heck, I patched my systems directly) but every distro
that could potentially run a 2.6.21 kernel. I am *NOT* in touch with many
such maintainers.
> On Tue, Mar 06, 2007 at 08:06:27PM -0800, David Brownell wrote:
>
> > I see there's a GIT archive but you don't seem to have merged the patch I sent
> > you back in November ... and the GIT tree doesn't show any active development,
> > no commits except syncing to old releases.
>
> Please, don't use broken gitweb at kernel.org or use it very carefully.
>
> There is active development, see "log" in the devel branch:
>
> http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=log;h=devel
Well, by active development I included "merging patches submitted" e.g. hwclock,
but it's also rather conventional to have patches show up on mainline instead of
only on branches. See for example the kernel tree, or essentially any other tree...
It stiil doesn't *show* that development in the usual way. Attributing the issue
to gitweb isn't relevant; lots of people don't know more than "git pull", and if
that doesn't give them updates, they effectively didn't happen.
> The good news is that I have more time and I work on that full time
> now.
That's good to know. As you're well aware, the fact that this package
is an orphan has made trouble. No real release since 2005, etc ...
- Dave
^ permalink raw reply
* Re: what happend with hwclock patches?
From: Karel Zak @ 2007-03-07 10:42 UTC (permalink / raw)
To: David Brownell; +Cc: List util-linux-ng
In-Reply-To: <200703062006.27793.david-b@pacbell.net>
On Tue, Mar 06, 2007 at 08:06:27PM -0800, David Brownell wrote:
> See
> http://bugzilla.kernel.org/show_bug.cgi?id=8138
Thanks for this link. The patch is not applied yet. Maybe I should
release a snapshot (at least) with urgent things like hwclock or some
mount patches.
But I think you should ask downstream (your distribution) maitainer
to apply these kind of patches. They have pretty stable util-linux
packages now. I'll need few weeks to prepare useful util-linux-ng release.
(I'm going to add the patch to Fedora tree.)
> I see there's a GIT archive but you don't seem to have merged the patch I sent
> you back in November ... and the GIT tree doesn't show any active development,
> no commits except syncing to old releases.
Please, don't use broken gitweb at kernel.org or use it very carefully.
There is active development, see "log" in the devel branch:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=log;h=devel
Number of applied patches:
$ git rev-list --pretty=oneline devel ^master | wc -l
52
Number of patches in queue:
$ ls util-* | wc -l
49
The good news is that I have more time and I work on that full time
now.
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Pádraig Brady @ 2007-02-15 15:04 UTC (permalink / raw)
To: Karel Zak; +Cc: Christian Schlotter, util-linux-ng
In-Reply-To: <20070215141835.GH3925@petra.dvoda.cz>
Karel Zak wrote:
> On Thu, Feb 15, 2007 at 01:31:20PM +0000, Pádraig Brady wrote:
>
>> Sorry I missed the original mail/patch.
>> Can you send again?
>
> There is a small display error when using cal from util-linux-2.13-pre7
> with the command line "cal -3m". On Sep 27th 2006 it produced the
> following output (Sep 27th is highlighted):
>
> August 2006 September 2006 October 2006
> Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su
> 1 2 3 4 5 6 1 2 3 1
> 7 8 9 10 11 12 13 4 5 6 7 8 9 10 2 3 4 5 6 7 8
> 14 15 16 17 18 19 20 11 12 13 14 15 16 17 9 10 11 12 13 14 15
> 21 22 23 24 25 26 27 18 19 20 21 22 23 24 16 17 18 19 20 21 22
> 28 29 30 31 25 26 27 28 29 30 23 24 25 26 27 28 29
> 30 31
>
> As one can see, the second but last row of October is misaligned because
> the characters used for highlighting are not taken into account when
> aligning the last line of September.
Yes, that is exactly the issue my patch fixes.
Pádraig.
^ permalink raw reply
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Pádraig Brady @ 2007-02-15 15:03 UTC (permalink / raw)
To: Karel Zak; +Cc: Christian Schlotter, util-linux-ng
In-Reply-To: <20070215144938.GI3925@petra.dvoda.cz>
Karel Zak wrote:
> On Thu, Feb 15, 2007 at 01:31:20PM +0000, Pádraig Brady wrote:
>> Karel Zak wrote:
>>> Hi Christian,
>>>
>>> some ideas from your patch are really good, but the rest is not so
>>> perfect after all.
>> Sorry I missed the original mail/patch.
>> Can you send again?
>
> Done.
>
>> For reference I did the "highlight today" functionality
>> in cal a couple of years back which has alignment issues,
>> and have been trying to get the fix in since then:
>> http://www.pixelbeat.org/patches/cal-2.12q-highlight.diff
>
> This patch is already in my mail box ;-)
>
> Well, Christian's patch is more about code refactoring rather than
> about simple bug fix only. (It might good idea to cleanup the code.)
Yes the code can definitely be refactored.
I was wary of changing format though when I looked at it,
in case I broke scripts depending on whitespace etc.
>
>> Incidentally I also fixed the weekday alignment for
>> multibyte locales in the changes I did a couple of years ago
>
> There is also other multibyte fix (by RH):
>
> http://people.redhat.com/kzak/util-linux/util-linux-2.12p-cal-wide.patch
>
> My plan is write some regression tests for the "cal" before playing
> with these patches.
I used the following 2 scripts to test my changes:
[ ! -e "./cal" ] && CAL=cal || CAL=./cal
LANG=ga_IE.utf8 $CAL -3 11 2004 #truncation (first month)
LANG=zh_HK.utf8 $CAL -3 #multibyte centering
$CAL | cat #no highlight
TERM= $CAL #no highlight
TERM=vt100 $CAL #highlight, with characters to be stripped by putp
$CAL -y | head | tr ' ' . #3 spaces between cols?
$CAL -3 | tr ' ' . #2 spaces between cols and trailing spaces?
locale -a |
grep utf8 |
uniq -w2 |
while read LANG; do
cal -3 |
head -2 | tail -1;
done
Pádraig
^ permalink raw reply
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Karel Zak @ 2007-02-15 14:49 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Christian Schlotter, util-linux-ng
In-Reply-To: <45D460A8.7080409@draigBrady.com>
On Thu, Feb 15, 2007 at 01:31:20PM +0000, Pádraig Brady wrote:
> Karel Zak wrote:
> > Hi Christian,
> >
> > some ideas from your patch are really good, but the rest is not so
> > perfect after all.
>
> Sorry I missed the original mail/patch.
> Can you send again?
Done.
> For reference I did the "highlight today" functionality
> in cal a couple of years back which has alignment issues,
> and have been trying to get the fix in since then:
> http://www.pixelbeat.org/patches/cal-2.12q-highlight.diff
This patch is already in my mail box ;-)
Well, Christian's patch is more about code refactoring rather than
about simple bug fix only. (It might good idea to cleanup the code.)
> Incidentally I also fixed the weekday alignment for
> multibyte locales in the changes I did a couple of years ago
There is also other multibyte fix (by RH):
http://people.redhat.com/kzak/util-linux/util-linux-2.12p-cal-wide.patch
My plan is write some regression tests for the "cal" before playing
with these patches.
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Karel Zak @ 2007-02-15 14:18 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Christian Schlotter, util-linux-ng
In-Reply-To: <45D460A8.7080409@draigBrady.com>
On Thu, Feb 15, 2007 at 01:31:20PM +0000, Pádraig Brady wrote:
> Sorry I missed the original mail/patch.
> Can you send again?
There is a small display error when using cal from util-linux-2.13-pre7
with the command line "cal -3m". On Sep 27th 2006 it produced the
following output (Sep 27th is highlighted):
August 2006 September 2006 October 2006
Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su
1 2 3 4 5 6 1 2 3 1
7 8 9 10 11 12 13 4 5 6 7 8 9 10 2 3 4 5 6 7 8
14 15 16 17 18 19 20 11 12 13 14 15 16 17 9 10 11 12 13 14 15
21 22 23 24 25 26 27 18 19 20 21 22 23 24 16 17 18 19 20 21 22
28 29 30 31 25 26 27 28 29 30 23 24 25 26 27 28 29
30 31
As one can see, the second but last row of October is misaligned because
the characters used for highlighting are not taken into account when
aligning the last line of September.
This patch fixes the erroneous display by adopting the style of the
yearly(...) function. The patch also removes one unused variable "len"
and unifies the amount of whitespace used for separating two month
displays.
Signed-off-by: Christian Schlotter <schlotter@users.sourceforge.net>
---
misc-utils/cal.c | 124
+++++++++++++++++++++++++-----------------------------
1 files changed, 57 insertions(+), 67 deletions(-)
diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 339a610..9719c12 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -232,7 +232,7 @@ void yearly(int, int);
void j_yearly(int, int);
void do_monthly(int, int, int, struct fmt_st*);
void monthly(int, int, int);
-void monthly3(int, int, int);
+void monthly3(int, int, int, const int);
void trim_trailing_spaces(char *);
void usage(void);
void headers_init(void);
@@ -245,6 +245,7 @@ main(int argc, char **argv) {
int ch, day, month, year, yflag;
char *progname, *p;
int num_months = NUM_MONTHS;
+ const int show_year = 1;
progname = argv[0];
if ((p = strrchr(progname, '/')) != NULL)
@@ -347,7 +348,7 @@ main(int argc, char **argv) {
if (month && num_months == 1)
monthly(day, month, year);
else if (month && num_months == 3)
- monthly3(day, month, year);
+ monthly3(day, month, year, show_year);
else if (julian)
j_yearly(day, year);
else
@@ -424,7 +425,7 @@ void headers_init(void)
void
do_monthly(int day, int month, int year, struct fmt_st *out) {
- int col, row, len, days[MAXDAYS];
+ int col, row, days[MAXDAYS];
char *p, lineout[FMT_ST_CHARS];
int width = (julian ? J_WEEK_LEN : WEEK_LEN) - 1;
@@ -436,7 +437,7 @@ do_monthly(int day, int month, int year, struct
fmt_st *out) {
* Basque the translation should be: "%2$dko %1$s", and
* the Vietnamese should be "%s na(m %d", etc.
*/
- len = sprintf(lineout, _("%s %d"), full_month[month - 1], year);
+ sprintf(lineout, _("%s %d"), full_month[month - 1], year);
center_str(lineout, out->s[0], SIZE(out->s[0]), width);
sprintf(out->s[1],"%s",
@@ -466,46 +467,62 @@ monthly(int day, int month, int year) {
}
void
-monthly3(int day, int month, int year) {
- char lineout[FMT_ST_CHARS];
- int i;
- int width;
- struct fmt_st out_prev;
- struct fmt_st out_curm;
- struct fmt_st out_next;
- int prev_month, prev_year;
- int next_month, next_year;
-
+monthly3(int day, int month, int year, const int show_year) {
+ char *p, lineout[FMT_ST_CHARS], head[FMT_ST_CHARS / 3];
+ int *dp, days[3][MAXDAYS], months[3], years[3], row, col, i;
+ const int week_len = (julian) ? J_WEEK_LEN : WEEK_LEN;
+ const int head_sep = (julian) ? J_HEAD_SEP : HEAD_SEP;
+ const char * const headings = (julian) ? j_day_headings : day_headings;
+
+ /* previous, current and next month/year */
if (month == 1) {
- prev_month = 12;
- prev_year = year - 1;
+ months[0] = 12;
+ years[0] = year - 1;
} else {
- prev_month = month - 1;
- prev_year = year;
+ months[0] = month - 1;
+ years[0] = year;
}
+ months[1] = month;
+ years[1] = year;
if (month == 12) {
- next_month = 1;
- next_year = year + 1;
+ months[2] = 1;
+ years[2] = year + 1;
} else {
- next_month = month + 1;
- next_year = year;
+ months[2] = month + 1;
+ years[2] = year;
}
- do_monthly(day, prev_month, prev_year, &out_prev);
- do_monthly(day, month, year, &out_curm);
- do_monthly(day, next_month, next_year, &out_next);
- width = (julian ? J_WEEK_LEN : WEEK_LEN) -1;
- for (i = 0; i < 2; i++)
- printf("%s %s %s\n", out_prev.s[i], out_curm.s[i], out_next.s[i]);
- for (i = 2; i < FMT_ST_LINES; i++) {
- snprintf(lineout, SIZE(lineout), "%-*s %-*s %-*s\n",
- width, out_prev.s[i],
- width, out_curm.s[i],
- width, out_next.s[i]);
+ memset(lineout, ' ', sizeof(lineout) - 1);
+ lineout[sizeof(lineout) - 1] = '\0';
+
+ for (i = 0; i < 3; i++) {
+ day_array(day, months[i], years[i], days[i]);
+ if (show_year) {
+ snprintf(head, sizeof(head), _("%s %d"),
+ full_month[months[i] - 1], years[i]);
+ } else {
+ snprintf(head, sizeof(head), _("%s"),
+ full_month[months[i] - 1]);
+ }
+ center(head, week_len, (i == 2) ? 0 : head_sep);
+ }
+ printf("\n%s%*s %s%*s %s\n", headings, head_sep, "", headings,
+ head_sep, "", headings);
+ for (row = 0; row < 6; row++) {
+ p = lineout;
+ for (i = 0; i < 3; i++) {
+ dp = &days[i][row * 7];
+ for (col = 0; col < 7; col++) {
+ p = ascii_day(p, *dp++);
+ }
+ p += sprintf(p, " ");
+ }
+ *p = '\0';
+ trim_trailing_spaces(lineout);
#if defined(HAVE_NCURSES) || defined(HAVE_LIBTERMCAP)
- my_putstring(lineout);
+ my_putstring(lineout);putchar('\n');
#else
- fputs(lineout,stdout);
+ puts(lineout);
#endif
}
}
@@ -546,47 +563,20 @@ j_yearly(int day, int year) {
#endif
}
}
- printf("\n");
}
void
yearly(int day, int year) {
- int col, *dp, i, month, row, which_cal;
- int days[12][MAXDAYS];
- char *p, lineout[100];
+ int month;
+ char lineout[100];
+ const int show_year = 0;
sprintf(lineout, "%d", year);
center(lineout, WEEK_LEN * 3 + HEAD_SEP * 2, 0);
printf("\n\n");
- for (i = 0; i < 12; i++)
- day_array(day, i + 1, year, days[i]);
- memset(lineout, ' ', sizeof(lineout) - 1);
- lineout[sizeof(lineout) - 1] = '\0';
- for (month = 0; month < 12; month += 3) {
- center(full_month[month], WEEK_LEN, HEAD_SEP);
- center(full_month[month + 1], WEEK_LEN, HEAD_SEP);
- center(full_month[month + 2], WEEK_LEN, 0);
- printf("\n%s%*s %s%*s %s\n", day_headings, HEAD_SEP,
- "", day_headings, HEAD_SEP, "", day_headings);
- for (row = 0; row < 6; row++) {
- p = lineout;
- for (which_cal = 0; which_cal < 3; which_cal++) {
- dp = &days[month + which_cal][row * 7];
- for (col = 0; col < 7; col++)
- p = ascii_day(p, *dp++);
- p += sprintf(p, " ");
- }
- *p = '\0';
- trim_trailing_spaces(lineout);
-#if defined(HAVE_NCURSES) || defined(HAVE_LIBTERMCAP)
- my_putstring(lineout);putchar('\n');
-#else
- puts(lineout);
-#endif
- }
- }
- printf("\n");
+ for (month = 0; month < 12; month += 3)
+ monthly3(day, month + 2, year, show_year);
}
/*
--
1.4.4.2
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply related
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Pádraig Brady @ 2007-02-15 13:31 UTC (permalink / raw)
To: Karel Zak; +Cc: Christian Schlotter, util-linux-ng
In-Reply-To: <20070215130303.GG3925@petra.dvoda.cz>
Karel Zak wrote:
> Hi Christian,
>
> some ideas from your patch are really good, but the rest is not so
> perfect after all.
Sorry I missed the original mail/patch.
Can you send again?
For reference I did the "highlight today" functionality
in cal a couple of years back which has alignment issues,
and have been trying to get the fix in since then:
http://www.pixelbeat.org/patches/cal-2.12q-highlight.diff
Incidentally I also fixed the weekday alignment for
multibyte locales in the changes I did a couple of years ago.
Pádraig.
^ permalink raw reply
* Re: [PATCH] cal: Output unaligned with "-3" option and libtermcap
From: Karel Zak @ 2007-02-15 13:03 UTC (permalink / raw)
To: Christian Schlotter; +Cc: util-linux-ng
In-Reply-To: <45868535.5030402@users.sourceforge.net>
Hi Christian,
some ideas from your patch are really good, but the rest is not so
perfect after all.
On Mon, Dec 18, 2006 at 01:10:29PM +0100, Christian Schlotter wrote:
> +monthly3(int day, int month, int year, const int show_year) {
> - do_monthly(day, prev_month, prev_year, &out_prev);
> - do_monthly(day, month, year, &out_curm);
> - do_monthly(day, next_month, next_year, &out_next);
This is basic idea of the old monthly3() implementation and I think
it's definitely good idea. There must be only one place
(= do_monthly()) where we generate output for months.
> - width = (julian ? J_WEEK_LEN : WEEK_LEN) -1;
> - for (i = 0; i < 2; i++)
> - printf("%s %s %s\n", out_prev.s[i], out_curm.s[i], out_next.s[i]);
> - for (i = 2; i < FMT_ST_LINES; i++) {
> - snprintf(lineout, SIZE(lineout), "%-*s %-*s %-*s\n",
> - width, out_prev.s[i],
> - width, out_curm.s[i],
> - width, out_next.s[i]);
> + memset(lineout, ' ', sizeof(lineout) - 1);
> + lineout[sizeof(lineout) - 1] = '\0';
> +
> + for (i = 0; i < 3; i++) {
> + day_array(day, months[i], years[i], days[i]);
> + if (show_year) {
> + snprintf(head, sizeof(head), _("%s %d"),
> + full_month[months[i] - 1], years[i]);
> + } else {
> + snprintf(head, sizeof(head), _("%s"),
> + full_month[months[i] - 1]);
> + }
> + center(head, week_len, (i == 2) ? 0 : head_sep);
> + }
Here you *duplicate* functionality from do_monthly(). I think a
better way will be add support for the "show_year" option to the
do_monthly() function.
Should be something like:
monthly3(int day, int month, int year, const int show_year) {
for (i = 0; i < 3; i++)
do_monthly(day, month[i], year[i], out[i], show_year);
}
> + my_putstring(lineout);putchar('\n');
Ah.., please, two lines:
my_putstring(lineout);
putchar('\n');
:-)
> yearly(int day, int year) {
> + for (month = 0; month < 12; month += 3)
> + monthly3(day, month + 2, year, show_year);
> }
Good idea.
yearly = 4 * monthly3
monthly3 = 3 * do_monthly
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Bryan Henderson @ 2006-12-25 22:50 UTC (permalink / raw)
To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng
In-Reply-To: <787b0d920612251203w3466e84elb9cb73d86004a177@mail.gmail.com>
>>> > tunelp -- obsolete (new PCs even lack the ports)
>>>
>>> Really? My one week old dell has it.
>
>I guess you got an older model. I just got a Dell XPS 400.
>
>no floppy drive
>no serial port
>no parallel port
>no PS/2 mouse port
>no PS/2 keyboard port
>
> ...
>
>You can shove the obsolete stuff into Fedora Extras.
These obsolete tools cost very little to have available on all Fedora
systems. And there are plenty of people using modern Fedora on
hardware that was made a few years ago.
--
Bryan Henderson San Jose, California
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Albert Cahalan @ 2006-12-25 20:03 UTC (permalink / raw)
To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng
In-Reply-To: <20061222102404.GU5971@petra.dvoda.cz>
On 12/22/06, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:
> > namei -- OK, though obscure and probably broken
>
> I have patches for this tool. I've played with it last week and
> it's not so bad tool. For example list all permission for a path:
>
> namei -m /usr/local/bin/cvscheck
> f: /usr/local/bin/cvscheck
> drwxr-xr-x /
> drwxr-xr-x usr
> drwxr-xr-x local
> drwxr-xr-x bin
> -rwxr-xr-x cvscheck
>
> I don't think it's so easily possible with an other tool.
The tool claims to let you know where you have too many
symlinks. I guess it could do that from one direction, but
the other direction requires knowledge of undocumented
kernel limits which have changed recently. The recursion
level just went from 5 to 8, and could change again.
> > pg -- old-timers from SysV are probably addicted
>
> removed from FC/RHEL and Suse, included in Debian
That's probably not nice of you.
> > whereis -- might make sense on Gentoo or BSD
>
> I often use it :-)
How? Unlike BSD, the OS isn't under /src.
> > cytune -- very obsolete hardware?
>
> ix86 alpha armv4l
Those are CPUs. The hardware in question is not a CPU.
It's a multi-port serial board.
> > raw -- obsolete
>
> Still supported by kernel. We have to keep it in the package.
>
> (My idea has been remove it from RHEL5, but there is
> still many enterprise users who require it. Things are moving
> slowly...)
Well make it spew warnings.
> > Lots of computers don't even have floppy drives anymore.
>
> and a lot of computers still have floppy drives...
...
> > tunelp -- obsolete (new PCs even lack the ports)
>
> Really? My one week old dell has it.
I guess you got an older model. I just got a Dell XPS 400.
no floppy drive
no serial port
no parallel port
no PS/2 mouse port
no PS/2 keyboard port
I got 7 USB ports instead, not counting ones on the
monitor or keyboard.
The obsolete parts are getting left off because people
haven't been using the ones they have. USB replaces
all of that obsolete crud, generally doing a better job.
You can shove the obsolete stuff into Fedora Extras.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Albert Cahalan @ 2006-12-22 17:38 UTC (permalink / raw)
To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng
In-Reply-To: <20061222102404.GU5971@petra.dvoda.cz>
On 12/22/06, Karel Zak <kzak@redhat.com> wrote:
> I think we can mark many of these utils as deprecated in 2.13 release
> and remove it in a future release (2.14). Maybe we can do
> something like
>
> ./configure --deprecated="list of wanted deprecated utils"
>
> it means default installation will be without these tools and
> nostalgic uses will be compile with the --deprecated option.
Can you get all the obsolete stuff into a separate RPM package?
Somebody might actually want tunelp or fdformat, but the vast
majority of us are totally uninterested.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Evan Hunt @ 2006-12-22 16:52 UTC (permalink / raw)
To: Karel Zak; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <20061222110352.GV5971@petra.dvoda.cz>
> Hmm... I can imagine faster things based on possition (so you call
> seek()) rather than on the serial number. But it's completely different
> topic.
Something like that is coming next, as a matter of fact. But yes,
different topic.
> And why we cannot use two tools for these two different jobs/formats?
Because it's an unnecessary duplication of code, because it's trivially
easy to have my tool run in a "look"-equivalent mode, and because I imagine
there may be some other shell script author out there in the world who's
been using "look" for this purpose for a long time and would be pleased
to find it suddenly having a smarter set of options.
> I really don't see any reason why we should merge these search tools
> to one monolithic tool. There's many different formats how you can
> organize your data and I think it's normal that we have separated
> tools for every format.
Then why not different tools for organizing it? Instead of using
"sort --ignore-case --dictionary-order --unique", why not have a
single-purpose "dictsort" tool to generate the input for "look"? ;)
I'm kidding, here, but my point is serious: Flexible tools that can
serve many purposes are better than inflexible ones that only serve
one, and if you have a flexible tool that serves your purpose equally
well or better, then there's no need to keep the inflexible ones around.
(I'm not sure this conversation still needs to be on the util-linux-ng
list, sorry if I'm hijacking it...)
Evan Hunt
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Mark Rosenstand @ 2006-12-22 14:50 UTC (permalink / raw)
To: Karel Zak; +Cc: Albert Cahalan, util-linux-ng
In-Reply-To: <20061222102404.GU5971@petra.dvoda.cz>
On Fri, 2006-12-22 at 11:24 +0100, Karel Zak wrote:
> On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:
>
> > arch -- OK, though people use uname
>
> we have tried remove it from FC, but many users still use it.
Perhaps it could spew a deprecation warning referring to uname so
current users can be spotted, and lead to removal long-term.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Ian Kent @ 2006-12-22 12:32 UTC (permalink / raw)
To: Karel Zak
Cc: Evan Hunt, Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <20061222080721.GS5971@petra.dvoda.cz>
On Fri, 2006-12-22 at 09:07 +0100, Karel Zak wrote:
> On Thu, Dec 21, 2006 at 11:45:53PM -0800, Evan Hunt wrote:
> >
> > > As far as I can see, "look" is basically a lame grep.
> > > Is this something we really need?
> >
> > However, you're right about it being lame. It only searches at the
> > beginning of the line, making it useless for files that are sorted on
> > different fields, can only deal with lexical ordering, etc.
>
> Yes, the definition of "look" is pretty exact. Who do you think that
> the tool should be work with any other type of files or with
> a different ordering ? Now, it seems like right tool for right job.
>
> > I'm fixing this, which is part of why I ended up in this conversation
> > in the first place; I want to put the improved version into miscutils.
> >
> > > more -- still better-known than "less", sadly
> >
> > Ah, a pet peeve of mine. :)
> >
> > Why doesn't the 'less' package just install 'more' as a link to 'less'?
>
> because some distributions have the 'more' command in the root
> filesystem (/bin) and the 'less' command in /usr/bin.
And because some people remember that stuff like this was done because
"/usr" may have been on a separate partition and this was the place to
put binaries that depended on a larger number of libraries, usually also
in "/usr/lib". Then in recovery situations such as single user mode only
"/" would be mounted. Same story with "/bin/sh" of course.
Those days may be behind us but I still think we should be able to boot
a minimal root filesystem for recovery, but perhaps I'm just old
fashioned.
> But yes, I agree that the 'more' should be die in some future release.
>
> Karel
>
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-22 11:03 UTC (permalink / raw)
To: Evan Hunt; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <20061222084521.GB10592@armory.com>
On Fri, Dec 22, 2006 at 12:45:21AM -0800, Evan Hunt wrote:
> ...and so on. Now, if that file grows very large, it would be useful
> to be able to rapidly search it based on the serial number, e.g.,
> something like this:
> $ search -n -t: -k3 97273 <filename>
Hmm... I can imagine faster things based on possition (so you call seek()) rather
than on the serial number. But it's completely different topic.
> So I've finally gotten around to writing such a tool, and I'm calling
> it "search" or "bs" (for "binary search") or something along those lines.
No problem.
> But I figured, well, it's almost identical to "look" when called without
> arguments, so why not just supplant the existing "look"? If it's invoked
> as "look <word>", then it looks up the word in /usr/share/dict/words; if
> it's invoked as "search -args <word> <filename>" then it's a general-
> purpose binary search tool.
And why we cannot use two tools for these two different jobs/formats?
I really don't see any reason why we should merge these search tools
to one monolithic tool. There's many different formats how you can
organize your data and I think it's normal that we have separated
tools for every format.
It really doesn't make sense merge it with 'look' if the 'look' is
stupid and simple tool how search in data in files in
sort --ignore-case --dictionary-order | uniq
format.
Karel "stubborn" ;-)
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-22 10:24 UTC (permalink / raw)
To: Albert Cahalan; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng
In-Reply-To: <787b0d920612212212s1ca3179jf037fc71f3f28498@mail.gmail.com>
On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:
> On 12/21/06, Karel Zak <kzak@redhat.com> wrote:
>
> >> problem, since there are people who are willing to maintain some
> >> pieces, but less energetic about maintaining the entire package or
> >> working through a central bureaucracy.
> >
> > I don't see any problem collaborate with more people.
>
> Power sharing is difficult.
Oh.. yes. Good things are difficult :-)
> I see rdev. If I remember right, that's used for the pre-2.6 kernels
I'm not 100% if wee still need it, but RH and Suse still have
rdev for ix86.
rdev = ramsize, rootflags and vidmode (all is implemented in rdev.c)
> Lots of computers don't even have floppy drives anymore.
and a lot of computers still have floppy drives...
> arch -- OK, though people use uname
we have tried remove it from FC, but many users still use it.
> chkdupexe -- OK, though obscure
removed from in FC/RHEL, included in Suse and Debian
> ddate -- pure junk
yes, strange tool
> line -- people use read
removed from in FC/RHEL, included in Suse and Debian
> namei -- OK, though obscure and probably broken
I have patches for this tool. I've played with it last week and
it's not so bad tool. For example list all permission for a path:
namei -m /usr/local/bin/cvscheck
f: /usr/local/bin/cvscheck
drwxr-xr-x /
drwxr-xr-x usr
drwxr-xr-x local
drwxr-xr-x bin
-rwxr-xr-x cvscheck
I don't think it's so easily possible with an other tool.
> pg -- old-timers from SysV are probably addicted
removed from FC/RHEL and Suse, included in Debian
> whereis -- might make sense on Gentoo or BSD
I often use it :-)
> cytune -- very obsolete hardware?
ix86 alpha armv4l
> elvtune -- useful
removed from FC/RHEL, included in Suse, Debian
elvtune is only useful on older kernels, 2.6 use IO scheduler and
sysfs tunables. So deprecated tool.
> fdformat -- for nostalgia?
No, I have feedback that people use it. FC/RHEL also includes
http://floppyutil.sourceforge.net/ that supports IDE floppies too.
> fsck.minix -- for the retro-computing crowd
removed from FC/RHEL, included in Suse, Debian
> getty -- might get used on servers for serial consoles (*)
agetty
> isosize -- belongs with mkisofs, not in util-linux
probably yes
> mkfs.minix -- for the retro-computing crowd
removed from FC/RHEL, included in Suse, Debian
> raw -- obsolete
Still supported by kernel. We have to keep it in the package.
(My idea has been remove it from RHEL5, but there is
still many enterprise users who require it. Things are moving
slowly...)
> tunelp -- obsolete (new PCs even lack the ports)
Really? My one week old dell has it.
There is more odd utils:
newgrp - broken, there is better version in shadow-utils
(but the version in shadow-utils is broken too. I fixed it one year
ago, but the patch is in FC/RHEL only :-( Need discussion with
shadow-utils upstream.
sln - removed from FC/RHEL and Debian, included in Suse
(new version is in glibc)
shutdown - removed from all dists (new version for example in
SysVinit)
wall - included in Suse (new version in SysVinit)
scriptreplay - Perl script ;-( I'm going to rewrite to C. The
dependence on Perl is ugly for basic system package.
last - probably removed from all dists (new version in SysVinit)
I think we can mark many of these utils as deprecated in 2.13 release
and remove it in a future release (2.14). Maybe we can do
something like
./configure --deprecated="list of wanted deprecated utils"
it means default installation will be without these tools and
nostalgic uses will be compile with the --deprecated option.
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Albert Cahalan @ 2006-12-22 9:06 UTC (permalink / raw)
To: Bryan Henderson; +Cc: kzak, ethanol, ams, P, util-linux-ng
In-Reply-To: <60569.bryanh@giraffe-data.com>
On 22 Dec 2006 07:13:47 +0000, Bryan Henderson <bryanh@giraffe-data.com> wrote:
> >I see rdev. If I remember right, that's used for the pre-2.6 kernels
> >when you use "dd" to put a raw kernel image on a floppy.
>
> Yeah, that's classic Unix. I don't think it was ever actually used
> much for floppy disks, because you can also just put a filesystem and
> LILO on a floppy; that's what I've always done. I didn't know they
> eliminated the integrated boot loader in 2.6.
My memory of rdev is dim, but I sure do remember putting the kernel
right on the floppy.
The compressed kernel was less than 400 kB.
That allowed for a compressed RAM disk of 1 MB.
I'd place the compressed RAM disk image at an
offset of 400 kB, then somehow indicate this to
the kernel. Maybe it was in the header, but maybe
it was a compile option.
None of this busybox nonsense of course... just
grab regular stuff from /bin and /lib, any file from /etc
that wasn't obviously useless, a real /dev... but then
along came big bad libc 6.
Anyway... this stuff is no longer useful at all.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Evan Hunt @ 2006-12-22 8:45 UTC (permalink / raw)
To: Karel Zak; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <20061222080721.GS5971@petra.dvoda.cz>
> Yes, the definition of "look" is pretty exact. Who do you think that
> the tool should be work with any other type of files or with
> a different ordering ? Now, it seems like right tool for right job.
It works well for looking up words in a dictionary file. It doesn't work
very well for looking up lines in a flat-file database.
Consider a flat file like the following, each line containing a name,
a serial number, and some additional information. Each time a new
transaction comes in, the serial number is incremented and a record
is added to the end of the file:
John:White:1:...
Mary:Brown:2:...
Fred:Green:3:...
...and so on. Now, if that file grows very large, it would be useful to
be able to rapidly search it based on the serial number, e.g., something
like this:
$ search -n -t: -k3 97273 <filename>
Right now, the closest you can get to this with a standard unix or linux
tool is to use "look", but that only works if the serial number is the
first field of the file... and even then it doesn't work very well, because
the file has to be lexically sorted, so the serial numbers would all have
to be padded to the same length with leading zeroes. It's faster than
using awk or grep, but it's a hassle.
I must have written a dozen shell scripts over the years that would have
been faster and easier to write if a tool like this had existed, and I
can't be the only one...
So I've finally gotten around to writing such a tool, and I'm calling
it "search" or "bs" (for "binary search") or something along those lines.
But I figured, well, it's almost identical to "look" when called without
arguments, so why not just supplant the existing "look"? If it's invoked
as "look <word>", then it looks up the word in /usr/share/dict/words; if
it's invoked as "search -args <word> <filename>" then it's a general-
purpose binary search tool.
I'm still playing with it, but I plan to have it ready to contribute in
another few days.
Evan Hunt
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-22 8:07 UTC (permalink / raw)
To: Evan Hunt; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <20061222074553.GA18589@armory.com>
On Thu, Dec 21, 2006 at 11:45:53PM -0800, Evan Hunt wrote:
>
> > As far as I can see, "look" is basically a lame grep.
> > Is this something we really need?
>
> However, you're right about it being lame. It only searches at the
> beginning of the line, making it useless for files that are sorted on
> different fields, can only deal with lexical ordering, etc.
Yes, the definition of "look" is pretty exact. Who do you think that
the tool should be work with any other type of files or with
a different ordering ? Now, it seems like right tool for right job.
> I'm fixing this, which is part of why I ended up in this conversation
> in the first place; I want to put the improved version into miscutils.
>
> > more -- still better-known than "less", sadly
>
> Ah, a pet peeve of mine. :)
>
> Why doesn't the 'less' package just install 'more' as a link to 'less'?
because some distributions have the 'more' command in the root
filesystem (/bin) and the 'less' command in /usr/bin.
But yes, I agree that the 'more' should be die in some future release.
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-22 7:52 UTC (permalink / raw)
To: Bryan Henderson; +Cc: ethanol, ams, P, acahalan, util-linux-ng
In-Reply-To: <42767.bryanh@giraffe-data.com>
On Fri, Dec 22, 2006 at 06:44:21AM +0000, Bryan Henderson wrote:
> > That's not 100% true. You need upstream and downstream maintainer for
> > every package. You need an infrastructure (scm, mailing list, ...)
> > for every package. Maybe it seems like something simple (10 clicks at
> > sf.net), but my experience is completely different. Maintainig is
> > really boring work and after few months nobody wants to do it...
> >
> > Number of well maintained packages is not so big. Believe me, people
> > who work on Linux distributions fight with unmaintained projects every
> > day.
>
> If you're willing to do all that work for all of the components of
> util-linux, or alternatively if most of the components simply don't
> require any maintenance, then the labor-distributing advantage of
> splitting isn't there. And you've obviously determined that you can
Yes.
> distribute one big package more easily than lots of little ones
> (myself, I've found the opposite -- I split things up into independent
> parts so that I can release in smaller doses).
Frankly, maybe 90% of utils in util-linux needn't any real development or
fixing. These utils are stable for really long time.
My experience (last two years) is that almost all bug reports are
about the mount/losetup, login, fdisk and man pages. Also the
problematic part of the package is NFS code -- but it will be removed
to nfs-utils (already done in FC6/RHEL5).
For example list of patches from Fedora Core 6:
floppy-0.12-locale.patch
util-linux-2.11y-chsh-103004.patch
util-linux-2.11y-fdisksegv-103954.patch
util-linux-2.11y-multibyte.patch
util-linux-2.11y-procpartitions-37436.patch
util-linux-2.11y-skipraid2.patch
util-linux-2.12a-126572-fdiskman.patch
util-linux-2.12a-16415-rdevman.patch
util-linux-2.12a-ipcs-84243-86285.patch
util-linux-2.12a-mountbylabel-dm.patch
util-linux-2.12a-mount-man-cifs.patch
util-linux-2.12a-pamsession.patch
util-linux-2.12a-pamstart.patch
util-linux-2.12a-partlimit.patch
util-linux-2.12j-113790-hotkeys.patch
util-linux-2.12j-managed.patch
util-linux-2.12j-pamconsole.patch
util-linux-2.12p-cal-wide.patch
util-linux-2.12p-col-EILSEQ.patch
util-linux-2.12p-execl.patch
util-linux-2.12p-fdformat-ide.patch
util-linux-2.12p-floppy-generic.patch
util-linux-2.12p-fstab-man.patch
util-linux-2.12p-ipcs-typo.patch
util-linux-2.12p-login-lastlog.patch
util-linux-2.12p-look-separator.patch
util-linux-2.12p-lvm2dupes-76467.patch
util-linux-2.12p-mount-ocfs2.patch
util-linux-2.12p-mtab-lock.patch
util-linux-2.12p-swaponsymlink-57300.patch
util-linux-2.12p-vipw-perm.patch
util-linux-2.13-arch.patch
util-linux-2.13-audit-hwclock.patch
util-linux-2.13-audit-login.patch
util-linux-2.13-cal-wide.patch
util-linux-2.13-cramfs-maxentries.patch
util-linux-2.13-cramfs-zerofiles.patch
util-linux-2.13-ctrlaltdel-man.patch
util-linux-2.13-ctty3.patch
util-linux-2.13-fdisk-b-4096.patch
util-linux-2.13-fdisk-gpt.patch
util-linux-2.13-fdisk-isfull.patch
util-linux-2.13-fdisk-sectors.patch
util-linux-2.13-hexdump-gcc.patch
util-linux-2.13-ipcs-shmax.patch
util-linux-2.13-login-hang.patch
util-linux-2.13-login-ipv6.patch
util-linux-2.13-login-pam-acct.patch
util-linux-2.13-login-timeval.patch
util-linux-2.13-losetup-all.patch
util-linux-2.13-losetup-deprecated.patch
util-linux-2.13-losetup-rdonly.patch
util-linux-2.13-mkswap-mounted.patch
util-linux-2.13-mkswap-selinux.patch
util-linux-2.13-more-CLOEXEC.patch
util-linux-2.13-moretc.patch
util-linux-2.13-mount-comment.patch
util-linux-2.13-mount-context.patch
util-linux-2.13-mount-man-bugs.patch
util-linux-2.13-mount-man-nfs4.patch
util-linux-2.13-mount-man-nfs.patch
util-linux-2.13-mount-move.patch
util-linux-2.13-mount-nonfs.patch
util-linux-2.13-mount-sloppy.patch
util-linux-2.13-mount-subtree.patch
util-linux-2.13-mount-twiceloop.patch
util-linux-2.13-mount-uhelper.patch
util-linux-2.13-mount-uuid.patch
util-linux-2.13-namei-logic.patch
util-linux-2.13-rmparts.patch
util-linux-2.13-schedutils-man.patch
util-linux-2.13-schedutils-SCHED_BATCH.patch
util-linux-2.13-swapon-suspend.patch
util-linux-2.13-swap-page.patch
util-linux-2.13-umount-sysfs.patch
[Not all will be ever merged with upstream of course, there're RH
specific patches too]
Karel
--
Karel Zak <kzak@redhat.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox