[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/tikiwiki: ChangeLog tikiwiki-1.9.8.1.ebuild
Donnie Berkholz [EMAIL PROTECTED] writes:
On 12:35 Fri 12 Oct , Gunnar Wrobel (wrobel) wrote:
1.1 www-apps/tikiwiki/tikiwiki-1.9.8.1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apps/tikiwiki/tikiwiki-1.9.8.1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-apps/tikiwiki/tikiwiki-1.9.8.1.ebuild?rev=1.1content-type=text/plain
You've got quoting issues in here, are you using current portage?
No. Did the bumping on a stable machine :) Thanks for the note. Fixed.
pkg_config() {
elog Type in your MySQL root password to create an empty tiki
database:
mysqladmin -u root -p create tikiwiki
}
Could this respect ROOT?
For a mysql db? I'm not sure I follow but the pkg_config was something
I should have removed anyhow.
Cheers,
Gunnar
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
--
Gunnar WrobelGentoo Developer
__C_o_n_t_a_c_t__
Mail: [EMAIL PROTECTED]
WWW: http://www.gunnarwrobel.de
IRC: #gentoo-web at freenode.org
_
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/tikiwiki: ChangeLog tikiwiki-1.9.8.1.ebuild
On 10:10 Sat 13 Oct , Gunnar Wrobel wrote: Could this respect ROOT? For a mysql db? I'm not sure I follow but the pkg_config was something I should have removed anyhow. Sure. I could envision mounting / of a database server onto a build server and building with ROOT, to avoid sucking up much-needed CPU/memory on the DB server. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
* Donnie Berkholz [EMAIL PROTECTED]:
On 13:25 Fri 12 Oct , Remi Cardona (remi) wrote:
1.1
dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1content-type=text/plain
pkg_postinst() {
python_version
python_mod_optimize
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
pkg_postrm() {
python_version
python_mod_cleanup
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
python_mod_optimize() and python_mod_cleanup() already tag ROOT on,
python_mod_optimize() does not.
so for ROOT != / this is broken.
But does python_mod_optimize do anything useful with ROOT !=/ and
cross-compilation? What if python versions differ?
--
.: Torsten Veller | :.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
On 10:44 Sat 13 Oct , Torsten Veller wrote:
* Donnie Berkholz [EMAIL PROTECTED]:
python_mod_optimize() and python_mod_cleanup() already tag ROOT on,
python_mod_optimize() does not.
Mine does:
python_mod_optimize() {
local myroot
# strip trailing slash
myroot=${ROOT%/}
...
ebegin Byte compiling python modules for python-${PYVER} ..
python${PYVER} ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py ${c$
python${PYVER} -O ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py $
eend $?
}
so for ROOT != / this is broken.
But does python_mod_optimize do anything useful with ROOT !=/ and
cross-compilation? What if python versions differ?
That's a good question, and it looks like python_version() could use a
fix for ROOT != / on same-arch systems. On cross-compiled, it'll
probably be more work and I'm not sure how to deal with it.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
* Donnie Berkholz [EMAIL PROTECTED]:
On 10:44 Sat 13 Oct , Torsten Veller wrote:
* Donnie Berkholz [EMAIL PROTECTED]:
python_mod_optimize() and python_mod_cleanup() already tag ROOT on,
python_mod_optimize() does not.
Mine does:
python_mod_optimize() {
local myroot
# strip trailing slash
myroot=${ROOT%/}
...
ebegin Byte compiling python modules for python-${PYVER} ..
python${PYVER} ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py
${compileopts} $@
python${PYVER} -O
${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py ${compileopts} $@
eend $?
}
No. The arguments of python_mod_optimize are just passed to the ROOTed
compileall.py.
--
.: Torsten Veller | :.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
Donnie Berkholz wrote:
python_mod_optimize() {
local myroot
# strip trailing slash
myroot=${ROOT%/}
...
ebegin Byte compiling python modules for python-${PYVER} ..
python${PYVER} ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py
${c$
python${PYVER} -O
${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py $
eend $?
}
Could the python eclass have a function (or whatever as I'm no bash
guru) that returns this :
${ROOT}/usr/$(get_libdir)/python${PYVER}/
We use it over and over in all our ebuilds, and it's error-prone as my
last few commits have shown.
Cheers,
Rémi
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/lirc: ChangeLog lirc-0.8.2-r2.ebuild
On Freitag, 12. Oktober 2007, Donnie Berkholz wrote:
On 19:35 Thu 11 Oct , Matthias Schwarzott (zzam) wrote:
1.1 app-misc/lirc/lirc-0.8.2-r2.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lirc/lirc-0.8.2-
r2.ebuild?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lirc/lirc-0.8.2-
r2.ebuild?rev=1.1content-type=text/plain
add_device() {
((lirc_device_count++))
[skip lots of code]
lirc_driver_count=0
driver != device
Might be useful to initialize it in add_device() if it's unset, so code
being this far apart won't get out of sync.
fixed
make DESTDIR=${D} install || die make install failed
If emake doesn't work, please add a comment to that effect.
changed it to emake for ~arch ebuild. Dont want to try that on stable without
knowing well.
newinitd ${FILESDIR}/lircd lircd
newinitd ${FILESDIR}/lircmd lircmd
newconfd ${FILESDIR}/lircd.conf lircd
insinto /etc/modules.d/
newins ${FILESDIR}/modulesd.lirc lirc
newinitd ${FILESDIR}/irexec-initd irexec
newconfd ${FILESDIR}/irexec-confd irexec
Quoting.
fixed
Matthias
--
Matthias Schwarzott (zzam)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
On 11:11 Sat 13 Oct , Torsten Veller wrote:
* Donnie Berkholz [EMAIL PROTECTED]:
On 10:44 Sat 13 Oct , Torsten Veller wrote:
* Donnie Berkholz [EMAIL PROTECTED]:
python_mod_optimize() and python_mod_cleanup() already tag ROOT on,
python_mod_optimize() does not.
Mine does:
python_mod_optimize() {
local myroot
# strip trailing slash
myroot=${ROOT%/}
...
ebegin Byte compiling python modules for python-${PYVER} ..
python${PYVER} ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py
${compileopts} $@
python${PYVER} -O
${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py ${compileopts} $@
eend $?
}
No. The arguments of python_mod_optimize are just passed to the ROOTed
compileall.py.
It took me about five minutes to figure out what you meant: this means
that the filenames do not get passed with ROOT prepended to them, so
compileall.py in ROOT compiles the files outside of ROOT.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: lame use flag, local to global
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 12 Oct 2007 17:22:54 -0700: Steve Long wrote: Duncan wrote: Steve Dibb posted: there is more than one mp3 encoder. [S]houldn't the description mention that? How about: Prefer using LAME for MP3 encoding support It doesn't mention anything else, so it'll work in all cases. WORKSFORME =8^) -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: www-client/planet
Am Mittwoch 10 Oktober 2007 schrieb Dawid Węgliński: www-client/planet [...] Anything to use instead? No ebuild for it, but blog harvester is an alternative: http://astroblog.spaceboyz.net/harvester/ it's suggested to use svn version. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new category for texlive modular ebuilds?
As nobody seems to complain about adding this category, I'll start adding it and populate it when I'll have a few spare hours to merge texlive. (most likely to be tomorrow) that'll leave dev-tex with generic tex packages and dev-texlive with various CTAN packages following how they're packaged into texlive upstream (and they'll probably not work with other tex distributions). Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Arch Testing Tool
On Wednesday 10 October 2007 04:54:13 Christian Faulhammer wrote: Hi, all arch devs interested in above tool (app-portage/gatt-svn), I wrote a little introduction for it. See Planet. V-Li From the Blog Post: 1. emerge the package with different USE flags Tasks 1, 2, 4 and 5 can be automated, while 3 needs some experience and brain-work. Gentoo Arch Testing Tool (Gatt) which comes in very handy at least in phase 1. However, the current gatt can't merge the packages with different USE flags yet(--with-use). Just thought I'd point that out. Thanks for the great tool! -- 2.6.22-gentoo-r8 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: lame use flag, local to global
On Sat, 2007-10-13 at 10:37 +, Duncan wrote: Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 12 Oct 2007 17:22:54 -0700: Steve Long wrote: Duncan wrote: Steve Dibb posted: there is more than one mp3 encoder. [S]houldn't the description mention that? How about: Prefer using LAME for MP3 encoding support It doesn't mention anything else, so it'll work in all cases. WORKSFORME =8^) InCVS... :P I've gone ahead and changed this. It isn't a harmful change, so I just went ahead and did it. Enjoy your newly modified description. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
RE: [gentoo-dev] Council meeting summary for 11 October 2007
Donnie Berkholz wrote: Here is the summary from today's council meeting. The complete log will show up at snip - The CoC is in effect, but it needs a new enforcement section since the proctors were disbanded. The council is sending discussion of this to the gentoo-project list, to come up with proposals for three points: - who enforces it - musikc said devrel could - tsunam said userrel could snip I wanted to clarify, please understand the intent behind my part of the conversation was that devrel and userrel should continue to share the responsibility as appropriate, and continue to work together, including the questionable/overlapping areas. The above may have been misinterpreted by some to indicate 'pick which one', when my intent was a joined front on enforcing the CoC. Kind regards, Christina Fullam Gentoo Developer Relations Lead | Gentoo Public Relations -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Kolab2/Gentoo project
On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote: The project has advanced far enough though that I feel it is a good time point to declare this a real Gentoo project. http://www.gentoo.org/proj/en/kolab/index.xml Umm... why? Why does a package need a project? Is this not just a mail server? I don't mean any offense. I just want to know. Why do we need to create a project, which should normally be reserved for wide-sweeping changes or things that require massive amounts of coordination? Why is this not just a part of the net-mail herd? It *is* a mail system, is it not? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: lame use flag, local to global
Chris Gianelloni wrote: On Sat, 2007-10-13 at 10:37 +, Duncan wrote: Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 12 Oct 2007 17:22:54 -0700: Steve Long wrote: Duncan wrote: Steve Dibb posted: there is more than one mp3 encoder. [S]houldn't the description mention that? How about: Prefer using LAME for MP3 encoding support It doesn't mention anything else, so it'll work in all cases. WORKSFORME =8^) InCVS... :P I've gone ahead and changed this. It isn't a harmful change, so I just went ahead and did it. Enjoy your newly modified description. Yay! :-) I like the idea of the metadata addition (IUSE_DESC) Duncan mentioned as well, but I don't know how much work it would entail. Flags can have such varying effects, so it does strike me as very useful documentation, for maintenance as well as end-users. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Kolab2/Gentoo project
On Saturday, 13. October 2007 19:27:05 Chris Gianelloni wrote: On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote: The project has advanced far enough though that I feel it is a good time point to declare this a real Gentoo project. http://www.gentoo.org/proj/en/kolab/index.xml Umm... why? Why does a package need a project? Is this not just a mail server? It's a full-blown collaboration/groupware server and it will likely need a fair bit of coordination between different herds and maintainers as it uses several major F/OSS components which (at least until recently) need patches and integration changes to be usable with Kolab. http://kolab.org/about-kolab-server.html I don't mean any offense. I just want to know. Why do we need to create a project, which should normally be reserved for wide-sweeping changes or things that require massive amounts of coordination? Indeed. Having tried to use Kolab on Gentoo before, I assume it will be the latter that makes a Kolab project reasonable. Best regards, Wulf signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
Rémi Cardona wrote:
Donnie Berkholz wrote:
python_mod_optimize() {
local myroot
# strip trailing slash
myroot=${ROOT%/}
...
ebegin Byte compiling python modules for python-${PYVER} ..
python${PYVER} ${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py
${c$
python${PYVER} -O
${myroot}/usr/$(get_libdir)/python${PYVER}/compileall.py $
eend $?
}
Could the python eclass have a function (or whatever as I'm no bash
guru) that returns this :
${ROOT}/usr/$(get_libdir)/python${PYVER}/
We use it over and over in all our ebuilds, and it's error-prone as my
last few commits have shown.
Why not just leave the path off altogether then? That should default to
${ROOT}/usr/$(get_libdir)/python[0-9].[0-9]* IIRC.
--
fonts / wxWindows / gcc-porting / treecleaners
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
Ryan Hill wrote:
Why not just leave the path off altogether then? That should default to
${ROOT}/usr/$(get_libdir)/python[0-9].[0-9]* IIRC.
We (gnome herd, possibly others) still need to append
/site-packages/gtk-2.0 to that path for most of our operations. So if we
could write :
python_mod_optimize $(python_lib_dir)site-packages/gtk-2.0
or even :
python_mod_optimize $(python_site_packges)gtk-2.0
that would be fantastic :)
Could that function benefit other ebuilds than ours?
Cheers,
Rémi
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
On 13:25 Fri 12 Oct , Remi Cardona (remi) wrote:
1.1
dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1content-type=text/plain
pkg_postinst() {
python_version
python_mod_optimize
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
pkg_postrm() {
python_version
python_mod_cleanup
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
While you guys are on this subject, I thought I would put in the
experience I just had.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-java/java-config/java-config-2.1.2.ebuild?rev=1.1view=markup
As you will note in the ebuild above I inherit distutils and then
declare
PYTHON_MODNAME=java_config_2
and have my 2 functions as so
pkg_postrm() {
distutils_python_version
distutils_pkg_postrm
}
pkg_postinst() {
distutils_pkg_postinst
...
...
}
Firstly it is interesting to note that you must call *python_version
before distutils_pkg_postrm while distutils_pkg_postinst handles this
itself.
Is this a good solution? Would it also be a good solution in your case?
PYTHON_MODNAME from my understanding what i've investigated will accept
a list of modules if you need it to.
Anyway, hopefully this helps.
Alistair.
ps. My python experience has not left the realm of java-config and I
have only done 2 releases, 1 1/2 of which I completely screwed up. I am
no expert and have no idea whether the above is correct, valid or
otherwise safe for human consumption. Don't complain!!
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: new old eclass - wxwidgets.eclass
Ryan Hill wrote: since everyone is getting into the reviewing mood, i thought it would be a good time to get some opinions on the wxwidgets eclass rewrite i've done. Committed. If anyone has any problems please let me know. -- fonts / wxWindows / gcc-porting / treecleaners EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Donnie Berkholz wrote:
On 18:55 Fri 12 Oct , Doug Goldstein (cardoe) wrote:
1.1 media-tv/mythtv/mythtv-0.20.2_p14668.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1content-type=text/plain
use alsa || myconf=${myconf} --disable-audio-alsa
use jack || myconf=${myconf} --disable-audio-jack
use dts || myconf=${myconf} --disable-dts
use freebox || myconf=${myconf} --disable-freebox
use dbox2 || myconf=${myconf} --disable-dbox2
use hdhomerun || myconf=${myconf} --disable-hdhomerun
use crciprec || myconf=${myconf} --disable-crciprec
use altivec || myconf=${myconf} --disable-altivec
use xvmc myconf=${myconf} --enable-xvmc
use xvmc use video_cards_via myconf=${myconf} --enable-xvmc-pro
use perl myconf=${myconf} --with-bindings=perl
myconf=${myconf}
--disable-audio-arts
$(use_enable lirc)
$(use_enable joystick joystick-menu)
$(use_enable dvb)
--dvb-path=/usr/include
$(use_enable opengl opengl-vsync)
$(use_enable ieee1394 firewire)
--enable-xrandr
--enable-xv
--disable-directfb
--enable-x11
--enable-proc-opt
How come some of these don't use use_enable()?
Because if you pass the inverse the script blows up. It's ffmpeg's
configure script that's a hand written script and modified by the MythTV
developers.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
On 00:12 Sun 14 Oct , Doug Goldstein wrote: Because if you pass the inverse the script blows up. It's ffmpeg's configure script that's a hand written script and modified by the MythTV developers. Sigh. Any chance of getting things to move to autotools? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
