Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux

[Dirkjan Ochtman]

On Wed, Nov 28, 2012 at 8:16 AM, Matt Turner  wrote:
> Sure, I would like to be a manager.
>
> I'd like to add these as well:
> https://www.ohloh.net/p/gentoo_loongson_overlay
> https://www.ohloh.net/p/gentoo_catalyst

They're in there already (the page only lists most active projects by
default, click the See all projects button to see the rest).

I've added you as a manager (and given you some kudos ;)).

Cheers,

Dirkjan

Re: [gentoo-dev] New eclass cuda.eclass

[justin]

Please review my inclusion of your suggestions. Additionally I move to
src_prepare to be more binpackage compatible as things are only of
interest at compile time.


commit 366a690925f5cc5e4bdd2ea984d9ccca65d8f996
Author: Justin Lecher 
Date:   Wed Nov 28 11:54:16 2012 +0100

Be bin package friendly

Move standard call of cuda_sanitize to src_prepapere as it isn't need
for bin packages.

Signed-off-by: Justin Lecher 

diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 08cfb72..beac082 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -110,13 +110,23 @@ cuda_sanitize() {

 # @FUNCTION: cuda_pkg_setup
 # @DESCRIPTION:
-# Sanitise and export NVCCFLAGS by default
+# Call cuda_src_prepare for EAPIs not supporting src_prepare
 cuda_pkg_setup() {
+   cuda_src_prepare
+}
+
+# @FUNCTION: cuda_src_prepare
+# @DESCRIPTION:
+# Sanitise and export NVCCFLAGS by default
+cuda_src_prepare() {
cuda_sanitize
 }

-EXPORT_FUNCTIONS pkg_setup
+
 case "${EAPI:-0}" in
-   0|1|2|3|4|5) ;;
+   0|1)
+   EXPORT_FUNCTIONS pkg_setup ;;
+   2|3|4|5)
+   EXPORT_FUNCTIONS src_prepare ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac

commit 07b5a629a7f6e9f163e0dfe9c1927010f527508f
Author: Justin Lecher 
Date:   Wed Nov 28 11:24:51 2012 +0100

Fix typo in Copyright year

Signed-off-by: Justin Lecher 

diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 0b2e084..08cfb72 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-20012 Gentoo Foundation
+# Copyright 1999-2012 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $


commit 7319422dd7c7427cc741e9bdab2f1211b5af1be4
Author: Justin Lecher 
Date:   Wed Nov 28 11:24:16 2012 +0100

Implemented comments from g-dev review

* Fix whitespacing
* Fix man pages tags
* Try to do things in functions instead of global scope
* remove _ from local variables
* inline check for presents and functionality of cuda-config

Signed-off-by: Justin Lecher 

diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index f8ebd81..0b2e084 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -13,49 +13,45 @@ inherit toolchain-funcs versionator
 # setting and/or sanitizing NVCCFLAGS, the compiler flags for nvcc. This is
 # automatically done and exported in src_prepare() or manually by calling
 # cuda_sanatize.
-#
-# Common usage:
-#
+# @EXAMPLE:
 # inherit cuda

 # @ECLASS-VARIABLE: NVCCFLAGS
-# DESCRIPTION:
+# @DESCRIPTION:
 # nvcc compiler flags (see nvcc --help), which should be used like
 # CFLAGS for c compiler
 : ${NVCCFLAGS:=-O2}

 # @ECLASS-VARIABLE: CUDA_VERBOSE
-# DESCRIPTION:
+# @DESCRIPTION:
 # Being verbose during compilation to see underlying commands
 : ${CUDA_VERBOSE:=true}

-[[ "${CUDA_VERBOSE}" == true ]] && NVCCFLAGS+=" -v"
-
-# @ECLASS-FUNCTION: cuda_gccdir
+# @FUNCTION: cuda_gccdir
+# @USAGE: [-f]
+# @RETURN: gcc bindir compatible with current cuda, optionally (-f)
prefixed with "--compiler-bindir="
 # @DESCRIPTION:
 # Helper for determination of the latest gcc bindir supported by
 # then current nvidia cuda toolkit.
 #
