Re: [RFC PATCH] use sulogin in single-user mode
On Fri, Jan 22, 2010 at 13:15:04 -0500, Tony Nelson wrote: > > Put SELinux into Permissive mode for single-user mode? Or just print a > suggestion to do that? (I'd think that SELinux would normally be > perceived as an obstacle to the normal uses of single-user mode.) I think doing it automatically is a bad idea. It doesn't save much over typing "setenforce 0". It does however reduce the security of the system if you do it by default and there is a vulnerable window before you get "setenforce 1" entered. The notice seems odd, but I don't think it would cause actual problems. I just think it would be odd to know to boot to run level 1 without knowing how to set selinux to permissive mode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging an application that phones home
On Tue, Jan 26, 2010 at 18:46:32 -0800, Eric Smith wrote: > > The Licenses page of the MeshLab wiki gives a privacy disclaimer stating > that it phones home periodically to check for availability of updated > versions, and that it uploads some aggregated statistical data about the Updates should come through Fedora so there shouldn't be a need to check their site for updates. > average number and size of the opened/saved meshes. Nothing personally > identifiable, though they obviously could capture the source IP address: This should be opt in or dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines
On Sun, Jan 31, 2010 at 22:32:57 +0100, Gianluca Sforna wrote: > On Wed, Jan 27, 2010 at 9:00 PM, John Poelstra wrote: > > A friendly reminder that yesterday, January 26, 2010, we reached the > > Feature and Spin submission deadline. > > Where is the list of accepted spins? > https://fedoraproject.org/wiki/Releases/13/Spins > says it's a placeholder, still https://fedoraproject.org/wiki/Category:Spins_Fedora_13 Some of those are kickstart only and won't have prebuilt isos for download. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Board efforts: scope, concept, and permission?
On Tue, Feb 02, 2010 at 17:16:14 -0500, Toshio Kuratomi wrote: > > Who's been told to fork Fedora because of the status-quo-target-audience? The guy who was complaining about nonfree firmware. He actually made a forked distribution for at least a while. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Asterisk 1.8 in Rawhide (F-15)
On Sat, Aug 07, 2010 at 18:04:29 +0200, Felix Kaechele wrote: > Furthermore I'd be interested in comaintaining the Asterisk stack, > especially also the DAHDI package, as I plan to submit the DAHDI kmods > to RPMFusion and it would be easier for me to keep stuff in sync if I > had commit access. That would be nice. The ATrpms version isn't buildable without some other special stuff and I want to get current builds when testing new kernels. I currently use a spec file that I got from Tony Messino (sp?). It downloads some firmware that I don't need every build, and I'd like to have a leaner package that I can use for doing rebuilds to match new kernels. (Even if it is in rpmfusion, I'll probably want to do rpm rebuilds to get new versions immediately,) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Thu, Aug 12, 2010 at 13:27:05 +0200, Jaroslav Reznik wrote: > Problem is not an image (we will provide it in the future, forever), the > issue > is size constraint - software grows faster and faster, we have more > dependencies > etc. -> means less software on LiveCD... I hope to occasionally push back a little against this. When LZMA squashfs makes it upstream (it looks like it won't happen in time for F14) we will probably gain about 10% on what we can fit in a given size image. Another change that could happen is 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. Also looking forward, USB drives are less limited in space and faster (especially seek time) than spinning disks and make more sense for live images in many circumstances. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Thu, Aug 12, 2010 at 14:50:38 -0400, Nathaniel McCallum wrote: > > One thing I am curious about is why, when slipping for an Alpha target, > the whole schedule slips. Can't we just take a week out of the Beta > cycle? The amount of testing time is roughly the same. We've tried that in the past and it didn't work. Slipping the whole schedule right away is better than slipping piecewise when it comes to planning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Thu, Aug 12, 2010 at 13:19:29 -0500, Mike McGrath wrote: > Since 2006 we've slipped at least 16-18 weeks by my count. That's more > than half of a full release cycle. > > Thoughts? One thing I have noticed is people landing big changes (such as python and systemd) that break things for a while, delay a lot of other testing. So that when the bigger changes get fixed up, other bugs get unhidden with little time to react. I'd like to see the big changes land a lot earlier, maybe a month before the branch, so that by the branch most things should be easily testable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Thu, Aug 12, 2010 at 12:00:29 -0700, Adam Williamson wrote: > > We usually catch most initial blockers for any given release at the > first TC stage. Bugs we slip for are usually ones identified at that > stage that we couldn't fix in time, bugs introduced between TC and RC by This is another place we could change things. We could build the TC a bit earlier (say a week) and be more conservative about what changes go in until the final RC is approved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14/F13 - system-config-display - should it work?
On Thu, Aug 12, 2010 at 14:32:21 -0400, Felix Miata wrote: > > So users of absent or dysfunctional DDC and/or EDID should be committed to > 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still > working just fine) displays or learn the cryptic and complicated methodology > to using xrandr and script editors? Does the Gnome module work for those who > never Gnome's DTE? system-config-display isn't good enough to fix that any more in any case. Those of us with antique displays not only need to give a desired display size, we need to define a mode line for it as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 01:18:29 +0200, Kevin Kofler wrote: > Bruno Wolff III wrote: > > I hope to occasionally push back a little against this. When LZMA squashfs > > makes it upstream (it looks like it won't happen in time for F14) we will > > probably gain about 10% on what we can fit in a given size image. > > It's quite sad that we're waiting for upstream there. The feature exists, we > could ship it, yet we prefer crippling our live images by dropping more and > more applications to meet the size constraints with obsolete compression > technology. What happened to the leading-edge Fedora? We'll until Lougher writes something that Linus will accept, we need to wait. I think someone paid him to work on xattr, so it makes sense that he would give that higher priority. > > Another change that could happen is 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? I am not sure. I haven't looked into it too deeply yet. I have enough stuff to do that I probably won't get to it real soon. I would guess there would be some way to make it work, but it might be a little different than what happens now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 16:54:22 +0200, Kevin Kofler wrote: > Chris Adams wrote: > > Why don't you give the kernel maintainers the same courtesy? > > Because LZMA SquashFS is a feature which affects the live images, and almost > exclusively the live images, and as such the SIGs controlling the live > images should be the ones making the decision. This means the 4 desktop > SIGs. (And FWIW, GNOME really needs a community-oriented SIG instead of the > current "RH Desktop Team == Fedora GNOME maintainers" practice.) In this case I think waiting is better, even though I proposed the feature. I was planning on requesting a back port if a patch for it gets accepted for 2.6.36, but it seems unlikely to happen as the merge window will be closing shortly. The issue is that if we apply the patch that was submitted for an earlier kernel (2.6.33 I think), and it had a problem due to some other change in the kernel, we don't have a practical way to support it. (While Lougher was VERY helpful recently with tracking down a squashfs-tools bug, we can't always count on having a few days of his time to provide us with support.) I really think the benefits and costs need to be looked at on a case by case basis and the package maintainers should be the ones making the call. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Thu, Aug 12, 2010 at 22:22:18 -0700, Jesse Keating wrote: > > How do you suggest we be "more conservative"? If you expect the > developers to do this on their own, good luck. If you want there to be > some sort of enforcement I welcome suggestions. My suggestion would be to ask developers not to move stuff from testing to stable unless it was a significant bug fix update, during that period. How much effect just asking would have, I don't know. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Fri, Aug 13, 2010 at 09:49:42 -0600, "Nathanael D. Noblet" wrote: > > Since the move to git, would it not be easier to allow features to > branch rawhide, get their individual bits together (syncing with 'trunk' > periodically)... Then like the kernel does, merge back the working bits > to rawhide for the alpha. Which would essentially then be making sure > that the features that were merged in play nice together? With no frozen rawhide and early branching, I don't think this is really necessary, you can do development in rawhide and go back to the branch when ready. Most features are fairly independent and don't cause problems when they run late or have problems, outside of that feature. Some are somewhat disruptive and can make it hard to test other things while they are having their kinks worked out or just waiting for rebuilds of dependencies to be completed. Those can cause a problem if they happen too close to a freeze since they result in work needing to be done in a very short time frame. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Engineering Services - Help Wanted!
On Fri, Aug 13, 2010 at 10:04:22 -0500, Michael Cronenworth wrote: > Mike McGrath wrote: > > Do you like fixing things but don't care what? > > > > Are you a jack of all trades sort of person? > > > > We need your help! > > Hey Mike, > > I know you're a cool guy and would be interested in signing up. However, > what kind of work would this entail? I see "4 hours per week" listed, > but could you go into more detail about what that 4 hours would cover? You can take a look at the tickets to see what kind of things have been requested so far. https://fedorahosted.org/fedora-engineering-services/report/6 Some of the stuff is fun. I keep meaning to do more, but i have gotten sucked into spins related stuff that is taking up most of my available time right now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 18:20:29 +0200, Kevin Kofler wrote: > Bruno Wolff III wrote: > > I really think the benefits and costs need to be looked at on a case by > > case basis and the package maintainers should be the ones making the call. > > The problem is, the kernel maintainers (and you, apparently) don't seem to > realize what big difference a 10% improvement in compression rate makes to > our live images! For KDE, we have to fight for every single MB, often making > tough decisions (e.g. size constraints are why we no longer ship Amarok on > the live image). Better compression would allow us quite some headroom to > work with. I think I do realize that a 10% size improvement is very nice. Unfortunately I don't have the ability to maintain Lougher's previously posted patches (and have other work important to Fedora that would greatly suffer if I took time out to learn how to do it). I have similar issues with the Games Spin. That's why I have been pushing for this. But I don't have the money to pay Lougher to do a new implementation now, nor do i have time to learn how do an implementation myself. Also note, that all of the infrastructure is in place except kernel support. So that if say 2.6.37 gains LZMA support for squashfs, you'll be able to use it in F14 to do builds taking advantage of it. You won't necessarily need to wait for F15 to start taking advantage of it. (Though it will end up being too late for the GA Release images unless something unexpected happens in the next few days.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Fri, Aug 13, 2010 at 19:07:57 +0200, Kevin Kofler wrote: > Bruno Wolff III wrote: > > Most features are fairly independent and don't cause problems when they > > run late or have problems, outside of that feature. Some are somewhat > > disruptive and can make it hard to test other things while they are having > > their kinks worked out or just waiting for rebuilds of dependencies to be > > completed. Those can cause a problem if they happen too close to a freeze > > since they result in work needing to be done in a very short time frame. > > The problem is that those are the very features that are hard to stage, > because the sets of packages to rebuild often intersect. I agree. My wish is that these be done a bit earlier so that they don't cause problems when other packagers (and people working on spins) are up against deadlines. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mailing list guidelines and smartphones
On Sun, Aug 15, 2010 at 00:32:46 +0200, Sven Lankes wrote: > > Smartphones seem to be changing this and the number of full-quote, > top-post emails is increasing steadily. I prefer that if it's too hard to intersperse text, that all of the old message be removed. The signatures that are primarily ads are annoying as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin development: how to trust an iso built outside the fedora build sys
On Sun, Aug 15, 2010 at 19:02:36 +1000, David Timms wrote: > > I was wondering if there is any process that we (spin developers - music > list) could use to confirm that a spin iso was > 1. built with a particular kickstart file (or list of files when there > is kickstart %include x directives). > 2. hasn't been doctored on purpose eg by the person building the iso, or > corrupted by the upload/download process > 3. hasn't been tainted by unknown code on the build machine My first suggestion is to build the iso yourself. > A few thoughts: > 1. the spin build process could place copies of all the spin kickstarts > files in a folder on the destination machine eg /root/build-process. > This would be in addition to the automatically created anaconda-ks.cfg > (which is the combined ks file). A fake spin could put the files you expect there, but not really use them. > 2. shaNsum created by the spin creator and uploaded alongside the iso That is reasonable if you both create and distribute isos. > 3. content test by downloader of the iso: > - mount -o loop/image on existing known good system > - using known system rpm -Va all packages Weeding out false positives here would make this step pretty tricky. > - using known system tools, compare filelist from on image rpm db with > complete list of files on disk to indicate every "extra" file present > anywhere on the image. list the name and contents of them. > - above check to indicate every "modified" rpm installed file > 4. If a user builds a spin at a different time, or with repo out of > sync, I expect that I could get different versions of packages in my > build, so I don't think you could say: User built from the spin > kickstart, and has a different sized/content iso, hence the original > spin is "faulty". Does that make sense ? I don't think you get bit identical spins if you build at different times, and you certainly don't if there are different versions of packages being used. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Sun, Aug 15, 2010 at 16:44:29 -0700, Matt McCutchen wrote: > On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote: > > Some web sites are indeed abusing JavaScript. > > > A web site is > > not and should not be an application, an application is not and should not > > be a web site. > > Just because you said so? Web applications bring enormous practical > benefits to their users and administrators. My view is that they show only be used for applications when that application is going to be used by someone with a trust relationship to the application provider. For example when using Peoplesoft at work it makes sense, since I trust my employer to not be trying to hack my work desktop. I think using javascript for pages meant to be used by the general public is a bad idea. It encourages people who don't know better to enable javascript for general browsing, which signifcantly increases the risks to them for having credentials stolen or their desktop hacked. Instead things should be done server side, with style sheets or xforms. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Mon, Aug 16, 2010 at 15:48:14 -0700, Adam Williamson wrote: > > Meanwhile, back in the real world, it is effectively impossible to use > all sorts of useful websites without Javascript enabled. Even for Then don't use them. If sites don't get used they may stop requiring people to significantly reduce the security of their systems to use them. It doesn't even have to be all of them, just the ones that aren't that important. > Shipping a Firefox with no ability to use Javascript would be more or > less equal to not shipping it, frankly. No-one would use the thing. While I think Firefox could do several things to increase it's real security instead of it's apparent security, I was actually complaining about the server side. Sites that use javascript encourage people to leave it turned on and even optional javascript is bad. Other ways of doing things (xforms, css, server computation) should be used instead. (Things that are really applications used with a special trust relationship and not by the general public are different.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Mon, Aug 16, 2010 at 17:08:27 -0700, "J. Randall Owens" wrote: > > Maybe you should file a bug against Javascript in Firefox? Oh, wait, > bugzilla uses Javascript, doesn't it? Scratch that, no bugzilla for the > purists. I don't use it with javascript enabled. Unfortunately the javascript code still slows downloading down. The only Fedora Project web page that I use with javscript enabled is the package database. It doesn't seem to work (when asking for access) if you don't have it enabled. I have filed bugs against apps where not having javascrip enabled broke things and they have been fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release bumps scripts caution
Release bump scripts bumping release version numbers for prereleases should be handled more carefully or they can cause update problems later on. For example xorg-x11-drv-ati-6.13.1-0.20100705git37b348059.fc14 got bumped to xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14 and then later xorg-x11-drv-ati-6.13.1-0.2.20100705git37b348059.fc14. Perhaps release bump scripts should be adding something to the end of the string so as not to break prelease version numbers. If they aren't already checking for version information after the dist-tag, that is another potential place for breakage, though not generally a problem for rawhide where mass rebuilds with scripts are typically done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Release bumps scripts caution
On Wed, Aug 18, 2010 at 12:04:33 -0700, Jesse Keating wrote: > > This likely happened because the original release string was non-conformant. I missed that. After that happened it looks like the release string did get changed to be conformant. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Mon, Aug 23, 2010 at 23:05:11 +0200, Lennart Poettering wrote: > > I know I am repeating myself: everything's wonderful. Maybe now, but the landing close to alpha made it harder to do some other testing needed before the alpha. (Though the fallout from Python and Boost updates, seemed worse.) I would have liked to have seen this land about a month earlier than it did. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Mon, Aug 23, 2010 at 23:30:22 +0200, drago01 wrote: > > Being "2 months old" isn't a problem in itself ... bugs on the other > hand might be if they can't be fixed in time (this does not include > already fixed ones). It is already too late. The bugs impacted alpha testing and probably in at least part contributed to the slip. Features (changes in general) that impact testing of significant fractions of the system should not be landing close to the alpha freeze. It makes it difficult for other people to get their work done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: a note on order of arguements to systemctl command
On Tue, Aug 24, 2010 at 16:45:49 -0500, Garrett Holmstrom wrote: > > I'm of two minds here. On the one hand it would be nice to preserve the > long-standing syntax convention for the reason Matt described. But on > the other hand, putting the verb before the object seems to mesh well > with how the English language usually works. systemctl also allows multiple objects which service didn't. With multiple objects it makes sense to put the action first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd v8 for rawhide?
On Fri, Aug 27, 2010 at 09:10:35 -0700, Jesse Keating wrote: > - -updates. A potential way to fix this is to have bodhi not /move/ the > build from dist-f14-updates-candidate into -testing or -updates, but > instead just add -testing or -updates as a secondary tag to the build. > This should ensure that the latest /built/ is nearly always the latest > /tagged/ in -candidate. What side effects this might have on the rest > of the system I don't know at this point, but messing with our tag > structure is not something to be taken lightly. This would also tie in to keeping stuff in testing for a while after it has a request to move to stable. Which if rpms are signed by the same key could save some mirror churn. And help with dealing with builds disappearing from the branched testing repo and yum not knowing if the builds were untagged because they were bad or moved to stable because they were good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 17:16:12 +, "\"Jóhann B. Guðmundsson\"" wrote: > It's not far from reality that Red Hat will get bought by a company > like Oracle so what's preventing us to get the same treatment as > OpenSolaris got? > > What happens to all the work the community has done, the fruits of > our labour? The code being distributed and needed for the build system are available. Removing the trademarked pieces are easy. So the project would need to change it's name, get new hardware and network service and hope enough community members continued to work on it and that there weren't ogranization issues caused by Redhat employees in leadership positions being lost. > The first mistake we did was trying to label end user since it's not > up to the project in whole to decide which end user type it's > target. I disagree. I think the project is the entity that needs to determine this. > It's should be up to individual community SIG's to decide what user > base they are targeting and the form they will present that to the > end user in live cd or a predefined installation option be it with > the latest and greatest bits of their product or a not which may or > may not be influenced from feed backs from the micro community they > have established around the product they ship. SIGs will be given a lot of lattitude and the target user will be used for resolving conflicts between SIGs. > The Fedora project in whole should give equal access to those bits > and devote equal amount of marketing resources to promote them. I disagree. Resources are limited. We need to prioritize marketing where it will best benefit the project. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 17:43:35 +, "\"Jóhann B. Guðmundsson\"" wrote: > > Unfortunate this has the side effect off taking side of one part of the > community over the other ( and the problem that comes with that ) and > usually people that are asked in cases like these are not the once > directly affected by the outcome of that decision. If two parts of the project have conflicting desires, than one is not going to get what they want. > Not following you here as I see it there would be no conflicts if the > SIGs them selves decided who their target audience is. SIGs don't work in independent silos. They share code and resources with the rest of the project. As such they can have conflicts with other SIGs. > 1) > What would be the criteria to determine how to spend those resources. I don't know. Marketing isn't my field. There is a marketing team and maybe someone from that group could weigh in on this. > 2) > Should we not then be spending all those resources strictly on core > components on marketing the community in whole where all would benefit > not a sub community within the community in whole.. That is still going to favor some SIGs over others. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 11:42:15 -0700, Jesse Keating wrote: > > This is utter bullshit. It assumes that anybody who works in the corporate > world and happens to have an interest in Fedora is somehow going to be a > puppet for the Smokey backroom corporate overlords and their evil designs > upon Fedora. It's ludicrous. What about people who work for a university, or > work for themselves? Are they somehow immune to making decisions that benefit > themselves or their paycheck writer? For my part I was assuming that the hypothetical buyer might order their employees not to work on Fedora any more if they wanted to keep their jobs. I further assumed that not all of the employees would be in a position to immediately resign and would not be able to participate in the new Fedora for a noticeable period of time. The particular issue with Redhat employees is that there are a lot of them contributing to Fedora and doing a lot of work for Fedora. If my employer banned employees from working on Fedora, I think I would be the only contributor (not counting people who just file bug reports or lurk on the mailing lists) taken out. I think takeover of Redhat by some company hostile to Fedora is possible, but pretty unlikely. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission
On Sat, Aug 28, 2010 at 16:14:42 -0400, Chris Ball wrote: > > How are you defining which things are sponsored and paid for? If it's > "whatever things Red Hat chooses to pay for", then the answer to how > much RH pays for is 100% by definition. If it's "all of the things > Red Hat requires from external contributors in order to make Fedora", > the answer to how much RH pays for is surely more like 10%, assuming > RH's level of contribution to the kernel and GNOME and so on holds > across different projects. Probably he is referring to infrastructure. Servers and network capacity. There is also funding to support events like FADs and FUDCONs. If you count people time, then its probably not that high. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Sun, Aug 29, 2010 at 05:46:31 +, "\"Jóhann B. Guðmundsson\"" wrote: > Times change and people with it and I'm willing to put money were my > mouth is. So let's separate the infrastructure to a neutral ground, > let's find a good place to host the community on. I don't have much to > spare but I'm willing to give it all I got it's not like I have not I've > invested far to much of my time and other things in the project so far.. There is no reason to expect they have changed that much since the last time this was looked at. You still wouldn't be able to have a nonprofit organization (for tax purposes) to handle infrastructure and accept the current level of contributions from Red Hat. People are less likely to donate if their donations aren't tax deductible. Going down that road now seems very dangerous and likely to kill the project. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 21:56:17 +0200, Sven Lankes wrote: > > Also - and this is a question that I have asked myself and others a > couple of times - if you could implement Fedora the way you want: What > unique selling points are left for Fedora? "Fedora is Ubuntu with rpm" > sounds about as bad as "Fedora is broken most of the time" (not that I > feel it is). Freedom Lots of packages Easy to contribute to Up to date at release New technologies (e.g. selinux, systemd, pulseaudio) Just works (except for patented media codecs while waiting for sane patent laws) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 17:33:33 -0400, Arthur Pemberton wrote: > > Well for one, if there is nothing different mission wise between > Fedora and Ubuntu, but Ubuntu gets more attention from desktop users, > then people might as well just all use Ubuntu. Despite being derived from Debian, the Ubuntu project doesn't seem to consider freedom as important as the Fedora project does. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 00:45:49 -0400, Arthur Pemberton wrote: > > So far the only brokeness I have had in all of F13 is with `seabios-bin`. Wasn't there recently a packagekit problem where it stopped doing updates, making it kind of hard to get a fix unless you knew about yum? That's a pretty significant oops. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 08:40:29 -0800, Jeff Spaleta wrote: > > I'm a package maintainer for one such application. I have yet to hear > from a single user...ever..that tracking releases from upstream has > been unwanted for this specific application regardless of the UI > tweaks that happen between upstream releases. In fact I have bug > reports to the contrary asking me to push newer versions because I > originally held back updates across a significant upstream version > boundary. Packages that need to sync to external servers or peers such as multiplayer games have similar issues. You need to be up to date to for the package to be useful in some cases. I would like to see some per package exceptions to this policy that don't need to be revisited for every update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, Aug 31, 2010 at 17:20:23 -0400, Al Dunsmuir wrote: > > Please do not ignore that the browser is there for the user to use, > not for Fedora to stream information in spite of the user's wishes. Nor for Mozilla to track its users. There shouldn't be a start page at all as it opens a connection back to the start page server before you (easily) have a chance to disable it. It is especially annoying that that after updates you still get some Mozilla update page (that at fisrt glance appears to be from a remote server, though maybe there is some trickery going on) even though the start page is disabled. I would think respecting the privacy of our users would be a good reason for having no start page the default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, Aug 31, 2010 at 17:46:53 -0400, Matt McCutchen wrote: > > The update page is remote. If you want to disable it, set > "startup.homepage_override_url" to the empty string. There is also > "startup.homepage_welcome_url" for the first run of the browser. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Putting cross compilers into Fedora
On Wed, Sep 01, 2010 at 11:41:34 +0100, David Howells wrote: > > Would it be worth our while putting into Fedora basic gcc and binutils rpms > for cross compilers for all the Linux arches? I keep finding the need to > compile kernels for arches other than the x86_64 boxes I normally use, and I > keep borrowing prebuilt compilers off others (usually Al Viro - thanks Al!) to > do this. > > However, as the kernel advances, older compilers cease being able to compile > it, so I have to go finding new compilers again. Openwrt's build environment builds the needed cross compiler for you. It works on Fedora. It may be a place to look for an example build system for doing this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 youtube support?
On Thu, Sep 02, 2010 at 17:26:28 +0200, Michał Piotrowski wrote: > 2010/9/2 Daniel J Walsh : > > It could be an SELinux problem. Look for AVC messages. > > No AVC's releated to flash-plugin. I disabled SELinux and it still > doesn't work - so it's not a "security issue" ;) Note that its better to switch to permissive mode if you want to test something like this than to switch to disabled mode. Once you switch to disabled, files don't get properly labelled and when you turn it back on you'll need to do a full relabel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git usage question
On Tue, Sep 07, 2010 at 19:24:58 -0400, Neal Becker wrote: > I need to make a minor edit to one of the sources of a package. I want the > sources on my machine in a state so that emacs will recognize the files are > under git control and act accordingly, so I can do my edits and use emacs > vc-mode stuff to commit, diff, etc. I tried using fedpkg clone + fedpkg > sources. That just gets me the .tar.gz + patches. I tried fedpkg prep. > That doesn't seem to work because it unpacks the source under a > subdirectory. Any hints? This sounds like you are trying to use the wrong git repo. The repo for a package will have a pointer to the compressed tar ball. You won't have easy access to the sources in that tar ball. You add patch files and edit the spec file at this level. If you were working with the upstream for the package (such as one of the projects on fedorahosted), then you could use that repo to deal directly with source. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100912 changes
On Sun, Sep 12, 2010 at 20:06:41 +0530, Rahul Sundaram wrote: > > livecd-tools-034-1.fc15 > > --- > > * Sat Sep 11 2010 Bruno Wolff III - 034-1 > > > > [snipped] > > Thanks for working on this. I was getting worried that this tool wouldn't > be taken care of after Jeremy Katz left Red Hat. Having regular updates is > pretty important for this one. Actually Jasper deserves more thanks than I do. (But I'll take some as well.) I tried to keep the authors of patches correct in upstream commits unless I made significant changes (and didn't want blame going to the wrong person), but I screwed up on at least one (where I was listed as the author instead of signed-off-by person). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ogre3d lagging behind more than half a year
On Tue, Sep 14, 2010 at 11:43:03 +0200, Rudolf Kastl wrote: > heyyas, > > ogre3d, one of the most important 3d engines we have in fedora is > already lagging behind over half a year in rawhide: > > https://bugzilla.redhat.com/show_bug.cgi?id=576286 > > would be nice to see it finally updated atleast in rawhide so it can > go atleast in f15... which means we are only 1 year behind by then. Get volunteers for the Spins SIG lead and Spins Wrangler to free up some of my time and there is a good chance it will get done for F15. It's really too late to try to do this for F14. There are some related packages (e.g. mygui) that also need updating. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ogre3d lagging behind more than half a year
On Tue, Sep 14, 2010 at 08:21:33 -0500, "Conan Kudo (ニール・ゴンパ)" wrote: > I don't think it would have been too late for Fedora 14. It isn't a core > package that needs to be available in a spin, afaik... It wasn't when I was going to try to work on it, but I got swamped with Spins SIG / livecd-tools work and didn't have time to do it. It's really too late to be doing soname bumps for this package for F14. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Tue, Sep 14, 2010 at 21:26:41 -0400, Máirín Duffy wrote: > > Hmm. Here's a couple ideas I could think of: > > - "If you don't place a vote by $DATE, your vote will be assumed to be > $POSITION" can be scarily motivating. > > - Nag emails sent out by trac daily until you click on the email's yes & > no links to vote! (some of the ticket reminder trac hacks might work to > provide this) Maybe we should track voting records and make them available publicly so that at election time people can see if and how people pvoted on issues. I would expect that people would be reluctant to keep people in FESCO who miss a lot of votes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 11:27:07 +0100, M A Young wrote: > > I agree. I was worried when systemd appeared in F14 just before the alpha. > Really we should have been much closer to where we are now at the start of > the alpha phase, and systemd should have gone in soon after F13 was forked > off. This is pretty much my feeling on this too. There really isn't that much time left before final freeze and there are still some backwards compatibility quirks that need to be dealt with (by prominent documentation or elimination) or we are going to cause pain for sysadmin type users. I think things will go a lot smoother having an F15 release. And we can still get the followon improvements originbally planned for F15, as that development doesn't need to wait just because the basic support was slipped to F15. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F12/ Cannot update
On Wed, Sep 15, 2010 at 11:01:04 +0200, Andrea Musuruane wrote: > On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen > wrote: > > File a ticket with FESCo. We should have "*all* packages go trough > > updates-testing, regardless of who's the maintainer or what's the > > reason of an update". If FESCo finds out that this is a bug (some > > packages can be pushed to stable directly) in Bodhi, fix it, ASAP. > > Opened ticket 466: > https://fedorahosted.org/fesco/ticket/466 In the recent Thunderbird case, it may have gotten some positive karma, but no one tried out sunbird as it was completely broken by a typo in the shell script. That push should have never made it to updates. (This was in F14, but still ...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Wed, Sep 15, 2010 at 09:09:58 -0400, "John W. Linville" wrote: > > AIUI, they main technical reason that they were finally willing to > open-up was that they were able to add some regulatory enforcement code > in their firmware. The added firmware functionality required more > firmware resources, and only the newer devices explicictly supported > by Broadcom's newly-released driver have enough firmware resources > to run it. How does the firmware know where you are? Do you need different firmware for different markets? I hope the guys that reverse engineered the firmware that can be used as an alternative with the b43 driver keep working on it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 07:20:30 -0700, John Poelstra wrote: > > And we are already reviewing and accepting features for Fedora 15. The > process never stops. > > https://fedoraproject.org/wiki/Features/Policy Thanks for the reminder; I'll put LZMA back in for F15 and hope the kernel changes make it in by then. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 17:11:03 +0200, drago01 wrote: > > That doesn't work ... someone has to be activly pushing the patches > upstream .. instead of just waiting and hoping that they magically > make it in. It's somewhere on Lougher's to do list. We can still be ready to take advantage of it if it gets completed without being especially active in their development. Just knowing their is a distro waiting to use the stuff when it gets upstream might (or might not) provide additional motivation for getting it done. That said, if someone is willing and able to help Lougher out, I'm all for it. But it is out of scope for my job, which I see as Fedora integration. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 17:20:22 +0200, drago01 wrote: > > I said _someone_ not _you_ ;) ... if Lougher is working on it fine. It's on his to do list, which isn't really the same thing. Lately he has been doing more getting the extended attributes feature cleaned up and a bit with the lzo stuff (which is in the kernel and seems to just be entering the 4.1 dev version of squashfs-tools now). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dependency advice for /sbin/extlinux ?
syslinux recently split out a a subpackage syslinux-extlinux. livecd-tools uses /sbin/extlinux in livecd-iso-to-disk. My questiomn is it better to use requires on syslinux for F13 (and maybe F12) and syslinux-extlinux going forward or should I require /sbin/extlinux allowing the same spec file to be used on F13 as on F14+ and take the hit of having to do a file check whenever livecd-tools is installed by yum? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Thu, Sep 16, 2010 at 18:48:03 +0200, Till Maas wrote: > > Latest design decisions for package management tools include to sign and > verify packages before they are installed. Rawhide RPMs are afaik not > signed, therefore using it for any non testing system that might contain > sensitive data is not a good decision. I believe there is a proposal to sign all packages in either bohdi or koji at some point. Signing would only indicate the package was build on Fedora infrastructure, which is slightly less checking than gets done now, but is probably good enough since there is already a lot of trust going on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dependency advice for /sbin/extlinux ?
On Thu, Sep 16, 2010 at 18:52:41 +0200, Michal Schmidt wrote: > On Thu, 16 Sep 2010 11:07:05 -0500 Bruno Wolff III wrote: > > My questiomn is it better to use requires on syslinux for F13 (and > > maybe F12) and syslinux-extlinux going forward or should I > > require /sbin/extlinux allowing the same spec file to be used on F13 > > as on F14+ and take the hit of having to do a file check whenever > > livecd-tools is installed by yum? > > Paths in /sbin (and /bin, /usr/bin, /usr/sbin) do not take the hit. Thanks, then I'll I'll adjust the package to use the path as that seems less likely to break going forward. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nightly compose not bootable?
On Fri, Sep 17, 2010 at 11:17:19 -0700, Carl Byington wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > desktop-i386-20100916.15.iso fails to boot from cd on dell dimension > 2350. Does it work for other folks? Do you have some more symptoms you can tell us? I did a local compose from around the same time and it worked on a USB drive. So I suspect it's a harware specific problem. If it might be video related, you can hit tab at the first window to get the boot menu and then try using the basic video boot option. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nightly compose not bootable?
On Fri, Sep 17, 2010 at 13:23:27 -0500, Bruno Wolff III wrote: > On Fri, Sep 17, 2010 at 11:17:19 -0700, > Carl Byington wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > desktop-i386-20100916.15.iso fails to boot from cd on dell dimension > > 2350. Does it work for other folks? > > Do you have some more symptoms you can tell us? I did a local compose from > around the same time and it worked on a USB drive. So I suspect it's a > harware specific problem. > > If it might be video related, you can hit tab at the first window to > get the boot menu and then try using the basic video boot option. There was also a recent thread about a problem related to VT-d on a different Dell model which mentioned that disabling iommu at boot made things better. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: rawhide now requires systemd to boot by default
On Fri, Sep 17, 2010 at 23:56:54 +0200, Michał Piotrowski wrote: > Hi, > > What are the current plans for SystemD in F14? Systemd is still listed > as F14 feature. Will it be developed in F14 or in external repo as > Rahul Sundaram suggested? From what I have seen discussed, probably neither. Development will probably proceed in F15 and the primary developers probably won't want to spend extra time backporting stuff to F14. Someone could still volunteer to do that, but I don't expect that to happen. If you really want to help test it, staying on rawhide is probably the place to do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9 for F14?
On Mon, Sep 20, 2010 at 16:00:46 -0400, Arthur Pemberton wrote: > On Mon, Sep 20, 2010 at 3:56 PM, Tom Lane wrote: > > Michel Alexandre Salim writes: > >> Note: I don't think Mark was proposing to do the packaging work himself. > >> But it'd be great if whoever picks this up (Michał, are you a packager?) > >> could reply to this thread, thus avoiding duplication of work and attract > >> potential reviewers once the new package is ready. > > > > I see no point whatsoever in a separate "postgresql9" package. The > > regular postgresql package will be up to 9.0.x in F-15. If you feel > > a need to run a bleeding edge database in F-14, it'll doubtless be > > built as an RPM by upstream as soon as F-14 is stable --- see > > http://www.postgresql.org/download/linux > > > > regards, tom lane > > > So a 6 month wait at best? For it to be in Fedora. But there will very likely be packages built for F14 externally before then. (Plus once there is an F15 srpm, you will be able to easily rebuild it yourself for F15.) You need to remember that bleeding edge to a DBA means something different than for other people. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: calculus of PT_NOTE "for GNU/Linux 2.6.32"
On Mon, Sep 20, 2010 at 11:41:31 -0700, John Reiser wrote: > Executable program files built by gcc+glibc on Fedora 14 contain a PT_NOTE > which says "for GNU/Linux 2.6.32". (For example, see "file /bin/date"; > the presence of a NOTE is indicated by "readelf --segments /bin/date", > but readelf does not display the contents.) What does the PT_NOTE mean; > what program cares about this value? I expect this is the lowest version kernel you can be running executable programs on with this combination of gcc and glibc. > The /bin/date of Fedora 14 does run on Fedora 11 which is only Linux 2.6.30. > So there is no harm in this case, despite "not meeting the requirement." Why? Not that you noticed, but potentially there could have been registers clobbered that you didn't notice or similar things. > If the requirement really is something less than Linux 2.6.32, > then why not note the minimum kernel version that is required? > How far back on previous Fedora releases can the /bin/date (and/or anything > else built by gcc+glibc on Fedora 14) run successfully? What does this mean > for builders who want to build on Fedora 14 and distribute the binary > executable program files to run on other systems? They probably shouldn't be doing that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 01:51:03 +0200, Michał Piotrowski wrote: > > Setting up "official" backport repo will avoid repos fragmentation. > Keeping all cool updates in one place appears to be a reasonable idea. > Am I right? If we had infinite manpower this might be doable on request. As things are, the people that want to do this need to volunteer to do work to make it happen. A good start would be setting up external repos and try to maintain some group of rawhide packages for the in support releases. If this was succesful, I expect getting Fedora infrastructure to make it more official would be possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 10:59:06 -0400, Brandon Lozza wrote: > However, if for example Microsoft had a similar system and did package > software for it. Their users would be up in arms for the latest > firefox too and Microsoft wouldn't keep them on an old firefox > version. Where is the logic in NOT having the latest software as long > as it doesn't break file format compatibility? On windows the user can Unexpectedly changing the UI is also bad. > Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If > you want something better than stable for KDE you can one click > install the factory KDE repo. You can one click install the trunk repo > too. They even have two Chromium branches available for single click > install (version 6 and 7). Perhaps a single click or easy method of > installing a yum repo could be invented that is similar to the one in > openSUSE. That would be a good start. Alternate repos are possible, but take work. Fedora doesn't have spare capacity to be doing this sort of thing right now. If you want to make it happen, you can by leading and working on a project to do that. As long as you are willing to work and can get a at least a few like minded volunteers also willing to work you should have at least some success. People here aren't against having a way to install alternate versions of packagers per se, but are noting that there is a significant amount of work needed. And many of us think there are better ways to be spending our limited time helping Fedora. But if it is a high priority for other people willing to do the work, it's something that could be done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Tue, Sep 21, 2010 at 15:47:04 -0600, Kevin Fenzi wrote: > Greetings. > > I'd like to ask for feedback and helping cleaning up an updates policy > draft page: Do you want feedback on the mailing list or the Talk page pn the wiki? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 12:35:01 +0200, Tomas Mraz wrote: > > - Avoid changing the user experence if at all possible. - this is too > strong condition. In some cases fixing a bug might inevitable change the > user experience and in some cases for example the user experience might > be just severally improved with the new release. So IMO this should be > reworded with much less strong wording such as 'Avoid major changes and > worsening the user experience if at all possible.' Perhaps the definition of "user experience" needs to get fleshed out a bit. I think the intent is that people should be able to easily do whatever they were doing before the update the exact same way after the update. If they need to learn something new after after the update, that's a problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 10:24:38 +0100, "Richard W.M. Jones" wrote: > > I use Rawhide on my laptop and one of my servers, so I'll tell you the > answer to this: because critical components such as the kernel are > often broken. IME this is because there is no testing of these > components before they get pushed out, and also the kernel developers > ignore bug reports. The kernel isn't that big of a deal unless there is a bug tied to your specific hardware. You can make the default the old kernel on updates and upgrade the kernel at a convenient time. If one breaks things for everyone, that will get fixed pretty quick. If there is a bug tied to specific hardware, affecting a small number people, it can take a long time to fixed in some cases. I find it's more just random stuff breaks and I need to work around something at a bad time. This is more likely to happen when some big change first lands. Or when the thunderbird guys update thunderbird and sunbird, but don't care if sunbird even works. If we were better about getting big changes in before the branch, running branched versions would probably be reasonable for people that want something close to a rolling update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 14:06:12 +0200, drago01 wrote: > Some of the reasons I can think of: > > 2) No signed packages There is a plan to deal with that, but I am not sure what its current status is. > 5) To many broken deps, which might prevent applying updates and security > fixes Hopefully autoqa will deal with this. My opinion is broken deps shouldn't be allowed except in updates-testing repos. Not even in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 09:59:51 -0400, Al Dunsmuir wrote: > > If a second rawhide-specific staging repository (equivalent to > updates-testing, so call it rawhide-testing) was added with some > autoqa automation to prevent gratuitous problems (such as broken > dependencies in core components), I suspect the situation would > improve. That is what branched releases have. Running one of these still gets you pretty up to date stuff, but a bit more protection from breakage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 15:34:34 +0100, "Richard W.M. Jones" wrote: > > No, I think you are wrong. > > First of all, I can see no benefit in pushing a package that cannot do > its basic function to Rawhide. Even in Rawhide, no one wants a kernel > that doesn't boot, even if in some circumstances they could go to the > trouble of downgrading their kernel. If we can test these situations > easily and reject these packages, we should just do it. (libguestfs > %check is a proof by example that such a thing is possible and easy in > Koji). My issue was with how much of a problem broken kernels in rawhide are. It's still a problem, but not as big of a problem as other random breakage when trying to run rawhide as your desktop. > Secondly, it does matter that in Rawhide you can at least get to the > login prompt, log in, and get a shell. AIUI this was the basic idea > behind the critical path packages. From the shell you have a hope of > fixing things. Your browser not working is a problem you might be > able to fix with a shell. Your kernel hanging under disk load or > hanging in init scripts (both actual problems with the current Rawhide > kernel) is a good deal more complex to fix. Sure, but if you don't automatically switch to the new kernel on every update (there's a setting to control this), you won't likely run into that because of a kernel update. You might have something else cause that though. The downside is that at some point you need to manually go in and switch kernels. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 17:01:02 +0200, Tomas Mraz wrote: > I say that the example of Webkit should be removed because if it is not > possible to backport the security patch and due to the version update > Midori has to be updated to a new version regardless of the changes of > user experience. The part of the example "judgement call based on how > intrusive the changes are" does not make any sense. We just cannot keep > the old insecure version regardless on how intrusive the changes are. Security isn't binary. It may be that a security update addresses an issue that can not happen in normal cases. It might be reasonable to just document the cases where there is a problem so as to warn people not to do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 17:05:30 +0200, Jesse Keating wrote: > > It isn't going to be perfect, but it'll definitely be better than what > we have now. The other case to consider is two updates in rawhide-pending that each are OK with rawhide, but which together have dependency issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 17:27:43 +0200, drago01 wrote: > On Wed, Sep 22, 2010 at 5:04 PM, Bruno Wolff III wrote: > > On Wed, Sep 22, 2010 at 17:01:02 +0200, > > Tomas Mraz wrote: > >> I say that the example of Webkit should be removed because if it is not > >> possible to backport the security patch and due to the version update > >> Midori has to be updated to a new version regardless of the changes of > >> user experience. The part of the example "judgement call based on how > >> intrusive the changes are" does not make any sense. We just cannot keep > >> the old insecure version regardless on how intrusive the changes are. > > > > Security isn't binary. It may be that a security update addresses an issue > > that can not happen in normal cases. It might be reasonable to just document > > the cases where there is a problem so as to warn people not to do that. > > NO, security issues ought to be *fixed* not just documented. All bugs ought to be fixed. That doesn't mean that if the cost to fix is high, other alternatives aren't acceptible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 17:51:01 +0200, Tomas Mraz wrote: > Of course, the issue might be very minor, but in that case it is not a > "judgement call based on how intrusive thec changes are" but "judgement > call on whether the pros and cons of doing the update are significantly > in favor of pros" The effort needed to make the changes needed for the update is part of the cons and is reasonable to weigh as part of this decision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 18:58:25 +0200, drago01 wrote: > > In case of a security issue a random note somewhere "don't do that" is > not acceptable ... that's all I am saying here. > You are leaving users at risk by assuming that they will read that > notice (note: most wont). I disagree. There are lots of degrees to security bugs. How they are handled depends on the cost of fixing the issue and the impact of the bug. These tradeoffs are made all of the time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 12:35:38 -0600, Kevin Fenzi wrote: > So, that would be, BAD: > > - Changing User interface (moving menu items or buttons around) > - Changing names of commands for command line. > - Changing behavior of command line options (ie, --foo does something > totally different). > - Server packages that require admin intervention to keep working > (database schema changes, config files change options that need to be > modified to the new way), etc. > > Of course there may be cases where we have to do these things, but they > should be exceptions, not something people expect. That seems to cover the bad pretty well. So if an upstream release included something from above and bug fixes, if practical you should backport the bug fixes. If that isn't practical, you need to decide whether the behavior change or the bug is worse. Is it safe to say bug fixes combined with enhancements not covered above would generally be OK? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 12:35:55 -0600, Kevin Fenzi wrote: > On Tue, 21 Sep 2010 17:09:32 -0500 > Bruno Wolff III wrote: > > > On Tue, Sep 21, 2010 at 15:47:04 -0600, > > Kevin Fenzi wrote: > > > Greetings. > > > > > > I'd like to ask for feedback and helping cleaning up an updates > > > policy draft page: > > > > Do you want feedback on the mailing list or the Talk page pn the wiki? > > I folded in changes based on your talk suggestions. > Take a look and see if I addressed them all. I looked and provided some updates in the talk section and fixed a typoish issue in the page. I'd still like to see something about not breaking things shortly before the alpha release as that can lead to slips. Pretty similar to what is said for the pre beta stuff. I found the short bit I wrote up about requesting dist-tags and added a link in the talk section. Probably it's OK to use in the doc, but I thought I'd let you read it first before adding it in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 13:05:23 -0600, Kevin Fenzi wrote: > > ok. I Changed 'Beta' mentions in the Pre Beta section to "Alpha or Beta > releases". Does that work? That looks fine now. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 20:56:07 +0200, drago01 wrote: > > Might be true but a random notice on some website / mailinglist / > $whatever is NOT a fix. period. If one decided to use a notification to mitigate a security issue, one would put the notice where the affected people would be likely to see it. Where that might be, would depend on the circumstances. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 13:01:49 -0600, Kevin Fenzi wrote: > > Right. Also, added to that is: Are the bug fixes worth shipping to > millions of people? ie, do they fix bugs that Fedora users would/have > encountered. That's another gray area without much guidance currently. I think mostly packagers rely on upstream's judgement, for efficiancy if nothing else. But that doesn't factor in the costs to the Fedora project and end users of dealing with updates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 19:33:22 +, Michel Alexandre Salim wrote: > > But branched releases stabilize sometime before the beta point is > reached, which triggered off this huge discussion in the first place, > because Postgresql 9.0 came out too late for inclusion. But if you are tracking branch releases you still need to wait less time. I don't have the planned date, but I think the F15 branch will occur in December which cuts the waiting time down to a about 3 months instead of about 7 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 14:45:03 -0500, Michael Cronenworth wrote: > > Rawhide kernels or using a stable kernel w/ Rawhide are not valid > options. Rawhide is rawhide - development of Fedora, not for production > use. Period. You can't jazz it up no matter how hard you try (Looking at > you Jesse, Adam, and Bruno). Well that depends on what you mean by production and what your needs are. The people that running rawhide or branched are suggested to are generally asking about using it to run the very latest of something (without having to go through the trouble of packaging it themselves). That sounds like testing to me, not production. People that try to both at the same time (like I do for my personal systems) have to balance both uses. > P.S. Can't use proprietary kernel modules (which some people have to > use) with debugging kernels. The world isn't perfect and neither is Fedora. The earlier message about debugging kernels has prompted a message to the Fedora kernel list about that topic. If you are interested in this, you might want to comment in that discussion. (All of one message so far.) http://lists.fedoraproject.org/pipermail/kernel/2010-September/002682.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo?
On Wed, Sep 22, 2010 at 22:38:21 +0200, Benny Amorsen wrote: > > I don't know about "many", but there is at least one organisation > which runs production databases on Postgres on Fedora. People keep > saying that "Fedora isn't for servers", but I just don't see why not. Because it is more work. If one is managing lots of systems as part of a job, you want to be efficient in how your time is used. Fedora systems change to fast for that. If you are running a server for a hobby and have some reason for running Fedora, then it is a reasonable choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 09:34:12 -0400, Brandon Lozza wrote: > > Some people also pointed out another interesting tidbit and that is > proprietary video drivers. Some of us use them and want to be able to > use them. We wouldn't be using a rawhide kernel if it won't load the > modules. I assume users of proprietary kernel drivers would have to > set it up in f13 with rpmfusion and nvidia-akmod first before > upgrading to rawhide. The kmod rpms for rawhide are already provided by rpmfusion. I don't know how often they do them nor how often new kernel releases just plain break the proprietary drivers. But it sure likes look at least some of the time you should be able to use them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing - a second perspective
On Thu, Sep 23, 2010 at 15:51:37 +0200, FlorianFesti wrote: > > 1) Comps groups. Not even used by PK to the full extend. Nevertheless > several groups are huge with over 100 packages (winner being "Games" > with over 300). Sorry, 100 packages in one list view doesn't work for me. Games have meta data that allows them to be further subdivided in their desktop files. This should up in the part of you app that takes that data into account. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 11:23:25 -0500, Michael Cronenworth wrote: > Bruno Wolff III wrote: > > The kmod rpms for rawhide are already provided by rpmfusion. I don't know > > how often they do them nor how often new kernel releases just plain > > break the proprietary drivers. But it sure likes look at least some of > > the time you should be able to use them. > > Bruno, you can't use certain proprietary modules with debugging kernels. > GPL symbols prevent you. In particular, the LOCKDEP stuff. That's interesting, because rpmfusion has nvidia modules in their development repo. It could be that they were for older kernels or something, I didn't look at the versions too closely. > Frank mentioned[1] a viable option for Rawhide, but with Rawhide broken > more often then not, it still isn't a viable option to use every day. I > can't recommend it to Joe Schmoe if he wants Firefox 4.0 and he runs > into broken deps or broken apps and goes off and uses Ubuntu or SuSE > because of it. To use rawhide you really need to be able to fix things; so you need to be an advanced user. There is also the branched release. It should be a bit better than rawhide, but does seem to get broken on occasion. Builds go through testing, so there is a chance to catch a lot of the bad stuff there before it gets to people not using testing. This would still be for advanced linux users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On Fri, Sep 24, 2010 at 17:43:47 +0100, Peter Robinson wrote: > > For the fact that its gone from version X to version Y yes. For the > actual application changed between version X and version Y they can > see the ChangeLog that's in the %doc or alternatively check the > release notes for the new version upstream (which can be easily > provided as a link in the rpm changelog). I just don't see the point > in duplicating hundreds of line of upstream release notes in the rpm > changelog when all that's actually changed in the rpm is that we've > gone from release X to release Y. On the otherside, sometimes all there is, is a note that the version changed. Including a link to the upstream release notes is nice, even if there isn't anything else that seems important enough to call out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Beta corrupts user data
On Sun, Sep 26, 2010 at 10:40:22 -0700, John Reiser wrote: > Compiled code for minimum(), maximum(), etc. suffers from a compiler bug: > https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by cmove > Unfortunately this bug can corrupt user data silently. > > I have hit the bug three times myself (bz 635508, 637303, 637461) > and consider myself lucky that the bad effects were evident and ignorable. > > A fix is in testing, and a critical path update has been approved: > https://admin.fedoraproject.org/updates/gcc-4.5.1-4.fc14 > IMNSHO this will require a mass rebuild of all architecture-specific > .fc14 .rpm. > > Meanwhile, do not use Fedora 14 Beta on data that you value (e-mail, > documents, database, etc.) It really is that dangerous. That's interesting. I just saw an odd regression in the httpd server after updating from F13 to F14. It affects deflate. The F13 httpd server appears to be based on the same upstream version, so it seemed odd. I'm adding a pointer to the gcc issue from my bug report. Do you know when the gcc bug was introduced? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Beta corrupts user data
On Sun, Sep 26, 2010 at 20:32:14 +0200, Jan Kratochvil wrote: > On Sun, 26 Sep 2010 19:58:05 +0200, Bruno Wolff III wrote: > > On Sun, Sep 26, 2010 at 10:40:22 -0700, John Reiser > > wrote: > > > Compiled code for minimum(), maximum(), etc. suffers from a compiler bug: > > > https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by > > > cmove > [...] > > Do you know when the gcc bug was introduced? > > gcc-4.5.1-4.fc14: PASS > gcc-4.5.1-3.fc14: FAIL > gcc-4.5.1-2.fc14: There was no -2. > gcc-4.5.1-1.fc14: PASS Does that mean the problem is restricted to packages built after gcc-4.5.1-3.fc14 was built on September 7th? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 21:50:21 +0200, Jan Kratochvil wrote: > On Mon, 27 Sep 2010 19:53:09 +0200, seth vidal wrote: > > On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote: > > > When will the Fedora project begin recommending x86_64 as the > > > preferred option on the relevant hardware? > > > > i686 will run on x86_64 and i686 machines and on the overwhelming > > majority of hw someone will happen to have. > > > > x86_64 will not. > > F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically > choosing x86_64/i686. I was told it is too late for F14 biarch spin but for > F15+ that one should be the best default. > > (With all the movie downloads around please do not reply wrt file size.) It still matters whether or not stuff fits on target media. The number of published spins might also change with F15. Spins SIG as it has been designed isn't working and needs to change. What that change will be hasn't been worked out yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 22:15:48 +0200, Jan Kratochvil wrote: > On Mon, 27 Sep 2010 21:58:26 +0200, Bruno Wolff III wrote: > > On Mon, Sep 27, 2010 at 21:50:21 +0200, Jan Kratochvil > > wrote: > > > F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically > > > choosing x86_64/i686. I was told it is too late for F14 biarch spin but > > > for > > > F15+ that one should be the best default. > > > > > > (With all the movie downloads around please do not reply wrt file size.) > > > > It still matters whether or not stuff fits on target media. > > After CDs have been replaced by DVDs which have been replaced by flash > disks(*), have you ever seen a CD-only drive? Popular small notebooks have > even no longer a DVD drive. > > (*) That it makes no sense with Internet is offtopic for what is popular. Some people still burn CDs as they are a bit cheaper. Some file systems in popular use, have file sizes limited to 4 GiB (which is less than fits on a DVD). There are still breakpoints in sizes and these may be more important than being able to run natively in both i686 and x86_64 modes with the same media. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 23:00:45 +0200, drago01 wrote: > > The x86_64 vs. i686 thing aside ... IMO the CD size limit does more > harm than good and should have been lifted a while ago. The CD size limit is self imposed by the Spins that choose to do so. The 4 GiB size limit is a Spins SIG rule, that all published spins are supposed to adhere to. Desktop considered using around a 1 GB target for F13, but in the end decided to stick with being CD sized. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 23:35:43 +0200, drago01 wrote: > On Mon, Sep 27, 2010 at 11:32 PM, Bruno Wolff III wrote: > > On Mon, Sep 27, 2010 at 23:00:45 +0200, > > drago01 wrote: > >> > >> The x86_64 vs. i686 thing aside ... IMO the CD size limit does more > >> harm than good and should have been lifted a while ago. > > > > The CD size limit is self imposed by the Spins that choose to do so. > > My point was that "but it does not fit on a CD" is a moot point. The individual spins groups decide that for their spins. Some of them seem to think targeting CDs is important. I don't know the specific reasons as I am not in any of those groups. (I do handle the Games Spin, but that targets 4 GiB.) If you want to change their minds, you should consider participating in the relavent groups. As for supporting larger possible spin sizes, I am all for that. That's why I pushed for UDF and LZMA support for livecd-tools. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another bug that would have been caught if packages went through a boot/acceptance test
On Wed, Sep 29, 2010 at 10:57:11 -0400, James Laska wrote: > > In fairness, reboot was tested by a proventester for this update. The > bug doesn't surface on reboot alone. The problem happens after prelink > has run ... then you're hosed. You still had a chance if you didn't reboot. rpm still worked for me on the second system I saw. Unfortunately on the first one, I assumed I lost a fan and shut the machine down and then was pretty hosed as chroot wouldn't work as my livecd's were too old and the minimum kernel level was a problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, Oct 06, 2010 at 08:29:32 -0400, Brandon Lozza wrote: > > Interesting, from the meeting we can tell > > 1) A number of people want to give Mozilla an exception. > > 2) BRANDING is an issue, like I said in another thread. Which is why > people are against removing it. People have claimed that the Firefox brand helps Fedora. I'd like to see some measurement of this. Especially in our target audience. > 3) Maintainers for Mozilla aren't being expected to follow package > guidelines, citing the use of system libs as a source of extra work. Yes and no. There are suggestions that Mozilla does eventually intend to use the upstream libraries once they are considered good enough (except for maybe libpng because of the fork) and so the exception is temporary per library. > 4) People still seem to think that Iceweasel is somehow inferior to > Firefox. Plus if Fedora removed the branding it wouldn't remove > compatibility, source code, plugin support and wouldn't introduce > so-called "sketchy" patches. I don't think that just debranding Firefox would be all that much extra work. Doing that would leave us positioned to do other changes when we were ready and to be able to more quickly respond to security issues. Replacing on of the library dependencies would be work and doing all of those might not currently be sustainable. Also the maintainers of the affected libraries in Fedora would need to help as there are patches in Firefox for some libraries that aren't upstream. There was also talk about whether or not it would be allowed for there to be a separate Iceweasel package in Fedora. This might be done to test the feasibility of maintaining it. There were mixed feelings about this amoung FESCO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, Oct 06, 2010 at 10:59:08 -0400, Nathaniel McCallum wrote: > > I have an idea... I'm going to create a fork of Fedora. I'm going to > fill it full of proprietary shit. I'm going to find the buggiest closed > drivers I can find and load them into the kernel. I'll also make it so > that you have to type in your credit card number just to login. I'll > register a fedora derivative domain name and SEO the hell out of it. > Then, I'll tell people my distro is called Fedora Ultimate Edition. > Everyone will believe me because I'll leave all the Fedora artwork in > place. I'll also publish is under the pseudonym of Ralf Corsepius: Ralf > Corsepius' Fedora Ultimate Edition. The Fedora project goes pretty far in making it easy to produce an unbranded version of Fedora for people that want to do that. The trademark protected stuff is supposed to be in just a few packages that have alternative packages in the distro already, that can replace them. I think that makes a point that Fedora isn't trying to abuse trademarks to keep supposedly open source closed. I don't think Mozilla is trying to abuse their trademarks either (though there have been open source projects that have). I don't think they go as far as fedora in making it easy to make a rebranded application, but they certainly don't make it very difficult either as there is an Iceweasel out there. The issue seems to be that Mozilla's policies for their brand conflict with Fedora's policies for their brand and that Fedora has limited resources. I don't think anyone is being evil here. There are reasonable positions on both sides of the argument. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, Oct 06, 2010 at 12:29:59 -0400, Nathaniel McCallum wrote: > > The only possible room for debate that I see is that there is, in > Firefox, a potential conflict between our "ship upstream" and "don't > bundle libs" values. We have FESco to sort that out. Those are the policies I was refering to. > In short: No big deal. Close the thread. Move on. ;) Well the project doesn't seem to be coming to consensus on this issue. Some of us feel that we should provide an Iceweasel or drop Firefox, similar to other things the project has decided to not package. Others think that Firefox is so important to the project, that we must make an exception for it. (And to some extent, that we should stay close to upstream.) Some have also hoped that Mozilla would change with regard to bundled libraries in the near future, but that seems pretty unlikely. I don't think this is just a FESCO issue. I really think this is a board issue as it has to do with the relative importance of our bundled libraries policy, our stay close to upstream policies, the impact on our user base of replaceing Firefox with an unbranded version or just dropping it and the morale of various developers if we give or don't give Firefox an exemption to the no bundled libraries policies. For example it may be that we can't do an Iceweasel, because the current packagers of Firefox may refuse to do that as an alterative to packaging Firefox and we may not find new volunteers to do the packaging work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, Oct 06, 2010 at 12:25:27 -0500, Chris Adams wrote: > Once upon a time, Bruno Wolff III said: > > Some have > > also hoped that Mozilla would change with regard to bundled libraries in the > > near future, but that seems pretty unlikely. > > I think that's an unfair statement; from what I understand, Firefox has > already unbundled some libraries, and said they will unbundle others > once their changes settle down. I guess that depends on what one means by near and unbundled libraries. I got the impression that the vpx stuff was months away from being unbundled. And there is no apparent commitment not to bundle new libraries going forward. So that there will need to be an ongoing exception to cover any new libraries that get used by Firefox. It does seem that specific libraries do end up getting unbundled in most cases eventually. However at least one library is likely to be a long term fork because Mozilla and upstream disagree on the feature added to the Mozilla version of the library. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 12:04:49 -0500, Mike McGrath wrote: > > We also decided to allow yubikeys as an authentication option for the > larger community to some hosts and services like fedorapeople.org or > https://admin.fedoraproject.org/community/. When asked for a password, > just use your yubikey to generate a otp instead. Those wishing to use one > may purchase a yubikey on their own at: While I won't make this Fudcon, I am wondering if it might be worth getting some idea of what interest there would be for people wanting those and getting a bulk discount and having people pay for them at a Fudcon. It looked like even 10 got you a decent discount. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 11:41:13 +0100, "Richard W.M. Jones" wrote: > > Some of the things it does which are IMHO better: > > - starts disk formatting / copying / installing in parallel >with asking user questions I think that is a misfeature. I don't want anything irreversible to be done until I say go. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams wrote: > > > > I think that is a misfeature. I don't want anything irreversible to be done > > until I say go. > > You know that Fedora has done partitioning/mkfs about halfway through > the install for a while now, right? I don't see why there would be a > problem with letting that run in the background while continuing through > the questions. I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. I tend to do install all of the games, so my installs may take longer than average. I also always do custom disk layouts, so I might see things a bit different from people that don't do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: THREE Days Remain to Fix Fedora 14 Blocker Bugs
On Wed, Oct 13, 2010 at 09:57:48 -0700, John Poelstra wrote: > > 641476 :: ASSIGNED :: kernel :: a...@redhat.com :: devicemapper UUID > field cannot be assigned after map creation :: > https://bugzilla.redhat.com/show_bug.cgi?id=641476 >* next steps ... > 1) Waiting for new build from maintainer 2.6.35.6-42.fc14 has the follopwing in its changelog: Changelog * Tue Oct 12 2010 Kyle McMartin 2.6.35.6-42 - Fix devicemapper UUID field cannot be assigned after map creation (rhbz#641476) thanks pjo...@. I haven't tested for that particular issue, but am running that kernel on three machines right now and am not seeing any regressions versus other 2.6.35 kernels. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
