Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Donnie Berkholz wrote:
On 23:52 Tue 25 Nov , Peter Alfredsen (loki_val) wrote:
loki_val08/11/25 23:52:04
Added:gtk-sharp-module.eclass
Log:
eclass required for gnome-sharp and gnome-desktop-sharp packages
Did I miss this on gentoo-dev? All eclasses must be sent there for
review before addition to the tree.
*loki_val bumps his head into the wall.
See, what happened was...
I have been doing nothing else but testing and bumping dotnet packages
for the last 3 days when not at work, so I kind of forgot that step.
Fortunately all packages using this eclass are still in package.mask.
Anyway, the eclass is derived from the gtk-sharp-component eclass (which
is a real bitrot mess that has to support 3 or 4 different naming
schemes) and is basically a simplification of that.
if [[ ${gtk_sharp_module_list} == * ${GTK_SHARP_MODULE} * ]]
; then my_module_list=${gtk_sharp_module_list}
my_tarball=gtk-sharp
elif [[ ${gnome_sharp_module_list} == * ${GTK_SHARP_MODULE} *
]] ; then
This seems like a really strange strategy for checking whether a
certain item is in a list.
I disagree.
# Make selecting components configurable.
epatch ${WORKDIR}/${MY_P}-configurable.diff
This seems like something you might want optional, depending on some
variable.
It really isn't. That patch adds AC_ARG_ENABLEs to configure so we can
split up the gnome-sharp and gnome-desktop-sharp tarballs into smaller
pieces.
# Fixes support with pkgconfig-0.17, #92503.
sed -i -e 's/\PKG_PATH\/GTK_SHARP_PKG_PATH/g' \
-e ':^CFLAGS=:d' \
${S}/configure.in
It would be nice to quote all instances of $S, $D etc.
CanDo.
LANG=C emake -j1 || die emake failed
Worth a comment about parallel make being broken, with a reference to
the upstream bug.
This is inherited from the old eclass. Upstream does not care and
there's only work enough for one make job anyway.
Attached is a diff from the old eclass to the new eclass, generated
thusly:
diff -wU5 gtk-sharp-component.eclass gtk-sharp-module.eclass
--
/PA
--- gtk-sharp-component.eclass 2008-11-25 22:05:58.0 +0100
+++ gtk-sharp-module.eclass 2008-11-26 02:06:17.0 +0100
@@ -1,192 +1,180 @@
-# Copyright 1999-2004 Gentoo Foundation
+# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/gtk-sharp-component.eclass,v 1.29 2008/11/25 20:44:25 loki_val Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/gtk-sharp-module.eclass,v 1.2 2008/11/26 00:54:41 loki_val Exp $
-# Author : Peter Johanson [EMAIL PROTECTED]
+# Author : Peter Johanson [EMAIL PROTECTED], butchered by ikelos, then loki_val.
# Based off of original work in gst-plugins.eclass by [EMAIL PROTECTED]
+# Note that this breaks compatibility with the original gtk-sharp-component
+# eclass.
+
inherit eutils mono multilib autotools
-LICENSE=LGPL-2
+# Get the name of the component to build and the build dir; by default,
+# extract it from the ebuild's name.
+GTK_SHARP_MODULE=${GTK_SHARP_MODULE:=${PN/-sharp/}}
+GTK_SHARP_MODULE_DIR=${GTK_SHARP_MODULE_DIR:=${PN/-sharp/}}
+
+# In some cases the desired module cannot be configured to be built on its own.
+# This variable allows for the setting of additional configure-deps.
+GTK_SHARP_MODULE_DEPS=${GTK_SHARP_MODULE_DEPS}
+
+# Allow ebuilds to set a value for the required GtkSharp version; default to
+# ${PV}.
+GTK_SHARP_REQUIRED_VERSION=${GTK_SHARP_REQUIRED_VERSION:=${PV%.*}}
+
+# Version number used to differentiate between unversioned 1.0 series and the
+# versioned 2.0 series (2.0 series has 2 or 2.0 appended to various paths and
+# scripts). Default to ${SLOT}.
+GTK_SHARP_SLOT=${GTK_SHARP_SLOT:=${SLOT}}
+GTK_SHARP_SLOT_DEC=${GTK_SHARP_SLOT_DEC:=-${GTK_SHARP_SLOT}.0}
+
+# Set some defaults.
+DESCRIPTION=GtkSharp's ${GTK_SHARP_MODULE} module
+HOMEPAGE=http://www.mono-project.com/GtkSharp;
-HOMEPAGE=http://gtk-sharp.sourceforge.net/;
LICENSE=LGPL-2.1
-RESTRICT=test
-
-: GTK_SHARP_TARBALL_PREFIX=${GTK_SHARP_TARBALL_PREFIX:=gtk-sharp}
-
-: GTK_SHARP_REQUIRED_VERSION=${GTK_SHARP_REQUIRED_VERSION:=${PV%.*}}
-
-[ ${PV:0:1} == 2 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp-2.0/;
-
-# Can be switched to [ ${PV:0:3} == 2.8 ] when 2.8.0 is out of the tree.
-[ ${PV} == 2.8.2 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp-2.8/;
-
-[ ${PV%.*} == 2.10 ] || [ ${PV%.*} == 2.16 ] \
- SOURCE_SERVER=mirror://gnome/sources/${GTK_SHARP_TARBALL_PREFIX}/${PV%.*}/
-
-[ ${PV} == 1.0.10 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp/;
-
-[ -z ${SOURCE_SERVER} ] \
- SOURCE_SERVER=mirror://sourceforge/gtk-sharp/
-
-###
-# variable declarations
-###
-MY_P=${GTK_SHARP_TARBALL_PREFIX}-${PV}
-
-# From gtk-sharp-1.0 series
-my_gtk_sharp_components=art gda glade gnome gnomedb gtkhtml rsvg vte
-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wed, 26 Nov 2008 09:42:07 +0100 Peter Alfredsen [EMAIL PROTECTED] wrote: This seems like a really strange strategy for checking whether a certain item is in a list. I disagree. You do? Why do you think it's better than 'has'? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Some support for Sunrise Overlay :-)
Donnie Berkholz wrote: On 16:03 Mon 24 Nov , Homer Parker wrote: On Mon, 2008-11-24 at 11:45 +, Duncan wrote: That in fact is a big reason I never moved on becoming a Gentoo/amd64 AT, as well, since when I asked, they were doing most communication thru IRC, and that just doesn't work well for me. It's just that it's quicker and easier to get responses via IRC if you're there.. There's ATs that don't hang out in IRC and still follow bugzie and do their testing. Frankly, nothing works as well as IRC for realtime, interactive collaboration. That's why we don't use it ;)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Ciaran McCreesh wrote: On Wed, 26 Nov 2008 09:42:07 +0100 Peter Alfredsen [EMAIL PROTECTED] wrote: This seems like a really strange strategy for checking whether a certain item is in a list. I disagree. You do? Why do you think it's better than 'has'? Did I say that? I said that I disagree that it's a really strange strategy. -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Some support for Sunrise Overlay :-)
Nikos Chantziaras [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Nov 2008 12:37:45 +0200: Donnie Berkholz wrote: On 16:03 Mon 24 Nov , Homer Parker wrote: On Mon, 2008-11-24 at 11:45 +, Duncan wrote: That in fact is a big reason I never moved on becoming a Gentoo/amd64 AT, as well, since when I asked, they were doing most communication thru IRC, and that just doesn't work well for me. It's just that it's quicker and easier to get responses via IRC if you're there.. There's ATs that don't hang out in IRC and still follow bugzie and do their testing. Frankly, nothing works as well as IRC for realtime, interactive collaboration. That's why we don't use it ;) Exactly. =:^) I'm really too deliberative a thinker to comfortably keep up with IM/IRC, and there tend to be problems with either incoming message overload or (effectively) remote end time-out because they get bored waiting for me. OTOH, mailing lists and newsgroup servers where most users are on the same server and working at the same time, can work very close to real- time as well, except the technology buffers incoming messages somewhat better when necessary, and it doesn't matter so much if you take 20 minutes to compose a reply. Then there's the whole I want to schedule my own time thing, where IM, as with phones, can be very annoying due to the right now aspect. That sort of irritation just doesn't exist using a mailinglist/newsgroup, as the timing assumptions are very different. Nothing against those for whom it works. It just doesn't work for everyone. -- 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] Re: Some support for Sunrise Overlay :-)
On Wed, Nov 26, 2008 at 4:02 PM, Duncan [EMAIL PROTECTED] wrote: Exactly. =:^) I'm really too deliberative a thinker to comfortably keep up with IM/IRC, and there tend to be problems with either incoming message overload or (effectively) remote end time-out because they get bored waiting for me. If there are Sunrise collaborators (or people with strong intentions of becoming one) who want to propose a Sunrise mailing list, that's fine. Otherwise, this discussion is pointless. I don't think we want to start a debate in @gentoo-dev where everyone in this list state his opinion about what communication methods are more effective. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On 09:42 Wed 26 Nov , Peter Alfredsen wrote:
On Wednesday 26 November 2008, Donnie Berkholz wrote:
# Make selecting components configurable.
epatch ${WORKDIR}/${MY_P}-configurable.diff
This seems like something you might want optional, depending on some
variable.
It really isn't. That patch adds AC_ARG_ENABLEs to configure so we can
split up the gnome-sharp and gnome-desktop-sharp tarballs into smaller
pieces.
I'm thinking of what happens when you don't need the patch anymore for a
newer release but still do for an older one. Or maybe you update the
patch and want to test it on ~arch revisions for a while before hitting
stable users with it.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpKad2HZ4sCF.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On 15:39 Wed 26 Nov , Peter Alfredsen wrote: On Wednesday 26 November 2008, Ciaran McCreesh wrote: On Wed, 26 Nov 2008 09:42:07 +0100 Peter Alfredsen [EMAIL PROTECTED] wrote: This seems like a really strange strategy for checking whether a certain item is in a list. I disagree. You do? Why do you think it's better than 'has'? Did I say that? I said that I disagree that it's a really strange strategy. Consider strange replaced with suboptimal and overly complex then. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpwinrmZBT4o.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Donnie Berkholz wrote:
On 09:42 Wed 26 Nov , Peter Alfredsen wrote:
On Wednesday 26 November 2008, Donnie Berkholz wrote:
# Make selecting components configurable.
epatch ${WORKDIR}/${MY_P}-configurable.diff
This seems like something you might want optional, depending on
some variable.
It really isn't. That patch adds AC_ARG_ENABLEs to configure so we
can split up the gnome-sharp and gnome-desktop-sharp tarballs into
smaller pieces.
I'm thinking of what happens when you don't need the patch anymore
for a newer release but still do for an older one.
Then I add in the $PATCH_ACCEPTED_UPSTREAM var.
Or maybe you
update the patch and want to test it on ~arch revisions for a while
before hitting stable users with it.
I could add another var into the mix.
This isn't a catch-all eclass. It's designed for a very narrow group of
ebuilds which will only get smaller as I transition the packages to
eapi-2 and use depends.
--
/PA
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Linux 2.6.27 stabilisation plans
Hi, I'm tentatively planning to request that gentoo-sources-2.6.27 gets marked stable on x86+amd64 on December 15th, assuming we have fixed all regressions (we have some open, which will hopefully be fixed soon). Kernel-dependent packages that are broken by this upgrade are tracked at https://bugs.gentoo.org/show_bug.cgi?id=242708 Please help us fix these in the stable tree in advance of the stabling date. Thanks, Daniel
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
Peter Alfredsen [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Nov 2008 20:38:39 +0100: This isn't a catch-all eclass. It's designed for a very narrow group of ebuilds which will only get smaller as I transition the packages to eapi-2 and use depends. In that case, it may be better to do the limited code duplication, given the relative permanence of eclasses. They gotta stick around long after any ebuilds using them are gone, altho with newer portage (and I'd hope other PMs as well) that isn't /quite/ the problem it used to be. -- 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
[gentoo-dev] Re: [gentoo-council] Nominations open for 1 council slot - 48 hours left
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. This is a heads-up that the nominations will close in approximately 48 hours. So if you want to nominate anyone (yourself?), go on and send your mail to the gentoo-council ml. Donnie Berkholz wrote: Hi all, We have 1 open council slot because jokey got busy with real life. The council decided to open nominations for the next week, until 23:59 UTC Friday. Shortly after that, we will begin a week-long voting period. If you would like to nominate someone, please subscribe to the gentoo-council mailing list and reply to this email, ensuring it's sent there. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkt7/cACgkQcAWygvVEyAIROgCgisnUrrDm6i5ZVeowtRch8P/p oDkAnR4SLmUujQ1T3DWCQZTAxiRoQ8yg =7yKd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Thursday 27 November 2008, Duncan wrote: In that case, it may be better to do the limited code duplication, given the relative permanence of eclasses. So, what is it we're short of? Developer time or harddrive space? Is our problem that our packages start to bitrot or that we have huge number of bitrotting eclasses? Just saying. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?
Is there syntax in eix for querying: is package X installed with a
version X.Y or higher?
Amit
René 'Necoro' Neumann wrote:
Amit Dor-Shifer schrieb:
Thanks :)
Reason I thought this is relevant is: I'm basically looking for an API
to get an installed package's version/rev. I prefer that over making
syntactical assumptions on the way portage names packages.
Taking RPM for example, there's such an API: something like rpm -q
--queryformat '%{VERSION}|' PKG_NAME if I remember correctly.|
Amit
You could also use eix ... though I needed quite a time to figure it
out ;)
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort
1.9.6-r2 1.10.1-r1
Note however, that if you a package has multiple installed versions,
they are seperated by space. One could use
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort:\n
But this prints an additional empty line at the beginning.
Andrew Gaffney wrote:
Amit Dor-Shifer wrote:
Given the following:
# qlist -Iv sys-apps/portage
sys-apps/portage-2.1.4.5
How do I safely extract the 2.1.4.5?
That's probably offtopic for this list, since it really has nothing to
do with portage itself. However, you probably want something like:
qlist -Iv sys-apps/portage | sed -e 's:^.*-\([0-9][^-_]*\).*$:\1:'
Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?
On Wed, Nov 26, 2008 at 3:13 AM, Amit Dor-Shifer [EMAIL PROTECTED] wrote:
Is there syntax in eix for querying: is package X installed with a version
X.Y or higher?
Amit
portageq has_version / ATOM
René 'Necoro' Neumann wrote:
Amit Dor-Shifer schrieb:
Thanks :)
Reason I thought this is relevant is: I'm basically looking for an API
to get an installed package's version/rev. I prefer that over making
syntactical assumptions on the way portage names packages.
Taking RPM for example, there's such an API: something like rpm -q
--queryformat '%{VERSION}|' PKG_NAME if I remember correctly.|
Amit
You could also use eix ... though I needed quite a time to figure it out
;)
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort
1.9.6-r2 1.10.1-r1
Note however, that if you a package has multiple installed versions,
they are seperated by space. One could use
# PRINT_SLOTS=false eix -e -I sys-devel/automake --pure-packages
--format installedversionsshort:\n
But this prints an additional empty line at the beginning.
Andrew Gaffney wrote:
Amit Dor-Shifer wrote:
Given the following:
# qlist -Iv sys-apps/portage
sys-apps/portage-2.1.4.5
How do I safely extract the 2.1.4.5?
That's probably offtopic for this list, since it really has nothing to
do with portage itself. However, you probably want something like:
qlist -Iv sys-apps/portage | sed -e 's:^.*-\([0-9][^-_]*\).*$:\1:'
