Re: Fedora Linux Format software review: January 2010
2009/12/31 Tom spot Callaway tcall...@redhat.com: On 12/30/2009 02:15 AM, Hans de Goede wrote: It would be nice if others could join in (be it virtual not necessarily physically). So are there any takers for this ? I am looking to generate interest in getting software that is not included in Fedora into the repositories so to hear of this kind of effort is wonderful. I have updated the wiki page to reflect this, FWIW. https://fedoraproject.org/wiki/LinuxFormatPackaging/January2010 I am currently auditing of the next edition of the magazine and will update the wiki with that soon. It might be useful to have a wiki page listing out the specific content items which need to be replaced. Yes, this would be great. I take it upstream are not willing to re-license the sources? -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fixing the kernel for intel laptops
2010/1/1 Paul p...@all-the-johnsons.co.uk: Hi, I'm trying to get my Intel graphics driven laptop up and running again (see BZ 523646 for details of the problem) and am trying to rebuild the kernel using the latest from kernel.org and the fedora srpm (install srpm, copy the kernel, run the spec). The idea is I drop each patch, build and see which one is killing the system and then feed that back to the kernel bods. The current rawhide kernel (2.6.32.2-14.fc13.i686) is no go on the laptop. Question is, how do I configure the spec file to use the latest kernel tarball? I'm not sure why you are pulling from kernel.org and integrating into the srpm as that is what happens anyway. You mention in comment #31 of that bug that you updated and this caused the problem to exist on both f12 and f13 kernels. I'd be inclined to visit your yum log and see what was updated and revert it, if you are able. It may not even be kernel-related. You might also want to consider taking this to fedora-kernel as the kernel developers are less likely to read this list due to the volume. You don't have to subscribe. Best -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT considered painful
2009/12/30 Kevin Kofler kevin.kof...@chello.at: Michael Schwendt wrote: What's wrong with ABRT? My main beef with it is that it reports its crashes to the downstream bug tracker when really the right people to fix them are the upstream developers. KCrash/DrKonqi is much better there. Probably because we need to determine whether the issue is Fedora-specific (packaging bug) or is also replicated in the vanilla version before we create more noise on upstream's bug tracker. Hence why kernel developers usually ask if bugs can be reproduced from Linus' tree. Cheers -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora Linux Format software review: January 2010
Hi folks, Linux Format is a popular magazine in the U.K but which ships all over the world. It regularly reviews interesting bits of software and I thought: a) It would be interesting to see how much of what they review is included in Fedora b) It would be a good idea to get that which is not in and/or up to date c) If there is enough interest I would like to form a SIG to do the monthly reviews - a kind of packaging wishlist on steroids perhaps :) I blogged about this recently and you can read the basic idea there: http://chruz.wordpress.com/2009/12/23/ive-got-the-music-on-my-radio/ The editor has expressed his willingness to send details of software which they will review to us so we have a head start. I have conducted the first review of the January 2010 issue which you can read here: https://fedoraproject.org/wiki/LinuxFormatPackaging There are some interesting omissions, for example Recoll, the desktop search tool which came out ahead of Beagle and Google Desktop and which doesn't even have a review request opened for it yet. A few points that need mentioning: 1) I do not and have never worked for Linux Format nor has anyone I know :) 2) There may be some glaring errors - this is why this is on the wiki so please feel free to update/change etc. For example I have not undertaken rigorous reviews for the software's suitability. 3) This is not intended as anything other than a distillation of what would be good to have in the repositories. I welcome your comments as ever. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel security update required or not?
2009/12/21 Bojan Smojver bo...@rexursive.com: On Sun, 2009-12-20 at 22:21 -0600, Bruno Wolff III wrote: I didn't see any of the recent previous spec file comments indicate back ported security fixes. So its unlikely the latest security fixes are in any earlier version. If you want them now, grab the kernel from koji. Otherise you can wait for the kernel to push to updates or updates-testing depending on how much you want to wait for other people to test it before you try it out. I understand what I can do. That is not the issue. The question is, should Fedora get a security update or not - you know - for all the users out there that are unaware of Koji etc. I'm sure Fedora kernel folks reading the list will know. Ask on Fedora-kernel. Its got a better SNR and you don't need to subscribe. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
2009/12/15 Adam Goode a...@spicenitz.org: On 12/13/2009 06:16 AM, Christopher Brown wrote: 2009/12/11 Adam Goode a...@spicenitz.org: We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key. The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think. You're right. This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it. It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own? Ideally we (Fedora and Debian) should use a single key generated by upstream but as this issue is only problematic due to cyclic dep problems in the build process I think that using our own is enough. Unfortunately I don't care enough to chase this issue further. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
2009/12/12 Debarshi Ray debarshi@gmail.com: And let me put it this way: if fedora decides to post my non @fp.o address somewhere, like in git entries, I'm going to be extremely pissed off about it. As for me, I don't mind publishing my real email address but I would prefer not to have my fedoraproject.org alias published where the spammers can find it. I don't particularly like having forwarding aliases created for me, but if you have to give me one then please don't publish it. Here you go: rombobe...@fedoraproject.org rombobe...@fedoraproject.org rombobe...@fedoraproject.org rombobe...@fedoraproject.org rombobe...@fedoraproject.org Now what? Cheers, Debarshi I think that is unnecessarily untagonistic. This is a non-issue. Both my fpo and non-fpo are published regularly in commits and whatnot and I receive about 1 spam per week. But then I have gmail. :) -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
2009/12/11 Adam Goode a...@spicenitz.org: On 11/29/2009 11:29 AM, Christopher Brown wrote: 2009/11/29 Kalev Lember ka...@smartlink.ee: Hello, snip Comments? I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this. Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this. We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key. The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think. You're right. This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it. Best -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
2009/12/11 Dennis J. denni...@conversis.de: On 12/10/2009 09:01 PM, Pete Zaitcev wrote: On Thu, 10 Dec 2009 15:38:10 -0200 Henrique Juniorhenrique...@gmail.com wrote: I agree that postgresql is great, but MariaDB is expanding very fast. I'm not the best person to opine about databases, my experience is very limited, but it would be nice to keep an eye on MariaDB. Well, duh. Who's going to maintain it though? There must be a warm body. I for one care much more about Drizzle than about MariaDB. From what I can tell MariaDB is basically just a new storage engine inside the old crufty MySQL shell whereas Drizzle is a (much needed) overhaul of the whole thing. Much more interesting for future projects if you ask me. Regards, Dennis Meh. May the best code win. I would have thought that at the moment you could pretty much drop the MariaDB sources into the MySQL directories and: sed 's/MySQL/MariaDB/g' mysql.spec mariadb.spec as a start. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Useless setroubleshoot alerts
2009/12/8 Konstantin Ryabitsev i...@fedoraproject.org:
From the point of view of security usability, this is cardinal sin:
http://file.status.net/identica/tieguy-20091208T063036-ngc2rhp.png
If we start the warning message with SELinux has detected suspicious
behaviour on your system and end it with You can safely ignore this
avc, then we are doing everyone a nasty disservice. Please, let's fix
it as soon as possible. I understand the need for SELinux to log
things purely for auditing purposes, but the user must NOT see those
alerts, or we'll condition everyone to just dismiss them.
I'm fairly certain this is a bug, but I've not yet bz'd it, as I
wanted to make sure that this is not intended behaviour.
If it is then it is proof of insanity. I shy away from any Yet
Another SELinux Rant type stuff but this is plain ridiculous. I had
Gnome-terminal up this morning and was shelled into a remote box.
Thats it. Then I got a warning of the above - something to do with
bash and prelink. Couldn't care less really.
The end result is me disabling SELinux on my box. Sorry, I don't have
time or inclination to file a bug on this constant irritant ever since
it was introduced as nobody seems to take notice. Instead I'm asked
to:
# chcon_text_rel_slib insert_irritating_long_option_here
add_some_random_characters_for_good_measure_}{)()(*^^$%$1
or something. SELinux was quite good on F11 and F12. Now it would seem
it is starting to regress again.
/rant
--
Christopher Brown
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kernel update highly recommended
2009/12/9 Kyle McMartin k...@mcmartin.ca: NOTE: This is only a problem if you're using EXT4, if you aren't, you're safe. ReiserFS FTW!!! :) -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
2009/12/7 Toshio Kuratomi a.bad...@gmail.com: On Sun, Dec 06, 2009 at 11:48:12AM +0100, Adrian Reber wrote: I was informed that wordpress uses bundled libraries and would like to request an exception from FESCo. https://bugzilla.redhat.com/show_bug.cgi?id=544720 You need to have an explanation of why an exception would be appropriate. Bundling libraries is, among other things, a potential security hazard which means that people are able to get connected to the place. When formulating the explanation, remember that you have to make the case that unbundling libraries would be harmful and that the problems outlined on this page: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries It looks like there is a clear advantage to shipping _without_ bundled libraries anyway as the wordpress people keep having to update their bundled bits for security and feature reasons... But anyway, I think Adrian gets the message now :) -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
2009/11/29 Kalev Lember ka...@smartlink.ee: Hello, snip Comments? I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this. Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this. Paul Johnson looks after a good deal of the mono stuff so happy to be guided by him really. I imagine Spot will want to have a say as it looks like he has been doing the heavy-lifting when each rebuild takes place and this is clearly a pain[2]: Thanks for raising this Kalev! Cheers -- Christopher Brown [1] http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-signing [2] https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00122.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/iptstate/F-12 iptstate.spec,1.21,1.22
2009/11/11 Michael Schwendt mschwe...@gmail.com: On Wed, 11 Nov 2009 09:17:58 + (UTC), Paul wrote: Author: stingray Update of /cvs/pkgs/rpms/iptstate/F-12 %changelog +* Tue Nov 10 2009 Paul P. Komkoff Jr i...@stingr.net - 2.2.2-2 +- rebuild for libnetfilter_conntrack-0.0.100 + +* Tue Nov 10 2009 Thomas Woerner twoer...@redhat.com 2.2.2-1 +- new version 2.2.2 +- removed upstream strerror patch +- fixed package description (rhbz#140516) + Caution! Dude, you should slow down quite a bit and give all this a second thought. You have not yet committed and built the new libnetfilter_conntrack upgrade for F-12. Rebuilding the other packages for F-12 won't work correctly because of that. They are built against the old library. Take your time. Update your cvs working-directory with cvs up -d to get the F-12 branch, then follow Fedora procedures for this ABI-incompatible library upgrade (which means to request a koji buildroot override tag from Fedora Release Engineering so the new libnetfilter_conntrack for F-12 will be made available in the koji buildroot _prior_ to pushing it into the stable updates repository. That way you can prepare all rebuilds without pushing any incompatible upgrades into the stable repo). If you need help, ask your sponsor, or ask on this list. Oops, too late! [ch...@yoda ~]$ sudo yum update Loaded plugins: presto, refresh-packagekit Setting up Update Process Resolving Dependencies -- Running transaction check --- Package dhclient.x86_64 12:4.1.0p1-4.fc11 set to be updated --- Package f-spot.x86_64 0:0.6.1.3-1.fc11 set to be updated --- Package f-spot-screensaver.x86_64 0:0.6.1.3-1.fc11 set to be updated -- Processing Dependency: libnetfilter_conntrack.so.1()(64bit) for package: iptstate-2.2.1-5.fc11.x86_64 --- Package libnetfilter_conntrack.x86_64 0:0.0.100-1.fc11 set to be updated --- Package libvorbis.x86_64 1:1.2.0-9.fc11 set to be updated --- Package libvorbis-devel.x86_64 1:1.2.0-9.fc11 set to be updated -- Finished Dependency Resolution iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems -- Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Is there any way to sanity-check pushed updates for depsolving capabilities? -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CONFIG_INTEL_TXT
2009/10/23 Arjan van de Ven ar...@infradead.org: On Thu, 22 Oct 2009 18:39:53 +0100 Jon Masters j...@redhat.com wrote: Don't forget to mention the more paranoid hand-waving about removing RAM chips at runtime with liquid nitrogen after going into suspend and hax0ring. I think there will be more upstream discussion anyway. I'm sorry but this argument makes no sense whatsoever. Claiming that a feature should not be enabled because someone is talking about a mythical attack that is waaay outside the scope of what a technology wants to protect is not solid reasoning, it's fear mongering instead. All the same, it was disappointing news to me to read that Intel are even pushing stuff that leverages binary blobs with no source code. There would be nothing to fear and no need for fear mongering if it was an open blob. It would make the whole argument moot. -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
2009/9/8 Markus Kesaromous remotes...@live.com: Date: Mon, 7 Sep 2009 18:17:38 -0400 From: jwbo...@gmail.com To: remotes...@live.com CC: fedora-kernel-list@redhat.com Subject: Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: Still not fixed: arch/x86/kernel/pvclock.c:63:7: warning: __x86_64__ is not defined Please stop posting such messages here. josh Why? What gives you the right to say what gets posted or does not get posted here ? This is the fedora kernel list. I posted an issue with the latest fedora kernel source. No, you didn't. The latest fedora kernel source is found in rawhide. If you have a problem with that, I strongly encourage you to unsubscribe from this list. The problem Markus is that you have already had your query responded to and it took me a very small amount of time to discover the problem was fixed in 2.6.31. Messages like the ones above detract from people's time spent developing the kernel and as such you were asked to not post messages of this nature. Please respect that - contributions such as patches to enable the kernel to build are most welcome however. Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
2009/9/7 Markus Kesaromous remotes...@live.com: Still not fixed: arch/x86/kernel/pvclock.c:63:7: warning: __x86_64__ is not defined Correct. You will see this in 2.6.31. http://lkml.org/lkml/2009/7/14/164 Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bugzilla Desktop Client
Would be grateful for info on what this does that bz web interface doesn't. On Sep 5, 2009 6:36 PM, Rajkarn Singh rajkar...@gmail.com wrote: Hi, I am working on the development of a general Desktop Client for Bugzilla. Currently it can access Red Hat Bugzilla database, however in future I'd be working to make it work for other Bugzillas. I have posted a blog having somewhat detailed information about it. Please check it at: http://raj-khalsa.blogspot.com/2009/09/bugzilla-desktop-client-first-phase.html Working on this project is my first experience into the world of Open Source. I'm very new to this field. So I'd appreciate your suggessions and comments for this work. Also, I'm eager to hear you guide me for my future endeavours. :) Regards, Rajkarn Singh -- 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: yum-presto plugin by default
2009/8/18 Chuck Anderson c...@wpi.edu: On Tue, Aug 18, 2009 at 01:35:37AM +0530, Rahul Sundaram wrote: On 07/26/2009 06:40 AM, Rahul Sundaram wrote: Hi, Can we make it a default in comps for Rawhide? Rahul No answer here after weeks. After some lengthy discussion with rel-eng team in irc, not much care either way. Talked to desktop team and based on their recommendation, I have added yum-presto to the GNOME Desktop group by default. If rel-eng wants to add it a base group for the DVD image, feel free to do so. Spin owners - likewise. Thanks. I've been using yum-presto since before F11 came out, and it is great. +1 to installing it by default in F12. FWIW, I have also experienced zero problems with it and believe it would be better enabled by default, retaining the option to disable. Updates would get done faster and mirrors would be able to cope with more connections, especially in the first push after release day... :) -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (no subject)
2009/8/13 Markus Kesaromous remotes...@live.com: Date: Thu, 13 Aug 2009 00:01:25 +0100 Subject: Re: (no subject) From: snecklif...@gmail.com To: remotes...@live.com Hi Markus, 2009/8/12 Markus Kesaromous : Dear List, I searched the ath9k source directory /usr/src/redhat/BUILD/kernel-2.6.29/linux-2.6.29.i586/drivers/net/wireless/ath9k for any strings that would hint/suggest support for the Atheros 9220/9223 chipset. I saw no such strings. What strings were you looking for? I stated: for any strings that would hint/suggest support for the Atheros 9220/9223 (meaning 9220 or 9223 ala grep '922[0-9]' * (within the ath9k directory). So, I emailed Atheros.com sales dept. and asked if they intend to provide an open source driver for the AR9000 series chipsets, esp. the AR9220/AR9223. They replied that they already DO support the AR92xx chipset in the ath9k driver. Before I go out and purchase the mini-pci card, is it true that the ath9k driver has ineed been tested to fully support AR9220/AR9223 chipsets?? Your thought process intrigues me. If you have communication from the manufacturer advising it is supported then you have your answer (and a waterproof returns policy if they are wrong). I have learned never to trust sales people. When it comes to dealing with online merchants, what the sales contact at the manufacturer says will not be sufficient reason for return for a full refund, of a device which turns out to be unsupported. Then why contact them? My question to you is - why do you have to resort to assuming such a pompous attitude via questions like Your thought process intrigues me. I'm afraid this is your interpretation. There is a fitting description for such attitude, but I will not spam this mailing list with such a vivid description. Then please reply off-list, as I did. Some basic investigation on the web will tell you what you need to know: http://wiki.debian.org/ath9k#supported No really, that's my pleasure. -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel 2.6.29.6-217.2.3.fc11 compile d from source will not boot
2009/8/10 Markus Kesaromous remotes...@live.com: Dear list, There is something seriously wrong with this kernel release. It compiles - but will not boot all the way. It hangs somewhere. I even tried to boot into single user mode. I never get to the shell prompt when booting in single user mode, nor to the gnome login banner when letting it boot in multiuser mode. After some 30-45 minutes I Ctrl-Alt_Del and the kernel pops the message Stopping all md devices .. and the pc reboots. I did not have this problem with these kernels 2.6.29.6-213.fc11 2.6.29.5-191.fc11 Are there others who have tried to build 2.6.29.6-217.2.3.fc11 from source rpm and configured the kernel in any way before building? Did you see any errors when running make modules_install as I did? Did the resulting kernel boot up all the way? If you need more info, please let me know. The main piece of information you appear to have missed off is the modifications you have made in your build. I would suggest the following for further reading: http://fedoraproject.org/wiki/Docs/CustomKernel http://fedoraproject.org/wiki/KernelCommonProblems Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Feature proposal: Extended Life Cycle Support
2009/7/6 Jeroen van Meeuwen kana...@kanarip.com: On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? That plus the fact that you have Red Hat, the major backers of Fedora, producing a distribution that is geared towards long term support for their clients. Hence any initiative to increase the length of time Fedora is supported will not (I believe) receive anything more than lip service from RH. I completely understand that and it makes financial sense. The more you try and give Fedora some kind of LTS, the more you stray into territory already covered by RHEL (paid support) or CentOS (unpaid support). I was simply trying to identify what the requirements are for LTS on Fedora. I think simply saying Fedora needs LTS is doomed as the past has proved. Those that forget the past are doomed to repeat it. - George Santayana The sooner Fedora gets out of its identity crisis the better. I believe the following: Fedora is the distribution for those who love computers. CentOS, Ubuntu and others are for those who dont. Regards -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
1. How did you find out about Fedora Test Days? Planet.fp.o 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? Documentation was excellent. 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? None - only took part on the nouveau day though. 4. Were you able to locate and download installation media for testing? Did it function as expected? Yes. 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? Bugs fixed. Possibly a summary of how the previous test day helped before talking about the next one? 6. Would you participate again in future Fedora Test Days? Yes, dependent on barrier to entry. 7. Do you have any more general comments or any suggestions for improving future test days? Just that I'm very glad they're happening. Well done. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching Fedora to pae kernel by default?
2009/1/20 Kyle McMartin k...@infradead.org: On Tue, Jan 20, 2009 at 11:06:17AM +0200, Avi Kivity wrote: Eric Paris wrote: I've got a P3 (Coppermine) with 256M memory running F10. My significant other took it with her to Antarctica (Well F9 has been to Antarctica but it'll be F10 in Antarctica next month). You can only run one app at a time and have to be patient, but it's perfectly usable (and noone cares if this laptop is lost, stolen or destroyed [aside from her being pissed she lost all her research data]). I wouldn't/couldn't to use it as a daily machine, so while I'm in favor of -PAE default, F10 is usable on such small machines. I don't care if old machines need some bit twiddling to get to work, but we aren't dead yet :) By F12 you'll be down to zero apps at the same time, and slow... We can keep the non-PAE kernel, but as non-default in recognition that technology has moved on. Look, I'm sorry if I'm just not thinking big picture enough here, but what exactly is the use case for a PAE kernel these days? The compat code in x86_64 should be more than good enough for the apps that require an i686 chroot. I just don't see the status quo as doing any real harm, as the only generations of CPU that benefit are really P4 (which aren't worth the electricity used to power them) or Core (One) Duo (which didn't exist for a particularly long time...) Neither of which actually supported more than 3GB of RAM on their northbridges except for the Xeon chipsets anyway. I have no idea what the installer and livecd do, but to me, it would seem to be a waste of space to carry two sets of installable kernels on the discs, when one would do. That said again, I'm suprised we aren't installing i586 kernels by default... Odd. I think the ideal solution here is to support x86_64 kernel, i686 userspace more actively. What, honestly, are the odds of someone with a bunch of P4 Xeons these days with 32GB of ram running Fedora? Are there really enough of them that it's worth caring? ;-) Of course, take what I say with a grain of salt. I don't particularly care at all, I'm just trying to play the pragmatist. Another question is what's the perf penalty of going to PAE on a 2GB of ram machine versus the vanilla HIGHMEM4G config? The only argument I really buy into is the NX one, honestly... What about a yum plugin that recommends a kernel that the user could override? I'll poke at it this afternoon (hey, I've always wanted to learn python...) May I point out that those that care enough to want PAE usually know how to go about getting it enabled whereas those that have install failure because they're running non-PAE hardware probably wont know how to go about getting it disabled. The fall-out from this going onto the livecd makes me shudder. The original argument that many machines have 4GB of memory is simply false. Manufacturers aren't shipping anything more than 2GB on desktops at most unless you have oodles of money to throw at a Alienware box or something. Sure, servers come with more but Fedora is not really a reality for a long term server O.S. -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Custom Kernel USB Boot Problem
2009/1/9 Ahmad Al-Yaman ahmad221...@yahoo.com: Hi everyone, I'm building a custom kernel optimized for the Eee PC netbook. The kernel works without problems when installed on the main SSD but when I tried installing it on a USB flash disk, or SD card, and booted, I got the following error: Unable to access resume device (UUID=UUID) mount: error mounting /dev/root on /sysroot as ext3: No such file or directory I'm assuming there are some packages necessary to boot from USB devices that need to be included in the kernel config which I didn't include. Can anyone give me an idea what those packages might be? Isn't this problems with mkinitrd? http://fedoraproject.org/wiki/Common_F10_bugs#Unbootable_new_installation_of_F10 There's not much point using journalled file systems on SSD btw - you should use ext2 to save your drive some unnecessary writes. Turn off swap too if you have it enabled. Regards -- Christopher Brown ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-vanilla builds for 2.6.27-rc1
2008/8/8 Josh Boyer [EMAIL PROTECTED]: On Fri, 2008-08-08 at 00:39 +0100, Christopher Brown wrote: 2008/8/7 Josh Boyer [EMAIL PROTECTED]: On Mon, 2008-08-04 at 23:01 -0400, Josh Boyer wrote: http://jwboyer.fedorapeople.org/pub/ Let the kernel installs begin. Hopefully I didn't fsck something up horridly. If I did, then I'll fix it for -rc2. Updated to -rc2 builds now. And the kernel-firmware Requires issue should be fixed up thanks to Jarod. It looks all good from here. I'll be posting a diff of the vanilla and ummm ... blueberry ... dmesg in a moment. Any caveats, gotchas, test suites? As for gotchas, well, it's a -rc2 kernel so be warned. But the same is true of rawhide in general. My current plan is to only do vanilla builds for -rc and final releases, unless a particular -rc is really badly broken and a git snapshot fixes quite a bit. A few caveats below. The intention isn't to provide an alternative kernel. It's more for those that want to test something and see if it works on vanilla as opposed to a patched Fedora kernel. That should be quite rare, as the Fedora kernels are fairly top notch and don't differ much from vanilla anyway. Then I suppose this begs the question - why aren't we shipping a vanilla kernel to begin with? I'm sure there are excellent answers and I'm aware of some of them already. I do think it would be good to pimp this a bit more and that it could be offered as a viable alternative. Or do I have my head in clouds I don't understand? Probably. I'm sure some will use it as a primary kernel, but they should realize there is no support for these and the likely response will be try rawhide and/or please report it to the Linux kernel mailing list. On the contrary would this not bring greater support. At the moment mainline ask people with bugs to test with mainline which your average joe has difficulty with. Also, due to quota limitations I can really only host one kernel version at a time. That means as soon as -rc3 comes out, the current builds are replaced. Understood, but if there was some way to get this added into the official repositories do the Fedora kernel bods see an opportunity? Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] be less annoying on boot
On Friday 01 August 2008 3:51:05 pm Bill Nottingham wrote: As long as we're printing mostly useless messages on every boot regardless of debug level, make them 5% more amusing. Sometimes I think a Frankenstein quote more appropriate: --- linux-2.6.26.noarch/arch/x86/kernel/head64.c.foo2008-08-01 15:44:28.0 -0400 +++ linux-2.6.26.noarch/arch/x86/kernel/head64.c2008-08-01 15:46:53.0 -0400 @@ -109,11 +109,11 @@ early_printk(Kernel alive\n); x86_64_init_pda(); - early_printk(Kernel really alive\n); + early_printk(And now, with the world before me, whither should I bend my steps?\n); x86_64_start_reservations(real_mode_data); } void __init x86_64_start_reservations(char *real_mode_data) -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] be less annoying on boot
2008/8/2 Eric Paris [EMAIL PROTECTED]: On Sat, 2008-08-02 at 14:59 +0100, Christopher Brown wrote: On Friday 01 August 2008 3:51:05 pm Bill Nottingham wrote: As long as we're printing mostly useless messages on every boot regardless of debug level, make them 5% more amusing. Sometimes I think a Frankenstein quote more appropriate: NAK, does not apply. Yeah, gmail's interface does this fantastic Watch while I f*** with your coding style as soon as you hit send. I think its called a WYSIWLLAA editor - What You See Is What Looks Like Ascii Art. It's a sad day when I can't submit a single one-liner -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: gspca as part of the rawhide kernel?
2008/7/3 Hans de Goede [EMAIL PROTECTED]: Hi all, As some of you know I've been working on improving webcam support under Fedora, see: http://fedoraproject.org/wiki/Features/BetterWebcamSupport http://hansdegoede.livejournal.com/ One of the things I've been working on is in beating gspcav2 (a v4l2 port of gspca) into shape, although I must admit most of the work has been done by Jean-François Moine, the latest version is available from his mercurial tree and it has been pulled into the official v4l-dvb tree for wider testing. Once it has been in the v4l-dvb tree it will make its way into the mainline hopefuly for 2.6.27, if not then certainly fotr 2.6.28. To check it out see: http://linuxtv.org/hg/~jfrancois/gspca/ Some time ago I've already done a review of the gspca_core and there are some locking issues to solve (I already know how, I just need to code them out). Once this is done I would like to see gspcav2 be added to the Fedora kernel, as to make the: http://fedoraproject.org/wiki/Features/BetterWebcamSupport Feature a reality (also needs userspace work, I'm on this). So my questions are: 1) would it be acceptable to cary the gspca driver as a patch (only new files and makefile / kconfig changes doesn't touch anything else) until it is merged upstream. Note that this is much needed for wider webcam support and that gspca is on its way to the mainline now, and I'll personally will be working on ironing out any issues upstream may have with gspca as is. 2) Assuming the answer to 1 is yes, how do I move forward, can I get be added to the kernel package acl, what are the procedures for adding a patch and building a new kernel, etc? Personally I'd love to see this in rawhide. If you have a patch that applies against the current rawhide kernel then scratch-building one in koji isn't too much of a greater leap. Maybe DaveJ and the other kernel bods would be happier if i's cleanly applying and won't need much maintenance. Just note in the kernel.spec to append a buildid (e.g. gspca) - more info here: http://fedoraproject.org/wiki/Docs/CustomKernel Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
On 21/01/2008, Adam Jackson [EMAIL PROTECTED] wrote: http://people.freedesktop.org/~ajax/kernel-autopatch.patch Based on something I did for the xserver specfile. Essentially this makes it so you only have to name the patches once, in the order you want to apply them, which makes it both easier to work with and harder to forget things. I've tried to make this as friendly and robust as possible, including bailing out appropriately when faced with a bad patch, and explicitly naming patches that fail to apply right at the end of build output. Feedback would be appreciated, even if it's of the form no, that's gross. Can't speak from an implementation point of view but you must be a mind-reader. Several people will appreciate the thought behind it, myself included. On #fedora-kernel recently: kylem i really find it irritating that i need to edit Patchxx: *and* add an ApplyPatch. * kylem ponders converting the spec file to use quilt. j-rod fark j-rod not a fan of that either jwb why not j-rod ? f13 I think he meant he's not a fan of editing twice. f13 not that he wasn't a fan of quilt. jwb oh kylem i always forget to do one or the other :\ Cheers! -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Bug triage - next step
Hello Dave, Chuck et al, I'm back from the extended break and intend to review F7 bugs once more with a view to closing those that have not responded to gentle nudging for more info. In general these will have been dormant for 2-3 months. Unless there are any objections I intend to start this process within the next few days. Hopefully then the bug count will rapidly start to look less manic and the important stuff will bubble to the surface a little more clearly. Cheers -- Christopher Brown http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Vacation
Hi folks, As per http://fedoraproject.org/wiki/Vacation I'm away for a little under a month from tomorrow, pretty much out of contact. I have been through most of the Fedora 7 kernel bugs and will resume these duties on my return. I hope I have been of some help but for now, Australia awaits! Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IRC.
On 21/09/2007, Dave Jones [EMAIL PROTECTED] wrote: I've created a #fedora-kernel channel on freenode in response to the large number of /msg's I continue to get which really should be going to a wider audience. I expect it to be low-traffic, but it may be a worthwhile experiment to see if it helps any for triage, coordination etc. Is there any value is punting out a message to fedora-test to get more people on the case with triaging? I'm getting to the point now where bugs aren't so old any more therefore people remember why they filed, can still replicate the bug so the process rate is slowing somewhat. When you say /msg do you mean people in IRC or bugzilla emails about bug status changes. Is it worth setting up a bugzilla monitor to show status changes to kernel bugs? Also, is it worth setting mailman to change the reply-to address so it goes to the list rather than the poster a-la -devel and -test? Cheers Chris -- http://www.chruz.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
