Re: Change to DSO-linking semantics of the compiler

far was that implicit linking feature. Sadly, my concerns got ignored at the FESCo meeting where this "feature" was discussed:-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Change to DSO-linking semantics of the compiler

g the DSO to the one providing the symbols is not enough due to the very change which is causing the problems. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Change to DSO-linking semantics of the compiler

else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel m

Re: Change to DSO-linking semantics of the compiler

else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel m

Re: gvfs causes hangs

a ntfs-3g, but I'm not sure that's vital / > common enough to block a release. The problem is that gvfs also uses FUSE (AIUI, it can work without, but FUSE mounting for the benefit of non-gvfs-enabled apps is enabled by default). Kevin Kofler -- devel mailing

Re: Orphaning xerces-c

bypass this "automatically reassign to the comaintainer" "feature". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gvfs causes hangs

Steve Grubb wrote: > Digging into this further, if you run lsof, it hangs when it gets to > ~/.gvfs: It is possible to disable FUSE mounting in gvfs, see: http://lists.fedoraproject.org/pipermail/users/2009-August/084569.html Kevin Kofler -- devel mailing list

Re: OpenModelica users wanting to have rpms?

ilibbed due to the libraries and if the script is not identical for 32-bit and 64-bit, there will be a conflict between the 2 multilibbed packages. (Splitting out the libraries into a -libs package is a way to work around that.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Purging the F13 orphans

one can just die. > Unblocked orphan qtoctave I'll pick this one up, it's useful (a Free Software equivalent to the MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, even), there's AFAIK no obvious replacement and upstream seems active. Kevin

Re: Purging the F13 orphans

Kevin Kofler wrote: > Jesse Keating wrote: >> Unblocked orphan qtoctave > > I'll pick this one up, it's useful (a Free Software equivalent to the > MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, > even), there's AFAIK no obvi

Re: rawhide report: 20100128 changes

nitor and PKI enrollment client > New package font-manager > A font management application for the GNOME desktop environment > New package iwl5150-firmware [and it ends here] The report got truncated yet again. :-( Kevin Kofler -- devel mailing list de

Re: best practice for packing programs that use strlcpy()?

s that's part of kdelibs it's probably not the answer you were looking for. ;-) libbsd sounds like a decent solution, probably the best you'll get due to the conflict cited above. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Draft privilege escalation policy for comments

of evil things to avoid which the proposal provides and I haven't seen any evidence as to the contrary (again, the PackageKit example is not applicable because the PackageKit maintainer did NOT have such a list to go by when he made his change; there's no reason to believe he&#x

Re: How about firefox 3.6 in Fedora 12 ?

Liu Yu Fei Eric wrote: > I noticed firefox was stuck on 3.5.6 for a rather long time. > What about 3.5.7 and the recently 3.6? They are even not in koji. http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org

Re: Draft privilege escalation policy for comments

seful. The PackageKit issue was caused by lack of a policy, not lack of enforcement.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How about firefox 3.6 in Fedora 12 ?

reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How about firefox 3.6 in Fedora 12 ?

A new version of IcedTea with a new plugin which supports Firefox 3.6 is being imported into Rawhide. This would have to be backported if Firefox 3.6 were to be pushed to F12. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How about firefox 3.6 in Fedora 12 ?

Rawhide are NOT SUPPORTED and will in many cases NOT work as expected due to dependencies and reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Ko

Re: How about firefox 3.6 in Fedora 12 ?

LM issue? That looks like it could affect Fedora users if they are behind a Window$ Vi$ta or 7 proxy. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)

f you scratch-build, once it's successful, you have to redo the build as a real build, so you waste one build. With my workflow, you save that build. Saves both Koji resources and your time. Also saves your time over local mock builds where you also have this "one wasted build&qu

Re: How to take ownership of a package in rawhide branch? - Was: [Taking ownership of the orphaned packages: bytelist, jcodings, jvyamlb]

ned for more than 3 months. You need to submit new review requests, specifying that this are packages which were previously in Fedora and are being resurrected. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)

e_cb() work on a copied tuple > (the metadata updates flood is too racy IMO). > - Fix tuple_copy(). This style is not compliant with the Fedora packaging guidelines. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Draft privilege escalation policy for comments

it's just a source-level abstraction layer (so for example, you won't find a PolicyKit policy in the source code, but a KAuth policy which is converted to a PolicyKit policy at build time). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines

