Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, Sep 22, 2010 at 17:27:43 +0200, drago01 drag...@gmail.com wrote: On Wed, Sep 22, 2010 at 5:04 PM, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 22, 2010 at 17:01:02 +0200, Tomas Mraz tm...@redhat.com 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 tm...@redhat.com 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 drag...@gmail.com 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 ke...@scrye.com 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 ke...@scrye.com wrote: On Tue, 21 Sep 2010 17:09:32 -0500 Bruno Wolff III br...@wolff.to wrote: On Tue, Sep 21, 2010 at 15:47:04 -0600, Kevin Fenzi ke...@scrye.com 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 ke...@scrye.com 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 drag...@gmail.com 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 ke...@scrye.com 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 fed...@michelsylvain.info 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 m...@cchtml.com 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 benny+use...@amorsen.dk 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: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Tue, Sep 21, 2010 at 15:47:04 -0600, Kevin Fenzi ke...@scrye.com 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: PostgreSQL 9 for F14?
On Mon, Sep 20, 2010 at 16:00:46 -0400, Arthur Pemberton pem...@gmail.com wrote: On Mon, Sep 20, 2010 at 3:56 PM, Tom Lane t...@redhat.com wrote: Michel Alexandre Salim fed...@michelsylvain.info 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 jrei...@bitwagon.com 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 mkkp...@gmail.com 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: FYI: rawhide now requires systemd to boot by default
On Fri, Sep 17, 2010 at 23:56:54 +0200, Michał Piotrowski mkkp...@gmail.com 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: nightly compose not bootable?
On Fri, Sep 17, 2010 at 11:17:19 -0700, Carl Byington c...@five-ten-sg.com 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 br...@wolff.to wrote: On Fri, Sep 17, 2010 at 11:17:19 -0700, Carl Byington c...@five-ten-sg.com 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
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 opensou...@till.name 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 mschm...@redhat.com 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: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, Sep 15, 2010 at 11:27:07 +0100, M A Young m.a.yo...@durham.ac.uk 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 musur...@gmail.com wrote: On Wed, Sep 15, 2010 at 9:53 AM, Thomas Janssen thom...@fedoraproject.org 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 linvi...@redhat.com 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 poels...@redhat.com 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 drag...@gmail.com 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 drag...@gmail.com 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
Re: ogre3d lagging behind more than half a year
On Tue, Sep 14, 2010 at 11:43:03 +0200, Rudolf Kastl che...@gmail.com 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 (ニール・ゴンパ) ngomp...@gmail.com 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 du...@fedoraproject.org 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: rawhide report: 20100912 changes
On Sun, Sep 12, 2010 at 20:06:41 +0530, Rahul Sundaram methe...@gmail.com wrote: livecd-tools-034-1.fc15 --- * Sat Sep 11 2010 Bruno Wolff III br...@wolff.to - 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: F14 youtube support?
On Thu, Sep 02, 2010 at 17:26:28 +0200, Michał Piotrowski mkkp...@gmail.com wrote: 2010/9/2 Daniel J Walsh dwa...@redhat.com: 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: Putting cross compilers into Fedora
On Wed, Sep 01, 2010 at 11:41:34 +0100, David Howells dhowe...@redhat.com 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: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 00:45:49 -0400, Arthur Pemberton pem...@gmail.com 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 jspal...@gmail.com 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 al.dunsm...@sympatico.ca 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 m...@mattmccutchen.net 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: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 21:56:17 +0200, Sven Lankes s...@lank.es 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 Sun, Aug 29, 2010 at 05:46:31 +, \Jóhann B. Guðmundsson\ johan...@gmail.com 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 Sat, Aug 28, 2010 at 17:16:12 +, \Jóhann B. Guðmundsson\ johan...@gmail.com 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\ johan...@gmail.com 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 jkeat...@j2solutions.net 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 c...@laptop.org 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: systemd v8 for rawhide?
On Fri, Aug 27, 2010 at 09:10:35 -0700, Jesse Keating jkeat...@redhat.com 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: systemd and changes
On Mon, Aug 23, 2010 at 23:05:11 +0200, Lennart Poettering mzerq...@0pointer.de 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 drag...@gmail.com 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
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 jkeat...@j2solutions.net 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: Javascript JIT in web browsers
On Mon, Aug 16, 2010 at 15:48:14 -0700, Adam Williamson awill...@redhat.com 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 jrowens.fed...@ghiapet.net 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
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 dti...@iinet.net.au 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 m...@mattmccutchen.net 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: Mailing list guidelines and smartphones
On Sun, Aug 15, 2010 at 00:32:46 +0200, Sven Lankes s...@lank.es 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: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Fri, Aug 13, 2010 at 16:54:22 +0200, Kevin Kofler kevin.kof...@chello.at 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 jkeat...@redhat.com 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 nathan...@gnat.ca 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 m...@cchtml.com 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 kevin.kof...@chello.at 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 kevin.kof...@chello.at 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: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
On Thu, Aug 12, 2010 at 13:27:05 +0200, Jaroslav Reznik jrez...@redhat.com 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 nathan...@natemccallum.com 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 mmcgr...@redhat.com 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 awill...@redhat.com 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 mrma...@earthlink.net 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 kevin.kof...@chello.at 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: Asterisk 1.8 in Rawhide (F-15)
On Sat, Aug 07, 2010 at 18:04:29 +0200, Felix Kaechele fe...@fetzig.org 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: Fedora 14 branching and dist-git roll out
On Sat, Jul 31, 2010 at 12:45:13 +0200, Ralf Ertzinger fed...@camperquake.de wrote: Hi. On Fri, 30 Jul 2010 21:48:22 -0500, Bruno Wolff III wrote I got some info from McGrath and added it to the wiki. I don't think it's a good idea to save informations that are used to authenticate a connection in a wiki. The fingerprint is there, where to look for the public key info or how to use a dns check is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedoraproject.org certificate has expired
On Sat, Jul 31, 2010 at 11:08:02 -0400, Tom Lane t...@redhat.com wrote: Just in case you thought we weren't having enough infrastructure fun already ... My web browser is complaining that admin.fedoraproject.org is presenting an invalid SSL certificate: it expired July 31, 2010 8:17:52 AM ET, ie about three hours ago. McGrath posted an outage notice on the announce list about this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing Fedora? Please enable SELinux if you can
On Fri, Jul 30, 2010 at 09:51:05 -0400, Daniel J Walsh dwa...@redhat.com wrote: I decided to respond to these emails about Google Applications in a blog entry The link to Drepper's stuff should be: http://people.redhat.com/drepper/selinux-mem.html Your link has a ~ and a trailing space. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: State of the Fedora 14 Alpha Blockers + Meeting summary
On Fri, Jul 30, 2010 at 14:25:46 -0700, John Poelstra poels...@redhat.com wrote: 617115 :: ON_QA :: livecd-tools :: David Huff :: rawhide live spins showing black screen instead of syslinux boot menu :: https://bugzilla.redhat.com/show_bug.cgi?id=617115 Just in case David sees this, this should have been assigned to me as I agreed to do the version bump to get the fix back in rawhide/F14. I changed the assignee to myself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
I was unable to find a fingerprint for pkgs.fedoraproject.org. Since the risk is low, I'll start doing work and check it retroactively. I think there should be some comment in the documentation about what the project expects maintainers to do with regard to using it to avoid man in the middle attacks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Fri, Jul 30, 2010 at 21:07:08 -0500, Bruno Wolff III br...@wolff.to wrote: I was unable to find a fingerprint for pkgs.fedoraproject.org. Since the risk is low, I'll start doing work and check it retroactively. I think there should be some comment in the documentation about what the project expects maintainers to do with regard to using it to avoid man in the middle attacks. I got some info from McGrath and added it to the wiki. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
I noticed that the f14 repo from the kernel mirror seems to have only things that are tagged dist-f14 and no inherited stuff. (Note that while there is kitutuki-0.9.9c-1.fc13.i686.rpm, it's tagged both dist-f13 and dist-f14.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Fri, Jul 30, 2010 at 22:24:59 -0500, Bruno Wolff III br...@wolff.to wrote: I noticed that the f14 repo from the kernel mirror seems to have only things that are tagged dist-f14 and no inherited stuff. (Note that while there is kitutuki-0.9.9c-1.fc13.i686.rpm, it's tagged both dist-f13 and dist-f14.) Probably related to this I got some broken package dependency warnings emailed to me that seem to be for things that weren't rebuilt for F14. Is it safe to ignore this batch of warnings? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Fri, Jul 30, 2010 at 22:39:08 -0500, Bruno Wolff III br...@wolff.to wrote: Probably related to this I got some broken package dependency warnings emailed to me that seem to be for things that weren't rebuilt for F14. Is it safe to ignore this batch of warnings? I see this got answered in another thread. I'll see how things look tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Blocker Meeting #3 Friday @ 16:00 UTC
On Wed, Jul 28, 2010 at 19:33:46 -0700, John Poelstra poels...@redhat.com wrote: 615443 :: NEW :: livecd-tools :: David Huff :: booting live images from nightly fails (can't mount root filesystem) :: https://bugzilla.redhat.com/show_bug.cgi?id=615443 --This bug was reported on July 16, 2010, coming up on two weeks ago. Still no comments from the maintainer. I am a co-maintainer and have made some comments. I don't have an easy way to try doing builds on x86_64 to try to see if this really is an arch related issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Blocker Meeting #3 Friday @ 16:00 UTC
On Wed, Jul 28, 2010 at 23:08:13 -0600, Kevin Fenzi ke...@scrye.com wrote: On Wed, 28 Jul 2010 19:33:46 -0700 John Poelstra poels...@redhat.com wrote: 615443 :: NEW :: livecd-tools :: David Huff :: booting live images from nightly fails (can't mount root filesystem) :: https://bugzilla.redhat.com/show_bug.cgi?id=615443 --This bug was reported on July 16, 2010, coming up on two weeks ago. Still no comments from the maintainer. We have made some progress here. It's looking like a squashfs issue. Hopefully we will know more tomorrow. On the kernel side or the squashfs-tools side? If on the tools side, I updated squashfs-tools just before the git conversion and branch. That update is mostly better error handling for the xattr changes. But maybe it will help with the problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
'man' in comps?
It looks like man is being replaced by man-db in F14 (though the last I checked the package hadn't been dropped yet, just obsoleted). However comps still lists man in the base group. Should this be changed to man-db? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New QGIS owner
On Fri, Jul 09, 2010 at 21:19:05 +0200, Volker Fröhlich volke...@gmx.at wrote: Dear Fedora members! I'm happy to announce myself as the new owner of the QGIS package. Thanks. I wanted to play with that a bit to see if I could use it for RPG maps, but the package does a lot more. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)
On Wed, Jul 07, 2010 at 01:56:41 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Richard W.M. Jones wrote: I think this is another problem with pkgdb or Fedora. Why is there a maintainer (owner?) and co-maintainers, rather than just having all co-maintainers be equal? Good point. I think, just like you, that there should be a list of owners rather than just 1 owner. I think anyone who can update ACLs should be effectively considered an owner. If #maintainers == 0 then the package is either just sitting there (as long as there are no serious bugs), or is being best-effort maintained by provenpackagers, at least until that becomes a burden and only then should the package be dropped. This is really a separate issue, but FWIW, I agree with you on this point as well. It's also possible now to have a package with no owner, but co-maintainers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I claimed qgis
I was looking at qgis for doing roleplaying maps (I am not sure if that will work out) and noticed it was way behind upstream and then when filing a bug, noticed that it was orphaned. I am going to try to get it updated to 1.4 and see how things go. If it works out for roleplaying, I'll be a long term maintainer, if not I might orphan it again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I claimed qgis
On Sun, Jul 04, 2010 at 01:40:52 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Sorry, but qgis has been orphaned and not updated for more than 3 months, so it needs a rereview as per: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure I wasn't sure what the state was. I saw that you had done an update in February and thought maybe it was recently released. There is also a co-maintainer still listed. which is already in progress here: https://bugzilla.redhat.com/show_bug.cgi?id=605373 where the specfile is also updated to 1.4. Thanks. You guys were further along than I was, though I have some suggestions that I have added to the review. Thanks for adding me to it. The package is supposed to be owned by Volker Fröhlich, who is being sponsored as part of the rereview. So please release ownership again, and you can apply for comaintainership once the required rereview is through. I released ownership, but hung on to the watch stuff. The bug where ownership switched on release seems to have been fixed. I'll apply for commit later. I'd rather be a co-maintainer in any case, as my use case for the package is fairly limited, and there are a lot of things it does that I probably won't be playing with. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I claimed qgis
On Sun, Jul 04, 2010 at 02:21:22 +0200, Kevin Kofler kevin.kof...@chello.at wrote: The added complication is that the criterion is when the package was last touched before being orphaned (and some people say it should be when it was last touched by the maintainer, which is even longer ago in qgis's case), not when the ownership was released. Well there seem to be exceptions to that. Packages often go 3 months without updates, yet (at least informally) people orphan packages briefly to hand them over to other people without this being checked. Presumably there is an exception for orderly handovers where packages are only in orphan status for a short amount of time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
On Wed, Jun 30, 2010 at 12:10:11 -0500, Rex Dieter rdie...@math.unl.edu wrote: Another wrinkle here is both libjpeg and libjpeg-turbo existing in rawhide/repo. Shouldn't libjpeg get removed now? Doing so should help matters too. If someone looks at that, they might also want to look at dropping 'man' which is in a similar situation (obsoleted, but still hanging around). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-haskell-list] headsup: ghc-6.12.3
On Sun, Jun 27, 2010 at 20:43:26 -0400, Jens Petersen peter...@redhat.com wrote: Just to update I finished rebuilding all the ghc packages in dist-f14-ghc over the weekend and they should appear in the next rawhide push. Probably kaya and hedgewars should be rebuilt too. I'll bump hedgewars once the update shows up. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-haskell-list] headsup: ghc-6.12.3
On Mon, Jun 28, 2010 at 08:35:39 -0500, Bruno Wolff III br...@wolff.to wrote: On Sun, Jun 27, 2010 at 20:43:26 -0400, Jens Petersen peter...@redhat.com wrote: Just to update I finished rebuilding all the ghc packages in dist-f14-ghc over the weekend and they should appear in the next rawhide push. Probably kaya and hedgewars should be rebuilt too. I'll bump hedgewars once the update shows up. I am not seeing a conflict with hedgewars after the update. So for now at least, I don't think hedgewars needs to be rebuilt. None of the ghc related requires (ghc-dataenc, ghc-network, ghc-stm, ghc-utf8-string) were version specific. Does that indicate that the requires were set up improperly or just that these packages didn't have an abi change? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-haskell-list] headsup: ghc-6.12.3
On Mon, Jun 28, 2010 at 20:25:19 -0400, Jens Petersen peter...@redhat.com wrote: - Bruno Wolff III br...@wolff.to wrote: I just suggested the rebuilds as best practice. :) I'll probably be doing one in F14 to get the latest upstream release, once I get a bit of a lull. So there should be one before release. None of the ghc related requires (ghc-dataenc, ghc-network, ghc-stm, ghc-utf8-string) were version specific. Does that indicate that the requires were set up improperly or just that these packages didn't have an abi change? You should not need those Requires since they are for shared libs. Rpm would generate them for you automatically: so they should be redundant. You could pass -dynamic to ghc if you want to link to the shared libraries. I am pretty sure I had a build fail in F14 when I didn't list ghc-utf8-string on a build requires. It didn't happen in F13 though. I'll drop the reuires though if they get built automatically. And I'll try out using -dynamic. Thanks for the advice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Early warning of Ogre, MyGUI and CEGUI updates in rawhide
I am finally starting work on getting Ogre 1.7 into rawhide. I will also bump the related packages MyGUI and CEGUI to the latest version as well. I'll be working on these locally so as not to make people rebuild dependencies multiple times. Barring unexpected problems I should have this ready before alpha (including dependent games that I can update). I'll send out another warning shortly before pushing stuff to rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora, DNSSEC and GOST (ECC like) algorithms with openssl
On Mon, Jun 21, 2010 at 11:07:05 -0400, Paul Wouters p...@xelerance.com wrote: Some references showing there should not be any known IPR issues filed with the IETF that would prevent implementing RFC standards using ECC: DJB has made some public comments on why he doesn't think any patents apply to ECC work he has published at: http://cr.yp.to/ecdh/patents.html He isn't a lawyer, but his comments may still be useful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Sat, Jun 19, 2010 at 17:07:02 -0400, Digimer li...@alteeve.com wrote: Perhaps they are, and I will look into them. However, my curiosity has been piqued, so I'd still like to know how it's supposed to be done. It seems to me like it should be a somewhat straight forward task, so I am curious about where my understanding has failed. I think pungi is used for official releases, but that Fedora Unity uses revisor for their respins. Either should be usable with mock to get reproduceable builds. For one offs on the same arch as the builder, you don't really need mock. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with createrepo for modified DVD ISO
On Fri, Jun 18, 2010 at 09:15:09 -0400, Digimer li...@alteeve.com wrote: Hi all, I asked this on buildsys, so this is something of a repost. I'm not sure where to turn at this point, so if this isn't the right list, would anyone be able to point me in the right direction? Probably the question belongs on users. I've been trying to create my own (minorly) custom distro for Fedora 13. All it really is is a custom kickstart and a changed up set of RPMs. I think revisor is the tool that is best for making custom install DVDs. I usually make live images using livecd-creator and can't give you specific information on using revisor. My problem is; I've added some RPMs and removed others, so I need to regenerate the files in dvd:/repodata to properly reflect what is in dvd:/Packages. I've tried various incantations of 'createrepo Packages/' but none seem to work. When I move the generated files into dvd:/repodata, roll the ISO, burn and install, the installer complains that the repo data is bad (sorry, I don't have the exact error at the moment). The path to the packages might not be correct. If relative paths are used and the repodata directory is not related to the location of the rpms the same way, then you could see something like that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 02, 2010 at 08:19:24 +0100, Peter Robinson pbrobin...@gmail.com wrote: On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram methe...@gmail.com wrote: On 06/02/2010 12:09 PM, Peter Robinson wrote: It does work in F-12, the response for the lack of support in F-13 was 'deal with it'. There is suppose to be a patch to emulate it in the kernel but apparently it won't go upstream until its a generic infra patch that can allow support of other emulated bits in other cpus in a generic way. So its possible it will come back, but I don't hold up hope of a quick resolution. Which leaves us in a big predicament as to how we're going to support the 1.5 million odd XO-1s out there moving forward. Can you file a ticket with FESCo? Would be useful to track and resolve this issue. I will do. I'll gather up all the bits I have an add it to the ticket. Thanks. This issue points out a gap in our QA testing. Fixing it now could end up being painful (if we need to rebuild lots of packages). Catching it earlier would have made that (lots of rebuilds) a lot more palatible. Also the process for changing which instructions gets used in generated code should be looked at. The gcc people should not just be deciding this in a vacuum. Even changing some instructions to emulation could potentially have big performance impacts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Mon, May 31, 2010 at 16:55:26 -0400, Paul Wouters p...@xelerance.com wrote: Fixing init scripts and %post is now left in the state maintainer is too busy to fix. In the past I already offered co-maintainership or taking over the package due to my close relationship with upstream. It's a lame excuse for leaving it in the current state, since that's the preference of the maintainer, which violates fedora packagaging policies. Does FESCO know you'd be willing to become the maintainer? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue, Jun 01, 2010 at 11:48:02 -0400, Paul Wouters p...@xelerance.com wrote: On Tue, 1 Jun 2010, Bruno Wolff III wrote: Fixing init scripts and %post is now left in the state maintainer is too busy to fix. In the past I already offered co-maintainership or taking over the package due to my close relationship with upstream. It's a lame excuse for leaving it in the current state, since that's the preference of the maintainer, which violates fedora packagaging policies. Does FESCO know you'd be willing to become the maintainer? I've definately talked to quite a few of them (online and in person) over the years this has been going on. I even had a tor package made and submitted it, but Enrico and my package crossed paths and his was a day earlier, so his personal version instead of a fedora version got accepted: The reason I asked is that they might be more willing to yank the package from the current maintainer if there is someone willing to step in and fix things rather than having to orphan it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Tue, Jun 01, 2010 at 16:43:07 -0400, James Laska jla...@redhat.com wrote: Greetings package maintainers, Want to get notification of any breakage in your just-built koji packages? This includes results of rpmlint [1], rpmguard [2] and, if applicable, initscript [3] tests. Good news, you can now opt-in to receive test results by mail! All you have to do is: 1. Login to fedorapeople.org # ssh fedorapeople.org 2. Run the command: autoqa-optin package [release] That's it! Thanks to Seth Vidal for the autoqa-optin script and proposed changes to enable this feature. Who gets the email? What if I am a co-maintainer, do I get the email or does it go to the package owner? Can I opt in for all packages I am the owner or all packagers I co-maintain with one command? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Tue, Jun 01, 2010 at 22:43:25 +0200, Gland Vador glandva...@yahoo.com wrote: On 05.04.2010 14:48, Dan Horák wrote: I was trying to install i686 variant of F-13 to an Alix board (2D13 with Geode LX) and got into troubles. The kernel boots fine, but when it should start initramfs the kernel panics. Everything works well when using complete F-12 environment and when using F-12 kernel+initramfs with F-13 rootfs the initramfs stuff runs well, but when I try to manually chroot into the F-13 from the dracut shell I get an Invalid instruction exception. I though last change in x86 CPU support was in F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it explicitly talks about Geode LX as still supported. So the question is whether F-13 should still work on Geode LX? Sorry to reopen this old topic, but the conclusion is not obvious. The F13 is out and it seems to have lost support for the Geode LX CPU (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the NOPL instruction by GCC. Will this CPU be supported during F13 and above or should I search for a new distribution ? I don't believe there was any intentional change in supported CPUs for F13. If it was supposed to work in F12, I think it is supposed to work in F13. Did you file a bug against gcc? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Sun, May 30, 2010 at 00:39:14 -0400, Matthew Miller mat...@mattdm.org wrote: So, clearly, there's some disagreement about what's fixed and what's broken. But printing out a passive-agressive warning to end-users is not the solution. The error message is confusing and very, very unhelpful. Worse, it's not _meant_ to be helpful to the poor end user -- it's meant to try to goad the other packager into action. Such things need to be taken up with FESCO, not fought about in user-visible debug output. See: https://fedorahosted.org/fesco/ticket/347 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 23:39:49 +0200, Kevin Kofler kevin.kof...@chello.at wrote: seth vidal wrote: It appears this subject has been picked up on lwn - so I'm certain there will be a fruitful, productive and constructive discussion there. Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and What's interesting is that Fedora's development / user list discussions get so much press on LWN. their comments are infested by trolls like no other place! You must not read slashdot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Release Candidate Phase
On Fri, May 14, 2010 at 08:58:04 -0700, Jesse Keating jkeat...@redhat.com wrote: On Fri, 2010-05-14 at 06:52 -0700, John Poelstra wrote: I'm up for the challenge previously having been told it wasn't possible for release criteria and blocker bugs ;-) And we're still making judgment calls there, because it is very very difficult to codify. I think it would help to make notes about why exceptions were granted and collect them. That may help with writing policy and modifying it later where needed. As well as possibly helping speed decisions when similar cases come up again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Release Candidate Phase
On Thu, May 13, 2010 at 09:06:39 -0500, Jon Ciesla l...@jcomserv.net wrote: I can prep for the test tonight, but it's a pain to do the final test remotely. So that will wait until tomorrow. Email me as soon as you want this done, and I'll do it ASAP. Two people have confirmed that a combination of installing the scratch build and rebuilding and then installing wesnoth solves the x86_64 connect to server issue. To do this quickly, it will require chainbuilding both packages so that both can get tested at the same time. Otherwise the boost update needs to go through testing and get to stable before a wesnoth rebuild would do any good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
