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