FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

LinkBack Thread Tools
Old 06-07-2010, 10:06 PM
Kevin Fenzi
Default Plan for tomorrow's FESCo meeting (2010-06-08 19:30UTC)

Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on

= Followups =

#topic #351 Create a policy for updates - status report on implementation

#topic #385 Zim / zim package issues.

#topic #382 Implementing Stable Release Vision

= New business =

#topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13

#topic #388 request for e2fsprogs-libs-static

#topic #391 F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall

#topic #390 F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images

#topic #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo

= Fedora Engineering Services tickets =


= Open Floor =

For more complete details, please visit each individual ticket. The
report of the agenda items can be found at

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic.

devel mailing list
Old 06-08-2010, 08:55 PM
Kevin Fenzi
Default Plan for tomorrow's FESCo meeting (2010-06-08 19:30UTC)

#fedora-meeting: FESCO (2010-06-08)

Meeting started by nirik at 19:30:07 UTC. The full logs are available at

Meeting summary
* init process (nirik, 19:30:07)
* notting kylem and cwickert all said they will be unable to attend
today. (nirik, 19:30:41)

* #351 Create a policy for updates - status report on implementation
(nirik, 19:34:07)
(nirik, 19:36:04)
* lmacken is working on a new bodhi version this week that will have
the important packages and (possibly) the all other updates section
implemented. (nirik, 19:39:10)

* #385 Zim / zim package issues. (nirik, 19:40:29)

* #387 compile list of supported CPUs and reacto to recent loss of
support for Geode LX on F13 (nirik, 19:41:55)
* ACTION: SMParrish will contact gcc maintainer and see what possible
solutions to this problem are. (nirik, 20:08:44)

* #388 request for e2fsprogs-libs-static (nirik, 20:10:15)
* LINK: https://fedorahosted.org/fesco/ticket/388 (nirik, 20:10:15)
* AGREED: yaboot can statically link here. (nirik, 20:13:09)

* #391 F14Feature: MultipathInstall
https://fedoraproject.org/wiki/Features/MultipathInstall (nirik,
* AGREED: feature is approved. (nirik, 20:15:06)