lers (DVD, CD set, netinstall). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)

Nicolas Mailhot wrote: > Sure it is, it's changelog style #3 of > http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs No, it's not style #3. It's 2 or more style #3 entries collapsed into 1, which is not one of the allowed formats. Kevin Kofler -- dev

Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)

e FPC to officially clarify this. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: KDE-SIG meeting report (05/2010)

m directly in the current code), so they just removed it in Rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=561001 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)

hange the requirements, they're not cast in stone. Even existing changelogs can be fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is PulseAudio dead?

ntly claimed. PS: And since PulseAudio is a shared technology also used by other desktops than just GNOME, I'd be willing to pick up comaintainership, but then it'd very likely be maintained in KDE SIG style, aggressively tracking upstream development. Kevin Kofler -- devel

Re: Is PulseAudio dead?

Matthias Clasen wrote: > I was on vacation for two weeks, but I'm back now. So our manpower > should be even again :-) LOL, it's true that you do a lot of work all by yourself. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapro

Re: git branch help?

erything in its own bizarre, confusing and broken way. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is PulseAudio dead?

d despite the fact that this makes us lose our niche, compete directly with distributions we CANNOT compete with (we stand no chance against Ubuntu's massive marketing machine) and leave users in our current niche out there in the cold with no way to go. :-( Kevin Ko

Re: Is PulseAudio dead?

letting go of the notion that my > approach is the only right one. I don't believe it is possible to fix PulseAudio bugs effectively without tracking upstream more closely. Upstream is where Lennart focuses his bugfixing. Kevin Kofler -- devel mailing list devel@list

Re: git branch help?

to entry and much harder work for existing packagers. (And yes, I've also tried to make these points BEFORE the migration, but nobody listened.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is PulseAudio dead?

Rahul Sundaram wrote: > Since there is no new upstream release, you will have to triage bugs, > cherry pick patches and push them as updates. What else do you mean by > tracking upstream closely? If there's no new release, I'd just ship a snapshot. Kevin Kofler --

Re: git branch help?

mmits and thus repository-wide revision IDs). Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

if I work on multiple branches, that's what directories on my file system are for). (And this is another reason why I consider DVCSes to be broken by design.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is PulseAudio dead?

updates (unless they fixed that recently) and they do strange things to specfiles (like automatically bumping Revision) and encourage the use of constructs which don't work outside of OBS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

foo when upgrading to F13? The sequence number before (17 vs. 18) might have been incremented due to one or more plain rebuild(s), it doesn't necessarily reflect the sequence of upstream snapshots being packaged. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

ith a distributed server doesn't. Git doesn't (by design) support the required server-side operations. I'd have to set up an SVN gateway to the repository on some server. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

at. I am not willing to silently accept anything with a nonzero probability of failure on perfect hardware. Any such algorithm is just incorrect. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

workflow, I usually just copied the specfile, sources and .cvsignore from devel, no re-editing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

t cherry-pick master fedpkg commit && fedpkg push && fedpkg build cd ../f13 git pull git cherry-pick master fedpkg commit && fedpkg push && fedpkg build That way the contents of your directories always contain the same branch, so you don't end up accidentally

Re: git branch help?

s between the releases (e.g. BuildRequires), that's what 0%{?fedora} is for. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

rithm doesn't work). Using an algorithm which doesn't work is unacceptable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is PulseAudio dead?

e, ideally, we'd have an actual upstream release to ship. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git branch help?

e and check manually, but how do you verify that the key you downloaded is the correct one?) In addition, even packages legitimately signed by the repository could have been compromised at some other point in the chain. Signature mechanisms are NOT the perfectly tamper-proof protection they're

Re: dist-git tag question

. And once that component is in place, will it also retroactively tag git for all the builds that are happening now or will we be stuck with builds without a matching named tag in the repo forever? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapro

Re: dist-git tag question

ementation does not comply to that essential requirement. Thus, this is a showstopper which should have blocked putting dist-git into production. Plus, automatic tagging was promised as THE reason we switch to dist-git in the first place. Kevin Kofler -- devel mailing list devel@list

Re: [ACTION REQUIRED] orphaned packages in F-14

t that these be just built without NAS support. NAS is basically an older competitor to PulseAudio with fewer features (it focuses on network transparency, which is just one of the things PulseAudio does), it is not compatible with PulseAudio, few to no people use it. Kevin Kofler -- dev

Re: EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)

