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