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