devel January 2005

devel@lists.stg.fedoraproject.org

273 participants
203 discussions

Re: Apt at fedora.us
by Warren Togami 31 Jan '05

31 Jan '05

Ville Skyttä wrote: > >>"apt-get build-dep" does not need SRPMS at all except the local >>SRPM, which you already have locally because you want to build it. > > > Right, but the source _indexes_ need to be available for build-dep to > work in the first place, no? apt-get build-dep TARGET_LOCAL.src.rpm does not require SRPMS in the apt repository. This only resolves and installs stuff from binary RPMS needed to build that local package. Am I missing something else? Warren Togami wtogami(a)redhat.com

2 1

RFC: Soname in rpm name
by Aurelien Bompard 31 Jan '05

31 Jan '05

Hi all A question to packagers: what would you think of a policy to add the library soname in package libraries ? For example, I have a libkexif package, which provides libkexif.so.0, and at least 3 applications depend on it. Now there is an update to libkexif, which provides libkexif.so.1. I can't update libkexif without updating the applications depending on it. OK, this is probably something that you know much better than me, and that you've run into several times before, so you probably already know the solution. I've searched a bit, and it seems that Mandrake and Debian both have a policy to include the library soname in the package name : http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_pol… http://www.debian.org/doc/debian-policy/ch-sharedlibs.html How about a similar policy for Fedora ? Is it the best solution to this problem ? Aurélien -- http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals. We cause accidents." -- Nathaniel Borenstein

33 158

syncing evolution w/ connector in rawhide (and others)
by Edginton, Brian (GE Healthcare) 31 Jan '05

31 Jan '05

I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward. Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. So now in this test environment mail is completely useless. Is there a way to encourage, or preferably enforce, keeping the wavefront coherent? edge

7 9

RE: syncing evolution w/ connector in rawhide (and others)
by Edginton, Brian (GE Healthcare) 31 Jan '05

31 Jan '05

> -----Original Message----- > From: fedora-devel-list-bounces(a)redhat.com > [mailto:fedora-devel-list-bounces@redhat.com]On Behalf Of David Hollis > > If you have an important workstation/server, you really shouldn't be > running from Rawhide. Things get out of sync, break, get your cat > pregnant, etc. all the time. You can't expect real stability > until the > few weeks prior to release when everything freezes and the various > glitches are worked out. If there was any mandate to keep Rawhide > stable at all times, it would be the equivalent of production and they > would have to put out Beta/RC releases for Rawhide! Then > we'd never see > anything go anywhere. In a general sense I totally agree and follow this concept. But when it involves familiar components it tends to break the ability to provide the testing and feedback necessary to move the rawhide model forward. Perhaps the output of the build could be made more accessible (and maybe it is and I just don't know about it). We could then either what until the components we need are back in sync, or we could dive into cvs and provide feedback that is more productive than my whining! ;) edge

1 0

Re: Better repodata performance
by Konstantin Ryabitsev 31 Jan '05

31 Jan '05