mpatible with PulseAudio and which is supported by few applications. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] orphaned packages in F-14

Petr Pisar wrote: > PulseAudio is interresting project, but it's absolutely unusable on old > slow hardware. Last time I checked it out on Pentium TSC (no MMX) > running at 200 MHz, Fedora doesn't support that hardware anymore (the minimum is i686 = Pentium Pro). Kevi

Re: feature freeze?

7;t resolve the complaint that upstream will be unwilling to add features which are specific to the non-Free edition. Crippleware "OSE"s suck. Fedora should not encourage this practice. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

also KDevelop, to display that documentation. (It would be a separate subpackage.) Though shipping only the QCH might also be worth considering. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY

Those JavaScript JITs are a really bad security risk. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

ribution. Whatever can be generated on the build system MUST be generated on the build system, not on the client. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

ernet connections. Not everyone has slow Internet and a fast CPU. In my case, it'd take 20+ times as long to build the documentation on the client than to download it! Plus, there's also other technical issues, e.g. that the files generated that way bypass RPM's file

Re: root-doc subpackage slightly obese

es I pointed out elsewhere in this thread, this means you need to install the source code (!) of the package on the client. This is in itself a significant download and it's something Fedora does not normally do. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20100806 changes

Debarshi Ray wrote: > Waiting for Devhelp to be downgraded to 2.31.x after Fedora 14 Alpha > is released. This report is about Rawhide (now targeting F15+), not the F14 branch. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/m

Re: cvs2cl orphaned

ship in Fedora if you apply. I'm also fine with any Fedora-only comaintainers, just apply through pkgdb. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

t KDE SIG meeting (Tuesday 14:00 UTC / 16:00 CEST / 10:00 (AM) EDT / 07:00 (AM) PDT). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

w fast I could download that file at my university. :-p Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: root-doc subpackage slightly obese

g those docs is what Qt Assistant is for. We'll discuss this in the meeting. (That said, assistant_adp is NOT dropped in Fedora, we ship a qt-assistant- adp compatibility package because some apps need it. But viewing Qt docs in the compatibility Assistant isn't of much use.)

Re: [ACTION REQUIRED] orphaned packages in F-14

and sees similar issues as well. The N900 also uses PulseAudio (though not on Fedora). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: feature freeze?

