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