This bug has been fixed with the upstream release (some days ago) of
man-pages-5.09, which now provides a kernel_lockdown.7 page.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1767971
Title:
No such
Upstream maintainer here. Yes, the currently released upstream manual
page is out of date. But this is rectified already for the next upstream
release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/180
On 21 February 2016 at 13:56, Rolf Leggewie <311...@bugs.launchpad.net> wrote:
>> In reply to the initial report:
>>
>> > 'locale' prints not only the values of LC_*, but also LANG and LANGUAGE.
>>
>> Does it really do this on Ubuntu?
>
> Yes, it does.
>
> $ locale
> LANG=de_DE.UTF-8
> LANGUAGE="de
E. These variables should be appropriately documented in the
> manpage.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/311558/+subscriptions
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pa
In reply to the initial report:
> 'locale' prints not only the values of LC_*, but also LANG and
LANGUAGE.
Does it really do this on Ubuntu? On my Fedora system, locale(1)
displays LANG, but not LANGUAGE. This is consistent with the fact that
LANGUAGE is gettext-specific, as I understand it.
--
Regarding the initial report:
[[
It would be nice to have the manpage of setlocale updated to declare that the
env variable "LANGUAGE" will be read to get the language. It should also state
that the variable LANGUAGE will be the first one (before LC_ALL or LANG).
]]
This appears incorrect to me
The point here is that /etc/environment is a pam_env(8) thing. The
pam_env(8) page documents /etc/environment, but users can't easily
discover that information. There needs to me a man page "link" ,
environmen(5), that points to pam_env(8). I filed this report to get
that fixed:
https://fedorahost
On 04/22/2015 11:02 AM, Michael Kerrisk (man-pages) wrote:
> Hi Stéphane
>
> On 04/22/2015 02:32 AM, Stéphane Aulery wrote:
>> ** Patch added: "0003-resolv.conf.5-document-RES_SNGLKUPREOP.patch"
>>
>> https://bugs.launchpad.net/ubuntu/+source/manpages/+b
It's not clear to me whether you want me to do something here.
Maybe I just get this message because I'm auto subscribed to
the Ubuntu man pages BTS...
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programm
Upstream man-pages maintainer here. This seems to me a man-pages
problem, and I've change the relevant text in the man page to:
mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9
chown root:root /dev/random /dev/urandom
--
You received this bug notifi
Upstream maintainer here.
Regarding the /proc/PID/stat, you need to upgrade your man-pages. An
update to man-pages in May 2014 added documentation for these fields.
Likewise VmSwap in /proc/PID/status is already documented in recent man-
pages.
(See http://man7.org/linux/man-pages/man5/proc.5.ht
Upsteam maintainer here. This report does not seem to be correct. The
ffs(3) page does not make this claim, and I'm not sure that it ever did.
The SYNOPSIS shows that including is needed for ffsl () and
ffsll(). (and _GNU_SOURCE must also be defined).
--
You received this bug notification becau
ccurate queues_max hard limit (INT_MAX instead of 1024) at least as
> of Ubuntu 13.10.
Yes, it's been on my long TODO list to follow this up. Doc will get fixed,
and I hope the kernel too. Tell me, was this limitation the reason to
abandon PMQs?
--
Michael Kerrisk
Linux
I've applied the following patch upstream:
diff --git a/man5/proc.5 b/man5/proc.5
index efb402d..3acf867 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -1198,13 +1198,9 @@ instead.
.TP
\fIwchan\fP %lu
(35) This is the "channel" in which the process is waiting.
-It is the
-address of a system cal
The example is okay. The text preceding that example says:
The following example reads multiple **single-byte** elements from the
fp stream into the array pointed to by buf.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
*** This bug has been marked as a duplicate of bug 1481 ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/121768
Title:
manpage for ld.so mistake
To manage notifications about this bug go to:
https
(In reply to Matthias Klose from comment #0)
> [forwarded from https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/121768]
>
> the ld.so manpage says for option LD_DEBUG_OUTPUT that the default value is
> standard output, when in fact it is standard error.
I've amended the ld.so man page to fix
> However, it unfortunately does not fix the issue.
> sysctl still cannot be used to raise the message
> queue limit above 1024. Given this, ipc_ns->mq_queues_max
> is still initialized to DFLT_QUEUESMAX (256) and
> ultimately limited by HARD_QUEUESMAX (1024),
> even if that's not being tested
Arto, it's the simple fix, but before I push it further, does the
attached patch fix your problem?
At this point (ii.e., since LInux 3.8), I suspect that the limit that
the kernel code currently tries to enforce on queues_max is anyway
meaningless. Unprivileged users can nowadays use
clone(CLONE_
ad. Not a happy day...
Arto, I don't think you should be doing that. The upstream kernel
broke user space here, and I am sure that was not intended. I would
imagine that an upstream fix that repairs your problem would probably
be accepted. How about we pursue that line instead?
--
Michae
Also:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=02967ea08ede0f8cc7e0526aedffdae65a099b07
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1155695
Title:
mq_overview(7) c
Arto, clearly the man-page needs some fixing, and I'll look into it.
But, I am curious. Did this change cause some real-world applications to
break?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/11556
Whoops. Hit post too soon on the last...
The change seems to be this ONE:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=93e6f119c0ce8a1bba6e81dc8dd97d67be360844
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
This appears to be the relavant change:
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1155695
Title:
mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max
limit description
To manage
This was fixed in upstream 3.46 release, commit
d4fd41208248a9c43eef300804dd3aff70eaa223
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1039260
Title:
proc(5) doesn't document all CPU values in /proc
So, it'd be good if someone had directed this to upstream man-pages. I
found this bug report by chance. I've made appropriate changes for the
upcoming man-pages-3.42.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
Was fixed in upstream man-pages-3.26 (Sep 2010)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/638023
Title:
Error in mq_send(3) man page
To manage notifications about this bug go to:
https://bugs.l
The problem has been resolved in glibc.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/189208
Title:
MNT_DETACH is missing in sys/mount.h
To manage notifications about this bug go to:
https://bugs.l
Has been fixed in upstream 3.36.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/897257
Title:
pipe(2,) int pipe2(int pipefd[2], int flags); needs #include
To manage notifications about this bug go
Upstream man-pages-3.41 patches as follows:
--- a/man3/syslog.3
+++ b/man3/syslog.3
@@ -66,6 +66,13 @@ opens a connection to the system logger for a program.
The string pointed to by
.I ident
is prepended to every message, and is typically set to the program name.
+If
+.I ident
+is NULL, the pr
The subject line in this report isn't correct. Read
http://man7.org/linux/man-pages/man7/feature_test_macros.7.html and the
header files carefull!y
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/791886
I belive the problem here is a misreading of the English text.
I changed the text slightly in upstream 3.41 from
EINTR The call was interrupted by a signal handler before any of the
requested events occurred or the timeout expired; see signal(7).
to
EINTR The call was interrupted
Upstream man-pages-3.41 will add a sentence that the driver was removed
in 2.6.26.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/528020
Title:
sk98lin man page should be removed
To manage notificat
@David T Chen
David, how did you confirm this bug? The reporter talks of behavior having been
changed (though as far as I can see, nothing has changed) -- did you confirm
that behavior was different in an earlier kernel version?
--
shmctl man differs from kernel operation
https://bugs.launchpad
@Hans Dietz:
Hans,
I'm the upstream man-pages maintainer, and I took a look at this bug
report to see if I should fix anything upstream.
You wrote:
[[
However, setting IPC_RMID in recent Linux kernels has the important side effect
of CHANGING the key associated with the segment to 0 (aka, IPC_
For what it's worth, I filed this glibc bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=10567
** Bug watch added: Sourceware.org Bugzilla #10567
http://sourceware.org/bugzilla/show_bug.cgi?id=10567
--
getaddrinfo manpage doesn't match glibc implementation when hints is NULL
https://bugs.l
Note that the reporter is marking a bug against the POSIX man page which
is taken straight from the standard. By definition, this page won't
describe glibc specifics.
I confirm that the reporter is correct in pointing out that glibc
deviates from the standard. (I don't know the reasons) The Linux
I think the problem rather lies in glibc. I filed this bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=10566
** Bug watch added: Sourceware.org Bugzilla #10566
http://sourceware.org/bugzilla/show_bug.cgi?id=10566
--
MNT_DETACH is missing in sys/mount.h
https://bugs.launchpad.net/bugs/189
38 matches
Mail list logo
