devel October 2006

devel@lists.fedoraproject.org

217 participants
201 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

kernel/accounting question ...
by William W. Austin 16 Dec '09

16 Dec '09

(I know that this question might be more reasonable on a kernel list, but a while back I posted the question twice and got no answers.) The acct struct is defined in /usr/include/sys/acct.h includes both ac_io and ac_rw for bytes transferred and blocks read or written, respectively. Fair and good - works (on paper) similarly to unix, solaris, hp-ux, etc. However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw (blocks) are always set to 0 by these two lines: ac.ac_io = encode_comp_t(0 /* current->io_usage */); ac.ac_rw = encode_comp_t(ac.ac_io / 1024); For most purposes, this probably wouldn't be an issue, but I also do extensive performance analysis on several platforms and have written a fairly compresive accounting package (as a wraparound for psacct or as a standalone) including both an improved acctcom and a built-in reporter for it. Does anyone know wby the kernel zero's out the bytes transferred data? (Overhead comes to mind.) Not that it makes a huge differnce for my purposes (I had to write some wraparound code to make a "best-guestimate" about the data I'm missing), but curiosity is bugging me now. When I compile my program on other OS's I get useful data for char and block i/o and I'd like to find out whether there is something obvious that I'm just totally missing here...). Thanks -- william w. austin waustin(a)speakeasy.net "life is just another phase i'm going through. this time, anyway ..."

4 3

Self-Introduction: Denis Ovsienko and /etc/net project
by Denis Ovsienko 24 Oct '07

24 Oct '07

Denis Ovsienko Russia, Moscow Linux system administrator and developer ValueCommerce/Russia I develop /etc/net project (http://etcnet.org) and my goal is to integrate it into Fedora Core. I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux development tree and should soon be seen in 3.0 version. I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too, but i haven't heard from them for last months. My skills include 6 years Linux experience, several programming languages, 5 years of mixed software development and system/network administration and so on, but I guess it's not related much to my goal now. I have reviewed current initscripts buglist. Some bugs are not bugs in /etc/net: #65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop... #75390 it would be nice to tie bandwidth shaping into the networ... #129820 initscripts maclist patch #132252 Request for addition of routing rule config file #132912 No additional IP addresses at ethX without aliased devices #132925 initscripts use old ifconfig instead of iproute2 #154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup... #168990 No ifup-gre/ifdown-gre scripts. #170884 MTU of ethernet card can't be set before interface is up #171763 Enhancement to initscripts Some bugs gave me ideas how to improve /etc/net: #59114 .d-style scripts for ifup/ifdown #119952 RFE: Add hook for "local" network initialization #124045 Support setting a metric on interface routes The whole process, if we don't face some unexpected problems, should take 3 to 6 months. What I need: 1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages. 2. Probably some help with documentation. How can we start? pub 1024D/6D1844F2 2002-11-11 Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2 uid Denis Ovsienko <linux(a)pilot.org.ua> uid Denis Ovsienko (http://pilot.org.ua) <pilot(a)altlinux.ru> sub 2048g/57B7ACBE 2002-11-11 -- DO4-UANIC

10 17

anaconda update time needs to be improved
by dragoran 22 Feb '07

22 Feb '07

Hello I have updated 3 boxes from FC5->FC6 (x86_64) using anaconda (booted from a DVD). All three of them is nothing that can be called a slow machine: 1) AMD64 3000+ @ 4100+ (2.61ghz) 1024MB RAM 7200 RPM 2MB Cache IDE Seagate HDD 120GB 2) Laptop: Core 2 Duo T7400 2x2.17Ghz 4MB shared L3 Cache 2048MB RAM 7200 RPM 8MB Cache SATA Hitatchi HDD 80GB 3) AMD Opteron 170 @ 2x2.7Ghz 2048MB RAM 2x120GB Hitatchi SATAII HDD 8MB Cache MD RAID0 Update time was ~90-120min depending on the sys. Why does the update take that long? A reinstall is much faster.. I think that improving this should be a goal for FC7 Also why isn't it possible to install from a md raid partition? Should I fill a RFE?

9 12

[offtopic] Ignacio Vazquez-Abrams
by Arthur Pemberton 09 Jan '07

09 Jan '07

Hi guys, I apologize ahead of time for the offtopic nature of this thread, and if desired, I will cease any continuation. Threads over on fedora-extras-list have brought my attention to the e-dissappearance of one "Ignacio Vazquez-Abrams". This guy has helped me out many times over of #fedora, and was always online, despite me changing time zone twice - to the point where I asked if he was a bot. He seemed to have also had a large load in package maintaince. Fedora being partly about the community, I have to ask: does anyone know what happened to this guy? His online presence seems to have simply ceased as of May-2006. I searched Gmail for emails from him, the last was in May. His blog (http://www.ivazquez.net) seems also to have gone quiet as of May. Just felt that the guy has helped me enough to at least care if he suddenly died or something. Peace. -- To be updated...

15 23

Move Evolution to Extras?
by David Woodhouse 03 Jan '07

03 Jan '07

Evolution is fairly much broken in FC5, and there's little movement even on the 'this mail crashes Evolution' bugs, let alone the "Evolution is totally unusable with IMAP" bugs. What are we going to do about it? One option might be to move it to Extras in the hope that someone will actually start to look after it there. Or perhaps just drop it entirely? Any better ideas? Volunteers? -- dwmw2

64 174

ifup-ipsec: Manual v. Automatic keying
by Bojan Smojver 26 Nov '06

26 Nov '06

