devel May 2007

devel@lists.fedoraproject.org

292 participants
281 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 17 Dec '09

17 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

acctcom for linux
by William W. Austin 17 Dec '09

17 Dec '09

I recently made several updates to a Linux version of of acctcom (actually another accounting add-on package) which I've been using for several years, and one of the people testing it asked a question which I cannot answer. I'm hoping that someone on this list can give me some info. I have previously (over a year ago) asked on both this and a couple of kernel lists (several times there) about this issue, but nobody has ever answered. So if you have any info about this, I'd really appreciate it. As in many (all?) previous Linux kernels, the struct acct (defined in /usr/include/sys/acct.h) has members ac_io and ac_rw which are presumably counts of characters transferred and blocks read/written respectively. However, in the kernel code, the ac_io is set to 0 and the ac_rw gets set to (ac_io/512) or some such - it is set to 0 as well (and thus these are always reported as 0 in process accounting records. not good if you're trying to measure them...). Does anybody know why this is done that way? A long time ago (IIRC late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the kernel code but was not successful (I finally produced a bootable kernel, but it was unstable. Then I changed jobs, got swamped at work, and eventually gave up). As I said above, I have previously asked about this issue without success, and I have essentially given up changing or "fixing" it. But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's just too much work for too little added value), I'd really appreciate knowing the reason. Curiosity and the cat and all that ... Thanks - Bill -- william w. austin waustin(a)speakeasy.net "life is just another phase i'm going through. this time, anyway ..."

3 2

Any way to search all .spec files?
by Orion Poplawski 26 Mar '08

26 Mar '08

Is there any was to do a grep/search on all of the Fedora .spec files for a specific release (or devel)? I'd be fine with checking them all out if there was a way to just the the spec files for a specific release. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

4 5

Re: Firefox 3
by Takanori MATSUURA 14 Nov '07

14 Nov '07

Hi all, I put firefox-trunk SRPM based on current fedora rawhide one at http://homepage2.nifty.com/t-matsuu/install-memo/fc/ Notice: this package breaks the dependency against devhelp and yelp. Janina Sajka <janina(a)rednote.net> wrote: > Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere > near ready for prime time, but I have a compelling reason to start using > ff3 fairly soon and would rather install from rpm, of course. > > BTW: My compelling reason is that FF3 will contain a11y support that > should prove superior to any yet seen on any platform. Fingers crossed, > etc ... MATSUURA Takanori

8 13

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

25 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

koji weirdness
by Hans de Goede 06 Jul '07

06 Jul '07

Hi all, I'm working on updating libgda + libgnomedb to 3.0.x for F-8 / future rawhide (more on that later) and yesterday evening before going to bed I queued a build of libgda-3.0.1, which completed successfully. This morning I build libgnomedb-3.0.0, which correctly got its buildroot populated with the fresh libgda-3.0.0 . So next I tried to build gnumeric against the new libgda + libgnomedb, but populating the root failed with: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/dist-f8-build-5517-1020/root resolvedep 'intltool' 'pygtk2-devel >= 2.6.0' 'libgnomeprintui22-devel >= 2.8.2' 'libgnomedb-devel >= 3.0.0' 'python-devel' 'scrollkeeper' 'gettext' 'automake' 'desktop-file-utils >= 0.9' 'libgnomeui-devel >= 2.4.0' 'libgsf-gnome-devel >= 1.13.2' 'goffice-devel >= 0.2.0' 'libtool' 'autoconf' 'guile-devel' 0:intltool-0.35.5-3.fc7.x86_64 0:pygtk2-devel-2.10.4-2.fc7.x86_64 0:libgnomeprintui22-devel-2.18.0-1.fc7.x86_64 1:libgnomedb-devel-1.9.100-15.fc7.x86_64 0:python-devel-2.5-12.fc7.x86_64 0:scrollkeeper-0.3.14-11.fc7.x86_64 0:gettext-0.16.1-8.fc7.x86_64 0:automake-1.10-5.noarch 0:desktop-file-utils-0.12-4.fc7.x86_64 0:libgnomeui-devel-2.18.1-2.fc7.x86_64 0:libgsf-gnome-devel-1.14.3-4.fc7.x86_64 0:goffice-devel-0.2.2-1.fc7.x86_64 0:libtool-1.5.22-11.fc7.x86_64 0:autoconf-2.61-8.fc7.noarch 5:guile-devel-1.8.1-3.fc7.x86_64 Notice how it says its going to include libgnomedb-devel-1.9.100, not 3.0.0 and then: Error: Missing Dependency: libgda-3.so.3()(64bit) is needed by package libgnomedb Which figures, as that is the old 1.9.100 libgda .so For the full log see: http://koji.fedoraproject.org/koji/getfile?taskID=18756&name=root.log So why is koji finding the new libgda, but not the new libgnomedb, is some kinda sync script running for this at regular intervals, or ... ? Regards, Hans

10 24

Massive size increases in certain packages
by Orion Poplawski 05 Jul '07

05 Jul '07

I just got a bug report on python-numarray (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240289) indicating that the size of the installed package has increased from around 6.7MB in FC6 (1.5.2-1.fc6) to around 56MB currently (1.5.2-2.fc7). Now, the only this that was done was to rebuild the package for python 2.5 back in December. If I rebuild the package now the size is back to "normal". The differences are in the size of the shared libraries: < 1272 /usr/lib/python2.5/site-packages/numarray/_bytes.so < 1264 /usr/lib/python2.5/site-packages/numarray/_chararray.so < 1308 /usr/lib/python2.5/site-packages/numarray/_conv.so < 1268 /usr/lib/python2.5/site-packages/numarray/_converter.so < 1280 /usr/lib/python2.5/site-packages/numarray/_ndarray.so < 1280 /usr/lib/python2.5/site-packages/numarray/_numarray.so < 1260 /usr/lib/python2.5/site-packages/numarray/_numerictype.so < 1264 /usr/lib/python2.5/site-packages/numarray/_objectarray.so < 1260 /usr/lib/python2.5/site-packages/numarray/_operator.so < 1376 /usr/lib/python2.5/site-packages/numarray/_sort.so < 1292 /usr/lib/python2.5/site-packages/numarray/_ufunc.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so < 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so < 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so < 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so < 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so < 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so < 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so --- > 28 /usr/lib/python2.5/site-packages/numarray/_bytes.so > 20 /usr/lib/python2.5/site-packages/numarray/_chararray.so > 72 /usr/lib/python2.5/site-packages/numarray/_conv.so > 20 /usr/lib/python2.5/site-packages/numarray/_converter.so > 36 /usr/lib/python2.5/site-packages/numarray/_ndarray.so > 36 /usr/lib/python2.5/site-packages/numarray/_numarray.so > 12 /usr/lib/python2.5/site-packages/numarray/_numerictype.so > 16 /usr/lib/python2.5/site-packages/numarray/_objectarray.so > 16 /usr/lib/python2.5/site-packages/numarray/_operator.so > 136 /usr/lib/python2.5/site-packages/numarray/_sort.so > 48 /usr/lib/python2.5/site-packages/numarray/_ufunc.so > 80 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so > 80 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so > 84 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so and so on. I did a quick compare of FE 6 to the last FE devel and found that the following packages have increased in size by more than a factor of 2. Some of these may be fine, I haven't looked into it in detail. What's up? banshee 2536364 -> 6770157 cppunit-doc 4504311 -> 10063237 duplicity 936214 -> 2255520 fwbackups 347859 -> 894038 graphviz-tcl 298038 -> 2020760 libburn-devel 47334 -> 944521 libcaca-devel 507545 -> 1482955 libhugetlbfs 97382 -> 206633 libhugetlbfs-test 1031501 -> 135632714 libpreludedb-python 91466 -> 1355682 linux-libertine-fonts 2589874 -> 10225720 mercurial 2063651 -> 6487353 nsd 446095 -> 1665847 ogre 6374746 -> 29476134 openbabel-perl 1206495 -> 3376667 openbabel-python 1501764 -> 3509293 ortp-devel 197141 -> 3761868 php-pear-PHPUnit 126756 -> 1106041 plplot-wxGTK 54287 -> 144831 pybluez 341942 -> 1617662 pyflowtools 35170 -> 1302402 pyfribidi 27095 -> 1299303 pygpgme 79943 -> 1349853 python-CDDB 55383 -> 1324169 python-GeoIP 30419 -> 1299395 python-adns 60844 -> 1327860 python-alsaaudio 28238 -> 1297182 python-chm 121632 -> 2670312 python-durus 419912 -> 1718919 python-numarray 6771218 -> 56416870 python-protocols 766774 -> 2075564 python-pycurl 212612 -> 1485863 python-quixote 1853963 -> 7008959 python-ruledispatch 933214 -> 2272446 python-smbpasswd 34293 -> 1302773 python-twisted-runner 74839 -> 1349825 python-zope-interface 1013800 -> 2358938 pyxmms 327987 -> 2871939 rdiff-backup 1286381 -> 3896666 supertux 15057058 -> 49666684 wallpapoz 110963 -> 363890 xpa 945338 -> 1979801 zvbi-fonts 43808 -> 132817 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

13 22

http://buildsys.fedoraproject.org/buildgroups/7 ?
by Ralf Corsepius 28 Jun '07

28 Jun '07

Hi, Can we please have http://buildsys.fedoraproject.org/buildgroups/7 Ralf

6 19

For your consideration: Secondary Architectures in Fedora
by Tom Callaway 15 Jun '07

15 Jun '07

This is a very early draft of what I am planning on presenting to FESCo in the near future: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures I am very interested in comments and suggested changes. Thanks in advance, ~spot

29 134

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 May 2007