15:00:03 <licquia> #startmeeting LSB Bug Triage 2013 Jan 17
15:00:03 <lsbbot> Meeting started Fri Jan 17 15:00:03 2014 UTC.  The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:03 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:15 <licquia> good morning
15:00:23 * licquia is happy mwichmann made it back :-)
15:02:31 <licquia> #info lsb bugs: 2 new
15:02:47 <licquia> #info fhs bugs: 27 new, 1 reopened
15:03:44 * licquia is surprised there aren't 3 new; checks status of 3901
15:04:21 <mwichmann> I already assigned it
15:04:33 <mwichmann> and, to be honest, finished it
15:04:41 <licquia> so i see
15:05:01 <mwichmann> submitter said it worked for him, so I pushed a little bit ago
15:05:14 <licquia> excellent
15:05:20 <licquia> we'll come back to it, then
15:05:24 <mwichmann> this time I have some excused for spending time looking into it :)
15:05:44 <licquia> nice
15:05:47 <licquia> !lsbbug 3900
15:05:50 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3900 normal, P2, ---, mats, NEW , foomatic-rip is specified in the wrong place
15:06:44 <mwichmann> triage wise, if the original claim is correct, we should assign and fix in 5.0
15:07:23 <mwichmann> we could also spend time discussing *what* to do, but maybe other bugs deserve the time more?
15:07:36 * orc_fedo returns w coffee
15:07:37 * abadger1999 dealing with an outage diagnosis at work... will try to join triage later
15:07:45 <licquia> abadger1999: awesome
15:08:00 <licquia> (not the outage, but joining us later, of course :-) )
15:08:31 <licquia> i'm inclined to call 3900 a bug-fix for 5.0
15:08:55 <licquia> it's my understanding, though, that we can't specify the utility in both paths at the same time?
15:09:25 <licquia> or is that fixed with denis's recommended index change?
15:09:44 <mwichmann> the db part is changed
15:10:07 <mwichmann> willing to bet some script counts on the current uniqueness property, because it always happens that way
15:10:24 <licquia> but we won't know that until we try it, i would imagine
15:10:40 <mwichmann> interesting, /usr/lib/cups/filter/foomatic-rip: symbolic link to `../../../bin/foomatic-rip'
15:11:50 <licquia> that's probably why it hasn't come up before
15:12:00 <mwichmann> and our printing test finds it by:
15:12:05 <mwichmann> sources/printing-test/testfoomaticrip/testfoomaticrip.sh:FOOMATICRIP=`type foomatic-rip | awk '{print $3}'`
15:13:45 <licquia> hmm
15:14:13 <mwichmann> that's easy to fix, of course
15:14:18 <orc_fedo> mwichmann: so it needs to do a find ... -type f -name foomatic-rip  -a -exec type {} \; | awk '{print $3}'    >
15:14:23 <orc_fedo> ?
15:15:16 <licquia> or just 'type /usr/lib/cups/filter/foomatic-rip'...
15:15:38 <orc_fedo> licquia: but avoiding hard paths was part of the issue, no?
15:16:03 <licquia> actually, not setting the correct hard path was the issue
15:16:28 <licquia> with anything in /usr/bin, it makes sense to avoid hard-coding in case it needs to move
15:16:47 <orc_fedo> I think we just said the same result  ;)
15:16:58 <licquia> possibly
15:17:23 <licquia> my point, though, is that here we need the hard path
15:17:52 <licquia> if foomatic-rip isn't in /usr/lib/cups/filter, then things potentially don't work
15:18:20 <licquia> anyway, i'm ok for fixing in 5.0; objections?
15:18:26 <mwichmann> none
15:18:30 <orc_fedo> no objection if that serves the reporter
15:19:40 <mwichmann> next bug?
15:19:52 <licquia> and we're ok with the plan, then?  1.  deprecate /usr/bin, add /usr/lib/cups/filter paths, 2.  remove /usr/bin in a later revision of the lsb
15:20:38 <mwichmann> I could go along with that
15:20:58 <mwichmann> could come up with a little weasel wording for the spec
15:21:17 <mwichmann> implementation will have to wait for some experiments since it's a "first" (two entries with same command name)
15:21:31 <orc_fedo> I dont really like ading a package specific path .. isnt it enuf for us to say it needs to be findable
15:22:02 <licquia> in this particular case, it's not enough, unfortunately
15:23:33 <licquia> ok, done
15:23:38 <licquia> !lsbbug 3902
15:23:41 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3902 normal, P2, ---, licquia, NEW , jerror.h should not leave JMESSAGE defined
15:25:02 <mwichmann> this comes out of the effort to build sane-backends
15:25:45 <mwichmann> anybody want explanation?  I tried to capture it somewhat concisely in the bug
15:26:45 <orc_fedo> nice writeup -- so we need to cache (push) prior state when we define it and under / pop at end of tests, as I read it?
15:26:53 <orc_fedo> undef*
15:26:53 <licquia> so i take it this was a script fail, in that it saw JMESSAGE defined and just sucked it in back when we did jpeg
15:27:16 <mwichmann> yup
15:27:43 <mwichmann> not "fail" so much... this is a place we needed human intervention, because decided not to import jpeg hdrs as-is
15:28:10 <licquia> right; i'm calling it a fail only in the sense that our scripts aren't 100%
15:28:30 <mwichmann> sure
15:28:33 <licquia> not necessarily implying there's a bug in the script; this is one of those things we should have caught, but didn't
15:29:29 <licquia> and i imagine that JMESSAGE is one of those things you can't actually use in libjpeg, b/c it won't be defined by the time user code gets to it
15:29:30 <mwichmann> orc_fedo: for full functionality we would need to get rather clever, because there are actually three states represented
15:29:47 <mwichmann> but only two of the states matter to us
15:29:58 <mwichmann> licquia: right
15:30:06 <licquia> so this isn't a case where we're going to break some code that relies on it
15:30:10 <orc_fedo> mwichmann: * nod * I saw that -- def / undef, crossed with calue, empty, no?
15:30:16 <orc_fedo> value*
15:30:40 <licquia> imho, we should just drop JMESSAGE if we don't need it for internal use by our header
15:31:00 <licquia> next question: spec impact?
15:31:07 * licquia checks navigator on that
15:31:29 <mwichmann> well, it's there in 4.0 and 4.1
15:31:45 <mwichmann> I don't minding errata for dropping it tho
15:31:57 <licquia> that was going to be my next question :-)
15:32:01 <mwichmann> uh... that didn't come out right.  don't mind writing.
15:33:27 <licquia> ok, i'm good with doing that for a stable update
15:33:30 <mwichmann> "never define at all" i the preferred answer for me, I'm not sure I can twist specdb into producing #define FOO { some stuff } #undefine FOO
15:33:43 * licquia agrees with that
15:33:54 <licquia> only concern is if we need it ourselves for some reason
15:33:55 <mwichmann> since we never use it anyway :)
15:34:15 <mwichmann> can't find one
15:34:32 <licquia> then i vote we drop, and let the reason find us if it's out there :-)
15:34:33 * mwichmann greps in tests just in case
15:35:27 <licquia> so, w/ spec impact, this should block spec and sdk, or just sdk (plus errata keyword)?
15:35:39 <mwichmann> I already attached this to next-SDK
15:36:06 <licquia> ok, cool, then i'll just mark assigned and set milestone
15:36:06 <mwichmann> the one I asked about yesterday, though it may in fact turn out to be the 5.0 sdk (we need to sort that story too)
15:36:28 <mwichmann> it does have errata/spec impacts, I'll add those notes in a bit
15:39:12 <mwichmann> so what next?
15:39:30 * licquia getting his machine to respond, for starters :-)
15:39:38 <licquia> !lsbbug 3901
15:39:40 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3901 normal, P2, 4.1-updates, mats, ASSIGNED , Some CUPS types aren't defined, when LSB_VERSION is set to 3.2
15:40:28 <mwichmann> we've hashed this out in lots of detail already but...
15:41:04 <mwichmann> it seems a patch which otherwise was good (importing new functionality) flipped the appeardin date on five cups enums from 3.2 to 4.1
15:41:33 <mwichmann> not finding any evidence that was intentional, I've put them back
15:41:55 <licquia> i'm just wanting to make sure we're cool with treating that as errata rather than "change in 5.0"
15:42:11 <mwichmann> there is zero spec impact: at the times 3.2 and 4.0 were produced, the .defs correctly indicated the types were in
15:42:31 <mwichmann> if we tried to rebuild 4.0 last week, it would have come out wrong
15:42:31 <licquia> and 4.1?
15:42:47 <mwichmann> spec only cares what is defined for that version
15:42:56 <licquia> ah, ok
15:43:07 <mwichmann> flipping dates to 4.1 meant it was defined for that version, so no prob there either
15:43:21 * licquia gets it
15:43:55 <mwichmann> it's hard to keep track of; headers are ifdef-versioned, defs are not
15:44:03 <licquia> and this is pushed and regenned and everything, right? so basically ready for testing this evening with the weekly rebuild?
15:44:13 <mwichmann> I yup
15:44:33 <mwichmann> the Samsung printing guy already took the header I attached to the bug and said it works for him
15:44:40 <licquia> cool
15:45:09 <licquia> so, i propose we mark PLEASETEST and deal with next week; if the rebuild worked out ok, we'll call it fixed
15:45:18 <licquia> and close it then
15:46:34 <mwichmann> works for me
15:46:57 <mwichmann> licquia can go back and do the meetbot foo if it's needed
15:47:06 * licquia forgot about that
15:47:40 <licquia> #agreed attach 3900 to lsb 5.0; fix part of it now and part in a future lsb release
15:47:44 <mwichmann> there's some new info on bug 3875 when you're ready
15:48:06 <licquia> #agreed fix 3902 as part of the next stable sdk, add errata
15:48:32 <licquia> #agreed 3901 should be fixed already; test with weekly rebuild and review next week (set to PLEASETEST)
15:48:46 <licquia> !lsbbug 3875
15:48:48 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3875 normal, P2, 5.0, mats, ASSIGNED , RFE: add ioperm to LSB
15:49:39 <mwichmann> basically... michael hsieh keeps running into trouble, and couldn't explain the last one (that ended up as the JMESSAGE bug)
15:50:01 <mwichmann> so he just sent me the sane-backends tarball (which I could have fetched upstream if I knew that's whatit was)
15:50:41 <mwichmann> we added ioperm because it was needed; it does also need iopl, and it needs some inline stuff (inb/outb) which I'll do another bug for so we can reject :)
15:51:03 <mwichmann> anyway... so ioperm is in, and last week I wondered why it shwoed up in the AMD64 book but not the other two
15:51:21 <mwichmann> we have old manpages from when AMD64 support was added so they're sitting in that dir
15:51:41 <mwichmann> I moved them to generic, now all three ioperm arches find the page
15:51:49 <mwichmann> page is out of date: volunteers to update?
15:52:34 <licquia> anything in particular out of date, or just "make sure to sync up with upstream manpage"?
15:52:35 <mwichmann> and.. now I think we should just go ahead and do iopl as well
15:52:47 <mwichmann> the one I noticed is in the bug
15:52:55 <licquia> ok
15:53:22 <licquia> your rationale for iopl makes sense, so i'm inclined to agree
15:53:46 <licquia> objections from anyone else?  orc_fedo?
15:53:53 <mwichmann> ok. that should just take a few minutes to set up once I get to it
15:54:41 <licquia> alrighty then
15:55:07 <licquia> #agreed on 3875, update man page to note linux 2.6.8 change, also add iopl for lsb 5.0
15:56:28 <mwichmann> don't have any other "favorites" off the top of my head
15:56:43 <licquia> !lsbbug 535
15:56:45 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=535 enhancement, P3, 5.0, mats, ASSIGNED , MO File format should be specified
15:57:22 <licquia> i'm thinking this should be closed as something like WONTFIX
15:58:22 <licquia> we're certainly not doing it for lsb 5.0
15:58:31 <mwichmann> that's true
15:58:44 <mwichmann> I can't figure out if there's really a problem or not
15:58:56 <licquia> and maybe requiring people to do msgfmt post-install is probably a better answer anyway
15:59:18 <licquia> i'd say let's see if someone actually has a problem before worrying any more about it
15:59:38 <mwichmann> as opposed to shipping "compiled" files?
15:59:39 <mwichmann> I don't know what current practice is
16:00:17 <licquia> i think most distros ship compiled files, but they also have more control over .mo file format changes than we do
16:01:41 <mwichmann> sure, we're not talking about distro pkgs anyway
16:01:54 <licquia> so, no objections to closing?
16:02:11 <mwichmann> fine with it
16:02:22 <licquia> #agreed close 535 with WONTFIX
16:02:49 <licquia> alrighty, that's the top of the hour
16:02:54 <mwichmann> in almost 10 yrs it never went beyond "we really ought to...", not a hard choice :)
16:03:00 <licquia> anything else?
16:03:14 <mwichmann> let me ask about the SDK blockers
16:03:26 <mwichmann> we have one for the next release
16:04:19 <licquia> "next" -> "next after 5.0"?
16:04:20 <mwichmann> there's also one for 5.0... mainly because we have to flip to marking 5.0 in the released list, and make it the default
16:04:35 <mwichmann> no, just "next SDK"
16:04:46 <licquia> ah, so "next stable release"
16:05:26 <mwichmann> I'm presuming the one for 5.0 will be the next stable release?
16:05:39 <licquia> good question
16:05:53 <mwichmann> maybe not, though that would be a bit sad
16:06:05 * licquia was thinking of doing a stable sdk release with 5.0 included, but not default
16:06:37 <mwichmann> okay, the not-default is not an absolute for me
16:06:53 <licquia> that would be part of the beta process
16:07:28 <licquia> so, beta X (X > 1) would also be a stable release for all the version-indepedent stuff, with 5.0 turned on
16:07:37 <mwichmann> in any case, there are two blockers to look at, roughly converging to the same thing
16:07:43 <licquia> then, 5.0 stable would change for version-indep only by making 5.0 the default
16:07:49 <mwichmann> it's just a reminder that we keep stuff sorted out
16:08:26 <licquia> ok; we could go with a non-default beta release, or just say we're not releasing another stable sdk until 5.0 and merge the bugs
16:08:32 <licquia> i could go either way
16:09:42 <licquia> maybe discuss as part of next weeks call, or on the list?
16:10:05 <mwichmann> cool, touched some button on my kbd while removing dog hair and it put the system to sleep
16:10:21 <mwichmann> yes, list and next call, both would be useful
16:10:27 <licquia> ok
16:11:02 <licquia> #action discuss merging "next stable sdk" and "5.0 sdk" on list, next call
16:11:06 <licquia> #endmeeting