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