14:01:29 <licquia> #startmeeting LSB Bug Triage 2013 May 23 14:01:29 <lsbbot> Meeting started Thu May 23 14:01:29 2013 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:29 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:37 <licquia> #info 1 new, 0 unconfirmed, 0 reopened, 1 needinfo, 0 pleasetest 14:03:40 <licquia> good morning everyone 14:05:00 <mwichmann> hi 14:05:18 <licquia> !lsbbug 3415 14:05:22 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3415 normal, P2, 4.1-updates, licquia, NEEDINFO , /atk-t2c/tests/AtkObject_signals/AtkObject_signals 13,14,22,23 FAIL 14:06:08 <licquia> so, my main question here: do we need to document the behavior change here, or should we just waive and fix? 14:07:26 <mwichmann> wave goodbye? 14:07:30 <licquia> heh 14:07:46 <mwichmann> I'm not sure what a change note would look like... 14:08:09 <licquia> the new behavior is: when you initialize an AtkObject, name and description get set to NULL initially 14:08:35 <licquia> then, when you set those properties, you get a notification that the properties changed 14:08:59 <licquia> the difference: old atk always sent a notification 14:09:34 <licquia> new atk doesn't send a notification when the properties are initially set (i.e. when they start out as NULL) 14:10:28 <licquia> so that would be the note: "you will not be notified on initial setting of these properties" 14:11:43 <mwichmann> right, but how do we express it in an erratum (assuming that's where it goes)? 14:12:56 * licquia isn't sure; that's why he's asking 14:13:46 * mwichmann claims his opinion is "unspecified" 14:14:01 <licquia> ok; suppose that answers the question 14:14:07 <mwichmann> which is probably what we have to say, in some form, about the issue 14:14:09 <licquia> so, just fix 14:15:36 <mwichmann> it's been a really long time.... what do we say about atk in any case, do we just point? 14:15:43 <licquia> just point 14:16:12 <mwichmann> and my usual nitpickery, is the thing we point to still there by some miracle? 14:16:28 <licquia> well, that's another question, to be sure 14:16:28 <mwichmann> actually the real question was whether the old upstream spec said anything about this, 14:16:45 <mwichmann> or whether it was an inferred behavior (it worked like this, so that's what the test does) 14:16:52 <mwichmann> sorry I'm behind on this topic... 14:18:14 <licquia> the docs, such as they are, are unclear; this is a notification you can get, and this is when you get it 14:18:35 <licquia> the argument is that the initial setting of the property is different from a change to that property 14:18:49 <licquia> and that the notification was intended for the latter 14:19:32 <mwichmann> I don't think a small clarifier is out of order 14:19:43 <licquia> the problem they were solving was that a11y apps were getting flooded with bogus change notifications because that event would fire every time the property was set at object creation 14:20:39 <mwichmann> reality is, nobody's doing spec stuff at the moment 14:20:56 <licquia> true; just noting for the record something that needs to be done 14:21:01 <licquia> probably by me at some point 14:21:23 <mwichmann> is there a way we can bin that part of the issue without completely blocking the bug? (that old problem) 14:22:23 <licquia> we could set the errata keyword on it 14:23:53 <licquia> ok, set errata keyword; moving on 14:24:20 <licquia> !lsbbug 3788 14:24:22 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3788 normal, P2, ---, licquia, NEW , Failure in /olver/io/term/tests/read_tty_spec 1 14:28:28 * licquia noodles around in bzr 14:28:32 <licquia> oh, forgot: 14:28:55 <mwichmann> it's amusing that something so simple (tty settings) has caused so much trouble historically 14:29:03 <licquia> #agreed consider adding a compatibility note of some kind for 3415 14:30:21 <licquia> not finding anything that jumps out at me re: 3788 14:32:56 <orc_fedo> sort of strange it is only on one arch 14:33:10 <licquia> that's what i was thinking 14:33:30 <licquia> dunno if we have other tests that check this condition 14:36:12 <licquia> so... will attach to the stable update bug, though it's almost certainly going to be put off this go-round 14:36:44 <licquia> but i'd at least like to get a sense of whether this bug needs a waiver or is a problem in the distro 14:37:23 <orc_fedo> licquia: there is some work toward a recent fedora ppc64 which may reveal it 14:37:35 <orc_fedo> would you like me to try to solve an install in th4e spare VM ? 14:37:49 <licquia> orc_fedo: that would be excellent, if you could 14:38:19 <orc_fedo> I may well ask Karel for an assist 14:38:29 <licquia> ok 14:40:17 <orc_fedo> set up a 4.2 updates and dump it there for mow? 14:40:34 <licquia> i've attached it to the current update blocker 14:40:38 <orc_fedo> kk 14:40:52 <licquia> probably later this week, i'll create a new one for "next time" and move a bunch of bugs off to it 14:41:26 <orc_fedo> www.google.com/reader 14:41:30 <orc_fedo> urk 14:41:31 <orc_fedo> sri 14:41:40 <licquia> heh 14:42:17 <licquia> alright, that's it for the regular bug triage list 14:42:34 <licquia> anything else we want to talk about? 14:42:52 <orc_fedo> re-visit: deadwood by target milestone? 14:43:28 <licquia> we could 14:43:30 <orc_fedo> https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3290 14:43:50 <orc_fedo> sri -- wrong bot 14:43:59 <orc_fedo> !lsbbug 3290 14:44:01 <lsbbot> orc_fedo: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3290 critical, P1, ---, licquia, ASSIGNED , LSB web/FTP/etc. restoration rollup 14:44:11 <orc_fedo> 'critical' -- really? 14:44:44 <orc_fedo> and so look at the blocker elements 14:44:52 <orc_fedo> !lsbbug 3451 14:44:54 <lsbbot> orc_fedo: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3451 normal, P2, ---, herrold, ASSIGNED , supybot config should be in puppet 14:44:59 <licquia> it was critical at one time, though we did get the critical parts fixed 14:45:00 <orc_fedo> kill it 14:45:11 <licquia> yeah, that one's done 14:45:29 <orc_fedo> closed 14:45:53 <orc_fedo> !lsbbug 3401 14:45:55 <lsbbot> orc_fedo: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3401 normal, P2, ---, licquia, ASSIGNED , restore lsbprs 14:46:05 <orc_fedo> hmmm 14:46:10 <orc_fedo> over my pay grade 14:46:42 <orc_fedo> we could have a crawler walk the site and find all matches 14:47:16 <licquia> lsbprs was the first problem reporting thing we did when we took over certification from the open group 14:47:19 <orc_fedo> but the bug also said it was a short term need -- has the need passed? 14:47:40 <orc_fedo> if so can we close it, pending a problem surfacing? 14:47:57 <licquia> the real answer is probably to find all references to the old lsbprs and change them to point to something more permanent 14:48:01 <orc_fedo> and when such surfaces, open a fresh bug 14:48:11 * licquia checks problem_db 14:48:23 <orc_fedo> the prefect is the enemy of the good -- do you really need it? 14:48:34 <orc_fedo> perfect .. the rule applies to spelling as well 14:49:06 <licquia> [licquia@lflap5 problem_db]$ grep lsbprs problem_db2 | wc -l 14:49:07 <licquia> 62 14:49:48 <licquia> my guess is that these are nearly all ancient, and no one would run across them anymore 14:49:54 <orc_fedo> so close it? 14:51:03 <licquia> one loose end: let's make sure problem_db2 has version boundaries on all those 14:51:10 <licquia> so that they aren't triggered anymore 14:51:25 <orc_fedo> need a new sub bug for that ? 14:53:28 <licquia> reading the list over; some are still valid in that they were tied to a deficiency in the os 14:53:53 * licquia figures he can just close 14:54:04 <orc_fedo> don 't be a hoarder ;) 14:54:59 <orc_fedo> closed 14:55:16 <orc_fedo> !lsbbug 3395 14:55:18 <lsbbot> orc_fedo: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3395 normal, P2, ---, licquia, ASSIGNED , LSB release notes in inconsistent locations 14:55:57 <orc_fedo> again, work to do when stuck on a conf call one need not pay close attention to 14:56:07 <orc_fedo> I would leave open 14:57:49 <licquia> yup 14:58:01 <orc_fedo> !lsbbug 3376 14:58:03 <lsbbot> orc_fedo: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3376 normal, P2, ---, licquia, ASSIGNED , wiki dumps should be made 14:58:42 <orc_fedo> I think you recently prolly did this as to current content 14:58:55 <orc_fedo> is there a cron proces to this effect set up? 14:59:10 <licquia> no, not at present 14:59:20 <orc_fedo> would you please set one up? 14:59:47 <licquia> i know that backups are being done at the lf 14:59:50 <orc_fedo> or even a co-sysadmin to do so 15:00:16 <licquia> so i'm inclined to say this is done, unless there's some other concern here 15:00:17 <orc_fedo> licquia: do you use just one tether line when rapelling? 15:00:51 * licquia doesn't rapel, but good point 15:01:19 <orc_fedo> just set an ageing of the last three, to keep it from taking over a box and call it done 15:01:48 <licquia> otoh, the lf's backup strategy now is pretty robust; if the lf loses their backups, we've got bigger problems than the wiki 15:01:53 <orc_fedo> we are at top of hour -- shall I just note the box for now? 15:01:58 <licquia> sure 15:02:10 <orc_fedo> licquia: not if flat test backups are offsite elsewhere 15:02:25 <orc_fedo> updated 15:02:27 <orc_fedo> and we are done 15:02:38 * licquia may close a few more on his own 15:02:44 <orc_fedo> as you wish 15:02:45 <licquia> #endmeeting