devel November 2004

devel@lists.fedoraproject.org

287 participants
252 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

autoconf breakage on x86_64.
by Sam Varshavchik 26 Sep '06

26 Sep '06

I don't know the right way to fix this, but something is definitely broken; and something needs to be fixed, one way or the other. The question is what exactly needs to be fixed. Consider something like this: LIBS="-lresolv $LIBS" AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no)) Here's what happens on x86_64: gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5 /tmp/ccW7EeDX.o(.text+0x7): In function `main': /home/mrsam/src/courier/authlib/configure:5160: undefined reference to `res_query' collect2: ld returned 1 exit status configure:5147: $? = 1 configure: failed program was: [ blah blah blah ] | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char res_query (); | int | main () | { | res_query (); | ; | return 0; | } The same exact test on FC1 x86 will work. The reason appears to be that you have to #include <resolv.conf> on x86_64 in order to succesfully pull res_query() out of libresolv.so. You don't need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC does not include any headers, but uses a manual prototype. So, what now?

4 3

DMRaid in Fedora devel
by Mark Wormgoor 19 Apr '05

19 Apr '05

Hi, Attached are three patches that I made to get Fedora-devel to install on a bios sata raid-0 system (Sil 3112 on Abit AN7). It uses Heinz Mauelshagen's dmraid for detecting the disks. The first patch is against Anaconda. It removes the raid disks from the isys disklist and replaces them with the mapper device. The patch requires the full (not enable-mini) dmraid binary in the stage 2 image. I tested the patched Anaconda in install, upgrade and rescue mode (text and gui) and had no problems on my system. The second patch is against mkinitrd. It adds /sbin/dmraid.static to the initrd if necessary and updates the initscript. The /sbin/dmraid.static binary is not yet a part of the current dmraid rpm, so you need to provide your own. The third patch is against rc.sysinit so that dmraid.static is run at boot. Again, you need the full dmraid binary under /sbin/dmraid.static (not enable-mini) because the rc.sysinit script uses the testmode first before enabling the mapper devices. I now have a Fedora-devel system booting from my two raid-0 disks. Unfortunately, there is no bootloader for /dev/mapper devices. There is a patch against lilo to make it work on devmapper devices here (http://www.saout.de/misc/) and Eric Agsjö has a patch to make it work with raid-1 devices here (https://www.redhat.com/archives/ataraid-list/2004-October/msg00007.html). I am still using lilo under FC1 (using the medley.o module) and that works for me. I hope someone finds these patches useful; it would be very nice if FC4 would install on and boot from these bios ide raid devices without too much hacking. Kind regards, Mark Wormgoor -- *************************************************************** * |\ /| | /| / Mark Wormgoor * * | \ / | | / | / mailto:mark@wormgoor.com * * | \/ |ark |/ |/ormgoor http://www.wormgoor.com/mark/ * ***************************************************************

2 1

Emacs cvs snapshot packages available
by Jens-Ulrik Petersen 10 Apr '05

10 Apr '05

I finally got round to packaging a snapshot of current development Emacs from CVS. Noone knows when the next actual release of Emacs will be, but there are many new features and changes: improved utf-8 and gtk2 support in particular. See http://people.redhat.com/petersen/emacs/ for more details. Enjoy and please report any problems directly to me (ie not to bugzilla or the emacs-devel list:), Jens

4 5

Improving security
by Hans de Goede 19 Jan '05

19 Jan '05

Hi, I just read this interesting article on lwn: http://lwn.net/Articles/106214/ (lwn subscriber only) This talks about things like: 1 Stack Smash Protection 2 PAX (alternative Exec Shield) 3 Position Independent Executables. Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier. PAX uses tricks to get a non executable stack, and assignes random addresses to PIE executables, which Fedora already has in the form of Exec Shield, good! But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into. PIE we already have, good! Regards, Hans

5 8

ia32e, er EM64T that is...
by Jesse Keating 22 Dec '04

