date:20110502

[Bug 636803] Update mldonkey to ver. 3.0.5

2011-05-02 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=636803

--- Comment #4 from 甘露(Gan Lu) rhythm@gmail.com 2011-05-02 04:20:41 EDT 
---
I think Fedora is a great distro, and its community is quite good, but I am
using Arch Linux, this may be the reason:
https://bugs.archlinux.org/task/22984

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

Re: adding manual to existing package - soft review ?

2011-05-02 Thread Ville Skyttä

On 05/02/2011 01:48 AM, David Timms wrote:
 The -manual package can be used by either audacity or 
 audacity-freeworld. At the moment the manual spec marks up the 
 datadair/audacity folder and hence dually owns it with audacity if that 
 is installed. Reading the packaging examples, seems that this can 
 sometimes be OK, but does what I've done make sense ?

Seems to make sense if you don't want to add a dependency to either package.

 Or should I Require the audacity (or audacity-freeworld) package, and 
 not add the datadir/audacity folder to the -manual directory.

No opinion on that (don't know enough about it), but if you do, you can
accomplish the or by adding a dependency on /usr/bin/audacity.

 Thirdly, vague recollection of one source/package. Should the -manual 
 just be a separate package anyway (review?) ? It's likely to be updated 
 more often, but not necessarily in sync with the program.

I'd lean towards making it a completely separate subpackage then.  But
whichever way you choose, the manual should be kept in sync with the
main package so that it documents whatever is in the main package, not
earlier nor newer version of the software.

If the intent is to make the manual installable without installing
audacity itself, I'd also consider installing the manual to let's say
/usr/share/doc/audacity-manual and patching the main packages to use it
from there, I think that's a location where people are more likely to
find it than /usr/share/audacity/help.

 4. Being new to git/fedpkg, how can I tell which branch I'm on ?

git branch.

If you use bash, here's how you get it shown directly in your prompt:
http://fedoraproject.org/wiki/Git_Quickref#Display_current_branch_in_bash
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package with x86 vector instruction support

2011-05-02 Thread Christoph Frieben

On Wed, Apr 20, 2011 at 5:27 PM, Jussi Lehtola wrote:
 x86_64: plain and sse2

This does not look good to me, because the x86-64 instruction set only
includes sse2. sse3 is not available on every amd64 processor and thus
should not be used by default. The maintainer should rather build the
base package for sse2 and create an sse3 optimized subpackage
atlas-sse3. Otherwise illegal instruction errors can occur
unexpectedly.
~C
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [solved] illegal instruction - create compile variants ?

2011-05-02 Thread David Timms

On 02/05/11 11:01, Reindl Harald wrote:
 the application must cpu-runtime-detect itself what means taht for
 performance-critical parts different code is included and at
 the start the application checks what code-parts have to be used

 but this is nothing anybody can make generic by packaging if
 the developer do not support native nor you can analyze the
 binary to find this out
OK, thanks all responders for clear logic and possible solutions.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: illegal instruction - create compile variants ?

2011-05-02 Thread Hans de Goede

Hi,

On 05/01/2011 09:56 AM, David Timms wrote:
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 on all systems Fedora
supports.
Where is that stated currently, and for older releases ?

I was hoping someone who knows the exact answer knows... All I can give
you is:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html#sect-Release_Notes-Hardware_Requirements

Which is not really exact...

No tricks / hacks with multiple compilation, cpu detect scripts, etc.
will be necessary then.
Though it comes at the cost of audio lag/latency increase when we are
trying to achieve near real time (eg live guitar input to sound effect
generation output). Even on the my machine (4x core amd 3Ghz), the
calculations the app performs for difficult presets (convolution) can
cause jack to abort because rakarrack didn't finish it's calculations
before it was required to deliver data.

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) ?

As already answered by others ideal would be one binary, which runtime
chooses between normal C and mmx/sse#/whatever variants based
on CPU capabilities.

This is definitely something to ask to upstream, as this won't
be trivial.

In the mean time, you need to patch the build-system so that
you can control what cpu features it will enable, then you
can build a number of variants, install them as
/usr/libexec/%{name}-$cpufeaturepostfix

And make /usr/bin/%{name} a shell script which checks
/cpu/procinfo for features and then executes the right
binary (passing through all cmdline args using the
$@ magic var for proper quoting)

For which variants it makes sense to build, you would
need to talk to someone who is more of a cpu head then me,
try starting a new thread, with an appropriate $subject.

Note that all of this is only really needed on 32 bits,
on 64 bit I believe (*) all cpu's have at least sse2, so unless
you want to use sse3 you'll only need 1 binary there.

79 matches

Mail list logo