[gentoo-dev] Re: bzr.eclass into Portage
> On Mon, 13 Oct 2008, Steve Long wrote:
> No objections, a minor point wrt bash:
> EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
> doesn't do anything (beyond waste lex and yacc time.)
It does something, namely assigns an empty string if the variable was
undefined before. ;-) git.eclass and mercurial.eclass do
: ${EGIT_OPTIONS:=}
which has the same effect.
I've left these statements in for now, since I don't see how they
could harm. Does anyone else have an opinion here? I'm not really
decided about this point.
> [[ -z ${EBZR_REPO_URI} ]] && die ..
> Here's how I'd write that:
> [[ $EBZR_REPO_URI ]] || die ..
Applied. (However, I didn't remove the curly braces which are Gentoo
"house style".)
> I've heard the "be explicit" argument before (hey antarus;) and
> here's why I disagree:
> If you don't know test (''help test'') and what its default is, then
> you really don't know the basics of shellscript (you possibly only
> think you do.) If you don't know shell, and can't begin to
> understand what that might do, then you shouldn't consider coding as
> a career, and I'd expect you to take quite a while to go through the
> #bash crucible; if you ever make it I'd have a lot of time for you.
Don't use a sledgehammer to crack a nut. The above is purely a
question of coding style and personal preferences.
> Given that, is there any reason not to use 1.6 if installed, and
> fallback to an earlier version if not?
Of course not. The dependency is DEPEND=">=dev-util/bzr-1.5".
Ulrich
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
Jeremy Olexa wrote: > Fabian Groffen wrote: > >> Most notably, in Prefix all keywords are full GLEP53 style, which >> results in e.g. amd64-linux. We did this on purpose, because in Prefix >> we don't necessarily are on Gentoo Linux. We also chose to expand fbsd, >> nbsd and obsd to their long variants, mainly because the short variants >> might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD, >> polyBSD or DragonflyBSD, DesktopBSD. (At some point we were a bit >> over-enthausiastic.) >> >> I would like to hear some opinions on the keywords in general, as well >> as the particular problem of having Gentoo Linux, and a Linux supported >> by Gentoo Prefix. Would it not be simpler just to say the keyword can be from 1 to 4 hypen-separated parts, 1 as-is (in both GLEPS) 2 as GLEP 53, 3 with libc change, and 4 with non-default userland as per GLEP22 (perhaps change the order to be more intuitive, if you think it would be better)? >> Right now there is just the difference of "-linux" >> appended, however this is not the clearest distinction between the two. >> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do, >> and should we use something like PREFIX_KEYWORDS? > > Ignoring the bit about how to name the keywords.. ;) > > I am undecided about Prefix keywords in the normal KEYWORDS variable. In > particular, we are overloading the -linux keyword to mean that it will > run on any linux that Gentoo Prefix supports. This includes, Gentoo, > RHEL, SLES, FreeMint, $OTHER. > > Is there any problem with "overloading" the keywords like that? If not, > then it shouldn't be a problem to keep prefix keywords in the KEYWORDS > field. OTOH, I don't think we should add another variable to ebuilds. > > Thoughts? > Wrt to the variable thing, I agree the specification of prefix is orthogonal to the spec of an EAPI. Orthogonality [at least in sw terms] doesn't just mean "nothing to do with it whatsoever," or it wouldn't apply to the software in question. Unless someone can say what using PROPERTIES=prefix would break, I'd go with that. It's a /classic/ usage of that variable, as it's simply a boolean; PROPERTIES is well-defined and I'm hoping all the manglers support it. It'd be great to see the prefix branch finally merged so we all get to play with it.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Thomas Sachau wrote:
> what about this:
> insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across the
board?
[EMAIL PROTECTED] NB: I'm raising this as a talking-point, not pushing it as an
agenda,
so please don't reply if discussion doesn't interest you.]
Besides being faster (quote the whole thing) they leave the option in future
of having package names etc with spaces, or at this point, more useful
error messages in the case of a dev/user slip-up. They also highlight
better in a capable editor.[1]
iow: insinto "/usr/share/doc/$P/examples"
[1] Try kate, if gvim and xemacs don't do it for you: that quoting error of
yours in the other thread would be a very good example-- it simply wouldn't
happen on kate unless you had a very strange (ie functionally useless;)
colour setup.
[gentoo-dev] Re: bzr.eclass into Portage
Ulrich Mueller wrote:
>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:
>
>> No objections here, just a question. Do you know if the issue with the
>> lp:// sources has been fixed in bzr?
>
No objections, a minor point wrt bash:
EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
doesn't do anything (beyond waste lex and yacc time.) I can understand the
maintenance argument, but I don't think it really flies, given the
inordinate lengths considered in the past to avoid sourcing an ebuild.
The same consideration applies to all those "constant values" 'and indeed'
${foo} as opposed to $foo, though first time I raised that I got sworn at,
so not expecting miracles here.
[[ -z ${EBZR_REPO_URI} ]] && die ..
Here's how I'd write that:
[[ $EBZR_REPO_URI ]] || die ..
I've heard the "be explicit" argument before (hey antarus;) and here's why I
disagree:
If you don't know test (''help test'') and what its default is, then you
really don't know the basics of shellscript (you possibly only think you
do.) If you don't know shell, and can't begin to understand what that might
do, then you shouldn't consider coding as a career, and I'd expect you to
take quite a while to go through the #bash crucible; if you ever make it
I'd have a lot of time for you.
(Since you use || elsewhere, I don't expect to hear the "|| is cryptic even
if we say OR in speech" argument.)
I appreciate that appears like 3 or 4 points: they all come under the 'clean
bash' heading: it runs faster, as well as being easier to read and write.
> Looks like this is working fine with bzr-1.5, so I'll change the
> dependency.
>
Given that, is there any reason not to use 1.6 if installed, and fallback to
an earlier version if not? Personally I'd just use an unversioned dep in
the latter case, given that 1.5 is stable and 1.7.1 is ~arch (amd64).
Doesn't sound like it's going to be long to get 1.6.
I'm thinking: "maximise utility before you unleash it on the tree".
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Ryan Hill wrote: > Zac Medico <[EMAIL PROTECTED]> wrote: >> Ryan Hill wrote: >> > Though I'm still not sure what happens when a package is in two >> > unrelated sets.. >> > >> > @gnome: >> >RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2" >> > >> > @xfce4: >> >RDEPEND="gnome-extra/gnome-screensaver" >> > >> > package.use: >> > @gnome opengl >> > @xfce -opengl >> >> I suppose we could use the order that they are listed in package.use >> to apply the incremental stacking, so opengl would be disabled since >> @xfce comes after @gnome. > > I guess I'll need to stop sorting my package.use then. :p > > But yeah, I have no better idea. If someone really needs to lock down > a USE flag on a pkg they can put the pkg atom itself into p.use. > Indeed, although a more natural approach might be to take whichever dependency is more specific (in the case where the user hasn't otherwise expressed a preference, and there is a conflict.) The more specific dep implies a closer relationship (although a warning would be useful ofc.) Another way to express preference or association might be useful too, although a category heuristic would also aid automated decision-making (the set is being considered, so I'm guessing we know, which packages are listed in it; can easily query if not.) The fallback would be the simple position in the list. While this might sound like yet more special-casing it's the kind of thing that delights users ime, since it means less for them to worry about, and only runs in the case where the decision is not clear from the configuration and the tree. IOW something to specify as a 'may' rather than 'undefined.' (I still feel the same about losing 'world' ofc *sniff* ;)
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Peter Volkov wrote:
> Robert Buchholz ?:
>> Thilo Bangert wrote:
>> > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/";
>>
>> Why not use our package site for this, i.e.
>> HOMEPAGE="http://packages.gentoo.org/package/${CAT}/${PN}";
>
> This is not homepage. HOMEPAGE should point to "package dependent
> information" or in other words to upstream.
Er it is package-specific, and this is for where there is no upstream.
> Same stands to existent or nonexistent link on gentoo.org or any other
> domain. This is even worth as this solution also makes users to open
> another page which just tell them that homepage does not exist...
>
No, the packages site links to a forum search (I'd personally make that
a 'site:forums.gentoo.org' google search across the board, since it's so
much handier, and get some adsense bucks while you're there;) and a
bugzilla search, as well as giving information about all the available
versions in the tree. You should check it out ;p
> So I think if HOMEPAGE does not exist then it's better either put some
> constant there or better make it empty. If we wish, for packages with
> empty HOMEPAGE we can teach tools like emerge -s or eix to show "Home
> page unknown" or "Homepage does not exist". Simple and clear, what else
> do we need? :)
>
An easy way for Gentoo users to contact other people using the software;
given that it's available on Gentoo, and officially dead as far as Gentoo
is aware, having the cli interface display that url (however formulated) is
a plus in support terms, and maybe one day getting the package resurrected.
A gui wrapper like himerge would display the link as clickable, as would a
suitably configured xterm.
So while I agree the empty value in the ebuild is the way to go, I'd
personally like it a lot if Portage at least displayed a useful url (and
the website was ok with it.) If you're going that far for the official
mangler and the site, it seems like something to mandate/specify (I
really /don't/ want to file that bug;)
Is there at least consensus that the above formulation wrt user-display, and
zero-length, would be useful?
(Leaving aside concerns over backward-compatibility/EAPI.)
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-10-12 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-10-12 23h59 UTC. Removals: dev-tex/vntex 2008-10-06 19:53:29 aballier media-sound/gogo2008-10-08 16:08:15 mr_bones_ www-apps/xrms 2008-10-11 19:12:23 wrobel www-apps/bugport2008-10-12 05:49:06 wrobel Additions: dev-db/maatkit 2008-10-06 11:34:32 wschlich sys-apps/fakeroot-ng2008-10-06 21:55:10 spock media-libs/realcodecs 2008-10-07 15:02:53 beandog media-libs/babl 2008-10-07 21:34:20 hanno media-libs/gegl 2008-10-07 22:12:50 hanno dev-lang/c-intercal 2008-10-08 00:58:26 ulm x11-misc/ktsuss 2008-10-09 05:06:39 darkside app-dicts/stardict-freedict-tur-eng 2008-10-09 19:17:24 serkan app-dicts/stardict-freedict-tur-deu 2008-10-09 19:21:08 serkan app-dicts/stardict-freedict-eng-tur 2008-10-09 19:24:19 serkan games-arcade/tecnoballz 2008-10-09 20:42:44 tupone dev-java/jpf2008-10-11 19:50:07 caster media-libs/exempi 2008-10-11 22:30:41 eva gnome-extra/gnome-user-share2008-10-12 20:14:39 eva -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-tex/vntex,removed,aballier,2008-10-06 19:53:29 media-sound/gogo,removed,mr_bones_,2008-10-08 16:08:15 www-apps/xrms,removed,wrobel,2008-10-11 19:12:23 www-apps/bugport,removed,wrobel,2008-10-12 05:49:06 Added Packages: dev-db/maatkit,added,wschlich,2008-10-06 11:34:32 sys-apps/fakeroot-ng,added,spock,2008-10-06 21:55:10 media-libs/realcodecs,added,beandog,2008-10-07 15:02:53 media-libs/babl,added,hanno,2008-10-07 21:34:20 media-libs/gegl,added,hanno,2008-10-07 22:12:50 dev-lang/c-intercal,added,ulm,2008-10-08 00:58:26 x11-misc/ktsuss,added,darkside,2008-10-09 05:06:39 app-dicts/stardict-freedict-tur-eng,added,serkan,2008-10-09 19:17:24 app-dicts/stardict-freedict-tur-deu,added,serkan,2008-10-09 19:21:08 app-dicts/stardict-freedict-eng-tur,added,serkan,2008-10-09 19:24:19 games-arcade/tecnoballz,added,tupone,2008-10-09 20:42:44 dev-java/jpf,added,caster,2008-10-11 19:50:07 media-libs/exempi,added,eva,2008-10-11 22:30:41 gnome-extra/gnome-user-share,added,eva,2008-10-12 20:14:39 Done.
[gentoo-dev] Re: System packages in (R)DEPEND?
Thomas Sachau <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 12 Oct 2008 19:04:21 +0200: > I see packages like bison, flex, perl or sed in the system set. And i > also see ebuilds depending on them. I also heard from Peter Volkov (pva) > that there where discussions about removing different packages from the > system set. So now my question is: > > Should we depend on all system packages? Should we depend on some > packages, because they could be removed? If yes, which ones? Or should > we leave the system packages out completly? The idea has been to reduce the system set, but packages coming out of it will of necessity need to be widely known. Meanwhile, in general, the system set should be reasonable to rely on in general. The cases where system packages are in depends should generally be limited to those in which it's necessary to resolve circular dependencies, with the help of USE=build and boostrap, or to other special cases (like a dependency on a specific USE flag on a system package, or where not all profiles may depend on the same system packages, etc). IOW, "normal" packages shouldn't need to specify "normal" dependencies on system packages. At least, that's how I've read the discussion I've seen to date. -- 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] System packages in (R)DEPEND?
I see packages like bison, flex, perl or sed in the system set. And i also see ebuilds depending on them. I also heard from Peter Volkov (pva) that there where discussions about removing different packages from the system set. So now my question is: Should we depend on all system packages? Should we depend on some packages, because they could be removed? If yes, which ones? Or should we leave the system packages out completly? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: fox.eclass update
Hi folks,
While fixing bug #240060 I touched fox.eclass.
In the process, I updated the eclass to
* use versionator
* cut support for fox-1.0 (loong outdated)
* cut support for fox-1.5
* use eautomake instead of =automake-1.4*
* use emake instead of make
* use elog instead of einfo
* apply more variable quoting
I'm sure, I missed one or the other issue. That's why I'm posting it
here for public review. If you have requests or comments to make, please
reply to this thread.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06
mabi Exp $
# fox eclass
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.4: '=x11-libs/fox-1.4*'
# 1.5: '~x11-libs/fox-${PV}'
# 1.6: '=x11-libs/fox-${FOXVER}*'
#
# Some concepts borrowed from gst-plugins and gtk-sharp-component eclasses
inherit autotools eutils libtool versionator
FOX_PV="${FOX_PV:-${PV}}"
FOXVER=$(get_version_component_range 1-2)
FOXVER_SUFFIX="-${FOXVER}"
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
SRC_URI="http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz";
IUSE="debug doc profile"
FOX_APPS="adie calculator pathfinder shutterbug chart"
if [ "${PN}" != fox ] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
if [ "${PN}" != reswrap ] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
DEPEND="${RESWRAP_DEP}
doc? ( app-doc/doxygen )
>=sys-devel/automake-1.4
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
cd "${S}"
ebegin "Fixing configure"
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=""::' configure.in || die "sed configure.in error"
touch aclocal.m4
sed -i -e 's:CXXFLAGS=""::' configure || die "sed configure error"
eend
ebegin "Fixing Makefiles"
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e "s:${d}::" Makefile.am || die "sed Makefile.am error"
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
if version_is_at_least "1.6.34" ${PV}; then
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die "sed ${d}/Makefile.am
error"
else
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox${FOXVER_SUFFIX}:" \
-e 's:../src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die "sed ${d}/Makefile.am
error"
fi
done
eend
ebegin "Running automake"
eautomake || die "automake error"
eend
#elibtoolize
}
fox_src_compile() {
local myconf
use debug && myconf="${myconf} --enable-debug" \
|| myconf="${myconf} --enable-release"
econf \
${FOXCONF} \
${myconf} \
$(use_with profile profiling) \
|| die "configure error"
cd "${S}/${FOX_COMPONENT}"
emake || die "compile error"
# build class reference docs (FOXVER >= 1.2)
if use doc && [ -z "${FOX_COMPONENT}" ] ; then
cd "${S}/doc"
emake docs || die "doxygen error"
Re: [gentoo-dev] svn.overlays migration/downtime
On Sat, Oct 11, 2008 at 11:05:47PM -0700, Robin H. Johnson wrote:
> On Sat, Oct 11, 2008 at 12:50:40AM -0700, Robin H. Johnson wrote:
> > Hi Folks,
> >
> > At some point over this weekend (we haven't pinned an exact time yet,
> > details to follow), there's going to be a ~5-minute outage of overlays
> > SVN service to move SVN onto the new server.
> Unless there's any objections, I'm going to try to do this at 07h30 UTC,
> Oct 12th. (45 minutes from now).
Overlays have now been migrated to the new hardware, just in time too,
the hard drive on the old box started showing signs of failure.
Further notes:
--
1. SSL for commits:
As originally discussed way back in January when I laid out the big
infra projects for the year, commits must now be performed via HTTPS.
Non-SSL commits are no longer possible (partially for security, but also
to aid the Squid caching).
It's very easy to switch your repository:
# repo=$(svn info |awk '/^Repository Root:/{print $3}')
# svn sw --relocate ${repo} ${repo/http:/https:}
2. SSL certificates:
The same old overlays.gentoo.org SSL certificate is still being used for
the moment. We will be switching the site to a CACert certificate, just
like forums and bugzie later this week.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpiRPQRnI30e.pgp
Description: PGP signature