-# Calling plain it returns simply the path, but you probably want to
add \"-f\""
-# to get the full flag to add to nvcc call.
-#
 # Example:
-#
+# @CODE
 # cuda_gccdir -f
 # -> --compiler-bindir="/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3"
+# @CODE
 cuda_gccdir() {
-   local _gcc_bindir _ver _args="" _flag _ret
+   local gcc_bindir ver args="" flag ret

# Currently we only support the gnu compiler suite
if [[ $(tc-getCXX) != *g++* ]]; then
-ewarn "Currently we only support the gnu compiler suite"
+   ewarn "Currently we only support the gnu compiler suite"
return 2
fi

while [ "$1" ]; do
case $1 in
-f)
-   _flag="--compiler-bindir="
+   flag="--compiler-bindir="
;;
*)
;;
@@ -63,43 +59,46 @@ cuda_gccdir() {
shift
done

-   if [[ ! $(type -P cuda-config) ]]; then
+   if ! args=$(cuda-config -s); then
eerror "Could not execute cuda-config"
eerror "Make sure >=dev-util/nvidia-cuda-toolkit-4.2.9-r1 is 
installed"
die "cuda-config not found"
else
-   _args="$(version_sort $(cuda-config -s))"
-   if [[ ! -n ${_args} ]]; then
+   args=$(version_sort ${args})
+   if [[ -z ${args} ]]; then
die "Could not determine supported gcc versions from 
cuda-config"
fi
fi

-   for _ver in ${_args}; do
-  has_version sys-devel/gcc:${_ver} && \
- _gcc_bindir="$(ls -d
${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${_ver}* | tail -n 1)"
-   done

Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux

[Theo Chatzimichos]

On Mon, Nov 26, 2012 at 9:58 PM, Dirkjan Ochtman  wrote:
> On Fri, Nov 23, 2012 at 12:18 PM, Dirkjan Ochtman  wrote:
>> I haven't heard back from them, maybe you can ask them what's up.
>
> This has been setup (with Donnie's help):
>
> https://www.ohloh.net/orgs/gentoo
>
> I've claimed 15 of the projects on there that I could easily find,
> analysis on those should complete shortly. If you're on Ohloh, please
> nominate further projects. You can also add the organization as a tag
> to your project contributions (which I've done for my gentoo-x86
> commits).
>
> Also, if you're an active Ohloh user, let me know if you want to be a
> manager for the Gentoo organization.
>
> Cheers,
>
> Dirkjan

Hello,

thank you both for taking care of this. Please add me as manager as well.

Theo

Re: [gentoo-dev] Last rites: app-admin/profiler

[viv...@gmail.com]

Il 28/11/2012 00:04, Sebastian Pipping ha scritto:

# Sebastian Pipping  (27 Nov 2012)
# Masked for removal in 30 days.
# Licensing issues, turned out not distributable (bug #444332)
app-admin/profiler

uhm, maybe for licensing issues the grace period of 30 days could be 
shortened (not that I care)

[gentoo-dev] Using emerge-webrsync to simplify the handbook

[Richard Yao]

We could slightly simplify the handbook installation procedure if we
told people to use emerge-webrsync to fetch the initial snapshot. What
do people think?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Maxim Kammerer]

On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao  wrote:
> We could slightly simplify the handbook installation procedure if we
> told people to use emerge-webrsync to fetch the initial snapshot.

Using emerge-webrsync also makes the installation process more robust,
since it only requires HTTP access (whereas many firewalls restrict
RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
that it should be the primary recommended portage tree synchronization
method.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Richard Yao]

On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao  wrote:
>> We could slightly simplify the handbook installation procedure if we
>> told people to use emerge-webrsync to fetch the initial snapshot.
> 
> Using emerge-webrsync also makes the installation process more robust,
> since it only requires HTTP access (whereas many firewalls restrict
> RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
> that it should be the primary recommended portage tree synchronization
> method.
> 

The only downside of which I am aware is increased network traffic.
However, we could redesign emerge-webrsync to take advantage of GNU
Tar's incremental archive functionality.

That would permit us to mirror compressed diffs in addition to regular
portage snapshots. Doing that well could reduce bandwidth requirements.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Matthew Thode]

On 11/28/2012 09:05 AM, Richard Yao wrote:
> On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
>> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao  wrote:
>>> We could slightly simplify the handbook installation procedure if we
>>> told people to use emerge-webrsync to fetch the initial snapshot.
>>
>> Using emerge-webrsync also makes the installation process more robust,
>> since it only requires HTTP access (whereas many firewalls restrict
>> RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
>> that it should be the primary recommended portage tree synchronization
>> method.
>>
> 
> The only downside of which I am aware is increased network traffic.
> However, we could redesign emerge-webrsync to take advantage of GNU
> Tar's incremental archive functionality.
> 
> That would permit us to mirror compressed diffs in addition to regular
> portage snapshots. Doing that well could reduce bandwidth requirements.
> 
weekly fulls and daily diffs?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-admin/profiler

[Ulrich Mueller]

> On Wed, 28 Nov 2012, vivo75@gmail com wrote:

>> # Sebastian Pipping  (27 Nov 2012)
>> # Masked for removal in 30 days.
>> # Licensing issues, turned out not distributable (bug #444332)
>> app-admin/profiler

> uhm, maybe for licensing issues the grace period of 30 days could be
> shortened (not that I care)

Not a problem here, because the ebuild is fetch restricted now, and
therefore we don't distribute the upstream package.

Ulrich

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Michał Górny]

On Wed, 28 Nov 2012 10:05:55 -0500
Richard Yao  wrote:

> On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
> > On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao  wrote:
> >> We could slightly simplify the handbook installation procedure if we
> >> told people to use emerge-webrsync to fetch the initial snapshot.
> > 
> > Using emerge-webrsync also makes the installation process more robust,
> > since it only requires HTTP access (whereas many firewalls restrict
> > RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
> > that it should be the primary recommended portage tree synchronization
> > method.
> > 
> 
> The only downside of which I am aware is increased network traffic.
> However, we could redesign emerge-webrsync to take advantage of GNU
> Tar's incremental archive functionality.
> 
> That would permit us to mirror compressed diffs in addition to regular
> portage snapshots. Doing that well could reduce bandwidth requirements.

There's emerge-delta-webrsync but it's mostly hand-work to reconstruct
the webrsync tarball. Therefore, it is very slow and not worth
the effort when syncing often.

However, I'm not aware of gnu tar's incremental archive. If it's much
faster than the above, then it should probably replace
emerge-delta-webrsync.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Justin]

Hi,

and another one.

Problem:
Some packages aren't lucky and their buildsystem doesn't create
pkg-config files out of the box.

Solution:
Create them by hand.

Eclass:
Simplifies this by providing a general function for that.

Example:
https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild

Thanks for comments,
Justin
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: pkgconfig.eclass
# @MAINTAINER:
# j...@gentoo.org
# @BLURB: Simplify creation of pkg-config files
# @DESCRIPTION:
# Use this if you buildsystem doesn't create pkg-config files.

inherit multilib

# @ECLASS-VARIABLE: PC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_PREFIX:="${EPREFIX}/usr"}

# @ECLASS-VARIABLE: PC_EXEC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_EXEC_PREFIX:="${PC_PREFIX}"}

# @ECLASS-VARIABLE: PC_LIBDIR
# @DESCRIPTION:
# libdir to use
: ${PC_LIBDIR:="${EPREFIX}/usr/$(get_libdir)"}

# @ECLASS-VARIABLE: PC_INCLUDEDIR
# @DESCRIPTION:
# include dir to use
: ${PC_INCLUDEDIR:="${PC_PREFIX}/include"}

# @ECLASS-VARIABLE: PC_NAME
# @DESCRIPTION:
# A human-readable name for the library or package
: ${PC_NAME:=${PN}}

# @ECLASS-VARIABLE: PC_DESCRIPTION
# @DESCRIPTION:
# A brief description of the package
: ${PC_DESCRIPTION:=${DESCRIPTION}}

# @ECLASS-VARIABLE: PC_URL
# @DESCRIPTION:
# An URL where people can get more information about and download the package
: ${PC_URL:=${HOMEPAGE}}

# @ECLASS-VARIABLE: PC_VERSION
# @DESCRIPTION:
# A string specifically defining the version of the package
: ${PC_VERSION:=${PV}}

# @ECLASS-VARIABLE: PC_REQUIRES
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of packages required by this package. The versions of these packages
# may be specified using the comparison operators =, <, >, <= or >=.

# @ECLASS-VARIABLE: PC_REQUIRES_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of private packages required by this package but not exposed to
# applications. The version specific rules from the PC_REQUIRES field also
# apply here.

# @ECLASS-VARIABLE: PC_CONFLICTS
# @DEFAULT_UNSET
# @DESCRIPTION:
# An optional field describing packages that this one conflicts with.
# The version specific rules from the PC_REQUIRES field also apply here.
# This field also takes multiple instances of the same package. E.g.,
# Conflicts: bar < 1.2.3, bar >= 1.3.0.

# @ECLASS-VARIABLE: PC_LIBS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags specific to this package and any required libraries that
# don't support pkg-config. The same rule as PC_CFLAGS applies here.

# @ECLASS-VARIABLE: PC_LIBS_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags for private libraries required by this package but not
# exposed to applications. The same rule as PC_CFLAGS applies here.

# @ECLASS-VARIABLE: PC_CFLAGS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The compiler flags specific to this package and any required libraries
# that don't support pkg-config. If the required libraries support
# pkg-config, they should be added to PC_REQUIRES or PC_REQUIRES_PRIVATE.

# @FUNCTION: create_pkgconfig
# @USAGE: [-p | --prefix PC_PREFIX] [-e | --exec-prefix PC_EXEC_PREFIX] [-L | 
--libdir PC_LIBDIR ] [-I | --includedir PC_INCLUDEDIR ] [-n | --name PC_NAME] 
[-d | --description PC_DESCRIPTION] [-V | --version PC_VERSION] [-u | --url 
PC_URL] [-r | --requires PC_REQUIRES] [--requires-private PC_REQUIRES_PRIVATE] 
[--conflicts PC_CONFLICTS] [-l | --libs PC_LIBS] [--libs-private 
PC_LIBS_PRIVATE] [-c | --cflags PC_CFLAGS] 
# @DESCRIPTION:
# Creates and installs .pc file. Function arguments overrule the global set
# eclass variables. The function should only be executed in src_install().
create_pkgconfig() {
local pcname

[[ "${EBUILD_PHASE}" != "install" ]] && \
die "create_pkgconfig should only be used in src_install()"

while (($#)); do
case ${1} in
-p | --prefix )
shift; PC_PREFIX=${1} ;;
-e | --exec-prefix )
shift; PC_EXEC_PREFIX=${1} ;;
-L | --libdir )
shift; PC_LIBDIR=${1} ;;
-I | --includedir )
shift; PC_INCLUDEDIR=${1} ;;
-n | --name )
shift; PC_NAME=${1} ;;
-d | --description )
shift; PC_DESCRIPTION=${1} ;;
-V | --version )
shift; PC_VERSION=${1} ;;
-u | --url )
shift; PC_URL=${1} ;;
-r | --requires )
shift; PC_REQUIRES=${1} ;;
--requires-private )
shift; PC_REQUIRES_PRIVATE=${1} ;;

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> create_pkgconfig()

