14:00:07 <licquia> #startmeeting LSB Bug Triage 2013 Aug 1 14:00:07 <lsbbot> Meeting started Thu Aug 1 14:00:07 2013 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:07 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:26 <licquia> good morning 14:00:42 <mwichmann> allergies, morning is not so good 14:00:46 * mwichmann waves anyway 14:01:22 <mwichmann> #info 549 open, 543 assigned, 5 new, 1 needinfo 14:03:23 <licquia> hmm 14:03:29 * licquia counts only 4 14:03:34 <mwichmann> refresh 14:03:51 <licquia> there it is 14:04:06 <mwichmann> I forgot to push the submit button until just now 14:04:18 <licquia> heh 14:04:25 <licquia> alrighty 14:04:31 <licquia> !lsbbug 2902 14:04:33 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2902 enhancement, P2, 5.0, mats, NEEDINFO , RFE: Add symbols for libnspr4 14:05:14 <licquia> anything more to say here beyond "yep, let's just do these symbols for now"? 14:05:23 <mwichmann> naaah 14:06:31 <licquia> done 14:06:49 <licquia> !lsbbug 3824 14:06:51 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3824 normal, P2, ---, licquia, NEW , failures /tset/POSIX.os/dataform/cpio/T.cpio 24 27 14:07:51 * licquia suspects something odd is happening with user ids in the test 14:08:02 <mwichmann> before you go on... it seems we have a snapshot of nspr docs on refspecs 14:08:08 <mwichmann> and I don't see these functions there 14:08:19 <licquia> hmm 14:09:03 <mwichmann> http://refspecs.linuxfoundation.org/NSPR_API_Reference 14:09:18 <mwichmann> we'll at least have to adjust that 14:09:31 <mwichmann> maybe a note in the bug to check on docs status? 14:10:23 <licquia> http://refspecs.linuxfoundation.org/NSPR_API_Reference/NSPR_API.html 14:10:37 <licquia> "This document contains descriptions of NSPR functions included in the Linux Standard Base." 14:10:45 <mwichmann> right 14:10:47 <licquia> so... perhaps that's on purpose? 14:10:53 <mwichmann> I think so 14:11:00 <mwichmann> can no longer recall why we "mirrored" though 14:11:40 * licquia notes, for example, https://developer.mozilla.org/en-US/docs/PR_AtomicIncrement 14:12:00 <mwichmann> sure.. it's upstream 14:12:04 <licquia> i imagine it's to ensure we keep a static api 14:12:26 <licquia> i.e. the problems we've had with the gtk spec disappearing on us on gtk.org 14:12:29 <mwichmann> note there the atomic ops are a set of three, but we have two on the list (not PR_AtomicSet), so may still need to do some research when adding 14:12:41 <mwichmann> anyway, we can move back to 3824 14:13:37 <mwichmann> I'll add to 2902 14:13:41 <licquia> ok 14:13:47 * licquia deals with a browser crash 14:14:07 <mwichmann> modern browsers are so reliable they should never crash 14:14:16 <mwichmann> well, not more than once a day or so.... 14:14:33 <licquia> there's some bad relationship between synergy and chrome, need to debug it someday 14:14:43 <mwichmann> (and you can usually blame it on js or flash, so it's your fault) 14:14:54 <mwichmann> ah... you've added synergy to the mix 14:14:59 <licquia> yup 14:15:54 <licquia> ok... on 3824, i've taken a brief look 14:16:33 <licquia> there's a user id issue, which i need to look at; apparently, we care whether the euid or the real uid is used when creating files on extraction 14:16:41 <licquia> need to verify that it's legit 14:17:23 <licquia> the other is that pax on rhel7/f19 drops leading slashes as a security precaution 14:18:10 <licquia> not sure what posix actually says, but i'm inclined to allow this behavior 14:18:56 <mwichmann> drop by default, or drop no matter what? 14:19:29 <mwichmann> in tar, anyway, it seems to be the former: 14:19:31 <mwichmann> -P, --absolute-names 14:19:31 <mwichmann> don't strip leading `/'s from file names 14:19:53 * licquia checks 14:21:34 <licquia> there doesn't seem to be a way to tell fedora's pax to keep leading slashes 14:21:36 * mwichmann is looking at posix, pardon my inattention 14:25:04 * licquia doesn't see that posix requires honoring leading slash 14:26:21 <mwichmann> nor does it say you can ignore it 14:26:35 <licquia> true 14:26:49 * licquia does housekeeping 14:26:55 <mwichmann> if someone reminds me later, I'll check bugtracker/list archives for austin group to see if this has come up, bet it has 14:27:13 <licquia> #agreed only fix specific symbol list in 2902 14:27:21 <licquia> ok 14:28:01 <licquia> #action mwichmann check austin group bug tracker and list archives for pax behavior re: leading slash 14:28:19 <licquia> so, for this bug, target 4.1 updates? 14:28:33 <mwichmann> I think so, if we can work out the right resolution 14:32:03 <licquia> #agreed target 4.1 updates for 3824 14:32:18 <licquia> #action write problem_db entry for 3824 14:32:49 <licquia> one question: i don't see a discussion on euid vs. real uid in the posix spec linked in the bug; should we treat that as a test bug? 14:33:14 <licquia> i.e. it's not wrong to force the real uid in that case 14:34:23 <mwichmann> dunno 14:34:31 <mwichmann> would have to actually stop and think about it 14:35:36 <licquia> ok 14:35:43 <licquia> !lsbbug 3825 14:35:45 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3825 normal, P2, ---, licquia, NEW , refactor loopback code in core and dist-checker 14:36:14 <licquia> this came out of last week's discussion of 3815 14:36:32 <licquia> (loopback mount checking in test-core and dist-checker) 14:36:48 * licquia is inclined to assign to lsb 5 14:37:07 <mwichmann> yeah 14:37:40 <licquia> #agreed assign 3825 to lsb 5 test rollup 14:38:22 <licquia> !lsbbug 3827 14:38:24 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3827 normal, P2, ---, mats, NEW , possible regression exposed on F19 tester instance 14:38:52 <licquia> this is orc_fedo's bug on the libstdcpp-test bug 14:39:04 <licquia> where it's not building on the s390s 14:40:02 * licquia actually thinks it should be assigned to libstdcpp-test until we know it's a spec issue 14:40:48 <mwichmann> sure, that's fine (with me) 14:43:26 <mwichmann> our suspicion was it might be a problem in an implementation 14:43:46 <licquia> yup, writing something up 14:43:58 <mwichmann> sometimes I wish orc would clean up things he's cut from irc before pasting.... sigh 14:45:19 <licquia> #agreed reassign 3827 to distro tests, libstdcpp-test; research build issue as a potential fedora 19 regression 14:46:48 <licquia> !lsbbug 3828 14:46:50 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3828 normal, P2, ---, licquia, NEW , Failure in /convenience/cupsConvenience 37 14:47:26 <licquia> this should be waived 14:48:07 <licquia> we've had a number of issues with the cupsd we use in the printing tests; it uses more stuff than is in the spec 14:49:15 * licquia considers that we might want to write a stub cupsd that just signals success in the right ways; perhaps a big job, but should save us in the long run from a lot of these kinds of bugs 14:49:33 <licquia> objections? 14:50:09 <mwichmann> not really, but... whan will this happen? 14:50:34 <mwichmann> we've had similar joy with "dummy" xservers to test x functionality, as you know 14:51:00 <licquia> true, but ipp is a lot more simple of a standard than x11, for sure 14:52:05 <licquia> #agreed waive 3828 14:52:18 <licquia> #action licquia write problem_db entry for 3828 14:52:56 <licquia> interesting; ksrot has sent some feedback just as we're looking at this 14:53:20 <licquia> their guy thinks this is a bug in gcc, of all things 14:56:03 <licquia> not sure it changes the outcome, though 14:56:08 <mwichmann> I like such conclusions :) 14:56:18 <licquia> (though it does make the urgency of writing our own cupsd less) 14:56:55 <licquia> !lsbbug 3829 14:56:57 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3829 enhancement, P2, ---, mats, NEW , RFC: specdb refactor for later interface/library binding 14:58:45 <licquia> mwichmann: this is the thing you were talking about yesterday in the call? 14:58:46 <mwichmann> just get it done, wouldya? :) 14:58:50 <mwichmann> yes 14:58:51 <licquia> heh 14:59:47 <licquia> so, for bug triage purposes, just mark assigned? or something else? 15:00:43 <mwichmann> I don't think we can do anything else now 15:00:47 <licquia> ok 15:00:56 <licquia> #agreed mark 3829 assigned 15:01:09 <mwichmann> okay, a couple of reports... 15:01:40 <mwichmann> #info confirmed ncurses "deprecated" functions were indeed dropped in Xopen Curses Issue 7 15:01:56 <mwichmann> shall I also drop from curses, or just leave out of ncursesw? 15:02:56 <licquia> might be best to note in the bug; we can perhaps make that a late decision 15:03:17 * licquia would like to see info on usage before dropping 15:03:28 <mwichmann> navigator, I guess 15:03:35 <mwichmann> okay, I'll go along with that 15:03:37 <licquia> yup 15:03:58 <mwichmann> busy fixing different odd problem: five functions were in db but not included 15:04:15 <mwichmann> the ncursesw import "repurposed" them to ncursesw and turned them on 15:04:26 <mwichmann> but... those functions were always in xopen-curses 15:04:36 <mwichmann> I propose to add them for 5.0 15:05:03 <licquia> makes sense 15:05:20 <mwichmann> next info: 15:05:34 <mwichmann> nspr - our "needed by the app" list includes functions in these categories 15:05:42 <mwichmann> condition variables (5/5) 15:05:52 <mwichmann> lock functions (4/4) 15:06:06 <mwichmann> atomic operations (2/3), should also add the third 15:06:08 <mwichmann> easy so far.... 15:06:31 <licquia> ok 15:06:31 <mwichmann> and threads: our list has four functions 15:07:02 <mwichmann> one from "Creating, Joining and Identifying" threads - but not create or join 15:07:36 <mwichmann> three from "Controlling Pre-Thread Private Data" 15:07:45 <mwichmann> but missing the rest of the thread functionality 15:08:04 <mwichmann> another nine functions 15:08:08 <mwichmann> so what to do here? 15:08:32 <mwichmann> we can move to #lsb if you want.... 15:08:46 <licquia> yeah, let's do that 15:08:58 <licquia> anything else for the meeting notes before shutting it down? 15:09:29 <mwichmann> no 15:10:18 <licquia> #endmeeting