On Sun, Jun 5, 2011 at 12:18 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
> On 06/05/2011 02:10 AM, Chris Tyler wrote:
>> On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
>>>  We're making a "one time" incompatible ABI switch in F-15 bringup to
>>> the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly
>>> referred to as the ARM EABI - but that doesn't actually exist as a
>>> name). The procedure call standard will be ARM AAPCS vfpv3-d16, as
>>> defined in section 6 of that document. Other distros are switching and
>>> this will form the basis of any LSB standardization effort later on.
>>> Think of v7 and v5 as being different arches, which they are really.
>> And to further clarify:
>> - This is an addition, not a switch -- the intention is to continue to
>> support armv5tel in addition to armv7hl at this time -- Tegra and
>> Marvell Kirkwood (including plug computer) devices which do not support
>> armv7hl will continue to work with armv5tel.
>> - The significant incompatibility is hardfp vs. softfp ABI (moreso than
>> v7 vs. v5).
> So would it not be more sensible to make the distro ARMv7 without NEON?
There's no mention of NEON above. Where do you get that idea from?
I am seeing a metric ton of extensions showing up for Gnome shell that
are enhancing the shell in positive ways. Some are packaged singly;
some are grouped together in bundles; some are configured by editing
.js files directly. I am hesitant to install any of them because of
the manual, bolted on feel of them and the risk of them causing
trouble in the future.
Is there some sort of extension management planned that would handle
the separate enabling/disabling/configuration of individual extensions
via the grand unified Settings menu?
If this is under way, could extension makers be pointed towards it to
future-proof their extensions.
If not then I think it needs to be introduced early to avoid the mess
that is beginning to develop.
On Wed, 2011-06-01 at 12:25 +0100, Luke Kenneth Casson Leighton wrote:
> sooo... although the situation *right now* is that nobody in the
> commercial world is the slightest bit interested in LSB because they
> all do "custom builds" of complete software stacks, it could be said
> that *if* the free software community just dropped ready-to-go LSB
> standards in front of their noses, they'd quite likely use it.
The reason we're discussing this is because a new architecture isn't
going to be supported in standards like LSB overnight. It might take
some time, and by that time, things may have changed with respect to the
adoption of ARM systems. But if we don't think ahead, we're forced to be
reactionary and try to do this (probably less effectively) later on.
Nobody will be forced to adopt LSB, but general purpose distributions
can benefit from having compatibility at the software level. Is this an
issue for deeply embedded platforms? Not so much. Is it bad that Android
rebuilds the Universe? It's their decision to make. I think we need to
distinguish between traditional embedded uses of ARM parts, which will
continue, and those of larger parts running general a purpose OS. I
don't expect to see Fedora running on my cellphone, but I do have it
running on a netbook quite nicely - the latter needs LSB more.
I'll leave the rest of the rhetoric alone :)
It seems to me that as a general observation, package sizes are either
stable or coming down in size. And even the total size of the Fedora
Live CD has dropped significantly.
I installed Fedora 15 a couple of days ago. After fully updating, I
couldn't help but notice the amount of updates and packages that were
downloaded and installed for a relatively small total download.
After updating to the latest packages, I proceeded to install Java and
Flash plugins. Flash is a different situation so I won't go into that
in this post. That discussion is for another day.
But whilst installing the Java web-browser plugin, I observed that
it's not its dependancies that suck up the size but rather the
physical java packages themselves. And I just don't understand what
makes Java packages so big and bulky? I mean, I can install The GIMP
(a full image editing package) in under 10MB.
Perhaps someone can shed some light on this and perhaps more effort
put into bringing down the size of java packages, if possible?
This message was sent using IMP, the Internet Messaging Program.
it seems that rpmbuild runs prelink nowadays, since in Fedora 15 I have
run into a problem that I haven't seen before when packaging
proprietary 3rd party software.
The error is
prelink: (file name here) at least one of file's dependencies has
changed since prelinking
The cause of the problem is probably that the files in question have
been compiled with a proprietary compiler.
Does anyone know what causes the error and how I can get around it?
Fedora Project Contributor
Maybe it's common knowledge already but the 3.0 / 3.0.0 thing has led to
the uname -r of the kernel not matching the packaged module path.
Your boot will be a "bit minimal" until you stick a symlink in along the
lines of -->
ln -sf /lib/modules/3.0-0.rc1.git0.1.fc16.x86_64