* #390 F14Feature: LZMA_for_Live_Images
https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images (nirik,
* AGREED: Feature is approved. (nirik, 20:18:34)

* #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo
(nirik, 20:18:44)
* AGREED: Feature is approved. (nirik, 20:23:19)
* LINK: http://atkac.fedorapeople.org/libjpeg-turbo/libjpeg-turbo.spec
(nirik, 20:24:34)

* FES ticket updates -
https://fedorahosted.org/fedora-engineering-services/report/6 (nirik,
* LINK: https://fedorahosted.org/fedora-engineering-services/ticket/24
that one (mmcgrath, 20:26:56)

* #382 Implementing Stable Release Vision (nirik, 20:31:46)
* LINK: https://fedorahosted.org/fesco/ticket/382#comment:6 (nirik,
(nirik, 20:47:57)

* Open Floor (nirik, 20:49:28)

Meeting ended at 20:54:26 UTC.

Action Items
* SMParrish will contact gcc maintainer and see what possible solutions
to this problem are.
19:30:07 <nirik> #startmeeting FESCO (2010-06-08)
19:30:07 <zodbot> Meeting started Tue Jun 8 19:30:07 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:07 <nirik> #meetingname fesco
19:30:07 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:07 <nirik> #topic init process
19:30:07 <zodbot> The meeting name has been set to 'fesco'
19:30:07 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:28 <pjones> jola.
19:30:41 <nirik> #info notting kylem and cwickert all said they will be unable to attend today.
19:30:49 <mjg59> Afternoon
19:31:42 * nirik waits to see if we have quorum.
19:32:25 * SMParrish here
19:32:41 <ajax> if i say i'm not here, can we skip it?
19:32:42 <nirik> ok, thats 5 at leasy.
19:32:59 * nirik can't type today.
19:33:06 <pjones> I'm definitely not here. No way no how.
19:33:12 <pjones> I'm someplace else. Probably at home.
19:33:40 <nirik> cool. Since pjones isn't here lets assign everything to him.
19:33:58 <pjones> good luck with that
19:34:07 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:34:08 <nirik> .fesco 351
19:34:10 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:34:28 <nirik> so, I talked with lmacken... hopefully we can get something pushed out later this week...
19:34:34 <mjg59> o/
19:34:36 <pjones> yay
19:34:40 <nirik> for the critpath at least.
19:34:40 * mclasen walks in
19:34:56 <nirik> lmacken: does that include the other 2 tickets I filed... ?
19:35:16 <lmacken> nirik: potentially... I need to give them a Good Hard Look first.
19:35:31 <nirik> ok.
19:35:50 <nirik> I take it no one objects to implementing critpath and the 3rd section before autoqa is ready to land?
19:36:04 <nirik> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
19:36:48 <mclasen> nirik: whats the 3rd section ? All other updates ?
19:37:17 <nirik> the Updates to 'important' packages and All other updates sections.
19:38:08 <pjones> yeah, I'm for that.
19:38:17 * nirik is too.
19:38:28 <SMParrish> I'm ok with it
19:38:33 <mclasen> +1
19:39:10 <nirik> #info lmacken is working on a new bodhi version this week that will have the important packages and (possibly) the all other updates section implemented.
19:39:42 <nirik> ok, any other thoughts/input on this? or shall we move along?
19:40:04 <mjg59> Guess we can move on?
19:40:08 <mclasen> thanks to lmacking for working on this
19:40:12 <mclasen> err, lmacken
19:40:16 <mjg59> And yeah, definitely
19:40:25 <nirik> agreed.
19:40:29 <nirik> #topic #385 Zim / zim package issues.
19:40:29 <nirik> .fesco 385
19:40:31 <zodbot> nirik: #385 (Zim / zim package issues.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/385
19:40:41 <nirik> I'm just going to note here that things seem to be moving on this ticket ok.
19:40:59 <nirik> The Current Zim maintainer is going to allow the new submitter to update to the new version with the existing Zim package.
19:41:07 <nirik> So, nothing to see here. moving on.
19:41:29 <mclasen> great
19:41:33 <mjg59> Yup, I think we're done there
19:41:34 <pjones> toldja.
19:41:34 <nirik> I'd like to hold the "Implementing Stable Release Vision" ticket to the end since it's likely to have longer discussion...
19:41:37 <pjones>
19:41:55 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13
19:41:55 <nirik> .fesco 387
19:41:55 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387
19:42:08 <nirik> so, this looks unfortunate for XO folks.
19:42:17 <SMParrish> yes it is
19:42:43 <ajax> i've asked this before and never really gotten a good answer: why are primitive x86s not treated as a secondary arch?
19:42:46 <SMParrish> IMO probably to late to change things for F13 but would like to see it corrected for F14
19:43:13 <mjg59> Well, we're kind of limited by the code that gcc outputs
19:43:22 <nirik> ajax: because no one would do the work and they would just die I suspect?
19:43:30 <ajax> mjg59: -march=i386 is a pretty good control for that.
19:43:37 <pjones> nirik: and that's an argument against?
19:43:38 <Guest62041> I investigated this last night, it CAN be changed for F13. See bug report https://bugzilla.redhat.com/show_bug.cgi?id=579838
19:43:45 <mjg59> ajax: Yeah, we could output for 586 and optimise for 686
19:43:49 <ajax> well, i486 since pthreads, but.
19:43:50 <mjg59> s/686/core
19:43:57 <Guest62041> All the executables are OK, only glibc is borked.
19:45:11 <nirik> so, a) get gcc changed b) get glibc changed to not use that instruction c) get the kernel emulation of that instruction working/added, d) say we don't support this cpu anymore.
19:45:45 <mjg59> Previous attempts to implement missing instructions in the kernel have generally not been accepted by upstream
19:45:59 <pjones> 3 of those require us to mandate that people do work when we really are in no position to ask that.
19:46:03 <mjg59> There's several easy and wrong ways to do it. I don't know that anyone's done it in an upstream acceptable way.
19:46:11 <Guest62041> re a), this doesn't appear to be a gcc issue. gas is generating NOPL for .align opcodes, probably because the glibc build told it we were building for i686.
19:46:20 <SMParrish> (d) is not an option. Sugar has too much invested in working with Fedora for the XO-1
19:47:01 <pjones> c's pretty much a nonstarter. that leaves 'b', which sounds like loads of fun.
19:47:06 <mclasen> If it is just glibc, would a custom glibc build for olpc be an option ?
19:47:20 <mjg59> SMParrish: Well, I think (d) is certainly an option at our level. I'd think that it's the board's responsibility to determine whether supporting a third party is worth making technical compromises.
19:47:28 <nirik> yeah, upstream kernel or upstream glibc... which would more likely accept a fix?
19:47:45 <mjg59> Well, we could build glibc with different options
19:47:47 <Guest62041> olpc wants to be able to use the standard Fedora repos.
19:48:01 <mclasen> well, we are not talking about upstream fixes but about build configuration, no ?
19:48:07 <pjones> yeah, which is something we should try to encourage, not inhibit.
19:48:15 <SMParrish> mjg59: Fedora has alot invested with the Sugar folks as well. RH was on original sponsor of the program
19:48:19 <mjg59> But if there's a performance hit, compromising glibc seems like a poor choice
19:48:29 <ajax> i don't think d) is an option; we didn't intend to break geode in f13, so retroactively declaring it so is disingenuous.
19:48:51 <ajax> mjg59: .align isn't something i'd expect to be a performance path
19:49:00 <Guest62041> the 'performance hit' is on the No-ops that precede a loop start. Not in the inner loops.
19:49:00 <ajax> i mean, that's the dead space between functions, right?
19:49:09 <ajax> oh, loop align too, right.
19:49:12 <ajax> still, whatever.
19:49:26 <dsd_> its not entirely limited to glibc. there were some mentions of other packages
19:49:49 <dsd_> providing alternative packages might be an option, but as things progress in future it would probably be hard to control
19:49:53 <Guest62041> all the packages I found with nopl's were either generated from glibc sources, or were linked statically with glibc.
19:49:59 <mjg59> In an ideal universe, gcc would have a definition of 686 that matched reality
19:50:33 <SMParrish> dsd_: what is the best solution for you. Would an i586 subarch work?
19:51:28 <dsd_> i dont know too much about subarchs
19:51:44 <dsd_> subarch = secondary architecture?
19:51:48 <Guest62041> mjg59: competition in the cpu market is such a drag. Innovation that doesn't all go in one direction, bah.
19:51:54 <SMParrish> dsd_: yes
19:52:17 <mclasen> is autoqa in a position to do checks like 'no NOPL' on our binary rpms ?
19:52:29 <mjg59> Guest62041: So the difference would be (i) a glibc built with -march=586, and (ii) a rebuild of everything that statically links glibc?
19:52:38 <nirik> mclasen: I don't think so yet, but eventually I would think so.
19:52:50 <Guest62041> I think you are correct.
19:52:57 <ajax> mclasen: it certainly could. it has the binary payloads, and objdump knows how to disassemble. just needs writing.
19:53:05 <mjg59> So it would be a relatively small package overlay
19:53:10 <nirik> so, our glibc maintainer(s) aren't willing to work around this? I only see the one comment pointing to the kernel work...
19:53:14 <dsd_> SMParrish: i dont know enough about what "secondary arch" means to say really.. and i guess my newbie questions would be outside of the scope of this meeting
19:53:37 <Guest62041> Why build a sub architecture for three packages? Why not just fix glibc in the F13 repos?
19:53:57 <mjg59> Fix glibc how?
19:54:26 <Guest62041> fix its configuration so that it uses the i686 instruction set minus NOPL
19:54:30 <dsd_> can anyone say with confidence (perhaps with a solid reference) that nopl is the only i686 instruction unsupported by Geode LX?
19:54:43 <SMParrish> Guest62041: My fear is that over the next few years additional changes could be introduced which cause another issue with Geode
19:54:47 <ajax> dsd_: nopl, and cmov, and ...
19:55:02 <cjb> ajax: no, we have cmov.
19:55:08 <ajax> i don't know of a list of what's definitely excluded from geode
19:55:19 <Guest62041> there's a memory/memory CMOV missing, but we don't use it.
19:55:22 <Guest62041> ...yet...
19:55:24 <dsd_> i'm just wondering if we'll see the same thing again in 6 months time with another weird instruction
19:55:29 <ajax> probably.
19:55:37 <ajax> so when i said "why is this not a secondary arch" i was trolling
19:55:48 <ajax> it's because we don't actually have a meaningful secondary arch process
19:55:51 <Guest62041> testing on Geodes would let us figure out early enough if something does come up in 6 months.
19:55:54 <mjg59> So, I don't think changing glibc is a sensible plan here
19:55:57 <Guest62041> the problem was that the bug was reported and then ignored.
19:56:17 <mjg59> Because the code is correct, it just has undesirable effects on a given CPU
19:56:58 <nirik> which leaves what? kernel or seperate i586 versions.
19:56:59 <nirik> ?
19:57:03 <mjg59> And it's possible that updates *within* a release may cause applications that previously worked to suddenly contain these instructions
19:57:15 <cjb> in several years, the only sigill we've seen when running i686 distros on the LX is from NOPL. (And NOPL is interesting because it's not actually a documented insn in i686, which is perhaps why the Geode designers chose not to bother.)
19:57:17 <Guest62041> the high level question is: is the Geode LX a supported CPU? If so, glibc has a bug. If not, glibc is correct and the Geode has a, uh, problem.
19:57:37 <ajax> i think by inertia lx _is_ supported.
19:57:41 * nirik notes we are at 15minutes into this discussion. Votes to keep going? or ask for more data/wiki writeups of proposals?
19:57:42 <mjg59> So we either need to stop gcc emitting nopl or we need nopl to work on the geode
19:58:03 <mjg59> It's trivial to stop gcc emitting nopl - we just change the default architecture again
19:58:17 <mjg59> ...and rebuild the entire archive
19:58:28 <Guest62041> mjg59 ideally we'd fix it both ways -- patch the glibc makefiles, AND add a kernel workaround to avoid future problems
19:58:39 <mclasen> but it only seems to emit it for a handful of binaries now, so why rebuild everything ?
19:59:07 <Guest62041> mjg59: For some reason we don't yet understand, only glibc binaries are affected. Standard package build process doesn't produce NOPLs.
19:59:08 <mjg59> mclasen: Yeah, I guess ABI isn't going to be impacted, so we could scan the entire binary archive and just rebuild them
19:59:15 <nirik> folks? votes to keep going please?
19:59:20 <ajax> nirik: keep going
19:59:23 <mjg59> nirik: +1
19:59:26 <SMParrish> +1
19:59:29 * nirik is fine with going on.
19:59:46 <mjg59> My concern is that changing the architecture mid-release could trigger other issues
19:59:59 <cjb> I think that'd be great. (Scan and rebuild affected binaries, which we currently believe to only be glibc.)
19:59:59 <mjg59> Updates of some libraries may start using different codepaths
19:59:59 <nirik> mjg59: change it to what? i586?
20:00:02 <pjones> keep going, yes
20:00:13 <mjg59> nirik: Yeah, unless there's some more fine-grained architecture control I'm unaware of
20:00:22 <mclasen> cjb: plus static linkers of glibc ?
20:00:33 <mjg59> Perhaps we could convince upstream to do a 686-nopl
20:00:47 <mjg59> But, like I said, there's a risk inherent in doing this mid-cycle
20:00:47 <dsd_> mjg59: it could be done for F14, perhaps. (i dont think that would bother OLPC too much, but other LX users might think differently)
20:00:52 <mclasen> would that be i686-nonopl ?
20:01:03 <Guest62041> sounds like a nonopoly to me
20:01:04 <mjg59> The risk is lower if we just change the glibc spec file
20:01:27 <dsd_> or that. change arch for f14, hack glibc for F13
20:01:28 <mjg59> But there'd plausibly be a package update that broke things mysteriously
20:01:36 <ajax> i'm a little confused why we're talking about glibc; .align is a macro in gas.
20:01:51 <ajax> (i assume)
20:02:00 <mjg59> ajax: glibc or gcc?
20:02:20 <ajax> i think really all we can say at this point is that we think it's broken, and we need to figure out where.
20:02:30 <Guest62041> gcc generates .align sometimes, to line up loops on cache line boundaries. gas turns that into any of a dozen forms of NOP depending on what CPU was specified and tuned for.
20:02:43 <mjg59> Yeah, so when I say gcc pretend I said binutils
20:03:02 <Guest62041> But either gcc isn't generating .align for most packages, or gas is being passed different flags for most packages than for glibc.
20:03:08 <Guest62041> that's the part we don't understand.
20:03:29 * nirik thinks we should try and get gcc / glibc maintainers involved in this discussion... but not sure how best to do that.
20:03:34 <mjg59> Ok. Perhaps we should come back to this when the problem is better understood?
20:03:52 <nirik> something like: we want to support this cpu. How can we most easily and safely make it so?
20:04:25 <Guest62041> the CLOSED NOTABUG bug report has been reopened, so it should reenter the maintainers' radar.
20:04:34 <mclasen> did we definitively decide that we need to fix this in f13 and not tell olpc to use an overlay ?
20:04:47 <pjones> so we all agree we'd rather continue supporting this, right? and then mclasen's question was my next one.
20:04:50 <mjg59> mclasen: I think definitively deciding that depends on what's actually happening
20:05:12 * nirik wants to support this cpu... but needs more info on what changes could do that and how risky they are.
20:05:13 <mclasen> ok, so we are still trying to figure out if we _can_ safely and acceptably fix it in f13
20:05:18 <mjg59> It'd be desirable, certainly
20:05:24 <cjb> mclasen: I think the position is more that, since we thought it *was* a supported arch for the release, if we're going to drop it then that should happen with warning at the next release, not retroactively.
20:05:41 <SMParrish> +1 on continuing support and if possible fixing in F13
20:05:51 <pjones> cjb: I think that's fair, but I was asking about a stronger position of "we don't want to discontinue this"
20:05:55 <cjb> any suggestions for who to reassign the now-opened WONTFIX bug to?
20:05:58 <pjones> which it sounds like there's wide agreement on
20:06:19 <nirik> well, is a bug the best way to get input from gcc/glibc folks? or can we contact them more directly?
20:06:37 <pjones> the best thing is probably to find jakub on email or irc and ask him what can be done
20:06:46 <Guest62041> It's a bit of an odd position to say, let's desupport 1.5M in-use machines to get a <1% speedup on NOPs in libc.
20:06:51 <pjones> email might be preferable in that more of us can see it.
20:07:12 <pjones> (he's currently idle 10 hours on irc, so... probably not around)
20:07:27 <nirik> would someone be willing to take that action item and provide any info back to the fesco ticket/bug?
20:07:55 * mclasen can do that
20:07:55 <SMParrish> I will
20:08:03 * mclasen steps back quickly
20:08:25 <nirik> ha.
20:08:44 <nirik> #action SMParrish will contact gcc maintainer and see what possible solutions to this problem are.
20:08:49 <nirik> thanks SMParrish
20:08:53 <cjb> thanks all
20:08:54 <nirik> anything more on this now?
20:08:54 <Guest62041> thx to all
20:09:17 <nirik> cjb / Guest62041 / dsd_ : thanks for the input on the issue.
20:09:38 <Guest62041> nice to know somebody's listening!
20:09:50 * nirik is sorry it happened and wasn't caught before release. ;(
20:09:56 <nirik> (well, wasn't acted on before release)
20:10:15 <nirik> #topic #388 request for e2fsprogs-libs-static
20:10:15 <nirik> https://fedorahosted.org/fesco/ticket/388
20:10:15 <nirik> .fesco 388
20:10:15 <zodbot> nirik: #388 (request for e2fsprogs-libs-static) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/388
20:10:24 <nirik> turns out I think this ticket can be closed...
20:11:05 <nirik> or I guess it's not against the right package.
20:11:17 <nirik> ie, yaboot should get approval for linking static.
20:11:36 <ajax> bootloaders are exceptional, yeah
20:11:46 <nirik> in any case, I am fine with this, it makes sense why it needs it.
20:12:06 <nirik> so, +1 here.
20:12:18 <nirik> +1 from notting in the ticket
20:12:22 <mjg59> Reading a shared object off a filesystem is hard if you need that shared object in order to read the filesystem, yeah
20:12:33 <ajax> +1 to exception for yabooy
20:12:38 <SMParrish> +1
20:12:38 <mjg59> +1
20:12:46 <ajax> also, the package spelled correctly
20:13:09 <nirik> #agreed yaboot can statically link here.
20:13:25 <nirik> now on to f14 feature fun!
20:13:28 <nirik> #topic #391 F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall
20:13:28 <nirik> .fesco 391
20:13:29 <zodbot> nirik: #391 (F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/391
20:14:00 <nirik> +1 from notting in the ticket.
20:14:29 <nirik> +1 from here. Also not sure how many people will use it, but it's cool.
20:14:31 <mjg59> I can't see any reason for anything but +1 here
20:14:36 <ajax> same, +1
20:14:39 <pjones> I'll be +1 on it I _guess_
20:14:45 <pjones> but consider that to be under duress.
20:14:46 <SMParrish> +1 as well
20:14:56 <nirik> pjones: odd. I was expecting you to kibosh it.
20:15:06 <nirik> #agreed feature is approved.
20:15:13 * mclasen added some comments on the feature
20:15:39 <nirik> #topic #390 F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images
20:15:39 <nirik> .fesco 390
20:15:40 <zodbot> nirik: #390 (F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/390
20:15:51 <pjones> mclasen: that comment kindof makes me want to punch people.
20:16:00 <mclasen> fine with me
20:16:06 <mclasen> as long as you don't punch the messenger :-)
20:16:30 <pjones> it's as if the people doing the work weren't consulted at all... oh wait
20:16:53 <mclasen> I don't know that, and I didn't mean to imply that
20:17:02 <ajax> man i sure would like it if squashfs would grow interface-stable tools, ever.
20:17:12 <pjones> ajax: s/interface-//
20:17:26 <nirik> yeah. ;(
20:17:43 * nirik is +1 here, we can yank it if it doesn't land or turns out to not work or be slow or whatever.
20:17:48 <ajax> i think it's a reasonable thing to shoot for though. +1
20:18:03 * SMParrish agrees with nirik +1
20:18:11 <mjg59> Yeah, +1
20:18:14 <mclasen> +1
20:18:17 <nirik> it's a pity the upstreaming is going so slowly. It was first submitted for .32 I think... or .31
20:18:34 <nirik> #agreed Feature is approved.
20:18:44 <nirik> #topic #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo
20:18:44 <nirik> .fesco 392
20:18:45 <zodbot> nirik: #392 (F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/392
20:18:45 <brunowolff> Thanks.
20:18:58 <nirik> brunowolff: sorry for forgetting to cc you on that ticket. ;( I failed.
20:19:26 <nirik> +1 from notting on the ticket to libjpeg-turbo
20:19:34 <brunowolff> I knew that it was going to be discussed at the meeting because the wrangler changed the wiki page to indicate that.
20:19:44 <ajax> i love the "how to test" on this one. seeing artifacts is all jpeg _ever_ does.
20:20:28 <mjg59> It should produce identical output to libjpeg, right?
20:20:45 <nirik> +1 from me. Again we can back it out pretty easily since no rebuilding needs to happen.
20:20:52 <nirik> mjg59: yeah, should be.
20:21:07 <ajax> mjg59: i think there's some wiggle room there, but at least perceptually yes.
20:21:07 <mjg59> Yeah, so it should be pretty obvious if it's grotesquely broken
20:21:08 <mclasen> mjg59: yeah, that should be testable
20:21:09 <mjg59> +1
20:21:30 <mclasen> perceptual diff...
20:21:51 <ajax> istr one of the libjpeg replacements doing something different for iDCT which meant you got rescaling for free, but not pixel identical results.
20:21:57 <ajax> might be this one, might not.
20:22:04 <ajax> anyway, +1, looks plausible
20:22:36 <SMParrish> Easy to revert if we find issues later +1
20:23:19 <nirik> #agreed Feature is approved.
20:23:32 <mclasen> so, how is this going to work in practise btw
20:23:42 <mclasen> is libjpeg-turbo going to replace libjpeg ?
20:23:48 <pjones> we run out of time and move whatever is finished to next release.
20:23:53 <pjones> Oh, you meant that.
20:24:10 <mclasen> obsoletes/provides ?
20:24:20 <nirik> yes
20:24:23 <nirik> it does currently.
20:24:24 <pjones> obsoletes/provides is probably the way
20:24:34 <nirik> http://atkac.fedorapeople.org/libjpeg-turbo/libjpeg-turbo.spec
20:25:12 <nirik> ok, anything more on this?
20:25:57 <nirik> #topic FES ticket updates - https://fedorahosted.org/fedora-engineering-services/report/6
20:26:05 <nirik> mmcgrath: anything to report this week?
20:26:13 <mmcgrath> Just a few things
20:26:29 <mmcgrath> 1) we got a new contributor that knows C/C++ so that's good.
20:26:36 <mmcgrath> other then that there was one ticket /me gets it
20:26:56 <mmcgrath> https://fedorahosted.org/fedora-engineering-services/ticket/24 that one
20:27:09 <mmcgrath> josemm went through and wrote this but it's not so clear the data we're getting is particularly useful in that form.
20:27:32 <mmcgrath> nirik: did you have any additional thoughts on that?
20:27:33 <nirik> yeah, I'd like more idea on what we could look for for 'very active bugs'
20:28:06 <nirik> basically we want a way to note things that are hitting lots of users or have lots of activity, but not closed... so we could look at adding resources to get them fixed...
20:28:12 <mmcgrath> I'd think active bugs is less important then the number of cc's on a bug.
20:28:24 <mmcgrath> if lots of people care to watch it, they probably all want to know when its fixed.
20:29:09 <nirik> yeah, so perhaps just 'number of cc's'... but I'm not sure we can get that from bugzilla easily.
20:29:28 * mmcgrath isn't sure either
20:29:31 <mmcgrath> I be josemm knows
20:30:05 <nirik> If anyone else has any ideas or thoughts, chime right in.
20:31:03 <nirik> well, we can keep poking at it... and perhaps josemm can find a way to do things for us.
20:31:09 <nirik> thanks mmcgrath.
20:31:32 <nirik> As always, feel free to file tickets or add info to them...
20:31:42 <mmcgrath> yup yup
20:31:46 <nirik> #topic #382 Implementing Stable Release Vision
20:31:47 <nirik> .fesco 382
20:31:48 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
20:32:07 <nirik> so, mclasen added some ideas last week...
20:32:20 <nirik> also poelcat would like us to come up with a timeline for implementation
20:32:27 <nirik> https://fedorahosted.org/fesco/ticket/382#comment:6
20:33:23 * nirik taps the mic. Is this thing on?
20:33:57 <ajax> oh, timelines.
20:34:14 <ajax> "man, i need to measure this somehow... but how?"
20:35:18 <pjones> yeah, they tend to be pretty bogus, especially when you're pretending they're schedules.
20:35:38 <nirik> also, it's hard to say much until we have a list of things we would like to implement.
20:35:46 <ajax> i think mclasen's ideas are along the right track. but in saying that, i'm saying that i don't think we have tools to measure a lot of that.
20:36:04 <ajax> was re: hot bugs from the FES tickets above.
20:36:19 <nirik> yeah.
20:36:52 <poelcat> what i was trying to get at was a rough notion of when it will be implemented... a goal of some sorts
20:36:57 <poelcat> ?
20:37:01 <nirik> I think it might be worthwhile to list out things to implement for each bullet point in the Board vision... perhaps setup a wiki page to collect things ?
20:38:08 <ajax> yeah. it's probably worth trying to talk with the design people about what this would look like for a user trying to consume it.
20:38:09 <nirik> poelcat: yeah, but it's really hard to estimate that when we don't yet have a full list of things that we would like to implement?
20:38:46 <poelcat> nirik: even thinking really broadly? e.g. end of F14, or end of 2010, or ?
20:38:50 <ajax> some of that we already know, of course. things like abrt being able to tell you that your crash is fixed with a given update.
20:39:30 * poelcat subscribes heavily to the "if you shoot for nothing" principle
20:39:35 <nirik> poelcat: the thing is I bet some of them would be pretty short term/before f14, but some might not be until later...
20:40:29 <poelcat> true
20:41:23 <nirik> I can make a wiki page for a ideas container?
20:41:31 <ajax> sounds good.
20:41:44 <nirik> then we can have folks add to it and see which ones we can do at what time
20:41:44 <nirik> ?
20:41:55 <SMParrish> nirik: good idea
20:41:55 <ajax> i think we should be able to come up with which bits we're going to aim for by f14 and which will be later.
20:42:37 <nirik> yeah, so: before f14, f15 and 'pie in the sky' ?
20:42:59 <ajax> that sounds like a good start
20:43:16 <mclasen> if we do something before f14, it would be for f13 updates, yes ?
20:44:03 <pjones> nirik: that sounds about right, yeah
20:44:17 <pjones> mclasen: I don't see why not
20:44:21 <ajax> mclasen: well, or something to have ready for f14 gold. i guess those are different things.
20:44:24 <nirik> mclasen: good question... I think a number of these things could be addressed in all active streams.
20:47:57 <nirik> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
20:48:11 <nirik> please edit/add/fold/spindle/mutilate.
20:48:46 <ajax> excellent, thanks!
20:48:52 <nirik> any other thoughts on this for now?
20:49:28 <nirik> #topic Open Floor
20:49:35 <nirik> Anything for open floor?
20:49:43 <ajax> i do have the libiberty scanner running, but lord is it slow
20:50:08 <ajax> 9000 packages in F13, and i've got through 2000ish in the past two hours or so
20:50:09 <pjones> not really surprising.
20:50:28 <ajax> almost entirely blocked on read bandwidth to the lookaside cache
20:50:29 <pjones> that's actually faster than I would have predicted.
20:50:32 <nirik> cool. Update the ticket as you get info.
20:50:48 * mclasen apologizes for being slightly unresponsive today, dueling meetings...
20:51:01 <pjones> I guess the last time I tried to do something like that was on a sun ultra 2 (and rh7.1...), so...
20:51:09 <nirik> ajax: any news on the mediawiki fun?
20:51:14 <pjones> mclasen: no worries, thanks for making an attempt on the scheduling
20:51:50 <nirik> mjg59: any update for https://fedorahosted.org/fesco/ticket/381
20:52:06 <mjg59> nirik: Nobody replied when I brought it up. I'll try harder.
20:52:14 <ajax> nirik: i think i'm coming down on the side of mediawiki. it's a worthwhile change in principle but i don't think the implementation is good enough to be carrying. still thinking.
20:52:17 <nirik> bummer. ;(
20:52:29 <nirik> ajax: ok.
20:52:46 <nirik> oh, does anyone object to me just closing https://fedorahosted.org/fesco/ticket/276 ?
20:52:55 <nirik> thats the 'include cacert.ca'
20:53:08 <ajax> boot it.
20:53:18 <nirik> cool.
20:53:21 * nirik has nothing else.
20:53:41 <pjones> keeeel
20:53:49 * mclasen ponders bringing up nss-softokn
20:53:53 <mclasen> nah
20:54:01 <nirik> mclasen: yeah, it's a mess. ;(
20:54:02 <mclasen> next week
20:54:04 <nirik> ok.
20:54:08 <pjones> we could argue about that in public for another week before you do that
20:54:13 <nirik> Thanks for coming everyone!
20:54:26 <nirik> #endmeeting
devel mailing list

Thread Tools

All times are GMT. The time now is 09:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org