14:00:27 <licquia> #startmeeting LSB Bug Triage 2013 Apr 4 14:00:28 <lsbbot> Meeting started Thu Apr 4 14:00:27 2013 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:28 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:02 <licquia> busy triage; 10 "interesting" bugs 14:02:21 * licquia figures he should make that an official note 14:02:33 <licquia> #info 10 bugs to triage this week 14:03:18 <licquia> !lsbbug 2912 14:03:18 <mwichmann> #info 6 new, 1 reopened, 2 needinfo, 1 pleastest 14:03:21 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2912 normal, P2, ---, phoenix, REOPENED , /olver/math/cexp/tests/cpow_spec 5162 FAIL OpenSUSE-11.2 14:04:30 <dsilakov> i think this one should be reassigned 14:04:41 <dsilakov> doubt that roman has time to investigate it 14:05:07 <licquia> that's probably a function of the default bug assignments 14:05:32 <licquia> is there a better person to assign it to? (besides me, i mean) 14:06:17 <dsilakov> can't suggest any:) 14:06:18 <mwichmann> it was a sane assignment when it was originally opened 14:06:30 <licquia> most likely 14:06:45 <mwichmann> I should probably check the defaults, and adjust s/*/licquia/ 14:07:03 <licquia> perhaps 14:07:10 * licquia assigns to himself, sets target and blocker 14:07:14 <mwichmann> anyway the reassignments you did a while back would have touched only bugs open at the time 14:07:44 <mwichmann> gargh, juggling two keyboards is tricky 14:07:54 <licquia> yup 14:08:03 <mwichmann> you want to tell meetbot your decision? 14:08:30 <licquia> yup 14:08:34 <licquia> one sec 14:09:35 <licquia> #agreed assigning 2912 to licquia, targeting next stable update 14:10:09 <licquia> !lsbbug 3408 14:10:12 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3408 normal, P2, 4.1-updates, licquia, NEEDINFO , /tests/functions/Keyboard_Accelerator_Groups/Keyboard_Accelerator_Groups 27,28,29 FAIL 14:11:13 <licquia> so this is a deliberate upstream change that isn't getting reverted 14:11:34 <licquia> a pedantic reading of the spec could lead one to believe it's not an incompatible change 14:12:00 * mwichmann notes the bugbot's display doesn't hint what this bug is against. maybe we could add product/component to that? 14:12:18 <mwichmann> my broser display shows those fields and it's quite clear it's desktop-test 14:12:38 <licquia> possibly 14:12:42 <mwichmann> (irrelevant to the bug itself) 14:13:58 <licquia> so my take is we waive and fix/disable test (whichever is appropriate); i.e. that we simply accept the new behavior 14:14:00 <mwichmann> I do usualyl try to sneak a hint to the component into the summary 14:14:25 <mwichmann> anyway... seems like this is bugging one user, and if behavior isn't going to change... 14:16:05 <licquia> that's my thought 14:16:24 <licquia> so no objections to the current plan of attack? 14:17:22 <licquia> ok 14:17:56 <licquia> #agreed proceed with 3408 according to plan in comment 5 14:18:27 <licquia> !lsbbug 3599 14:18:29 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3599 normal, P2, ---, licquia, NEEDINFO , rework development Release naming to add a leading '0.' before the YYYYMMDD 14:19:23 <licquia> so the main issue here is that sorting with .0. doesn't seem to fix the problem 14:19:26 <mwichmann> where's the Objecting Orc when we need him? 14:20:15 <mwichmann> sorry, originally just implemented what we were told, perhaps misinterpreted the details 14:20:40 <mwichmann> rpmvercmp really is a black art 14:20:45 <licquia> there was this clarification from #lsb: 14:20:45 <dsilakov> uh, unfortunately i hadn't time to read the latest discussin there, but i'll do soon and provide my comments 14:20:50 <licquia> <orc_emac> I intentionally put a non-working series in the Version (prefixed witha ^0. , and add an 'excludes' in the yum specification for the production archive to exclude the package being stabilized 14:20:50 <licquia> then when the package is 'released', I comment out the exclude, and the automatic yum rules bring the now released update over top of the testing 0. variant 14:21:45 <licquia> my alternative was to put the date in the release, and use (release-1).(date) 14:21:56 <dsilakov> meanwhile, modern rpm supports '~' in versions to designates betas/snapshots/etc. 14:22:13 <licquia> dsilakov: that's good news 14:22:31 <mwichmann> I know that was imported from debian, and not without some complaint... 14:22:52 <mwichmann> question is, can we count on it? 14:22:59 * licquia had been worried that vercmp would diverge between rpm and deb 14:23:40 * licquia pokes orc_fedo, in case he has some additional feedback to give 14:24:15 <licquia> as to "whether we can count on it", dunno that it matters even if not supported 14:24:29 <licquia> i.e. we need to use some kind of separator, and ~ works for that 14:25:31 <licquia> so my proposal, then: version-(release-1)~(date) 14:25:53 <mwichmann> I'm fine with whatever actually works, I've stumbled across the problem a few times in the past 14:26:12 <licquia> orc_fedo's proposal: version.0.(date)-release, and not supporting moving between snapshots and non-snapshots w/o manual package munging 14:26:20 <licquia> (as i understand it) 14:28:10 <licquia> so, perhaps that should be posted to the bug, and leave NEEDINFO, to give it some time to simmer and get comments 14:28:16 <mwichmann> we're not getting further here... do it. 14:28:22 <licquia> if not resolved next week, we pick a plan and move forward 14:28:26 <orc_fedo> licquia: just back 14:28:38 <licquia> aha! 14:28:45 <licquia> orc_fedo: any observations? 14:29:55 <orc_fedo> ~ is a name is probably durable and will end up everywhere 14:30:13 <orc_fedo> as to letting it simmer, nothing clarifies like a worked example 14:30:23 <orc_fedo> perhjaps I should describe my approach in an email 14:30:40 <licquia> perhaps so; can you post it to the bug? 14:30:45 <licquia> i'll do the same 14:30:51 <licquia> (with my idea) 14:31:06 <orc_fedo> the bug is directed to matters of workflow, to make it easy for a person to step off mail line stabel, for developmental, and then once done, hop back on without interruption 14:31:13 <orc_fedo> it is not all that important to third parties 14:31:22 <licquia> true 14:31:23 <orc_fedo> s/mail/main/ 14:31:27 <mwichmann> indeed 14:31:47 <mwichmann> I just end up ignoring attempted stable builds, partly because of this, but usually because I've already moved on :) 14:32:14 <orc_fedo> mwichmann: you are just a pioneer scout --- I can see that from the arrows in your buckskin 14:32:29 <licquia> so, then, we'll leave NEEDINFO, and post some more to the bug, and make a decision next week 14:32:32 <mwichmann> ow, that smarts 14:32:35 <licquia> cool? 14:32:38 <orc_fedo> s/buckskin/telephone link/ 14:32:43 <orc_fedo> licquia: works4me 14:33:06 <licquia> #agreed leave 3599 at NEEDINFO, collect more comments and decide next week 14:33:09 * mwichmann notes we've done 2/10 in 32 minutes :( 14:33:25 <licquia> !lsbbug 3759 14:33:27 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3759 normal, P2, ---, dsilakov, PLEASETEST , navigator can't handle three-version symbols 14:33:43 <mwichmann> sorry, 3/10 14:34:06 <mwichmann> looks ok in the one known instance 14:34:09 * licquia updated database and navigator recently on main 14:34:28 <licquia> mwichmann: so you think we got it? 14:35:19 <mwichmann> looks like this instance has rotted a bit, but take a look: 14:35:20 <mwichmann> http://navigator.lsbtest.net/navigator/browse/int_single.php?cmd=list-by-name&Ilibrary=libc&Iname=_sys_errlist 14:36:17 <licquia> looks that way 14:36:22 * licquia checks the main navigator 14:36:43 <mwichmann> wasn't sure things were up to date there 14:37:11 <mwichmann> they seem to be at least as far as this goes 14:37:19 <licquia> yup, looks good there 14:37:23 <licquia> so close? 14:37:58 <dsilakov> failures in test navigator doesn't seem to be caused by the patch from that bug... 14:38:17 <mwichmann> no, it's something to do with community that has failed, not worrying right now 14:38:22 <licquia> nope, don't see them in the linuxbase one 14:38:51 <licquia> ok 14:39:04 <mwichmann> I'm not sure the "char * const[0]" is correct, but that's also a separate issue. 14:39:24 <dsilakov> hm, yes 14:39:27 <licquia> #agreed resolve 3759 as fixed 14:39:27 <mwichmann> the display of symbol with three versions is fine with me, the two older greyed out and current one not 14:39:47 * licquia thought the [0] part was a different bug 14:40:05 <dsilakov> well, then i think the bug can be closed. I haven't seen any regressions up to now. feel free to open the new one for '[0]' 14:40:16 <mwichmann> yes... possibly caused not by nav bug but by my mistakes on db 14:40:25 <mwichmann> which *IS* a separate bug 14:41:01 <licquia> #action open new bug (or update existing bug if there) for [0] display on sys_errlist 14:41:57 <licquia> !lsbbug 3771 14:41:59 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3771 normal, P2, ---, mats, NEW , some size problems in specdb 14:42:01 <mwichmann> 3771 is in fact, the one about my mucking some things up, we can skip that if wanted 14:42:18 <licquia> just assign to you, or leave for next time? 14:42:36 <mwichmann> already assigned 14:42:52 <licquia> sorry, meant "mark assigned" 14:43:03 <mwichmann> one of our old answers was "put this in stub_libs override, it's hard getting data right" 14:43:20 <mwichmann> in recent years we've tried to get right, but I wasn't smart enough here I guess 14:43:39 <mwichmann> yes, mark assigned 14:44:06 <licquia> #agreed mark 3771 assigned 14:44:26 <licquia> #info note that the [0] problem mentioned in the action item appears to be 3771 14:44:45 <licquia> !lsbbug 3772 14:44:47 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3772 normal, P2, ---, mats, NEW , update reference to x86_64 ELF ABI 14:45:25 <licquia> got this question to the lf helpdesk 14:45:46 <licquia> basically: we refer to the 0.95 x86_64 abi, but also distribute a 0.98 version 14:45:53 <licquia> is there a reason we haven't uplifted? 14:47:22 <mwichmann> don't recall history 14:47:43 <licquia> !lsbbug 1615 14:47:46 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=1615 normal, P2, ---, mats, RESOLVED FIXED, Broken link to x86-64 ABI 14:48:08 <licquia> that was the original bug which prompted us to pull in the new abi specs to refspecs 14:49:06 <mwichmann> I know 14:49:31 <mwichmann> I guess at the time I spotted a newer version (or someone did) and we decided to archive it as well 14:49:40 <mwichmann> there seems no longer to be a master site 14:50:38 <mwichmann> we *could* update, but I'm disinclined to fiddle absent any reported issues, given how much else there is to do 14:51:12 <mwichmann> and despite the fiction that LSB documents these levels of ABI, actually gcc implementation is "the spec", sadly... 14:51:37 <licquia> true 14:51:50 * licquia supposes the gcc folks have an interest of maintaining something like compatibility... 14:52:04 <licquia> so postpone to post-5.0? 14:52:36 * licquia considers: RESOLVED LATER, or just ASSIGNED? 14:52:46 <mwichmann> I think just assigned for now 14:53:00 <mwichmann> this is a simple change if we decide to do, as long as it's to a spec we've archived 14:53:34 <mwichmann> 2-3 new lines of sql, and a change to expire an old entry 14:53:42 <licquia> #agreed postpone 3772 to after 5.0 14:54:14 <licquia> !lsbbug 3773 14:54:16 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3773 normal, P2, ---, bugzilla-owner, ASSIGNED , Test bug for infrastructure upgrade 14:54:40 <licquia> #info skipped 3773; test bug for lf sysadmins, already dealt with 14:54:55 <licquia> !lsbbug 3774 14:54:57 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3774 normal, P2, ---, licquia, NEW , failure /olver/util/format/tests/wcsftime_spec 561 14:56:30 <licquia> basically, strftime bug 14:56:36 * licquia thinks this used to work 14:56:51 <licquia> but the test submitter tried it on some older distros 14:56:57 <licquia> and couldn't get it to work right 14:58:25 * licquia thought there was a bug filed on this before, but can't find it now 14:59:40 <licquia> !lsbbug 2577 14:59:43 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2577 normal, P2, ---, stewb, RESOLVED NOTOURBUG, /tset/ANSI.os/time/strftime/T.strftime 9 fails on several distributions 14:59:49 <licquia> looks similar 15:01:06 <mwichmann> top of the hour, keep going a few minutes more? 15:01:36 <licquia> well, the last two bugs are well-known (the gcc 4.7 build fails) 15:01:58 <mwichmann> this one has a reproduer for the behavior, so I'd assign and investigate further 15:02:02 <licquia> i can deal with those, just want to get some conclusion on 3774 15:02:20 <licquia> ok, will assign and target next stable update 15:02:43 <licquia> #agreed target 3774 at next stable update 15:03:03 <licquia> #action research 3774 more, possibly update problem_db2 with better info 15:03:15 <licquia> last two: 15:03:26 <licquia> !lsbbug 3775 15:03:28 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3775 normal, P2, ---, licquia, NEW , appbat fails to build on recent distros 15:03:33 <licquia> !lsbbug 3776 15:03:35 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3776 normal, P2, ---, licquia, NEW , libstdcpp-test failing to build on OpenSuSE 12 15:03:47 <mwichmann> 3775 and 3776 need to be fixed pretty soon, but there's nothing natural to hang them off (milestone) I guess 15:04:22 <licquia> definitely by next stable update; hard to do fixes if we can't build :-) 15:04:28 <mwichmann> assign and bump priority? 15:04:45 <licquia> that, and target next stable update 15:04:51 <mwichmann> sure, why not 15:05:03 <mwichmann> you get to do the work either way :) 15:05:09 <licquia> yup 15:05:27 <mwichmann> didn't we have cases where "be more permissive" wasn't enough? 15:05:40 <licquia> #agreed bump priority, assign, and target next stable update for 3775 and 3776 15:05:49 <licquia> there's at least one case like that, yes 15:06:48 <mwichmann> is that recorded? 15:07:17 <licquia> not sure; it's the libstdcpp-test bug, though 15:07:56 <mwichmann> also might help to attach the build-addons log... well, whatever helps you track it down 15:09:06 <licquia> ok, that's done 15:09:14 <licquia> so, done for the day? 15:10:08 <mwichmann> +1 15:10:13 <licquia> #endmeeting