Re: safe way to standby sata hdd?
Michał Piotrowski wrote: 2009/12/16 Eric Sandeen sand...@redhat.com: Michał Piotrowski wrote: Hi, I've got a home database/symfony env/etc../file server. It's based on Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power connected through Sata. First drive has / and /home filesystem, second has /home/samba4. On the first drive there are two directories /home/samba2 and /home/samba3 where I'm mounting ecryptfs. /home/samba4 is also crypted by default. I'm wondering if there is a safe way for such configuration to put second harddrive into sleep (or both drives) after some idle time? After some googling I've found some resolutions (haven't tested any of these yet): - hdparm -S I use this for the data drive on my mythbox. I just put this in my /etc/rc.local - # Spin down in 1 hours idle time hdparm -S 240 /dev/sda Have you used this for a disk with your rootfs? In the past I have, but lately getting the root to actually get idle is just about impossible it seems. I now have an ssd root and don't bother. (yeah, oddly, sda is not my boot drive) :) - sdparm --set=STANDBY - and laptop_tools I'm really not convinced that these methods are safe for my configuration. Anyone have tried this before? Yep. What kind of safety are you worried about? I know that ecryptfs is just fs stack on top of my ext3 partition, but still I care about data integrity. Ok but what does that have to do with spinning down a disk? :) It should just work, although you want a long enough idle time that you're not constantly spinning the disk up and down. Actually /home/samba4 is not mounted all the time - I'm umountig this fs when I'm not using it. I'm wondering if there will be any problems with data integrity when I forgot to umount ecryptfs and disk will be stopped. I don't think so. Any access should just spin up the disk and carry on. -Eric Is there any nice user-friendly frontend to set this? It'd be nice to expose more power management choices to the users (for anything that can't be easily defaulted, that is). -Eric Regards, Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: safe way to standby sata hdd?
Michał Piotrowski wrote: Hi, I've got a home database/symfony env/etc../file server. It's based on Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power connected through Sata. First drive has / and /home filesystem, second has /home/samba4. On the first drive there are two directories /home/samba2 and /home/samba3 where I'm mounting ecryptfs. /home/samba4 is also crypted by default. I'm wondering if there is a safe way for such configuration to put second harddrive into sleep (or both drives) after some idle time? After some googling I've found some resolutions (haven't tested any of these yet): - hdparm -S I use this for the data drive on my mythbox. I just put this in my /etc/rc.local - # Spin down in 1 hours idle time hdparm -S 240 /dev/sda (yeah, oddly, sda is not my boot drive) :) - sdparm --set=STANDBY - and laptop_tools I'm really not convinced that these methods are safe for my configuration. Anyone have tried this before? Yep. What kind of safety are you worried about? It should just work, although you want a long enough idle time that you're not constantly spinning the disk up and down. Is there any nice user-friendly frontend to set this? It'd be nice to expose more power management choices to the users (for anything that can't be easily defaulted, that is). -Eric BTW. I'm using F11 on this system - it appears that I even don't have /etc/hdparm.conf... Regards, Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Extremely Unstable
Brad Longo wrote: I reinstalled Fedora, and also checked the cd I installed from to see if that would fix the problem. I believe the issues I had previously may have been caused by putting /home on its own lvm, which I did not do when I reinstalled. I wanted to do this so I could install future releases without having to erase the home folder. Unfortunately, I don't have the time continue to reinstall Fedora over and over to confirm that putting /home on its own lvm is the source of the issue, but maybe someone else can replicate this? I'd be awfully surprised if this were the root cause. The suggestion to run the failing application from a console, and look for errors on the console and the X log, sounds like the best plan of attack to me. Before reinstalling, the programs that crashed when I tried to edit their preferences were all of the ones I tried: Thunderbird, Empathy, and Mozilla. The automatic bug reporting tool crashed the system when trying to report some of the bugs too. The system was fully update when I was experiencing the crashes. Reinstalling solved all of my problems except one. Keyboard shortcuts are still not saved. However, this issue is trivial compared to the frequent crashes I was experiencing before. oh, ok. Hm, odd. -Eric Brad. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
Dennis J. wrote: On 11/12/2009 04:03 PM, Eric Sandeen wrote: Richard W.M. Jones wrote: ... I'd like to repeat my proviso: I think this test is meaningless for most users. Until users have 8TB raids at home, which is not really that far off ... Let's hope btrfs is production ready before then because extX doesn't look like a fitting filesystem for such big drives due their lack of online fsck. ext4's fsck is much faster than ext3's, and xfs's repair tool is also pretty speedy. Both are offline, but so far online fsck for btrfs is just a goal, no (released, anyway) code yet AFAIK. -Eric Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
Roberto Ragusa wrote: Ric Wheeler wrote: In our testing with f12, I build a 60TB ext4 file system with 1 billion small files. A forced fsck of ext4 finished in 2.5 hours give or take a bit :-) The fill was artificial and the file system was not aged, so real world results will probably be slower. fsck time scales mostly with the number of allocated files in my experience. Allocated blocks (fewer very large files) are quite quick. What kind of machine did you use? With 60TB a simple allocation bitmap for 4k-blocks takes almost 2GB; and this is just to detect free space or double allocation of blocks. Wow. The box did have a lot of memory, it's true :) But ext4 also uses the uninit_bg feature: uninit_bg Create a filesystem without initializing all of the block groups. This feature also enables checksums and highest-inode-used statistics in each block- group. This feature can speed up filesystem cre- ation time noticeably (if lazy_itable_init is enabled), and can also reduce e2fsck time dramati- cally. It is only supported by the ext4 filesystem in recent Linux kernels. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
Gene Czarcinski wrote: ... I am not sure if this is related or not ... During the F12 development cycle, I have done a number of installs on both bare hardware and qemu-kvm guests. In all cases, I have formatted the root (/) partition as ext4. I have noticed that formatting the partition for ext4 seems to take considerably more wall-clock time for ext4 partitions than my previous experience with ext3 partitions. I do not know if this is because ext4 formatting needs to do a lot more work than ext3 or if there is a performance issue. Gene There shouldn't be a big difference, but if you want to do some tests, find a difference, and report back with some times, I'd be interested. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
Frank Ch. Eigler wrote: Gene Czarcinski g...@czarc.net writes: [...] In all cases, I have formatted the root (/) partition as ext4. I have noticed that formatting the partition for ext4 seems to take considerably more wall-clock time for ext4 partitions than my previous experience with ext3 partitions. [...] I have seen the same thing; this sort of thing appeared to help: mkfs.ext4 -O uninit_bg -E lazy_itable_init=1 - FChE lazy_itable_init isn't yet safe, unfortunately, we still need a kernel background zeroing to make it so ... Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in the default config, but I don't think it should be slower than mkfs.ext3 for the same sized disks. You sure your disks didn't just get bigger since the F9 days? :) -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
Dennis Gilmore wrote:
Hi All,
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between 32bit/64bit
or
multilib arches have defines for the appropriate arches. sometimes
incomplete
since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should add.
Dennis
I have hacks like this in e2fsprogs.spec for example:
%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
%{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif
Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
Dennis Gilmore wrote:
On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
Dennis Gilmore wrote:
Hi All,
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between
32bit/64bit or multilib arches have defines for the appropriate arches.
sometimes incomplete since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should
add.
Dennis
I have hacks like this in e2fsprogs.spec for example:
%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
%{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif
Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?
right now you need to define multilib_arches for that to work with my
proposed
changes you could drop your defines and use
%ifarch %{multilib64} %{multilib32}
Right, I was hoping for maybe some macros to make my above mess simpler;
%{do_magic_header_stuff} header1.h header2.h ...
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F-12 upgrade experience with Dell D630
Peter Robinson wrote: Hi All, As the Dell Latitude D630 is one of the more common devices that smolt reports being used by Fedora I thought I'd mention my upgrade experience and issues for F-12. Please do file bugs for any problems you encountered, they -should- get more attention from the correct maintainers that way. Thanks, -Eric Probably the two usual things that people query are grahics and wifi. The model I have has the Intel IWL-4965AGN device which as expected works fine. I'm having a few issues with the nouveau driver with plymouth in that it doesn't work at all but if I remove all the options from the kernel boot line it gets to X and apart from some initial corruption as GDM comes up its OK from there. I have no idea how to debug this. Thankfully the issue with detection of my 2nd screen at 1680x1050 is no longer and it now works great. Laptop screen is 1440x900 and I use to have to run a manual 'xrandr --auto' to get it to detect both resolutions properly and configure it. Probably the most annoying is the breakage of sound. This seems to have every other kernel/alsa/pulseaudio update and was an issue on and off right through F-11 as well so its not exactly surprising but also disappointing that one of the most common devices running Fedora has sound broken on a semi regular basis. Again some pointers in debugging this so it can be fixed by F-12 final would be great. The only other very minor issue I see is that the icon spacing on the gnome panels is massive! Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: ... id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Trouble formatting flash disk
Casimiro de Almeida Barreto wrote: Hello, I have a pendrive (flash memory) which lists in /proc/bus/usb/devices as: ... And I've tried to format it as ext2 (so I can backup my home directory). It happens that no matter what I do (and I've tried almost everything) it formats but no matter what I do when I record a large file (2GBytes) it generates file system inconsistencies. First I thought that perhaps the device was defective. But when I try to write and read it, everything seems to be OK. It even passes badblock -w ... Any suggestions on what may be wrong? Could you take this to the linux-ext4 list? It'd be the more appropriate place for the discussion. It'd be good to know the details of the errors you see, too. Thanks, -Eric Best regards, CdAB -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Trouble formatting flash disk
Casimiro de Almeida Barreto wrote: Em 18-08-2009 15:13, Eric Sandeen escreveu: (...) Could you take this to the linux-ext4 list? It'd be the more appropriate place for the discussion. It'd be good to know the details of the errors you see, too. Thanks, -Eric Best regards, CdAB Yes, if I know where I can subscribe this list. http://vger.kernel.org/vger-lists.html#linux-ext4 -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Running a command in background inside spec file
Murilo Opsfelder Araujo wrote: Hi, how can I run a command in background inside spec file? Thanks. ooh boy, I think the answer is, you don't - why do you need to? -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Till Maas wrote: Hiyas, currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. It might be easily possible in the future to monitor a bunch more packages and create bugs in case there are newer versions available at upstream. Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. Speaking just for myself, I'd be happy to have it automatic for my packages. But wow, who's going to key in all those regexps and keep it up to date? -eric Regards Till [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: potential file-system bug, unison locking issue over ext4
Ahmed Kamal wrote: Hi, I'm probably hitting some bug in F11. I've created the lcktest directory, and date lcktest/date-file to create a simple file inside. Repeated this on a ext3 and a ext4 file-system. Now, this works fine on ext3, but fails on ext4. I tried the same setup on another F11 machine that was upgraded from F10 and hit the same locking bug. The behaviour is below, and a full 'strace -f' in case of ext4 is at http://www.fpaste.org/sZXa/ If you think it's a bug, please file one against the kernel in bugzilla, you can assign it to me. It'd be helpful if you could explain what the test is trying to do, and what might make it fail this way. Thanks, -Eric ** On a EXT3 file-system [...@matrix ~]$ unison -ui text -batch unitest/ ssh://d...@cairo//tmp/unitest/ Contacting server... Connected [tmp/unitest - //matrix//home/me/unitest] Looking for changes Waiting for changes from server Reconciling changes Nothing to do: replicas have not changed since last sync. [...@matrix ~]$ *** Changing to EXT4 file-system [...@matrix tmp]$ unison -ui text -batch unitest/ ssh://d...@cairo//tmp/unitest/ Contacting server... Connected [tmp/unitest - //matrix//tmp/unitest] Looking for changes Fatal error: Warning: the archives are locked. If no other instance of unison is running, the locks should be removed. The file /home/me/.unison/lk0548d63e56f1eba992c46c641772d4a0 on host matrix should be deleted Please delete lock files as appropriate and try again. [...@matrix tmp]$ ls -la /home/me/.unison/lk0548d63e56f1eba992c46c641772d4a0 ls: cannot access /home/me/.unison/lk0548d63e56f1eba992c46c641772d4a0: No such file or directory -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Any asciidoc users?
Todd Zullinger wrote: I'm not sure how widely used asciidoc is around here. Both git and tig use it to build their documentation and have been hit by bug 506953¹. I think this bug may hit many other users of asciidoc as well, making our current packages a bit annoying to use for many projects. If any other asciidoc users have run into spurious 'unsafe: include file' errors since asciidoc was updated to 8.4.5 (F-11 and devel), your help confirming that the patch I posted to the bug report helps and doesn't hurt would be most welcome. (Even if you haven't hit the 'unsafe: include file' errors, your testing would be great.) ¹ https://bugzilla.redhat.com/506953 guilt hit this, but I just passed the --unsafe option to asciidoc to work around it :) -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packages tracked by FEver that need to be updated
Till Maas wrote: Aloas, some of you added your packages to: https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes Unfortunately seems the original author of fever not to be around anymore, e.g. his fedorapeople account is removed/backed-up. Therefore I started to write a new framework to replace it. My tool is not ready to bug you via private mail or create bug reports, therefore I only post the current findings here: Thanks! I wonder, can FEver become part of the Fedora infrastructure, so it's not quite so bus-sensitive? -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
Nathanael Noblet wrote: On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: ... Well their python run script checks for its dependancies, and if not met will do a svn checkout of the right copy, however, they don't keep copies of the libraries within their own repository. So if you fulfill all its dependancies that shouldn't be an issue. Ah, ok - maybe that was it. As for data storage and all that I assume the methods they choose to store data aren't part of the review? Plus that is configurable between a few different choices. Right, as long as it's not putting it in /apple or something it should be fine. FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it seemed like an interesting possibility as well. Looks interesting, however the last release was well over a year ago it seems. Whereas Apple's CalendarServer is likely to receive more constant development. I guess there is a chance the Apple starts adding some features only available in their commercial version I guess... but I'm not sure if that is relevant either... Ok, if it's stagnant then maybe not such a good choice. So would a good start be attempting to package calendar server for F11 along with verifying its dependancies and then getting someone to review it? Yep, just follow the review guidelines... I'm a little curious about the one library that F11 packages (libevent at 1.4.x, where calendar server seems to download a 1.5.x...) Do I repackage libevent as part of my packages to be reviewed? Or simply talk to the maintainer of libevent to see if it can be bumped? On my system the only package that required libevent was something related to nfs... though I guess there could be others but I haven't checked... Looking at http://monkey.org/~provos/libevent/ there's no mention of 1.5.x on the front page anyway. Where does it get it? steved 'Steve Dickson' ste...@redhat.com owns libevent, you could talk w/ him. Starting w/ rawhide may be easier. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
Nathanael Noblet wrote: Hello, So I've been toying with the idea of getting more involved with fedora. Up till now if there has been a bug or other issue, i'll file a bug or simply get the srpm and try to update it to a newer version, or create my own specs / rpms when they don't already exist. Lately I've figured that I should get more involved with some of the packages that I use or anything like that. The packaging guidelines kinda describe entry to the packager group as being done via new packages. I've offered to try to help on some recently orphaned packages. Though that may be more work than just submitting a new package. So after all that rambling, I'm wondering about the two following pieces of software. Apple's Calendar Server. It runs using python 2.5 or greater (I've installed it on a F11 machine and it work well). I've started looking at some of its dependancies. 90% of them are in fedora already, and of the ones in F11, only one if I remember correctly isn't at the version it requires). It seems like a great addition to Fedora if you ask me. So basically it would require two new packages, and an update to one other package (libevent) which is a minor version bump it seems if at all needed. I'd love to see a calendar server in Fedora, though TBH when I looked at Apple's long ago it was a bit daunting; it seemed like one of those cross-platform hacks that is very much -not- nicely integrated with the OS (I don't remember the details; weird file hierarchies or private copies of libraries or ...?). Maybe it's better now. But if not, that may be a hiccup. But I'd say give it a shot. I'd help test it. :) FWIW I looked at DAViCal (http://rscds.sourceforge.net/) too and it seemed like an interesting possibility as well. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
Miroslav Lichvar wrote: I'd like to update readline to the latest version 6.0. The problem is that the license was changed to GPLv3+ and we have some GPLv2 packages using readline. A possible replacement is the editline library which provides a compatible interface and is licensed under BSD, unfortunately it doesn't handle UTF-8. Are we stuck with readline 5.2? Suggestions? The package list is: latest xfsprogs uses libreadline too (it can also be configured to use editline) -Eric GMT-4.4.0-2.fc11 Macaulay2-1.2-4.fc12 afpfs-ng-0.8.1-2.fc11 bti-015-1.fc11 calc-2.12.2.1-13.fc11 callweaver-1.2.0.1-3.fc11 cgdb-0.6.4-4.fc11 chrony-1.23-5.20081106gitbe42b4.fc12 clisp-2.47-3.fc11 coda-6.9.4-2.fc11 devtodo-0.1.20-3.fc12 fityk-0.8.1-14.fc10 gnu-smalltalk-3.1-5.fc12 gnubg-0.9.0.1-7.fc11 gnuplot-4.2.5-4.fc12 grass-6.3.0-12.fc11 kdeedu-4.2.95-1.fc12 ktechlab-0.3.70-1.20090304svn.fc11 lvm2-2.02.48-1.fc12 maxima-5.18.1-3.fc12 ocfs2-tools-1.3.9-10.20080221git.fc11 socat-1.7.0.0-2.fc11 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Getting MD5 sum mismatch errors unpacking rawhide on FC9
Philip A. Prindeville wrote: Grrr... that would cause all sorts of other things to be brought in. I just need to rebuild certain Rawhide or FC11 packages for FC9. Is there an easy way to do this using mock? -Philip rpm -i --nomd5 blah.src.rpm rpmbuild -ba blah.spec -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Getting MD5 sum mismatch errors unpacking rawhide on FC9
Eric Sandeen wrote: Philip A. Prindeville wrote: Grrr... that would cause all sorts of other things to be brought in. I just need to rebuild certain Rawhide or FC11 packages for FC9. Is there an easy way to do this using mock? -Philip rpm -i --nomd5 blah.src.rpm rpmbuild -ba blah.spec -Eric or maybe rpmbuild -bs blah.spec and mock build the resulting src.rpm -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads Up: e2fsprogs library split-out
There have been a few requests to split out the various libraries in e2fsprogs into subpackages: libcom_err(-devel) libss(-devel) libuuid(-devel) Note that libblkid(-devel) has already been split out as it is now part of util-linux-ng (thanks to kzak!) - an email was sent previously about that. The following packages have BuildRequires: on e2fsprogs-devel, so depending on what libs they required from the package, they may need to shift to one of these new subpackages when they go in (hopefully today or tomorrow). I'll send another follow-up mail when it's done. Thanks, -Eric aconway: qpidc aconway: rhm anaconda-maint: anaconda atkac: dump ausil: silo bpepple: evolution-brutus bpepple: libepc cmadams: ufiformat danms: libvirt-cim dcbw: NetworkManager deji: gparted deji: mpich2 deji: nautilus-actions denis: k3d drago01: fsarchiver dwmw2: yaboot ensc: util-vserver gavin: squeak-vm green: lash grenier: testdisk harald: readahead ianweller: lordsawar itamarjp: reiserfs-utils ivazquez: mod_dnssd ixs: e2tools jgranado: parted jnovy: mc jorton: apr jorton: apr-util josef: btrfs-progs jwboyer: jfsutils karlik: gmediaserver kasal: pmount kraxel: xenner kwizart: libewf kzak: util-linux-ng laxathom: gnubversion lvm-team: cryptsetup-luks mbarnes: samba4 mfasheh: ocfs2-tools mitr: usermode mjakubicek: ext3grep nalin: krb5 nhorman: coda nhorman: pam_kcoda oget: muse orphan: luks-tools ovasik: inn ovasik: quota ovasik: star pbrobinson: gupnp pbrobinson: gupnp-tools pbrobinson: rygel rcritten: ipa rishi: anjuta rjones: zerofree rstrode: gnome-utils ruben: gearmand salimma: Io-language sandeen: e2fsprogs sandeen: xfsdump sandeen: xfsprogs sindrepb: gtranslator spot: ntfsprogs ssp: libSM steved: nfs-utils steve: qtparted sundaram: gnote tbzatek: libarchive tgl: postgresql xris: dar -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads Up: e2fsprogs library split-out
Bill Nottingham wrote: Eric Sandeen (sand...@redhat.com) said: libcom_err(-devel) libss(-devel) libuuid(-devel) Note that libblkid(-devel) has already been split out as it is now part of util-linux-ng (thanks to kzak!) - an email was sent previously about that. The following packages have BuildRequires: on e2fsprogs-devel, so depending on what libs they required from the package, they may need to shift to one of these new subpackages when they go in (hopefully today or tomorrow). I'll send another follow-up mail when it's done. Any chance that in the interim, e2fsprogs-devel could Require: these new split out packages (if it doesn't already)? For now it only requires libcom_err-devel, from inspection it looks like that's the only set of headers that the e2fsprogs-devel headers include ... I could do this though - but when would it get removed again; would it be better to go with the short sharp shock and just clean it up in the early phase of F12? :) It doesn't much matter to me either way, though, really. Thanks, -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
Casey Dahlin wrote: On 06/29/2009 03:48 PM, Peter Lemenkov wrote: 2009/6/29 Matthias Clasen mcla...@redhat.com: Hey all, we'd like to announce the 'Fit and Finish' initiative for Fedora, http://fedoraproject.org/wiki/Fit_and_Finish with the goal to improve the user experience of the Fedora desktop. If you wish to improve *user* experience, then you should focus entirely on actual Fedora releases rather than on Rawhide. However I see that in testing days you still encourage only users with up-to-date Rawhide installations. That's not an option for wide audience, and, therefore this initiative will be doomed. These aren't typically the sort of issues you can fix in a running release. UI is one of those things we expect to remain stable through the cycle. Woe to he who removes the bugs the user has gotten used to. You could always test F11 and fix in F12, of course. Best of both worlds? -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why a multilib wrapper for non-multilib architectures?!
Rex Dieter wrote:
Tom Lane wrote:
Personally I don't use multilib wrappers on arches that don't need it;
I think not needing extra cases in the wrapper header outweighs the
added complexity in the specfile. But I'm not going to tell the gmp
maintainer he's wrong for doing it the other way.
+1
-- Rex
Heh, so I have it both ways in my packages, xfsprogs does it only for
(hand-defined) %{multilib_arches}, e2fsprogs does it for all, inherited
via cut and paste.
If someone who cared provided some nice rpm macros to work with, perhaps
we'd easily have the best of both worlds. :)
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
Eric Springer wrote: 2009/6/12 Christoph Höger choe...@cs.tu-berlin.de: Without knowing how exactly the benchmark works I would guess that most of those apache requests are kernel calls so SELinux _might_ make a huge difference here. Shouldn't be overly hard to test as phoronix-test-suite is available in Fedora's repository. I'd run it, but my system at the moment won't play nicely with SELinux. Perhaps somebody from the SELinux team should tell phoronix about it (and to _always_ test with SELinux disabled to measure the price of security). Would kind of defeat the purpose of out of the box benchmarking of the distros. Just like how phoronix didn't change Ubuntu's filesystem to ext4 when comparing it against Fedora. True, though over and over again I see things where I wish they'd at least dig into the discrepancies they find, rather than just reporting numbers. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
Xose Vazquez Perez wrote: All Phoronix Test Suite[1] tests run in *local* host. NO net. Basically the apache test do: download http://archive.apache.org/dist/httpd/httpd-2.2.11.tar.gz and http://www.phoronix-test-suite.com/benchmark-files/apache-ab-test-files-1.tar.gz then compile apache ; exec it and run ab: $ ab -n 50 -c 100 http://localhost:8088/test.html So they are grabbing some upstream vanilla version of apache, building -it- and benchmarking -it- on ubuntu and f11 and comparing the results. I don't know much about apache but I bet a default ./configure winds up with different builds depending on the build environment, which in this case is probably dictated by whatever the default generic OS intall contains. And this is useful how? Geez. Me, I'd rather know how -Fedora's- httpd fares against -Ubuntu's- httpd, but maybe I'm just nuts. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
James M. Leddy wrote: On 06/11/2009 02:17 PM, Eric Sandeen wrote: True, though over and over again I see things where I wish they'd at least dig into the discrepancies they find, rather than just reporting numbers. Seconded, I mean, wtf is this? with the test profiles that stress the system disk, Fedora 11 generally did much better -- in part due to the EXT4 file-system and newer Linux kernel. How much of it was the new kernel, and how much was the filesystem? It's just total speculation. It wouldn't be that hard to run some oprofile while running these tests. It almost makes me want to start a keep phoronix honest blog, we could start with that one bug you opened against their ext4 test (I presume the inaccurate benchmark is still up) It is, though they note the problem and link to my screed on their mailing list ;) It may be better to engage them, though, and try to make the tests more correct, transparent and relevant they do have a lot of momentum. Which makes the crazy stuff hurt even more. :) -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
Jeff Spaleta wrote: On Thu, Jun 11, 2009 at 10:44 AM, Xose Vazquez Perezxose.vazq...@gmail.com wrote: then compile apache ; exec it and run ab: $ ab -n 50 -c 100 http://localhost:8088/test.html So did they use the phoronix-test-suite that is packaged as part of fedora and used fedora packaged apache binaries? Or did they build their own local versions of everything outside of the Fedora build system. They did not test Fedora or Ubuntu's httpd for the httpd test. They built and ran their own httpd from upstream, with a default ./configure; make; make install. If nothing else, the config.log from both builds would be interesting to compare. Knowing if they are testing Fedora built and packaged apache matters a lot in terms of interpretation. wait it's not obvious from the article graph? :) -Eric -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
