devel November 2009

devel@lists.fedoraproject.org

330 participants
292 discussions

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

Possible wrong versions tagged into f12-final
by Quentin Armitage 16 Dec '09

16 Dec '09

I've noticed what might be a couple of anomalies regarding which versions of packages have been tagged into f12-final. freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but 0.9-10.fc11 tagged has been tagged into f12-final. gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but 0.8.14.3.fc11 has been tagged into f12-final. It appears that 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12 rebuild). Quentin Armitage

3 2

Promoting i386 version over x86_64?
by Gregory Maxwell 14 Dec '09

14 Dec '09

I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight?

50 164

Need a sponsor: mod_proxy_html (apache)
by Philip Prindeville 11 Dec '09

11 Dec '09

Hi. I need a sponsor for this. An RPM has been built on several systems (including FC8 and FC9 and Centos5) and tested on all of those. The ticket has been languishing now unassigned for almost a year. https://bugzilla.redhat.com/show_bug.cgi?id=452636 Can someone please pick this up? It's just an .src.rpm for Apache's mod_proxy_html. It's pretty trivial. Thanks, -Philip

6 9

F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
by Terry Barnaby 10 Dec '09

10 Dec '09

If the NetworkManager service is running, but not managing the current network connection, then Firefox starts up in offline mode. Is this a bug in NetworkManager or Firefox ?

9 25

Local users get to play root?
by nodata 08 Dec '09

08 Dec '09

Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible!

68 317

orphaning dblatex
by Neal Becker 08 Dec '09

08 Dec '09

I no longer wish to maintain dblatex. Any takers?

2 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

Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
by Terry Barnaby 07 Dec '09

07 Dec '09

Ok, controversial title. I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times. I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues. The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it. I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora. As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.

35 107

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 2009