devel May 2009

devel@lists.stg.fedoraproject.org

310 participants
223 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

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

16 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

Packages looking for new owners
by Trond Danielsen 07 Dec '09

07 Dec '09

Hi everyone, it is becoming clear to me that I can no longer provide the collection of packages I maintain the love and care that they deserve. If only there were more hours in a day, but the current situation does no leave much room for volunteer work on free software :-(. Hopefully I will find time in the future to return to Fedora related work The list if packages I maintain is available here: https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner I don't mind keeping libopenraw, avrdude and uisp unless anyone _really_ want to maintain these packages. Best regards, -- Trond Danielsen

8 12

Packaging Survey - May 2009
by Rahul Sundaram 27 Oct '09

27 Oct '09

Hi I did a quick survey from Fedora on what software Fedora users are using that is not available in the repo. Here are the results. If you find anything interesting, feel free to pick it up. https://fedoraproject.org/wiki/Packaging_Survey_May_2009 Rahul

18 32

gnaughty is a hot babe
by Rahul Sundaram 21 Jul '09

21 Jul '09

Hi My packaging survey turned up a interesting suggestion https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html We don't currently have any guidelines covering this but considering the Debian action to hot babe http://lwn.net/Articles/113644/ I wanted to asked first, is this allowed in Fedora? Rahul

40 138

Rawhide debuginfo packages with no sources
by Ville Skyttä 27 Jun '09

27 Jun '09

Hello, Quite a few packages that produce *-debuginfo without sources have crept again in rawhide. See https://fedoraproject.org/wiki/Packaging/Debuginfo for possible reasons, the most usual of which in my (past, haven't checked this batch that closely) experience is failure to honor $RPM_OPT_FLAGS during build which can also mean that the default security related compiler flags aren't being applied either. List of such packages identified by my debuginfo-check.py is attached (ownership info generated with Thorsten's fedoradev-pkgowners). I intend to submit debuginfo-check.py to yum-utils (probably as debugrepo-check) and have added a similar check in upstream svn rpmlint, hopefully with these additions people will start noticing the issues easier. Maintainer Package Co-maintainers ---------------------------------------------------------------- aconway rhm nsantos alexlan pvm (none) amdunn why (none) athimm mediawiki (none) ausil elftoaout pjones,spot,jima awjb multisync (none) bjensen colrdx sindrepb,sconklin,dp67 bonii moe (none) caolanm sac (none) ctyler nled overholt cweyl perl-DBI-Dumper perl-sig cwickert emelfm2 (none) dbhole antlr (none) dbhole jakarta-commons-logging overholt,kasal dbhole sinjdoc (none) dcantrel pyparted (none) dcbw csound pfj dchen libchewing i18n-team dchen tomoe-gtk i18n-team,ryo deji atlas deji devrim byaccj dbhole devrim postgresql-odbcng (none) devrim regexp (none) dledford lam (none) drepper pfstools (none) dwalluck hamcrest (none) dwheeler zenon pertusus fab rfdump (none) fab timespan (none) fnasser gnu-getopt (none) gemi curry (none) gemi erlang (none) gemi GtkAda (none) gemi wings (none) green phasex (none) guthrie simplyhtml (none) ianweller csstidy (none) ifoox mysql-connector-java (none) itamarjp balance (none) ixs ddrescue (none) ixs hevea (none) jkeating email2trac (none) jmagne esc (none) jsafrane freeipmi pknirsch jsafrane OpenIPMI pknirsch jwrdegoede elice (none) jwrdegoede lostlabyrinth (none) kasal transfig pertusus kdudka curl (none) konradm genus2reduction (none) konradm taginfo (none) kvolny vodovod (none) langel bouncycastle langel,oget laxathom gammu (none) limb astromenace (none) limb planets mmahut limb wesnoth wtogami linville b43-fwcutter (none) makghosh qps (none) maxamillion ninvaders (none) maxamillion shed (none) mbooth brazil (none) mmahut nightfall astronomy-sig mwringe xerces-j2 (none) oget slv2 (none) orion GMT pertusus orion wgrib2 pertusus ovasik star mildew overholt jython jmatthews pcheung avalon-logkit (none) pcheung concurrent (none) pcheung jakarta-commons-httpclient akurtakov pfj mono-debugger (none) pvrabec sectool jhrozek,mildew rishi osmo (none) rrankin denemo (none) sconklin splat bjensen,dp67 sergiopr blitz (none) sindrepb xdotool (none) snecker libflaim (none) tanguy gperiodic (none) terjeros simdock (none) thias gentoo (none) tuxbrewr quassel (none) twaugh cups (none) verdurin gnomint (none) wart wormux (none) wtogami ldm toshio,pertusus,eharrison,ryan52 zprikryl libtrash (none) (orphan) olpc-utils dcbw,johnp

11 37

need help with mock
by Neal Becker 20 Jun '09

20 Jun '09

Need to debug segfault with gcc-4.4 of python-igraph. python-igraph requires igraph-devel, so here's what I tried: mock -r fedora-devel-x86_64 --install ~/fedora/igraph/devel/igraph-0_5_2-1_fc12/igraph-0.5.2-1.fc11.x86_64.rpm INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot [nbecker@nbecker6 devel]$ mock -r fedora-devel-x86_64 --install ~/fedora/igraph/devel/igraph-0_5_2-1_fc12/igraph- devel-0.5.2-1.fc11.x86_64.rpm INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot [nbecker@nbecker6 devel]$ mock -r fedora-devel-x86_64 --install ~/fedora/igraph/devel/igraph-0_5_2-1_fc12/igraph- debuginfo-0.5.2-1.fc11.x86_64.rpm INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot [nbecker@nbecker6 devel]$ mock -r fedora-devel-x86_64 --rebuild --no-clean python-igraph-0.5.2-2.fc12.src.rpm INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start INFO: Start(python-igraph-0.5.2-2.fc12.src.rpm) Config(fedora-rawhide- x86_64) State Changed: init State Changed: lock buildroot Mock Version: 0.9.14 INFO: Mock Version: 0.9.14 INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: setup ERROR: Exception(python-igraph-0.5.2-2.fc12.src.rpm) Config(fedora-rawhide- x86_64) 0 minutes 4 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result ERROR: Bad build req: No Package Found for igraph-devel = 0.5.2. Exiting.

10 25

Requires: %{_libdir}/pkgconfig
by Michael Schwendt 18 Jun '09

18 Jun '09

Dependency chaos. Some packagers have started with adding Requires: %{_libdir}/pkgconfig instead of the good old "Requires: pkgconfig". Not only is this dependency expensive -- the filelists metadata must be loaded and parsed -- it doesn't work correctly either, because 1) package "pkgconfig" is not multilib'ed, so e.g. pkgconfig.i386 is not available in the x86_64 repo, and hence nothing provides the /usr/lib/pkgconfig directory, (and it would be a broken dep) but 2) a couple of other packages include %_libdir/pkgconfig by accident, which violates the packaging guidelines. Namely: openchange-devel 499655 ipod-sharp-devel 499658 sane-backends-devel 499659 libXScrnSaver-devel 499660 freetype-devel 499661 anthy-devel 499663 Since these are multilib'ed, a dependency on /usr/lib/pkgconfig doesn't pull in pkgconfig.i386 but one of these -devel packages instead. [...] Conclusively, neither "Requires: %{_libdir}/pkgconfig" nor "Requires: pkgconfig%{_isa}" will work as expected.

3 6

RFE: Makefile.common patch to error out when no spec is present
by Kevin Fenzi 11 Jun '09

11 Jun '09

Greetings. I know some of you have run into this situation: If you have a package where there is no *.spec file present and you try to run any of the fedora cvs Makefile.common targets, nothing happens and the command just hangs. Turns out it's doing a grep of the spec file to figure out if the package is noarch or not. When there is no spec file the grep hangs. Here's a very hacky patch that should at least error out in this case. Makefile hackers welcome to provide a better one. kevin -- Index: Makefile.common =================================================================== RCS file: /cvs/extras/common/Makefile.common,v retrieving revision 1.127 diff -u -r1.127 Makefile.common --- Makefile.common 15 Apr 2009 04:57:41 -0000 1.127 +++ Makefile.common 24 Apr 2009 21:15:03 -0000 @@ -35,6 +35,9 @@ BUILD_FLAGS ?= $(KOJI_FLAGS) +ifndef $(SPECFILE) +SPECFILE = "NO_SPEC_FILE_FOUND" +endif LOCALARCH := $(if $(shell grep -i '^BuildArch:.*noarch' $(SPECFILE)), noarch, $(shell uname -m)) ## a base directory where we'll put as much temporary working stuff as we can

6 7

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 2009