EPEL Thunderbird and/or claws-mail in epel 7 beta
Hi, Will the subject packages be included in epel 7? I don't see them listed on the web pages at http://dl.fedoraproject.org/pub/epel/beta/7/SRPMS/repoview/ tia ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F19 DVD over size - what to drop?
On 05/03/2013 09:45 AM, Jóhann B. Guðmundsson wrote: snip Why not just make the assumption that administrators will use the netinstall and or ks and desktop users will use live spins? JBG I don't know if it is still the case, but historically you could NOT specify a file system different from the live spin--ext4. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 05/03/2013 12:30 PM, Rahul Sundaram wrote: On 05/03/2013 04:22 PM, Clyde E. Kunkel wrote: On 05/03/2013 09:45 AM, Jóhann B. Guðmundsson wrote: snip Why not just make the assumption that administrators will use the netinstall and or ks and desktop users will use live spins? JBG I don't know if it is still the case, but historically you could NOT specify a file system different from the live spin--ext4. That doesn't apply for the last few releases. Rahul Well, heck, just go with spins then. Put them on DVDs. Allow a default desktop environament and a selection of other desktop environments. Common brown bear users will use the default spin (Gnome) and more sophisticated users will pick their spin and if they need something not on the spin, they will yum install it. I don't intend to start the discussion on default desktop, but it really doesn't seem to be of any consequence since all popular desktops have their own spin. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 11:51 AM, Felix Miata wrote: On 2013-03-13 17:29 (GMT+0200) Sebastian Mäki composed: * remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on. * keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood. I was pretty much unable to do anything when my hood release froze this winter. The only way to get under the hood and fix a problem with starting the car was to wait for warmer weather. No amount of waiting within my expected lifetime would have helped me. The battery died, and the hood cable broke at the latch. No amount of sheet metal disassembly was possible with the hood latched, even after removing the grill. I had to go find a similar car to study its latch mechanism, then squeeze in between the puddle and the bottom of the car and reach up with a big screwdriver to fram on the latch mechanism until I got lucky and hit the right spot to make it release. My kind of engineer!! We fix anything!! -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 03/13/2013 12:02 PM, Kevin Fenzi wrote: snip 2) You can take the longer release time, get the new codebase in and done and then you are in much better shape moving forward. We choose 2. (Anaconda folks, feel free to drop in and correct me if I got anything wrong). I can't see much way to explain it in more detail, so I think I will leave it at that. kevin Finally, a reasonable development approach. Please do get the installer in maintainable shape and consistent from release to release. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system freezes after loading gdm/gnome
On 02/25/2013 09:26 AM, Jan Dvořák wrote: Hi, I am running rawhide for fun and since a few days ago a few seconds after starting gdm the whole system freezes. I am sorry that I can't really pinpoint the exact update as I suspend and this only manifested after a reboot. The problem is that I don't get any logs and running startx with exec gnome-session in .xinitrc leads to the exactly same problem. Interestingly, if I run just gnome-terminal from my .xinitrc, close it and then re-run with full gnome-session, I get the shell and everything seems to work. Well, except it is somewhat sluggish, suggesting some hidden breakage. Any advices? Best regards, Jan Dvorak Seeing this also. Rawhide up-to-date with stock ati driver on RV 630. X seems to be eating up cpu cycles during sluggishness. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130223 changes
On 02/23/2013 03:48 PM, Kevin Fenzi wrote: snip mygui - http://koji.fedoraproject.org/koji/taskinfo?taskID=5047260 No idea what should be providing libCommon.so for it. snip maybe should be libcommon vice libCommon? -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help figure out the debug slowness
On 01/27/2013 06:12 AM, Michael Schwendt wrote: On Tue, 22 Jan 2013 09:44:43 -0600, Justin M. Forbes wrote: snip kernel-3.8.0-0.rc4.git5.1.fc19.x86_64 is significantly slower than the previous release for all graphical activities. For me the opposite is true. It is (subjectively) faster than 3.8.0-0.rc4.git3.1.fc19.x86_64. Have not been updating daily, tho. $ lspci | grep -i vga 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV630 [Radeon HD 2600 Series] -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [rawhide] ideas to improve rawhide
On 01/23/2013 11:55 AM, Kevin Fenzi wrote: Greetings. As some of you may know, I switched my laptop over to rawhide and have been posting a series of blogs about the various issues I have run into in the last month. To recap from those: - xfce4-session crash: https://bugzilla.redhat.com/show_bug.cgi?id=891113 (work around clearing session cache, it's not shown up again) - libselinux blow up. This could have caused folks to not be able to boot until upgraded/downgraded. Broken package only in for one day. - libcdio abi bump with a few broken packages. Fixed in one day. - xulrunner/firefox broken dep for a day. - colord multilib issue. Fixed in one day. - iwlwifi slow. Not a stopper, just anoying. (bug 863424) - gtk3 update makes nm-applet unhappy (bug https://bugzilla.gnome.org/show_bug.cgi?id=691911 ) - libnl3 abi break. fixed in 2 days. - mdadm needs newer dracut. Just needs a rawhide build, should be fixed tomorrow. So, I've been collecting ideas on how to improve things in rawhide and have made a wiki page for these ideas. https://fedoraproject.org/wiki/Rawhide_improvement_project_2013 I know some folks at fudcon were talking about rawhide improvements too, so hopefully we will see those proposed before too long as well. I've tried to suggest things that won't disrupt maintainers much while making things nicer for consumers. Some of these things I have already discussed with folks involved and we are going to try and do them, others are needing more fleshing out/discussion. I'm very open to more ideas or thoughts, or comments/people willing to work on items from the above wiki page. Thoughts? kevin Would issues with specific 3.8 kernel drivers affecting rawhide be a candidate? TIA -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [rawhide] ideas to improve rawhide
On 01/23/2013 12:25 PM, Kevin Fenzi wrote: On Wed, 23 Jan 2013 12:08:21 -0500 Clyde E. Kunkel clydekunkel7...@verizon.net wrote: Would issues with specific 3.8 kernel drivers affecting rawhide be a candidate? Candidate for a tracker bug? Perhaps. It would depend on how widespread the issue is. Definitely do file a bug on it, and if you think it's a common hardware, notify the list about it so other people can see if they have the same issue. kevin Bug 901828 - radeon :01:00.0: GPU lockup CP stall for more than 1msec This is ATI RV630 [Radeon HD 2600 Series] graphics card. Google search shows some issues with the driver in the 3.8 series of kernels. All other flavors of fedora (non-3.8 kernels) are fine. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 01/16/2013 12:00 PM, Rahul Sundaram wrote: snip I haven't seen any recent activity in Fedora from him. Have you? Rahul Some patches on the btrfs list on Jan 7 and 8, 2013. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
On 12/08/2012 12:07 AM, M. Edward (Ed) Borasky wrote: snip Why does there need to be a long-term support for Fedora? Why not just use Red Hat Enterprise Linux? I imagine it boils down to money since Fedora=free and RHEL=$$$. Corporate suits will will weigh cost of Fedora support vs RHEL support and decide accordingly. Or if money is an issue use Centos. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 11/21/2012 03:01 PM, David Lehman wrote: snip Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. David I, for one, would be interested. Will the image be usable with RC9? Thanks for all of your hard work!! -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 10/17/2012 11:55 AM, Adam Williamson wrote: On Wed, 2012-10-17 at 16:05 +0200, Dario Lesca wrote: Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto: to keep you on your toes, of course you forgot ;-) ... because if you're talking seriously this is a wild unacceptable answer What is the real reason for this (for now unjustified) change? Does anyone know? Was the old one really better, or were you just used to it? Comparing the first time you use the new dialog to the 50th time you used the old one is an entirely unfair comparison. You have to compare the first time you use the new dialog to the first time you used the old one. *Any* new design will seem more difficult than the old one, at first, to someone who was familiar with the old one. I think the new dialog could use some improvements, and it's getting them, but a question like 'the old one ruled, the new one sucks, why u change?!' is really not that productive. The reasons for the UI re-design are in the feature page. The newui is akin to gnome 3 in that it takes some getting used to. Now, g3 is second nature and very usable. Using newui as much as possible, and filing bugs, helps a lot. My only gripe is that the storage portion of F17 worked very well at final and I only wish that logic had gone into F18 from alpha on. Why fight the storage battle again when it has already been won? -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer ?
On 12/06/2011 05:26 AM, Daniel P. Berrange wrote: On Mon, Dec 05, 2011 at 11:08:32PM +0100, Pierre-Yves Chibon wrote: snip It might be interesting to run this script across every single user in the Fedora accounts system, and proactively identify any users whom have not done anything in Fedora for a period longer than say 6-9 months. Daniel If we have a FAS account and don't use it often but review several fedora lists weekly, would we show up in this scenario? -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fesco membership policies
On 11/14/2011 11:19 AM, Peter Robinson wrote: On Mon, Nov 14, 2011 at 4:15 PM, Matthew Garrettmj...@srcf.ucam.org wrote: Something that was brought up at the last fesco meeting is that fesco membership is currently restricted to members of the packaging group. That's arguably overly restrictive - fesco is intended to be the body with technical oversight over the entire project, not merely packaging, and in that situation it seems odd to restrict membership to a subset of the people under fesco's pervue. There's a few things we can do here. We can keep the status quo. We can add new groups such as qa. Or we can open it to the entire project and just assume that the electorate will ensure that nobody inappropriate gets elected. Anyone have opinions on what we should be doing here? Sounds reasonable to me, is changes to FESCo something that needs to be approved by the Board? (adding f-a-b mailing list for clarification). Peter Multidisciplinary membership is good. However, please keep a balance in that no one group is over represented. Also, how about a non-technical member from the general user community? Should provide a nice balance to the technical side. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On 10/17/2011 10:20 AM, Bruno Wolff III wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? I filed https://bugzilla.redhat.com/show_bug.cgi?id=746481 against systemd, but it has been closed notabug. So I am looking for simple alternatives to do this. If there aren't any, then it looks like I need to make a custom service that waits for networking to be up. FWIW, I have been struggling with this for awhile. And now, in what seems like magic, it is working fine in rawhide but not in F16 (tho it does in maybe 1 in 20 boots). I followed the procedure in https://fedoraproject.org/wiki/Netconsole. Since the e-net card is renamed to a local bus name (p37p1 in my case), specifying eth0 in the netconsole parms wasn't working and systemd was reporting an error and specifying p37p1 wasn't working since the device was eth0 at the time. Since updating systemd to systemd-37-1.fc17.x86_64, specifying eth0 now works nicely to start netconsole logging well before NetworkManager does its thing and I still get a eth0 network using NetworkManager. Before the systemd update, I would see the following in dmesg: ... [ 12.732929] netconsole: local port [ 12.734575] netconsole: local IP 192.168.0.10 [ 12.735906] netconsole: interface 'eth0' [ 12.737225] netconsole: remote port [ 12.738535] netconsole: remote IP 192.168.0.11 [ 12.739846] netconsole: remote ethernet address 00:1d:60:e5:ee:55 [ 12.741201] netconsole: eth0 doesn't exist, aborting. [ 12.742528] netconsole: cleaning up [ 12.74] mtp-probe[909]: checking bus 8, device 4: /sys/devices/pci:00/:00:1d.2/usb8/8-2/8-2.4 [ 12.749445] mtp-probe[872]: checking bus 2, device 2: /sys/devices/pci:00/:00:1d.7/usb2/2-5 [ 12.751298] mtp-probe[912]: checking bus 8, device 3: /sys/devices/pci:00/:00:1d.2/usb8/8-2/8-2.1 [ 12.752693] fedora-loadmodules[747]: FATAL: Error inserting netconsole (/lib/modules/3.1.0-0.rc8.git0.1.fc16.x86_64/kernel/drivers/net/netconsole.ko): No such device [ 12.754183] systemd[1]: fedora-loadmodules.service: main process exited, code=exited, status=1 [ 12.773096] systemd[1]: Unit fedora-loadmodules.service entered failed state. ... -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On 10/17/2011 01:10 PM, Clyde E. Kunkel wrote: On 10/17/2011 10:20 AM, Bruno Wolff III wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? I filed https://bugzilla.redhat.com/show_bug.cgi?id=746481 against systemd, but it has been closed notabug. So I am looking for simple alternatives to do this. If there aren't any, then it looks like I need to make a custom service that waits for networking to be up. FWIW, I have been struggling with this for awhile. And now, in what seems like magic, it is working fine in rawhide but not in F16 (tho it does in maybe 1 in 20 boots). I followed the procedure in https://fedoraproject.org/wiki/Netconsole. Since the e-net card is renamed to a local bus name (p37p1 in my case), specifying eth0 in the netconsole parms wasn't working and systemd was reporting an error and specifying p37p1 wasn't working since the device was eth0 at the time. Since updating systemd to systemd-37-1.fc17.x86_64, specifying eth0 now works nicely to start netconsole logging well before NetworkManager does its thing and I still get a eth0 network using NetworkManager. ... Well, spoke too soon, seems I had a run of good luck with netconsole loading early. No longer true. Need to figure out how to get this working: $ systemctl status fedora-loadmodules.service fedora-loadmodules.service - Load legacy module configuration Loaded: loaded (/lib/systemd/system/fedora-loadmodules.service; static) Active: failed since Mon, 17 Oct 2011 13:36:20 -0400; 16min ago Process: 632 ExecStart=/lib/systemd/fedora-loadmodules (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/fedora-loadmodules.service Sorry for the noise. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Proventesters meetup 2011-10-12 at 18UTC
On 10/11/2011 04:05 PM, Kevin Fenzi wrote: We are going to be having another proventesters meetup tomorrow on IRC in #fedora-meeting at 18:00UTC. Purpose of meetup: Brainstorm ideas on improving testing and processes for testing updates. * Intro/gather more agenda items * Recruiting more proventesters/testers. * One stop page for updates testing resources * Your amazing agenda item here. Please do join us if you are a proventester, want to become one, or have ideas for improving the testing of updates. Note that this is not the venue for changing the updates policy, see FESCo for that, this is an attempt to get things working better within our existing updates policy. Hope to see folks there! kevin ... I cannot attend this meeting but would like to request that consideration be given to changing the Fedora NN updates-testing report to list the actual package/software requiring security or critical path testing. I used to be able to look at these items when the actual package/software was listed and then try to test the ones I have installed and/or am familiar with. Since I always keep 3 versions (plus rawhide) of Fedora installed, it really facilitates the testing. Thanks for your consideration. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On 10/08/2011 05:43 PM, Christoph Wickert wrote: Since Mozilla switched to the new rapid release model, Firefox in Fedora is no longer fun: Every 6 weeks a new major version hits our stable release and breaks Firefox horribly: * My favorite extensions (and actually the only thing that keeps me using FF) stop working. In the last 7 weeks I had to pitch in three times and update packages to get things working again. Sometimes there is not even an update available upstream. * Firefox falls back to English as there is no language pack provided. I have to go go the FTP server and download and install the XPI file manually. We have ratified very strict guidelines for updates in the stable releases and we allow one of the critical path applications to break this hard? So what can we do to improve the situation? 1. Can we bring back the language packs as part of the packages? 2. Can the FF maintainers make sure that all maintainers of extensions get notified of changes *before* release of a new package? 3. Can someone (I'm looking at you, QA) make sure all extensions are still compatible? More ideas or suggestions? Regards, Christoph This is why I now use only google-chrome. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS on LVM causes long fedora-storage-init run?
On 10/07/2011 11:31 AM, Richard Shaw wrote: I posted this on the main mailing list but didn't get any hits. Hopefully I'll have better luck here. --- I found the following thread but I don't think mine is the same problem: http://lists.fedoraproject.org/pipermail/test/2011-June/100861.html I am, however, running BTRFS on main main partitions on top of LVM (since anaconda as of F15 still creates an LVM setup regardless of filesystem?) This is the only thing I can think of that's causing the problem. $ systemd-analyze blame | head 47003ms fedora-storage-init.service 30284ms boot.mount 8829ms udev-settle.service 3692ms cups.service 1686ms systemd-vconsole-setup.service 1567ms udev.service 1510ms autofs.service 1403ms fedora-readonly.service 1311ms lvm2-monitor.service 1295ms NetworkManager.service boot.mount I assume just remounts the boot partition as read-write, so I think it's just waiting on fedora-storage-init.service. Any ideas? Thanks, Richard Don't really know...but, if no LV snapshots, then suspect BTRFS as it is still very experimental. There is a newer lvm2 (lvm2-2.02.84-4.fc15.x86_64) which fixed the LVM snapshot problem and systemd (systemd-26-10.fc15.x86_64) for F15. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS on LVM causes long fedora-storage-init run?
On 10/07/2011 12:57 PM, Michael Cronenworth wrote: Tomasz Torcz wrote: Do you have caches enabled and fully built? Remounting with -o space_cache,inode_cache will enable them. Then wait few minutes for caches to be built (I/O will stop when they're ready). Subsequent mounts should be faster. No. I'm using defaults as my mount option. I'm hesitant to enable the caches as btrfs is still very experimental and I'd rather not have to rebuild the fs if something fails. I'm probably just going to format the drive as ext4 and wait for btrfs to mature. Since you are going to reformat the drive anyway, maybe a test with -o space_cache,inode_cache first would help the btrfs folks gain some information. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs
On 09/12/2011 07:39 AM, Kevin Kofler wrote: Clyde E. Kunkel wrote: Didn't say like, said similar. Don't you test your changes somehow? Or do you just toss the mods over the wall and hope for the best? I don't think so. Share your test cases for those packages that should just work--not all packages. Forget that the changes are for rawhide and forget that Rawhide is NOT suitable for any sort of production use and that it WILL break. (Not may, will!) I bet every developer and maintainer has pride in their work and products and really don't want to put untested changes into any distro. Testing is exactly what we have Rawhide users for. Kevin Kofler Please tell me that you aren't advocating that developers/maintainers don't need to test their work before releasing it to rawhide. yes, rawhide is a testbed--and a good one--but that does not mean stuff should just be thrown into it. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development to release quality
On 09/12/2011 06:01 AM, Matej Cepl wrote: Too much QA (or any external QA) imposed on the development make it slower. Compare Linux v. OpenSolaris kernel development. Fedora tries to be very fast developing distro, thus less QA in the development version. Ah yes, the ol' QA conundrum. There isn't enough when a bad product slips into production and there is too much the rest of the time. We need QA. We also need to remember QA's place in this world--support, not line management, not the the final arbiter. But then this is another long thread. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development to release quality
On 09/12/2011 10:17 AM, Jakub Jelinek wrote: Sure, we need QA, but for rawhide the development shouldn't be totally stalled as it is already in F16 right now, where updates for critpath packages, even when they have several hundred thousands of tests performed already during package building, just sit in bodhi for 2-3 weeks, often with first proventester karma after 12 or 14 days. Jakub I think I used too much hyperbole in my original rant on this subject. We certainly don't want rawhide packages to sit anywhere for a period of time. We just want some system that assures us that the package got some kind of testing before it was released to rawhide. And not every package--just the critical core packages (what those are would be another long thread). For 99% of the packages, I am sure they have been tested by the developer/maintainer. It is the package that just doesn't work that causes the angst, when a simple install or update and run would have shown a problem. Anyway, the problem as it relates to rawhide is really too small to spend any more energy on. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What do rawhide testers want and expect?
On 09/12/2011 11:57 AM, Stephen John Smoogen wrote: In reading the long trash each other fest that accompanies pre-release jitters, could we start on a cleaner plate? What do the people who are using rawhide day-in/day-out expect out of the channel? What level of pain does someone like Jonathan Corbet expect and how can we better serve them? [And no this isnt me trying for another distro quote of the week, he is just my reference point of someone I know who runs rawhide day in and out.] In some cases, expectations may be off which means we need to market our deliverables better. In other cases, they may be looking for a better way to get attention to rawhide issues when everyone else is focused on F-XX-beta. In that case we can look at a mechanism that allows for less zero-sum game antics of elementary school yard you suck, no you suck more that the threads head towards. I use rawhide daily, primarily for mail, web and document creation. I also enjoy trying new software in rawhide which leads to some interesting situations. I like to test the packages in updates-testing as a proven packager, but lately have been afraid to do so since what I think is a problem is criticized as not being a problem or if the package works for me but I can't test the bug it fixes then I am criticized for not testing the bug and passing the package on. I expect rawhide to just, minimally, work, i.e., boot at least to a command line. I also expect breakage, but I also expect that whatever breaks it to get attention and will file a bug if I can figure out what broke it. Before there was no-frozen-rawhide, we would sometimes get a heads up that something would break rawhide and a workaround or advice to avoid the specific update. That doesn't seem to happen any more. It seems that too much software is just dumped into rawhide without any sanity checking before hand. I do see notices on the development list about abi breakage or a change in an .so-n file. Should new packages, bug fixes, new capabilities and enhancements destined for the current development release (F16) be required to work in rawhide first? Why not have FESCO develop a definitive statement on what rawhide is, how to use it and what it expects from developers/maintainers and testers and then publish it on all Fedora lists, wiki's, LWN and the New York Times and Washington Post. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs
On 09/11/2011 04:33 AM, Jim Meyering wrote: darrell pfeifer wrote: Fails for me too, with the same error. Thanks for confirming that. I don't mean to be rude or inflammatory, but do have to wonder how such a fundamentally-broken package was released -- even to rawhide. In the fedora openssh release process, isn't there some sort of sanity check that would catch this before inflicting it on all rawhide users? Maybe there needs to be a classification for rawhide similar to the karma system for updates-testing, but limited to just a set of packages that should just always work (maybe openssh would be one). For such packages, there should be a test validation set that the maintainer runs to automatically allow the package into rawhide. I know in the past when such things have been discussed, some maintainers chimed in that they do have test sets that they run on their packages. Doesn't have to be for all packages, just the ones that are critical or necessary. Yeah, defining those will be a challenge, but then what they hey, makes life interesting. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs
On 09/11/2011 06:19 PM, Kevin Kofler wrote: Clyde E. Kunkel wrote: Maybe there needs to be a classification for rawhide similar to the karma system for updates-testing, but limited to just a set of packages that should just always work (maybe openssh would be one). For such packages, there should be a test validation set that the maintainer runs to automatically allow the package into rawhide. NO! Just no! We cannot do any useful development if we have to wait 10+ days (1 push delay + 7 full days + 1 (another) push delay) for any of our changes to get out. The push delays alone are enough of a PITA even if the 7-day delay is set to 0 days for Rawhide. This karma model doesn't even work well for releases, it'd be completely insane for Rawhide. We just need people to grasp that Rawhide is NOT suitable for any sort of production use and that it WILL break. (Not may, will!) As they say: Rawhide eats babies! If people have to run Rawhide to get the current software they need, then THAT is the problem we must fix (and in fact one of the major advantages of Fedora used to be that this was NOT the case, but recent policy changes made it more and more the case!). Making Rawhide suitable for production use is about as realistic as making nuclear fission without radioactive waste. Kevin Kofler Didn't say like, said similar. Don't you test your changes somehow? Or do you just toss the mods over the wall and hope for the best? I don't think so. Share your test cases for those packages that should just work--not all packages. Forget that the changes are for rawhide and forget that Rawhide is NOT suitable for any sort of production use and that it WILL break. (Not may, will!) I bet every developer and maintainer has pride in their work and products and really don't want to put untested changes into any distro. I am willing to test and test and test, but need test cases for most things, especially esoteric bugs that are hard to duplicate. Just because its rawhide doesn't mean we just throw our hands up and say oh its just rawhide and ignore sound development, coding and testing methods and ignore good engineering principles. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide openssh-server update kills sshd
On 07/26/2011 12:22 PM, Jim Meyering wrote: snip service ssh restart Would that be: service sshd restart ? -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On 06/24/2011 04:07 AM, Rahul Sundaram wrote: On 06/24/2011 12:55 PM, JB wrote: JBjb.1234abcdat gmail.com writes: http://en.wikipedia.org/wiki/Trusted_computing TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around trusted computing. If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that Rahul Rahul, Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
On 06/24/2011 11:04 AM, Rahul Sundaram wrote: On 06/24/2011 09:55 PM, Clyde E. Kunkel wrote Rahul, Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette. The proper etiquette would be to use the reference once and state the contention along with it. Not merely copy paste wikipedia article content multiple times in a thread especially when you are confusing remote attestation with remote access. What am I suggesting is a more effective way. and less noise. Rahul OK, you win, Rahul. From now on you will be the Emily Post of mail lists. :-) -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji: filter by dist-release
On 06/21/2011 01:56 PM, Reindl Harald wrote: http://koji.fedoraproject.org/koji/builds is there any way to get this filtered only for F15 or whatever is used? Maybe try: https://admin.fedoraproject.org/updates/ then select Fedora 15. You may need a FAS account, not sure. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome borked?
On 06/20/2011 06:46 AM, Paul Johnson wrote: Hi, After doing a rather large update to my rawhide box, it seems that it no longer wants to play fair with Gnome giving a very unfriendly Something has gone wrong which I can't recover from. You should logout and try again message. Other than some desklet errors, nothing seems to be wrong (obviously it is though). Any ideas what the problem is or how to fix it? PFJ main.js threw exception: Error: FIXME: Only supporting fixed size ARRAYs https://bugzilla.redhat.com/show_bug.cgi?id=714472 Waiting for a fix...too many dependencies to revert gnome-shell I guess. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 04:44 PM, mike cloaked wrote: On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundarammethe...@gmail.com wrote: On 06/11/2011 12:36 AM, mike cloaked wrote: Would be nice to see the systemd author join this discussion? I am sure you can get answers when someone is off vacation. However what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul OK I guess we'll get more discussion when he comes back from his holiday - sorry I was unaware of the vacation but thanks for clarifying. I guess that your reference to moving to upstream indicates that systemd is now sufficiently established that discussion of problems is an upstream issue for bug triage/fixing? I would imagine that the user list may have useful exchanges too but that it would be important to get any issues moved upstream from there too? The most important outcome is that bugs are fixed so whatever route is best for that (including bugzilla of course) users should add input to. Hence links to upstream for systemd are made available so that the best exposure to recourse to resolution is optimised? I hope discussions continue on Fedora lists as well. systemd impacts lots of fedora users who just read Fedora lists. I've subscribed to gnome, network manager, btrfs, virt, lvm, selinux, anaconda, kickstart, desktop, and etc. Sure, folks subscribe to more lists than that, but when you can't spend much timre reading the lists, having discussions concentrated in your distro of choice's lists frees up precious time to actively participate in testing. As a Fedora user and tester it is far easier to just peruse the Fedora lists. Once systemd settles in and is no longer viewed with suspicion, then maybe add upstream for the rare issue. Please don't be a wet blanket, folks, let the discussions continue here. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110520 changes
On 05/20/2011 05:35 AM, Rawhide Report wrote: kernel-2.6.39-0.fc16 * Thu May 19 2011 Dave Jonesda...@redhat.com - Update to 2.6.39 final. * Sat May 14 2011 Kyle McMartinkmcmar...@redhat.com - Update to v2 of Mel Gorman's SLUB patchset Above didn't update installed 2.6.39-0.rc7.git6.1.fc16.x86_64. Are they the same? TIA -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Special thanks to gnome3 and systemd developers
On 05/18/2011 10:20 AM, Bruno Wolff III wrote: While everyone that worked on the F15 release deserves thanks and congrats, I'd like to give a special thanks to the systemd and gnome3 developers because of the large amount of work needed to implement those features. By working hard to get these into F15, they helped meet Fedora's goal of being First. +100 -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Final Release Candidate 1 (RC1) Available Now!
On 05/11/2011 03:27 PM, Andre Robatino wrote: As per the Fedora 15 schedule [1], Fedora 15 Final Release Candidate 1 (RC1) is now available for testing. Please see the following pages for download links and testing instructions. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test swnip x86_64 dvd iso is missing. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Status of btrfs in rawhide
Hi, Is rawhide following current btrfs development releases with kernel patches and userland programs? Or, should we role our own? I am interested in testing only. TIA -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 / Gnome 3 gotchas
On 05/07/2011 12:50 PM, Mario Blättermann wrote: Am 07.05.2011 16:51, schrieb Richard W.M. Jones: On Fri, May 06, 2011 at 03:58:51PM +0200, Denys Vlasenko wrote: On Sat, 2011-04-16 at 11:05 +0100, Camilo Mesias wrote: snip GNOME 3. We need a new GNOME as close as possible to the old one, to keep the current users. Well, it would be fine to get new GNOME lovers, but not by kicking the old farts out. Hey, I resemble that crack. Gnome 3 has not kicked me out and the more I use it, the more I like it. Just shows that you can teach an old dog new tricks!! -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 / Gnome 3 gotchas
On 05/07/2011 01:23 PM, Michael Schwendt wrote: On Sat, 07 May 2011 13:15:11 -0400, CEK wrote: snip It's entertaining already to see how people [try to] leave Ubuntu because of Unity, and to hear that they like Fedora 15's GNOME 3 better. ;) (sorry, going way off topic, but then it seems Gnome 3 has invaded many lists) Yeah...I tried Ubuntu/Unity and didn't care for it at all. Of course that was after experiencing Gnome 3. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xorg-x11 gone squiffy in rawhide?
On 04/21/2011 11:40 AM, Paul Johnson wrote: Hi, Just done quite a big update to my rawhide box, performed a reboot and have been left without an x server. I thought it was the xserver, so downgraded to 1.10.99.1-2.20110418.fc16, but still the same problem. I'm getting a segfault at adress 0xb2b4c using the neuveau driver Help! I'm reduced to using a win7 box TTFN Paul go to these guys from koji (WFM): xorg-x11-server-common-1.10.99.1-3.20110418.fc16.x86_64 xorg-x11-server-Xorg-1.10.99.1-3.20110418.fc16.x86_64 xorg-x11-server-Xephyr-1.10.99.1-3.20110418.fc16.x86_64 -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
On 03/30/2011 07:54 AM, Lennart Poettering wrote: Heya, I just uploaded a new version of systemd into F15, which establishes a directory /run in the root directory. Most likely you'll sooner or later stumble over it, so here's an explanation what this is and why this is. It's a fairly minor technical change, though presumably people consider this a bigger political change, so I guess this deserves an explanation: snip The actual code changes we needed to implement this scheme were trivial (basically, just bind mount /var/run and /var/lock instead of mounting two new tmpfs' to them.), which is why we opted to do this so late in the F15 cycle. However, the political implications are much bigger I guess, so let's see what a fantastic flamewar we can start with this on fedora-devel now. Flame away! Lennart Well, installed the new systemd, udev and dracut and rebooted several times and rebuit the initramfs. Same ol' system (except for populated /run dir), no smoke, no noises, no howling ghosts, etc. Nice quiet change. Now to enjoy the flame war, it was kind of quiet on the fedora front. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Alpha impressions
On 02/27/2011 09:55 AM, Mike Chambers wrote: snip I used to be able to hover my mouse over the time and at least it would tell me the date instead of having to click on it just to see it. try: $ gsettings set org.gnome.shell.clock show-date true -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110129 changes
On 01/29/2011 09:21 AM, Jason L Tibbitts III wrote: New package: ghc-process-leksah-1.0.1.4-2.fc15 Haskell process-leksah library Is it not possible to try a little harder to write a useful package summary? Or for the package reviewer to take just a quick look and notice that a summary such as that is pretty much completely useless? - J Yes, please. Also, new upstream version as the only summary is not useful either. Can't the summary part be automated so the maintainer pushing the change can get the change logs as part of the update process? Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110129 changes
On 01/29/2011 10:58 AM, Orcan Ogetbil wrote: On Sat, Jan 29, 2011 at 9:34 AM, Clyde E. Kunkel wrote: On 01/29/2011 09:21 AM, Jason L Tibbitts III wrote: New package: ghc-process-leksah-1.0.1.4-2.fc15 Haskell process-leksah library Is it not possible to try a little harder to write a useful package summary? Or for the package reviewer to take just a quick look and notice that a summary such as that is pretty much completely useless? - J Yes, please. Also, new upstream version as the only summary is not useful either. By summary, do you mean the %changelog entry? That entry represents the changelog of the specfile/srpm, which is different than the changelog of the software. While it is perfectly fine to write new upstream version to the %changelog of the specfile, the software changelog can (and perhaps should) go to the Notes section in bodhi. Orcan Well, I guess I mean the changelog of the software. Especially when it is a new upstream version. There just needs to be more information for the new versions so a user can anticipate a potentially changed environment. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging 20s pause in boot time in rawhide
On 01/16/2011 02:32 AM, Jason D. Clinton wrote: There's a twenty second pause in my boot sequence, shown below, before GDM starts and I'm not certain if it's in NetworkManager waiting on org.bluez, bluez itself or the bluez systemd unit file. (Or maybe I'm completely off.) Later on, the bluetooth.service starts normally and Bluetooth is working normally. Any ideas how to debug this? snip Maybe https://bugzilla.redhat.com/show_bug.cgi?id=668633 Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot hang at the loopback interface in rawhide?
On 01/13/2011 10:59 PM, Matthew Miller wrote: For some reason, boot is hanging with today's rawhide update -- I get stuck at Bringing up loopback interface. Oddly, if I boot into runlevel 1, lo is there just fine. (But if I telinit 5 from there, it immediately tries to bring it up again and hangs.) Is anyone else seeing this or is it a one-off quirk? May be sytemd starting both NetworkManager.service and network.service instead of just one or the other. See: https://bugzilla.redhat.com/show_bug.cgi?id=668633 Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)
On 12/09/2010 08:59 AM, Jiri Moskovcak wrote: snip - debuginfo-install is just a fallback if ABRT fails to retrieve the debuginfo itself (and ABRT doesn't need the root privs, as is *does not* install the packages, it just unpacks them) snip Jirka Currently, abrt says the debuginfo packages are missing, but doesn't download any and does not allow me to download them. Used to be a msg about what the download cmd should be. This is rawhide, up-to-date. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 12/02/2010 02:25 PM, Adam Williamson wrote: On Thu, 2010-12-02 at 14:10 -0500, Doug Ledford wrote: My package in question (mdadm) is only used in certain circumstances, but if it isn't right, systems fail to boot. I can certainly see why something that can render a machine unbootable should be critpath. However, because only a few people use it, testing is sparse at best. I think probably more people use it than current testing indicates, and we should do a better job of getting more people involved in testing. I'll get one or two testers actually testing the package, but I won't know until a release is made whether or not it truly works for the masses because it isn't until then that I hit enough critical mass to know. That being the case, I test the package fairly rigorously myself. But this process doesn't take that into account. I test far more things than you get with a few people just doing smoke tests, but the smoke tests are actually the gating factor. If you changed the process so a maintainer can indicate they've done their own fairly extensive testing, that would satisfy me. But that also opens the door for abuse, so you would have to watch maintainers once you enabled this ability. I've posted in the thread earlier that I'd actually like to do this, others seem opposed however. What about putting the maintainer's tests somewhere a tester can get them and use on their own system(s)? Maybe even require critical path packages to actually provide test cases. This is not to say we don't believe the maintainer, it is just a validation that the package passes reasonable testing of the actual changes. I continue to be frustrated by not being able to always test the actual change. In most cases all I can do is make sure there are no regressions and then that means all I have done is use the system with the changed package installed and see if anything at all fails. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NFS in rawhide
On 11/17/2010 02:26 PM, Jon Masters wrote: On Wed, 2010-11-17 at 14:14 -0500, Ric Wheeler wrote: snip Yes, thanks Ric, your reply to me was most helpful. Jon. What was the reply? TIA Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 11/12/2010 11:14 PM, Tom Lane wrote: Clyde E. Kunkelclydekunkel7...@cox.net writes: snip The major packages that I work with have regression test suites, which in fact get run as part of the RPM build sequence. It's not apparent to me that I should need to invent some more tests. I did not know that. Good to know. Would it help if the test cases were mentioned so their use could be considered in providing karma? Or, even if they were made available? Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 11/12/2010 02:32 PM, Tom Lane wrote: Till Maasopensou...@till.name writes: snip It's absolutely crystal clear to me that we don't have enough tester manpower to make the current policy workable; it's past time to stop denying that. I'd suggest narrowing the policy to a small number of critical packages, for which there might be some hope of it actually working as designed. regards, tom lane Test cases would help alleviate manpower issues. Many of the security updates and regular updates are outside my area and I feel some frustration that I have to bypass providing karma; however, I am used to doing QA work with test cases. Are they so hard to provide? Maybe certain updates should have test cases, i.e., security updates and critical path updates. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 10/31/2010 03:18 AM, Michael Schwendt wrote: On Sun, 31 Oct 2010 04:37:38 +0100, Kevin wrote: Martin Stransky wrote: there's a new Firefox update waiting in Bodhi and we can't push it to stable because of new rules. We recommend you to update to it ASAP as it fixes a public critical 0day vulnerability (https://bugzilla.mozilla.org/show_bug.cgi?id=607222). Looks like the F13 build got karma quickly enough to land directly in stable after all, the F12 build, on the other hand, was stuck in testing for 2 days before finally making it out to stable. Yet another blatant example of failure of the Update Acceptance Criteria, needlessly exposing our users to critical vulnerabilities. (And no, by giving yet another special exception to Firefox wouldn't be a solution. ;-) This problem can hit any other app as well.) Kevin Kofler Okay, feedback time. Lately, there have been several attempts at urging proventesters (and not just testers in general) to give positive karma for aging critpath updates. It also has been decided by someone (or maybe even a comittee) to spam proventesters daily with [old_testing_critpath] messages for all three dist releases, with no day to unsubscribe from that (other than leaving proventesters group, which is what at least one person has threatened with, or filtering those messages). Dunno about other testers (and there aren't many yet), but I have abandoned F-12 long ago due to lack of time when F-13 became the one to use on a daily basis. And some time before F-14 Beta, my desktop has been switched to boot F-14 by default. That's the only opportunity to evaluate F-14 early and possibly find issues prior to its release. On the contrary, most of Fedora's users will wait for the final release, and many users will wait even longer. It's highly likely that bugzilla can confirm that. F-14 is the the only way forward, and don't like to spend time on F-13 and older anymore. That also applies to packagers I maintain or monitor. I simply don't see the user base [target group] anymore. About positive karma in bodhi, I don't feel comfortable signing off arbitrary updates just because they didn't crash for me after five minutes. With some updates, regression has slipped through already. And the more bugs an update addresses with either patches or a version upgrade, the more careful I would like to be when testing something. Also, in my book, an update working on F-14 may still malfunction on an older dist release due to differences in dependences and the core setup. I still don't understand why some non-security updates are rushed out with sometimes not even the package maintainer(s) having tested them at all. I am willing to work with the older, still supported, distros, but would really appreciate test cases since most of the critical-path bugs the update addresses are not common and I haven't run into them. That said, if the update remains without karma, the release is within a month of end-of-life, then the update could be left in updates testing and docs changed to provide a warning. I don't think there would be that much impact on storage to keep an updates-testing repo around on the mirrors that choose to provide the release. Most just delete the release anyway. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
On 10/05/2010 11:01 PM, Eric Sandeen wrote: snip cool! I suppose I could turn it on in rawhide, or you could just build your own e2fsprogs to get it ... -Eric Cool if you turn it on in rawhide. Helps those of us who are build challenged :-). I can test in raid and LV environments. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
On 10/06/2010 02:01 PM, Eric Sandeen wrote: snip OK gang, it's in e2fsprogs-1.41.12-6.fc15 you have to invoke it with -test options to make it go ;) Word of warning, it's not had a lot of attention, and the whole design could change in the future, but it's something to play with :) -Eric Docs with it? In man pages? Thanks!! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: rawhide now requires systemd to boot by default
On 09/17/2010 02:18 PM, Bill Nottingham wrote: While upstart is still in the repo, the initscripts package now pulls in systemd and systemd-sysvinit. Bill from todays 201009218 rawhide update (bz'd on the yum site as #593): sudo yum --enablerepo=mash --skip-broken update . Updating for dependencies: upstart x86_64 0.6.5-8.fc15 mash 149 k Skipped (dependency problems): initscripts x86_64 9.21-2.fc15 mash 951 k systemd-sysvinit x86_64 10-3.fc15 mash 12 k upstart-sysvinit x86_64 0.6.5-8.fc15 mash 15 k Transaction Summary Upgrade 1 Package(s) Total size: 149 k Installed size: 498 k Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug ERROR with rpm_check_debug vs depsolve: upstart = 0.6.5-8.fc14 is needed by (installed) upstart-sysvinit-0.6.5-8.fc14.x86_64 Please report this error in http://yum.baseurl.org/report You could try running: rpm -Va --nofiles --nodigest -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does the DVD media check if installing a new Fedora version? / Proposal
On 08/13/2010 04:32 AM, Joachim Backes wrote: Hi, having the following question: What does the DVD/CD media check exactly if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media check, because it could be done after having burned the DVD? If not, is it possible to perform this media check immediately after having burned the DVD (means: can I start the media check from that freshly burned DVD?) Proposal: If not, it would be nice if the media checker would be placed on the DVD for running in normal mode after the DVD has burned - perhaps allowing to check both an i386 and x86_64 install DVD. Kind regards k3b has a verify written data checkbox. I use it to check and skip the DVD media check after booting the DVD. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 TC2 x86_64b
On 08/03/2010 07:25 PM, John Reiser wrote: Ok, so this compose seems to have anaconda-14.14. When trying to do an nfs install, once I put in the server/directory information, it shows it connecting and trying to pull up the gui. But after that, my monitor just stays black and nothing ever happens, nor does it seem to react to keyboard cept to do a ctrl+alt+del. Does your video card use the 'radeon' driver for ATI Radeon cards? https://bugzilla.redhat.com/show_bug.cgi?id=596985 hang at start of X11 on fresh install from DVD [2 months old] The workaround is to choose Install with basic video driver. Or, pass nomodeset to the kernel... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
