Re: [gentoo-dev] svn.overlays migration/downtime

2008-10-12 Thread Robin H. Johnson
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).

No problems expected, since our testing went fine already.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgprWNWl5JhEC.pgp
Description: PGP signature


[gentoo-dev] Last rites: net-mail/qmail-vmailmgr

2008-10-12 Thread Thilo Bangert
# Thilo Bangert [EMAIL PROTECTED] (12 Oct 2008)
# Masked for removal in 30 days (see bug #240371)
# useless meta ebuild - never fully developed
net-mail/qmail-vmailmgr


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


Re: [gentoo-dev] svn.overlays migration/downtime

2008-10-12 Thread Robin H. Johnson
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


[gentoo-dev] RFC: fox.eclass update

2008-10-12 Thread Matti Bickel
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
fi
}

fox_src_install () {
cd ${S}/${FOX_COMPONENT}


[gentoo-dev] System packages in (R)DEPEND?

2008-10-12 Thread Thomas Sachau
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] Re: System packages in (R)DEPEND?

2008-10-12 Thread Duncan
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] Automated Package Removal and Addition Tracker, for the week ending 2008-10-12 23h59 UTC

2008-10-12 Thread Robin H. Johnson
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: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

2008-10-12 Thread Steve Long
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] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-12 Thread Steve Long
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: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-12 Thread Steve Long
Jeremy Olexa wrote:

 Fabian Groffen wrote:
 snip
 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.