this sounds like a very bad idea.

pkgconfig files are common interfaces and should almost never be
created/modified/renamed anywhere except upstream.

debian packagers are already messing up pkgconfig files randomly
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498416 (broke
devilspie2)
also happened for dev-cpp/tbb and a few packages I don't recall right now

The result is that pkgconfig files don't represent common interfaces
anymore, cause application developers can't rely on them being
integrated in different distros in the same way.
Once this evolves further people will stop using them, cause it breaks
build systems.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQto0zAAoJEFpvPKfnPDWzWJoH/0yCI78/4t/hj/EMCKLGeTh+
LDZDmirdw5dTUpa0ZzG9lu/3GVr3FwwSDc8c+RzQjdRfpA+KwiFs4pEC3zu2CxvG
fwkIkU0g4NUwGF+7cVuqCQ4oAf/05utBFD/lpsWcASA7yB/8PNtT/NHZlsH7VW5v
sZX58bAGrwGcLN2YN5eC+qv+xS9p2ZklG4omBLzG8nc6RAdmLoyuO9fBz4GC+TaV
czTSpdslGnks1Bb+c2i1fuxPVTQTC21X6UQzflQVYh1O1bgOUpmir7kfz5XsEfnT
ZaCO4A0co3r0tK3hxuQk2FoB1z/9+YMquqyPxoblgvB5M3mr5kMHc2IDbGcI/EA=
=ecPj
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Michał Górny]

