14:00:29 <licquia> #startmeeting LSB Bug Triage 2013 May 2
14:00:29 <lsbbot> Meeting started Thu May  2 14:00:29 2013 UTC.  The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:29 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:50 <licquia> good morning
14:02:08 <mwichmann> and an interesting one it's been....
14:02:23 <mwichmann> yesterday afternoon was mid-70's, this morning 15
14:02:30 <mwichmann> spring in the mountains
14:02:48 <licquia> crazy
14:03:08 <licquia> we're supposed to cool off here, too, but "cool off" -> going down from 70s to 60s
14:04:26 <licquia> #info 3 new bugs, 0 unconfirmed, 0 reopened, 3 needinfo, 3 pleasetest
14:04:46 <licquia> oops
14:04:47 <licquia> #info 3 new bugs, 0 unconfirmed, 0 reopened, 3 needinfo, 0 pleasetest
14:05:36 <licquia> !lsbbug 3124
14:05:38 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3124 normal, P2, 4.0, licquia, NEEDINFO , /Qt4_Menus-t2c/tests/QMenuBar/QMenuBar 30 FAIL
14:06:49 <licquia> the proposed solution here: test using different points
14:08:02 <licquia> main question this brings up: if qt uses different methods for determining that a point lies within a widget depending on external factors (the theme, internal math changing, whatever), is that a problem?
14:08:43 <mwichmann> it's irritating, but perhaps within the design?
14:08:52 <mwichmann> wonder if there's anyone we can ask
14:09:29 <licquia> my guess is that this is used after getting a point via some ui action, like "the mouse clicked here"
14:10:20 <licquia> which means that theme changes don't really matter, as the click will presumably take the theme border into account
14:10:50 <licquia> no idea if we can ask someone
14:12:58 <licquia> alright, i say we just go with the test change/waiver for this case
14:13:34 <mwichmann> no objection here
14:13:38 <licquia> #agreed waive/fix 3124 according to comment 6
14:13:54 <licquia> !lsbbug 3274
14:13:56 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3274 normal, P2, ---, licquia, NEEDINFO , /Qt4_Paint_Device-t2c/tests/QPixmap/QPixmap 67 fail, rawhide, qt-4.8.0
14:14:29 <licquia> here, i'm making the judgment call that x11-specific stuff in qt was a "mistake"
14:14:43 <licquia> (specifically, the function which gets the x11 handle for a QPixmap)
14:15:48 <licquia> upstream has made it so stuff like this doesn't work unless you explicitly enable it with a new method call
14:15:58 <licquia> "new" -> we don't have it
14:17:22 <mwichmann> ok
14:17:38 * mwichmann has eyes glaze over when talk turns to qt internals
14:17:57 <licquia> heh
14:18:43 <licquia> #agreed on 3274, waive and disable test
14:19:15 <licquia> #action file bug for deprecating QPixmap::handle() in LSB 5.0 per bug 3274
14:19:36 <licquia> !lsbbug 3416
14:19:39 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3416 normal, P2, ---, licquia, NEEDINFO , /glib-t2c/tests/glib_threads/glib_threads 1,2,3,8 FAIL
14:21:08 <licquia> glib has changed upstream here; thread priorities and bounds are now ignored
14:21:55 <licquia> so the test fails because the priority on the newly-tested thread is wrong
14:22:28 <licquia> not a segfault-causing abi break, but certainly apps relying on thread priorities won't get them
14:22:41 <licquia> otoh, upstream has already weighed in
14:23:16 <licquia> the call should be deprecated in lsb 5, and the new function for creating threads added (if it isn't already), but what to do with lsb < 5?
14:24:10 <mwichmann> for the 5.0 case, we've uplifted glib, what does that mean for the above?
14:24:45 <licquia> i think we need to make sure g_thread_create_full (and the other one) are deprecated in lsb 5
14:24:56 <licquia> and that we include g_thread_new
14:25:22 <mwichmann> g_thread_new is in
14:25:38 <licquia> cool
14:26:25 <licquia> and, i note, g_thread_create_full is marked deprecated
14:26:29 <mwichmann> g_thread_create_full marked deprecated >= 5.0
14:26:30 <mwichmann> right
14:26:49 <licquia> so all that's left is to decide what to do now
14:27:31 * licquia is resigned to disable/waive here
14:27:44 <mwichmann> charge extra $1000 to applicant if they want a waiver
14:27:53 <licquia> heh
14:28:22 <licquia> not super thrilled, but don't think this is something upstream is going to consider reverting
14:29:01 <licquia> #agreed disable/waive test in 3416
14:29:19 <licquia> !lsbbug 3778
14:29:21 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3778 normal, P2, ---, mats, NEW , Define 'ssize_t' in 'sys/types.h'
14:30:21 * licquia gathers from mwichmann's comment in the bug that he's not opposed
14:31:34 <mwichmann> no, just worried that somewhere in the bowels of rebuilding the whole world, some obscure corner of appbat breaks again
14:31:43 <licquia> right
14:31:57 <licquia> so, do the usual target/milestone/rollup?
14:32:05 <licquia> (for 4.1 update sdk)
14:32:15 <mwichmann> I guess, and same for the next one
14:32:20 <licquia> ok
14:32:42 <licquia> #agreed target 4.1 updates for 3778
14:32:59 <licquia> !lsbbug 3779
14:33:01 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3779 normal, P2, ---, mats, NEW , Add '#include <limits.h>' to 'sys/param.h'
14:33:09 * licquia looks
14:33:35 * licquia agrees
14:33:57 <licquia> #agreed target 4.1 updates for 3779
14:34:20 <licquia> !lsbbug 3780
14:34:22 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3780 normal, P2, ---, mats, NEW , Addition of 'ifaddres.h' and corresponding prototypes
14:34:48 * licquia thinks this is a duplicate
14:35:02 <mwichmann> I'll change for 3778 and 3779 today or tomorrow, in the hopes we can get buildbot to pick up during the weekend
14:35:18 <licquia> ok
14:35:43 <mwichmann> 2143 it looks like
14:35:45 <licquia> !lsbbug 2143
14:35:47 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2143 enhancement, P2, 4.1-errata, mats, ASSIGNED , Add *ifaddrs to LSB
14:35:53 <licquia> yup
14:36:43 <mwichmann> we even have a patch, wow
14:36:53 <licquia> #agreed mark 3780 as a duplicate of 2143
14:37:04 <mwichmann> would want to update patch a bit I guess; I assume add=5.0
14:37:24 <licquia> yup
14:37:46 <mwichmann> i can try, should we wait on that one until after the weekend?
14:37:57 <licquia> #agreed target 2143 for lsb 5.0
14:38:19 <licquia> up to you; i'm ok with doing it at the same time as the others
14:38:43 <mwichmann> well, if you have time to poke through smoldering ruins....
14:38:44 <licquia> different enough that they shouldn't interfere, and any breakage should be obvious
14:38:53 <mwichmann> you'd think so
14:39:04 <mwichmann> ifaddrs will be picked up by someone's configure
14:39:18 <licquia> so if it's easier for you to do all three at once, go for it
14:39:39 <mwichmann> samba it looks like from stewb comments
14:39:58 <mwichmann> well, I prefer to make them look like separate commits
14:40:14 <licquia> oh, right; i meant "in one sitting"
14:40:21 <mwichmann> else it's "changeset: many changes, good luck untangling, sucka!"
14:40:26 <orc_fedo> heh
14:41:09 <mwichmann> yeah, one sitting should be okay, once I reboot into f17 so my sign-after-commit stuff in bzr works again
14:41:14 <mwichmann> not sure it's today
14:41:20 <licquia> ok
14:41:27 <licquia> so, last question:
14:41:40 <mwichmann> ifaddrs stuff will need manpages
14:42:25 <licquia> looking at updates, wondering if we can put off sdk update for next stable update cycle (august, i believe)
14:42:37 <licquia> so...
14:42:44 <licquia> !lsbbug 3747
14:42:46 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3747 blocker, P1, 4.1-updates, licquia, ASSIGNED , LSB SDK 4.1.7 release
14:43:12 <licquia> wondering if anyone would point at one of those bugs and say "no, that one there needs immediate attention"
14:43:47 <mwichmann> hmmm
14:44:04 <orc_fedo> 3625 has been looked at me recently for some reason
14:45:01 <licquia> yeah, the STT_GNU_IFUNC vs. ld-gold thing
14:45:16 <licquia> !lsbbug 3625
14:45:18 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3625 normal, P2, 4.1-updates, licquia, ASSIGNED , lsbcc/lsbc++ generates non-compliant binaries with GCC 4.5 and 4.6
14:45:21 <orc_fedo> * nod *
14:45:50 <licquia> you think that one needs quicker attention?
14:46:14 <orc_fedo> licquia: not necessarily -- my browser just says I've considered it
14:46:35 <orc_fedo> perhaps going thru all on that blocker list, and ranking as high, middle low makes sens
14:46:39 <orc_fedo> sense
14:46:50 <licquia> ok
14:47:02 <licquia> quick-like?  mwichmann ok with that?
14:47:27 <mwichmann> I guess, a bit distracted at the moment, but it's what this mtg is for....
14:47:28 <orc_fedo> 1716 is P1 ... rest are P2
14:47:42 <licquia> !lsbbug 1716
14:47:44 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=1716 normal, P1, 4.1-updates, mats, ASSIGNED , lsbcc should not automatically add -lpthread
14:47:58 <licquia> i'd actually argue that should be a 5.0 bug, not a 4.1 update bug
14:48:02 <licquia> objections?
14:48:16 <orc_fedo> I see: It's a complicated issue, and we don't seem to have examples where this has
14:48:19 <orc_fedo> caused a real problem.  So, putting off to 4.0.
14:48:24 <orc_fedo> as no=one is clamoring for it, sure
14:48:46 <licquia> #agreed move 1716 to 5.0 blocker/target/milestone
14:48:48 <orc_fedo> mwichmann: how say you?
14:48:49 <mwichmann> we did have a case where it caused a problem
14:49:03 <mwichmann> but I can't recall it, and we may have worked around it other ways
14:49:22 <licquia> !lsbbug 2935
14:49:24 <mwichmann> so: not arguing for doing it now
14:49:25 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2935 normal, P2, 4.1-updates, licquia, ASSIGNED , SDK package build knows too much about LSB versions
14:49:42 <licquia> right/wrong priority?
14:49:58 <mwichmann> lemme look, don't recall details
14:50:49 <mwichmann> hmmm
14:51:16 <mwichmann> i figured I would have put in a four-page treatise on this one, but nothing from me at all... odd :)
14:51:39 <orc_fedo> seems a low piority, but also, perhaps an easyfix that could be knocked out, or simply closed, pending actual problems surfacing?
14:52:15 <licquia> not in favor of "just close", but otherwise agree
14:52:28 <mwichmann> I'm not actually sure what the problem is
14:52:49 <licquia> it's a completeness thing from back when we made the sdk version-independent
14:53:17 <orc_fedo> licquia: and an Agile response to that is: if we are not hitting it, You arent Gonna Need It
14:53:45 <mwichmann> I think licquia's workaround is working well enough now, maybe it's ugly?
14:53:59 <licquia> it is, but it does work
14:54:14 <mwichmann> .... and certainly, if it ain't actually impeding us, there's way too much else on the plate
14:54:17 <licquia> i.e. we get the right libs, etc. for stable vs. devel sdks
14:54:23 <orc_fedo> close with a: not presently causing a problem and no reproducer, so close
14:54:30 <licquia> ok
14:54:45 <licquia> #agreed close 2935 with wontfix
14:54:53 <licquia> !lsbbug 2941
14:54:55 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2941 normal, P2, 4.1-updates, licquia, ASSIGNED , lsbcc changes order between library arguments and file name arguments
14:55:09 <licquia> p2?
14:55:17 <licquia> or more important?
14:55:30 <mwichmann> sigh
14:55:56 <mwichmann> pragmatism says this shouldn't block anything
14:56:19 <mwichmann> refactor lsbcc would be great, but will take some time to implement, and a lot more than that to "prove"
14:56:49 <mwichmann> we had some case where this was a problem, right?
14:56:53 <licquia> we did
14:57:00 <orc_fedo> perhaps ping the reporter and ask about its relevance, and recheck next week?
14:57:09 <orc_fedo> drop to P3, pending a reply
14:57:41 <licquia> dunno that relevance is at issue, though
14:57:51 <licquia> it's clearly wrong behavior
14:58:07 <licquia> and build system convention is the only reason it's not a bigger deal
14:58:38 <licquia> (it's uncommon to mix .a file args with -l library args)
14:58:57 <orc_fedo> licquia: in RH space it is as they stomp out .a and .la
14:59:26 <orc_fedo> (and so the effect of having such present is not expressed)
15:01:30 <licquia> i think i'm ok with keeping the priority as is; not moving it up or down
15:01:38 * licquia notes the time; keep going?
15:02:08 <orc_fedo> fine w me ... my thout at a re-examination was to get an implementation sequence to drop out from P reorderings
15:02:41 <licquia> mwichmann?
15:03:35 * licquia is ok with just taking p2 bugs in time order oldest-first; mainly wondering if any of them is important enough for a p1/immediate fix
15:04:02 <orc_fedo> licquia: how then will you decide you are done and to release it?
15:04:10 <orc_fedo> onlt P1, and ship ?
15:04:16 <orc_fedo> s//only/
15:04:19 <licquia> for now
15:05:27 <orc_fedo> ... so with only one P1, fix is and ship the update this month?
15:05:49 <licquia> actually, zero p1, assuming we move 1716 to lsb 5
15:05:59 <orc_fedo> licquia: indeed
15:06:09 <licquia> so that would mean we can put off shipping to august
15:07:16 <orc_fedo> licquia: works4me ... perhaps publish the bug list to the ML, invite objections as to need, and wait a week
15:07:34 <licquia> ok, works for me
15:07:49 <licquia> #endmeeting