On Fri, 2012-02-03 at 02:43 +, Matthew Garrett wrote:
> On Thu, Feb 02, 2012 at 06:25:50PM -0600, David Lehman wrote:
>
> > My understanding is that the so-called "Apple Bootstrap" filesystem
> > required for ppc Macs to boot is HFS. That's what anaconda uses for it.
> > If we could be using H
On Thu, Feb 02, 2012 at 09:54:12PM -0500, Josh Boyer wrote:
> On Thu, Feb 2, 2012 at 9:43 PM, Matthew Garrett wrote:
> > On Thu, Feb 02, 2012 at 06:25:50PM -0600, David Lehman wrote:
> >
> >> My understanding is that the so-called "Apple Bootstrap" filesystem
> >> required for ppc Macs to boot is
On Thu, Feb 2, 2012 at 9:43 PM, Matthew Garrett wrote:
> On Thu, Feb 02, 2012 at 06:25:50PM -0600, David Lehman wrote:
>
>> My understanding is that the so-called "Apple Bootstrap" filesystem
>> required for ppc Macs to boot is HFS. That's what anaconda uses for it.
>> If we could be using HFS+ in
On Thu, Feb 02, 2012 at 05:45:38PM -0800, John Reiser wrote:
> > Does anyone object [to dropping support for HFS]?
>
> Plain HFS has no journal, so there are workloads where HFS is faster
> than HFS+ which has a journal. Is it economical to cater to such cases?
> Probably not. However, I do have
On Thu, Feb 02, 2012 at 06:25:50PM -0600, David Lehman wrote:
> My understanding is that the so-called "Apple Bootstrap" filesystem
> required for ppc Macs to boot is HFS. That's what anaconda uses for it.
> If we could be using HFS+ instead, fine.
Is that created with hfsplus-utils or with parte
Hi All,
Just a reminder that we'll be holding a Fedora kernel meeting in
#fedora-meeting tomorrow at 18:00 UTC. We'll be chatting about
the current state of the Fedora kernel, where we're heading in F17
and what we're going to be looking at otherwise. Feel free to stop
by and ask questions or ma
El Thu, 02 Feb 2012 17:45:38 -0800
John Reiser escribió:
> > Does anyone object [to dropping support for HFS]?
>
> Plain HFS has no journal, so there are workloads where HFS is faster
> than HFS+ which has a journal. Is it economical to cater to such
> cases? Probably not. However, I do have a
> Does anyone object [to dropping support for HFS]?
Plain HFS has no journal, so there are workloads where HFS is faster
than HFS+ which has a journal. Is it economical to cater to such cases?
Probably not. However, I do have a PowerPC Mac Mini that runs plain HFS
and Fedora 10 with ext3.
--
-
On Fri, 2012-02-03 at 00:15 +, Matthew Garrett wrote:
> There's various issues with the hfsplus utilities we ship at the moment,
> including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
> update this to the latest upstream, but code to generate legacy HFS (ie,
> pre-HFS+) filesy
There's various issues with the hfsplus utilities we ship at the moment,
including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
update this to the latest upstream, but code to generate legacy HFS (ie,
pre-HFS+) filesystems has been dropped.
HFS+ was introduced in MacOS 8.1 in 1998
Florian Müllner wrote:
> [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html
KDE might actually adopt dconf for KDE Frameworks 5, though this seems to be
still under discussion:
http://community.kde.org/KDE_Core/Platform_11/Settings
Kevin Kofler
--
devel mailing list
devel@l
On 01/30/2012 02:34 PM, Krzesimir Nowak wrote:
I guess that Q_DECLARE_FLAGS macro for QItemSelectionModel overrides
this operator.
Possible workaround for it would be:
ClearAndSelect = static_cast(Clear) | static_cast(Select)
That compiled at least. Thanks!
--
Orion Poplawski
Technical Man
Florian Müllner wrote:
> The discussion was about GNOME shell's top bar. No application (GNOME,
> KDE, Unity or whatever) can add anything there (using XEmbed,
> NotifierIcon, libnotify or whatever).
That's exactly the source of the complaint: Only stuff hardcoded inside
gnome-shell (or written
Matthew Garrett wrote:
> And the people working on Gnome feel that adopting a bad specification
> would cost more than enhancing this interoperability would provide.
And that's exactly my complaint: GNOME doesn't give a darn about
compatibility with other desktops and isn't willing to make ANY sa
On Thu, Feb 2, 2012 at 9:59 PM, Kevin Kofler wrote:
> Florian Müllner wrote:
> > It is not implemented with XEmbed.
>
> If the user runs non-GNOME software which tries to bring up a system tray
> icon, it is.
The discussion was about GNOME shell's top bar. No application (GNOME, KDE,
Unity or w
On Thu, Feb 02, 2012 at 10:04:03PM +0100, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Samba is a project written specifically to interoperate with Windows,
> > because the developers involved felt that interoperability was more
> > important than the flaws in the SMB spec (to the extent that a
Matthew Garrett wrote:
> Samba is a project written specifically to interoperate with Windows,
> because the developers involved felt that interoperability was more
> important than the flaws in the SMB spec (to the extent that any such
> thing existed).
My point is that interoperability between t
Florian Müllner wrote:
> It is not implemented with XEmbed.
If the user runs non-GNOME software which tries to bring up a system tray
icon, it is. The icon will not only be hidden in your legacy compatibility
grace popup, but also be rendered using XEmbed. As I explained, both kdelibs
and libap
On 02/03/2012 12:42 AM, Kevin Kofler wrote:
> Stijn Hoop wrote:
>> Is there a bug we can vote on? I also agree 100% with this, I rather
>> like gnome-shell except for this 'notification system'.
>
> You seriously still think that GNOME will listen to its users??? You gotta
> be kidding!
You are
On Thu, Feb 02, 2012 at 08:19:44PM +0100, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > The answer still resulted in a spec that permitted compliant
> > implementations to have no practical interoperability.
>
> You keep repeating that, yet I still don't see ANYTHING backing that
> assertion.
On Thu, Feb 2, 2012 at 8:19 PM, Kevin Kofler wrote:
> Matthew Garrett wrote:
>> The answer still resulted in a spec that permitted compliant
>> implementations to have no practical interoperability.
>
> You keep repeating that, yet I still don't see ANYTHING backing that
> assertion. Interoperabil
On jue, 2012-02-02 at 20:17 +0100, Kevin Kofler wrote:
> And the thing is, renaming "Tooltip" to "Description" will break all the
> existing implementations and provide no benefit whatsoever to the end user.
> It's just an internal identifier the user will never see. For all I care it
> could be
On jue, 2012-02-02 at 20:11 +0100, Kevin Kofler wrote:
> Florian Müllner wrote:
> > I actually agree to that - if we used the notifier spec in the top bar,
> > we would either compromise on the intended experience, or provide a
> > crappy implementation. Or in other words: the spec is a poor fit fo
Matthew Garrett wrote:
> The answer still resulted in a spec that permitted compliant
> implementations to have no practical interoperability.
You keep repeating that, yet I still don't see ANYTHING backing that
assertion. Interoperability depends only on the protocol (which is clearly
specified
Florian Müllner wrote:
> I was talking about a supposed property called "circle", not a property
> "themedIcon" with a value of "circle". The spec actually contains
> language like this (quoting from memory, as the link to the draft on
> freedesktop.org is dead):
>
> "Tooltip: a descriptive string
On Thu, 2012-02-02 at 20:12 +0100, Kevin Kofler wrote:
> Stijn Hoop wrote:
> > Is there a bug we can vote on? I also agree 100% with this, I rather
> > like gnome-shell except for this 'notification system'.
>
> You seriously still think that GNOME will listen to its users??? You gotta
> be kiddi
On 2 February 2012 12:12, Kevin Kofler wrote:
> Stijn Hoop wrote:
>> Is there a bug we can vote on? I also agree 100% with this, I rather
>> like gnome-shell except for this 'notification system'.
>
> You seriously still think that GNOME will listen to its users??? You gotta
> be kidding!
>
At so
Florian Müllner wrote:
> I actually agree to that - if we used the notifier spec in the top bar,
> we would either compromise on the intended experience, or provide a
> crappy implementation. Or in other words: the spec is a poor fit for
> what we try to achieve, so it makes sense to not use it.
H
Stijn Hoop wrote:
> Is there a bug we can vote on? I also agree 100% with this, I rather
> like gnome-shell except for this 'notification system'.
You seriously still think that GNOME will listen to its users??? You gotta
be kidding!
Kevin Kofler
--
devel mailing list
devel@lists.fedor
Dan Winship wrote:
> http://aseigo.blogspot.com/2008/12/free-dektop-notifications.html
That's not a fair comparison:
* The KDE Plasma Workspace actually *implements* the Galago (notification)
spec now (and has done so for a while), as does Unity. KDE actually *cares*
about interoperability with
On Fri, Jan 27, 2012 at 14:10, Harald Hoyer wrote:
> Hello Testers and rawhide Users,
>
> Fedora 17 will locate the entire base operating system in /usr. The
> directories
> /bin, /sbin, /lib, /lib64 will only be symlinks:
> /bin → /usr/bin
> /sbin → /usr/sbin
> /lib → /usr/lib
> /lib64 → /us
# F17 Alpha Blocker Review meeting #2
# Date: 2012-02-03
# Time: 17:00 UTC [1] (12:00 EST, 09:00 PST)
# Location: #fedora-bugzappers on irc.freenode.net
The second F17 alpha blocker bug review meeting will be this Friday at
17:00 UTC in #fedora-bugzappers. We'll be running through the final
blocke
On 02/01/2012 10:57 PM, Tom Callaway wrote:
> On 02/01/2012 12:24 PM, Jerry James wrote:
>> Yes, the buildroots are both fine now. Thanks for fixing them. I was
>> just responding to spot's apparent surprise that an updated libvpx in
>> the buildroot should have broken package building for other
On Thu, Feb 02, 2012 at 05:26:15AM +0100, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Because it is the job of people who are proposing a spec to answer the
> > objections of the people who perform critical analysis of the spec
>
> They did answer. You just didn't like their answer.
The answ
Let it go kevin ...
I know there are a bunch of gnome happy users (and of course the devs),
but there are probably less now than earlier ...
A limited sample but everyone I know - all of whom were gnome users - no
longer use gnome - they have all switched to either kde or xfce (each
with its own
On 02/02/12 12:42, Rex Dieter wrote:
Would the /usrmove script
replace the hardlink with the softlink?
no.
-- rex
Thanks Rex,
Unfortunatly I'm not a scripter.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
Frank Murphy wrote:
> On 27/01/12 13:10, Harald Hoyer wrote:
>> Hello Testers and rawhide Users,
>>
>> Fedora 17 will locate the entire base operating system in /usr. The
>> directories /bin, /sbin, /lib, /lib64 will only be symlinks:
>> /bin → /usr/bin
>> /sbin → /usr/sbin
>> /lib → /usr/li
On 02/01/2012 01:04 PM, Kevin Kofler wrote:
> Matthias Clasen wrote:
>> After the fruitless discussion on xdg-list, we decided that the spec was
>> not going to help us in implementing the desired user experience.
>
> That's not up to you to decide.
http://aseigo.blogspot.com/2008/12/free-dektop-
On 27/01/12 13:10, Harald Hoyer wrote:
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories
/bin, /sbin, /lib, /lib64 will only be symlinks:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
if before the
Hello,
I've taken these:
pfscalibration
pfstmo
pfstools
I do use them occasionally but I know nothing about their internals. I just
don't want those packages to be purged out of Fedora. I will happily pass
them to somebody else or welcome any co-maintainers.
Regards,
--
Tomáš Sme
On jue, 2012-02-02 at 01:16 +0100, Kevin Kofler wrote:
> Then your implementation in gnome-shell would just be half-assed and crappy,
> just like your implementation of the XEmbed-based spec is. Unlike the
> XEmbed-based spec, the status notifier spec actually allows apps to specify
> whether th
On jue, 2012-02-02 at 00:44 +0100, Kevin Kofler wrote:
> >> So the argument that you're refusing to implement a cross-desktop
> >> protocol in order to ban random applications from adding themselves to
> >> the panel is bogus.
> >
> > Nobody said that.
>
> Florian Müllner did:
Not really. We did
On jue, 2012-02-02 at 01:28 +0100, Kevin Kofler wrote:
> Florian Müllner wrote:
> > No, but it would require that "circle" is drawn as circle and not a
> > square (or just discarded without notice). The NotifyIcon spec
> > explicitly allows either absurdity.
>
> If your icon theme thinks a square
On mié, 2012-02-01 at 17:00 -0700, Adam Williamson wrote:
> Yay cross-desktop maybe, but still a freaking disaster from a UI point
> of view, and the only thing I really dislike about GNOME 3
I don't think it's that bad, but that might just be me having different
use patterns (for instance a comm
On jue, 2012-02-02 at 05:26 +0100, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Because it is the job of people who are proposing a spec to answer the
> > objections of the people who perform critical analysis of the spec
>
> They did answer. You just didn't like their answer.
Their answer wa
Daniel J Walsh wrote:
> On 01/31/2012 12:07 PM, Jerry James wrote:
>> After installing today's Rawhide updates on an x86_64 VM, I
>> started having troubles running programs. Nothing linked with
>> libselinux.so.1 could actually open that library; the programs were
>> getting EACCESS on the attem
On Thu, 2012-02-02 at 08:27 +0100, Stijn Hoop wrote:
> On Wed, 01 Feb 2012 17:00:30 -0700
> Adam Williamson wrote:
> > I realize this isn't a very constructive mail, and the point has been
> > raised before, but I'm hoping at some point the sheer weight of
> > complaints will cause someone more
47 matches
Mail list logo
