14:00:15 <licquia> #startmeeting LSB Bug Triage 2014 Mar 14 14:00:15 <lsbbot> Meeting started Fri Mar 14 14:00:15 2014 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:35 <licquia> good morning 14:01:38 <mwichmann> morning 14:02:04 <licquia> #info lsb: 4 new 14:02:13 <mwichmann> and way too many old 14:02:55 <licquia> #info fhs: 28 new 14:03:23 <licquia> and here we go 14:03:31 <licquia> !lsbbug 3941 14:03:34 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3941 normal, P2, 5.0, mats, NEW , Gtk 2/3 usages of "struct _Foo" instead of "Foo" 14:03:57 <mwichmann> assign as normal for 5.0 14:04:17 <mwichmann> meanwhile, I believe this is complete, can't find any more "bad" ones in current headers 14:04:26 <mwichmann> but was hoping for a bit of review 14:04:29 <licquia> this affects 4.1 and previous too, though, right? 14:04:46 <mwichmann> ah, right, there is an impact on 4.1 14:05:03 <mwichmann> that was in fact why I split this off from another 14:05:37 <mwichmann> comment #2 14:05:43 <mwichmann> so not assign quite as usual 14:06:17 <mwichmann> as an aside - the tool didn't just break, it also made a few errors in the gtk additions ("uplift") done for 4.1 14:06:56 <mwichmann> so licquia doesn't need to feel personally picked on 14:07:22 <licquia> heh 14:07:56 <licquia> so, add errata keyword, target 4.1-errata and 5.0? 14:08:04 <mwichmann> not as many, since the scope of that work was much simpler 14:08:16 <mwichmann> yes, that's right 14:08:35 <mwichmann> grrr, my opensuse vm doesn't have gtk3 devel pkg on it 14:08:44 <mwichmann> now I have to wait for the updates to spin first 14:09:37 <licquia> what fun 14:09:58 <licquia> that's one thing apt seems to do right: work with what it has rather than force people to update 14:10:20 <licquia> #agreed target 3941 at 4.1-errata, 5.0 spec 14:10:39 <licquia> !lsbbug 3942 14:10:41 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3942 normal, P2, ---, dsilakov, NEW , importer tool gets struct -> typedef -> const ptr wrong 14:10:59 <mwichmann> (it's more that I don't boot that vm often any longer since 13.1 came out, and now it's well out of date) 14:11:12 <licquia> fun 14:11:51 <mwichmann> assign as you wish, this is more recording one of the classes of problems than something I expect fixed 14:12:03 <mwichmann> (fixed soon anyway) 14:13:06 <licquia> so, not a 5.0 requirement 14:13:18 * licquia figures mark assigned, deal with after 5.0 14:13:24 <mwichmann> that horse has already left the barn: the imports are in, and broken 14:14:04 <licquia> #agreed mark 3942 assigned, fix post-5.0 14:14:53 <licquia> !lsbbug 3943 14:14:55 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3943 normal, P2, ---, mats, NEW , gtk3 missing types 14:15:22 <mwichmann> that's the "current" bug 14:16:03 <licquia> this is the bug where you fixed a lot of the "typedef struct _Foo Foo" parts, but left the actual _Foo structs undefined? 14:16:14 <licquia> (thus being the part we actually have to fix) 14:16:14 <mwichmann> right 14:16:53 <licquia> so clearly a 5.0 spec bug 14:17:53 <mwichmann> yes 14:17:57 <licquia> and, as i understand, we have two things to do: 14:18:18 <licquia> 1. for the struct members that are in, make sure they have proper appearedin data 14:18:33 <mwichmann> yes, and types 14:18:34 <licquia> 2. for the struct members that are not, add them (with proper appearedin as well) 14:19:01 <mwichmann> some types have been gotten wrong in other parts of the import 14:19:38 <mwichmann> in particular, gchar/guchar have often turned up as the underlying type (signed/unsigned char) 14:19:59 <licquia> ah 14:20:14 <licquia> do we have a list of those? 14:20:23 <mwichmann> no 14:20:33 <licquia> ok, so... 14:20:53 <licquia> 3. fix up any type irregularities in struct members 14:20:54 <mwichmann> this is not terribly likely anyway... for some reason, "partial imports" seem to pick up the first member and not the rest 14:21:23 <mwichmann> and the first member is rarely a simple type, usually a pointer to some complex struct 14:21:32 <mwichmann> nothing absolute, that's just an observation 14:22:05 <mwichmann> but yes, #3 included as well 14:22:32 <mwichmann> I did have to fix some earlier 14:23:29 <licquia> #agreed target 5.0 spec for 3943, set task list 14:23:55 <licquia> !lsbbug 3944 14:23:57 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3944 normal, P2, ---, mats, NEW , inb/outb are not defined in <sys/io.h> 14:24:27 <licquia> so this is a sane-related bug 14:25:04 <licquia> not remembering; did we exclude inb and outb on purpose? 14:25:06 <mwichmann> it's related to wanting to use a particular upstream pkg, built in LSB mode, unmodified 14:25:58 <mwichmann> low-level arch-specific stuff has generally been left out, we've had the general talk many times before 14:26:49 <licquia> right, but this isn't necessarily evil like, say, syscall 14:27:36 <licquia> hmm 14:27:42 <mwichmann> They are primarily designed for internal kernel use, but can be used from user space. 14:27:42 <mwichmann> You must compile with -O or -O2 or similar. The functions are defined as inline macros, and will not be substiā 14:27:42 <mwichmann> tuted in without optimization enabled, causing unresolved references at link time. 14:27:42 <mwichmann> You use ioperm(2) or alternatively iopl(2) to tell the kernel to allow the user space application to access the I/O 14:27:43 <mwichmann> ports in question. Failure to do this will cause the application to receive a segmentation fault. 14:27:53 <licquia> yeah, just reading that 14:28:02 <licquia> the macro bit makes me wonder; what's the implementation? 14:28:38 <mwichmann> I think I got the build working by just copying in the bits from the upstream header 14:29:32 <mwichmann> but that's me taking the bits from a header already tweaked for the arch I'm building on 14:30:55 <mwichmann> static __inline unsigned char 14:30:55 <licquia> think i see; they're turned into __asm__ stuff, so not anything terrible (like, say, a ref to syscall in the macro) 14:30:55 <mwichmann> inb (unsigned short int __port) 14:30:55 <mwichmann> { 14:30:55 <mwichmann> unsigned char _v; 14:30:55 <mwichmann> __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (__port)); 14:30:56 <mwichmann> return _v; 14:30:58 <mwichmann> } 14:31:35 <mwichmann> to implement, though, we'd have to figure out how to make this right (which might involve "exclude" in some cases) for all the arches 14:31:39 <licquia> so don't actually need the symbol in the stubs 14:31:46 <mwichmann> only headers 14:31:53 <mwichmann> but not sure we can emit stuff like that 14:32:17 <licquia> ok, that addresses some of my concerns 14:32:49 <licquia> and, more interestingly, not necessarily tied to 5.0 14:32:59 <licquia> i.e. this could be provided as a post-5.0 feature 14:35:44 <mwichmann> given I don't know how such a pseudo-function would be added to headers, not sure 14:36:12 <mwichmann> might end up being something that appears in data defs, If So, then it would be better to get into 5.0 14:36:38 <mwichmann> if it is sdk-only, then I'd agree 14:36:47 <mwichmann> high-prio interrupt 14:37:05 <mwichmann> we can stop here (after you figure out how to mark), or resume in ~30 minutes 14:37:22 <mwichmann> this was the last new (although 3941 still shows new on my screen) 14:37:59 <licquia> mwichmann: ok, will write up and we can be done 14:42:41 <mwichmann> thx 14:43:43 <licquia> #agreed target 3944 at 5.0 sdk; is a sdk feature only, so can be done anytime 14:43:47 <licquia> #endmeeting