14:00:45 <licquia> #startmeeting LSB Bug Triage 2014 May 9 14:00:45 <lsbbot> Meeting started Fri May 9 14:00:45 2014 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:45 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:39 * orc_fedo is here, lsbbot 14:02:11 <licquia> #info lsb: 5 new, 1 reopened 14:02:17 <licquia> #info fhs: 26 new 14:02:31 <mwichmann> I'll be back in just a couple of minutes, dog needs to go out 14:02:32 * licquia waves to everyone 14:05:11 <mwichmann> ok 14:05:24 <licquia> !lsbbug 3195 14:05:26 <mwichmann> darn collie is not checking my calendar before fussing 14:05:27 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3195 normal, P2, ---, mats, REOPENED , LSB packages with unowned directories uninstallable on some rpm implementations. 14:05:30 <licquia> heh 14:05:54 <licquia> so, same status 14:07:00 <licquia> #action licquia on 3195, release the darn test harnesses already 14:08:18 <licquia> !lsbbug 3972 14:08:20 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3972 normal, P2, ---, licquia, NEW , Apache Tests(2.2.14-8) Fail on x86_64: Failed to prepare apache 14:08:45 <orc_fedo> that one is in process .. there are problems upstream they need to address 14:09:02 <mwichmann> you're thinking of this one 14:09:06 <mwichmann> next one, I means 14:09:11 <mwichmann> grrr 14:09:19 <orc_fedo> rolly 14:09:24 <mwichmann> quick, either get me a new keyboard or a new brain 14:09:34 <mwichmann> if you're thinking of gl 14:09:54 <mwichmann> I guess here it's a question of who's upstream... 14:10:03 <mwichmann> put initscript functions in wrong place 14:10:22 <mwichmann> not-our-bug, but maybe leave it open as a courtesy and a place to hold more comments? 14:10:28 <orc_fedo> here, upstram -- distro under test 14:10:44 <licquia> that's the odd thing, though 14:11:06 * licquia would expect they would have an actual distro person doing the testing 14:11:30 <licquia> i'm ok with leaving it open until they get it worked out 14:12:04 <licquia> hopefully will be resolved by next week 14:12:07 <mwichmann> licquia has not worked for Intel, I notice.... testing always gets "farmed out" 14:12:21 <mwichmann> not sure these folks are with Intel, but it's mostly Intel doing Yocto 14:12:45 <mwichmann> may actually be someone trying to implement yocto, and thus wanting to test it 14:13:00 <licquia> could be 14:13:01 <mwichmann> anyway, is there any need to mark this further? 14:13:39 <licquia> #agreed leave 3972 for now, which bug submitter works out the problem 14:13:46 <licquia> !lsbbug 3974 14:13:48 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3974 normal, P2, ---, licquia, NEW , LSB 4.1: Celestia Test : OpenGL GLX extension not supported by display ':0' 14:14:21 <licquia> this one puzzles me 14:14:48 <licquia> there should be an easy way to just disable the hardware driver and run with software rendering 14:15:15 <licquia> this would suck perf-wise, but would be enough to determine that the libraries all work properly, at least 14:16:03 <mwichmann> but... that's not of much use unless end users will be expected to run that way 14:16:49 <mwichmann> this is a weird area for us 14:17:07 <orc_fedo> I added the outlink to the OpenGL debugging options, so that if the bug DOES get to teh person handling their x drivers, they will have a pointer 14:17:13 <mwichmann> a "standard system library" actually gets replaced by one that matches a piece of hardware 14:17:47 <orc_fedo> we could run try to glxinfo before going off into applications and catch failures and notify about possible problems 14:17:48 <licquia> hmm, like the nvidia situation, where they use a custom libGL.so.1 14:18:15 <orc_fedo> I also have a non-funcy libGL.so.1 under this workstation's ATI card 14:18:28 <mwichmann> right 14:18:48 <licquia> and if we test with mesa, we're testing a different library 14:19:01 <mwichmann> so passing the test with a setup customers are unlikely to see has, to me, somewhat limited value 14:19:30 <mwichmann> so I don't really know what to do with this either. it also seems not-our-bug 14:19:32 <licquia> otoh, if their driver is this bad, i doubt customers will see it very much either way :-) 14:20:06 <licquia> i mean, it's not like celestia and the bouncing cow screensaver are cutting-edge gl apps 14:21:25 <mwichmann> no 14:21:56 <licquia> so that makes me wonder 14:22:08 <licquia> it's almost as if opengl and the x server are out of sync 14:22:25 <licquia> like if you try to use the mesa libgl with the nvidia driver 14:22:31 <mwichmann> don't know any particulars, but sometimes when you buy a graphics chipset, you get the bits for it too - and not the ability to change anything 14:23:25 <licquia> at any rate, if glxgears is busted, that's the clear problem, i'd imagine 14:23:33 <licquia> same treatment as last bug? 14:23:39 <licquia> or is it time to close this one 14:23:41 <orc_fedo> licquia: sure 14:23:46 <mwichmann> either way 14:23:54 <orc_fedo> he was in channel working this one yesterday 14:24:04 <licquia> ok 14:24:04 <orc_fedo> I would leave it open for a target for him to return to 14:24:24 <licquia> #agreed leave 3974 for now, while bug submitter works out the problem 14:24:37 <licquia> !lsbbug 3975 14:24:39 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3975 normal, P2, 5.0, licquia, NEW , consider adding durable 'branding' inside LSB libraries and binaries, to permit inventorying possible stray content 14:25:22 <orc_fedo> I am convinced by mats reply that this is not a small task, and think this approach should be closed 14:25:27 <orc_fedo> should have done that 14:26:10 <licquia> so, not even a "do some other time" kind of thing? 14:26:50 <orc_fedo> licquia: yes -- the approach would be different; this is wrong way 14:26:54 <licquia> ok 14:27:21 <licquia> #agreed close 3975; wrong way to achieve this goal 14:28:08 <licquia> !lsbbug 3976 14:28:10 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3976 normal, P2, ---, licquia, NEW , Distribution database updates 14:28:53 <mwichmann> we should reword the summary a bit 14:29:20 <mwichmann> "app-checker distro data out of date", something like that 14:29:43 <licquia> done 14:30:02 <licquia> so, there was a concern that it wouldn't work, which got fixed, it looks like 14:30:30 <licquia> is this just a matter of "run the gen script against f20, opensuse 13.1, and a few ubuntus"? 14:30:46 * licquia expects he will have to do something interesting to the current tarball 14:33:02 <mwichmann> different issues 14:34:03 <mwichmann> when db updates, app-checker has to gen new data - since it keeps a local copy of interesting stuff to avoid going out over the net to a db instance 14:34:23 <licquia> ah, so we need the existing data to be part of an appchecker release 14:34:27 <mwichmann> this bug is about the fact that this was not done last may when the last community data dump happened 14:34:32 * licquia also expects we should gen new data too 14:35:00 <mwichmann> we ALSO can claim that the distro data needs updating, and denis has told us some in email about how to do that 14:35:03 <licquia> but having the current data would be a good idea as well 14:35:30 <licquia> so, question: should we just release a new appchecker now, or do the new imports first? 14:35:31 <mwichmann> we talked about this a bit some other times 14:35:40 <mwichmann> new appchecker now 14:35:49 <mwichmann> no idea when we'll have time to do new imports, right? 14:36:07 <licquia> quite possibly true 14:36:18 <mwichmann> the data is arch-specific, so we have to run "make gensrc" on each of the seven 14:36:24 <orc_fedo> licquia: I would do release a new appchecker now, and if we issue another one in the future, so be it 14:36:38 <licquia> so, target vip? 14:36:39 <mwichmann> and then upload the files to the ftp side 14:37:04 <mwichmann> because a normal build downloads the files rather than trying to gen 14:37:12 <licquia> right 14:37:37 <mwichmann> I have the x86_64 ones ready, if we can decide how I get them to the location - I assume I can't write there directly 14:38:01 <licquia> can you log into vm1.linuxbase.org? 14:38:17 <mwichmann> otherwise the only change to appchecker itself is to bump the version so it's slightly clear there's new data in play 14:38:29 <mwichmann> hang on... 14:38:45 <mwichmann> yes, I can 14:39:31 <licquia> so it looks like you need sudo access still 14:40:04 <mwichmann> I can just scp the files to my home and have you take it from there? 14:40:09 <licquia> that works 14:41:06 <mwichmann> in progress 14:41:15 <mwichmann> now ... markup on the bug? 14:41:24 <licquia> target vip updates? 14:41:34 <mwichmann> I would think so 14:42:01 <licquia> do we need to do this for x86 too? 14:42:09 <mwichmann> we need to do it for all seven 14:42:10 * licquia figures those would be the two most interesting archs 14:42:31 <licquia> we can just run the script on the arch, no need for the actual distros? 14:42:32 <mwichmann> I can do x86 in a vm without any real trouble, but my contribution runs out there 14:42:53 <mwichmann> now you're off on the other topic :) 14:43:10 <mwichmann> for this one, it's arch-specific, but not distro-specific 14:43:26 <mwichmann> where you run it, I mean 14:43:58 <licquia> ok; so running this on the power build slave, lfdev-ia64, and the new s390 slave should do the trick 14:44:03 <mwichmann> right 14:44:06 <licquia> ok 14:44:34 <mwichmann> need app-checker branch, then just run "make gensrc" in the package dir 14:44:59 <mwichmann> you'll see what you're expecting if you follow the link in the bug to the ftp location 14:45:03 <licquia> do you need a full db? (specdb "make restoreall") 14:45:14 <mwichmann> ah.. yes, you need access to one 14:45:18 <licquia> ok 14:45:44 <mwichmann> but it should be okay to set the env vars to point to the master, I don't think other than for speed that it has any need to be local 14:46:12 <licquia> ok 14:46:59 <mwichmann> the convention seems to be that the ftp dir keeps one previous version of the files around - anyway there's an "old" directory that has some previous version 14:47:15 <mwichmann> x64 files copied up to ~mats 14:47:27 <licquia> and you'll do x86? 14:47:43 <mwichmann> I will try - at that point I can answer the question about the database :) 14:48:06 <licquia> heh 14:48:14 <mwichmann> I'll write a new bug about updating the distro data 14:48:19 <licquia> ok 14:48:24 <mwichmann> we can use it to collect thoughts on which ones to scan 14:48:58 <licquia> #agreed gen data for 3976 and update the pkg, target vip 14:49:13 <licquia> #action mwichmann gen data for x86 for 3976 14:49:32 <mwichmann> these are the last few adds in the Distributions file 14:49:33 <mwichmann> 465 openSUSE 12.2 2012 Novell 1 14:49:33 <mwichmann> 467 Fedora 18 2013 Fedora Project 1 14:49:33 <mwichmann> 469 openSUSE 12.3 2013 Novell 1 14:49:33 <mwichmann> 475 Debian 7.0.0 2013 SPI 1 14:49:33 <mwichmann> 478 Ubuntu 13.04 2013 Canonical 1 14:49:36 <licquia> #action licquia gen data for ppc32, ppc64, ia64, s390, s390x for 3976 14:50:40 <licquia> so, perhaps f19 and f20, opensuse 12.3, ubuntu 13.10 and 14.04 14:51:43 <mwichmann> 12.3 is there, but not 13.1 14:51:50 <licquia> oops, mistype 14:52:15 <mwichmann> was debian 7 really available a year ago? 14:52:18 <licquia> maybe others (rosa, mandriva, etc.) 14:52:22 <mwichmann> sure 14:52:36 <mwichmann> we can get denis to voluteer time on rosa :) 14:52:38 <licquia> a year plus sounds about right 14:52:42 <mwichmann> ok 14:53:15 <licquia> !lsbbug 3978 14:53:17 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3978 normal, P2, 5.0, licquia, NEW , should xml2 testsuite move out of desktop? 14:54:12 * licquia supports adding this to the 5.0 distro tests blocker, but with the understanding it probably won't happen in time 14:54:22 <mwichmann> fair enuff 14:54:42 <mwichmann> dist checker would have to know about a new test, only for 5.0 14:54:50 <licquia> right 14:54:59 <mwichmann> dunno if that goes in some manifest only, or in some code, don't know that tool at all well 14:56:19 <licquia> it's in the manifest 14:56:49 * licquia thinks we could add that test to dist-checker w/o doing a dist-checker release, but not sure about that 14:56:59 <orc_fedo> ;) 14:57:16 <licquia> #agreed target 5.0 for 3978; may not get to it for release 14:57:32 <mwichmann> that would be cool... I think it does try to download new manifest, but not sure it can actually deal with a whole new test. fun experiment someday. 14:57:50 <licquia> ok, that's it for lsb bugs 14:58:00 <licquia> anything else pressing to talk about in the few minutes remaining? 14:59:04 <mwichmann> we need to do more work going over the 5.0 bugs 14:59:10 <mwichmann> not in one minute, obviously 14:59:38 <mwichmann> was there every any agrement to start one of these sessions for "new LSB" stuff? 14:59:40 <licquia> yup 14:59:59 <licquia> i think robjo was going to propose something, and we could work out a time 15:00:11 * licquia is behind on email, but hadn't seen it yet 15:00:29 <licquia> that, or maybe we just decided that the wed call was the best time to handle those 15:00:38 * licquia must be getting senile in his old age :-) 15:00:44 <orc_fedo> I do not think we so decided 15:00:53 <licquia> ok 15:01:15 <rickt_> Watch your comments about age, young man. 15:01:20 <licquia> heh 15:01:45 <licquia> ok, declaring this one done; we can heckle and such back in the other channel 15:01:48 <licquia> #endmeeting