15:00:07 <licquia> #startmeeting LSB Bug Triage 2014 Feb 28 15:00:08 <lsbbot> Meeting started Fri Feb 28 15:00:07 2014 UTC. The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:08 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:18 <licquia> #info lsb: 1 pleasetest, 2 needinfo, 2 new 15:02:07 <licquia> #info fhs: 27 new, 1 reopened 15:02:24 <licquia> oops, miscount 15:02:40 <licquia> #info fhs: 28 new, 1 reopened (correction) 15:03:11 <licquia> ready? 15:03:17 <mwichmann> I guess 15:03:45 <licquia> !lsbbug 3171 15:03:47 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3171 normal, P2, 4.1-errata, mats, PLEASETEST , sockaddr_un.sun_path should not use UNIX_PATH_MAX 15:04:52 <mwichmann> sorry, a bit distracted there 15:05:29 <mwichmann> sys/un.h does not use the constant, linux/un.h does (but I don't see a normal path to including that) 15:05:35 <mwichmann> so dropped 15:05:46 <mwichmann> remaining question was: bother with errata? 15:07:05 <licquia> we're just punting to posix, right? 15:07:17 <licquia> so this strictly speaking is just a change to the sdk 15:07:29 * licquia doesn't think that's errata-worthy 15:08:55 <mwichmann> posix says nothing specific here 15:08:57 <mwichmann> The size of sun_path has intentionally been left undefined. 15:09:19 <mwichmann> it mentions some different sizes, but no constant in this context 15:09:21 <mwichmann> so close? 15:09:44 <licquia> right, but we don't say something like "posix leaves this undefined, but we define it to be 'foo'" 15:10:09 <licquia> that would be errata-worthy, i think, but not as things stand 15:10:15 <licquia> so i'm ok with closing 15:10:41 <licquia> #agreed 3171 doesn't need errata, so resolve 15:11:00 <licquia> will you close it, or should i? 15:11:51 <mwichmann> go ahead 15:12:20 <licquia> ok 15:12:26 <licquia> !lsbbug 3849 15:12:29 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3849 major, P1, 4.1-errata, mats, NEEDINFO , sizeof(struct epoll_event) wrong on amd64 15:14:04 <mwichmann> fixed for sdk 15:14:59 <mwichmann> haven't done errata, as I confused myself about whether needed or not 15:15:23 <mwichmann> the packing stuff is normally an sdk attribute, but then I found it does show in some .defs in the spec 15:16:46 <licquia> so the question is whether this needs errata? 15:17:11 <mwichmann> yes 15:17:29 <mwichmann> and maybe whether .defs generation is correct or not 15:17:32 <mwichmann> let me check 15:17:47 <orc_fedo_> licquia: simply mentioning the bug and close in the release notes but not beyond would seem to suffice, so a person tracking it can see why the change happened, perhaps 15:18:07 <licquia> in other news, builds restarted for ia64 15:19:01 <mwichmann> mmm, even this change made the header arch-specific, that does not appear in the .defs 15:19:32 <mwichmann> so based on current generation, there's no need for errata, since no spec-level change :) 15:19:39 <licquia> ok 15:19:40 <mwichmann> now whether that's right or not... 15:19:52 <licquia> if not, then we have a different bug to file 15:20:08 <licquia> #agreed 3849 does not need errata, resolve 15:20:21 <mwichmann> in /theory/, the size of the struct should be a spec issue 15:20:34 <mwichmann> I just don't feel like pursuing, sorry 15:20:56 <mwichmann> (because it's a binary standard, not a source standard) 15:21:28 * licquia wonders if the spec wasn't incomplete on that specific point 15:21:43 <licquia> i.e. we carried the indefiniteness of posix into the binary standard 15:22:09 <licquia> !lsbbug 3923 15:22:11 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3923 normal, P2, ---, mats, NEEDINFO , tic and infocmp 15:22:39 <mwichmann> still no word 15:23:17 <licquia> i would say resolve with NOTABUG, with an invitation to thorsten to reopen if he feels it necessary 15:25:28 <mwichmann> go ahead 15:26:32 <licquia> #agreed resolve 3923 as not a bug, with invitation to reopen if needed 15:28:25 <licquia> !lsbbug 3933 15:28:27 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3933 normal, P2, ---, mats, NEW , specdb Xt defintions confused 15:29:36 <mwichmann> this one should be fresh in the memory still 15:29:38 <mwichmann> yuck 15:29:44 <licquia> yup 15:30:03 <licquia> i think i want to test this more before applying, just because of the header mess 15:30:41 <orc_fedo_> was comment 2 split off and separately filed? 15:30:50 <licquia> i know there's a real bugfix buried in there, but it doesn't seem to have bitten us yet 15:31:54 * licquia suspects that the comment 2 issue is related to the other problems 15:32:16 <licquia> i.e. not sure how much sense it makes to split it off 15:32:35 <mwichmann> dunno either 15:32:35 <licquia> changing the type of a declaration like that can cause the headers to reorder, which is the other problem in that bug 15:33:25 <licquia> anyway, attach to 5.0 spec bug? 15:33:34 <licquia> sorry, 5.0 sdk bug? 15:34:07 <licquia> hmm, except this *does* have spec implications 15:34:19 <licquia> so maybe 4.1-updates? 15:34:49 <mwichmann> the one change has spec implications yes, so I guess updates is right 15:35:26 <mwichmann> so is it supposed to be __attribute__((packed)) or ((__packed__)) or do both work? 15:35:53 * licquia can't remember 15:36:02 <mwichmann> we have one of each 15:36:09 <mwichmann> I guess it's off to search engines 15:37:47 <licquia> #agreed target 3933 at 4.1 errata and 5.0 spec 15:38:20 <licquia> !lsbbug 3934 15:38:22 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3934 normal, P2, ---, mats, NEW , reconcile 5.1 pkgconfig files with 5.0 15:38:54 <licquia> think this should target "next", i.e. not 5.0 or anything earlier 15:39:50 <mwichmann> that's fine 15:40:14 <mwichmann> at the moment I believe there's one line missing 15:40:14 <licquia> #agreed target 3934 at "future", not for 5.0 15:40:44 <licquia> right, but i want to make sure we review the whole thing when the time comes, to make sure we didn't miss any other changes 15:41:17 <mwichmann> I did that, so it was only a question of your additions 15:42:25 <licquia> ok, that's it for the "interesting" bugs in lsb; anything else we want to talk about? 15:42:51 <mwichmann> probably 15:42:59 <mwichmann> but I'm not paying enough attention today 15:43:17 <mwichmann> I would like to do something with the fhs bug marked "reopened" 15:44:04 <orc_fedo_> licquia: do we need a watchdog that receives reports from builders, and barks when a unit fails to check in for more than a couple hours, and builder clients checknig that puppet is running, etc? 15:44:28 <mwichmann> except for 390, which may take a week to build some :) 15:44:53 <licquia> orc_fedo_: buildbot has the "checkin" part for builders, so could possibly write a nagios check for that 15:44:59 <orc_fedo_> mwichmann: no -- not having poppet do that but a light side montofing process 15:45:00 <licquia> (for the alerting) 15:45:15 <orc_fedo_> licquia: may exist already -- lemme look 15:45:54 <licquia> as for puppet, i know checks exist, but they involve nrpe checks on every system, which is a pain 15:46:48 <licquia> may be better options, not sure if i can get the master to report on "old" agent statuses 15:47:39 <licquia> !fhsbug 105 15:47:43 <lsbbot> licquia: 04Bug http://bugs.linuxfoundation.org/show_bug.cgi?id=105 normal, P2, ---, licquia, REOPENED , A standardised place for Maildir mailboxes - is this /var/mail ? 15:49:19 <licquia> i think part of the deal here is that people like to argue about what the proper implementation should be 15:49:27 <licquia> which is fine, but not part of the fhs :-) 15:50:54 <mwichmann> the part that motivates people to need this is "if there isn't a standard place, selinux is going to have a hairball, because it won't be in any default rule" 15:51:13 <mwichmann> to which I'm tempted to snipe: you shouldn't be using selinux 15:51:33 <orc_fedo_> heh 15:52:29 <licquia> to which i say: which distros ship selinux policy that allows for maildirs? and where do they put them? 15:52:55 * licquia suspects the answers are "none" and "no idea", which makes it "not our problem" 15:53:27 <orc_fedo_> re-genning selinux policy files is kind of a black art, but RHT ships them 15:53:30 <orc_fedo_> dunno suse 15:53:47 <orc_fedo_> debian has been edging toward selinux more 15:53:52 <mwichmann> suse /was/ using the other system, dunno if they drank the coolaid and switched 15:54:15 * licquia thought system-level mail on rh/fedora/centos was still mbox 15:54:31 <licquia> fairly sure it's mbox by default on debian 15:54:37 <licquia> ditto for ubuntu 15:54:44 <orc_fedo_> but the broader question seems: should we be requireing an mbox or such to exist anywhere, compared to slotting email into a DB or such 15:54:51 <mwichmann> apparently something went into a RH guide, but as I'm not a subscriber I can't see the article 15:55:13 * licquia closed it with NOTOURBUG 15:55:32 <mwichmann> okay, I'm happy: it's no longer REOPENED 15:55:37 <orc_fedo_> outbound queues would vary, but I think we can say: distro's free choice on a /var/spool/mail or whatever 15:55:39 <licquia> #agreed close fhs bug 105 as not our bug 15:55:43 <orc_fedo_> concur 15:56:31 <licquia> !lsbbug 3827 15:56:33 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3827 normal, P2, ---, licquia, ASSIGNED , libstdcpp-tests failing to build on some archs 15:56:52 <orc_fedo_> licquia: nagios and a tool to tie puppet to SNMP exists ... enabling SNMP visibility would be new on that unit though, I think 15:56:59 <mwichmann> as of today, more of them than before! 15:57:09 <licquia> this now appears to have spread to other archs 15:57:34 <licquia> i expect to see ia64 to join the party once that rebuild happens 15:57:52 <orc_fedo_> always the trendsetter, that ia64 15:58:04 <mwichmann> running behind, in this case 15:58:22 <licquia> oddly, x86 succeeded; wonder why? 15:59:09 <licquia> aha; probably because x86 is f16 15:59:40 <licquia> possible that ia64 will succeed, then (it's sles11) 15:59:41 <mwichmann> gcc version likely the trigger, yes 15:59:56 <mwichmann> since we dinna change any code 16:00:53 <mwichmann> oddly... there seems to be a way to get besteffort.o involved for c++ code, there may still be a bug in that path (and likely unrelated to this problem) 16:01:46 <licquia> might deserve its own bug, if confirmed 16:02:19 <mwichmann> 20_util/functional/binders/1.cc : FAIL 16:02:19 <mwichmann> 20_util/functional/binders/1.cc (test for excess errors) 16:02:19 <mwichmann> DGTest.excess_errors: 16:02:19 <mwichmann> 16:02:19 <mwichmann> c++: /opt/lsb/lib-5.0/besteffort.o: linker input file unused because linking not done 16:02:36 <licquia> hmm, interesting 16:04:06 * licquia votes to make this bug high priority and tie to 4.1 updates 16:04:12 <mwichmann> there's a bunch of those (this is in the successful log on x86 by the way, so it's not breaking things) 16:04:16 <licquia> high priority, b/c it affects beta 16:04:21 <mwichmann> yup 16:04:34 <mwichmann> I think that's right 16:04:53 <mwichmann> the other high-prio one is the gdk3 header 16:05:05 <licquia> yup 16:05:26 <mwichmann> so you have some fun ahead of you :) 16:06:10 <licquia> #agreed mark 3827 high priority, target 4.1 updates and 5.0 16:06:22 <licquia> ok, looks like top of the hour; last call 16:07:48 <licquia> #endmeeting