Re: Heads up: NoArch Sub Packages Feature continues
Seth Vidal wrote: Just to be clear - you're okay with writing things off as a bug in the repo but you're unhappy saying not obsoleteing the older pkg on an arch-change is a packaging bug? Yes, I'm entirely serious. A package should never have to obsolete an older version of itself. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, Jun 17, 2009 at 3:28 AM, Kevin Koflerkevin.kof...@chello.at wrote: drago01 wrote: Only in certain apps, and most of them have handwritten SSE routines anyway. Not all the apps with handwritten SSE routines can detect the CPU at runtime, there's a significant amount which needs to be built with or without SSE support at compile time. (This is broken in principle, but it exists.) In part, this is because GCC only allows SSE intrinsics to be used if SSE support is enabled, which also allows GCC to use SSE wherever it feels like it, even in functions where there are no SSE intrinsics. So the only way to properly support runtime SSE detection is to compile SSE routines as a separate compilation unit, which not everyone gets right. Yeah by handwritten I was talking about assembler routines as for instrincts yeah GCC needs sse enabled for this. There is an interesting feature that is worth mentioning here: See Automatic use of optimized function in http://udrepper.livejournal.com/20948.html Yeah that's why we hide the x86_64 arch from the download page and promote x86 everywhere.(attempt to change this failed) That's a bad thing indeed, and I'm with you there, this needs to change! The website team does not really care (x86 works so what?, cluttering the download page with links is not an option, ...) FESCo delegated this to the website team and as they aren't interested I simply gave up (no need to fight an useless flamewar that wont change anything anyway). A way that would fix this is a LiveDVD with both the x86_64 and x86 image on it and let the bootloader boot the appropriate version. (I don't know if this is possible with the current tools). But this would result into this: * Default media works for every x86 system while it still takes advantage of the hardware (x86_64) * We have more space on the media (even when it has to be shared between x86 and x86_64) * It won't clutter the download page because it will simply replace the current download link But this will probable require some amount of work. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Orcan Ogetbil, Tue, 16 Jun 2009 20:16:36 -0400: - Let's keep F-12 the same: ppc, ppc64, i586, x86_64 - Since ppc and ppc64 are going to be dropped from F-13, fill in the blank spot with i686+SSE2, i.e. F-13: i586, i686+SSE2, x86_64 Everyone happy? No, I hate we will be missing other-endian but that's war lost, I am afraid. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Thoughts? Re: Do we need split media CDs for F12?
We've seen arguments, for and against. Statistics and Numbers, thinking! Get the community involved. *Find Out* As I've stated earlier: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01015.html Run a poll, get the fp.o to run a poll, and blog\twitter etc. *Don't ask pointed questions* Do you want to keep split-cd for Fedoa X rather What is you preferred method of obtaining Fedora With a realistic range of values as check-boxes\radio buttons. looking at: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01426.html I would also included an option, and this would probably go further up the chain. Would you be willing to buy a 4(8)gb usb stick with Fedora X (DVD contents on it), supplied with a boot CD. (This could also be an Ambassador supplied option, either way costs only) If all that can be done by F12 fine, if not defer the whole thing to F13. Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: iptables/firewall brainstorming
Jud Craft wrote: On Mon, Jun 15, 2009 at 4:52 AM, Thomas Woernertwoer...@redhat.com wrote: The major problem with a /etc/iptables.d direcory with files provided by packages are that you can not say in the end what your firewall will look like: Is the firewall is open for a specific service/host/network or not. The files are text blobs and therefore there is no way to say what they will do. If you have packages dropping in some firewall rules into the firewall without the ability for activation/deactivation and also sorting of the rules, then you could get into unexpected behaviour and also big security risks. Well, ideally, system-config-firewall should support iptables rules (in text blobs) AS IS, rather than having its own set of custom rules that are completely obviously to the standard method for specifying them. Custom rules in system-config-firewall are text blobs in the iptables-save format to make it possible to add rules, s-c-fw is not able to handle. And then, it should be able to display the state of the firewall in its entirety, not just its own custom rules. If it's going to be an abstraction around iptables, it should be a good one, and actually...you know, abstract iptables. Not just add another non-exclusive conflicting interface for specifying rules on top. Just use service iptables status. It is displaying the current active firewall. Building an up-to-date abstraction layer around iptables is nearly impossible. There are too many changes going on in netfilter and iptables. Or, pull a fontconfig, and obsolete the iptables text files, requiring everyone to go through an official API (firewallconfig) or somesuch to specify behaviors. Then packages could use this system, rather than dropping in random text files, and these settings could then be centralized and monitored by a tool like system-config-firewall. A start for this is done, please have a look at the tool. Just thoughts. Thomas -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tue, Jun 16, 2009 at 09:33:22PM -0400, Orcan Ogetbil wrote: Now where does the i686+SSE2 come into play? Does this SSE2 have any effect on those programs that do not contain SSE(2) related assembly code? Is this 1-2% improvement that you are mentioning only about these kind of programs (that do not contain assembly code)? One advantage of SSE2 is that it can be used as a replacement for the braindead x87 (floating point) instructions. The x87 instructions are architecturally stupid because they arrange the registers as a stack, whereas what a compiler wants is a flat register file. There was an experimental branch of the OCaml/i386 compiler which used SSE2 as a replacement for x87 instructions, and it gained a 10-15% increase in performance *on floating point benchmarks* [1] (ie. not just on any old code, and not code which used specific hand-written SSE2 optimizations). (It's worth noting that SSE2 is always used on ocamlopt/x86_64) Rich. [1] http://caml.inria.fr/pub/ml-archives/caml-list/2009/05/781b091ad8006b117f8554014826665e.en.html -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Push?
On Mon, Jun 15, 2009 at 10:34:32PM +0100, Peter Robinson wrote: Is there a different problem with the override tagging then? Yes. Mostly getting people to do them. FYI, you can ping rdieter for override tags. Peter Robinson, if you're thinking of webkitgtk-1.1.8-1.fc11, SMParrish asked rdieter to tag it on #fedora-kde, it should be tagged now. hehe, no i wasn't actually :-) I was wanting opal for ekiga :-D Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Mon, 15 Jun 2009 18:35:00 -0300 Martín Marqués martin.marq...@gmail.com wrote: 2009/6/15 Casey Dahlin cdah...@redhat.com: Maybe we should just make the command line more friendly so users don't mind reaching for it. I vote we add clippy. You're joking, right? It's *clippy* - of course it's a joke. :-) I'm sure the appropriate people within MS would admit to all sorts of perverse indiscretions well before admitting that Clippy was their idea. A command line clippy would result in sysadmins and power users rioting in the street. I see you're trying to write a shell scri^C; rm -f /usr/bin/clippy... (A true BOFH would have it run in his least-favourite luser's .profile, set immutable and located in luser's $HOME/bin. :-P) Serious note: hotwire / hotssh may not suit the experienced - personally it's not my thing - but it would be an excellent compromise for the newer user that needs a bit of help with the CLI. Michael. -- Michael Fleming mflem...@thatfleminggent.com - (EMail/XMPP/Jabber) WWW: http://www.thatfleminggent.com Fedora / Red Hat Packages: http://www.thatfleminggent.com/rpm-packages Twitter: http://twitter.com/thatfleminggent -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Am Freitag, den 12.06.2009, 08:48 -0700 schrieb Toshio Kuratomi: On 06/12/2009 08:14 AM, Christoph Wickert wrote: Am Freitag, den 12.06.2009, 05:34 +0200 schrieb Kevin Kofler: I don't see what it buys our users if they get one big update over 2 small ones. In most cases the biggest part (consuming time and cpu cycles) of the updates is not installing them but everything else like checking for new packages, downloading the metadata, This portion of the list is saved. This part happens in the background without user's notice, so this portion irrelevant. calculating dependencies, downloading the packages and running the transaction test. Especially for small updates this takes much more time than the actual rpm -U part. But this portion of your list is dependent on the size of the transaction so it isn't going to halve the time to go from two small updates to a single large update here. But this is the portion that requires user interaction, what happens between the first update notice and the message that all updates were installed. So from a users POV the time is reduced dramatically. I think it could even more than halve because scriptlets are only running once instead of several times. -Toshio Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera: On Mon, 2009-06-15 at 13:09 +0100, Paul wrote: Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? As per usual, pulseaudio debug output is a requirement. I found that pulseaudio -k pulseaudio fixed it for me after chown on /dev/snd/* which had root.audio ownership. I see this error when starting pulseaudio though: [kmar...@nc6400 ~]$ pulseaudio E: bluetooth-util.c: Error from ListAdapters reply:org.freedesktop.DBus.Error.ServiceUnknown Cheers Kjartan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, 2009-06-17 at 13:51 +0200, Kjartan Maraas wrote: ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera: On Mon, 2009-06-15 at 13:09 +0100, Paul wrote: Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? As per usual, pulseaudio debug output is a requirement. I found that pulseaudio -k pulseaudio fixed it for me after chown on /dev/snd/* which had root.audio ownership. I see this error when starting pulseaudio though: [kmar...@nc6400 ~]$ pulseaudio E: bluetooth-util.c: Error from ListAdapters reply:org.freedesktop.DBus.Error.ServiceUnknown That means that bluetoothd isn't running, which should be fine. There are some known problems with PulseAudio's Bluetooth plugin handling of presense/absence of bluetoothd. This was discussed in another thread on this ML. Cheers -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, 17.06.09 13:51, Kjartan Maraas (kmar...@broadpark.no) wrote: ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera: On Mon, 2009-06-15 at 13:09 +0100, Paul wrote: Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? As per usual, pulseaudio debug output is a requirement. I found that pulseaudio -k pulseaudio fixed it for me after chown on /dev/snd/* which had root.audio ownership. I see this error when starting pulseaudio though: Hmm, if the permissions aren't set up correctly then this is some HAL ACL handling brokeness. Wouldn't be the first one. [kmar...@nc6400 ~]$ pulseaudio E: bluetooth-util.c: Error from ListAdapters reply:org.freedesktop.DBus.Error.ServiceUnknown That's a missing bluetoothd. This shouldn't be fatal though, or is it? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
So, https://bugzilla.redhat.com/show_bug.cgi?id=502226 was logged a while ago against OOo for the rpms improperly providing and requiring .sos that are not in the linker path, but instead in OOo's own subdirs. The concern is that the autorequires/provides operate in a flat namespace and that eventually there'll be some conflation where something linking to /usr/lib/foo.so will force sucking in a package that provides /usr/lib/package/plugins/foo.so instead Clearly this isn't specific to OOo, e.g. as a random example $ rpm -q --provides gedit|grep spell libspell.so $ rpm -ql gedit | grep libspell.so /usr/lib/gedit-2/plugins/libspell.so and probably thousands of others. So, a) do we care ? b) if we care do we want to b.1) make every package that has some shared libraries in it that are not in the default linker path make manual filters to exclude the provides/requires ? (oh, the pain) b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Caolán McNamara caol...@redhat.com said: The concern is that the autorequires/provides operate in a flat namespace and that eventually there'll be some conflation where something linking to /usr/lib/foo.so will force sucking in a package that provides /usr/lib/package/plugins/foo.so instead It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) and auto-provided them. Since mrtg is shorter than perl-SNMP_Session, mrtg was chosen to provide those dependencies, which didn't work. mrtg is still auto-providing a bunch of internal modules; only the SNMP_Session modules were filtered out. That's just one I've personally had to deal with. In a perfect world, the solution would be something along the lines of: - generate the auto-provides for system directories separate from package-provided directories - generate the auto-requires - filter everything auto-provided from package-provided directories out of both the provides and requires I'm sure that would still break something though. You'd have to have a way to flag additional directories as system for packages that extend the system directories list (e.g. by dropping something in /etc/ld.so.conf.d). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: So, https://bugzilla.redhat.com/show_bug.cgi?id=502226 was logged a while ago against OOo for the rpms improperly providing and requiring .sos that are not in the linker path, but instead in OOo's own subdirs. a) do we care ? Yes I care. I ran into somthing similar for perl modules. Packages shouldn't provide 'perl(foo)' unless those modules are in perl's default module path. It clearly breaks programs when a perl module in a private directory satisfies an rpm dependency for another package. b) if we care do we want to b.1) make every package that has some shared libraries in it that are not in the default linker path make manual filters to exclude the provides/requires ? (oh, the pain) That is what I had to do in the case of a perl program I'm packaging. There are even Fedora guidelines on how to do this for perl. b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Chuck Anderson c...@wpi.edu said: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. Until that becomes possible, I'm inclined to say that AutoReq/Prov shouldn't be searching private directories, and we should require all packages that have such requirements to use manual Requires: on either the file path or the package that provides the private library. Keeping things the way they are now is just plain broken. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Gregory Maxwell (gmaxw...@gmail.com) said: I doubt having consistently lower FP precision is anything many users are asking for. The few that do can usually take care of themselves. And yet you say we should push them all to x86_64, which has the same lower precision? - More clearly delineates our support set of targets, sticking true to forwards innovation, not necessarily legacy support If thats the case why maintain x86 at all? Because it's 58% of our userbase (source: F11 torrent stats.) How much of that 58% is actually 64 bit machines running the 32 bit OS? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
* Ingvar Hagelund But amarok-2.x does not (yet) support non-hardware (that is, not found by HAL) mounts. * Kevin Kofler What would such a non-hardware mount be? Are you trying to use a partition or directory on your computer as a fake iPod? Why Not fake. Real iPods like the iPhone or the iPod Touch. They are mounted using Fuse mounts, that is sshfs or ifuse. Fuse mounts are not detected by HAL. Ingvar -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
On Wed, Jun 17, 2009 at 04:56:26PM +0200, Ingvar Hagelund wrote: * Ingvar Hagelund But amarok-2.x does not (yet) support non-hardware (that is, not found by HAL) mounts. * Kevin Kofler What would such a non-hardware mount be? Are you trying to use a partition or directory on your computer as a fake iPod? Why Not fake. Real iPods like the iPhone or the iPod Touch. They are mounted using Fuse mounts, that is sshfs or ifuse. Fuse mounts are not detected by HAL. Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
PLEASE do not do this. If we stop supporting Pentium II and Pentium III, I have to buy a whole lot of new hardware. Dead serious. Could we do i686 as a secondary arch, and swap with i386 further in the future? While I understand you may have a lot of older hardware, the point of a *seconday* architecture is that it's not the primary architecture target. Even if we didn't split off older CPUs, we're still primarily targeting newer machines. Except there is no proper support for secondary arches yet. See the discussion and the decision on PPC and moving it to a secondary arch. Maybe that should be postponed until there is a proper secondary arch and all the policies etc associated with it. It seems most of the CPUs exlcuded from the list above are probably 64 bit capable anyway (excluding the P4 netburst stuff which have their own perf issues, the earlier gens of centrino, and atom). I still have an Athon32, XO and another geode machine (Fit-PC - which are still shipping with geode models). The Fit-PC I got because it was tiny, silent, uses about 5 watts of power and had 2 onboard ethernet which makes it ideal for router/fw stuff. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
BTW are those new VIA netbooks SSE2-capable? Additionally, what will this do to RHEL? I can't imagine RHEL customers being too happy about this for RHEL7(?), and if i386 would still be in RHEL, it would worry me that it would only be a secondary arch in Fedora. . . This is not relevant for fedora's decisions. -sv I'm not sure I understand why not. Are you saying that if RedHat decided that RHEL7 was to support Sparc , there'd be no interest in making that a primary arch? ppc/ppc64 is supported in RHEL. It is no longer a primary arch in Fedora. Sorry? I thought it was still primary until after F-12. So yes its scheduled to be a secondard arch for F-13 in 12 months time. Its not one yet. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
- Intel i586 (all) - Intel Pentium Pro - Intel Pentium II - Intel Pentium III - 32-bit AMD Athlon As an ambassador, it's going to be hard to explain people that I can't install Fedora 12 on their computers that still run Windows XP, Ubuntu and others perfectly fine. We see 32 bit Athlon at Install Parties (I don't think so for the other ones) here in France, where we are supposed to be a rich country. Fedora moves from an OS suitable to poor people (I mean, the fact that it is free of charge is a perfectly valid reason for using Linux) to an elitist OS that will only support (and welcome as contributors!) people rich enough to upgrade their hardware. That is kind of sad, but if that's the plan forward, I'll try to refine my ambassador speach Agreed. According to the web Microsoft will still support machines of this spec for Windows 7. That feels like a bit of a kick in the teeth http://www.microsoft.com/windows/windows-7/download.aspx Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Gregory Maxwell (gmaxw...@gmail.com) said: 'outside'. Please don't just dismiss these recent systems, they are a real issue. According to public smolt stats: http://smolt.fedoraproject.org/static/stats/stats.html only 0.38% of the userbase is non-Intel/AMD. (Number of registered systems that report as Geode: 4.) That's assuming everyone is registering. I have my Fit-PC registered but none of my XOs as smolt isn't installed. I also have friends that have Fit-PCs running Fedora 10/11 but I know they don't use smolt (so that's another 6+ devices) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 01:51:37PM +0200, Kjartan Maraas wrote: ti., 16.06.2009 kl. 11.17 +0100, skrev Bastien Nocera: On Mon, 2009-06-15 at 13:09 +0100, Paul wrote: Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? As per usual, pulseaudio debug output is a requirement. I found that pulseaudio -k pulseaudio fixed it for me after chown on /dev/snd/* which had root.audio ownership. I see this error when starting pulseaudio though: [kmar...@nc6400 ~]$ pulseaudio E: bluetooth-util.c: Error from ListAdapters reply:org.freedesktop.DBus.Error.ServiceUnknown Cheers Kjartan Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Now where does the i686+SSE2 come into play? Does this SSE2 have any effect on those programs that do not contain SSE(2) related assembly code? Is this 1-2% improvement that you are mentioning only about these kind of programs (that do not contain assembly code)? One advantage of SSE2 is that it can be used as a replacement for the braindead x87 (floating point) instructions. The x87 instructions are architecturally stupid because they arrange the registers as a stack, whereas what a compiler wants is a flat register file. There was an experimental branch of the OCaml/i386 compiler which used SSE2 as a replacement for x87 instructions, and it gained a 10-15% increase in performance *on floating point benchmarks* [1] (ie. not just on any old code, and not code which used specific hand-written SSE2 optimizations). (It's worth noting that SSE2 is always used on ocamlopt/x86_64) That's because its always been there on x86_64 and most people that care about performance have already moved to x86_64 to get the other performance benefits of 64 bit anyway. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolsonra...@bludgeon.org wrote: Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? No... you should be added to the acl list associated to the device if you are the physical console user as per the authorization policy managed by PolicyKit. This it how it works from at least F10 onward. Mucking around with file ownership directly is old think. The system scripts associated with pam use to do that on user login and logout...but has been replaced with the more flexible solution involving acls that PolicyKit based hardware access authorization makes use of. for example on the F10 system I'm on right now: ls -la /dev/snd/seq crw-rw+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq getfacl /dev/dsp # file: dev/snd/seq # owner: root # group: root user::rw- user:myuser:rw- group::rw- mask::rw- other::--- I do not own the file in the traditional Unix permissions sense. But I am listed in the acl list with read write access. If your user is not in the acl list, something misfired in the area of the PolicyKit based authorization handling. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Peter Robinson wrote: [...] why maintain x86 at all? Because it's 58% of our userbase (source: F11 torrent stats.) How much of that 58% is actually 64 bit machines running the 32 bit OS? I'm going to guess, a lot of it? 60% of my installations are x86 (75% if you count only hardware, and 25% of my hardware is i686-without-sse2). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Websites such as ... Wikipedia ... are reputed to occupy users for periods in excess of 5 hours. -- Wikipedia article on Internet Addiction -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Removing support for still-functional hardware is a trademark of Microsoft, not Linux. I'd also argue that doing another full rebuild of the OS for a 1% performance gain on a single architecture is not a particularly production use of resources. The 1% comes from i586 - i686; SSE2 would be additional on top of that. But given the vehement opposition, I can see dropping the SSE2 requirement. I'm still fairly convinced that going to i686 is the right move - we really don't support i586 as a practical matter, and even the Geode should still work with that. Furthermore, it's likely we'll have a mass rebuild for LZMA support and/or debuginfo changes, so it's no additional cost. When I ran Fedora 10 on my Fit-PC I would run a i686 kernel openssl without issue but yum wouldn't see it as an update because the arch didn't match so I'd have to manually download it and install it with 'rpm -i --ignorearch kernel' so I presume there would have to be changes to at least rpm to override the fact that its i586 + cmov as opposed to officially being i686. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
Thomas Janssen on 06/17/2009 03:19 AM wrote: Ubuntu Alternative Thats not a LiveCD. It's just a install CD. No Live. So? Your point? A Fedora LiveCD is an install CD. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, 2009-06-17 at 02:55 +0200, Kevin Kofler wrote: Bruno Wolff III wrote: Is there going to be a way to tell which binaries actually use sse2 instructions, so that the others can be inherited by a secondary arch? Due to how GCC works, if the compiler flags enable SSE/SSE2, basically all the binaries will be using some SSE/SSE2 instructions. And on the various SSE-capable CPUs, how much benefit does that actually give us? I'm after a system-wide answer, not a microbenchmark for zlib or crypto code. It should take into account any overheads involved in saving/restoring registers on context switch that wouldn't otherwise have to be saved/restored. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
BTRFS in 2.6.31-rcwhatever
Hello, It seems there has been some confusion about BTRFS and the new format, so let me try and clear some things up 1) Btrfs is an experimental and unstable fs that is to be used for testing only as it could eat your data. 2) Btrfs is an experimental and unstable fs that is to be used for testing only as it could eat your data. 3) Btrfs is an experimental and unstable fs that is to be used for testing only as it could eat your data. Ok now that we have that out of the way, 4) The merge window opened last week for 2.6.31, at which point a new disk format for btrfs was sucked into the kernel. 5) This new disk format is _incompatible_ with older kernels, which means that older kernels will not mount a fs with the new format. Nothing bad will happen if you try to boot into an older kernel, you won't lose data, it just won't work. 6) This new disk format is automatic. As soon as you boot into the new kernel, your filesystem will be automatically converted to the new format. There is nothing you can do, so if you don't want the new format, don't run the new kernel. At some point in the next few weeks this kernel will land in rawhide. I will try and make sure btrfs-progs-0.19 goes out at the same time. The new btrfs-progs isn't essential for running the new format, so if you just install the kernel you will be fine, but obviously some of the commands may not work properly. So if you installed onto btrfs, be careful about going to rawhide, since you will not be able to go back if you do. Btrfs will not be as stable as ext4 currently is for at least another year, so it is still very much just for testing. I am very interested in hearing about bugs and getting them fixed, however there will be little to nothing that I can do if you lose data. Thank you, Josef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tuesday 16 June 2009, Steven M. Parrish wrote: The OLPC folks have made a commitment use Fedora as the base for future releases for not only the XO-1.0 but for the new XO-1.5 which is still in development. Does use Fedora as the base mean they'll be using binary packages as is from Fedora, without rebuilding them? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Once upon a time, Adam Jackson a...@redhat.com said: Really we just need the moral equivalent of %exclude for autoreqprovs. Yeah, I said that years and years ago, but RPM didn't want it. Having many many packages with their own hacked versions of scripts to exclude autoreqprovs is silly (and a maintenance mess). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wednesday 17 June 2009, Adam Jackson wrote: Really we just need the moral equivalent of %exclude for autoreqprovs. http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5854 https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 8:06 AM, Jeff Spaletajspal...@gmail.com wrote: getfacl /dev/dsp typo: that should have been .dev./snd/seq not /dev/dsp the getfacl output cut and paste was correct for /dev/snd/seq -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Den 2009-06-17 18:42, Ville Skyttä skrev: On Tuesday 16 June 2009, Steven M. Parrish wrote: The OLPC folks have made a commitment use Fedora as the base for future Does use Fedora as the base mean they'll be using binary packages as is from Fedora, without rebuilding them? Yes. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Changing the default 32-bit x86 arch for Fedora 12 (#2)
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom Why? - We don't really support i586 in any meaningful matter - OLPC still works with base i686 - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of -march=i586 -mtune=generic. P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom Bill [1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
Jeroen van Meeuwen (kana...@kanarip.com) said: Something else not terribly unreasonable, instead of split CD media, a single CD offered that is netinst.iso plus the contents of @core and @base if it'll fit on a CD. Then they can do whatever custom install they want, and add packages after install, either from a DVD media or from a local mirror, or from the Internet. That's exactly what Fedora Unity is about to release for Fedora 11. Any particular reason why this is (or isn't) a spin? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
On Wed, 2009-06-17 at 16:07 +0100, Matthew Garrett wrote: On Wed, Jun 17, 2009 at 04:56:26PM +0200, Ingvar Hagelund wrote: * Ingvar Hagelund But amarok-2.x does not (yet) support non-hardware (that is, not found by HAL) mounts. * Kevin Kofler What would such a non-hardware mount be? Are you trying to use a partition or directory on your computer as a fake iPod? Why Not fake. Real iPods like the iPhone or the iPod Touch. They are mounted using Fuse mounts, that is sshfs or ifuse. Fuse mounts are not detected by HAL. Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. To be clear, apps like AmaroK / Rhythmbox would just talk to the iPod via libgpod or similar directly. The FUSE method of 'mounting' iPods is just another way of talking to libgpod, to give you the convenient user interface of a mounted filesystem, but it doesn't really make sense for other applications to go through the fake filesystem rather than just using the library to talk to the device directly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
- Michael Cronenworth m...@cchtml.com wrote: So? Your point? A Fedora LiveCD is an install CD. There are several points that I hope will be taken from the entire thread. Some people do not like the LiveCD install option, or lack of options as they may see it. The point I failed to communicate earlier that lead to a lot of noise is Fedora Unity's position. It is simple really, Even if Fedora Project does not produce CD media, Unity still has users that want it, so the community that needs it should not panic. I think producing media for niche groups is perfect for smaller organizations or groups, Just like the FEL Spin or KDE Live media for the KDE SIG. We need real data if at all possible from as many sources as possible so the Fedora Project and the Community that Fedora Unity is a part of can make a true informed decision. We really should not feel that we need to worry about upstream projects such as anaconda, they should be allowed to drop or abandon the needed code if they want or need to. Fedora Project also should not feel that is needs to worry about downstream projects like Fedora Unity, we will hold our own and do what is needed to supply users with this niche media. There may be other bits that I have overlooked but I think this covers the big bullets. - Bob P.S. Kevin is not a bad guy, just pissed in my Wheaties(tm) at the wrong time. | Robert 'Bob' Jensen|| Fedora Unity Founder | | b...@fedoraunity.org|| http://fedoraunity.org/ | | http://bjensen.fedorapeople.org/ | |http://blogs.fedoraunity.org/bobjensen| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On 06/17/2009 07:52 PM, Bill Nottingham wrote: Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom Why? - We don't really support i586 in any meaningful matter - OLPC still works with base i686 - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of -march=i586 -mtune=generic. P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom Bill [1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode This sounds a perfectly fine and sensible solution to me, thanks for taking the feedback into account :) Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Once upon a time, Bill Nottingham nott...@redhat.com said: Why? - We don't really support i586 in any meaningful matter What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work? - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it That's a pretty poor justification. - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available There are also lots of other chips that people run 32 bit x86 code on. I don't think Atom is a majority percentage of 32 bix x86 Fedora users either. If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of -march=i586 -mtune=generic. P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom Bill [1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode Okay, before I thought you said this was a 1-2% improvement across the board, but now it is a 1% improvement on some CPU-intensive operations on some CPUs (and a 1% performance hit on other CPUs). How does this affect multilib on x86_64? The justification for the i586 rebuild was that there hasn't been a Fedora i386 kernel for years (so i586 was already required anyway). This is the first time Fedora is proposing to throw out CPU support in a long long time, and I find a minimal improvement on some targeted benchmarks a poor justification. It would seem to me that adding a few targeted Atom packages would be a better use of resources (e.g. similar to openssl.i686). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Gregory Maxwell (gmaxw...@gmail.com) said: Consider: -Os on the x86 build? Back when I tested before, -Os unilaterally made things worse across Athlon64/C2D/Atom. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Le mercredi 17 juin 2009 à 11:49 -0500, Chris Adams a écrit : Once upon a time, Adam Jackson a...@redhat.com said: Really we just need the moral equivalent of %exclude for autoreqprovs. Yeah, I said that years and years ago, but RPM didn't want it. Having many many packages with their own hacked versions of scripts to exclude autoreqprovs is silly (and a maintenance mess). File triggers are based on the same idea. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote: Gregory Maxwell (gmaxw...@gmail.com) said: Consider: -Os on the x86 build? Back when I tested before, -Os unilaterally made things worse across Athlon64/C2D/Atom. Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:30 AM, Muayyad AlSadi wrote: Note that this is of only very limited usefulness because packages often have updates available anyway. on the contrary this feature is very important for people who got no or slow internet connection, and in my country this is almost always the case in that case one won't mind getting an older openoffice.org than downloading tons of mega bytes. and even if one wants the latest oo.o he could install it from DVD then use presto to save bandwidth The closing is done automatically, not by humans, so there's no way that bugs that are 'obviously' still valid can be excepted. You have already said that you *know* how to do this. May I suggest that you do it then? I'm not here to complain about closing the bug nor to ask how to make a local repo I'm here to ask what does the new UI for media change mean in the PK update https://admin.fedoraproject.org/updates/FEDORA-2009-5748 It appears that existing media sources can be enabled or can be disabled in the GUI by marking the check boxes or unmarking the check boxes. In my Fedora 11 it does not show a CD or DVD source. You would have to add them, as in the example that I pointed to earlier, yourself. From what I read it works. I can not really confirm that because I have not done that. Nor will I because it is not what I want. Similar to yumex. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 8:46 PM, Jakub Jelinekja...@redhat.com wrote: On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote: Gregory Maxwell (gmaxw...@gmail.com) said: Consider: -Os on the x86 build? Back when I tested before, -Os unilaterally made things worse across Athlon64/C2D/Atom. Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions. Is this (bloated code) really a problem if the code runs faster? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Once upon a time, drago01 drag...@gmail.com said: Is this (bloated code) really a problem if the code runs faster? Bloated code: == more disk space (not too critical except for LiveCD type setup) == more RAM usage (most have lots of RAM so not too bad) == more cache misses (slows down code because of waiting on RAM) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote: Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions. Is this (bloated code) really a problem if the code runs faster? Of course it is. You trash caches by rarely used functions. You don't want to optimize rarely used code at the expense of code size, only the often used. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 9:01 PM, Jakub Jelinekja...@redhat.com wrote: On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote: Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions. Is this (bloated code) really a problem if the code runs faster? Of course it is. You trash caches by rarely used functions. You don't want to optimize rarely used code at the expense of code size, only the often used. OK, fair enough. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
It appears that existing media sources can be enabled or can be disabled in the GUI by marking the check boxes or unmarking the check boxes. In my Fedora 11 it does not show a CD or DVD source. You would have to add them, as in the example that I pointed to earlier, yourself. From what I read it works. I can not really confirm that because I have not done that. Nor will I because it is not what I want. Similar to yumex. -- a bit you can't add the media itself as a repo [not a copy of it nor a file:// something I'm talking about the removable media] not in PK nor yumex nor any other tool -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 08:06:36AM -0800, Jeff Spaleta wrote: On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolsonra...@bludgeon.org wrote: Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? No... you should be added to the acl list associated to the device if you are the physical console user as per the authorization policy managed by PolicyKit. This it how it works from at least F10 onward. Mucking around with file ownership directly is old think. The system scripts associated with pam use to do that on user login and logout...but has been replaced with the more flexible solution involving acls that PolicyKit based hardware access authorization makes use of. for example on the F10 system I'm on right now: ls -la /dev/snd/seq crw-rw+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq getfacl /dev/dsp # file: dev/snd/seq # owner: root # group: root user::rw- user:myuser:rw- group::rw- mask::rw- other::--- I do not own the file in the traditional Unix permissions sense. But I am listed in the acl list with read write access. If your user is not in the acl list, something misfired in the area of the PolicyKit based authorization handling. Good to know. I've checked the acl list in the past and definitely wasn't a member. I'll have to remove myself from audio and see if I can track this down. Thanks, Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Wednesday 17 June 2009 14:01:02 Bill Nottingham wrote: Jeroen van Meeuwen (kana...@kanarip.com) said: Something else not terribly unreasonable, instead of split CD media, a single CD offered that is netinst.iso plus the contents of @core and @base if it'll fit on a CD. Then they can do whatever custom install they want, and add packages after install, either from a DVD media or from a local mirror, or from the Internet. That's exactly what Fedora Unity is about to release for Fedora 11. Any particular reason why this is (or isn't) a spin? I thought an official spin could only be a live image. i.e., once you start letting the user choose packages in anaconda, it can't be an official spin anymore. At least, I'm pretty sure that was the case a while back, unless the guidelines have changed while I had my head buried in the sand. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Wed, 2009-06-17 at 15:14 -0400, Jarod Wilson wrote: I thought an official spin could only be a live image. i.e., once you start letting the user choose packages in anaconda, it can't be an official spin anymore. At least, I'm pretty sure that was the case a while back, unless the guidelines have changed while I had my head buried in the sand. I don't know that we forced spins to be live, I just don't think anybody came up with a good spin concept for a choose your own adventure. However we did plan for it by naming the DVD/Split CDs we do now the Fedora spin and putting it in its own directory. So you could have releases/12/Everything releases/12/Fedora releases/12/Fedora-Minimal releases/12/Live or some such. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:10 PM, Muayyad AlSadi wrote: It appears that existing media sources can be enabled or can be disabled in the GUI by marking the check boxes or unmarking the check boxes. In my Fedora 11 it does not show a CD or DVD source. You would have to add them, as in the example that I pointed to earlier, yourself. From what I read it works. I can not really confirm that because I have not done that. Nor will I because it is not what I want. Similar to yumex. -- a bit you can't add the media itself as a repo [not a copy of it nor a file:// something I'm talking about the removable media] not in PK nor yumex nor any other tool I'll say this one last time. Then I am done with this. I believe that the way to do this is to *write* a repo configuration file that *points* to the DVD drive. Which is what that article said to do. And no you can not put the disk in the drive and expect the GUI applications to add it for you. And that, I don't think, is considered a 'bug'. So if you want this to change you need to write a Bugzilla RFE. Not a Bugzilla bug. That would put you in direct contact with the developer and not a common user like I am. Have a good day. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upgrade to F11, now yum python module missing
On 06/10/2009 11:55 AM, Seth Vidal wrote: 1. export PYTHONPATH=/usr/lib/python2.5/site-packages 2. yum update yum I had the same issue, and I can confirm that this does work, if done as root. Obviously if you do line 1, then sudo yum update yum, the env is different, or at least it must be because it failed to work that way for me, so I had to su first. -- Nathanael d. Noblet T: 403.875.4613 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, Jun 17, 2009 at 04:22:21PM +0100, Peter Robinson wrote: BTW are those new VIA netbooks SSE2-capable? Additionally, what will this do to RHEL? I can't imagine RHEL customers being too happy about this for RHEL7(?), and if i386 would still be in RHEL, it would worry me that it would only be a secondary arch in Fedora. . . This is not relevant for fedora's decisions. -sv I'm not sure I understand why not. Are you saying that if RedHat decided that RHEL7 was to support Sparc , there'd be no interest in making that a primary arch? ppc/ppc64 is supported in RHEL. It is no longer a primary arch in Fedora. Sorry? I thought it was still primary until after F-12. So yes its scheduled to be a secondard arch for F-13 in 12 months time. Its not one yet. Correct. Though in the context of the discussion, it won't be in the RHEL7 timeframe. I was simply using it as a counter to the but RHEL argument. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
I believe that the way to do this is to *write* a repo configuration file that *points* to the DVD drive. Which is what that article said to do. And no you can not put the disk in the drive and expect the GUI applications to add it for you. And that, I don't think, is considered a 'bug'. So if you want this to change you need to write a Bugzilla RFE. Not a Bugzilla bug. That would put you in direct contact with the developer and not a common user like I am. hello!! you miss the key point here, the media is REMOVABLE and you need to handle media insertion and removal notice that I asked about new UI for media change I guess it means a dialog box which says please insert the disk label so and so -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
maintainers needed
Hi all, Due to current circumstances (scholarship abroad), I will be unable to take proper care of my packages for the next few months. Therefore, I'm looking for (co-)maintainers for ALL of my packages. List of affected packages can be found in pkgdb: https://admin.fedoraproject.org/pkgdb/users/packages/rathann Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Hi, The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom This sounds good to me/OLPC. Thanks! - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: iptables/firewall brainstorming
Thomas Woerner wrote: Roberto Ragusa wrote: //A if(port==(20-21)) PERMIT; //B if(port==(20-21) net==trusted) PERMIT; //default DENY; A wins here. The first matching rule will be used. Therefore there is no restriction for a trusted network. So your ftp server will be available for everyone - even in a public wifi. And this is exactly what it should happen. B is trying to give permissions to some machines, but it is useless, as A is giving permission to everyone. If it were: //B if(port==(20-21) net==trusted) PERMIT; //A if(port==(20-21)) PERMIT; //default DENY; then B would give permission to some machines and A would give permission to all the others, so even if the decision process is a little different the final result is the same as before. The ftp server is available for everyone. Good, so A is doing its job. :-) -- Roberto Ragusamail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:27 PM, Muayyad AlSadi wrote: I believe that the way to do this is to *write* a repo configuration file that *points* to the DVD drive. Which is what that article said to do. And no you can not put the disk in the drive and expect the GUI applications to add it for you. And that, I don't think, is considered a 'bug'. So if you want this to change you need to write a Bugzilla RFE. Not a Bugzilla bug. That would put you in direct contact with the developer and not a common user like I am. hello!! you miss the key point here, the media is REMOVABLE and you need to handle media insertion and removal notice that I asked about new UI for media change I guess it means a dialog box which says please insert the disk label so and so I know of *no* distribution that does this. Sorry. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
2009/6/17 Michael Cronenworth m...@cchtml.com: Thomas Janssen on 06/17/2009 03:19 AM wrote: Ubuntu Alternative Thats not a LiveCD. It's just a install CD. No Live. So? Your point? A Fedora LiveCD is an install CD. My point.. It is/was obviously that you dont know what an alternative CD is. So i explained it to you. But i failed. Maybe you grab one in your spare time and check out the alternative installation possibilities, compared to a LiveCD. VM`s are great for that. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 7:52 PM, Bill Nottinghamnott...@redhat.com wrote: Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom Sounds much better than your last proposal. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
Thomas Janssen on 06/17/2009 03:25 PM wrote: My point.. It is/was obviously that you dont know what an alternative CD is. So i explained it to you. But i failed. Maybe you grab one in your spare time and check out the alternative installation possibilities, compared to a LiveCD. VM`s are great for that. What's with the negative comment? I know what an alternative installation is. A LiveCD is too offensive for you? We need 10 different installation CD types? Why? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
On Wed, Jun 17, 2009 at 11:12:20AM -0700, Adam Williamson wrote: On Wed, 2009-06-17 at 16:07 +0100, Matthew Garrett wrote: Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. To be clear, apps like AmaroK / Rhythmbox would just talk to the iPod via libgpod or similar directly. The FUSE method of 'mounting' iPods is just another way of talking to libgpod, to give you the convenient user interface of a mounted filesystem, but it doesn't really make sense for other applications to go through the fake filesystem rather than just using the library to talk to the device directly. Right, but my understanding was that various applications required a mount point to be flagged as belonging to an ipod for them to use libgpod on it. The ipod touch and iphone can't be used as mass-storage devices - they speak a custom USB protocol which has been implemented as a fuse driver. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnott...@redhat.com wrote: - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable? I'm thinking specifically with people with Centrino stickered laptops of unclear vintage who may not realize that they have a 64bit capable machine even when they do. The Centrino branding doesn't exactly make it obvious as Intel pushed 64bit capability into the brand at some point (2006 ?). How many people are running 32bit Fedora on 64bit capable hardware without realizing its 64bit capable laptop hardware? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tuesday 16 June 2009, Steven M. Parrish wrote: The OLPC folks have made a commitment use Fedora as the base for future releases for not only the XO-1.0 but for the new XO-1.5 which is still in development. Does use Fedora as the base mean they'll be using binary packages as is from Fedora, without rebuilding them? Yes with the exception of the kernel OLPC uses stock fedora packages. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how to patch native pacakge
On Wed, Jun 17, 2009 at 10:40:56PM +0200, Farkas Levente wrote: Richard W.M. Jones wrote: On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote: so what's our position now? it seems upstream wouldn't like to (and probably can't solve without break something). Have you talked to upstream about this? Please point us to the upstream discussion on their mailing lists. without any response: http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701%40lfarkas.orgforum_name=libjpeg-devel-6x and we discuss many way that this not possible. There's a reason I keep going on about upstream libjpeg, not just because I'm being difficult. It's because there's no way we, as mere packagers, can fix this on our own. We can't even fix it if we have the consent of SuSE, Debian and other packagers. libjpeg has a screwy, disfunctional upstream. There's not been a real upstream release for 11 years. Now there is someone claiming to be the official upstream for libjpeg who isn't ready to hold open discussions with any of the interested groups. This can *only* be fixed by someone taking control, and making a real upstream libjpeg which has an open, responsive governance. This is *not* a Fedora problem. Create a real upstream libjpeg (maybe you'll need to change the name). Involve all the parties and packagers, make the right technical decisions, release up to date, modern packages, and then, maybe, mingw32-libjpeg can be a proper part of Fedora. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 11:00:06AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. I was talking about in the same package. For example, MRTG installs in /usr/bin/mrtg, and then needs private perl modules. If you simply remove the private directories, you'll end up with broken dependencies because /usr/bin/mrtg needs modules that are not provided anywhere. I don't see why. You would obviously filter out the Requires as well as the Provides. Those files are in the same package as the binary, so they'll always be there when the package is installed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... and for what ... P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom This just doesn't look worthwhile at all. My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
Ingvar Hagelund wrote: * Ingvar Hagelund While waiting for amarok-2.x to support scripting or fuse mounts, I could use some advice on getting 1.4 to work. All the parts seems to be present, I just can't get them to play together. (...) My small F11 patch for amarok-1.4.10, based on the version in epel can be found at http://users.linpro.no/ingvar/amarok Sorry for the noise. I scratched and rebuilt the iPod db on the iPhone, and then amarok-1.4.10 worked without problems. If anyone are interested in the packages, they are available from http://ingvar.blog.linpro.no/2009/06/11/amarok-14-for-fedora-11/ Ingvar Thank you Ingvar. After using Amarok 2 for a couple of months I'm convinced it has a long way to go before it comes near Amarok 1.4 in terms of features, usability and robustness. Greg -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
* Matthew Garrett Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. * Adam Williamson To be clear, apps like AmaroK / Rhythmbox would just talk to the iPod via libgpod or similar directly. The FUSE method of 'mounting' iPods is just another way of talking to libgpod, to give you the convenient user interface of a mounted filesystem, but it doesn't really make sense for other applications to go through the fake filesystem rather than just using the library to talk to the device directly. * Matthew Garrett Right, but my understanding was that various applications required a mount point to be flagged as belonging to an ipod for them to use libgpod on it. The ipod touch and iphone can't be used as mass-storage devices - they speak a custom USB protocol which has been implemented as a fuse driver. (Sidenote: The sshfs method does of course not use the USB protocol. It uses ssh.) iFuse is built on top of libiphone. I would guess that some glue code between libiphone and libgpod, and some HAL signalling, would eliminate the need for a fuse mount - and then perhaps amarok-2.x will be usable for our needs. Until then, we'll have to keep going with 1.4. Luckily it has been picked up by epel. Ingvar -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 2:00 PM, Richard W.M. Jonesrjo...@redhat.com wrote: This just doesn't look worthwhile at all. My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature. Hmm. In the scheme of the numbers you references. What does that look like in terms of a performance penalty? Or was your proposal specifically covered by Bill's numbers? is the downgrade you are talking about within the jitter of Bill's posted performance numbers as well? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Hi, On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... That's not true; Geode has cmov, and should be compatible with gcc's i686. - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Richard W.M. Jones rjo...@redhat.com writes: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... No, though it cuts out VIA C3 (used mostly(?) on EPIA (mini-ITX) boards). I have one but it had never run Fedora (only PXE ramdisk-based small LFS). Hmm... Just checked and it seems they still list EPIA-M and others as available. I'm not sure what to think about that: - The CPU in question is C3 Eden / Samuel 2 / Ezra (not sure about the difference but C3-2(?) aka Nehemiah seems to be CMOV-capable). - I think the clock range is 400 - 1000 MHz, though I've only seen 600+ MHz versions. - it seems they've started selling mini-ITX EPIAs in 2002 - low-power fanless boards, the old EPIA-M was capable of hardware decoding MPEG2 and I'm told newer boards can do MPEG4 in hardware as well - they are/were popular as DVD/digital TV/DVR boxes. - Eden CPU datasheet dated Jan 18, 2006 states that CMOV and FCMOV instructions available and Notes On CPUID Feature Flags: The CMPXCHG8B instruction is provided and always enabled, however, it can be disabled in the corresponding CPUID function bit 8 to avoid a bug in an early version of Windows NT. However, this default can be changed via bit 1 in the FCR MSR. - Maybe Samuel 2 and Ezra are non-cmov and Eden is cmov-able? I don't say if those CPUs have to be supported by Fedora, I'm just posting this for completeness. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
David Woodhouse wrote: I'm after a system-wide answer, not a microbenchmark for zlib or crypto code. It should take into account any overheads involved in saving/restoring registers on context switch that wouldn't otherwise have to be saved/restored. Doesn't the kernel have to save/restore them anyway? Or how does it know that a program doesn't contain any SSE assembly? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
Ingvar Hagelund wrote: Not fake. Real iPods like the iPhone or the iPod Touch. They are mounted using Fuse mounts, that is sshfs or ifuse. Fuse mounts are not detected by HAL. Then that's a HAL bug. HAL is supposed to detect hardware and mount it automatically (using FUSE if needed, that works just fine with ntfs-3g). It makes no sense that you have to mount it by hand and it makes even less sense to expect apps to handle hardware which the tools responsible for detecting hardware don't detect. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Hi, On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... That's not true; Geode has cmov, and should be compatible with gcc's i686. Agreed, I've run i686 kernel/openssl on a geode based Fit-PC for 18 months (until F11 when it went to i586) and it supported it without massive issues. RPM/yum support is a different issue and will need to be addressed, but I'm sure that's probably a basic patch to identify a i586 that has cmov as being i686 capable. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
The OLPC folks have made a commitment use Fedora as the base for future releases for not only the XO-1.0 but for the new XO-1.5 which is still in development. Does use Fedora as the base mean they'll be using binary packages as is from Fedora, without rebuilding them? Yes! The vast majority of packages used in OLPC are vanilla fedora packages. The packages that are branched for OLPC is currently very low. I have around a dozen or so on my current list, although that varies from time to time dependent on what they need to pull in from upstream etc. Either way they don't do complete mass recompiles. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Chris Adams wrote: It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) That's the real problem, apps are not supposed to ship private copies of system libs in the first place, it needs to be fixed to use the system libraries. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 4:55 PM, Kevin Koflerkevin.kof...@chello.at wrote: Jeff Spaleta wrote: Well, we need to start by actually telling people a 64-bit version exists in the first place! The crappy download page needs to be fixed! We should go back to something like get-fedora-all, the current get-fedora is a disaster. Its all a matter of how you look at it. If it turns out that a lot of 64bit hardware owners are running 32bit Fedora 11, then we can probably assume the function of such a page is a high impact tool acting as a guide a significant portion of our userbase towards install media. If that's so then it probably deserves a lot of attention and scrutiny for first impression impact. If on the other hand people with 64bit systems are predominately installing the 64bit version, even though its not exposed on that page then we can probably say that our current userbase demographics are very technically saavy, and that the details of the contents of that sort of on-ramp page doesn't particularly matter to them. -jefA firm believer that all great culinary inventions were in fact thought to be cooking disasters at first glance... until someone dared a 12 year old boy to eat it. Half the time the kid would die, 10% of the time it was actually tasty.spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote: Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm. Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network? -- Mike Chambers Madisonville, KY Fedora Project - Bugzapper, Tester, User, etc.. miketc...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Thu, Jun 18, 2009 at 01:46:30AM +0100, Peter Robinson wrote: I'm not sure I understand why not. Are you saying that if RedHat decided that RHEL7 was to support Sparc , there'd be no interest in making that a primary arch? ppc/ppc64 is supported in RHEL. It is no longer a primary arch in Fedora. Sorry? I thought it was still primary until after F-12. So yes its scheduled to be a secondard arch for F-13 in 12 months time. Its not one yet. Correct. Though in the context of the discussion, it won't be in the RHEL7 timeframe. I was simply using it as a counter to the but RHEL argument. I don't see RHEL as any form of argument. RedHat does a mass recompile Nor I. That was my entire point. Since we agree, and I'm utterly confused as to why you decided to nit-pick the ppc thing as a counter to a RHEL argument, perhaps it's best if we just agree to agree? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Chuck Anderson (c...@wpi.edu) said: system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Not really unbounded. If a package puts a file in /etc/ld.so.conf.d/ then the library is now available system-wide, so it should be searched by autorequires/autoprovides. The package that puts the file in ld.so.conf.d and the package that puts libraries into the location specified in that file may not be the same package, and actually may have no dependencies between them at all... Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, 17 Jun 2009 10:03:38 +0200 drago01 drag...@gmail.com wrote: ...snip... A way that would fix this is a LiveDVD with both the x86_64 and x86 image on it and let the bootloader boot the appropriate version. (I don't know if this is possible with the current tools). But this would result into this: * Default media works for every x86 system while it still takes advantage of the hardware (x86_64) * We have more space on the media (even when it has to be shared between x86 and x86_64) * It won't clutter the download page because it will simply replace the current download link But this will probable require some amount of work. This sounds like an excellent idea. :) Hopefully someone knows if this is possible and/or how to approach it. Of course it's going to be larger than the live cd images and it will require dvd, but it could be nice in any case. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gpsdrive and some perl packaging needed
On Wed, 17 Jun 2009 20:44:19 -0300 Murilo Opsfelder Araújo mopsfel...@gmail.com wrote: Hi Kevin, I sent you the same link in a private message, but I thought I should share with the fedora-devel-list. Here is the link: https://fedoraproject.org/wiki/Perl/cpanspec Yes, I know about cpanspec. ;) I was more asking if there were perl packagers interested in packaging/maintaining those packages. I can probibly find time to do it sometime, but I thought someone else might be more quickly able to do so. ;) Thanks. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Chris Adams (cmad...@hiwaay.net) said: - We don't really support i586 in any meaningful matter What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work? I know of *no one* in the community who tests on i586 to ensure that it works. (If this drags them out of silence, so be it!) It is certainly not part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel team even has hardware around that they could test fixes on. On the userspace side, we don't do a lot, if any, of optimization (or testing) of yum or the installer for working in small memory environments. I believe the minimum memory actually used for any of the qualification tests in the installer for F11 was 512MB. At a certain level, I suspect many, if not all, bugs of a Fedora does not install/takes three days to do anything/does not run well on a i586-class box are going to be CLOSED/WONTFIX-UNLESS-YOU-ARE-SENDING-A-PATCH, at best. *That's* what I mean by we don't really support i586 in any meaningful manner. As for why it was done that way in F-11, paranoia mostly (about the XO not being fully vetted, among other things.) - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it That's a pretty poor justification. The common complaint leveled about doing it was why go to the extra effort. If we're doing a mass rebuild, it's essentailly zero extra effort. - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available There are also lots of other chips that people run 32 bit x86 code on. I don't think Atom is a majority percentage of 32 bix x86 Fedora users either. See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I suppose.) If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of -march=i586 -mtune=generic. P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom Bill [1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode Okay, before I thought you said this was a 1-2% improvement across the board, but now it is a 1% improvement on some CPU-intensive operations on some CPUs (and a 1% performance hit on other CPUs). Well, if you're using a P4, you may have already lost, as it's not really a good CPU for optimization, period. The fact that -march=i686 is a lose on P4 makes it unique among everything I have access to, and the thing that really dragged the benchmark down on P4 was software we don't even ship (MP3 decode). How does this affect multilib on x86_64? It doesn't. Bill [1] http://fedoraproject.org/wiki/Foundations [2] http://fedoraproject.org/wiki/Objectives -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Once upon a time, Bill Nottingham nott...@redhat.com said: Chris Adams (cmad...@hiwaay.net) said: How does this affect multilib on x86_64? It doesn't. What I meant was what was the impact on running 32 bit binaries on the 64 bit OS (e.g. run your benchmarks there as well). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 10:50:43PM -0400, Bill Nottingham wrote: Chuck Anderson (c...@wpi.edu) said: system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Not really unbounded. If a package puts a file in /etc/ld.so.conf.d/ then the library is now available system-wide, so it should be searched by autorequires/autoprovides. The package that puts the file in ld.so.conf.d and the package that puts libraries into the location specified in that file may not be the same package, and actually may have no dependencies between them at all... Do we have any examples of that? I'd be inclined to say if there are a very few cases where one package provides an ld.so.conf.d file that ends up being used by many other packages, we should just put that path into the system default /etc/ld.so.conf, so it is always present. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Chris Adams (cmad...@hiwaay.net) said: How does this affect multilib on x86_64? It doesn't. What I meant was what was the impact on running 32 bit binaries on the 64 bit OS (e.g. run your benchmarks there as well). Unless I've completely missed something (always a possiblity), 32-bit code runs *exactly* the same when the CPU is in 64-bit mode. In the benchmarks posted, the Athlon64 (and possibly the P4; I'd have to check later) was actually running in 64-bit mode at the time, even though the binaries were 32-bit. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, 17 Jun 2009, Mike Chambers wrote: On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote: Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm. Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network? The only verification we've done to see how accurate the smolt stats are is to compare the i386 vs x86_64 in smolt to the mirror list requests, and they are consistently within a couple of percentage points of each other. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Mike McGrath (mmcgr...@redhat.com) said: Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm. Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network? The only verification we've done to see how accurate the smolt stats are is to compare the i386 vs x86_64 in smolt to the mirror list requests, and they are consistently within a couple of percentage points of each other. That doesn't help with I have a 32-bit install on my 64-bit box, of course. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 23:00:38 +0100, Richard W.M. Jones rjo...@redhat.com wrote: My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature. If you succeed let me know. I have a couple of P90 laptops with 24MB of memory that won't boot from CDs that I currently have RH 6.2 on and would upgrade to something more recent if I could. I only use them once a year so I am not willing to invest a lot of time in helping. RH 6.2 works well enough for what I use them for. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On 06/17/2009 08:10 PM, Bill Nottingham wrote: See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I suppose.) I agree with your analysis leading to the we don't really support i586 in any meaningful manner statement but not this one. Being innovative in software and operating system design may be meaningful despite running on old hardware or even precisely because it runs on old hardware. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gpsdrive and some perl packaging needed
On Wed, Jun 17, 2009 at 8:04 PM, Kevin Fenzike...@scrye.com wrote: Greetings. I am trying to package up the newest gpsdrive. (2.10pre7). I have a package now that builds fine, but I am missing some perl packages that it needs: perl(Text::Query) I'd love to help, but upstream seems to be dead since 2001 and it fails to pass tests. perl(WWW::Curl::easy) Has been spelt with upper case E since 2005 (gpsdrive upstream should really update their code accordingly) - already available in perl-WWW-Curl. perl(Geo::OSM:EntitiesV3) perl(Geo::OSM::OsmReaderV5) perl(Geo::OSM::EntitiesV5) perl(Geo::OSM::OsmReaderV3) Seem to be in gpsdrive tarball only - not in CPAN - should be part of your package? -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 3:55 PM, Mike Chambersm...@miketc.net wrote: Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network? I'll take it with a grain of salt...but I've no a priori reason to think that the number of 32bit installs on 64bit hardware would be unrepresentativeif we exclude virtualized installs completely. I'm not trying to compare the existence of 32bit to 64bit hardware just 32bit OS installs on 64bit hardware as a subset of all registered 64bit hardware. Just looking at 64bit hardware doesn't have the same sort of legacy or geographic distribution caveats that 32bit does with regard to re-purposed equipment. 64bit stuff just hasn't been around long enough. If 32bit installs on 64bit hardware is a tiny percentage of the registered smolt installs i doubt seriously its going to a majority situation for 64bit hardware in the wild. If its 20% or more as a function registered 64bit hardware..its a big enough population to try to account for in how we communicate a change in policy with regard to 32bit. I'm not suggesting that policy decision be based on this numbers..I'm saying that how we communicate a change in policy should have these numbers in mind when generating Release specific talking points for the release where the change impacts potential install scenarios.. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 5:45 PM, Kevin Kofler kevin.kof...@chello.atwrote: Chris Adams wrote: It has happened with perl modules already. mrtg has a private copy of the perl SNMP_Session, SNMP_util, and BER modules (all from SNMP_Session) That's the real problem, apps are not supposed to ship private copies of system libs in the first place, it needs to be fixed to use the system libraries. There are two problems here, one fixed: 1) mrtg should look at using the perl modules provided by perl-SNMP_Session, and 2) mrtg must not provide perl dependency info where the Perl modules are outside the system Perl library paths (that is, @INC). -Chris -- Chris Weyl Ex astris, scientia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gpsdrive and some perl packaging needed
On Thu, 18 Jun 2009 05:58:45 +0200 Iain Arnell iarn...@gmail.com wrote: On Wed, Jun 17, 2009 at 8:04 PM, Kevin Fenzike...@scrye.com wrote: Greetings. I am trying to package up the newest gpsdrive. (2.10pre7). I have a package now that builds fine, but I am missing some perl packages that it needs: perl(Text::Query) I'd love to help, but upstream seems to be dead since 2001 and it fails to pass tests. :( ok. I can look at whats calling it and see if it can be patched out/removed. perl(WWW::Curl::easy) Has been spelt with upper case E since 2005 (gpsdrive upstream should really update their code accordingly) - already available in perl-WWW-Curl. Ah ha. perl(Geo::OSM:EntitiesV3) perl(Geo::OSM::OsmReaderV5) perl(Geo::OSM::EntitiesV5) perl(Geo::OSM::OsmReaderV3) Seem to be in gpsdrive tarball only - not in CPAN - should be part of your package? Hum. I will dig some more, but they don't seem to be getting picked up. http://www.scrye.com/~kevin/fedora/gpsdrive-2.10-0.1.pre7.fc11.src.rpm is what I have so far. If anyone would like to provide patches or suggestions, they are welcome. Thanks for the reply! kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