22 Dec '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What are the chances of getting an ia32e specific kernel in the x86_64 version of Fedora Core 3? We're starting to ship Nacona based systems, and we have always done Fedora Core pre-installs. While the x86_64 kernel of FC2 works now, I thought it was in some sort of 'compatible 64bit' mode rather than ia32e or em64t specific mode. I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBPJpX4v2HLvE71NURAgLOAJ41i+nTykxeQlOs+SG0Lxu297RM/gCfQ30X DzP7D/wWGZN0T8LiXAlZFpY= =7oGl -----END PGP SIGNATURE-----

6 11

Some encryption-related projects
by W. Michael Petullo 08 Dec '04

08 Dec '04

I have several encryption-related projects that I like to advertise on this list every once in a while in hopes of attracting interested developers or testers. Since we are just beginning work on Fedora Core 4, now seemed like a good time to mention them. 1. Encrypted swap. This is a prerequisite for many different disk encryption techniques. See [1] for a good example of why this is necessary (potential shortcoming of Apple's FileVault). See Red Hat bug #127378 for some discussion about this, including a proposed patch for initscripts. The patch has not been scrutinized very much yet, so is only meant to encourage discussion at this point. 2. Encrypted root filesystem. Red Hat Bug #182479 discusses adding support for an encrypted root filesystem to Fedora. The bug contains a patch for mkinird that facilitates this. Eventually it would be nice to see support in anaconda for this, but #182479 is the first step. 3. Pam-keyring. The pam-keyring PAM module unlocks a GNOME keyring for a user using that user's login password. The idea behind pam-keyring is to make using GNOME keyrings as transparent as possible. Pam-keyring is available at http://flyn.org/projects/pam_keyring/index.html. 4. Command line gnome-keyring tool. GNOME bug #155681 proposes an addition to gnome-keyring. The gnome-keyringtool utility is a program that manipulates keyrings from the command line. I originally wrote gnome-keyringtool so that it could be assigned SELinux privileges and used by pam-keyring. This avoids assigning additional privileges to various login programs. 5. Automounting encrypted removable filesystems. I would like to see encrypted removable filesystems handled as transparently as other removable media. Red Hat bug #133461 discusses this a bit. I have done some experimentation with this and have a prototype working. However, my work contains a large kludge to get HAL to acknowledge dm-crypt filesystems properly. Documentation of this shortcoming may be found at http://freedesktop.org/pipermail/hal/2004-September/001051.html and http://marc.theaimsgroup.com/?l=linux-kernel&m=109937418210973&w=2. [1] Archive of bugtraq mailing list message: http://securityfocus.com/archive/1/367116/2004-06-24/2004-06-30/0 Date: 06/25/2004 Subject: Mac OS X stores login/Keychain/FileVault passwords on disk Author: Matt Johnston -- Mike :wq

4 4

Elektrified X.org released (was: X configuration paradigm, and a proposal)
by Avi Alkalay 08 Dec '04

08 Dec '04

For people that still don't know the Elektra Project (http://elektra.sourceforge.net), it provides an alternative back-end for text configuration files. So instead, for example, the human-readable-only xorg.conf file, we'll have a hierarchy of key/value pairs easily and precisely accessible by X.org and also any other programs through an API or command, and human beings too. Same concept as GConf, but designed for system-wide use. We've been working on X.org source code to do exactly what we just described above. And it is ready for use, tested even with very complex X.org configurations. A patched X server will convert your xorg.conf file automatically, even the most complex ones, including non-documented parameters. It is available at http://sourceforge.net/project/showfiles.php?group_id=117521 http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136… You'll find there the patch against X.org source, the patch against Fedora Core 3 RPM spec file (to see how to build it), and the README file, which is pasted in this e-mail bellow. We'll write patches for other software, and everybody is invited to join this integration effort. Thank you, Avi Alkalay Elektra Project <http://elektra.sf.net> ----------------------README------------------------- ELEKTRIFIED X.ORG: PRECISE AND PROGRAMATICALY EASY X CONFIGURATION Your X server has to work with your installed video card, monitor, find your font server and dirs, modules, extensions, drivers, plugins. You have to tell him how to integrate it all through its xorg.conf file. If you need to change something, you start a text editor and use your human brain and eyes to find the correct line, understand it, have the skills to change it, and change it in order to work. This is good for advanced technical guys, but very bad for people that don't have this skills, and in fact, don't really want to. He just wants to change the screen resolution to make that projector work with his laptop, and go ahead with his sales presentation. This is just an example. The point is: it is very difficult to make simple programs or scripts that make simple changes to X configuration. Another example is a monitor vendor that wants to support X, and for this he'd like to provide easy installation of his product, without having to ask his user to read documentation about horizontal Sync, and vertical refresh rates. For him again is difficult to write some simple software that preciselly changes X configuration to work correctly with his product. The xorg.conf file (as most Unix configuration files) was designed for human beings. The Elektra Project (http://elektra.sourceforge.net) introduces a new way to handle configurations through a clean API (or command line tool) that accesses atomic configuration data, into a standarized hierarchycal tree of key-value pairs. It is similar to GConf, but designed for system-wide use, which also implies it does not have dependencies. And this is what this patch is about: to make the X server look for its configurations into a machine-ready tree of key-value pairs, instead of the human-ready xorg.conf. So where you had to look for "Device radeon" into a "Section Device", with the key/value tree, X and other programs can look for it preciselly at system/sw/xorg/current/Devices/Videocard0/Driver = radeon Where you once had to "vi" your "Section Monitor", now X and other programs can do it accessing the keys: system/sw/xorg/current/Monitors/Monitor0/HorizSync = 31.5 - 48.5 system/sw/xorg/current/Monitors/Monitor0/VertRefresh = 40.0 - 70.0 system/sw/xorg/current/Monitors/Monitor0/ModelName = IBM T40 LCD Panel system/sw/xorg/current/Monitors/Monitor0/VendorName = IBM system/sw/xorg/current/Monitors/Monitor0/Options/dpms Where once the salesman above had to "vi" the Screen Section to change the resolution, color depth, etc, a program can help him accessing: system/sw/xorg/current/Screens/Screen0/Displays/00/Depth=24 system/sw/xorg/current/Screens/Screen0/Displays/00/Modes=1024x768 And so on.... We believe an elektrified X server can leverage more plug-and-play configurations, providing configuration power to HW vendors in a very simple way, and making users experience less painfull. BEHAVIOR OF AN ELEKTRIFIED X SERVER A patched X server will look for its configuration keys under the namespace: system/sw/xorg/current first, then if not found it tries system/sw/xorg If not found, it will default to some xorg.conf file, parse it, and store in its internal structures, then convert and commit it to a set of keys under system/sw/xorg/current, and reload these keys. So you get automatic one-time conversion from xorg.conf to the hierarchycal configuration key/value pairs Very complex examples of xorg.conf files were tested for conversion. Even undocumented configuration parameters (because the original source was used as the reference). The Elektrifyied X server also works for the Red Hat Graphical Boot, where you still don't have mounted partitions, network, etc. ELEKTRIFING X.ORG You'll need the elektra-devel package installed in order to build X with Elektra support. 1. Download and unpack X.org source code from 2. Download the xorg-x11-6.8.1-elektra.patch file from http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136… 3. Apply it: ~/src/xc$ cd .. ~/src$ patch -p0 < xorg-x11-6.8.1-elektra.patch ~/src$ cd xc ~/src/xc$ # ...configure your build in host.def 4. Enable the patch: ~/src/xc$ echo "#define UseElektra" >> config/cf/host.def 5. Build X.Org You'll find the new X server as file xc/programs/Xserver/Xorg . The patch will add the following files: xc/programs/Xserver/hw/xfree86/parser/ elektra.h (exported methods) elektra.c (key fetching and X structs integration business logic) xorg-example.conf (a very complex conf file to test conversion) xelektrify.c (cmd to convert xorg.conf->keys and vice-versa) README.Elektra (this file) And it will instrument xc/programs/Xserver/hw/xfree86/common/xf86Config.c::xf86HandleConfigFile() to trigger the one-time conversion, and key fetching logic. And instrument the Imakefiles for correct builds: xc/programs/Xserver/hw/xfree86/parser/Imakefile xc/programs/Xserver/hw/xfree86/common/Imakefile xc/programs/Xserver/Imakefile If "#define UseElektra" is not present in host.def, the patch is completelly disabled, and you'll get a binary-identicall built as before applying the patch. All patched code are surrounded by #ifdefs. ELEKTRA MEETS X.ORG SOURCE CODE or how we wrote the patch.... X.org has an xorg.conf parser that takes this steps to handle configuration: 1. Lexically parse the xorg.conf file 2. Put each Section info in an equivalent struct 3. Encapsulate all structs together and pass them to a validator 4. Use structs to define X behavior This process is triggered by the xf86HandleConfigFile() method from xc/programs/Xserver/hw/xfree86/common/xf86Config.c Each xorg.conf Section has an equivalent structure defined in xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h and the lexycall analyzer code to parse each Section is under xc/programs/Xserver/hw/xfree86/parser/ A fully parsed file has its equivalent structures encapsulated in a parent XF86Config struct. We have: struct XF86ConfModuleRec for the "Section Modules" struct XF86ConfMonitorRec for the "Section Monitor" struct XF86ConfDeviceRec for the "Section Device" etc... These structs are a pure computer representation of the text in each Section, so the methods under "parser/" convert text to structs, and the structs to text. This is how original X.org source handles xorg.conf. The Elektrification add methods that act in steps 1 and 2 above. And also include methods to convert each struct to a KeySet. Both old (xorg.conf) and new (Elektra) ways to get configuration information can live together and they are actually used to automatically convert xorg.conf to keys. So at the first time you'll run your elektrified X server, it will: 1. Not find configuration keys (because it is the first time) 2. Parse xorg.conf into structs 3. Convert structs to Keys 4. Commit the keys to key database 5. Reload configurations from the key database See the behavior in the previous section. After assembling the XF86Config C structure, X will decode all its info into more practicall parameters for its further operation. As a side note, with a key/value pair configuration hierarchy paradigm, the XF86Config assembling code (the parser) could be avoided, making X look for its configurations in a programatically easier, yet human-readable, configuration organization. We worked at the parser level to keep compatibility and to not go too deep in X.org source code. http://elektra.sourceforge.net The Elektra Project Avi Alkalay November 2004

16 41

adventures in booting
by David Zeuthen 07 Dec '04

07 Dec '04

Hey, So, I've looked a bit more into the booting process and how to optimize it. Mostly based on the discussion triggered by Owen's boot poster challenge, here http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00447.html and also some experiments that I did - basically replacing rhgb with gdm as described here http://www.redhat.com/archives/fedora-desktop-list/2004-November/msg00066.h… What I've done is a bit crude - I've replaced init(1) with a shell script based on /etc/rc.d/rc.sysinit and tried to optimize specifically for my system: IBM Thinkpad T41 laptop with a Pentium M processor at 1600MHz along with 512MB of RAM. The results are pretty good I think, here is the general time line made with a wallclock 00: exit grub; start booting the kernel 04: kernel prints audit() 11: initrd is mounted; Red Hat nash visible mount / ro (normal initrd procedure) 13: start bootchart logging; start readahead of approx 193MB files sleep until readahead is complete 24: readahead done; now create /dev and modprobe (in background) mount / rw, enable swap start xfs startx as user davidz in background start messagebus start hald start acpid start NetworkManager 32: X claims the display 34: GNOME desktop banner 40: GNOME desktop is usable (Nautilus desktop, panel fully populated) Here is a bootchart made with the bootchart software from Ziga Mahkovec: http://people.redhat.com/davidz/bootchart.png You may notice that I also start firefox after login and it starts very very fast - that's because readahead loads all files used by Firefox - in earlier experiments I've also added files from OpenOffice.org to readahead and that meant I could start up OpenOffice.org Writer in about three seconds. More below. I've made the following observations 1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working well for me - it reported far to few files - instead I added a printk() to fs/namei.c:link_path_walk() (disclaimer: I don't know much about the kernel so there may be a better solution than this). 2. The data captured from link_path_walk() was massaged into a list of unique files to preload and sorted on sectors. 3. While capturing the data link_path_walk() and before processing I went through all the menus in the GNOME desktop (to make sure their icon and desktop files would be added to the list) as well as loading Firefox. The list contains 5189 unique files - 231 of these from my home directory - 103 of these from gconf in my home directory and 302 from gconf in /etc. 2267 were .png files and 814 of them were .desktop files. 488 files had ".so" in their name. There was a total of 193MB of files (which says something about the footprint of the GNOME desktop on Fedora :-/) 4. Doing the readahead really helped the time from startx till a usable desktop - less than 10 seconds! 5. Doing readahead on the 5189 files took about 45 seconds on my system, mostly because the files were scattered around the disk. Since I had a spare partition 17GB partition, I did this: a. format spare partition as ext3 b. copy all readahead files to spare partition (193MB) c. copy rest of files from main partition to spare partition (about 9GB) Now the readahead is down to 11 seconds which averages out to be 18MB/s. On the other hand, I can still see (using fileblock) that the files in the readahead is still scattered out and hdparm says I should be able to get 33.87 MB/sec with no seeks. 6. I made a hack to cache /dev (a dev.tar file) and the list of modules to load. This could be used in production if the kernel could give us basically a hash value for the kobject hierarchy representing the hardware (perhaps even a 'tree /sys |md5sum' would suffice). This shaved some seconds of as well. 7. A number of things was started in parallel - I found that doing readahead while running modprobe wasn't helping anything; in fact it contributed negatively to performance (a bit to my surprise, I guess because the kernel was busy). 8. readahead on the right files is A Good Thing(tm). Booting my system without readahead on the partition with the readahead files scattered took 58 seconds (compared to 39 with readahead on the optimized partition) http://people.redhat.com/davidz/bootchart-without-readahead-scattered.png and without readahead on on the optimized partition it took 43 seconds http://people.redhat.com/davidz/bootchart-without-readahead-nonscattered.png again compared to 39 seconds. As an added bonus, the readahead makes sure that e.g Firefox loads fast; all .png and .desktop files are in place for when using the menus. As mentioned, one could put very big apps like e.g. OO.o in the readahead set. So, I think these numbers are good and there's still some room for improvement; e.g. it takes ten seconds from grub to when the initrd is mounted - surely the kernel can boot faster? It's after all 25% of the time spent from grub until I have usable desktop. The bad thing is that this approach is highly specific to my system (and thus why I'm not posting an RPM with it :-), however I think it clearly shows where improvements should be made; here are some random thoughts a. We should keep track of files being loaded and maintain the readahead fileset as appropriate. printk() doesn't seem like the right solution; perhaps a system daemon using inotify or the kernel events layer is the road ahead? This would enable us to readahead the KDE stuff if the user is e.g. using KDE a lot. b. ext3 should support operations for moving blocks around; e.g. optimize around the readahead fileset - when idle the system should rearrange the files to facilitate faster booting c. the start_udev and kmodule process could be cached as I did above d. The whole init(1) procedure seems dated; perhaps something more modern built on top of D-BUS is the right choice - SystemServices by Seth Nickell comes to mind [1]. Ideally services to be started would have dependencies such as 1) don't start the gdm service before /usr/bin/gdm is available; 2) the SSH service would only be active when NetworkManager says there is a network connection; /usr from LABEL=/usr would only be mounted when there is a volume with that label and so forth. Also, such a system would of course have support for LSB init scripts. (This is probably a whole project on it's own so I'm omitting detailed thinking on it for now) Thanks a lot to Ziga Mahkovec for the bootchart software - it's been very useful. Have fun, David [1] : http://www.osnews.com/story.php?news_id=4711 http://www.gnome.org/~seth/blog/2003/Sep/27

10 23

Fine-tunign of Bluecurve QT theme
by Peter Backlund 07 Dec '04

07 Dec '04

Hello. I've just opened a general bug about the differences between the QT and Gtk Bluecurve styles, with a partial patch. The bug lists quite a few differences that I've found (xmag is your friend!). If there are any QT hackers on the list who are interested in helping out, please take a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141125 Bye, Peter Backlund

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2004