Re: http://www.fsf.org/news/dont-depend-on-mono
drago01, Mon, 29 Jun 2009 17:00:56 +0200: Another don't use $LANGUAGE because its evil post from RMS. ($LANGUAGE has been Java, Javascript and now C#). I am not big fan of RMS, but we have to admit that at least in case of Java, he was just right, and among other things, because of strong stand on the principle by the FLOSS community, Java is now free (ask some RH folks about making OOo working without Sun JRE). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
Kevin Kofler, Mon, 29 Jun 2009 17:08:11 +0200: I'm not familiar with the JavaScript story, but if he really recommended against using it, there was certainly a valid reason. His point was that thousands of line of hardly obfuscated Javascript (think Google Docs) is hard to recognize from binary-only distribution, which I can see as pretty good argument. And yes I know that this obfuscation is not for malicious reasons (it's compression as well), but still, it would be lovely if source for Google Docs was available somewhere. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Peter Lemenkov, Tue, 30 Jun 2009 00:25:10 +0400: Please, take a look at smolts statistics, for example. Don't fool yourself with wrong statement that many users (not redhat employees) using Rawhide. Actually in this case Red Hat employees are as good as any other user. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Ralf Corsepius, Mon, 29 Jun 2009 23:22:47 +0200: Yes, my Fedora 11 _desktop_ experience so far has been very negative, to say the least. And yes it says just a little about state of F11 desktop. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Installing Fedora with software based synthesizer for sceenreader
Is is possible to *install* Fedora using our accessibility support out of the box, specifically do we have support for installing fedora and have a software based synthesizer available for the screen reader during installation ? I see that there was a previous fedora-derived effort but only as far as F-9, and A hardware speech synthesizer is required to install though after install supports operation using software speech synthesizers, i.e. http://speakupmodified.org/HOWTO_INSTALL.html C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Le Lun 29 juin 2009 22:05, Peter Lemenkov a écrit : Please, keep in mind, that almost nodoby using Rawhide Which is why rawhide quality needs to improve because rawhide is the next Fedora version and if it's not usable now F12 will start will mass updates and destabilization as usual. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jun 30, 2009 at 8:55 AM, Matej Ceplmc...@redhat.com wrote: Kevin Kofler, Mon, 29 Jun 2009 17:08:11 +0200: I'm not familiar with the JavaScript story, but if he really recommended against using it, there was certainly a valid reason. His point was that thousands of line of hardly obfuscated Javascript (think Google Docs) is hard to recognize from binary-only distribution, which I can see as pretty good argument. And yes I know that this obfuscation is not for malicious reasons (it's compression as well), but still, it would be lovely if source for Google Docs was available somewhere. Well as the code has a non free license anyway its better that it is obfuscated. So a developer cannot read and get infected by it. Write his own code and copy parts of the code which he is not allowed to copy. Sure getting Google to release it under a free license would be a good thing, but I doubt that will do it anytime soon :(. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
2009/6/30 Kevin Kofler kevin.kof...@chello.at: Seth Vidal wrote: On Mon, 29 Jun 2009, R P Herrold wrote: umm -- trying to boot and install the x86_86 image on a i686 unit returns basically the same under Anaconda's kernel which is why i686 isos are the ones users get by default. ... which is bad. Users should get the x86_64 version by default if they don't know what they have, it's the one which should be tried first, if it doesn't work, they can always get the legacy version. Sorry, but i have to disagree with that. Because *that* would be really bad. Give the user at least the arch that works no matter how old his box is (ok, if it's too old he is screwed anyways). Get him download 700MB again for the LiveCD and he will walk away. Back to windows with a bad experience (linux not working at all) or to another distro. And i speak of the default for users who cant/want find out what arch they need (x86). *Some* people dont want to read too much and want just download something to try it. For all the other users we would have choices as shown in the other thread with some very basic ASCII mockup. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
On Tue, Jun 30, 2009 at 9:39 AM, Nicolas Mailhotnicolas.mail...@laposte.net wrote: Le Lun 29 juin 2009 22:05, Peter Lemenkov a écrit : Please, keep in mind, that almost nodoby using Rawhide Which is why rawhide quality needs to improve because rawhide is the next Fedora version and if it's not usable now F12 will start will mass updates and destabilization as usual. -- Nicolas Mailhot Isn't this that what the topic is all about (not specifically improving the quality of Rawhide but having a better general release after the Rawhide period)? ;-) Ps. Did I mention that I'm a Rawhide user myself? Pps. The whole topic sounds like a good idea to me. -- Eelko Berkenpies http://blog.berkenpies.nl/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning par2cmdline
I have just orphaned par2cmdline¹. I am not using that package for more than one year, now, and I was doing the minimal maintenance (taking care of mass- rebuilds and so on). Erik van Pienbroek (erik-fed...@vanpienbroek.nl) is already willing to maintain it, as he is currently maintaining NTTPgrab, that needs par2cmdline. See the discussion in the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=508772#c1 ¹) https://admin.fedoraproject.org/pkgdb/packages/name/par2cmdline -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning par2cmdline
On Tuesday 30 June 2009 01:47:37 am Laurent Rineau wrote: I have just orphaned par2cmdline¹. I am not using that package for more than one year, now, and I was doing the minimal maintenance (taking care of mass- rebuilds and so on). Erik van Pienbroek (erik-fed...@vanpienbroek.nl) is already willing to maintain it, as he is currently maintaining NTTPgrab, that needs par2cmdline. See the discussion in the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=508772#c1 ¹) https://admin.fedoraproject.org/pkgdb/packages/name/par2cmdline -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau Erik, I'd like to join you as a co-maintainer if it is ok with you. A package I maintain also requires par2cmdline (hellanzb). Regards, -- Conrad Meyer ceme...@u.washington.edu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, 2009-06-29 at 17:21 -0500, King InuYasha wrote: I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12. Would it be possible to implement this or something similar for Fedora? The ksplice tools have been included in Fedora since around f8. This gives you the bits you need to create and apply ksplice updates to a running system. The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the Uptrack service). Regards, Bryn. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, 2009-06-29 at 23:22 -0500, King InuYasha wrote: Also, while KSplice is currently being used for kernel updates, it isn't limited to those. It could be adapted to work for other updates that normally force a reboot. Though, I can't think of any off the top of my head, it has been over a week since I ran the updater... -- Please: no. If parts of userspace cannot re-initialise themselves without a reboot then they should just be fixed. Even init has been able to do this for years now - resorting to exotic live-patching methods for updating userspace is just a workaround for badly written software. Bryn. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, 2009-06-29 at 19:38 -0500, King InuYasha wrote: Then Linux shouldn't be compiled using kmods and instead as a monolithic binary, since kernel modules fall under the patent. Besides, there are tons of prior art on it. KSplice is a good technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice is there as a package, but what about the GNOME frontend? The screenshot for The frontend is Ksplice Inc's Uptrack service, not ksplice. The installable bits of Uptrack seem to be GPLv2 (only the artwork has an exception which is fair enough). I couldn't find any of the backend bits available for download though and as others have pointed out in this thread there's still the problem of making ksplice fit in with Fedora's approach to kernel updates (to be honest, I think it'd be a lot easier to run a service like this for RHEL or CentOS particularly if you're only interested in selected security errata). Regards, Bryn. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Matthias Clasen wrote: we'd like to announce the 'Fit and Finish' initiative for Fedora, http://fedoraproject.org/wiki/Fit_and_Finish with the goal to improve the user experience of the Fedora desktop. We want to identify the small (and sometimes large) roadblocks that make everyday computer use harder than it needs to be, and try to fix them. In Ubuntu there's a Help button on the top menu bar that leads to a nice help application, yelp. We have that app too, but it doesn't seem to have the same contents, which are: New to Ubuntu? Adding and Removing Software Files, Folders and Documents Customising Your Desktop Internet Music, Videos and Photos Assistive Tools Keeping Your Computer Safe Printing, Faxing and Scanning Advanced Topics And under each section there's a clear explanation of what to do. Maybe we have something equivalent for Fedora, but I can't find it. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: New parted version
On Tue, Jun 30, 2009 at 11:47:23AM +0200, Joel Granados wrote: Heads up. New parted version comming to fedora devel. This will bring in a bunch of bugfixes. It does not change the API. Upstream has not released 1.9.0 yet, but what is on master will probably end up in the release (with minor changes). I decided to put it in now sowe can iron out any issues with the packages that depend on parted. The release will still have the 1.8.8 version but I will add the date of the snap-shot to the release number. If you have any issues with the new parted scream at me on #parted or #anaconda :). When the 1.9.0 is officially released I'll change the version of the package. Upstream does not handle alpha, beta nor RC kind releases, so the snapshot is the best bet. * The scratch builds are on http://koji.fedoraproject.org/koji/taskinfo?taskID=1443622 ^ This one failed for some reason. Investigating... http://koji.fedoraproject.org/koji/taskinfo?taskID=1429025 * I'll probably do the build tonight or tomorrow morning. Regards. -- Joel Andres Granados Brno, Czech Republic, Red Hat. -- Joel Andres Granados Brno, Czech Republic, Red Hat. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Monday 29 June 2009 16:19:13 Cliff Nadler wrote: I think a Help me choose choice that takes you to a page with descriptions of each spin's environment would be more friendly (and probably more accurate as to why someone would want to use that choice. [cut] I agree, Help me choose + description + a couple of screenshots would be nice, and I think that it's much better than labeling one version as default. Maybe it's also useful to teach people that there are multiple environments to choose from (instead of assuming that they won't care about that)? L.V. signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: New parted version
On Tue, Jun 30, 2009 at 11:48:39AM +0200, Joel Granados wrote: On Tue, Jun 30, 2009 at 11:47:23AM +0200, Joel Granados wrote: Heads up. New parted version comming to fedora devel. This will bring in a bunch of bugfixes. It does not change the API. Upstream has not released 1.9.0 yet, but what is on master will probably end up in the release (with minor changes). I decided to put it in now sowe can iron out any issues with the packages that depend on parted. The release will still have the 1.8.8 version but I will add the date of the snap-shot to the release number. If you have any issues with the new parted scream at me on #parted or #anaconda :). When the 1.9.0 is officially released I'll change the version of the package. Upstream does not handle alpha, beta nor RC kind releases, so the snapshot is the best bet. * The scratch builds are on http://koji.fedoraproject.org/koji/taskinfo?taskID=1443622 ^ This one failed for some reason. Investigating... This one should be fine. It was caused by e2fsprogs changing :) http://koji.fedoraproject.org/koji/taskinfo?taskID=1443661 -- Joel Andres Granados Brno, Czech Republic, Red Hat. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
In my opinion, maybe Mono is a good thing for attracting more developers to come into Linux world. Also Programmers write a lot of great softwares, such as tomboy, f-spot and giver. But we can not ignore that there are some legal issues in Mono. If Microsoft accuses some users of stealing his copyright, or Microsoft bans developers to write C#, it will cause a large disaster for OpenSource community. As far as I am concerned, I suggest that Mono is not the default installation on Fedora. But Mono should staying at Fedora repository. I am using f-spot to export my photos to picasa web album. It is much better than Google Picasa for Linux. I know that gnote will replace tomboy. I hope solang will replace f-spot for the reason that sometimes after I upload photos to picasa web album f-spot would crash. Also moving Mono to RPM Fusion may be a better choice. It is more efficient to avoid legal issues with Microsoft. But lacking of maintainers, RPM Fusion is unlikely to maintain Mono platform and some applications requiring Mono well. So I suggest that Mono should stay at Fedora repository but not be the default installations. -- urlhttp://liangsuilong.co.cc/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FAO: Programmers Quick Q?
On 30/06/09 03:41, Kevin Kofler wrote: Another big issue is what -devel packages to ship. A KDE application developer will have little to no use for GNOME -devel packages and vice-versa. The old Developer spin had only the GNOME -devel stuff on it (it didn't even ship KDE at all), #1 A Poll http://fedoraproject.org/wiki/SIGs/Development#Fedora.2C_Developer_Edition_details which made it completely uninteresting to me. And there are tons of libraries programmers may want to use, we can't ship them all, along with their respective -devel packages, on one spin. Kevin Kofler I know everything cannot go on it, but I want some form of basic consensus. As to what can make a good intro to Fedora as a programmers platform. What I would like to see is none of: DE sucks. Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Removing obsolete buildings from Bodi
Hi, how do I remove obsolete buildings from Body? I tried delete, but I always get: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On 06/30/2009 07:26 PM, Matthew Garrett wrote: ACPI docking stations are mildly complicated creatures that require the OS to handle part of the undocking process. We're currently doing this entirely within the kernel, but this has the significant downside that there's no way to handle cleanly unmounting any block devices that are contained within the dock - they'll simply vanish. I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop. Where exactly in the desktop and can that be a library? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, 29 Jun 2009 19:38:58 -0500, you wrote: technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice The fedora-ksplice script are doing the following: 1.) Getting the sources of the current running fedora kernel 2.) Prepare the kernel source tree for running ksplice. 3.) Create the kernel patch module on based of a patch and the prepared kernel sources. The main aim is a more convinience way to use ksplice on fedora. Best Regards: Jochen Schmitt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 9:14 AM, Arjan van de Venar...@infradead.org wrote: how common are docking stations in practice? (as opposed to port extenders) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Roughly half of the people where I work have docking stations for their laptops, they aren't all linux/Fedora users but docking stations are still somewhat commonplace around here. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Tuesday 30 June 2009, drago01 wrote: On Mon, Jun 29, 2009 at 10:46 PM, Richard Junerj...@bravegnuworld.com wrote: Does archetecture get exported anywhere by javascript? If so, it would provide a simple way to query the users' hardware. No. Sure it does get exported, kind of, but at least some parsing is required and there are cross browser issues; see navigator.platform, navigator.oscpu and/or navigator.userAgent. Anyway, as others have already noted, the usefulness of that info for the above purpose is very much questionable. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, 2009-06-30 at 14:56 +0100, Matthew Garrett wrote: Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled? Can't the desktop inform the kernel if it can handle the interaction? If not, you can just fallback to the current behavior. -- Dimi Paun d...@lattica.com Lattica, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
Ville Skyttä wrote: Sure it does get exported, kind of, but at least some parsing is required and there are cross browser issues; see navigator.platform, navigator.oscpu and/or navigator.userAgent. Anyway, as others have already noted, the usefulness of that info for the above purpose is very much questionable. And many people who aren't using GNU/Linux yet will be running 32-bit Window$ on their 64-bit CPU, so it'll report 32-bit. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
Bryn M. Reeves wrote: The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the Uptrack service). And as I explained, this can't be done for the released Fedora kernels (because they get big changes which ksplice cannot handle), unless you start from the GA kernel and only backport security fixes, which makes the kernel you provide become completely different from the current Fedora kernel over time. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
Adam Miller wrote: That's actually a little different, Kubutu and Xubuntu are considered completely separate distributions from within the Ubuntu community. That wasn't really my point (it was about their use of just one letter for each desktop environment), but... They all have disjoint development teams (though *some* do cross distros in their development efforts) really the only thing they share is a package repository, but so do distros like Mint. This is an aspect of Fedora that I really like, I always felt it foolish to have a different distro for each Desktop Environment. ... +1. :-) That said, Kubuntu and Xubuntu aren't really completely separate either, they're just marketed as such. They're really just spins from the same repository. The way they're marketed as separate is really silly. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
梁穗隆 wrote: I am using f-spot to export my photos to picasa web album. It is much better than Google Picasa for Linux. I know that gnote will replace tomboy. I hope solang will replace f-spot for the reason that sometimes after I upload photos to picasa web album f-spot would crash. Try Digikam. su -c yum install digikam Kevin Kofler I more like gtk+ programs than qt4 programs.Haha! So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. -- urlhttp://liangsuilong.co.cc/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Matthew Garrett wrote: I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop. What changes are needed to the desktop? The big problem we've been facing integrating new features of core system services into KDE so far was lack of documentation. What do we need to change? If this will be all handled within DeviceKit, then this will come by itself with the Solid DeviceKit backend ltinkl is working on, but if we need to add some desktop interaction for it, we have to know what it should be. Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled? You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Tue, 2009-06-30 at 17:34 +0200, Kevin Kofler wrote: Bryn M. Reeves wrote: The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the Uptrack service). And as I explained, this can't be done for the released Fedora kernels (because they get big changes which ksplice cannot handle), unless you Which is more or less what I was getting at in the following message: The frontend is Ksplice Inc's Uptrack service, not ksplice. The installable bits of Uptrack seem to be GPLv2 (only the artwork has an exception which is fair enough). I couldn't find any of the backend bits available for download though and as others have pointed out in this thread there's still the problem of making ksplice fit in with Fedora's approach to kernel updates (to be honest, I think it'd be a lot easier to run a service like this for RHEL or CentOS particularly if you're only interested in selected security errata). On Tue, 2009-06-30 at 17:34 +0200, Kevin Kofler wrote: start from the GA kernel and only backport security fixes, which makes the kernel you provide become completely different from the current Fedora kernel over time. Not necessarily GA but yes, it's a lot of additional work and a struggle to fit this to the normal approach to kernel updates in Fedora. To be honest, I'm glad to have the ksplice tools in the distribution as it makes it easy to play with them if you're interested in the technology but I do think that the applicability of this tool to a distribution like Fedora is probably a lot less than it would be for e.g. one of the enterprise distributions for the simple fact that end users who are particularly intolerant to reboots are likely already looking for a platform with a longer release and support cycle and stronger (i.e. commercial) support guarantees. Fedora users who just want quicker reboots can always make use of kexec. Along with the boot time improvements in recent releases that should make installing and booting a new kernel pretty quick (apart from the inconvenience of shutting down applications). Regards, Bryn. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Tue, Jun 30, 2009 at 10:27 AM, Kevin Koflerkevin.kof...@chello.at wrote: That said, Kubuntu and Xubuntu aren't really completely separate either, they're just marketed as such. They're really just spins from the same repository. The way they're marketed as separate is really silly. They are actually separate development teams unless something changed since I left the Xubuntu project a few years ago. It was always that the projects were disjoint and the project leads were really the main line of communication between the separate projects (which makes zero sense to me). But none of that really matters, and I do see your point that we would essentially run into a similar situation from a marketing standpoint and I agree it is best left to the way it is with full identification of the Spins and their purpose. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
梁穗隆 on 06/30/2009 10:51 AM wrote: So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. I don't see a package review request or any koji builds. Are you sure it's coming to Fedora? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
Matej Cepl wrote: His point was that thousands of line of hardly obfuscated Javascript (think Google Docs) is hard to recognize from binary-only distribution, which I can see as pretty good argument. Right. The point isn't really about JavaScript the language, but about its integration into browsers and how it ends up used. It basically hides proprietary software in what users perceive as content. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Kevin Kofler (kevin.kof...@chello.at) said: Chris Adams wrote: ISTR FESCo voted that down. They voted it down based on false assumptions, such as the one from Bill Nottingham (the one that it doesn't make any actual difference, You know, I realize we may not agree. But I'd appreciate it if you didn't put words in my mouth. If you'll see the log: 17:33:02 notting The current naming misleads users into either thinking GNOME is the only available desktop environment in Fedora or thinking the image also provides the other options. - i don't really think either of these are accurate 17:33:26 notting skvidal: the download page already says 'featuring the gnome desktop' (The quoted part is your rationale from the ticket). My only other comments on the subject were questioning why you waited until you joined FESCo to propose this, when it didn't require that at all, and a comment that the discussion was going in circles, which it was. But hey, thanks for the unfounded assertion that everyone who voted against it was operating under false assumptions, and they could not possibly have any rational reasons for disagreeing with you. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Tue, 30 Jun 2009, Kevin Kofler wrote: Chris Adams wrote: ISTR FESCo voted that down. They voted it down based on false assumptions, such as the one from Bill Nottingham (the one that it doesn't make any actual difference, which was also Seth Vidal's main argument) I just rectified in the post you're replying to. I'll do what I can to get it up for a revote based on the feedback from this thread. It really wasn't my main argument. My main argument was that we need a default no matter what and that adding 'GNOME' to the label doesn't change anything and adds to the confusion of new users. It's the same argument that notting and ricky and others gave. Asserting that the only reason your proposal was rejected is b/c everyone else misunderstood is just outrageous. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On 06/30/2009 09:28 PM, Michael Cronenworth wrote: 梁穗隆 on 06/30/2009 10:51 AM wrote: So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. I don't see a package review request or any koji builds. Are you sure it's coming to Fedora? Solang developers need to port it to the newer version of libgda first. Otherwise it would require a compat package to get into the repository. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
梁穗隆 on 06/30/2009 10:51 AM wrote: So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. I don't see a package review request or any koji builds. Are you sure it's coming to Fedora? I really do not know when it comes to Fedora. I hope it soon. If you are interested in it, you can click into these websites and lean more about it. https://savannah.nongnu.org/projects/solang/ http://www.stefanoforenza.com/solang-is-a-new-photo-manager/ At last, I am not solang's author. -- urlhttp://liangsuilong.co.cc/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Outage Notification - 2009-07-01 01:00 UTC
There will be an outage starting at 2009-07-01 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-01 01:00 UTC' Affected Services: Buildsystem CVS / Source Control Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1496 Reason for Outage: Final migration step for new cvs server. It will hopefully be offline for only 30-45 minutes. The additional time is for some further tuning if needed and some verification steps. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
2009/6/30 Rahul Sundaram sunda...@fedoraproject.org: On 06/30/2009 09:28 PM, Michael Cronenworth wrote: 梁穗隆 on 06/30/2009 10:51 AM wrote: So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. I don't see a package review request or any koji builds. Are you sure it's coming to Fedora? Solang developers need to port it to the newer version of libgda first. Otherwise it would require a compat package to get into the repository. Rahul They also need to support latest version of libexiv2 -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
梁穗隆, Tue, 30 Jun 2009 23:51:30 +0800: I am using f-spot to export my photos to picasa web album. It is much better than Google Picasa for Linux. I know that gnote will replace tomboy. I hope solang will replace f-spot for the reason that sometimes after I upload photos to picasa web album f-spot would crash. jbrout works just fine for me. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.06.2009 19:04, schrieb Bill McGonigle: ksplice updates are only available for: 1. kernels that have been the lastest kernel in the past two weeks 2. kernel updates that are remotely exploitable 3. kernel updates that rate 'high' on CVSS I'd have to do more research to be sure, but just guessing this feels like 0-4 candidates per Fedora release cycle. Please keep in mind, that you can't handle a kernel update, if globlal structure was changed. Because Fedora has several kernel update in the lifetime, you have to create a ksplice kernelpatch for each kernel release which is available on Fedora. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpKSUYACgkQT2AHK6txfgxPDgCeLcU53/wFqhdSmydCzn5ToxB6 n0IAoI03A7nF40CXhjqgpYUvE5KfPDfj =d1i6 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
an update to automake-1.11?
I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. In general automake hasn't had a very good track record of compatibility between 1.x and 1.y, though this has been getting better recently. I don't see any specific mentions of incompatible changes in a quick scan of: http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html But it is also a pretty long release announcement so it wouldn't surprise me if there were some subtle incompatibilities. The only breakage I'm actually aware of in the gnome-common package; gnome-common-2.26 and earlier doesn't know that automake-1.11 is a valid replacement when automake-1.10 is asked for. So, we definitely need to release an update for gnome-common, or people aren't going to be able to do GNOME development on F11. But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in maintenance mode distributions like F9 and F10. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: Matthew Garrett wrote: Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled? You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change. I think the words you have choosen here are too strong. There is no current policy or requirement that requires that. I will certainly agree that it would be _better_ to coordinate among the DEs, and even possibly say it's preferred. But there is nothing that says they have to do that or wait for other DEs to catch up. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 11:19 AM, Matthew Garrettm...@redhat.com wrote: On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change. Hm. So, that bit about KDE not holding Gnome back wasn't entirely correct? I think you mean holding back Fedora. Obviously KDE is not holding back GNOME, or GNOME's development, or the GNOME Desktop Team from doing their work. Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one use at your own risk desktop? True question. I enjoy the new features in Fedora, like Bluetooth, PackageKit, and even Pulse occasionally. And I really like KDE, but I have cold shivers thinking that whether or not any of this stuff works under KDE is a crapshoot. KDE may not hold back GNOME. But it is perfectly logical to expect that KDE will hold back a Fedora feature release, if indeed A) that feature is not yet implemented in the desktop, and B) Fedora wishes to support KDE and GNOME together. Assuming that KDE features are given the same respect as GNOME features. If that doesn't hold, then no, KDE won't be holding back anybody. I suppose I'd be using KDE a little less under Fedora then. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads Up: e2fsprogs library split-out
On Mon, Jun 29, 2009 at 10:38:32AM -0500, Eric Sandeen wrote: There have been a few requests to split out the various libraries in e2fsprogs into subpackages: libcom_err(-devel) libss(-devel) libuuid(-devel) Note that libblkid(-devel) has already been split out as it is now part of util-linux-ng (thanks to kzak!) - an email was sent previously about that. Note that I'm also going to move libuuid (and all UUID utils) to util-linux-ng in next few days. You don't have to care about this change if you properly set dependences in your packages to libuuid, libuuid-devel or uuidd. Karel -- Karel Zak k...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, 2009-06-30 at 13:42 -0500, Jud Craft wrote: Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one use at your own risk desktop? Strictly, they're all use at your own risk. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Segfault connecting to a VPN through NetworkManager
Hi, I got this segfault trying to connect to the Microsoft VPN at work. [1] What should I raise a ticket against? NetworkManager, kernel, pptp, none of the above? [1] http://mbooth.fedorapeople.org/vpn-bug.txt -- Mat Booth www.matbooth.co.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Segfault connecting to a VPN through NetworkManager
On Tue, Jun 30, 2009 at 9:52 PM, Mat Boothfed...@matbooth.co.uk wrote: Hi, I got this segfault trying to connect to the Microsoft VPN at work. [1] What should I raise a ticket against? NetworkManager, kernel, pptp, none of the above? [1] http://mbooth.fedorapeople.org/vpn-bug.txt Actually this is a regression from F10. The script I use to connect on my F10 laptop [2] fails on my newly installed F11. It works with this software installed: kernel 2.6.27.15-170.2.56.fc10 NetworkManager 1:0.7.1-1.fc10 NetworkManager-pptp 1:0.7.0.99-1.fc10 pptp 1.7.2-5.fc10 And produces the segfault shown above with the following software installed: kernel 2.6.29.5-191.fc11 NetworkManager 1:0.7.1-4.git20090414.fc11 NetworkManager-pptp 1:0.7.0.99-1.fc11 pptp 1.7.2-6.fc11 [2] http://mbooth.fedorapeople.org/start-vpn (sorry, I deleted my password from this script ;-) -- Mat Booth www.matbooth.co.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
Dnia 2009-06-30, o godz. 10:35:13 Bryn M. Reeves b...@redhat.com napisał(a): If parts of userspace cannot re-initialise themselves without a reboot then they should just be fixed. Even init has been able to do this for years now - resorting to exotic live-patching methods for updating userspace is just a workaround for badly written software. Oh please... In your opinion, every program in existence should allow a user to hot-patch it? Like: dump the memory and open descriptors somewhere and execve() new version of itself? Yeah, you go ahead - write patches, contribute. Meanwhile, when a security bug strucks in the least obvious place, like wnck-applet or something, we will have means to fix it without logout for our users. That's a win. Really. Even if the method is exotic, which I can't deny. Lam signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On 6/30/09 2:05 PM, Owen Taylor wrote: I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. Wow. That *is* surprising. But is this the type of upgrade that makes sense in general? No. Even if Automake had a better track record of compatibility, upgrading a build tool to something that isn't simply a bugfix release does not make sense *in general* for released versions of Fedora. Special circumstances that might prompt such a move can always be discussed, of course. But this sort of thing incurs way too much risk. -- Braden McDaniel e-mail: bra...@endoframe.com http://endoframe.com Jabber: bra...@jabber.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, Jun 30, 2009 at 02:05:57PM -0400, Owen Taylor wrote: I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. In general automake hasn't had a very good track record of compatibility between 1.x and 1.y, though this has been getting better recently. I don't see any specific mentions of incompatible changes in a quick scan of: http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html But it is also a pretty long release announcement so it wouldn't surprise me if there were some subtle incompatibilities. The only breakage I'm actually aware of in the gnome-common package; gnome-common-2.26 and earlier doesn't know that automake-1.11 is a valid replacement when automake-1.10 is asked for. So, we definitely need to release an update for gnome-common, or people aren't going to be able to do GNOME development on F11. But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in maintenance mode distributions like F9 and F10. This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, 2009-06-30 at 14:05 -0400, Owen Taylor wrote: But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in maintenance mode distributions like F9 and F10. Agreed, and if there was a truly compelling reason for the upgrade, one would expect it to be mentioned in the update description. See also https://fedoraproject.org/wiki/Package_update_guidelines Cheers, Mark. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Bill Nottingham wrote: 17:33:02 notting The current naming misleads users into either thinking GNOME is the only available desktop environment in Fedora or thinking the image also provides the other options. - i don't really think either of these are accurate Well, I don't see how that's not the case. OK, the description on the download page says GNOME in small print, as you point out: 17:33:26 notting skvidal: the download page already says 'featuring the gnome desktop' but other references to the Desktop Edition or Desktop Live don't, e.g. the one on get-fedora-all, documentation, discussions etc. There's plenty of potential for misleading users. My only other comments on the subject were questioning why you waited until you joined FESCo to propose this, when it didn't require that at all Jef Spaleta nagged me about putting it before FESCo when the elections were already underway. I decided to wait until after the election because it was not a highly pressing matter and it was just a matter of a few days. The thing is, any moment is as good as any other to file a proposal to FESCo, I don't see why I *shouldn't* have filed it now. Surely I can't go back in time and file it before the election (or even months before, when nobody even told me to file it with FESCo). ;-) I think saying it has been like that for ages, you should have filed it earlier is a pretty weak argument against my proposal. Just because the status quo has existed for a long time doesn't mean it can't be improved upon. and a comment that the discussion was going in circles, which it was. It was because you (plural) didn't want to listen to my arguments, you were just eager to shoot my proposal down no matter what. But hey, thanks for the unfounded assertion that everyone who voted against it was operating under false assumptions, and they could not possibly have any rational reasons for disagreeing with you. The arguments you (plural) have brought have been very weak. If there are such rational reasons, I'd like to read them! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Seth Vidal wrote: It really wasn't my main argument. My main argument was that we need a default no matter what and that adding 'GNOME' to the label doesn't change anything If it doesn't change anything, why can't we add it? That argument doesn't make sense. and adds to the confusion of new users. How so? I see quite the opposite, i.e. it removes confusion! And incidentally, that's also what it'd change (so it changes something). How is it not confusing to users to have a spin called just Desktop? If KDE Desktop has KDE, what does Desktop contain? Something other than KDE, most likely, but that's all the name says. And taken by itself, Desktop could be anything: KDE, GNOME, even Sugar. Or all on the same spin. Calling it GNOME Desktop makes it clear it's GNOME and does not remove any information (it just adds a word)! And even if you know the Desktop spin contains GNOME, you may still think that having the GNOME spin called just Desktop implies it's the only desktop. That's actually a pretty rational assumption, as normally when there's more than one asdf, you don't just say asdf Edition, but Foo asdf Edition to distinguish it from Bar asdf Edition. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
Adam Miller wrote: But none of that really matters, and I do see your point that we would essentially run into a similar situation from a marketing standpoint Huh? If you follow the thread, I didn't really make that point at all! I just said made a semi-serious remark about how having a desktop environment with the same first letter as another would be a problem for Ubuntu as well. That said, I do agree that having our spins presented as separate projects is not the way to go. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Last call for F9 updates
F9 will be EOL'd very very soon. This is probably the last call for updates to F9. I wouldn't bother with updates-testing, as the time required to properly get those pushed out and have feedback from them is longer than the EOL date. That does not mean to push untested stuff straight to stable. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
Bill McGonigle wrote: The parenthetical is the actual reason people don't like to reboot and may ignore security updates. Boot times are trivial in comparison to restoring one's application state, for anything beyond the most trivial of use cases. The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day. Heck, even I do that. Leaving my computer running when I sleep wastes power and makes me sleep badly (probably because of the noise from the fans, though I don't exclude electromagnetic waves possibly having to do with it as well (but no, I don't use tinfoil hats or similar nonsense ;-) )). Home users with record uptimes are a small minority, even if there are probably many of those on this list. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Darn straight. I stand corrected. On Tue, Jun 30, 2009 at 3:06 PM, Adam Jacksona...@redhat.com wrote: On Tue, 2009-06-30 at 13:42 -0500, Jud Craft wrote: Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one use at your own risk desktop? Strictly, they're all use at your own risk. - ajax -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Josh Boyer wrote: I think the words you have choosen here are too strong. There is no current policy or requirement that requires that. And that's a big problem which needs fixing. Though I'd argue that it's just common sense and shouldn't need a policy in the first place. Just breaking other packages with an incompatible change without giving them a chance to adapt is the quickest way to degrade Fedora's quality. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, 2009-06-30 at 14:05 -0400, Owen Taylor wrote: But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in maintenance mode distributions like F9 and F10. Totally agree with you. We shouldn't be pushing updates to build tools in our stable releases unless there is a really strong reason for it. Later, /B -- Brian Pepple bpep...@fedoraproject.org identi.ca: http://identi.ca/bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Matthew Garrett wrote: So, what you'll get is a notification that a block device has requested removal along with a notification that a dock device is being undocked. What you do with the block device is up to you, but in general you'll want to unmount it. IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a please unmount me event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers? An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Daniel P. Berrange wrote: This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Some software may need the new version to build. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote: IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a please unmount me event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers? Because you might want to warn the user that they have unsaved work that will be lost if they continue? An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me. There are alternatives, like revoking the filehandles or prompting the user to close the application themselves. This is the same problem faced when unmounting any device. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, 2009-06-30 at 16:46 +0100, Matthew Garrett wrote: Can't the desktop inform the kernel if it can handle the interaction? If not, you can just fallback to the current behavior. Somewhat, but you then hit issues like fast user switching potentially involving desktops that support this and desktops that don't. But this is more a theoretical concern than practical. It would seem to me that you would still end up doing the right thing in a lot more cases than otherwise. And fast user switching could be instrumented to tell the kernel the right thing. The current behavior is useful for cases when you don't want user interaction (either because some desktops do not have the manpower to do it, or the use case for the box is such where such interaction is not desired). -- Dimi Paun d...@lattica.com Lattica, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Daniel P. Berrange wrote: This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Some software may need the new version to build. Then, they need to be patched so that they would get built for F9, or they should not be built for F9 altogether. pgp5bf8cXm7l4.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Segfault connecting to a VPN through NetworkManager
On 06/30/2009 09:11 PM, Mat Booth wrote: On Tue, Jun 30, 2009 at 9:52 PM, Mat Boothfed...@matbooth.co.uk wrote: Hi, I got this segfault trying to connect to the Microsoft VPN at work. [1] What should I raise a ticket against? NetworkManager, kernel, pptp, none of the above? [1] http://mbooth.fedorapeople.org/vpn-bug.txt Actually this is a regression from F10. The script I use to connect on my F10 laptop [2] fails on my newly installed F11. It works with this software installed: kernel 2.6.27.15-170.2.56.fc10 NetworkManager 1:0.7.1-1.fc10 NetworkManager-pptp 1:0.7.0.99-1.fc10 pptp 1.7.2-5.fc10 And produces the segfault shown above with the following software installed: kernel 2.6.29.5-191.fc11 NetworkManager 1:0.7.1-4.git20090414.fc11 NetworkManager-pptp 1:0.7.0.99-1.fc11 pptp 1.7.2-6.fc11 [2] http://mbooth.fedorapeople.org/start-vpn (sorry, I deleted my password from this script ;-) Creating a pptp vpn connection in NM works just fine for me :) NetworkManager-0.7.1-5.git20090617.fc11.x86_64 pptp-1.7.2-6.fc11.x86_64 NetworkManager-pptp-0.7.0.99-1.fc11.x86_64 kernel-2.6.29.5-191.fc11.x86_64 JBG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On 06/30/2009 08:14 AM, Arjan van de Ven wrote: how common are docking stations in practice? (as opposed to port extenders) Majority of our laptop users have them. Would be great to have them supported. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Wed, Jul 01, 2009 at 12:37:16AM +0200, Kevin Kofler wrote: Josh Boyer wrote: I think the words you have choosen here are too strong. There is no current policy or requirement that requires that. And that's a big problem which needs fixing. Though I'd argue that it's just common sense and shouldn't need a policy in the first place. Just breaking It is not always cut and dry. other packages with an incompatible change without giving them a chance to adapt is the quickest way to degrade Fedora's quality. Quite possibly. Though there are also cases where changes are made that will break a package and upstream has little or no intention of dealing with it in a timeframe that allows Fedora to progress. The whole zope/plone fiasco comes to mind there. I don't think KDE is the same in that regard, and both the KDE SIG and KDE upstream are very active and even proactive on a number of issues. So I agree breaking things is bad, and in general we should all try and play nice and communicate about upcoming changes. Which is exactly what Matthew has done by starting this very thread. Good for him. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Tue, Jun 30, 2009 at 5:12 PM, Kevin Koflerkevin.kof...@chello.at wrote: Seth Vidal wrote: It really wasn't my main argument. My main argument was that we need a default no matter what and that adding 'GNOME' to the label doesn't change anything If it doesn't change anything, why can't we add it? That argument doesn't make sense. and adds to the confusion of new users. How so? I see quite the opposite, i.e. it removes confusion! And incidentally, that's also what it'd change (so it changes something). Either way it is named can and probably will confuse some users. I don't think this is an important point since people will be confused either way. How is it not confusing to users to have a spin called just Desktop? It doesn't confuse the people who would be confused by adding GNOME to it when they don't know what GNOME is. Honestly, all arguments about this or that confusing or misleading users are not compelling. I happen to support the following changes. (1) I prefer the name of the Fedora-11-i686-Live.iso image to be Fedora-11-i686-Live-GNOME.iso to present consistent and accurate information about the content of the images in a directory listing. (2) On the wiki I prefer the Fedora 11 Desktop Edition be called the Fedora 11 GNOME Desktop Edition because that again makes for a consistent presentation and because that is what it is. Listening to a recent RadioTux broadcast I heard it called the GNOME Live Spin by a prominent community member. Both of these changes I would also support because I think it is nuts to deepen a rift in the community over them. If we continue to only have the GNOME Live image on the get-fedora page this won't confuse the new users looking for the desktop spin because it will be the only one they see and they will just take it. So if the community agreed to these two changes, which seem reasonable to me, then what? Well, I think at this point we hit the real wall in this debate, but I really don't think we can avoid the subsequent requests for more equal treatment by refusing to call GNOME GNOME. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
By the way, On Tue, Jun 30, 2009 at 2:05 PM, Owen Taylor wrote: I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. why is there no update information about these builds? There is a big Notes box on bodhi which is there for a reason. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
kernel-2.6.29.5-206.fc11.x86_64 in koji
Installed this kernel, and upon boot it panics. I can't find anything in any logs, as it seems to happen upon first start of boot (as in during the quiet part of boot) before the processes are started to come up. -- Mike Chambers Madisonville, KY Fedora Project - Bugzapper, Tester, User, etc.. miketc...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett wrote: On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote: IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a please unmount me event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers? Because you might want to warn the user that they have unsaved work that will be lost if they continue? Isn't there Save As... for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails. An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me. There are alternatives, like revoking the filehandles or prompting the user to close the application themselves. This is the same problem faced when unmounting any device. Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this. A similar problem is this: mkdir foo touch foo/bar kwrite foo/bar rm -rf foo Should kwrite be killed because rm killed the directory? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpKtXkACgkQiPi+MRHG3qTVrgCfXM3ItQpUBYzK1JT91RoJ4rjy fNEAoKEkgrII4JNkaundDYMv76fTAD69 =qUfz -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 09:01:45PM -0400, Ben Boeckel wrote: Isn't there Save As... for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails. It depends on what resources you have open on the hardware. If part of your application is on the disk that's about to be disconnected, then you have problems. Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this. A similar problem is this: mkdir foo touch foo/bar kwrite foo/bar rm -rf foo Should kwrite be killed because rm killed the directory? No, because it still has a reference to it. Unmount works differently to remove. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
- Matthew Garrett m...@redhat.com wrote: On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: Matthew Garrett wrote: What changes are needed to the desktop? The big problem we've been facing integrating new features of core system services into KDE so far was lack of documentation. What do we need to change? An event will be generated and a policy agent then needs to choose what to do in terms of unmounting any media. The precise interface doesn't exist yet, but will be documented. If this will be all handled within DeviceKit, then this will come by itself with the Solid DeviceKit backend ltinkl is working on, but if we need to add some desktop interaction for it, we have to know what it should be. So, what you'll get is a notification that a block device has requested removal along with a notification that a dock device is being undocked. What you do with the block device is up to you, but in general you'll want to unmount it. Whether you're willing to kill applications that have open files on it is a policy decision. After the unmount you'll then trigger the completion of the undock and tell the user that it's now safe to remove their hardware. IMHO, it is pretty much similar to the way that we handle USB hubs and devices. In terms of UI, it may have a nice dock status icon to show status and to be pressed if users want to un-dock safely. Yet we still need to handle the force-undock event, just like we handle the forced unplug USB devices. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Kevin Kofler (kevin.kof...@chello.at) said: The thing is, any moment is as good as any other to file a proposal to FESCo, I don't see why I *shouldn't* have filed it now. I wasn't asking as a means of making an argument against it. I'm asking because this is something that could have been raised to FESCo at any time in the past by you (or others), regardless of your status on FESCo. The fact that you filed it immediately after joining FESCo, combined with your own statement of 'I've been proposing this on the mailing list for ages' and 'My platform was clear', makes the implication that it was *intentional* to wait until now, and in essence use a FESCo position as the colloquial bully pulpit. Which I find sort of sad. But hey, thanks for the unfounded assertion that everyone who voted against it was operating under false assumptions, and they could not possibly have any rational reasons for disagreeing with you. The arguments you (plural) have brought have been very weak. If there are such rational reasons, I'd like to read them! 1) You argue that the name 'Desktop' makes people think that it contains *all possible desktops*. I find that to be an extremely unlikely reading of the name. Given that to assume that you'd already have to know of other desktops, then you would already know what the 'KDE fans...' text means, or know what the long list of things on the torrent pages are. 2) I feel that changing the name on get-fedora doesn't give any benefits; it adds verbiage that's *already there* in the description. 3) On get-fedora-all... you're coming from a page (#2) that already describes it as being GNOME. 3) If you're talking about torrent.fp.o, the descriptions on that are so bad that there are a whole host of things that need fixed before one filename. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Hi Kevin, It was because you (plural) didn't want to listen to my arguments, you were just eager to shoot my proposal down no matter what. I think this is your 60th post to this thread, in the four days that it's been going. I don't have anything to say about the thread itself, but I'd encourage you to take a break from the thread and consider what else you think it's important to add to it. This is just advice, naturally; I'm interested in ways that we can use this list more constructively. - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Josh Boyer (jwbo...@gmail.com) said: So I agree breaking things is bad, and in general we should all try and play nice and communicate about upcoming changes. Which is exactly what Matthew has done by starting this very thread. Good for him. And, to be honest, I think a hack that just returns 'hey, do whatever' to the kernel (thereby preserving the old behavior) would be pretty darn simple. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
Hi folks, Ksplice is very interesting and I've spoken with a few people about it before. I met the (local to Cambridge, MA) ksplice guys several times and recently talked to them about the kinds of things they're doing right now. Uptrack is a nice showcase of the technology for sure. More comments below... On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote: Michael Cronenworth wrote: From looking at their website, it sounds like this software can take you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like black magic. I'm intrigued. It relies upon using the existing module loading code to stop the kernel at a given moment in time (which might have to be attempted several times before succeeding in applying the ksplice patch, if the code paths being updated are currently being exercised) and inserts careful jumps to new code replacing existing functions wholesale with new ones. It actually can't and this is why it isn't very useful within Fedora, as we get big updates, not just minimal security patches. It would be useful for stable security updates in an enterprise distribution, and it is useful to some people in community distributions - but there's a lot of effort involved and this is where the ksplice guys have invested time in their infrastructure which we would have to entirely duplicate (and engineers too) to do this in Fedora. KSplice can't handle that kind of updates. Actually, it technically can. It can only handle small patches which don't change any data structures. That's a load of removed. I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot. But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu kernel they're doing this for at the moment they have some of the kernel engineers they have on staff actively writing pre/post hooks. So the official Fedora kernel updates will never be suitable to be distributed through KSplice. That's not technically true either. It's just not practical. We would need a much larger team of people and all of the infrastructure tools developed by the ksplice guys. And it's indeterminate what the end goal would be from that - most people are happy to reboot occasionally, and those who are not can already pay Ksplice, Inc. to make updates for them. I'm not sure this is something Fedora can practically offer. Also - for those kernel folks reading. Don't discount ksplice because it sounds ugly. Tim and Waseem really do get it, and they know what they're doing - and they're actively engaging with upstream to get the bits that could be in the mainline kernel in there (ksplice doesn't require any existing kernel modifications because it also injects its own code during the ksplice patch application as part of the wrapper module). I suggest if you're interested in add this random code patch here type of kernel development/testing that you add ksplice to the toolbox. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler wrote: Daniel P. Berrange wrote: This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Some software may need the new version to build. Very unlikely. However, this upgrade may break rebuilding some of the packages whose packagers refuse to accept that running the autotools during builts is harmful. Anyway, the changes between automake-1.10 and automake-1.11 have been comparatively harmless. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 508496] Perl: symbol lookup error: .../Wx.so: undefined symbol: Perl_Guse_safe_putenv_ptr
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=508496 Kevin Kofler ke...@tigcc.ticalc.org changed: What|Removed |Added CC||ke...@tigcc.ticalc.org --- Comment #5 from Kevin Kofler ke...@tigcc.ticalc.org 2009-06-30 12:56:14 EDT --- +1, disabling RPM_OPT_FLAGS is NOT ALLOWED in Fedora! You need to fix the actual issue. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