On 31 Jan 2005 03:59:14 -0200, Alexandre Oliva <aoliva(a)redhat.com> wrote: > >> Yeah. Multiply that by a few thousand users, if you happen to run one > >> of the mirrors... > > > Well, that's not the user's problem, is it? > > But why are you narrowing your focus only on users? > > If users don't care about mirrors, how about letting them all go away? > Will users still not care? As someone who is somewhat involved in running a very large mirror, I will tell you that it's much better to have one request for a 1MB file than 50 requests for 10KB files, since mirrors tend to bog down on disk IO, not on bandwidth. Sequential reads for one request for a large file will cause less load than lots of small requests for many files all over the disk. We have bandwidth out the wazoo: it's always down to seek times. > > I am not. I'm very happy that I no longer have to wait for a half an > > hour for all .hdr files to download after I do a fresh install. > > Yeah, I like that too. But I'm not happy that I have to wait longer > for all the updates, on aggregate, if a minor additional improvement > could make things significantly better for everybody. This is what > I'm talking about. That's not a "minor additional improvement" : that's a major modification that will a) significantly complicate the code, and b) make existing repositories incompatible all over again. > Do the maths. I did the maths not for my own set up, but for what a > user of FC alone would face. Is there any particular point in those > numbers you disagree with? > > Do you actually like to wait for downloads? If you could reduce the > download time before yum starts updating from 10 seconds to 1 second, > wouldn't you like that? Compared to the amount of downloading a typical update or install involves, that makes very little difference to me. It's more or less like "wouldn't you prefer to start off from the top of a truck when climbing mt. Everest?" Besides, startup times are already being addressed in HEAD, with large improvements. > It only speaks for the fact that you may not care about tiny amounts > of time you waste without even realizing, and without realizing that > they add up very quickly. Yes. In fact, very few people seem to care. Let's look at usual complaints about yum. Number one reason regular users bitch at yum is because Seth stubbornly refuses to implement the --magically-resolve-all-packaging-problems feature, next to --use-complex-ai-to-figure-out-what-i-really-want. Then it's "yum is too slow" and "yum takes up too much memory", both problems currently actively worked on. You are the first person to complain about repodata-related bandwidth, and judging from the fact that very few people other than you, me, Seth, and Jeff have joined this conversation, I can tell that it's a non-issue as far as most people are concerned. If you survey the users of Fedora systems (not developers or even those who run rawhide, since that will be a very, very small percentage of Fedora users) about yum, your typical responses will probably be: 90%: Yum? What's yum? Our sysadmin handles all our computers. 9% Yeah, I think it runs nightly when I forget to turn off my machine before going to bed, plus I run "yum update" once or twice a month when I am bored. 0.9%: I run "yum update" daily and use it to install new software all the time. 0.1%: I use yum hourly because I am a developer or repo maintainer, and it sucks my balls through a straw. It's the ~1% of yum users who are the vocal ones, since it doesn't satisfy their level of usage. The rest are either quite happy with it, or don't even know that yum is used on their systems, and I tell you that from my experience supporting quite a number of people running and using Fedora. I'm not sure how much effort is justified to satisfy those with uncommon patterns of usage. Regards, -- Konstantin Ryabitsev Zlotniks, INC

2 1

Virtualisation in Fedora status, jan 2005
by Rik van Riel 31 Jan '05

31 Jan '05

Virtualisation in Fedora status, jan 2005 The good news: - working Xen and kernel-xen0/U RPMs available in rawhide - grubby knows how to set up multiboot for the xen0 domain - people are starting to use the available RPMs - the network scripts now work in the presence of ipv6 - a Fedora project page on virtualisation is available: http://fedora.redhat.com/projects/virtualization/ - there is a HOWTO document, explaining how to set up Xen with Fedora http://www.fedoraproject.org/wiki/FedoraXenQuickstart Bugs & limitations: - X does not work on many systems, and appears to cause memory corruption on others - current xen0/U guest kernels are single CPU only - #146571 xen gets stuck at boot with "APIC error on CPU0" - #146575 xen interferes with X acceleration - #142046 XEN Graphical bugs and application instability in Xen dom... - #140847 X inside Xen only works when linux/libint10.a is moved TODO: - update to latest xen-unstable snapshot - apply the AGP patch, to try and remedy the X problems - build and test SMP xen0/U guest kernels - build and test xen and xen0/U kernels for x86-64

1 0

mono in fedora-core-4?
by Tobias Bradtke 31 Jan '05

31 Jan '05

i read in a blog (http://pubcrawler.org/archives/000579.html) that mono will be in fedora-core-4! that would bi great news! :D can someone confirm this? Bill Nottingham (https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00521.html) didn't mention it. Tobias Bradtke

3 2

rawhide report: 20050131 changes
by Build System 31 Jan '05

31 Jan '05

1 0

removing packages in fedora; nedit
by Marius Andreiana 30 Jan '05

30 Jan '05

It was good to see some packages removed from fedora to make room for new ones. I guess all had alternatives (except gnuchess/xboard, I thought about maintaining it in Extras but then remembered how it always beats me and grinned :-D ) Still, would be nice to have a proposal for removal on devel list first. Feels more like community. How about removing nedit too? I find out about it by typing "nc" instead of mc (nc is also netcat) Waiting for FC Extras submitting policy to be done and commit Hylafax, -- Marius Andreiana Epon Business Applications http://www.epon.ro

4 3

Re: Better repodata performance
by Jeff Johnson 30 Jan '05

30 Jan '05

1 0

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