Re: Cannot change fedora-cvs flag on bugzilla
On Fri, 23 Nov 2012 15:05:47 + Jamie Nguyen j...@jamielinux.com wrote: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Your bugzilla email has to be the same as the FAS email. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MPI updates
On Thu, 01 Nov 2012 09:08:36 -0600 Orion Poplawski or...@cora.nwra.com wrote: Some MPI updates: - I built openmpi 1.6.3 in rawhide yesterday. This had an unexpected bump in the libmpi_f90.so soname. I know this affects hdf5 and netcdf-fortran, both my packages and I'll be rebuilding them later today (hopefully). Given that f18 has 1.6, I believe the same update should be made on f18 as well. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu Unity has been ported to Fedora 17
On Thu, 19 Jul 2012 13:49:15 +0200 Antonio Trande anto.tra...@gmail.com wrote: 2012/7/19 Conan Kudo (ニール・ゴンパ) ngomp...@gmail.com This morning, I woke up to the news that a group of developers have managed to successfully make Ubuntu's Unity Desktop work on Fedora 17[1]. What kind of work would be needed to get these people to be able to bring their work into the Fedora repository so that everyone can easily choose to use it without breaking stuff? [1]: http://www.omgubuntu.co.uk/2012/07/unity-desktop-available-for-fedora (clip) This part worries me But, and this needs to be noted, updating with this repo added *will* replace some core GNOME components with Unity-compatible versions. Lol, as if that isn't enough, looks like they ship their own version of GCC 4.6 as well in the repo... -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu Unity has been ported to Fedora 17
On Thu, 19 Jul 2012 20:29:13 +0200 Ralf Corsepius rc040...@freenet.de wrote: On 07/19/2012 07:01 PM, Jussi Lehtola wrote: Lol, as if that isn't enough, looks like they ship their own version of GCC 4.6 as well in the repo... I don't know what Ubuntu has been doing so far, but to be fair, probably all major Linux distros and, on a more general scope probably all OSes ship their own (more or less heavily modified) versions of GCC for many years - Neither Fedora nor RH are exceptions from this. Sure, but my point was that repos for single packages rarely do that. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
On Tue, 17 Jul 2012 10:17:59 +0800 Mike Manilone crtm...@gmx.us wrote: 於 一，2012-07-16 於 22:02 -0400，Paul Wouters 提到： On Tue, 17 Jul 2012, Mike Manilone wrote: I think we can create a new repo called security like Debian. Push all the security updates to it. Uhm, we have that. It is called RHEL Paul No money to buy. :-) CentOS, Scientific Linux, ...? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Fri, 6 Jul 2012 16:55:19 -0400 Bill Nottingham nott...@redhat.com wrote: Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. That is currently scheduled to happen on or around August 7th. Package ape (fails to build) Whoops, this one slipped under my radar. Fixed. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Octave api bump coming up
Hi, Octave 3.6.0 was released yesterday, so I'm updating the rawhide branch to 3.6.0. This causes an API bump, causing the need to rebuild all octave related packages. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARPACK soname bump [Was Re: ARPACK - Change of upstream]
FYI, ARPACK 3.0, featuring a soname bump, has been built in rawhide. If it becomes necessary, I'll build the update in released branches as well. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
On Mon, 12 Dec 2011 21:34:12 +0100 Tomas Mraz tm...@redhat.com wrote: On Mon, 2011-12-12 at 15:21 -0500, Stephen Gallagher wrote: On Mon, 2011-12-12 at 13:16 -0700, Ken Dreyer wrote: On Mon, Dec 12, 2011 at 12:24 PM, Stephen Gallagher sgall...@redhat.com wrote: * #715 Provenpackager education/status/brainstorming (sgallagh, 18:43:02) There was some discussion a while back about preventing certain extensions from being uploaded to the lookaside cache. Could .patch be added to that list? Of course, a whitelist might be a better idea. Maybe we only allow .tar.gz, .tar.bz2 and .zip to be uploaded this way and make additional exceptions as they arise. What about running a 'file' command on the stuff and if the output contains 'text' then allow upload only with some kind of --force option? And what about separately shipped license files, documentation and so on? Not a valid option. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ARPACK - Change of upstream
Hi, ARPACK used to be a project at Rice University [1], but they abandoned it many years ago. After that many projects (e.g. Octave and Scilab) started bundling their own patched versions of the software to fix the bugs they had found in the package. The Fedora and Debian packages had their own patches as well. Recently, a collaboration has picked up the pieces and started maintaining a new fork of ARPACK [2]. Can I just change the arpack package to use the new tarballs, or does using them require a re-review of the software? [1] http://www.caam.rice.edu/software/ARPACK/ [2] http://forge.scilab.org/index.php/p/arpack-ng/ -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ARPACK soname bump [Was Re: ARPACK - Change of upstream]
On Sun, 11 Dec 2011 19:41:13 + José Matos jama...@fc.up.pt wrote: On 12/11/2011 06:46 PM, Jussi Lehtola wrote: ARPACK used to be a project at Rice University [1], but they abandoned it many years ago. After that many projects (e.g. Octave and Scilab) started bundling their own patched versions of the software to fix the bugs they had found in the package. The Fedora and Debian packages had their own patches as well. Recently, a collaboration has picked up the pieces and started maintaining a new fork of ARPACK [2]. Can I just change the arpack package to use the new tarballs, or does using them require a re-review of the software? [1] http://www.caam.rice.edu/software/ARPACK/ [2] http://forge.scilab.org/index.php/p/arpack-ng/ What is the prospect of adoption from those packages that use arpack? If the new package becomes the de-facto upstream for arpack I would say that it does not need a new review it is just the upstream url source that has changed. As the new project ships a maintained, up-to-date version, the need for bundling bug-fixed versions of ARPACK has disappeared and the projects have started to unbundle their own flavors of ARPACK. On the Fedora side, we'll just drop any patches currently present in the ARPACK package (which have become part of the new upstream release) and rebuild. If no-one disagrees to the procedure, I'll push the new version to rawhide as soon as upstream adds the missing libtool script in the tarball. Furthermore, since the library is only used by freefem++, I might as well push the version to other branches, too, so that removing the bundles can be done in them as well. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost soname bump
On Sun, 20 Nov 2011 08:05:34 -0600 Bruno Wolff III br...@wolff.to wrote: It looks like there was a soname bump in boost yesterday. Boost affects enough stuff, that there really should have been a heads up message posted to the devel list about this. +1 Is the bump for real this time? I remember that some time ago the soname was bumped but then returned, so I had to do two unneeded builds. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
On Fri, 18 Nov 2011 16:32:23 + Paul Howarth p...@city-fan.org wrote: On Fri, 18 Nov 2011 15:28:27 + Andrew Haley a...@redhat.com wrote: On 11/18/2011 11:31 AM, Paul Howarth wrote: One of my packages, pptp, suffers occasional segfaults as reported in http://bugzilla.redhat.com/749455. However, whilst investigating this, it seems to be the case that simply rebuilding the package using no optimization (-O0) as opposed to the default -O2 is enough to stop this happening. (clip) This is unlikely to be a gcc bug. Does the upstream package segfault? Upstream's Makefile uses -O0 and doesn't appear to segfault (probably as a result). Paul. .. but https://bugzilla.redhat.com/show_bug.cgi?id=749455 it's shown that the upstream makefile uses -Wall -O -Wuninitialized -g. According to the gcc man page, -O is equal to -O1. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdf5-1.8.8 in rawhide
On Wed, 16 Nov 2011 17:08:27 -0700
Orion Poplawski or...@cora.nwra.com wrote:
hdf5-1.8.8 is now in rawhide. Any packages that build against hdf5
need to be rebuilt. I've already done R-hdf5 and gdl. Note that
there is no soname bump but the hdf5 library checks that the runtime
and compile time versions are the same and aborts if they are not.
Probably good to have all hdf5 users do a:
Require: hdf5 = 1.8.8
.. so please just add an rpm macro in the hdf package, that handles
numbering automatically, so that we can just
Requires: hdf5 = %{hdf5ver}
in the related packages.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Gary T. Giesen
On Tue, 01 Nov 2011 19:50:38 +0100 Christoph Wickert christoph.wick...@googlemail.com wrote: Am Dienstag, den 01.11.2011, 19:36 +0100 schrieb Sven Lankes: On Sun, Oct 23, 2011 at 11:15:20PM +0200, Sven Lankes wrote: Does anyone know how to contact Gary T. Giesen? I've sent him an email (also CCed on this one) a few months ago requesting co-maintainer status for daemonize without a response. Gary has two open bugs without a response: https://bugzilla.redhat.com/show_bug.cgi?id=701383 https://bugzilla.redhat.com/show_bug.cgi?id=746783 His last koji build was in July 2009 - 27 months ago. No change here. I haven't received a reply so I'm requesting his packages to be orphaned. I would like to take daemonize and rancid. I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers No really. You should have done this in the bug reports in BZ and not on the mailing list. 2 Attempts in BZ are the first step, then comes the mailing list and (my personal opinion) a personal mail because people tend to ignore lists and BZ. ... in this particular case where a maintainer is has not done anything for more than 2 years, I find it hard to believe he will return. I therefor approve your request as a FESCO member in order to continue with the procedure. I'm Gary's sponsor. I, too, have been trying to contact him for a long time. As nothing has happened, I have revoked my sponsorship. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Taking a two-week holiday
Hi, just to let you know - I'm taking a two-week holiday starting tomorrow, during which time I probably won't have internet access. So, don't wonder why I'm not, e.g., attending anything in bugzilla. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems with the %{?_isa} macro in dependencies
On Sun, 25 Sep 2011 18:55:42 +0300
Ville-Pekka Vainio vpvai...@iki.fi wrote:
First case:
The arch-specific libvoikko spell checking package requires the
Finnish morphology, which is in the arch-specific malaga-suomi-voikko
package. I did the following change (the versioned dependency was
unnecessary): -Requires: malaga-suomi-voikko = 1.4
+Requires: malaga-suomi-voikko%{?_isa}
Libraries are multilib'd. malaga-suomi-voikko only contains data
files (in arch specific directories), thus it isn't multilib'd = the
32-bit data package isn't available on x86_64 and you get the
dependency problem.
Second case:
I'm renaming the openoffice.org-voikko package to libreoffice-voikko.
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=739331,
spec: http://vpv.fedorapeople.org/packages/libreoffice-voikko.spec.
The Provides and Obsoletes are as follows:
Provides: openoffice.org-voikko = %{version}-%{release}
Obsoletes:openoffice.org-voikko 3.1.2-6
This works, but if I change the Obsoletes to
Obsoletes:openoffice.org-voikko%{?_isa} 3.1.2-6
then the package does not obsolete openoffice.org-voikko any more,
which results in file conflicts.
The obsolete doesn't work, since then you're not obsoleting the
package, instead you're obsoleting what the package provides:
$ rpm -q openoffice.org-voikko
openoffice.org-voikko-3.1.2-3.fc15.x86_64
$ rpm -q --provides openoffice.org-voikko
voikko.so()(64bit)
voikko.so(UDK_3_0_0)(64bit)
openoffice.org-voikko = 3.1.2-3.fc15
openoffice.org-voikko(x86-64) = 3.1.2-3.fc15
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[SOLVED] Re: Jmol, Java and netscape.javascript
On Tue, 23 Aug 2011 14:25:16 -0400
Omair Majid oma...@redhat.com wrote:
On 08/23/2011 04:44 AM, Jussi Lehtola wrote:
$ ant -lib %{_datadir}/icedtea-web/plugin.jar doc main
doesn't work, it still fails in the same error.
There are two things that were causing problems. The spec file was
setting classpath to a directory, not a jar. Also, the build.xml file
was instructing ant to discard the classpath specified on the command
line.
The build.xml statement was indeed the culprit. Thanks for your help!
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Jmol, Java and netscape.javascript
On Wed, 17 Aug 2011 13:05:21 -0400
Omair Majid oma...@redhat.com wrote:
On 08/17/2011 12:22 PM, Jussi Lehtola wrote:
Hi,
I tried to update Jmol to the latest release, when I ran once again
into
error: package netscape.javascript does not exist
import netscape.javascript.JSObject;
The package is not standard part of Java. It is provided by
plugin.jar. In Fedora = 15 plugin.jar was included with the JDK (if
the java-1.6.0-openjdk-plugin package was installed). Now plugin.jar
is provided by icedtea-web.
My spec builds fine in Fedora 15, but fails to build in 16 and 17.
http://pkgs.fedoraproject.org/gitweb/?p=jmol.git;a=blob;f=jmol.spec;hb=HEAD
Does someone have a solution to this problem?
I think one possible fix would be to BuildRequire icedtea-web and
include /usr/share/icedtea-web/plugin.jar in the classpath.
icedtea-web had already been a BuildRequire since Fedora 15 (and the
package compiles fine in Fedora 15), but the jar file has been moved
after that.
$ ant -lib %{_datadir}/icedtea-web/plugin.jar doc main
doesn't work, it still fails in the same error.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jmol, Java and netscape.javascript
Hi, I tried to update Jmol to the latest release, when I ran once again into error: package netscape.javascript does not exist import netscape.javascript.JSObject; My spec builds fine in Fedora 15, but fails to build in 16 and 17. http://pkgs.fedoraproject.org/gitweb/?p=jmol.git;a=blob;f=jmol.spec;hb=HEAD Does someone have a solution to this problem? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EKOPath compiler in the next Fedora releases
On Sat, 13 Aug 2011 16:42:13 +0200
Björn Persson bj...@xn--rombobjrn-67a.se wrote:
Ilyes Gouta wrote:
I'm trying to put together an initial spec file for Fedora.
According to PathScale's license document their products are partly
free and partly unfree. You can of course only package the free
parts. How useful are they without the unfree parts?
Björn Persson
http://www.pathscale.com/ekopath4-open-source-announcement
June 13th, 2011
PathScale announced today that the EKOPath 4 Compiler Suite is now
available as an open source project and free download for Linux,
FreeBSD and Solaris. This release includes documentation and the
complete development stack, including compiler, debugger, assembler,
runtimes and standard libraries. EKOPath is the product of years of
ongoing development, representing one of the industries highest
performance Intel 64 and AMD C, C++ and Fortran compilers.
The sources seem to be available at
https://github.com/path64
The compiler part is GPLv3, the debugger is CDDL. I tried to get the
compiler packaged for a few hours, but ran into some problems in the
build phase; the compiler segfaulted in the bootstrap phase. This was
on Fedora 15. My spec file is attached, maybe someone can get it to
build.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
# Git snapshot version
%global gitver 20326a5
# Version of system GCC
%global gccver 4.6
Name: path64-compiler
Version: 4.0.10
Release: 1.%{gitver}git%{?dist}
Summary: PathScale EKOPath compiler suite
Group: Development/Languages
License: GPLv3
URL: http://www.pathscale.com/ekopath-compiler-suite
# Tarball got from https://github.com/path64/compiler/tarball/4.0.10
# it is automatically generated, so checksums might not match
Source0: path64-compiler-%{version}-0-g%{gitver}.tar.gz
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
ExclusiveArch: x86_64 %{ix86}
BuildRequires: cmake
BuildRequires: gcc-gfortran
BuildRequires: glibc-static%{?_isa}
%description
The PathScale® EKOPath Compiler Suite offers programmers a rich set of tools
and one of the world's most sophisticated optimization infrastructures to
maximize program performance on any Intel® 64 or AMD64 platform supporting
Intel® MMXâ¢, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AMD SSE4A and AVX.
* Intel® 64 AMD64 performance tuned
* ISO C99/C++ 2003 GNU compatible
* Fortran 90/95 and 2003
* Industry proven robustness and quality
%prep
%setup -q -n %{name}-%{gitver}
%build
mkdir objdir-%{_target_platform}
cd objdir-%{_target_platform}
gccdir=`echo %{_target_platform} | sed 's|-gnu||g'`
gccdir=/usr/lib/gcc/$gccdir/%{gccver}
%ifarch x86_64
export plat=x86_64
%else
export plat=x86_32
%endif
# The build will use the compiled compiler. Need to remove GNU specific flags from OPTFLAGS
#export CFLAGS=`echo %{optflags} | sed s|-fstack-protector||g;s|--param=ssp-buffer-size=4||g;s|-mtune=generic||g`
export CFLAGS=-Wall
export CXXFLAGS=$CFLAGS
export FFLAGS=$CFLAGS
%{cmake} \
-DPATH64_ENABLE_TARGETS=${plat} \
-DPATH64_ENABLE_MATHLIBS=ON \
-DPATH64_ENABLE_FORTRAN=ON \
-DPATH64_ENABLE_HUGEPAGES=ON \
-DPATH64_ENABLE_OPENMP=ON \
-DCMAKE_BUILD_TYPE=Release \
-DPSC_CRT_PATH_${plat}=%{_libdir} \
%ifarch x86_64
-DPSC_DYNAMIC_LINKER_${plat}=/%{_lib}/ld-linux-x86-64.so.2 \
%else
-DPSC_DYNAMIC_LINKER_${plat}=/%{_lib}/ld-linux.so.2 \
%endif
-DPSC_CRT_PATH_${plat}=%{_libdir} \
-DPSC_LIBSUPCPP_PATH_${plat}=$gccdir \
-DPSC_LIBSTDCPP_PATH_${plat}=$gccdir \
-DPSC_LIBGCC_PATH_${plat}=$gccdir \
-DPSC_LIBGCC_EH_PATH_${plat}=$gccdir \
-DPSC_LIBGCC_S_PATH_${plat}=$gccdir \
..
#make %{?_smp_mflags} VERBOSE=1
make VERBOSE=1
%install
rm -rf %{buildroot}
make -C objdir-%{_target_platform} install DESTDIR=%{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc
%changelog
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Handle sonames
On Tue, 09 Aug 2011 00:36:59 +0530 Ankur Sinha sanjay.an...@gmail.com wrote: Hello, This is what rpmlint says about it: python-pylibmc.i686: W: private-shared-object-provides /usr/lib/python2.7/site-packages/_pylibmc.so Could someone please direct us to the correct way of handling this please? https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Arch-specific_extensions_to_scripting_languages -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PokerTH orphaned
Hi, I've just orphaned PokerTH, since I'm trying to free myself some time and I don't use it myself. PokerTH does not currently build on rawhide, since OpenSSL support has been dropped from GnuTLS a week ago (BZ #726697). Getting it to build again would then require building against OpenSSL (and asking upstream for a GPL license exception), or shipping a private copy of GnuTLS. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Defining build options based on available compiler version
Hi,
I tried using
%global gccver %(gcc -dumpversion)
%if %{gccver} = 4.6.0
foo here
%endif
to conditionalize usage of quadruple precision support in a spec file
that ships on multiple distros, but the comparison gives the error
parseExpressionBoolean returns -1
Is there a way to check if the gcc version is sufficient with some rpm
macro?
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Defining build options based on available compiler version
On Sat, 30 Jul 2011 20:05:12 +0300 Ville Skyttä ville.sky...@iki.fi wrote: On 07/30/2011 07:44 PM, Jussi Lehtola wrote: Is there a way to check if the gcc version is sufficient with some rpm macro? Do you actually need to have it as a macro? Often cases like this can be handled with plain shell code in %prep, %build, etc. Or by patching the build system to do the check automatically and sending the patch upstream. Yes, since the existence of some subpackages depends on whether the option is supported or not. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Defining build options based on available compiler version
On Sat, 30 Jul 2011 11:50:51 -0500
Richard Shaw hobbes1...@gmail.com wrote:
I'm just guessing here, but I think because of the dots it's returning
a string instead of a number which makes the = comparison invalid. Is
there another gcc option that will give you a dotless version
number?
I would try something like:
%global gccver %(gcc -dumpversion | sed s/\.//g)
%if %{gccver} = 460
foo here
%endif
I'm guessing, too, that the issue has to do with strings vs numbers.
The above version also fails with parseExpressionBoolean returns -1.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Epson inkjet driver review
Hi, in case anyone here is running an Epson inkjet printer, you might want to know that I have packaged Epson's open source driver. The review is at https://bugzilla.redhat.com/show_bug.cgi?id=720435 and it is free for the taking. I've tested that the driver works on my own F15 desktop. PS. Willing comaintainers are welcome. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 06 Jul 2011 12:54:48 -0700 Adam Williamson awill...@redhat.com wrote: It's certainly not the same libotf, since OpenMPI does not have *anything* to do with truetype fonts. Even though the library is installed in a non-system directory, applications that link against libotf will get an automatically generated Requires: against it anyways. Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. .. but on the other hand, the same logic applies in the opposite sense: if something requires OpenMPI's libotf.so.0, also the truetype libotf will satisfy the requirement. (Although openmpi apps typically link to a half a dozen other openmpi libs as well). -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 06 Jul 2011 13:09:41 -0700 Adam Williamson awill...@redhat.com wrote: .. but on the other hand, the same logic applies in the opposite sense: if something requires OpenMPI's libotf.so.0, also the truetype libotf will satisfy the requirement. (Although openmpi apps typically link to a half a dozen other openmpi libs as well). Nothing really could require OpenMPI's libotf as things stand, because of what I wrote above: nothing can find it unless it uses a custom linker path. If OpenMPI actually wanted the library to be something other packages can use, it should really install it in a shared path (and, as we've already discussed, rename it). If we're just talking about different OpenMPI packages, they can handle the intra-dependencies manually, I'd say. Not really, since when the MPI environment is loaded the relevant library paths are added to LD_LIBRARY_PATH. They're not installed in system locations, since e.g. all MPI libraries ship with libmpi.so, and there are many variants: OpenMPI, MPICH2, MVAPICH, and so on. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Prelink + packaging proprietary software
Hi, 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? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, 3 Jun 2011 08:51:55 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: hulahop had it's Epoch bumped on the F-10 branch to hulahop-1:0.4.6-5.fc10 (commit 3c3f6d12edb) to undo 0.4.7 update. That epoch bump was limited to F-10, no other branches saw it afaict. So anyone who ever installed the F-10 package is stuck with it. Anyone else is still fine. Yum on my box claims the version available on f15 is indeed the 0.7.1 currently in the repos (I never had the F-10 package installed). What's the correct thing to do here? Just bump the Epoch again and get on with life? Yes, the correct way to fix this would be to set Epoch: 1 in the current spec file. That way version 0.7.1 would be allowed to update the 0.4.7 with Epoch 1. However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guidance on hulahop epoch usage
On Fri, 3 Jun 2011 09:39:13 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Jun 03, 2011 at 02:21:14AM +0300, Jussi Lehtola wrote: However, given that the problematic package only appeared in Fedora 10 and upgrade paths are guaranteed by Fedora policy only from F(N-1) to F(N), I'd say that there's probably no need to fix this any more, since any remaining installations haven't had updates for ages and upgrading to a current release cleanly would require a clean reinstall anyway. true, but anyone who would have had hulahop installed at F-10 time and did the (guaranteed) update to F11, F12, ... F15 at the right times would still have this issue now, right? tbh, it seems to be corner case enough to just say uninstall and re-install but nonetheless... Yes. It's just a bit hard to believe that there would be still a lot of systems suffering from this, since yum would have complained about the problem on every update, and you haven't had a single bug report about the issue in a time period of more than two years..? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On Wed, 20 Apr 2011 11:59:18 -0600 Jerry James loganje...@gmail.com wrote: 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. What package are we talking about? There is already at least one package in Fedora which does a similar thing: ATLAS. It normally automatically tunes itself for the optimal build flags, so some special tricks have to be done for packaging. ATLAS has currently the following versions on Fedora: i686: plain, 3dnow, sse, sse2 and sse3 x86_64: plain and sse2 The plain stands for the atlas package. I don't know what flags it uses. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken deps in F15 tree
Hi, I wonder why I'm still getting nag mails about pokerth has broken dependencies in the F-15 tree: On x86_64: pokerth-0.8.3-1.fc15.x86_64 requires libboost_iostreams-mt.so.1.44.0()(64bit) pokerth-0.8.3-1.fc15.x86_64 requires libboost_regex-mt.so.1.44.0()(64bit) and so on, when the package currently in the F-15 repo should be https://admin.fedoraproject.org/updates/pokerth-0.8.3-4.fc15 -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken deps in F15 tree
On Tue, 1 Mar 2011 11:54:10 +0100 Thomas Spura toms...@fedoraproject.org wrote: On Tue, 1 Mar 2011 12:42:08 +0200 Jussi Lehtola wrote: Hi, I wonder why I'm still getting nag mails about pokerth has broken dependencies in the F-15 tree: and so on, when the package currently in the F-15 repo should be https://admin.fedoraproject.org/updates/pokerth-0.8.3-4.fc15 Because it's not pushed to stable yet, only requested: Requested:stable Pushed: False .. duh. Thanks. Let's hope a F-15 push is done soon.. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fail to install gcc on fresh rawhide-from-F15
On Wed, 23 Feb 2011 23:05:50 +0100 Jim Meyering j...@meyering.net wrote: Andreas Schwab wrote: Jim Meyering j...@meyering.net writes: --- Package glibc.x86_64 0:2.8.90-11 will be a downgrade Where did you get that ANCIENT package? It's almost 3 years(!) old. I have *no* idea. Maybe you missed my former reply. On Wed, 23 Feb 2011 00:28:57 +0200 Jussi Lehtola jussileht...@fedoraproject.org wrote: I'd say there's something seriously wrong with your yum configuration or the rawhide mirror you've been using. There hasn't been a gcc-4.3.1 in Fedora for a couple of years. Check that the rawhide yum configuration (package fedora-release-rawhide) is installed, run # yum clean all and try again. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fail to install gcc on fresh rawhide-from-F15
On Tue, 22 Feb 2011 22:38:24 +0100 Jim Meyering j...@meyering.net wrote: With some effort, and help from the guys on #anaconda@freenode (thanks!), today I finally installed a bare-metal F15 system (part of the complication was my existing partitions). Then I updated it to rawhide. However, the whole point of this was to be able to compile and test some things, yet I cannot install gcc: # yum install gcc (clip) Error: Package: gcc-4.3.1-6.x86_64 (rawhide) Requires: cpp = 4.3.1-6 Installed: cpp-4.6.0-0.7.fc15.x86_64 (@rawhide) cpp = 4.6.0-0.7.fc15 Available: cpp-4.3.1-6.x86_64 (rawhide) cpp = 4.3.1-6 I'd say there's something seriously wrong with your yum configuration or the rawhide mirror you've been using. There hasn't been a gcc-4.3.1 in Fedora for a couple of years. Check that the rawhide yum configuration (package fedora-release-rawhide) is installed, run # yum clean all and try again. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010 10:15:47 -0600 Jason L Tibbitts III ti...@math.uh.edu wrote: PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable PM and enhanced dependency extration system. Documentation is scarce PM at the moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. It's working now. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Something wrong with the updates system?
Hi, there seems to be something wrong with the updates system. I get HTTP error 500 both with fedpkg and in the web interface when trying to submit updates. Is anyone else seeing this? e.g. ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/dd_rescue/Fedora/13, 500, Unknown HTTP Server Response) -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
On Fri, 5 Nov 2010 15:16:32 -0400 Bill Nottingham nott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: 2010/11/5 Marcela Mašláňová mmasl...@redhat.com: On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. There should have been a heads up for this. It affects 100s of packages. + 1 It's being fixed; no rebuilds needed. Fixed, in what sense? What about the packages that have already been rebuilt? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root has broken dependencies in the rawhide tree
On Sat, 30 Oct 2010 07:14:43 -0400 Neal Becker ndbeck...@gmail.com wrote: I have no idea what these messages I've received mean: root has broken dependencies in the rawhide tree: On x86_64: root-unuran-5.26.00e-1.fc15.x86_64 requires libunuran.so.14()(64bit) On i386: root-unuran-5.26.00e-1.fc15.i686 requires libunuran.so.14 Please resolve this as soon as possible. Hi, (cc root an unuran package owners) Looks like the unuran package has been updated to a new version in rawhide, which has a newer soname. This breaks dependencies of packages that have been built against an older version of unuran; they need to be rebuilt against the new version. Looks like unuran-1.8.0-1 has been built for f12 - f14, rawhide, el5 and el6. Package updates seem to have been submitted to f13 and f14. If these are pushed to the stable updates repository, packages such as root-unuran will break on existing installs. Also they must be built against the new version of unuran, and the new packages must be shipped together in the updates repository. You will have to request rel-eng for a buildroot override to do this. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ltsp-5.2.4-5.rpm's ready for testing (i686 x86_64)
On Sun, 12 Sep 2010 20:49:10 +0100 Gavin Spurgeon gspurg...@redhat.com wrote: Hiya JD Your repo file is busted. The repo is fine, if you look @ the url's in my original e-mail the arch's I have built for is only x86_64 i686, I haven't built the latest LTSP for i386. What JD probably meant is that the repo file does not work on 32-bit (x86_32) Fedoras, since $basearch is still set as i386 for some releng reason (IIRC this has been discussed on fedora-devel some while ago). You should be able to fix the repo tree with a symlink by making i386 point to the i686 directory. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Fri, 2010-07-09 at 12:55 +0530, Rahul Sundaram wrote: On 07/09/2010 03:41 AM, Jussi Lehtola wrote: I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. If you are a provenpackager, can't you just make the changes yourself and close the review request? I asked about this a year(?) ago when I became sponsor. The consensus in FESCo was back then that the reviewer making the changes would go against the whole idea of reviewing, which involves two people (the maintainer and the reviewer) going through the changes. Having a provenpackager replacing the maintainer would be possible in principle, but the merge review may in some cases involve rather drastic changes that should be not made by other people than the maintainer. Besides, it's the maintainer's work anyhow.. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. Just a few comments. First of all, option a) is IMHO out of the question. 242 reviews is not that much. Maybe people have not been aware so far that Merge Reviews exist and can be performed by anyone in the packagers group. This discussion should raise awareness about the fact. The work needed for the review depends, though, a lot on the nature of the package. The further down the pile we go, the more work there is per package: the spec files of say gcc, kernel or OpenOffice.org are rather daunting. I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Net-UPnP/EL-6 perl-Net-UPnP.spec,1.3,1.4
Author: jussilehtola
Update of /cvs/pkgs/rpms/perl-Net-UPnP/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31908
Modified Files:
perl-Net-UPnP.spec
Log Message:
Sync from rawhide branch.
Index: perl-Net-UPnP.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-UPnP/EL-6/perl-Net-UPnP.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Net-UPnP.spec 27 Dec 2009 15:50:39 - 1.3
+++ perl-Net-UPnP.spec 7 Jul 2010 17:44:48 - 1.4
@@ -1,7 +1,7 @@
Name: perl-Net-UPnP
Version: 1.4.2
Epoch: 1
-Release: 1%{?dist}
+Release: 4%{?dist}
Summary: Perl extension for UPnP
License: BSD
Group: Development/Libraries
@@ -10,6 +10,7 @@ Source0: http://search.cpan.org/CPAN/aut
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(version)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -52,10 +53,19 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README examples/
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Net/
+%{_mandir}/man3/Net::UPnP*
%changelog
+* Fri May 14 2010 Petr Pisar ppi...@redhat.com - 1:1.4.2-4
+- Remove duplicate BuildRequires perl(version)
+
+* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 1:1.4.2-3
+- Added BR: perl(version) to fix FTBFS.
+
+* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 1:1.4.2-2
+- Mass rebuild with perl-5.12.0
+
* Sun Dec 27 2009 Jussi Lehtola jussileht...@fedoraproject.org - 1:1.4.2-1
- Update to 1.4.2.
- Fix spelling in rpm version: 1.4.1 instead of previous 1.41.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages requiring numpy may require a rebuild in f13 and rawhide
On Thu, 2010-04-01 at 22:48 -0800, Jeff Spaleta wrote: On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura spur...@students.uni-mainz.de wrote: Are you sure, packages like gnuplot-py *have* to get rebuild? Your first programm that causes troubles 'python-basemap' is not noarch. A compiled programm needs a rebuild, but a programm with just python files in it? Apologies, see the revised list I posted later as a follow-up that does a better job of finding the things that buildrequire numpy. The first list was admittedly a rough cut. A Python package BuildRequiring numpy does not need to mean anything. All of my packages on the list BuildRequires numpy simply because the install scripts have a dummy check in them for checking that all necessary runtime modules are installed.. so AFAIK nothing is compiled against numpy. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning xine-ui: maintainers / comaintainers needed
Hi, I find myself busy at $DAYJOB, so I don't have the time necessary to maintain xine-ui. I'm going to orphan the package (pkgdb didn't let me do it just a while ago), so I'm asking for maintainers and comaintainer candidates to request access to the relevant branches in pkgdb. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote: 2010/3/6 Michał Piotrowski : But you are updating to latest KDE in f11. So what is the deal with full system update? Time. A simple yum update or make a selective update takes a few minutes. A whole system update takes more. I've been upgrading my systems for a few years now with a simple yum upgrade, i.e. install the new fedora-release package and run yum update. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: creating file in koji allowed?
On Fri, 2010-02-26 at 14:07 +0100, Thomas Spura wrote: Am Freitag, den 26.02.2010, 00:58 +0100 schrieb Dominik 'Rathann' Mierzejewski: On Thursday, 25 February 2010 at 22:29, Thomas Spura wrote: I need to write down a password into that file, for running a testsuite. If that file does not exist, I can't run mpich2 tests. Nice. Could you document this on the wiki somewhere? This could be useful for folks who want to run some testsuites which use mpich2. Could you prepare something similar (i.e. MPI environment setup) for openmpi? For example, currently I have the testsuite in freefem++ disabled, but I'd prefer to keep it enabled if I can. Sure, I thinkt he best place atm would be MPI packaging guidelines [1]. I'll ping the writer of that and maybe it's added there. [1] http://fedoraproject.org/wiki/PackagingDrafts/MPI Just create a proposal and send it to the FPC for discussion. If the proposal goes through both in the FPC and FESCo, maybe the MPI guidelines will finally be moved among the other guidelines; they were after all approved in August 2009.. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-static packages not multilib'd?
Hi, I was recently asked why there isn't an fftw-static.i386 on EPEL x86_64, even though both fftw and fftw-devel are available in both 32- and 64-bits. Is this a bug in the repo scripts, or an intentional feature..? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu ???
On Mon, 2010-02-01 at 18:24 -0500, Owen Taylor wrote: we seem to have things set up to run configure as: --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu --target=i686-redhat-linux-gnu Which, according to my reading of the autoconf manual means: * Build on a i386-redhat-linux-gnu * Create code that runs on i386-redhat-linux-gnu * Build a cross tool chain that targets i686-redhat-linux-gnu and really doesn't make sense. I'm pretty sure we want to pass i686-redhat-linux-gnu for --host, and we don't need to specify --target. (clip) Am I missing something here? This is causing GLib to build using slow fallbacks for atomic operations, and likely causes other problems as well. I've had some problems as well with pcc where using %configure makes the build process think a cross compilation should be done. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The road to dropping xdvik
On Wed, 2010-01-27 at 18:04 +, Jonathan Underwood wrote: However, it's not clear to me if okular and evince-dvi provide equivalent functionality that we're yet in a position to drop xdvik. Comments? If you use xdvik because other viewers don't give some particular functionality, it would be helpful if you stated what that functionality is. As a heavy LaTeX user I would be really against dropping xdvi before there is some other app that runs as fast. Evince very slow - xdvi shows pages straight away, whereas evince often displays Loading... -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wed, 2010-01-13 at 10:52 -0800, Roland McGrath wrote: - Jussi Lehtola jussileht...@fedoraproject.org wrote: So is --as-needed within the current default flags? As far as I know, no. The default will still be --no-as-needed. That's correct. This change does not affect --as-needed at all. The --as-needed flag will link libraries if A) they define symbols required by object files B) those symbols are still undefined when the library is checked That's correct. In other words, the libfoo.so DSO will only be used at runtime if the presence of -lfoo at link time actually had any effect on what symbols got resolved to what. But --as-needed is not really apropos in this thread. OK, if RPM picks only the libraries that are actually used in auto-requires, then there's no connection. Otherwise the situation would be a whole lot different, since the requires might have some bloat. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