Disclaimer: I know bugger-all about IPSec. I looked through this script in devel and it appears that it does something like this (among other things) when using setkey -c: ------------------------------ spdadd $SPD_SRC $SPD_DST any -P out ipsec ${SPD_ESP_OUT:+esp/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require} ${SPD_AH_OUT:+ah/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require} ; spdadd $SPD_DST $SPD_SRC any -P in ipsec ${SPD_ESP_IN:+esp/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require} ${SPD_AH_IN:+ah/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require} ; ------------------------------ The HOWTOs (located here: http://lartc.org/howto/lartc.ipsec.automatic.keying.html and here: http://www.ipsec-howto.org/x299.html) mention only the ESP bit in relation to automatic keying, but not the AH bit. From the HOWTOs: ------------------------------ #!/sbin/setkey -f flush; spdflush; spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require; spdadd 10.0.0.11 10.0.0.216 any -P in ipsec esp/transport//require; ------------------------------ ------------------------------ #!/usr/sbin/setkey -f # # Flush SAD and SPD flush; spdflush; # Create policies for racoon spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec esp/tunnel/192.168.1.100-192.168.2.100/require; spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/192.168.2.100-192.168.1.100/require; ------------------------------ FC5, that I'm using for my IPSec to PIX connection, is similar to devel (i.e. it has the AH bits in spdadd). Anyone on the list knows why the discrepancy? The HOWTO method lets me establish a tunnel to PIX. The one from the script does not... -- Bojan

2 4

Driver disks for FC6
by Gregory Maxwell 14 Nov '06

14 Nov '06

Is there a driver disk for FC6 example anywhere? The driver disk layout changed a few revisions ago and I had a lot of trouble building one for FC5. Now that FC6 has come around I'd like to avoid pulling my hair out again. I need to make a disk for the Arcea driver, arcmsr, which has finally gone into the upstream kernel (as of 2.6.19-pre1). Hopefully FC6 will upgrade to a kernel containing this driver soon, but to get it installed, I'll need to make a disk. It looks like compiling the driver outside of the tree against the kernel in FC6 shouldn't be hard... but I'm worried about figuring out the driver disk layout all over again. ... (well that and finding a working floppy disk drive.. ugh)

6 13

State of multilib development update
by Hans de Goede 04 Nov '06

04 Nov '06

Hi all, Some time ago I send the message below, I've now filed bugs left and right and I'm posting this again with the BZ url's for those interested. --- Yesterday I tried to build i386 rpms on my x86_64 using the new multilib-devel packages instead of resorting to an i386 chroot. Although we have come a long way to making this possible there are still a few issues which makes doing this very hard: 1) gcc ignores setarch ====================== "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64 system as expected however, "setarch i386 gcc -o hello helloworld.c" also creates an x86_64 elf file instead of an i386 one, to get an i386 one I must do: "gcc -m32 -o hello helloworld.c". This is unfortunate, because even though rpmbuild adds -m32 to the *FLAGS environment variables things still don't for many packages, because they for example often ignore LDFLAGS, thus not specifying -m32 when linking, causing things to fail. A work around is to create shell script wrappers for gcc, g++ and ld which always add -m32, put these somewhere outside the standard $PATH and add the location to PATH when you want to build i386 binaries. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212520 (which got closed as not a bug, as I was already afraid). 2) rpmbuild ignores setarch =========================== "setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo, I know "rpmbuild --target i386" works better but still has issues, for example libdir is still set to /usr/lib64, this is already in bugzilla. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194123 3) pkgconfig ignores setarch ============================ I thought that pkgconfig was supposed to get this right and hence it was used to implement verious replacement foo-config scripts, but pkgconfig doesn't get this right. When testing I had only libpng-devel.i386 installed not the x86_64 version: --- [hans@shalem ~]$ pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found --- Behaves as expected, since it searches /usr/lib64/pkgconfig where there is no libpng.pc --- [hans@shalem ~]$ setarch i386 pkg-config --cflags libpng Package libpng was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng.pc' to the PKG_CONFIG_PATH environment variable No package 'libpng' found [hans@shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc -> libpng12.pc --- Does not behave as expected, it should search /usr/lib/pkgconfig and find libpng.pc This can be worked around by doing a "export PKG_CONFIG_PATH=/usr/lib/pkgconfig" BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212522 4) rpmbuild lets x86_64 packages satisfy BR's when building for i386 ==================================================================== The subject says most of it, when doing an rpmbuild --target=i386 I don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel . I know things aren't that easy because with something like BR: desktop-file-utils, the x86_64 version will do fine. Suggestion: make rpmbuild check the arch of BR's who's name ends with -devel. BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212523 5) xxx-devel.arch should require xxx.arch not just xxx ====================================================== When I install libXt-devel.i386 I expect it to drag in libXt.i386 and not to be happy with the already installed libXt.x86_64 . This will also stop some polution with i386 packages of x86_64 system, because currently we have the following scenario: libXt-1.0.2-3.fc6.x86_64 is installed Users does "yum install libXt-devel.x86_64" Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64, which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the x86_64 version of libXt and as an added bonus also install the i386 version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64 BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212524 Let me know what you think & Regards, Hans

4 4

Propose Emacs 22 for Fedora Core 7
by Leo 03 Nov '06

03 Nov '06

Hi there, I'm a big fan of Emacs and I like to build Emacs from source. So whether FC7 is gonna have Emacs 22 does not concern me much. However I think it is important to have this modernized powerful tool available to our current and prospective Fedora users. As we know RMS is extremely strict on fixing bugs, Emacs 22 has long passed the production quality while still in development. A few days ago, Emacs's developers have decided to enter pretest¹. As it is in the early stage of FC7 cycle, I'd propose we upgrade to Emacs 22. The News is just too big for this mailing list, but you can read it here: http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/etc/NEWS?root=emacs A few highlights: - much improved Unicode support - Gtk2 menu, toolbar and scrollbar - Gnome style icons - Tons of add-on packages (calc 2.05, Gnus 5.11, ido etc) Footnotes: ¹ http://permalink.gmane.org/gmane.emacs.devel/61249 -- Leo

5 6

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 October 2006