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