On Wed, 28 Nov 2012 22:49:14 +0100
Justin  wrote:

> Hi,
> 
> and another one.
> 
> Problem:
> Some packages aren't lucky and their buildsystem doesn't create
> pkg-config files out of the box.
> 
> Solution:
> Create them by hand.

Result:
packages which fail to build on distributions other than Gentoo because
their authors were using Gentoo and didn't knew that the pkg-config
aren't anywhere else.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Christoph Junghans]

2012/11/28 Justin :
> Hi,
>
> and another one.
>
> Problem:
> Some packages aren't lucky and their buildsystem doesn't create
> pkg-config files out of the box.
>
> Solution:
> Create them by hand.
>
> Eclass:
> Simplifies this by providing a general function for that.
>
> Example:
> https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild
>
> Thanks for comments,
> Justin
Great jobs, I had a similar eclass on my mind for a long time. It will
for sure be useful for Gentoo prefix builds.

However, I have some suggestions:
- Cflags should contain -I${includedir} and Libs should contain
-L${libdir} by default (see
).
- Reduce the number of global variables. Arguments to create_pkgconfig
are as useful as global variables.
- arguments like -{l,L}* can be used as Libs to avoid redundancy in
the syntax (example: "-lm" instead of "-l -lm"), same for -I*
- it is only one function, maybe it could be added to eutils eclass
- pc files created by this eclass should go into a Gentoo specific
directory (/usr/share/gentoo/lib/pkgconfig?) to avoid confusion with
upstream pc files. This directory can then be added to PKG_CONFIG_PATH
during the build.

