I've got a question whose answer I expected to find on one of these
pages, but no joy:
https://fedoraproject.org/wiki/Architectureshttps://fedoraproject.org/wiki/Architectures/x86https://fedoraproject.org/wiki/Architectures/x86-64
I'm packaging a library that does some heavy mathematical
computations. The build system tries to cleverly determine whether an
Intel CPU with vector instructions is being used. Until I can
convince upstream to do this at runtime, I'll need to build the
package (a library) for the lowest common denominator. The package
checks for MMX, SSE, SSE2, SSE3, and SSSE3. For i686, can I assume
MMX? SSE? I believe I can also build an SSE2 version of the library
and drop it into /usr/lib/sse2. How about for x86_64? Can I assume
SSE2 is available? (I thought I could, but I see that /usr/lib64/sse2
exists on my machine, so now I'm uncertain.) I don't see a
/usr/lib64/sse3 or /usr/lib64/ssse3, so I just have to forget those,
right?
If there is a wiki page that answers these questions, I'd appreciate a
pointer. If not, perhaps someone with edit privileges could add the
answer to one of the pages listed above. Thanks,
--
Jerry James
http://www.jamezone.org/
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 change [1] I've committed fixes this.
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 ?
Or should I Require the audacity (or audacity-freeworld) package, and
not add the datadir/audacity folder to the -manual directory.
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.
4. Being new to git/fedpkg, how can I tell which branch I'm on ?
[1]
<http://pkgs.fedoraproject.org/gitweb/?p=audacity.git;a=blob_plain;f=audacit…>
My package for clapham, a railroad diagram generator, was recently approved:
https://bugzilla.redhat.com/show_bug.cgi?id=668240
There's no problem with Rawhide, F15, and F14, but I ran into a problem
with EL6. The package is noarch (being pure Java), and it seems to be
fine with i686 and x86_64, but he update system notified me of broken
dependencies for the PPC64 arch:
package: clapham-0.1.003-4.el6.noarch from fedora-epel-testing-6-ppc64
unresolved deps:
java>= 1:1.6.0
batik
I expect that this is true for other architectures as well. The problem
seems to be that the batik library only builds on x86-64 and i686 (using
an ExclusiveArch tag). Perhaps that is due to java-1.6.0-openjdk not
being available on other architectures, though I didn't research that
since the lack of batik is sufficient to prevent clapham from building.
I thought perhaps the appropriate thing to do would be to add the same
ExclusiveArch tag to clapham, but that results in not being able to
build at all, apparently because of clapham being a noarch package:
$ rpmbuild --rebuild clapham-0.1.003-5.fc16.src.rpm
Installing clapham-0.1.003-5.fc16.src.rpm
error: Architecture is not included: noarch
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?
Thanks!
Eric
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, I'm new to contributing but not new to Linux. I started on RHL 7.1
around 2000 and have used Slackware, Gentoo and Debian in the past. I
was active at my university LUG and Gaming Club (running the game
servers on Slackware) and now I work for Red Hat since August 2007 in
support.
I have been building RPMs for myself on and off almost since I started
at Red Hat and switched from Debian to Fedora. I built RPMs for
Rivendell [1] which is a large radio automation suite and some
recommended getting that into Fedora but at the time it seemed too
daunting.
Now I am getting into DJing and in particular using FOSS to do it. I
have used Mixxx and xwax. I am becoming the co-maintainer of Mixxx in
rpmfusion [2] and have just submitted my first package review request
for Fedora for xwax. [3] I would like to make Fedora a good platform
for digital DJing.
Mixxx was affected by a portaudio bug that had been fixed in Ubuntu
but not Fedora so I opened a bug [4] on that and got that fixed.
I have created a mixxx on fedora page for the Mixxx wiki. [5]
My FAS account is John2583 but you can find me on Freenode as
JBstrikesagain (I think that username was too long for FAS).
I am in #fedora and #fedora-devel among other channels.
You can check out my website to see some other stuff I do:
http://cupcakecarnival.net/
1) http://people.redhat.com/~jbrier/rivendell/
2) https://bugzilla.rpmfusion.org/show_bug.cgi?id=1667
3) https://bugzilla.redhat.com/show_bug.cgi?id=700551
4) https://bugzilla.redhat.com/show_bug.cgi?id=691148
5) http://mixxx.org/wiki/doku.php/mixxx_on_fedora
- --
John Brier, RHCA, RHCVA, RHCX
Senior Technical Support Engineer - NA
gpg: 1024D/251D9FF9 6F7B 242A 9375 F4CC BC6D F453 60D8 35FF 251D 9FF9
http://opensource.com - Where Open Source Multiplies
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk267R4ACgkQYNg1/yUdn/mWIACgo65xXmUXtl1PGIQOWhIGa1yJ
xtYAniwjr8b+tYSuG3rP8oMggoJGjfqo
=fBlB
-----END PGP SIGNATURE-----
On Mon, Apr 18, 2011 at 08:18:23PM -0400, Bill McGonigle wrote:
> Hi, Rich,
>
> I see that you got tagged as owner on the unison packages. Are you
> planning to package any updates, or did you just inherit it by
> default because of its OCaml nature?
Pretty much I inherited it.
> I was going to write a message to -devel, but then I saw Gerard
> didn't own the package anymore, and thought it best to drop you a
> note directly first.
>
> A new stable was declared in January, so we're officially 3 and 6
> years out of date on the existing packages. It turns out many of my
> complaints about unison have been fixed in the past 3 years!
>
> Since I don't know any OCaml and this package probably needs to
> combine 3 versions and label multiple binaries, I shouldn't
> volunteer to build this as my first package. But I'd be happy to do
> some manual builds and share notes if that would be useful.
There was a reason for splitting it in the first place which is to do
with (in-)compatibility between the versions. Because the protocol
sometimes changes incompatibly between releases and because we want to
interoperate with servers which may be running different versions, we
need to package up the different versionse separately. However this
is a big pain to maintain, not least because whenever a new
incompatible version comes along we have to apply for a new Unison
package to be added to Fedora(!)
It's probably going to be better to do something with multiple source
files in a single 'unison' package building multiple sub-packages.
Anyhow if you want to co-maintain it, please check the boxes at
https://admin.fedoraproject.org/pkgdb/acls/list/unison*
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora