Plan for tomorrow's FESCo meeting (2010-09-21)
kevin at scrye.com
Tue Sep 21 21:45:59 UTC 2010
#fedora-meeting: FESCO (2010-09-21)
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
* init process (nirik, 19:30:01)
* mclasen said he would be a few minutes late. (nirik, 19:30:29)
* kylem said he would not be able to make it today. (nirik, 19:30:40)
* pjones is vacationing on a tropical beach (nirik, 19:31:06)
* currently present are nirik notting mjg59 ajax SMParrish (nirik,
* Updates policy / Vision implementation status (nirik, 19:33:56)
* fesco track has ticket types and templates for 'updates issues' and
'update exception request' (nirik, 20:06:37)
* ACTION: nirik to ask for feedback from developers on
* LINK: https://fedorahosted.org/fesco/newtplticket (nirik,
* http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik,
* will defer this for now. Try and get NM maintainer and feature owner
together to work things out. (nirik, 20:14:01)
* http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik,
* will defer to next week (nirik, 20:20:36)
* #469 App install related issues (nirik, 20:20:40)
* will revisit this next week and try and have all interested parties
here to hash out a solution. (nirik, 20:34:15)
* #470 Look at buildid repo request from jkratoch (nirik, 20:34:52)
* LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2387
* will try using the mash data, see if it meets needs. (nirik,
* #464 Fix nss update issues (nirik, 20:49:02)
* LINK: https://fedoraproject.org/wiki/Updating_NSS (nirik,
* documenting update process for nss packages. (nirik, 20:51:20)
* going to try and simplify packaging (nirik, 20:51:27)
* #467 Make Feature Freeze happen sooner. (nirik, 20:52:19)
* will ask for clarification on what is exactly being proposed and
revisit. (nirik, 21:07:51)
* #468 Evaluate incomplete Fedora 14 Features (nirik, 21:09:13)
* LINK: https://fedoraproject.org/wiki/Features/Python_2.7 has 4
packages left to rebuild (nirik, 21:10:06)
* LINK: https://fedoraproject.org/wiki/Features/GNUstep is at 90%
* LINK: https://fedoraproject.org/wiki/Features/D_Programming is at
99% (nirik, 21:11:07)
* 3 features are still not 100% (nirik, 21:17:06)
* will work with feature owners to make sure they are 100% asap
* Open Floor (nirik, 21:18:09)
19:30:01 <nirik> #startmeeting FESCO (2010-09-21)
19:30:01 <zodbot> Meeting started Tue Sep 21 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:29 <nirik> #info mclasen said he would be a few minutes late.
19:30:34 <ajax> what up
19:30:40 <nirik> #info kylem said he would not be able to make it today.
19:30:59 <mjg59> Afternoon
19:31:05 <mjg59> nirik: I suspect that pjones is still unavailable
19:31:06 <nirik> #info pjones is vacationing on a tropical beach
19:31:12 <nirik> yeah.
19:31:19 <ajax> apologies in advance for being derelict on anything i've been derelict on, i was out of the country last week
19:32:02 * nirik looks around and sees only 3 of us so far.
19:32:18 * SMParrish here
19:32:18 * notting is here
19:32:35 <nirik> cwickert: you around?
19:33:18 <nirik> thats 5 in any case... so I guess we can get started.
19:33:40 <nirik> #info currently present are nirik notting mjg59 ajax SMParrish
19:33:52 <mjg59> 5 appears to be our lucky number
19:33:53 <nirik> Our favorate topic in the world:
19:33:56 <nirik> #topic Updates policy / Vision implementation status
19:33:56 <nirik> .fesco 351
19:33:56 <nirik> .fesco 382
19:33:56 <nirik> .fesco 454
19:34:00 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:34:04 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:34:08 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454
19:34:31 <nirik> So, I hacked some more on: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft the other day.
19:34:57 <SMParrish> and I worked on the KDE updates policy draft as well https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
19:35:05 <nirik> SMParrish: cool.
19:35:20 * nirik reads
19:35:28 * rdieter lurks
19:35:56 <ajax> nirik: nice! reading the diff now.
19:36:33 <mjg59> SMParrish: I've been looking at the KDE situation some more. My main concern is the tendancy for new KDE releases to require new Qt
19:36:34 <ajax> looks uncontroversial (and good)
19:36:50 <mjg59> There seem to have been a few cases where Qt updates have broken non-KDE Qt apps
19:37:00 <mjg59> And when I saw "a few", I really do mean a few
19:37:01 <nirik> so, basically this means there would be one expected kde exception per release?
19:37:04 <mjg59> It's not the common case
19:37:18 <SMParrish> mjg59: That is always a possiblity, in fact qt4.7 was just released
19:37:37 <mjg59> SMParrish: Yeah. So if KDE 4.5 goes into 13, qt gets bumped as well, right?
19:37:40 <rdieter> nirik: at most 1, could be 0
19:37:53 <SMParrish> mjg59: yes
19:37:57 <mjg59> So ideally the testing coverage isn't just KDE, it's the entire Qt dependency tree
19:38:30 <notting> i still find it odd on a logical level... 'we don't do feature/major updates, except this one we do each release'
19:38:36 <mjg59> I'm also a bit concerned by cases like the Dolphin tooltips
19:38:39 <nirik> notting: yeah.
19:38:55 <mjg59> (summary: dbus threading bug means that the KDE filemanager in 4.5 can lock up randomly)
19:38:55 <nirik> but it is a case where upstream just is not aligned with our release cycle at all... ;(
19:39:03 <ajax> it makes me want to release kde on its own schedule.
19:39:04 <SMParrish> The big issue is that the KDE SIG feels they should be one defining who their target audience is and what updates to provide to them.
19:39:58 <mjg59> So, my concern with KDE updates in a stable release don't really centre around KDE at all. It's the fact that KDE updates often require updates of other system components.
19:39:58 * thomasj lurks
19:40:14 <mjg59> For 4.5 to be stable, right now we'd need to update dbus
19:40:35 <rdieter> mjg59: the dbus problem is in kde-4.4 *now*, it's not exactly a regression
19:40:54 <mjg59> rdieter: Oh? The conversation seemed to surround it being much more of an issue in 4.5
19:41:16 <rdieter> mjg59: it does seem to affect *some* users more now, but the problem remains the same
19:41:43 <rdieter> mjg59: in particular, users who enable some non-default preferences
19:42:19 <notting> SMParrish: by logical extension, then the games sig defines their own audience, the desktop sig does, the firefox sig/maintainers do, and they each have their own separate update policy, and we have the same chaos now that the board requested we fix
19:42:36 <mjg59> rdieter: Well, my point was that the dbus update would change dbus's threading behaviour (in a good way, but...) and again we risk breaking non-KDE components
19:42:50 <notting> SMParrish: for a more concrete example, the FEL sig used KDE as a base, so what happens when their target's expectations clash?
19:42:51 <nirik> I think this policy may be the best we can do without more repos, so I would be willing to give it a go and see if it's workable.
19:42:55 <mjg59> The same if it ends up needing a newer fontconfig, or any other commonly used bit of code
19:42:56 <rdieter> mjg59: true, I'm not arguing for a dbus update
19:43:11 <skvidal> quick question
19:43:18 <skvidal> if we took kde out of the discussion
19:43:22 <skvidal> and said 'firefox' instead
19:43:25 <SMParrish> notting: that may be, the SIGs were given the autonomy to make those decisions for themselves
19:43:29 <skvidal> let's say firefox releases were not in sync
19:43:46 <skvidal> and with each new release firefox immediately deprecated the previous one and would not update it
19:43:52 <skvidal> what would we be doing?
19:43:58 <Oxf13> skvidal: perhaps firefox isn't the best example, because firefox I think was already an exception somewhat to the update rule
19:44:11 <Oxf13> wait, n/m, I think I'm thinking of another OS
19:44:16 <nirik> skvidal: I would suspect something similar to this proposal.
19:44:18 <gholms> Why does Firefox get a free pass?
19:44:25 <skvidal> gholms: it doesn't
19:44:28 <skvidal> so
19:44:32 <nirik> gholms: it does not.
19:44:41 <gholms> Whew, sorry.
19:44:47 <skvidal> nirik: so we're going to end up walking back the policy for anything that hits a lot of people?
19:44:49 <ajax> we'd probably look at what firefox expects in terms of OS requirements
19:44:50 <nirik> currently it's release cycle aligns ok with fedora's.
19:44:53 <skvidal> nirik: or that impacts a lot of people?
19:45:01 <skvidal> nirik: or that a lot of people complain about?
19:45:07 <ajax> in the firefox case, it doesn't really expect a lot...
19:45:25 <skvidal> ajax: xulrunner isn't involved?
19:45:34 <mjg59> skvidal: If Firefox did that, we'd probably be investing engineering time into supporting Firefox
19:45:42 <mjg59> skvidal: I suspect that other distributions would be as well
19:45:55 <skvidal> mjg59: hmm, okay.
19:45:58 <nirik> skvidal: no, I don't think so. I think in cases where upstream release doesn't match up at all with fedora releases, the maintainer(s) can ask for an exception, we can then decide it on a case by case basis.
19:46:26 <ajax> skvidal: mmm. xr doesn't have a huge amount of users outside other moz projects, but fair, i'd forgotten about that
19:46:49 <mjg59> I am minded to say that exceptions are reasoanble for closed sets of well-bounded code which don't have a significant impact upon the rest of the distribution
19:47:12 <mjg59> And that KDE would meet that *if* it doesn't require an update of any non-KDE libraries or daemons. Which would forbid qt updates.
19:47:30 <rdieter> mjg59: agreed, for the sake of this argument, take qt out of the equation
19:47:40 <notting> SMParrish: but if the board is asking us to set an update policy for Fedora, they are (implicitly, if not explicitly) saying *don't* leave it up to the SIGs
19:47:47 <nirik> mjg59: well, thats one part of it sure... but also if the upstream doesn't support the current release anymore, and their are bugs or security issues that can't be backported, etc.
19:47:50 <SMParrish> The issue with KDE is there is no support for previous releases. If there are bug & security fixes they are rolled into the following months release. The KDE sig does not have the manpower to backport these fixes, so a 4.(x+1) bump is going to happen during a fedora release
19:48:10 <nirik> rdieter: can you do a kde update with no qt update?
19:48:14 <rdieter> nirik: yes
19:48:18 <nirik> do they keep supporting the older qt?
19:48:21 <mjg59> SMParrish: So, what do we do when that results in updates that break non-KDE applications?
19:48:46 * mclasen walks in
19:49:01 <nirik> ok, we are at 15min here folks. Votes to keep going?
19:49:08 <thomasj> mjg59, what non-KDE apps do you have in mind?
19:49:10 <nirik> +1 from me. I would like to see more...
19:49:17 <mjg59> nirik: +1
19:49:30 <SMParrish> notting: yes but I dont think the boards mandate was a brick wall saying no updates just make sure what you do works and has no impact on the user experince. The KDEsig works hard to make sure everything is tested and ready to go before pushing to stable
19:49:33 <ajax> +1 continue
19:49:35 <SMParrish> nirik +1
19:49:48 <mjg59> thomasj: Anything that uses libraries which KDE requires a newer version of
19:49:48 <notting> nirik: i'm +1, although what is the end goal of this conversation? are we intending to approve something today?
19:50:04 <mjg59> thomasj: If we don't have to update any of those then there's much less of an issue
19:50:12 <SMParrish> notting: that is why KDE4.5 has not been pushed yet, we are not satisfied that it is ready
19:50:14 <nirik> notting: good question. I don't know...
19:50:30 <mjg59> notting: From my point of view, I'm interested in determinign what the expected boundaries of the exception process are
19:50:52 <nirik> I don't know that the proposed kde process needs anything from us... that basically just says they will request an exception 0 or 1 times per release, right?
19:51:03 * cwickert is sorry to be late
19:51:20 <SMParrish> nirik: right
19:51:24 <mjg59> nirik: I think it's interesting to work out whether or not we'd be likely to say yes to such a request
19:51:26 <nirik> cwickert / mclasen: we are talking about: https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
19:52:03 <nirik> mjg59: sure. I think you are right that with no qt update in the mix it would be easier to say yes...
19:52:28 <mjg59> I'm leaning towards it being ok to update KDE providing that it doesn't bump more generic code in the process. We'll be providing an alternative and functional desktop that doesn't have significant changes during the release, and I think it's reasonable to indicate to users that they should use Gnome if that's what they want
19:53:08 <mjg59> But I pretty strongly think it's unreasonable to update components used by non-KDE packages
19:53:38 <SMParrish> mjg59: I could go along with that
19:53:39 <nirik> of course unless it's needed to fix a serious bug or security issue...
19:53:56 <nirik> ok, so, where are we here then?
19:54:00 <notting> i like the idea of solving the issue that the SIG doesn't have the resources to backport security fixes if needed
19:54:22 <nirik> notting: how can we do that?
19:54:23 <notting> that may or may not be trivial. but it's work that is being done at some level for other OSes
19:54:35 <mjg59> Yeah. For widely used code, it really should be the case that SIGs are able to maintain releases without upstream support.
19:55:07 <mjg59> Does Suse bump KDE in released versions?
19:55:08 <rdieter> notting: true, our efforts include playing a more active role in upstream developement and release-engineering efforts
19:55:16 <SMParrish> notting: have RH hire a few KDE devs :)
19:55:17 <rdieter> mjg59: no
19:55:32 <mjg59> rdieter: How do they manage KDE security?
19:55:33 <SMParrish> mjg59: but we are not Suse either
19:55:49 <nirik> it would also be good longer term to try and get them to either release on a slightly better cycle, and/or somehow support some fixes for the older releases...
19:55:58 <nirik> but thats all longer term
19:56:00 <thomasj> mjg59, they have apid developers working on KDE
19:56:00 <notting> SMParrish: that's not a very community-scalable process
19:56:05 <thomasj> *paid
19:56:15 <mjg59> thomasj: Well, yeah, but they backport security fixes?
19:56:24 <thomasj> mjg59, the paid ones, yes
19:56:39 <mjg59> thomasj: So there's a maintained branch of old KDE versions?
19:56:49 <thomasj> mjg59, not really.
19:56:54 <rdieter> mjg59: suse manages that a bit painfully, I'd imagine
19:56:57 <Oxf13> doesn't RHT have paid developers working on KDE?
19:57:06 <thomasj> mjg59, it gets security fixes, that's it. if you call that maintained..
19:57:07 <Oxf13> couldn't the two sets work together?
19:57:16 <mclasen> Oxf13: yes, we do
19:57:35 <ajax> one or two, yeah.
19:57:43 <SMParrish> Oxf13: Yes and they do work with the SIG but they are a small handfull and have other duties as well
19:57:44 <mjg59> rdieter: But if someone's doing the security backports, why is it a problem that the KDE SIG don't have the manpower to do so?
19:57:57 <mjg59> rdieter: Extracting the patches from Suse shouldn't be a problem
19:58:32 * skvidal wonders about relying on suse's paid development....
19:58:33 <rdieter> mjg59: sure
19:58:51 <mjg59> rdieter: So the security argument doesn't seem compelling
19:58:54 * cwickert wonders just like skvidal
19:59:01 <SMParrish> mjg59: Keep in mind that Fedora KDE is basically a vanilla KDE, not sure what Suse may do to customize theres could be alot of work
19:59:04 <mjg59> At present, anyway
19:59:21 <rdieter> mjg59: imo, it is not, it's mostly about bugfixes that land only in branch+1
19:59:34 <mjg59> SMParrish: Sure. I'm just saying that I'm not going to vote for an exception on the grounds of security if it looks like all the necessary work is being just over -> there
19:59:41 <cwickert> mjg59, their branding is in a separate package, so the base should be vanilla kde too
20:00:12 <nirik> ok, for me I think this boils down to: the kde sig plan is ok, they should work to minimize changes they do intend to land to make it easier for an exception to be granted. Longer term: work to make upstream kde better so we don't have to do exceptions...
20:00:53 <cwickert> nirik, I doubt that the upstream part will be succesfull
20:00:56 <ajax> nirik: seems as reasonable as we're likely to get
20:01:00 <mjg59> Instead I'd like to concentrate on ensuring that there's security support for the version we shipped, and make it easier for users to *optionally* get feature updates of software
20:01:10 <nirik> cwickert: surely not quickly, but over time it could be...
20:01:16 <cwickert> and I really think that KDE users always want the latest and the greatest, cause that's what KDE is like
20:01:22 <mjg59> But I'm not strongly wed to that, and even if that's the future I'd like I don't see a huge problem with KDE udpates
20:01:52 <thomasj> cwickert, +1
20:01:52 <ajax> i do feel a bit surprised that security backports are considered such a huge blocker
20:02:17 <notting> cwickert: if we have a backports repo (which has been proposed), it seems like a great candidate for that
20:02:17 <ajax> but maybe that's because being someone who's actually written security fixes is sort of a rare thing
20:02:29 <cwickert> notting, indeed
20:02:29 <nirik> also as the 4.x series goes along, I would hope that the amount of user visible changes would go down.
20:03:14 <nirik> so, re: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft anyone have any changes they would like to make to that?
20:03:43 <SMParrish> nirik: and that is what we are seeing. Upstream is really working on stability and polish atm
20:03:50 <nirik> I think I would like to call for maintainer feedback on it and see if we can polish it over the next week, then next week vote on it?
20:04:11 <ajax> nirik: looks pretty good to me, thanks for running with it.
20:04:33 <mjg59> nirik: "Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update. "
20:04:38 <mjg59> nirik: Must coordinate?
20:04:40 <nirik> I know it may result in more flames on the list, but I would really like to get feedback and buyin from folks if possible.
20:04:59 <nirik> mjg59: depending on which section, sure. ;) Feel free to change.
20:05:14 <mjg59> nirik: Ideally autoqa would notice a soname bump and tell you how to do that, I guess
20:05:32 <mjg59> nirik: But otherwise, I think this is really solidifying
20:05:36 <nirik> mjg59: yeah. I added a 'We will add autoqa info when it's ready" at the end.
20:05:54 <SMParrish> nirik: Looks good and seems to address the issues
20:06:02 <wwoods> mjg59: tell you how to do what, a side tag mass-build?
20:06:12 <nirik> Oh, I also added 2 things to the fesco track:
20:06:22 <mjg59> wwoods: Yeah, or at least tell you who to talk to to arrange one
20:06:37 <nirik> #info fesco track has ticket types and templates for 'updates issues' and 'update exception request'
20:07:50 <nirik> ok, so ask for feedback and vote on this next week?
20:07:55 <nirik> anything further on updates from anyone?
20:08:21 <nirik> #action nirik to ask for feedback from developers on https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
20:08:24 <gholms> "fesco track"?
20:08:33 <ajax> ithm "trac"
20:08:39 <gholms> Ah
20:08:40 <nirik> trac, sorry
20:08:48 <nirik> https://fedorahosted.org/fesco/newtplticket
20:09:41 <nirik> ok then, moving on.
20:10:04 <nirik> #topic http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
20:10:05 <nirik> .fesco 434
20:10:06 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434
20:10:09 <nirik> any news here?
20:10:35 <mclasen> dcbw left his comments on the talk page
20:10:50 <nirik> I see that... yeah.
20:10:55 <mclasen> he's implementing caching in nm
20:11:03 <mclasen> not sure if he's had any contact with the feature authors
20:11:34 <mjg59> I think we're just going to have to ignore this until the feature appears
20:11:44 <ajax> i still expect this to break some kinds of wifi login redirects, but i'm okay with that
20:11:49 <mjg59> It would be nice to have default dnssec support out of the box
20:11:58 <mjg59> And I think that's something we should advertise
20:12:07 <nirik> yeah...
20:12:12 <mjg59> But this really needs to be happening as part of NM development, not Fedora development
20:12:21 <nirik> I wonder why the NM maintainer isn't feature owner here? since it's all in NM right?
20:12:37 <mjg59> nirik: At a guess, because nobody talked to him
20:12:41 <notting> it looks like a reasonable thing to have and tout as a feature, but there are the real roadblocks w.r.t. NM changes. so i'm leery to approve it until those roadblocks are worked out
20:12:52 <ajax> an excellent question! "this would be a cool feature, you should implement it for us"
20:13:02 <SMParrish> mjg59: I agree should be part of NM
20:13:08 <mclasen> if anything, nm will probably just grow the caching support without this feature being involved...
20:13:16 <mjg59> Right. I'm not going to vote for it until there's evidence that it's going to land in the nm tree
20:13:27 <nirik> ok, so defer for now?
20:13:31 <mjg59> I suspect that this is a failure of RH internal process, but...
20:13:44 <ajax> yeah, defer
20:14:01 <nirik> #info will defer this for now. Try and get NM maintainer and feature owner together to work things out.
20:14:05 <SMParrish> I agree defer
20:14:19 <nirik> #topic http://fedoraproject.org/wiki/Features/GoldLinkerDefault
20:14:20 <nirik> .fesco 423
20:14:21 <zodbot> nirik: #423 (F15Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423
20:14:23 <nirik> any news on this one?
20:14:51 <nirik> I don't see any.
20:14:54 * mclasen hasn't heard anything
20:14:59 <nirik> I can mail the feature owner directly for next week.
20:15:04 <cwickert> nothing on the talk page
20:15:08 <ajax> that was on me
20:15:18 <ajax> and i dropped it on account of xds
20:15:27 <jankratochvil> prelink has been fixed upstream.
20:15:39 <jankratochvil> That is gold for prelink (not prelink).
20:16:10 <mclasen> are we planning a mass rebuild for f15, anyway ?
20:16:22 <Oxf13> "planning"
20:16:27 <nirik> mclasen: not that I know of yet...
20:16:27 <ajax> i don't know of one planned
20:16:42 <Oxf13> generally I don't plan one, and wind up getting notified last minute that we need one :/
20:16:51 <Oxf13> so at this time, no we are not planning a mass rebuild.
20:16:54 <ajax> prelink was the only major objection i knew of that simply switching to ld.bfd wouldn't fix.
20:17:20 * mclasen points out the gold feature page talks about 'rebuild everything'
20:17:38 <drago01> so lets plan one ;)
20:17:39 <nirik> what about the kernel?
20:17:48 <nirik> and/or anything else that needs to not use it.
20:17:50 <notting> mclasen: that almost looks to be a QA step
20:17:59 <ajax> nirik: that falls under ld.bfd
20:17:59 <notting> mclasen: i.e., 'rebuild everything to make sure it's not broken'
20:18:02 <notting> could be done on the side
20:18:38 <nirik> ajax: yeah, but how does a package use that? is there some easy way in the spec?
20:19:04 <nirik> anyhow, lets ping the feature owner, get more info and revisit next week?
20:19:25 <ajax> nirik: for most makefiles "make LD=ld.bfd" would be enough, i suspect.
20:19:30 <mjg59> nirik: +1
20:19:40 <nirik> cool. I was thinking it would be more of a pain.
20:20:04 <nirik> any objections to defer?
20:20:12 * nirik will move on in a minute if none.
20:20:36 <nirik> #info will defer to next week
20:20:40 <nirik> #topic #469 App install related issues
20:20:40 <nirik> .fesco 469
20:20:42 <zodbot> nirik: #469 (App install related issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/469
20:20:55 <nirik> see https://bugzilla.redhat.com/show_bug.cgi?id=488968
20:20:59 <nirik> and discussion on the devel list.
20:21:52 <nirik> rhughes asked us to discuss this.
20:22:07 <ajax> man, that thread hit my tl;dr meter in a serious way.
20:22:43 <SMParrish> was an intersting read
20:22:46 <mjg59> I propose that we just remove all applications from the distribution
20:22:58 <skvidal> the only important criteria in the discussion, imo, is whethere or not repodata should be in the repodata or in a pkg in an rpm in the distro
20:23:00 <nirik> mjg59: hurray! less files.
20:23:00 <geppetto> ajax: I think all the info. was in the BZ
20:23:08 * gholms quietly removes his packages' .desktop files
20:23:11 <mclasen> the question here is in what form to provide additional app-centric metadata
20:23:19 <drago01> summary "disagrement on implementation - packagereview being blocked because it is 'the wrong way' (tm)"
20:23:40 <ajax> geppetto: 44 comments aren't a lot better than 44 emails. but yeah.
20:23:41 <mjg59> Putting it in repodata is certainly ideologically cleaner, but I'm not convinced that it works better
20:24:00 <geppetto> mjg59: How is it worse?
20:24:06 <SMParrish> mjg59: I agree, repodata will bloat
20:24:11 <nirik> we did in the past ship some things like this as packages, and we decided that was a bad idea and stopped doing that.
20:24:13 <skvidal> SMParrish: will bloat?
20:24:20 <skvidal> SMParrish: it is in a separate file
20:24:24 <skvidal> how is 'bloat' important?
20:24:33 <gholms> Will it matter? You can download it only when necessary.
20:24:41 <skvidal> nirik: specspo, comps - as a point in fact
20:24:42 <drago01> the word 'bloat' is way overused ... but ot
20:24:52 * mclasen does rpm -q specspo
20:25:00 <mclasen> specspo still around, how did we stop ?
20:25:01 <skvidal> mclasen: yah - useful isn't it?
20:25:15 <geppetto> mjg59 SMParrish: As I said in the BZ, it's less data than primary … and is much less likely to grow at the same rate
20:25:22 <mjg59> The main issue with doing it in repodata is that if you want any per-spin policy you still need to have data in the archive
20:25:23 <nirik> 'but we are trying to quit' :)
20:25:26 <notting> mclasen: honestly, specspo is still around because we've been too lazy to block it
20:26:01 <mjg59> On the other hand, requiring periodic manual updates of the package isn't sane
20:26:11 <mjg59> And how does it interact with updates-testing?
20:26:26 <mjg59> Or, indeed, updates?
20:26:43 <Oxf13> or rpmfusion?
20:26:46 <mjg59> Yeah
20:26:54 <Oxf13> can the package data be layered?
20:27:03 <mjg59> I think the base data source has to be repodata
20:27:05 <nirik> Oxf13: I was just wondering that.
20:27:08 <mclasen> mjg59: the expectation is that app data is fairly static
20:27:17 <mjg59> mclasen: Well, yeah, but it's not
20:27:19 * mclasen realizes he forgot to invite hughsie to this discussion
20:27:22 <nirik> rpm 'seed' that has data as of GA, and repodata update?
20:27:25 <mjg59> mclasen: People add new packages to existing distributions
20:27:31 <nirik> mclasen: if you can find him that would be great.
20:27:41 <skvidal> nirik: repodata updates a file put in place via pkg?
20:27:48 <notting> probably a bit late in the day for hughsie
20:27:50 <mjg59> nirik: It's 9:30PM in the UK, so he may well not be around
20:27:50 <skvidal> nirik: so rpm -V will show...
20:27:55 <mclasen> he didn't feel well earlier today, he's probably offline
20:28:06 <geppetto> mclasen: Except you just said firefox and KDE are going to get big updates for every release … so, not so much
20:28:07 <nirik> skvidal: no, tools look for repodata and fall back to seed?
20:28:09 <SMParrish> hughsie is not online -(
20:28:22 <skvidal> nirik: umm..
20:28:22 <geppetto> mclasen: In fact I can't think of any release of any distro. where it wouldn't have changed a few times
20:28:45 <nirik> ie if you are offline? or I guess just say you can't do it unless you are... not sure it buys us much
20:28:49 <SMParrish> I would personally like to get him here to discuss this before we take any action
20:28:52 <mjg59> mclasen: So if two packages get added to updates-testing and the data gets updated there, and then only one of those packages goes through to stable, what happens?
20:28:59 <skvidal> nirik: and offline caches work in yum now anyway
20:29:11 <mclasen> geppetto: I said what ?
20:29:11 <nirik> yeah, so if they were ever online to get it thats moot.
20:29:49 <geppetto> mclasen: You said that it was mostly static, I think in response to the question about how you sync. it if it's in a package
20:29:50 * nirik thinks repodata seems much more sane, but I'd like to see if we can address hughsie's issues with it.
20:30:10 <geppetto> mclasen: I'm just saying … I very much doubt it's mostly static
20:30:16 <mjg59> I'd like to see a proposal for how to keep it in sync with the updates/multiple repo case before deciding anything
20:30:21 <nirik> some of them seem solveable... like the 4hours per run... if it cached all things that didn't change, it should be much faster than thaty.
20:30:21 <mjg59> And I think we need to speak to hughsie about it
20:30:31 <geppetto> mclasen: Well maybe compared to primary, but not objectively
20:30:38 <Oxf13> I'd hate to see this issue get delayed again, but from the outside I don't think it'd be very nice to make a decision without having hugsie here to present his case
20:30:39 <mclasen> geppetto: sure, new apps will happen, but I don't think it is very common for an app to change its icon or menuitem text mid-release
20:30:40 <mjg59> If doing it in packages can be made to work sanely then I don't object to it
20:30:42 <nirik> so where does the pkgdb data fit in here?
20:31:00 <skvidal> nirik: that's a whole other issue
20:31:11 <skvidal> nirik: the pkgdb folks were working on their db 1.5-2yrs ago now
20:31:13 <skvidal> and implemented it
20:31:31 <nirik> right, it would be nice to use the same data and have ratings, etc feed into the same place.
20:31:32 <skvidal> I don't know the background on when richard started working on this or if he talked to them
20:31:55 <mclasen> skvidal: he started about the same time, and he did talk to them
20:31:56 <skvidal> from the posts from maplloin and mbacvosk - it seems he didn't talk to them
20:32:07 <skvidal> mclasen: weird - mbacovosk said he had never heard of it
20:32:09 <skvidal> in an email
20:32:09 <skvidal> today
20:32:17 <mclasen> yeah,thats wierd indeed
20:32:38 <nirik> so, defer to next week, try and make sure hughsie can make it and we can try and hash out a solution?
20:32:42 <mclasen> I know for a fact that they have talked about this (they are both in my team, after all...)
20:32:49 <skvidal> mbacovosk?
20:33:06 <ajax> yep!
20:33:13 <SMParrish> nirik: +1
20:33:14 <skvidal> hmm, I didn't know who he worked for
20:34:15 <nirik> #info will revisit this next week and try and have all interested parties here to hash out a solution.
20:34:24 <nirik> any objections? will move on in a minute.
20:34:50 <nirik> ok, moving on then...
20:34:52 <nirik> #topic #470 Look at buildid repo request from jkratoch
20:34:52 <nirik> .fesco 470
20:34:54 <zodbot> nirik: #470 (Look at buildid repo request from jkratoch) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/470
20:34:55 <notting> yeah, i mentioned in e-mail response to hughsie that we were discussing this today and offered an invitation to come. wasn't really forecful about requiring him come
20:35:20 <nirik> notting: yeah, he was cc'ed on the fesco ticket as well. Sounds like he's under the weather. ;(
20:35:49 <nirik> so, this is a request for buildid features.
20:36:06 <nirik> basically they want a repo that has all debuginfo packages for all packages ever built/shipped.
20:36:35 <nirik> our build wrangler and infrastructure lead both said this is not possible.
20:36:40 <jankratochvil> Even the binary rpms, not just debuginfo packages.
20:36:41 <nirik> https://fedorahosted.org/fedora-infrastructure/ticket/2387
20:36:52 <ajax> ha ha ha ha ha good one.
20:36:55 <nirik> jankratochvil: what action are you hoping for here?
20:37:28 <jankratochvil> At least an approval if there would be viable way that it should be done.
20:37:43 <nirik> we simply don't currently have the infrastructure to make a massive 'everything ever made' repo.
20:37:56 <notting> well
20:38:00 <jankratochvil> I would say yum as-is may be acceptable and I would prefer numbers why it is not acceptable.
20:38:08 <notting> if we're ever going down the road of debuginfo-fs, this would be part of that
20:38:08 <nirik> I think the solution would be best made with upstream koji development... find some way to store the info you need in the db.
20:38:34 <skvidal> everything ever made.... is gonna be a lot of pkgs....
20:38:34 <ajax> notting: ennh. not really?
20:38:38 <jankratochvil> Such repository would be useful only to the package maintainers for Bugs triaging; so it does not have to be perfectly performance wise, just bearable.
20:38:54 <notting> ajax: you need a repo of 'everything'
20:38:56 <skvidal> my concern is not performance of yum once it has the repodata
20:38:57 <nirik> 31GB of repodata is bearable?
20:39:03 <skvidal> it's getting the repodata
20:39:07 <skvidal> that makes me want to cry
20:39:22 <ajax> the only reason that "everything ever" would be useful, in a difs kind of world, is if you get a bug report from a user who's not updated in ages and his debuginfo packages have been gc'd away
20:39:22 <skvidal> screw worrying about deltas - the first time is gonna be the bludgeon
20:39:27 <jankratochvil> notting: As I said for the bugs triaging debuginfo rpms are not enought, you should setup a system with equivalent package NVRAs as the reporter had.
20:39:27 <Oxf13> yeah, that's a giant download
20:39:31 <nirik> jankratochvil: so the use case here is: someone has a crash with some packages that are no longer shipped?
20:39:34 <Oxf13> not to mention that the createrepo task would never finish
20:39:49 <skvidal> Oxf13: hey - maybe we should just throw cpus at it :)
20:39:52 <Oxf13> every time it would finish a run (which would take hours) there would be another few hundred packages built and the repodata would be out of date
20:39:54 <ajax> and i think the answer for that scenario, particularly for a rawhide kind of world, is "harden up and update"
20:40:15 <dgilmore> nirik: I spoke with the koji devs we feel it should be a standalone app
20:40:26 <dgilmore> we dont feel it belongs in koji
20:40:36 <jankratochvil> ajax: In fact every bugreport has at least one package updated. Triaging a backtrace to find out after an hour - I would need even this library but I no longer have it - so next time - is a loss of time from my experience.
20:40:53 <nirik> ajax: yeah, which is often what the developer would say... "there have been 10 releases since then, can you see if the new one fixes this"?
20:40:57 <jankratochvil> nirik: Yes, in fact the same line.
20:41:06 * skvidal hmms
20:41:20 <ajax> jankratochvil: that's "bug report is from a days-old system", not "bug report is from a months-old system"
20:41:23 <nirik> dgilmore: so something that watches builds and gathers the info in it's own db?
20:41:32 <dgilmore> nirik: yep
20:41:40 <ajax> koji's gc rate isn't that fast
20:41:58 <jankratochvil> Oxf13: I am proposing creating some repository-per-day. The yesterday builds are done, yesterday repository no longer has to be touched. Clients (bug triaged) can use many repositories for each day of the builds.
20:42:22 <ajax> i think you're solving the wrong problem
20:42:38 <Oxf13> jankratochvil: all the repositories are found on http://kojipkgs.fedoraproject.org/mash/
20:42:48 <Oxf13> and mash/updates/
20:43:00 <geppetto> jankratochvil: So you don't want "all packages" … just "all released packages for a specific release"?
20:43:13 <jankratochvil> I did not know /mash/. That may be enough.
20:43:22 <geppetto> jankratochvil: So they'd be a F-12-all, F-13-all, etc.
20:43:34 <jankratochvil> yes
20:43:55 <geppetto> Ok … you probably want to ask for that then, as that's much more doable, IMO
20:44:01 <jankratochvil> that would be in fact enough, people mixing packages across releases exist but let they be unsupported.
20:44:07 <nirik> Oxf13: that occasionally gets GCed doesn't it?
20:44:23 <geppetto> IIRC it's like 50% overhead for updates-all, vs. our current updates-latest
20:44:24 <notting> nirik: there is no automatic GC of that
20:44:29 <Oxf13> nirik: yes, but not so that you'd have less than a month of archive or so
20:44:31 <dgilmore> nirik: manually
20:44:32 <jankratochvil> If it gets GCed, nothing more can be done with it anyway.
20:44:35 <nirik> right, but releng can nuke them manually.
20:45:00 <nirik> so, where do we go on this now?
20:45:05 <jankratochvil> If you says "no such package" or if it says "404 downloading package" is not much a difference.
20:45:28 <jankratochvil> I can try this /mash/ in practice, I would say the request is resolved now, thanks.
20:45:36 <ajax> woo
20:45:47 <nirik> excellent.
20:45:52 <Oxf13> jankratochvil: sorry I didn't think to mention that to you earlier :/
20:46:02 <dgilmore> nirik: i think the most efficient is a combo build-id db app and a yum plugin to query it and grab debuginfo rpms from koji
20:46:07 <nirik> #info will try using the mash data, see if it meets needs.
20:46:21 <notting> nirik: it's sort of like the old rawhide/branched trees, which we manually GC once a year or so
20:46:26 <nirik> dgilmore: yeah, sounds reasonable...
20:46:39 <nirik> anything more on this? or shall we move on now?
20:46:48 <dgilmore> notting: ive been doing it more frequently lately
20:46:52 <skvidal> dgilmore: tie it into debuginfoinstall - since it has a bunch of other zany code
20:47:01 <jankratochvil> Some build-id only index would be small enough but that requires some yum or yum-caller coding.
20:47:03 <dgilmore> skvidal: :) that works too
20:47:18 <skvidal> jankratochvil: not terribly difficult, I suspect
20:47:52 <jankratochvil> I have to repeat debuginfo rpmsare not enough, you need even the binary rpms, readonly code/data may be needed for data analysis while not present in .debug files.
20:47:52 <nirik> ok, moving along then... thanks for the input on this one everyone...
20:48:49 <nirik> jankratochvil: ok, see how far you get with mash dirs and we can revisit after that.
20:49:02 <nirik> #topic #464 Fix nss update issues
20:49:02 <nirik> .fesco 464
20:49:03 <zodbot> nirik: #464 (Fix nss update issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/464
20:49:35 <nirik> emaldona_mtv has been documenting the update process on the nss packages.
20:50:10 <nirik> Toshio was going to look at helping him simplify the packaging.
20:50:13 <emaldona_mtv> documented what /me should have been doing
20:50:22 <nirik> https://fedoraproject.org/wiki/Updating_NSS
20:50:45 <nirik> emaldona_mtv: thanks for working on making these updates better.
20:51:10 <nirik> so, this is just FYI... if any fesco folks have input talk to emaldona_mtv or update the wiki page.
20:51:20 <nirik> #info documenting update process for nss packages.
20:51:27 <nirik> #info going to try and simplify packaging
20:51:44 <nirik> anyone have anything more on this? or shall we move on?
20:52:16 <nirik> ok, moving on...
20:52:19 <nirik> #topic #467 Make Feature Freeze happen sooner.
20:52:20 <nirik> .fesco 467
20:52:21 <zodbot> nirik: #467 (Make Feature Freeze happen sooner.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/467
20:52:33 <ajax> wow, that's some of the best best-practices doc i've seen us ever do
20:52:42 <ajax> big ups to the authors
20:54:03 <ajax> okay, that ticket makes no sense to me
20:54:45 <nirik> basically they would like to move feature freeze up a lot.
20:54:49 <ajax> "we freeze a week before alpha, and that's too soon, so we should freeze a month before alpha instead" ?
20:54:57 <ajax> so we should move it even sooner?
20:55:01 <ajax> i
20:55:03 <ajax> i don't even
20:55:55 <notting> i believe it's a reaction to us constantly slipping the alpha
20:56:02 <ajax> also i don't dig this at all from a raw development standpoint
20:56:09 <nirik> so, I think it's moving feature submission deadline earlier by 2 weeks.
20:56:10 <ajax> we wanted NFR so we'd have _more_ time
20:56:34 * nirik is also somewhat confused too tho
20:56:41 <Oxf13> well, you got more time by having the rawhide tree open while branched tree gets stable
20:57:03 <ajax> Oxf13: remind me what release was the first one developed on an NFR?
20:57:12 <Oxf13> f12
20:57:21 <Oxf13> I think f13 is the first full release with nfr
20:57:32 <Oxf13> although I may have shifted those wrong
20:57:36 <SMParrish> Oxf13: your right it was F13
20:57:41 <nirik> I think thats correct, yes
20:58:16 <Oxf13> if he's just talking about moving the feature submission deadline, I don't see a problem with that
20:58:29 <Oxf13> I'm not into moving the feature freeze much
20:58:56 <notting> but, a statement like "There's not enough time to make a good decision on whether a feature should be enabled by default (or included at all), and not enough time to fall back reliably if the go-ahead decision is changed. "
20:58:59 <nirik> I don't know that this would help prevent any slips at alpha tho... if thats the goal
20:59:04 <notting> implies that it's not talking about the submission deadline
20:59:27 <SMParrish> Oxf13: sounds more like moving the go/no go date to me
20:59:30 <notting> nirik: well, the problem is constant feature landing *at* feature freeze
21:00:03 <Oxf13> and not having enough time between feature freeze and release candidate?
21:00:04 <mclasen> I think it makes sense to know earlier about features that are coming
21:00:07 <Oxf13> I did carp about that this release
21:00:08 <nirik> perhaps we could ask the requestor here to provide a example using the f14 release? what dates would change?
21:00:15 <Oxf13> I wanted a bit more time between feature freeze and release candidate
21:00:20 <ajax> no matter when you move that deadline, someone's going to land something at the last minute.
21:00:24 <Oxf13> nirik: yeah I think that would help.
21:00:26 <Oxf13> ajax: right
21:00:48 <Oxf13> I think the only recourse is to pad the time after the deadline, and before the next deadline
21:01:03 <mclasen> ajax: if you move it, you can arrange things so that the 'last minute before feature deadline' is not also 'last minute before compose' though
21:01:15 <SMParrish> mclasen: +1
21:01:20 <notting> mclasen: yes.
21:01:21 <nirik> I'll note also that we should expand out the Feature policy some. For example, to indicate when and under what situations we enact the fallback process for them.
21:01:26 <ajax> mclasen: true.
21:01:34 <notting> mclasen: that was a plan at some point.
21:01:35 <Oxf13> mclasen: the trick is to not let people think "oh, I can just slip in the fixes after the deadline but before the REAL deadline
21:02:34 <nirik> so, ask submitter for more info and revisit?
21:02:45 <nirik> or do we have a proposal to vote on here?
21:03:29 <ajax> the schedule the submitter is asking for does have "one week between feature land and compose readiness". no?
21:03:38 <ajax> excuse me, the schedule he's objecting to.
21:03:45 <Oxf13> I would propose (off the cuff) of adding one more week between feature freeze and release candidate
21:04:17 <Oxf13> ajax: yes, I believe the current schedule has one week of time between those events
21:04:57 <nirik> so, that would move feature freeze up one week?
21:05:00 <notting> right, there is feature freeze/branch date, and one week to 'alpha change deadline'
21:05:23 <nirik> except thats not what the ticket is talking about...he's talking about feature submission deadline I thought.
21:06:27 <ajax> it sounds like we're unsure what we're voting on
21:06:35 * nirik is happy to adjust, but it's unclear what he's asking for...
21:06:39 <ajax> so let's ask for clarification
21:06:49 <SMParrish> ajax: +1
21:06:54 <nirik> ok, would someone like to do so in the ticket?
21:07:13 <Oxf13> yeah, that's why I said "off the cuff" when was poorly meant to mean "not necessarily what this ticket is asking for, but my idea for solving the problem the ticket kind of talks about"
21:07:51 <nirik> #info will ask for clarification on what is exactly being proposed and revisit.
21:07:51 <ajax> nirik: yeah, i will.
21:08:17 <nirik> Oxf13: would you like us to vote on that now? or just wait and revist once we know more about what the submittor is asking?
21:08:22 <Oxf13> nirik: nope
21:08:38 <nirik> ajax: thanks
21:09:00 <nirik> ok, if nothing else on this, moving on...
21:09:13 <nirik> #topic #468 Evaluate incomplete Fedora 14 Features
21:09:13 <nirik> .fesco 468
21:09:14 <zodbot> nirik: #468 (Evaluate incomplete Fedora 14 Features) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/468
21:09:18 <nirik> speaking of features. ;)
21:09:30 <mjg59> Most of these seemed to have been updated to 100%
21:09:45 <nirik> yeah, looking to see which aren't.
21:10:06 <nirik> https://fedoraproject.org/wiki/Features/Python_2.7 has 4 packages left to rebuild
21:10:22 <notting> ... and is not going to be reverted for those 4 packages. so, nothing to do here?
21:10:42 <mjg59> I think we're left with Python 2.7, which sounds under control, GNUstep, which, well, and D - I'm not clear on what's left to do for D?
21:10:52 <nirik> https://fedoraproject.org/wiki/Features/GNUstep is at 90%
21:11:07 <nirik> https://fedoraproject.org/wiki/Features/D_Programming is at 99%
21:11:33 <ajax> gnustep? what year is it?
21:11:56 <nirik> I'd guess the D thing is waiting for the final approval of the packaging guidelines?
21:12:06 <nirik> GNUStep hasn't been updated in a while.
21:12:37 <notting> yes, but if the only open issue is the examples package hasn't been reviewed yet...
21:13:19 <nirik> yeah, that seems like all I can see.
21:13:44 <nirik> it's been approved.
21:13:50 <nirik> but not imported and built yet
21:13:59 <nirik> today in fact.
21:14:42 <nirik> so, I think we can say all these are ok... barring information we don't have.
21:14:55 <gholms> It hasn't been built and you're approving it?
21:15:29 <nirik> gholms: it's just an extra examples package. I don't think it's a big deal either way if it was in or not...
21:15:43 <gholms> Just the one package. Got it.
21:16:00 <nirik> and it's approved and ready to build, so I don't see why it wouldn't be built later today and go to 100% on the feature.
21:16:35 <nirik> anyone have anything else on these features?
21:16:47 <ajax> not i
21:17:06 <nirik> #info 3 features are still not 100%
21:17:39 <nirik> #info will work with feature owners to make sure they are 100% asap
21:18:09 <nirik> #topic Open Floor
21:18:17 <nirik> anyone have anything for open floor?
21:18:31 <nirik> Oh, I had one thing:
21:18:48 <ajax> i have one, but you first.
21:19:00 <nirik> Tomorrow is the f14 beta readyness meeting. I won't be able to attend due to another meeting. Would someone be able to attend for fesco ?
21:19:52 <mclasen> what time is it ?
21:20:18 <nirik> Wednesday, September 22, 2010 @ 21:00 UTC (17:00 EDT/14:00 PDT)
21:21:02 <ajax> i can't make that, i have a concall then
21:21:28 <SMParrish> I can be there atleast until 545 or so
21:21:39 <nirik> SMParrish: that would be great if you could.
21:22:21 <nirik> ajax: you had something?
21:22:33 * mclasen not going to make it at that time
21:22:48 <ajax> yeah, talked to #tools on Some Other IRC Network
21:23:00 <notting> (sorry, had a drive-by)
21:23:13 <ajax> basically there's no strong push to switch to gold from their perspective and they don't have anyone spending cycles on it atm
21:23:32 <ajax> law@ is on paternity leave, which would explain why he's been pretty quiet about it
21:23:54 <notting> would they like to defer it?
21:24:11 <ajax> i suspect we'll get a hack pretty soon to make it easier for individual packages to opt-in to gold if they want, but as a default switch it's not going to be an F15 feature
21:24:25 <nirik> ajax: ah ha. Ok.
21:24:46 <mclasen> ajax: isn't opt-in just as easy as opt-out ? make LD=ld.gold ?
21:26:07 <ajax> mclasen: heh, true enough. i think this was more of a CFLAGS hack, since you don't know that the makefile will actually call $(LD) to link
21:26:22 <ajax> (and generally shouldn't, since raw ld invocations tend to get buildid wrong)
21:26:45 <mclasen> does libtool pay attention to LD ?
21:27:14 <ajax> shrug
21:27:23 <ajax> i don't trust libtool further than i can throw its authors
21:28:01 <ajax> that's all from me though
21:28:50 <nirik> ok, anyone have anything else? or shall we call it a meeting?
21:29:00 <SMParrish> I have 1 quickie
21:29:28 <SMParrish> In regards to the recent kernel security issue why did it take a week to get this pushed out?
21:29:33 <SMParrish> anyone know
21:29:50 <notting> for which release?
21:30:17 <SMParrish> f13 I believe came up in an earlier meeting
21:30:40 <nirik> looks like it was pushed on a friday... and we dont do updates pushes on weekends, so it took a while for karma and pushing
21:30:58 <nirik> I assume you mean this one: https://admin.fedoraproject.org/updates/search/CVE-2010-3081 ?
21:31:41 <SMParrish> yes thats the one
21:31:58 <cebbert> it was submitted to testing tuesday night and it took 2.5 days for it to get pushed to testing
21:32:42 <Oxf13> I may not have communicated well with dgilmore that he needed to push f12/f13 updates when I left for Zurich
21:32:57 <Oxf13> so a couple days went by without a push
21:33:06 <SMParrish> Ok seems like in the earlier mtg they were concerned that it was announce on the 13th and did not get tp the repos until yesterday
21:33:38 * dgilmore has been doing them daily
21:33:53 * nirik is happy to push updates on weekends once trained up in sigul speak.
21:33:54 <dgilmore> the longest period without was around 36 hours when i got sick
21:34:39 <cebbert> Date Submitted: 2010-09-15 05:29:33
21:34:49 <notting> cebbert: there was an updates-testing push for f14 late wednesday night. i do not know why the kernel was not included.
21:34:54 <cebbert> Date Released: 2010-09-17 18:03:36
21:35:05 <notting> unless it was submitted in bodhi w/o a push request
21:35:09 <SMParrish> dgilmore: thats understandable and I forgot about the weekend and FUDCon ZRH
21:35:37 <nirik> I'll also note f13/f14 firefox updates are pending... people should test and provide karma. ;)
21:36:31 <hicham> they are not pushed yet to testing
21:36:48 <nirik> hicham: right. You can still download and provide karma tho. ;)
21:36:51 <dgilmore> hicham: you can pull from koji and test :)
21:37:02 * dgilmore is doing a push now
21:37:19 * nirik will close the overtime meeting in a minute if nothing else comes up
21:37:25 <dgilmore> there is no firefox update in the push
21:38:26 <nirik> it might have happened after you started.
21:38:38 <nirik> Thanks for coming everyone!
21:38:43 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100921/06c56af9/attachment-0001.bin
More information about the devel