Kevin Kofler wrote:
> AFAIK, you can only use ExcludeArch for noarch packages, not
ExclusiveArch.
A search reveals that Matthias Saou ran into this problem in 2007:
http://www.redhat.com/archives/fedora-maintainers/2007-May/msg00738.html
It was recommended that a ticket be opened against k
I wrote:
> package: clapham-0.1.003-4.el6.noarch from fedora-epel-testing-6-ppc64
> unresolved deps:
>java>= 1:1.6.0
Ville Skyttä wrote:
> This is not an answer to your question, but if the above is exactly as
> is from the mail you received, something needs a fix: the dependency is
>
Am 02.05.2011 00:50, schrieb David Timms:
> Further, what can I run over an existing executable to detect what CPU
> it was built for, ie what instuctions have been included?
not really
the application must cpu-runtime-detect itself what means taht for
performance-critical parts different code
On Mon, May 02, 2011 at 08:50:48AM +1000, David Timms wrote:
> On 02/05/11 06:31, Kevin Kofler wrote:
> > David Timms wrote:
> >> Should I be suggesting to upstream to attempt to detect CPU before
> >> running non-available instructions, eg as part of app startup ?
> Further, what can I run over an
Compose started at Sun May 1 13:15:39 UTC 2011
Broken deps for x86_64
--
claws-mail-plugins-geolocation-3.7.8-8.fc15.x86_64 requires
libchamplain-gtk-0.8.so.1()(64bit)
claws-mail-plugins-geolocation-3.7.8-8.fc15.x86_64 requi
On 02/05/11 06:31, Kevin Kofler wrote:
> David Timms wrote:
>> Should I be suggesting to upstream to attempt to detect CPU before
>> running non-available instructions, eg as part of app startup ?
Further, what can I run over an existing executable to detect what CPU
it was built for, ie what inst
Hi, I'm adding a subpackage -manual to audacity to include the
additional manual archive. It links from the help menu items if it is
installed, or else points you to the in development online version.
I already made a mistake and included manual files in both the main and
sub package. The spec
Eric Smith wrote:
> Is there some way to have a noarch package that only builds for (or is
> only pushed for) specific architectures? Or is there some other correct
> resolution for this kind of problem?
AFAIK, you can only use ExcludeArch for noarch packages, not ExclusiveArch.
Kevin Ko
Michael Schwendt wrote:
> Rather find and fix the bug that is the cause of this. There have been
> a few updates like that recently, again.
>
> The 3.1.10-1.fc14 package is tagged dist-f14-updates already:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
>
> So, during the compose
David Timms wrote:
> Should I be suggesting to upstream to attempt to detect CPU before
> running non-available instructions, eg as part of app startup ?
Yes, this is the ONLY solution that's acceptable for binary packaging in
distributions. Otherwise, we can only build the most generic version.
Hans de Goede wrote:
> Erm, specifying a minimum support CPU in the package description is
> not acceptable IMHO. The fix here is to patch the packages buildsystem,
> so that it gets build for the minimum cpu level which is supported by
> Fedora, and thus will work out of the box on all systems Fed
Dne 1.5.2011 03:04, Kevin Kofler napsal(a):
> - or you'll do this, upstream will reject it just because and we end up with
> forked-forked-daapd… ;-)
Given my level of proficiency in C, the most likely scenario is that I
won't have forked-daapd server for some time more. Oh well.
Matěj
--
deve
On Sun, 1 May 2011 16:31:29 +0200, me wrote:
> > Please can the maintainers of thunderbird push thunderbird 3.1.10 again?
>
> Rather find and fix the bug that is the cause of this. There have been
> a few updates like that recently, again.
>
> The 3.1.10-1.fc14 package is tagged dist-f14-update
On Sun, 01 May 2011 15:53:10 +0200, CK wrote:
> Hi,
>
> Beginning of today "package-cleanup --orphans" reports
> thunderbird-3.1.10-1.fc14.i686 as orphan in F14.
>
> "yum clean all; yum list thunderbird" reports thunderbird-3.1.9-2.fc14
> as newest thunderbird package in the repositories. Howeve
Hi,
Beginning of today "package-cleanup --orphans" reports
thunderbird-3.1.10-1.fc14.i686 as orphan in F14.
"yum clean all; yum list thunderbird" reports thunderbird-3.1.9-2.fc14
as newest thunderbird package in the repositories. However, at one point
in time thunderbird-3.1.10-1.fc14.i686 must h
Am 01.05.2011 09:56, schrieb David Timms:
> Should I be suggesting to upstream to attempt to detect CPU before
> running non-available instructions, eg as part of app startup ?
> Can that even be done (reliably)?
ffmpeg has since years a option "--enable-runtime-cpudetect" what makes the
binary
On Sun, May 01, 2011 at 05:56:57PM +1000, David Timms wrote:
> Should I be suggesting to upstream to attempt to detect CPU before
> running non-available instructions, eg as part of app startup ?
> Can that even be done (reliably) ?
This is exactly what they should be doing, and yes it can be don
On 05/01/2011 09:57 AM, Steven Yong wrote:
> On Sun, May 1, 2011 at 11:49 AM, Pete Zaitcev wrote:
>> Just use Gnote. It being in C++ you can even maintain it for Fedora.
>>
> Is Gnote orphaned now too?
No. I just pushed a new upstream release as an update for Fedora 15.
https://admin.fedorapro
Compose started at Sun May 1 08:15:02 UTC 2011
Broken deps for x86_64
--
beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit)
beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit)
beldi-0.9.25-3.fc15.x8
On 05/01/2011 09:46 AM, Eric Smith wrote:
> package: clapham-0.1.003-4.el6.noarch from fedora-epel-testing-6-ppc64
>unresolved deps:
> java>= 1:1.6.0
This is not an answer to your question, but if the above is exactly as
is from the mail you received, something needs a fix: the dependen
On 01/05/11 17:41, Hans de Goede wrote:
> Erm, specifying a minimum support CPU in the package description is
> not acceptable IMHO. The fix here is to patch the packages buildsystem,
> so that it gets build for the minimum cpu level which is supported by
> Fedora, and thus will work out of the box
Hi,
On 05/01/2011 09:14 AM, David Timms wrote:
> On 01/05/11 16:47, Ralf Corsepius wrote:
>> Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS,
>> which packages are supposed to respect.
> Yes, I still have VSs bug (514991) regarding opt flags still open.
>
> So, for the lesser CP
On 01/05/11 16:47, Ralf Corsepius wrote:
> Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS,
> which packages are supposed to respect.
Yes, I still have VSs bug (514991) regarding opt flags still open.
So, for the lesser CPU problem, does that mean I just suggest, rebuild
srpm o
23 matches
Mail list logo