red to such a model, yours means having to wait much longer for the features, and being clearly pressured into buying the proprietary version, giving up the freedoms that come with Free Software. (As you can see, I'm familiar with both the Free Software and the Open Source view of things.

Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

Frank Murphy wrote: > I guess they are waiting to iron out a few bugs on F14 > systemd\selinux\udev? Before they push the same broken updates to > F15(Rawhide) Normally, development is supposed to happen in Rawhide FIRST. Kevin Kofler -- devel mailing l

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

e the "KDE Applications" and the whole thing is the "KDE Software Compilation" (but upstream prefers it if people are specific about what parts of the compilation they talk about rather than just using s/KDE/KDE SC/g). We hope that we will be able to meet the size constrain

Re: Orphaning all my packages

seth vidal wrote: > All your packages are now orphaned. > > Thanks for letting us know. Do we have a list of the packages that got orphaned? Unfortunately, querying pkgdb doesn't help anymore now that you set the stuff to orphaned. Kevin Kofler -- devel mail

Re: Orphaning all my packages

anymore because the packages are now orphaned. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

han a package that doesn't install at all! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

whether you really want a better Fedora. IMHO you just want a DIFFERENT one, one which doesn't fill its niche anymore and is instead yet another conservative distribution, of which there are way too many already. And stuff like broken dependencies just hurts everyone, even the conservative f

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

droppong the embedded ext3 image and > use squashfs directly. (Selinux should now be usable on squashsfs file > systems.) That might gain us a bit more space. Won't that break liveinst? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

t, but does this warrant new testing? No! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

E grouped update which has been in testing for a long time. Your "fix" breaks that. Plus, edits can also be only to the description or bug references, Bodhi doesn't allow me to edit those without editing the whole update. Kevin Kofler -- devel mailing list deve

Re: The slip down memory lane

actual target. If you schedule for a later date outright, you won't solve the problem, you'll just make it worse.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

to be broken. We HAVE to accept that Rawhide is sometimes broken to be able to do active development. If we need Rawhide to be always 100% regression-free, we will never get anywhere. It's Rawhide for a reason. Kevin Kofler -- devel mailing list devel@lists.f

Re: The slip down memory lane

nd to fix a lot of bugs. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

e for such a "feature" is in Rawhide immediately after the branch (i.e. they could have put it into F14 instead of F13 at the same time, that would have been borderline acceptable, what they did was absolutely not!). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

to accept this. If we really want to meet specific target dates for the release, e.g. May/Nov 1, then we need to schedule at least 2 weeks EARLIER, i.e. officially schedule for Apr/Oct 15 and compute all deadlines accordingly. Then the inevitable slips will just do the rest. Kevin Ko

Re: New bodhi release in production

refuse to accept the Fn karma as grounds to push the Fn+1 update. No amount of arguing helped. Such broken upgrade paths are now going to be extremely common with this useless, broken and inflexible procedure. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org

Re: New bodhi release in production

waiting another full week (also quite a bad option). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

mple time for invasive changes in Rawhide, Fedora can't be leading without the occasional breakage in Rawhide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

test the updates before +1ing them (as they're expected to). This excessive and useless QA adds delays over delays. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

et some support due to our objections to the critical path process as a whole.) We (KDE SIG) have been more or less forced to participate in a process most of us (and me in particular) do not agree with and consider outright harmful. Kevin Kofler -- devel mailing list devel@li

Re: New bodhi release in production

idered critical path, you also have to allow KDE people to approve critical path packages. (In fact, I think we actually need much more than one KDE proventester in the long run.) And likewise for XFCE and LXDE. IMHO, FESCo should be abolished, Fedora needs to be ruled by the S

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

to fit our needs. Backporting, sometimes from more or less unofficial development branches, is a required part of being on the leading edge. We cannot be "First" with a religious adhesion to upstream. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin

Re: New bodhi release in production

rnight, even if it's clearly better. But that's moot in the absence of infrastructure anyway.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

In addition, another objective of Fedora is to "include a wide range of packages", so we should support technologies which allow us to ship more packages on our live images. Basically, we're missing out on an important new feature and shipping less featureful live images th

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

Jesse Keating wrote: > Do you have any sort of proof that it's a "political" reason? It would > seem to me that our kernel maintainers do not wish to include code that > hasn't been blessed by Linus in our packages. That's political. Kevin Ko

Re: "Staying close to upstream"

ing, if we ask for getting the trademarks removed, they say that it wouldn't change anything anyway. Either they're just using the trademarks as an excuse for their laziness, or the trademarks are the problem and need to be removed, it's one or the other. Kevin Kofler --

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

ns the 4 desktop SIGs. (And FWIW, GNOME really needs a community-oriented SIG instead of the current "RH Desktop Team == Fedora GNOME maintainers" practice.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The slip down memory lane

don't work for RH, I can't attest to the truthfulness of those rumors, and I guess those who theoretically could aren't allowed to comment on it). You have to choose between timeliness or quality. I'll take quality any day (as long as it doesn't get ridiculous like

Re: New bodhi release in production

Jaroslav Reznik wrote: > Then we have to push broken updates, policy says so and it's ok, so let's > do it > :( A policy requiring us to push something broken is broken. I'm not going to push broken shit. Kevin Kofler -- devel mailing list devel@lists

Re: What does the DVD media check if installing a new Fedora version? / Proposal

u can check to verify the burned stuff. (If I'm not mistaken, it actually does a bytewise compare these days, not a checksum.) You can also run sha256sum /dev/cdrom and compare the result with the published checksums. Kevin Kofler -- devel mailing list devel@lists.fedo

Re: "Staying close to upstream"

our goals in a way coordinated throughout the distribution? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New bodhi release in production

wever, looking at the code a bit >> closer, your scenario would currently be allowed, as it currently only >> calculates the time-in-testing based on the first push to testing. > This behavior is helpful, because otherwise updates would "starve". +1 Once again, we're i

Re: New bodhi release in production

Rahul Sundaram wrote: > I expect more fine tuning will be needed for these changes but thanks for > all your work on this. No thanks from me. By implementing FESCo's diktats defying common sense, you broken updates for everyone. Kevin Kofler -- devel mailing

Re: New bodhi release in production

n proposed? Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are just political bureaucrats. Proper meritocracy means the SIGs get to decide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

with in the first place; it's a lot easier to regularly rebase a patch than to make it palatable to upstream, that's why there are so many out-of-tree patchsets). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: "Staying close to upstream"

stuff merged if you know the right people. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

  1   2   3   4   5   6   7   8   9   10   >