devel September 2007

devel@lists.stg.fedoraproject.org

290 participants
339 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

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

25 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

Please, make lftp orphaned!!!
by Alain PORTAL 02 Dec '07

02 Dec '07

Hi, I ask for orphaning lftp because package maintainer doesn't maintain this package since a long time. I asked for an updated in june, the 1st, for the 3.5.11 version, released on 2007-04-11 :-( https://bugzilla.redhat.com/show_bug.cgi?id=242112 http://lftp.yar.ru/events.html There is now a 3.5.14 release since 2 weeks. All these releases fix bugs. Regards, An angry lftp user -- Les pages de manuel Linux en français http://manpagesfr.free.fr/

18 34

Killing maintainers
by Jonathan Underwood 26 Nov '07

26 Nov '07

Hi, There's been a thread over on fedora-maintainers list for a few weeks proposing that fedora-maintainers be shut down, as it simply serves bifurcate discussion between here (devel) and there. All responses were in favour. Many people didn't respond, probably because they don't bother reading fedora-maintainers. As an aside, notice how quickly the discussion about naming F8 moved to devel simply because people weren't signed up to -maintainers. There has been a lot of discussion about list reorganization - let's not rehash that. One uncontentious point seems to be, -maintainers must die. What is the quickest way of getting this done? Which of the myriad committees does this need to go through? Jonathan.

7 10

[Long] Do we need a font SIG ?
by Nicolas Mailhot 26 Nov '07

26 Nov '07

Hi all [I wanted to prepare a bit more before writing this, but it seems everyone is asking about the same things at once, so this will have to do] I'd like know what people think of setting up a font SIG, and if there are enough would-be contributors for such a SIG to be viable. Fonts are a very transversal subject in Fedora, and the initial To: list reflects this. Please take care to reply on fedora-devel only however. The situation right now is: 1. we have several font packages in Fedora, but are only scratching what could be packaged. http://mihmo.livejournal.com/45152.html 2. In particular the art team wants a lot more fonts in for its Art spin http://fedoraproject.org/wiki/Artwork/ArtTeamProjects/FedoraArtStudio 3. I don't believe our font selection is optimal for every locale. It took a near-revolt by our Greek users to get their situation fixed in Fedora Core 6, and there are probably many other problem locales, where users just pass on Fedora or bear their pain silently instead of telling us about problems. 4. The i18n team is nominally in charge of selecting the best fonts for each locale, but does not always have the right local contacts to do so. So far i18n has focused on technical problems : if your locale needs complex IM methods you have i18n visibility, if your locale poses no technical challenge but your default fonts are suboptimal the i18n team may not notice you. 4. The l10n team has local contacts and could provide useful feedback on font choices, currently packaged font problems, local foundries/font designers that could be contacted to contribute to the FLOSS font pool, etc but has mostly focused on translation so far. 5. The desktop team handles our font infrastructure and takes the heat when a font is badly rendered (since we can not use the patented freetype autohinter many fonts that work fine under windows do not under Fedora) 6. We already have some font-related material disseminated on our wiki: - packaging rules, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93ce… - licensing rules http://fedoraproject.org/wiki/Licensing#head-63f9d798a33b23a752e5a3b22a0888… - other http://fedoraproject.org/wiki/Fonts/DejaVu 7. The font situation is bad enough we have a font exception to our FLOSS rules http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7… [for example we ship Luxi even though its licensing forbids modification, making it non-free http://www.xfree86.org/current/LICENSE11.html] 8. There are efforts to drain the font licensing swamp and promote FLOSS fonts (http://unifont.org/go_for_ofl/) they are aligned with Fedora general objectives yet Fedora has totally ignored them so far (cf Liberation licensing choices) This is a stark contrast with the very active debian font team : http://wiki.debian.org/DebianInstaller/GUIFonts The main part of the OLPC font page is the Debian font list! http://wiki.laptop.org/go/Fonts I believe there is enough interest in the various Fedora groups to improve the current situation through a font SIG. This SIG would be tasked with: A. providing a single point of entry for Fedora people interested in fonts, centralizing all our packaging rules or at least indexing them in a single place B. completing the existing font packaging documentation C. helping the i18n team maintain the font install list for each locale D. identifying fonts worthy of packaging for l10n or art reasons E. identifying problems in existing font packages and helping relay the info upstream F. identifying problems in our font infrastructure, packaging necessary font tools G. coordinating and effectively packaging new fonts As the current maintainer of dejavu, and a co-maintainer of charis and dejavu-lgc, I am ready to write a commented font spec example (B) (without legacy core font bits, which IMHO should be optional nowadays ; however I'm sure there are people ready and willing to write this part as an extension), and package a few fonts (G). The l10n and i18n groups are naturals for (C). We just have to steal the Debian receipe of having a font-by-locale table in our wiki. I think it's pretty obvious the art team is motivated by (E). IMHO the l10n team should have a role there too. Note that doing the legal analysis of a potential font is far from easy as font licensing practices are far less clean than software licensing practices. Also we should try to build font from sources whenever possible, but font building is often a mess. G will demand packagers and reviewers. By nature most of them will be active in other Fedora forums, so we're not talking of a few full-time SIG members but a lot of part-time contributors. I created a mockup wiki page to try to make all this clear http://fedoraproject.org/wiki/NicolasMailhot/FontMatrix It's far from complete, but I hope it's complete enough to give everyone an idea of the potential SIG scope. So, who wants to play? Is Fedora ready for a font SIG or should I ask again next year? Kind regards, -- Nicolas Mailhot

6 10

Re: Firefox 3
by Takanori MATSUURA 13 Nov '07

13 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

glade3 in fedora7
by Deependra Singh Shekhawat 07 Nov '07

07 Nov '07

Hi, Is Glade3 available on Fedora7. I saw it has been stable for long time now and I found no package with name Glade3. Is there no Glade3 in Fedora7 and if it isn't why is it so ? Thanks

13 27

Announcing rpmfusion
by Hans de Goede 25 Oct '07

25 Oct '07

The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project. RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux. We don't have a repository ready for end users yet, but we are actively working on merging the following ones: * http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/ We will have two distinct repositories: free and non-free. Free will contain Open Source Software (as defined by the Fedora Packaging Guidelines) which can't be included in Fedora -- for example because it might be patent encumbered in the US. Non-free will contain everything else which is not free software (as defined by the Fedora Licensing Guidelines), like software with public available source-code that has "no commercial use" restrictions or the graphics drivers from AMD and Nvidia. Repositories and infrastructure will follow Fedora where possible. This means using Fedora's packaging guidelines (except for legal), Fedora's review process for new submissions, Fedora's VCS structure etc. It will contain add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/CentOS + EPEL or Fedora (Fedora 7+). It will contain kernel module packages in the main repo, even if Fedora will drop them (which looks likely as of August 2007). We aim to provide support for all 'current' versions of Fedora including devel, for i386, ppc, ppc64 and x86_64. We hope to attract new Fedora packagers and many other 3rd party repositories. Please join our mailing list at: http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion

40 125

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