| Request ID | Summary | Comments | ||
|---|---|---|---|---|
| 816006 | remove interfaces deprecated in 1.3 | Decision is to remove these interfaces deprecated in 1.3. (there's a duplicate at bugzilla 14. Database and cvs rm should be done. Need to verify in build for all of __dcgettext, alphasort, alphasort64, fstatfs, fstatfs64, gets, setmntent, statfs, statfs64, waitid, sethostent, and endhostent. Kingdon reviewed; looked OK except gets. gets should be gone; now is present. gets is in 1.9.0-20031126 build. Stuart thought he got rid of gets on 19 Nov. Stuart to keep fighting. | nobody | kingdon |
| 721173 | fgetwc_unlocked() is not in SUS | Kingdon checked in man pages for fgetwc_unlocked and fflush_unlocked. Stuart changed database (standard for these points to ourselves; that triggers looking for a manpage). Seems to be in 1.9.0-20031126 build. Kingdon to check more carefully after call. |
| Request ID | Summary | Comments | Assigned To | Submitted By |
|---|---|---|---|---|
| 32 | privileges may be required to sucessfully call pam_authenticate | The old api (getpwent) also would require privileges. Chris Yeoh to come up with wording. | ||
| 33 | pam_strerror return value incorrect | Why specify this string at all? Right now test suites test for this. Do we need to test what happens on invalid number? (more specifically than "no core dump"). Probably should leave the contents of the message unspecified. | ||
| 31 | Remove nice man page | New (POSIX) behavior is in recent glibc's. The text currently in the spec derived from PR0014. The glibc change was in 2.2.x (after 2.2.5?) it would appear, although that PR isn't the right place to look for exact glibc versions (you need to be careful about upstream vs something which Debian might have patched or considered patching). This change would be in glibc 2.3.x. Test team might need to update test. Specauth is agreed to put this back to Single Unix Spec. Stuart thinks he updated database. Kingdon cvs rm'd manpage this morning. Kingdon to file this as test bug. Needs verification. | ||
| 30 | gLSB command section manpages should be updated to SUSv3 | Need to compare SUSv2 (or whatever LSB 1.3 cited) with SUSv3 and figure out what we want. XSI versus non-XSI. Kingdon to look at these. | ||
| 27 | LSB installer command needed | Would this confuse people (it looks like an alternative to rpm, dpkg, etc rather than a wrapper)? Is there time/interest in maintaining/writing the spec, the implementation, etc? Choices: pre and post install scripts (can these interact with user?). Require some kind of setup step after installation? We should forward this to the futures team. Kingdon to include a brief discussion in bug and then reassign. George sending email to futures. | ||
| 18 | Certification: Can we make LSB be part of default install | Registering product? (product list says FooLinux xx.xx plus yyy.yyy patches).
That isn't true of recent certifications (and never did address how to
install the lsb bits specifically). Should we have a command to
install the LSB bits (but how would exist on a system which doesn't
have LSB stuff?).
Issue for certification, not for specauth.
Send this to Certification Authority.
Stuart to create category in bug database.
George to ask Andrew.
Register for 1.3 has the information of how to get an LSB system (from the questionnaire - click on the little "document" icon). Ask the distributions? Will we get answers? Doug to take a stab at formulating the question. What about X11 and OpenGL on a server? (we don't yet have "workstation" vs. "server"). | ||
| 17 | Do we need ldconfig | Issue here is "ldconfig -n" versus creating symlinks manually (ldconfig -n does not update the cache, it just creates symlinks). Stuart actually meant something broader. "ldconfig" without further ado just looks at /lib and /usr/lib (and whatever is in ld.so.conf - we don't want apps editing ld.so.conf presumably). "ldconfig" without further ado in post-install script works for packages which install in /usr/lib. Current practice is generally to use LD_LIBRARY_PATH (or rpath). Close this bug. | ||
| 16 | GNU vs POSIX getopt | What about case of "cmd -a -b -c" where -b is not a valid option? There's a suggested footnote. Is getopt_long affected by POSIXLY_CORRECT? "+" is not good in that it is not in POSIX. "+" does give you the ability to make it behave the same on POSIX by removing a character. Kingdon to come up with wording. | ||
| 788396 | lsb dependency should become lsb-arch | We like the idea of "lsb" as noarch dependency (as suggested by Tobias). Stuart to come up with words for dependencies (still to do this, no change as of 3 Dec). Should we try to solve profiles and this at the same time (so things only break once?). But can't really support profiles (e.g. lsb-workstation and lsb-server dependencies each depend on appropriate packages) unless you know what is in the profiles. So does it help to say something about profiles before we have them? LSB 2.0 plan is a single profile. lsb_release is bug #788393. Applications need to be able to use lsb_release if not using RPM. lsb_release in spec and implementation. Kingdon to look at this. Multiple answers (also return "1.3,2.0"). Would like some tests. Also see lsb_release improvements See also Mats page | ||
| 764725 | wrong argument to install_initd | See also 811869. Kingdon added footnote clarifying the situation (3 Dec: said footnote checked in). Hopefully this adds to clarity rather than just providing more words to slog through. Seems good - give people until next meeting to review wording if desired. Need to review in build. | ||
| 777381 | URL for C523 in Related standards | Don't worry about this for 1.3. Stuart to put back (for 1.9) SUSv2 for tar, col, etc (commands at least). This is in standards table, but XREFLABEL should be "The Single UNIX Specification Version 2" (Stuart to change this in database). Kingdon to add xref tags (did col, more remain). | anderson | ajosey |
| 8 | Make sure syscall traps are forbidden | If syscall instruction is legal in arch manual, does that imply that one can call syscall instruction. Stuart to put statement in gLSB (3 Dec: no change). This seems better than trying to list specific instructions (in archLSB). Also, don't use privileged instructions. | ||
| 10 | The spec lists tar/cpio, the tests use pax | Try to get people to use star? Usually importing POSIX tar works fine. Other way (generate with GNU tar, when there are long file names, then try to use elsewhere). Matt Wilson not really keen on having tar command implemented by star. We probably are now citing the (pre-2001) POSIX tar format (accidentally?). Maybe specify "star" (of course, this would be yet another invention, sort of). Tell people that >100 byte filenames might not work? (especially a problem for Java, X, which tend to use long file names). Document where GNU tar is different? In what way? | ||
| 686119 | dlopen behavior incompletely specified | Is that ELF gABI actually the same as the one we cite (maybe yes)? Kingdon to check whether we can just cite that. DT_RPATH vs. DT_RUNPATH (no answers)? Does that spec say skip LD_LIBRARY_PATH for setuid? Fallback path (hardcoded to /lib and /usr/lib, or just something which contains LSB libraries). Should we allow applications to add things to ld.so.conf? (Note that ld.so.conf might be different for LSB dynamic linker). Maybe just point to relevant page and ask submitter if this suffices. Kingdon to look at this. | ||
| 819575 | __daylight SUSv2 vs SUSv3 | Kingdon to update this to xref to SUSv3. | ||
| 690069 | ia64 has extra libgcc routines | _Unwind_Find_FDE, _Unwind_GetDataRelBase and
_Unwind_GetTextRelBase on ia64. Short fix seems to be to remove those
3 for ia64. Stuart to change in spec and errata.
Need to check built spec to see that this worked. 3 Dec: Not showing up anywhere; should be showing up in some archLSB's. Seems to be spec production issue. This is in tables of interfaces (libgcc_s). | ||
| 15 | Remove man page for gethostbyname and ioctl | Kingdon says: looks right for
gethostbyname, but not ioctl (SUSv3 ioctl has I_PUSH which is what
makes STREAMS slow and thus not in Linux). Stuart changing
gethostbyname to point to SUSv3. Already bugs for gets, statfs, and
statfs64. Need new bug for nice. We should deprecate
gethostbyname_r (people agree to this) in favor of getaddrinfo. In 1.9.0-20031126 build, gethostbyname says LSB (should say SUSv3). Stuart to update. In 1.9.0-20031126 build, gethostbyname_r not yet deprecated (should be). Kingdon to assign this bug to Stuart. |
This is as far as we got.
| Request ID | Summary | Comments | Assigned To | Submitted By |
|---|---|---|---|---|
| 748981 | /opt/provider | Now just a question of tracking that we refer to FHS 2.3 when it is out, and that FHS 2.3 final indeed (still) has /opt/provider |
Manpages which we don't need any more: cat, chmod, chgrp, cp, csplit, date, diff, env, expand, expr, file, gencat, head, localedef, make, man, mkdir, mv, nice, nl, nohup, paste, pathchk, printf, pr, pwd, rmdir, rm, sleep, strip, tail, tee, test, touch, tr, tty, unexpand, and uniq. Also iconv, ln, and sort. (13 Oct update: Stuart seems to have updated database except iconv, ln, and sort; Kingdon ran cvs rm on 1 Oct). Stuart fixing iconv, ln, and sort.
The wording: "The SA agrees that for LSB 1.3 that the diff, fold, join, pr,sort, unexpand, uniq and wc utilities need not interpret sequences of multibyte characters according to the LC_CTYPE category of the locale." Put this in errata? Do we care? (see PR 0037 for background, although the PR as a PR is resolved). We guess we can just leave it as something in the PR database, but not the errata.
See test page. We should help him review this. Assertions and what-not. Start with easy tests, worry about stuff like cron.monthly later (if at all). We'd like to see the test group follow up on this.
| Request ID | Summary | Comments | Assigned To | Submitted By |
|---|---|---|---|---|
| 677749 | Forking of programs which don't detach themself | nobody | gk4 | |
| 677744 | the behaviour of start_daemon is currently unclear | "already running" issue. | nobody | gk4 |
| 677746 | [Enhancement] start_daemon should have a PID file argument | nobody | gk4 |
| Request ID | Summary | Comments | Assigned To | Submitted By |
|---|---|---|---|---|
| 653167 | Output from init scripts is described vaguely | |||
| 677739 | [Enhancement] pathname for killproc/pidofproc | nobody | gk4 | |
| 677752 | should-start | This is in WIP, but optional. We should make it required or take it out, probably. | nobody | gk4 |
| 677737 | Exit status for killproc, start_daemon, pidofproc | See discussion at start of minutes. | nobody | gk4 |
| 677745 | Should a pid file be deleted by killproc | nobody | gk4 |
| Request ID | Summary | Comments | Assigned To | Submitted By |
|---|---|---|---|---|
| 681265 | appchk/ia64 .sbss errors | Not a spec problem (?). Looks like binutils (probably). Mats to try to deal with this. | ||
| 681268 | appchk/ia64 .rodata errors | Would appear to need further investigation. Mats to try to deal with this. |
Possibly convenient links:
-kingdon