14:05:55 <licquia> #startmeeting LSB Bug Triage 2013 Mar 14
14:05:56 <lsbbot> Meeting started Thu Mar 14 14:05:55 2013 UTC.  The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:56 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:10 <licquia> ok, sorry about being late there
14:06:51 * mwichmann got one of his ubuntu vm's working right on virtualbox
14:06:58 <mwichmann> (which is completely off-topic)
14:07:13 <mwichmann> a second one is left broken by removing vmware-tools.... no fstab
14:07:53 <licquia> wow, how fun
14:07:55 <mwichmann> #info 537 open, 4 new, 533 assigned
14:08:12 <mwichmann> time for iso of system rescue cd to come into play...
14:08:38 <mwichmann> boots with root mounted read-only, but lack of fstab makes it impossible to remount r/w :)
14:08:53 <mwichmann> anyway, minor progress
14:09:20 <mwichmann> #info new last 90/30: 61/28, closed last 90/30: 45/16
14:09:33 <licquia> sounds like some tool was trying to be too clever
14:09:58 <mwichmann> vmware client install inserts a mount of /mnt/hgfs for "shared directories"
14:10:48 <mwichmann> and saves the old unmunched file; tried to put it back by symlinking to the saved old one, but that happened so long ago that didn't exist any longer
14:11:06 <mwichmann> still... should be some sort of warning that your system is being left broken BEFORE you shut it down
14:11:20 <mwichmann> !lsbbug 3763
14:11:20 <licquia> yup, just what i thought: tool trying to be too clever
14:11:23 <lsbbot> mwichmann: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3763 normal, P2, ---, licquia, NEW , failure in /olver/system/sysconf/tests/pathconf_spec 1
14:12:33 <licquia> that's a weird one
14:13:12 <mwichmann> indeed
14:13:24 <licquia> for triage: next stable update?
14:13:31 <mwichmann> yes
14:13:39 * licquia knows hacking on olver-core is still a bit of a black art...
14:13:50 <licquia> but that sounds like a good place to hang it
14:13:58 <mwichmann> there are way too many of these where a comparatively simple test leaves you insane after looking at the entire code flow
14:16:15 <licquia> #agreed 3763 should target next stable update
14:16:34 <licquia> #action update problem_db2 for 3763
14:17:22 <mwichmann> okay, an fstab is back on the vm, now to reboot into it
14:17:35 <licquia> !lsbbug 3764
14:17:38 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3764 normal, P2, ---, mats, NEW , RFE: add crypt_r
14:18:47 <mwichmann> there's nobody asking for this, but came across it in looking at the crypt issue we had
14:19:01 <licquia> but, you report significant app usage, right?
14:19:19 <mwichmann> crypt_r is used a bunch, the other two not; else I wouldn't have bothered filing
14:20:27 <licquia> so i'm ok with adding it; only concern is the usual time/resources thing
14:21:38 <licquia> target 5.0 spec, right?
14:21:42 <mwichmann> sure... interfaces trivial; struct a little more thought; manpage not too bad per our new plan (coming up in two bugs); there won't be tests... something like that.
14:21:52 <licquia> yup
14:21:55 <mwichmann> 5.0 is my thought, yes
14:22:13 <licquia> if we have tests for crypt, crypt_r tests should be a piece of cake
14:22:28 <mwichmann> maybe in olver...
14:22:38 * mwichmann drifts away to grep in some sources
14:22:43 <licquia> copy, paste, s/crypt/crypt_r/, add allocation/initialization of the struct
14:23:41 <mwichmann> there's files with crypt in them in olver, but do you wanna play in that testsuite?
14:23:52 <licquia> true
14:24:10 <mwichmann> actually, we KNOW there's tests for crypt, that's how we got here....
14:24:51 <licquia> #agreed go ahead with all symbols for 3764
14:24:52 <mwichmann> setting a blank salt was how it came up
14:25:06 <licquia> right, i remember
14:25:30 <mwichmann> we still have to decide how to handle that in LSB, that's sort of buried in the bug
14:25:47 <licquia> but that's a different bug than this one, right?
14:25:55 <mwichmann> !lsbbug 3762
14:25:58 <lsbbot> mwichmann: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3762 normal, P2, 4.1-updates, licquia, ASSIGNED , failure in /olver/util/crypt/tests/crypt_spec 1
14:26:40 <mwichmann> you want to talk about that after the next two?
14:26:48 <licquia> sure
14:27:00 <mwichmann> these sessions have gotten so lonely....
14:27:11 * licquia shrugs
14:27:46 <licquia> !lsbbug 3766
14:27:48 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3766 normal, P2, ---, licquia, NEW , problem_db doesn't match the checksum
14:28:22 <licquia> i've seen this before when the update script is in the process of running
14:28:46 * licquia writes a reply
14:30:13 <licquia> leaving it NEW; ksrot is pretty good at following up, but if we don't hear anything in a week, good to be reminded of it at next week's meeting
14:31:07 <mwichmann> !$@?@ the vmware thing went back to broken state
14:31:08 <lsbbot> mwichmann: Error: "$@?@" is not a valid command.
14:31:17 <mwichmann> gotta be some stupid thing lurking in an initscript
14:31:17 * licquia chuckles
14:32:27 <mwichmann> can you check what's on the server?
14:32:56 * licquia checks
14:33:45 <licquia> hmm, interesting...
14:33:59 <licquia> -rw-rw-rw- 1 root root 336209 2013-03-07 08:42 problem_db2
14:33:59 <licquia> -rw-rw-r-- 1 root root     46 2012-06-22 16:50 problem_db2.md5
14:34:35 <mwichmann> so his complaint was the md5 file is not downloaded, but it looks like maybe it is, and just is out of date?
14:35:08 <licquia> that's weird
14:35:20 <licquia> something must have changed; it's been working up to now
14:35:43 * licquia has seen that warning, but noticed the script was running; must have been a coincidence
14:39:10 <licquia> !lsbbug 3767
14:39:12 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3767 enhancement, P2, ---, mats, NEW , RFE: use POSIX as ISrefspec on derived-from interfaces
14:40:07 <mwichmann> you did something further with previous bug?
14:40:27 <licquia> yup, followed up again, marked assigned
14:40:45 <mwichmann> add agreed line here?
14:41:50 <licquia> #info 3766 is a bug in the server script; not updating md5sum of problem_db2 for some reason
14:42:01 <licquia> #agreed 3766 marked assigned, should fix asap
14:42:05 <licquia> that good?
14:42:12 <mwichmann> fine
14:42:25 <mwichmann> 3767 is a "cleanup proposal" I guess
14:43:08 <mwichmann> I haven't checked how many of the manpages in question already do what the change would make navigator show, possibly most/all
14:43:16 <mwichmann> don't know when I'll get to checking either
14:43:24 <mwichmann> but it would guide how to handle the new crypt ones
14:43:58 <mwichmann> separately, I speculate on whether LFS is still the right standard to point to... (silly me)
14:44:24 <licquia> i'm on board with the improvement, and doing the crypt_r stuff that way
14:44:57 <licquia> re: lfs, is this something where we need to transition (like moving posix to 2008)
14:46:17 <mwichmann> possibly
14:46:50 <mwichmann> LFS is a delta to posix issue 4.2, where we're moving from issue 6 (sortof) to issue 7 (2008)
14:47:14 <mwichmann> and it sort of talks about transitional where things have just become what they become....
14:47:21 <mwichmann> but maybe it's good enough
14:48:34 <licquia> sounds like an uplift is in order, if we're already uplifting to posix 2008
14:48:57 <mwichmann> assign it to the new sepc editor then
14:49:00 <mwichmann> oops
14:49:07 <licquia> heh
14:49:57 <licquia> though some of this we've decided isn't ready for prime time, i think
14:50:07 * licquia is thinking of the aio_* stuff
14:50:34 <licquia> though that could be just a "we don't have the non-64 versions, so we don't have the 64 versions either"
14:51:47 <mwichmann> separate question there.... aio stuff is no longer an "option group" in POSIX
14:51:55 <mwichmann> think I updated that bug too
14:52:38 * licquia searches for it
14:53:21 <licquia> !lsbbug 1391
14:53:24 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=1391 enhancement, P2, 5.0, mats, ASSIGNED , add async I/O interfaces to LSB
14:54:20 <licquia> so, apart from aio_*, i suppose we're on board with adding the new lfs stuff and uplifting lfs?
14:54:43 * licquia thinks aio_*64 should follow the other aio_* stuff
14:55:53 <mwichmann> sure, it does
14:56:50 <licquia> alright
14:56:58 <mwichmann> which is nothing :(
14:59:12 <licquia> #agreed make changes in 3767 for ISrefspec, uplift LFS and add symbols as appropriate
15:00:11 <mwichmann> !lsbbug 3762
15:00:13 <lsbbot> mwichmann: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3762 normal, P2, 4.1-updates, licquia, ASSIGNED , failure in /olver/util/crypt/tests/crypt_spec 1
15:00:49 <mwichmann> so: testsuite uses illegal salt, which now fails at certain upstream level
15:01:13 <mwichmann> of course, testsuite could wish to do that to verify failure in case of illegal, except that hasn't been documented
15:01:19 <mwichmann> (1) change testsuite?
15:01:56 <mwichmann> (2) update spec to *allow* error on illegal salt? (assuming we can't mandate, since only very recent system do)
15:02:12 <mwichmann> (that's a question too)
15:02:42 <mwichmann> (3) update spec to *allow* gnu-ish behavior where a particular illegal salt will be interpreted in a defined way?
15:02:53 <mwichmann> Is this just one bug?
15:03:52 <licquia> i'd say yes to 2 and 3, which implies 1
15:04:14 <licquia> dunno on the "one bug" thing; it's all the same issue, just multiple steps to fix
15:05:07 <mwichmann> right
15:05:50 <mwichmann> all 4.1, or split so doc changes happen only in 5.0?
15:06:30 <licquia> seems to me to be a 4.1 issue; it's not like you get older behavior with an older symbol, or some such
15:07:25 <mwichmann> Existing docs describe a valid salt, and the testsuite doesn't use it, so that's a fair thing to just fix next update
15:07:53 <mwichmann> Describing new behavior... that *could* wait, but I'm not fussy about it
15:08:48 * licquia defers to mats on the spec part
15:09:07 <licquia> so that sounds like i'm ok with it being a 5.0 thing, with the fixes to the test suite being a stable update
15:09:27 <mwichmann> becomes a matter of time/priority I guess
15:09:32 <licquia> yup
15:09:43 <mwichmann> I think we can close this session then
15:09:49 <mwichmann> and I'll pester you on #lsb
15:09:55 <licquia> alrighty
15:09:59 <licquia> #endmeeting