Can you also remind me what should go into these private variables and
what not? Since Fedora has started their DSO Linking policy I am very
confused about flags like -lm and -pthreads.

--
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele

[Chí-Thanh Christopher Nguyễn]

Walter Dnes schrieb:
>> Telling people to use xf86-video-fbdev for Poulsbo would be bad
>> advice, they should use xf86-video-modesetting.

> Since
> the "Intel GMA5/600 KMS Framebuffer" option is selected, xf86-video-fbdev
> *MUST* be used as the video driver.  I did try xf86-video-modesetting, a
> few minutes ago and it does not support X Windows on my machine.

The in-kernel GMA500 driver is being used with xf86-video-modesetting and it
has some advantages over xf86-video-fbdev (like xrandr 1.2 so you can
configure the resolution of your external monitor).

I have seen occasional reports from users that the modesetting driver fails
to detect the Poulsbo graphics, but due to lack of hardware I could not
investigate further. If the modesetting driver does not work for you, then it
would be a good idea to report a bug at https://bugs.freedesktop.org/ and
include the relevant logs.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Mike Frysinger]

On Wednesday 28 November 2012 16:49:14 Justin wrote:
> Problem:
> Some packages aren't lucky and their buildsystem doesn't create
> pkg-config files out of the box.
> 
> Solution:
> Create them by hand.

