[Bug 1767971] Re: No such man page: kernel_lockdown.7
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 man page: kernel_lockdown.7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767971/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1804185] Re: glibc has statx support in 18.10, but the manpage claims otherwise
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/1804185 Title: glibc has statx support in 18.10, but the manpage claims otherwise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1804185/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 311558] Re: $LANG and $LANGUAGE not documented in locale manual page
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:en:jp" > LC_CTYPE="de_DE.UTF-8" > LC_NUMERIC=de_DE.UTF-8 > LC_TIME=de_DE.UTF-8 > LC_COLLATE="de_DE.UTF-8" > LC_MONETARY=de_DE.UTF-8 > LC_MESSAGES=C > LC_PAPER=de_DE.UTF-8 > LC_NAME=de_DE.UTF-8 > LC_ADDRESS=de_DE.UTF-8 > LC_TELEPHONE=de_DE.UTF-8 > LC_MEASUREMENT=de_DE.UTF-8 > LC_IDENTIFICATION=de_DE.UTF-8 > LC_ALL= Hmmm -- looking at the glibc sources, locale(1) does not appear to natively do this. I wonder if this a Debiab/Ubuntu specific patch? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/311558 Title: $LANG and $LANGUAGE not documented in locale manual page To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/311558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 311558] Re: $LANG and $LANGUAGE not documented in locale manual page
Hi Stéphane. See my reply into the bug. The reporter is confused. AFAIK, setlocale() ignores LANGUAGE. Cheers, Michael On 17 February 2016 at 00:51, Stéphane Aulery <lk...@free.fr> wrote: > Hi, > > 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). > > Thanks. > For the record, the bug #700213 describes a problem about that. > > [This comment is merged from Bug #872343, which is more or less a > duplicate.] > > -- > You received this bug notification because you are subscribed to > manpages in Ubuntu. > Matching subscriptions: mk-manpages > https://bugs.launchpad.net/bugs/311558 > > Title: > $LANG and $LANGUAGE not documented in locale manual page > > Status in eglibc package in Ubuntu: > Triaged > Status in manpages package in Ubuntu: > New > > Bug description: > Binary package hint: belocs-locales-bin > > 'locale' prints not only the values of LC_*, but also LANG and > LANGUAGE. 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-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/311558 Title: $LANG and $LANGUAGE not documented in locale manual page To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/311558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 311558] Re: $LANG and $LANGUAGE not documented in locale manual page
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/311558 Title: $LANG and $LANGUAGE not documented in locale manual page To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/311558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 872343] Re: setlocale should say that LANGUAGE is used before LANG
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. setlocale(3) is, as far as I know, ignorant of LANGUAGE. Only gettext(3) knows about LANGUAGE. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/872343 Title: setlocale should say that LANGUAGE is used before LANG To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/872343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 18574] Re: /etc/environment lacks man page.
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://fedorahosted.org/linux-pam/ticket/55 ** Bug watch added: fedorahosted.org/linux-pam/ #55 https://fedorahosted.org/linux-pam/ticket/55 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/18574 Title: /etc/environment lacks man page. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/18574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1110781] Re: resolv.conf(5) fails to mention some options
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/+bug/1110781/+attachment/4380888/+files/0003-resolv.conf.5-document-RES_SNGLKUPREOP.patch 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... Ahhh -- now I understand. You sent the patch separately. That's exactly right for me. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1110781 Title: resolv.conf(5) fails to mention some options To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1110781/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1110781] Re: resolv.conf(5) fails to mention some options
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/+bug/1110781/+attachment/4380888/+files/0003-resolv.conf.5-document-RES_SNGLKUPREOP.patch 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 Programming Training: http://man7.org/training/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1110781 Title: resolv.conf(5) fails to mention some options To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1110781/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1397652] Re: /dev/random and /dev/urandom world writeable
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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397652 Title: /dev/random and /dev/urandom world writeable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1397652/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1071746] Re: Missing information in proc(5)
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.html ) For VmPin, the documentation indeed was lacking, and I have added: * VmPin: Pinned memory size (since Linux 3.2). These are pages that can't be moved because something needs to directly access physical memory. Thanks, Michael -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1071746 Title: Missing information in proc(5) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1071746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 321339] Re: ffsl(3) not in strings.h like manpage says
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 string.h is needed for ffsl () and ffsll(). (and _GNU_SOURCE must also be defined). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/321339 Title: ffsl(3) not in strings.h like manpage says To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/321339/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
On 02/19/2014 11:01 AM, Arto Bendiken wrote: Just to follow up on this, we have since abandoned the use of POSIX message queues altogether so this issue is no longer an ongoing concern for us. Still, the mq_overview(7) man page continues to refer to the outdated, inaccurate 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 man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 737452] Re: man 5 proc has obsolete info
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 call, and can be looked up in a namelist if you -need a textual name. -(If you have an up-to-date -.IR /etc/psdatabase , -then -try \fIps \-l\fP to see the WCHAN field in action.) +It is the address of a location in the kernel where the process is sleeping. +The corresponding symbolic name can be found in +.IR /proc/[pid]/wchan . .TP \fInswap\fP %lu (36) @@ -1479,6 +1475,10 @@ directory are not available if the main thread has already terminated (typically by calling .BR pthread_exit (3)). .TP +.IR /proc/[pid]/wchan (since Linux 2.6.0) +The symbolic name corresponding to the location +in the kernel where the process is sleeping. +.TP .I /proc/apm Advanced power management version and battery information when .B CONFIG_APM -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/737452 Title: man 5 proc has obsolete info To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/737452/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 345062] Re: fread(3) man page EXAMPLES section is misleading
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://bugs.launchpad.net/bugs/345062 Title: fread(3) man page EXAMPLES section is misleading To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages-posix/+bug/345062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 121768]
*** 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://bugs.launchpad.net/glibc/+bug/121768/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 121768]
(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 this error. -- 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://bugs.launchpad.net/glibc/+bug/121768/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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 for directly in mqueue_create(). Arto, Sorry for the delayed follow up., The point of the patch was *not* to allow the sysctl to be changed. Rather, it was to allow a *privileged* process to override the limit. Is you DB engine running as a privileged process? If not, then I suppose a somewhat different patch is in order. -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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_NEWUSER|CLONE_NEWIPC) to create an arbitrary number of new IPC namespaces, each of which can be populated with queues_max MQs. So the hard limit check doesn't really limit users at all (though, as you've discovered, it does inconvenience them). ** Patch added: mqueue_limit.patch https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+attachment/3581440/+files/mqueue_limit.patch -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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/1155695 Title: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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 Ubuntu. https://bugs.launchpad.net/bugs/1155695 Title: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
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) contains outdated, inaccurate fs.mqueue.queues_max limit description To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1155695] Re: mq_overview(7) contains outdated, inaccurate fs.mqueue.queues_max limit description
On Sun, Mar 17, 2013 at 12:57 PM, Arto Bendiken a...@bendiken.net wrote: Michael, thanks for looking into this. In answer to your question: yes, it caused the IPC mechanism in the database engine my company develops (dydra.com) to break, causing not a little aggravation. While we don't need millions of message queues, we had been relying on having at least a few thousand, and 1024 is just too low a hard limit. As we can't possibly require a custom-built kernel to run our software, we are now contemplating switching from POSIX to SysV message queues instead. 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? -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1039260] Re: proc(5) doesn't document all CPU values in /proc/stat
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/stat To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1039260/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 874418] Re: linking against librt doesn't provide sem_post
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.launchpad.net/bugs/874418 Title: linking against librt doesn't provide sem_post To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/874418/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 528020] Re: sk98lin man page should be removed
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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/528020/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 480566] Re: epoll_wait man page error
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 by a signal handler before either any of the requested events occurred or the timeout expired; see signal(7). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/480566 Title: epoll_wait man page error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/480566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 791886] Re: _ISOC99_SOURCE should be __USE_ISOC99
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 Title: _ISOC99_SOURCE should be __USE_ISOC99 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/791886/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 382096] Re: syslog(3) doesn't cover openlog()'s ident being NULL
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 program name is used. +(POSIX.1-2008 does not specify the behavior when +.I ident +is NULL.) + The .I option argument specifies flags which control the operation of -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/382096 Title: syslog(3) doesn't cover openlog()'s ident being NULL To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/382096/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 897257] Re: pipe(2,) int pipe2(int pipefd[2], int flags); needs #include fcntl.h
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 fcntl.h To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/897257/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 189208] Re: MNT_DETACH is missing in sys/mount.h
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.launchpad.net/ubuntu/+source/manpages/+bug/189208/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 638023] Re: Error in mq_send(3) man page
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.launchpad.net/ubuntu/+source/manpages/+bug/638023/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 189208] Re: MNT_DETACH is missing in sys/mount.h
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/189208 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153571] Re: getaddrinfo manpage doesn't match glibc implementation when hints is NULL
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 man page documents the deviation: http://www.kernel.org/doc/man-pages/online/pages/man3/getaddrinfo.3.html -- getaddrinfo manpage doesn't match glibc implementation when hints is NULL https://bugs.launchpad.net/bugs/153571 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153571] Re: getaddrinfo manpage doesn't match glibc implementation when hints is NULL
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.launchpad.net/bugs/153571 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62858] Re: shmctl man differs from kernel operation
@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_PRIVATE). Ideally, this side effect should be removed from the kernel, but the kernel folks seem unlikely to do this (the new behavior was mentioned in a discussion). Thus, I suggest fixing the shmctl man page to mention this strange behavior in the discussion of IPC_RMID: after IPC_STAT will be set. add the phrase The segment key may be changed to IPC_PRIVATE as a side effect of IPC_RMID. ]] Your report suggests (in recent kernels) that the kernel's behavior changed at some point. As far as I can see, there has been no change from 2.2 through to 2.6.31-rc with respect to this particular point. The key was always changed to IPC_PRIVATE, so that some program could not do a shmget() with the original key in order to obtain the ID of the now deleted object. As far as I know, all other Unix systems take analogous steps (to prevent a deleted object being re-used). What is unusual about the Linux implementation (i.e., different from other systems) is this behavior described in the http://www.kernel.org/doc/man-pages/online/pages/man2/shmat.2.html man page: On Linux, it is possible to attach a shared memory segment even if it is already marked to be deleted. However, POSIX.1-2001 does not specify this behavior and many other implementations do not support it. However, again, this behavior is unchanged in Linux 2.2 to 2.6.31-rc, as far as I can see. So, at this point, it doesn't look like any change needs to be made to the man page. But, I await further input. Thanks, Michael -- shmctl man differs from kernel operation https://bugs.launchpad.net/bugs/62858 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 62858] Re: shmctl man differs from kernel operation
@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.net/bugs/62858 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
