devel October 2010

devel@lists.stg.fedoraproject.org

255 participants
246 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

orphan most of my packages
by Andy Shevchenko 16 Sep '12

16 Sep '12

Hello, I have no more time to support the following packages in the Fedora. jack-audio-connection-kit -- The Jack Audio Connection Kit klamav -- Clam Anti-Virus on the KDE Desktop man-pages-uk -- Ukrainian man pages from the Linux Documentation Project python-alsa -- Python binding for the ALSA library qstat -- Real-time Game Server Status for FPS game servers uniconvertor -- Universal vector graphics translator -- With Best Regards, Andy Shevchenko

6 10

[ANNOUNCE] bfq disk I/O scheduler
by Paolo Valente 18 Apr '11

18 Apr '11

Hi, I have been working for a few years (with Fabio Checconi) on a disk scheduler providing definitely lower latencies than cfq, as well as a higher throughput with most of the test workloads we used (or the same throughput as cfq with the other workloads). We named this scheduler bfq (budget fair queueing). I hope this is the right list for announcing this work. One of the things we measured in our tests is the cold-cache execution time of a command as, e.g., "bash -c exit", "xterm /bin/true" or "konsole -e /bin/true", while the disk was also accessed by different combinations of sequential, or random, readers and/or writers. Depending on which of these background workloads was used, these execution times were five to nine times lower with bfq under 2.6.32. Under 2.6.35 they were instead from six to fourteen times lower. The highest price paid for these lower latencies was a 20% loss of aggregated disk throughput for konsole in case of background workloads made only of sequential requests (due to the fact that bfq of course privileges, more than cfq, the seeky IO needed to load konsole and its dependencies). In contrast, with shorter commands, as bash or xterm, bfq also provided up to 30% higher aggregated throughput. We saw from 15% to 30% higher aggregated throughput also in our only-aggregated-throughput tests. You can find in [1] all the details on our tests and on other nice features of bfq, such as the fact that it perfectly distributes the disk throughput as desired, independently of disk physical parameters like, e.g., ZBR. in [1] you can also find a detailed description of bfq and a short report on the maturity level of the code (TODO list), plus all the scripts used for the tests. The results I mentioned so far have been achieved with the last version of bfq, released about two months ago as patchsets for 2.6.33 or 2.6.34. From a few days a patchset for 2.6.35 is available too, as well as a backport to 2.6.32. The latter has been prepared by Mauro Andreolini, who also helped me a lot with debugging. All these patches can be found here [2]. Mauro also built a binary kernel package for current lucid, and hosted it into a PPA, which can be found here [3]. A few days after being released, this version of bfq has been introduced as the default disk scheduler in the Zen Kernel. It has been adopted as the default disk scheduler in Gentoo Linux too. I also recorded downloads from users with other distributions, as, e.g., Ubuntu and ArchLinux. As of now we received only positive feedbacks from the users. Paolo [1] http://algo.ing.unimo.it/people/paolo/disk_sched/ [2] http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php [3] Ubuntu PPA: ppa:mauro-andreolini/ubuntu-kernel-bfq

3 2

Re: Testing zsh completion for fedpkg
by Ben Boeckel 07 Apr '11

07 Apr '11

Christopher Aillon <caillon(a)redhat.com> wrote: > I missed the first notice of this go by, but I use zsh so can play with > it in the next few days. Can you post the updates so I don't hit the > same bugs you did? Sure. Attached. The bugs were mainly with zsh conventions and getting the sed command for the branch selection corrected. --Ben

3 5

how to speed up mock?
by Farkas Levente 03 Apr '11

03 Apr '11

hi, we use mock for local package build, but it's very slow. now we install a new host just for mock with 8core, ram disks etc. it seems it still slow. first of all most of the time mock use only one 1 core of the cpu. is there any way to speed up different part of the mock build process? thanks in advance. ps. anyway is there any better place to discuss it? -- Levente "Si vis pacem para bellum!"

10 19

HEADS UP! Ohloh Fedora repositories
by Peter Lemenkov 11 Jan '11

11 Jan '11

Hello All! I'm currently in process of automatic enlisting of all ~10K Fedora Git repos at Ohloh. Right now roughly 7% of repositories were added and overall process will be finished in a 20-30 hours (it takes me about 5-10 seconds to properly add repository, and I don't want to speedup this process - to prevent Ohloh from accidental DoS). Just FYI. -- With best regards, Peter Lemenkov.

6 9

Plan for tomorrow's FESCo meeting (2010-10-26) NEW TIME!
by Kevin Fenzi 23 Dec '10

23 Dec '10

Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at enforcement = New business = #416 Set EOL Date For Fedora 12 https://fedorahosted.org/fesco/ticket/416 * Since F14 was pushed out a week, should we move EOL for F12 as well? Elections coming up. * Note that FESCo (and FAMSCo and Board) elections are coming up. = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin

24 49

A comps group for the Design Suite
by Ankur Sinha 03 Dec '10

03 Dec '10

Hello, Since the design team is using a "design suite", would it be possible to please create a group in comps for the purpose? It would make installation of the design suite much easier for end users. The alternative is to create a meta package which isn't welcomed. This[1] is the tentative list of packages. [1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included -- Thanks! Regards, Ankur https://fedoraproject.org/wiki/User:Ankursinha "FranciscoD"

5 12

Heads Up - New Firefox update
by Martin Stransky 28 Nov '10

28 Nov '10

Hi, there's a new Firefox update waiting in Bodhi and we can't push it to stable because of new rules. We recommend you to update to it ASAP as it fixes a public critical 0day vulnerability (https://bugzilla.mozilla.org/show_bug.cgi?id=607222) Bodhi links: https://admin.fedoraproject.org/updates/firefox-3.5.15-1.fc12,xulrunner-1.9… https://admin.fedoraproject.org/updates/firefox-3.6.12-1.fc13,xulrunner-1.9… ma.

25 79

Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
by Jesse Keating 24 Nov '10

24 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. I detected all the "latest" builds of packages that had gcc-4.5.1-3.fc14 in the buildroot, and then further narrowed it down to things which require rtld(GNU_HASH) to find the things that actually used gcc (since gcc gets thrown in every buildroot anyway). For Fedora 15 this was a simple task. Just find the packages where the latest build is "bad", bump it and rebuild it. End of story. This work is already done (except that a few have failed, and I need to follow up on those). For Fedora 14 the matter is much more complicated. Builds are spread out across 3 main tags, dist-f14, dist-f14-updates-testing, and dist-f14-updates-candidate. dist-f14 is things that have made it through bodhi as stable. dist-f14-updates-testing is for things which are currently in updates-testing dist-f14-updates-candidate is for things which could potentially become an update should the maintainer decide. To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. Using this strategy we should be able to replace potentially bad builds with corrected ones wherever they might have been published (barring the failed builds). This message is mostly a heads up as to what's happening. PS I had a small misfire in some of the F14 builds, I used the wrong input set of packages. There is a chance that some f14 builds were done unnecessarily. The unnecessary builds will just be ignored and left to expire. PPS I did not modify my bump script yet to attempt a commit to master and merge to the f14 branch. In the interest of time, I took the easy route and just did commits to the f14 branch. Maintainers can do a merge and fixup after the builds have been done if they wish to have their branches in sync with master once more. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrpk4ACgkQ4v2HLvE71NW6IwCbBex8eV/0M2eOmfqTqakx14zC pDMAnA6iBmjaMC+E87fgp6CvLoxEhAiF =GFLf -----END PGP SIGNATURE----- _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

11 23

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 2010