i agree this is a problem.  but i think the only real place to fix this is in 
the upstream package.  otherwise, the .pc file is largely unused and kind of 
pointless.  other people have already enumerated more detailed responses, so 
i'll just leave it at this.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Richard Yao]

On 11/28/2012 05:21 PM, Michał Górny wrote:
> On Wed, 28 Nov 2012 22:49:14 +0100
> Justin  wrote:
> 
>> Hi,
>>
>> and another one.
>>
>> Problem:
>> Some packages aren't lucky and their buildsystem doesn't create
>> pkg-config files out of the box.
>>
>> Solution:
>> Create them by hand.
> 
> Result:
> packages which fail to build on distributions other than Gentoo because
> their authors were using Gentoo and didn't knew that the pkg-config
> aren't anywhere else.
> 

I suspect that the .pc files would probably be available if people
installed -dev packages. If not, people can blame the distribution
developers for breaking things.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass

[Duncan]

Richard Yao posted on Wed, 28 Nov 2012 20:26:00 -0500 as excerpted:

> On 11/28/2012 05:21 PM, Michał Górny wrote:
>> On Wed, 28 Nov 2012 22:49:14 +0100 Justin  wrote:
>> 
>>> Hi,
>>>
>>> and another one.
>>>
>>> Problem:
>>> Some packages aren't lucky and their buildsystem doesn't create
>>> pkg-config files out of the box.
>>>
>>> Solution:
>>> Create them by hand.
>> 
>> Result:
>> packages which fail to build on distributions other than Gentoo because
>> their authors were using Gentoo and didn't knew that the pkg-config
>> aren't anywhere else.
>> 
>> 
> I suspect that the .pc files would probably be available if people
> installed -dev packages. If not, people can blame the distribution
> developers for breaking things.

You missed the point.  This has nothing to do with the usual -dev 
packages on binary distros.

If the upstream devs for a package, call it package A, depending on and 
using a library, call it library B, are on gentoo, and gentoo's creating 
the *.pc files for library B because its upstream doesn't, then the devs 
of package A, being on gentoo, won't be aware that the upstream library B 
doesn't provide the *.pc files, since they're there on a gentoo system, 
because gentoo's providing them.

So the package A developer (on gentoo) will depend on library B's *.pc 
file, wrongly believing it's provided by upstream, when it's not, thus 
screwing up things for all the OTHER distros when they try to build 
package A, because it's trying to use a non-existent *.pc file that 
library B should have provided, but didn't.

The only proper way to fix it, therefore, is to persuade upstream to 
include the *.pc file, NOT for gentoo to provide what upstream should be 
shipping, but isn't.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Chí-Thanh Christopher Nguyễn]

hasufell schrieb:
>> create_pkgconfig()
> 
> this sounds like a very bad idea.
> 
> pkgconfig files are common interfaces and should almost never be 
> created/modified/renamed anywhere except upstream.

X11 team considered doing exactly that once after the nouveau API break in
libdrm-2.4.33, splitting libdrm_nouveau-2.4.32 into its own separate
package and renaming/modifying libdrm_nouveau.pc to make it installable in
parallel to more recent libdrm[video_cards_nouveau] (bug 409593 comment
30). We ultimately decided against it though.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele

[Walter Dnes]

> The in-kernel GMA500 driver is being used with xf86-video-modesetting and it
> has some advantages over xf86-video-fbdev (like xrandr 1.2 so you can
> configure the resolution of your external monitor).
> 
> I have seen occasional reports from users that the modesetting driver
> fails to detect the Poulsbo graphics, but due to lack of hardware
> I could not investigate further. If the modesetting driver does
> not work for you, then it would be a good idea to report a bug at
> https://bugs.freedesktop.org/ and include the relevant logs.

  Xorg appears to segfault with the xf86-video-modesetting driver.  This
