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