Re: RFE: Never, ever steal focus.
ons 2010-01-06 klockan 17:38 +0100 skrev Haïkel Guémar: > D-E enables either compiz or gnome-shell since F-12, the first one is a > different windows manager, the second is based on Mutter a fork of > Metacity (therefore, focus stealing prevention should work). I've considered suggesting that Mutter be added to the Desktop Effects settings. It's better than Metacity with compositing enabled. The catch though is that it's also slower than compositing Metacity on some hardware. Need to figure out why... /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
ons 2009-12-30 klockan 13:37 + skrev Daniel Drake: > I guess the approach I will take is to install our audited version as a > shared library under a different name (libtommath_olpc?) which the libtommath-audited No sense making it look like it's only for OLPC use. If others want audit-coloured bits they can use it too. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (huge) Ruby packaging changes
tor 2009-12-24 klockan 01:19 +0100 skrev Jeroen van Meeuwen: > The beast that is Java ;-) A very successful example where alternatives > is used heavily is of course a system's mail stack. I think it can be > done right, but the question is how. > > > On the other hand, if I got your intent right, environment-modules might be > > something to look into here. > > > > Care to explain the term environment-modules for me please? See Rahul's link, but it's a way to modify PATH, MANPATH etc. in a structured way. The alternatives system is configured by root and applies to everyone, the modules system is per-user or even per-process. It sounds like your use case needs a per-user or per-process choice, so I suggest you either use environment-modules or forego both modules and the alternatives system and just teach users and packagers to call ruby-1.8 instead of ruby when they need this version. As mentioned, two typical uses of alternatives are: Which MTA to use: Sendmail or something else? This is naturally root's domain. Users shouldn't have to care. Which Java to use: Mostly it's automatic. You install a bunch of Java implementations and alternatives then picks the "best" one based on priorities. Neither root nor users usually need to override it, but if they want to they can, by adding /usr/lib/jvm/java-1.6.0-openjdk/bin or similar to PATH, which is basically what modules does. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
ons 2009-12-23 klockan 14:32 -0800 skrev Jesse Keating: > I don't expect > that I'd have to go hunting down where the commit hash for the previous > build came from, then try to discover which branch that commit hash > currently lives on, so that I can commit on top of it and keep going. Automate it in fedpkg? "fedpkg checkout emacs F12 stable" or something. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
tor 2009-12-17 klockan 20:21 + skrev Ewan Mac Mahon: > Simply killing the process is > actually less disruptive. Yes. Please do not send close events to my Firefox windows. Do keep in mind that Firefox is pretty much broken and might not even be able to show a "Do you want to restart?" dialog by the time the RPM transaction is rolling, so if it's going to involve user interaction, that will have to happen in the PackageKit GUI. Another option is to make Firefox notice internally how broken it is and try to restart itself. It would need to somehow wait until the transaction is done, though. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
tor 2009-12-17 klockan 22:08 +0100 skrev nodata: > I wish mailing list discussions were point-for-point for-and-against. It > would be so much easier. You can easily accomplish this by quoting only the necessary text of the parent post and commenting between the lines. My Evolution preview window shows 38 lines of text. When _all_ of those are quoted text, the person who sent that mail did something wrong. (I'm not picking on you specifically, I think it's a general problem on this list.) > Here is my point: Windows requires a reboot less often than Linux. Argue > all you want, it's true. Like has been pointed out before, Fedora does not force a reboot at all. All it does is show an icon in the corner, telling me I need to log out or I need to reboot. It could gain more options, like "need to restart Firefox". > Linux has quicker security updates than Linux. That's an advantage. > > ksplice can patch a running kernel... I want suspend and resume with a new kernel. Also, ponies. :) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
tis 2009-11-17 klockan 09:52 -0500 skrev Chris Ball: > * Someone on the feature's Talk Page suggests that we should encourage > people using anaconda to create a btrfs rootfs separate to their > /home, so that they can rollback rootfs snapshots without affecting > their homedir. If you have a single btrfs filesystem with one snapshot from a while back and one "head", would it be possible for some hypothetical tool to create a new head which looks like the root from the snapshot but with the latest /home on top? I mean, without actually copying the files from the snapshot, just creating a "fake snapshot" that can the be mounted and writeable. Then you wouldn't need a separate /home. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
tis 2009-11-17 klockan 02:48 -0500 skrev Jeff Garzik: > A bloody awful solution, especially when you consider that btrfs' > maintainer Chris Mason is adding support for real userland transactions > (via some additional ioctls). Yes. But the draft proposal is presented as "tools for experienced people" rather than "cool feature for all", so I don't see the harm. (Check the uses cases under Benefit to Fedora.) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Conservative preupgrade
tor 2009-11-12 klockan 20:02 + skrev Richard Hughes: > Tomorrow I'll push a F11 update disabling the preupgrade > functionality. This will give us enough time to fix things, and then > we can "flip the switch" with another PK update in a few weeks that > re-enables the upgrade functionality. There is the option of a "conservative" preupgrade integration. By that I mean that PK would suggest an upgrade only when the currently installed release has reached end of life and it would then suggest an upgrade to the next release rather than the latest release (which would probably be +2 from what's currently running.) The advantages and disadvantages to the Fedora users and the Fedora project are obvious... /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
tis 2009-10-27 klockan 13:24 -0500 skrev Dennis Gilmore:
> On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
> > On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > > Id like to get some feedback on the patches that i'm proposing for F-13.
> > > quite a few packages that need to deal with differences between
> > > 32bit/64bit or multilib arches have defines for the appropriate arches.
> > > sometimes incomplete since they don't include secondary arches.
> > >
> > > I wanted to get some feedback. and see if there are other cases we should
> > > add.
> >
> > +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> > +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> >
> > Remind me what the asymmetry is for here? Why is %{ix86} not in
> > %{multilib32} ?
[...]
> it should be the attached patch. the initial one was based on what gcc does
> in its spec. it treats %{ix86} as not being multilib.
>
> +%multilib32 %{ix86} %{sparc32} ppc s390
> +%multilib64 x86_64 %{sparc64} ppc64 s390x
I thought the idea was: "multilibXX" is arches where libs go in "libXX"
Then "ix86" would indeed not be in multiliob32. (It should rather be in
"multilib" then, for symmetry...)
/abo
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
tor 2009-10-22 klockan 12:28 -0500 skrev King InuYasha: > I just saw this article about an effort to create Universal binary > style ELF binaries for Linux, and I thought that this would be > something to watch, so that Fedora could integrate both x86-32 and > x86-64 into single DVD sets. There's already lib / lib64 for parallell-installation of libraries, though granted it's limited to only two arches, but yes, something that covers bin too would be useful. But I doubt fat binaries are the answer. You'd probably end up with having rpm merge /usr/bin/xxx from different packages into a single fatelf file upon installation, rather than putting the fat elves in the RPM file. Instead, I think it would be better to extend FHS to support parallell install of binaries in a way that gives each arch its own file. But still, regardless if you go with a new binary format or with "fat filesystems", you end up blurring the line between native compilation and cross-compilation. An extended FHS would probably have to deal with that. (Fedora doesn't guarantee parallell install of -devel packages, for example.) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
tor 2009-09-24 klockan 16:31 -0400 skrev Seth Vidal: > We're a bleeding edge distro - that's our VAUNTED mission - shouldn't we > be able to assume that users of a BLEEDING EDGE, LATEST PACKAGE distro be > able to run a single command? Though Fedora currently might not currently be an optimal "just works" experience, I think that should be the design goal. I want ordinary people to be able to use free software. (And not just use.) Whether they end up using Fedora, a more polished derivative of Fedora (Sugar on a Stick, XO, RHEL etc.) or another distro that benefit from the work done within the Fedora project doesn't matter that much, but if the Fedora motto turns into "by geeks for geeks" and the project loses sight of ordinary people then it's on the wrong track. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Default heuristics for variable-format displays
Here's my suggestion... def mode_megapixels(mode): return mode.width * mode.height # Sort by best refresh rate. modes.sort(key=lambda mode: -mode['refresh']) # Prefer to balance refresh rate vs. pixels. if dpi_known: acceptable = filter(lambda mode: mode.dpi >= 90, modes) if len(acceptable) > 0: # Anything above 90 DPI is good enough # for a default. # Pick the one with the best refresh. return acceptable[0] # DPI not known or too low, balance refresh vs. pixels. best_megapixels = max(modes, mode_megapixels) acceptable = filter(lambda mode: megapixels(mode) >= best_megapixels / 2) # Pick the mode with the highest refresh rate and at least # half the max possible number of pixels. acceptable[0] /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish, round three: peripherals
lör 2009-08-08 klockan 13:11 +0100 skrev Peter Robinson: > I saw something a while ago about the DisplayLink (as opposed to > DisplayPort) USB Video standard released code/drivers as GPL for linux > but I've never seen anything further about it even in my random > following of the X mailing lists. There is activity on the wiki: http://libdlo.freedesktop.org/ /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pulseaudio 0.9.15 for F10?
lör 2009-08-08 klockan 19:32 +0200 skrev Roberto Ragusa: > Roberto Ragusa wrote: > > After applying this patch, mplayer does not get stuck, it is just the usual > > latency/skips/underruns... > > Wrongly pasted the patch. Corrected one follows: You should find an existing bug report in bugzilla.redhat.com or file a new report about this problem, and attach the patch there. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: An easy way to redefine configure?
tis 2009-08-04 klockan 12:14 +0300 skrev Jussi Lehtola: > What's the correct way to do this? I don't know about correct, but this should work: mkdir foo cd foo cat >configure <<'EOF' #!/bin/bash exec ../configure "$@" EOF chmod 755 configure %configure /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing Fedora with software based synthesizer for sceenreader
Den 2009-06-30 09:28, Caolán McNamara skrev:
Is is possible to *install* Fedora using our accessibility support out
of the box, specifically do we have support for installing fedora and
have a software based synthesizer available for the screen reader during
installation ?
I suppose the live image is probably the easiest way. Are all the
required components included? Also, an accessible method of enabling
them would be required. Then, is Anaconda/liveinst accessible if run in
a suitably configured desktop session?
Making {pxe,iso,sys}linux accessible and adding an option there would be
one way, but that seems hard or not very good. (Press 'a' when it goes
"bleep blaap" or something like that.)
Perhaps the two LiveUSB tools we have could benefit from options that
will enable the a11y bits for the live desktop session? (Probably by
adding yet another kernel command line option.) That way one could even
use an accessible Windows desktop to create an a11y-enabled Fedora
LiveUSB. (Is liveusb-creator and Gtk2 on Windows accessible?) Care would
perhaps need to be taken to make sure that a11y is also enabled by
default in the Fedora installation that liveinst produces, though that's
not as important because GDM does have an accessible way to enable a11y.
/abo (who could cross-post this all over the place considering how much
it covers, but won't)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-25 13:07, Simon Andrews skrev: If all anaconda upgrades are going to be online Anaconda upgrades initiated through Preupgrade do not require a network connection. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-24 20:55, Avery, David [DENTK] skrev: The problem is preupgrade normally pulls from release + updates, pulling from the DVD even now will not work because F10 + updates has newer file versions than are on the DVD. Nothing (AFAICT) prevents Preupgrade from pulling both from a DVD and from the net. That will save as much bandwidth as you save by upgrading from the DVD directly, but it will actually work. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
Den 2009-06-24 11:37, Simon Andrews skrev: So, just to be clear here. Anyone who either has no network connection or whose network connection is too slow to support downloading potentially hundreds of megs up updates isn't going to be able to upgrade any more? Preupgrade could install a hook that recognises distro DVDs (or even CDs) when inserted in a running system, prompting the user "Would you like to upgrade to ?", which would just run Preupgrade as usual, copying packages off the disc if possible. /abo -- 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)
Den 2009-06-18 05:10, Bill Nottingham skrev: 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. Yeah, but frankly, there's a difference between producing cutting edge software and requiring newer hardware... Sometimes they go hand in hand. Though I guess updating the compiler flags means using other/newer/better code in the compiler, which is a form of software improvement. /abo -- 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
Re: Changing the default 32-bit x86 arch for Fedora 12
Den 2009-06-17 03:07, Josh Boyer skrev: Someone else ask what the real benefit to moving to i686+SSE2 is. I haven't seen overwhelming evidence that a huge benefit exists. I think somone is working on gathering more data, but unless it shows massive gains To be relevant, such data gathering should be performed on non-x86_64 capable CPUs, because there are already fully optimized Fedora packages for x86_64. So that's Pentium 4, Pentium M or their Celeron or Xeon versions, Atom or VIA C7. There does not seem to be any AMD CPUs that supports SSE2 but does not support x86_64. /abo -- 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
Moving to i686+SSE2 while still keeping full support for i586 would imply: * A secondary arch * Bits in preupgrade/anaconda to pick the secondary arch on upgrade * Extra confusion on the download page Of course, those aren't all hard requirements, but still, I doubt it's worth the trouble... /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
