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