includes "Xorg -config".  Normally, I run with no xorg.conf, no evdev,
and no udev (I use mdev) and the machine works.  I don't know if they'll
accept a bug report due to my non-standard setup.

  I did some Google-searching.  The vast majority of hits either had
links to https://wiki.archlinux.org/index.php/Poulsbo (the Arch Linux
wiki) or else copied large portions of that page.  I followed their
instructions, but it did not help.  I'll do some more testing first, to
see if I can narrow down the bug.

-- 
Walter Dnes 

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Rémi Cardona]

Le mercredi 28 novembre 2012 à 22:49 +0100, Justin a écrit :
> Solution:
> Create them by hand.

The solution is to tell *upstream* how to build and ship .pc files with
their build system.

If we start shipping .pc files no one else has, projects that use such
libraries will have only 2 choices:

 - check the .pc file and use whatever fallback code they had before to
find the correct library paths and options.
 - change nothing and keep their current code

Either way, we'll be stuck maintaining .pc files no one will be using.

Please convince upstreams stuck in the middle ages that .pc files are a
Good Thing™ that make everybody's lives easier.

Cheers,

Rémi

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

On 29/11/12 02:14, Mike Frysinger wrote:
> On Wednesday 28 November 2012 16:49:14 Justin wrote:
>> Problem:
>> Some packages aren't lucky and their buildsystem doesn't create
>> pkg-config files out of the box.
>>
>> Solution:
>> Create them by hand.
> 
> i agree this is a problem.  but i think the only real place to fix this is in 
> the upstream package.  otherwise, the .pc file is largely unused and kind of 
> pointless.  other people have already enumerated more detailed responses, so 
> i'll just leave it at this.
> -mike
> 

Hi,

I will respond here, but this also is addressed to all the other
negative responses.

Let me explain the reason we (sci team) are using manually created .pc
files. And as a side note I totally agree with the statement that pc
file creation should be upstreams business.

Back to the problem. We are mainly using this approach to allow multiple
installations of packages providing BLAS and LAPACK implementations, and
its derivative. Why this? There is a reference implementation, a closed
source intel implementation, optimized versions for speed, a gnu version
and so on, from which the user should be able to choose. Still why we
need a switchable system? I would like to point [1] you to some great
GSOC work from andy which he also present in Praque [2]. He clearly
showed, that different implementations are good for different puposes.
Therefore we need to have different implementations installed in parallel.

Currently we have an eselect module to switch between different
implementations by setting /usr/lib/lib[blas,lapack].so to the selected
implementation.

This has two drawbacks, which some of you might already of hit:
1. They seem to be not completely API/ABI compatible (I don't which one
is correct here. And please don't be nitpicking on this point). So
switching would mean recompilation of all packages linked against it
before, otherwise you might get runtime errors. This takes time and
triggers point 2.

2. As andy showed we should stick with specific implementations for
specific tasks. The current way flattens this out to be optimal for some
and suboptimal for others.

Now, there has been a lot of effort around Andy and Sebastien to solve
this problem. The solution is simple: don't install any libblas.so or
liblapack.so in libdir, but instead make the pkg-config module
eselectable and force packages to used pkg-config. Nearly (I think its
100%) of the packages in the tree already use pkg-config to detect
blas/lapack.

The only remaining problem is on the implementation side. As you can
imagine, this effort is nothing in which the upstreams are really
interested in. Therefore most of our .pc files are created inside the
ebuild. Eventually they will find their way back upstream, but currently
this is something gentoo specific, it's about choices.

The eclass should just be a reduction of redundant code. And of course
its not meant to be a replacement to upstream work on packages with sane
buildsystems. Its just a last resort for corner cases like our
lapack/blas stuff, which do not have any reasonable option.

I hope this clears my intention and makes it reasonable to have this eclass,

justin


1)
https://github.com/andyspiros/numbench/wiki
http://andyspiros.wordpress.com/category/google-summer-of-code/

2)
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/miniconf/presentations/miniconf-2012-numbench-spiros.pdf



signature.asc
Description: OpenPGP digital signature