Fluidportage ebuilds for CVS/SVN programs

Message

Redeeman · Post by **Redeeman** » Sat Aug 21, 2004 1:13 pm

bmg ebuilds are strange for hal and dbus, please give me the errors you get, so i can fix them ;P

gungholady · Post by **gungholady** » Sun Aug 22, 2004 9:23 am

The bmg ebuilds for hal-cvs and ivman-cvs may be strange to you but they work. The error message was something about --debug. I could not find it in any of the ebuilds that you had for hal-cvs or ivman-cvs so I just had to delete them. This morning portage says that the ebuilds for xmms-cvs and kahakai-cvs have problems with the --debug issue and they failed the cache part. Since I'm not using them they didn't cause any problems in doing "emerge -uDa world" Plus when doing the "emerge sync," I got a lot of messages during the cache part about "grep: -P is not supported." I don't have a clue as to what ebuilds are causing that. I did not get all those messages until I did "svn up" so the errors have to be in your ebuilds somewhere.

Redeeman · Post by **Redeeman** » Sun Aug 22, 2004 9:30 am

no, seriously, its not because they appear strange, their configure options are directly wrong in some terms, i had alot trouble finding out whats wrong when i used them....

will_in_wi · Post by **will_in_wi** » Sun Aug 22, 2004 2:27 pm

this is really cool. I am pretty good at creating the simpler live cvs ebuilds, if I were to create ebuilds from the todo list where should I send them?

Redeeman · Post by **Redeeman** » Sun Aug 22, 2004 4:21 pm

redeeman@ <blblabla>gmail.com

gungholady · Post by **gungholady** » Mon Aug 23, 2004 10:23 am

Redeeman wrote:no, seriously, its not because they appear strange, their configure options are directly wrong in some terms, i had alot trouble finding out whats wrong when i used them....

Like I said, at least theirs work and I don't get all the portage error messages from their ebuilds like I do with yours. The portage error messages went away when I removed /usr/local/fluidportage/trunk from the /etc/make.conf file.

BNoise · Post by **BNoise** » Tue Aug 24, 2004 12:55 am

Code: Select all

athas local # svn co http://kaspersandberg.com/fluidportage/trunk
svn: REPORT request failed on '/fluidportage/!svn/vcc/default'
svn: REPORT of '/fluidportage/!svn/vcc/default': 400 Bad Request (http://kaspersandberg.com)

This keeps preventing me from checkout the tree, anyone has a clue?

Fanatic · Post by **Fanatic** » Tue Aug 24, 2004 6:25 pm

Redeeman wrote: Like I said, at least theirs work and I don't get all the portage error messages from their ebuilds like I do with yours. The portage error messages went away when I removed /usr/local/fluidportage/trunk from the /etc/make.conf file.

Yeah, I got quite a few error messages since I added /trunk to my make.conf file. And it takes something like three times as long to do a emerge -uDpv world than it used to.

sn4ip3r · Post by **sn4ip3r** » Tue Aug 24, 2004 8:29 pm

Fanatic wrote:...
Yeah, I got quite a few error messages since I added /trunk to my make.conf file. And it takes something like three times as long to do a emerge -uDpv world than it used to.

Could you post the errors here or directly to me?

Fanatic · Post by **Fanatic** » Tue Aug 24, 2004 9:12 pm

sn4ip3r wrote:
Could you post the errors here or directly to me?

These are the error messages i got during when I synced:

Code: Select all

grep: The -P option is not supported
grep: The -P option is not supported                                          
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707       has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612        grep: The -P option is not supported

Post by **pjp** » Tue Aug 24, 2004 9:44 pm

Moved from Documentation, Tips & Tricks.

sn4ip3r · Post by **sn4ip3r** » Tue Aug 24, 2004 10:06 pm

Fanatic wrote:

sn4ip3r wrote:
Could you post the errors here or directly to me?

These are the error messages i got during when I synced:

Code: Select all

grep: The -P option is not supported
grep: The -P option is not supported                                          
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707       has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612        grep: The -P option is not supported

When did you last "cd /usr/local/fluidportage/trunk && svn up" ? I know where those -P options were but they have already been removed and should not be a problem anymore. (btw. -P only exists in grep if it's compiled with the "pcre" use flag)

Fanatic · Post by **Fanatic** » Wed Aug 25, 2004 7:34 pm

Yeah i synced the /trunk folder and now i don't get the-P error messages anymore but I still get:

>>> Updating Portage cache...
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612 ...done!

And it still takes a long time to do a emerge -uDpv world.

sn4ip3r · Post by **sn4ip3r** » Wed Aug 25, 2004 9:27 pm

Fanatic wrote:Yeah i synced the /trunk folder and now i don't get the-P error messages anymore but I still get:

>>> Updating Portage cache...
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-cairo-cvs-20040707
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612
has_version() in global scope: x11-themes/gtk-engines-xfce-cvs-20040612 ...done!

And it still takes a long time to do a emerge -uDpv world.

The "has_version" warning is from /usr/portage/eclass/gtk-engines2.eclass, and should not be a cause for any concern, just an annoyance which would probably affects all gtk-engines ebuilds which are in a separate overlay (not inside portage tree).
About the -uDpv slowness, I don't think there is much that can be done to improve it other than optimize portage or upgrade your hardware/kernel/whatever.

Luxus · Post by **Luxus** » Mon Sep 06, 2004 12:40 am

hey i had a problem with the firefox-cvs ebuild

Code: Select all

 # emerge mozilla-firefox-cvs   
Calculating dependencies ...done!
>>> emerge (1 of 1) net-www/mozilla-firefox-cvs-20040827 to /
>>> Unpacking source...
cvs [checkout aborted]: must specify at least one module or directory

!!! ERROR: net-www/mozilla-firefox-cvs-20040827 failed.
!!! Function fluidcvs_fetch, Line 251, Exitcode 1
!!! cvs checkout command " cvs -q -f -z4 -d ":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot" checkout  -d  mozilla" failed

sn4ip3r · Post by **sn4ip3r** » Mon Sep 06, 2004 9:08 am

Luxus wrote:hey i had a problem with the firefox-cvs ebuild

Code: Select all

 # emerge mozilla-firefox-cvs   
Calculating dependencies ...done!
>>> emerge (1 of 1) net-www/mozilla-firefox-cvs-20040827 to /
>>> Unpacking source...
cvs [checkout aborted]: must specify at least one module or directory

!!! ERROR: net-www/mozilla-firefox-cvs-20040827 failed.
!!! Function fluidcvs_fetch, Line 251, Exitcode 1
!!! cvs checkout command " cvs -q -f -z4 -d ":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot" checkout  -d  mozilla" failed

Unfortunately this is not the only problem with firefox-cvs, I seem to be unable to even get it running (seems to be a similiar problem that the stable version had recently, about needing firefox first to be run as root because it needed to write to the directory where it was installed to, but this time even root will not work, it still reports a permission problem...). Sorry, that I commited this ebuild without making it fully usable first (btw. you are welcome to try to fix it

)

Luxus · Post by **Luxus** » Mon Sep 06, 2004 9:59 am

shit ;/ and i not have the time to play around with the ebuild...
nobody here with a working firefox-cvs ebuild?

robmoss · Post by **robmoss** » Mon Sep 06, 2004 7:56 pm

sn4ip3r wrote:The "has_version" warning is from /usr/portage/eclass/gtk-engines2.eclass, and should not be a cause for any concern, just an annoyance which would probably affects all gtk-engines ebuilds which are in a separate overlay (not inside portage tree).
About the -uDpv slowness, I don't think there is much that can be done to improve it other than optimize portage or upgrade your hardware/kernel/whatever.

Not a cause for any concern? I think you mean... BAD! BAD BAD BAD! It affects all gtk-engines-related ebuilds, regardless of where they're stored; it will pull in imlib1 and gtk1 as dependencies regardless of whether you need them or not. It's broken, and needs fixing. If anyone can come up with a brilliant solution there's large parts of the dev community that would be VERY grateful.

sn4ip3r · Post by **sn4ip3r** » Mon Sep 06, 2004 9:18 pm

[oops, doublepost]

sn4ip3r · Post by **sn4ip3r** » Mon Sep 06, 2004 9:26 pm

robmoss wrote:
sn4ip3r wrote:The "has_version" warning is from /usr/portage/eclass/gtk-engines2.eclass, and should not be a cause for any concern, just an annoyance which would probably affects all gtk-engines ebuilds which are in a separate overlay (not inside portage tree).
About the -uDpv slowness, I don't think there is much that can be done to improve it other than optimize portage or upgrade your hardware/kernel/whatever.
Not a cause for any concern? I think you mean... BAD! BAD BAD BAD! It affects all gtk-engines-related ebuilds, regardless of where they're stored; it will pull in imlib1 and gtk1 as dependencies regardless of whether you need them or not. It's broken, and needs fixing. If anyone can come up with a brilliant solution there's large parts of the dev community that would be VERY grateful.

I can't think of a clean solution right now, but for my cvs gtk-engines (cairo, xfce, gnome-themes, gnome-themes-extra) I've already made a smaller version of the gtk-engines2 eclass which has no gtk1 references. Ofcourse this solution is unique to cvs ebuilds because there is no need to make a cvs ebuild for a gtk1 engine.

btw. robmoss, any progress with grub/grub2(-cvs) ebuilds?

gurg4035 · Post by **gurg4035** » Tue Sep 14, 2004 7:08 am

when i run svn i get the error shown below:

Code: Select all

root icepc # svn co http://kaspersandberg.com/fluidportage/trunk 
svn: REPORT request failed on '/fluidportage/!svn/vcc/default' 
svn: REPORT of '/fluidportage/!svn/vcc/default': 400 Bad Request

i should note that when I use the windows version of SVN (TortoiseSVN), the repository check out fine, but on linux, i get the above error.

Any1 knows what is causing this error? I tried searching on google about this error but couldn't find anything :-/

George

btw: hi every1

eGore911 · Post by **eGore911** » Wed Sep 22, 2004 8:08 am

Would it be possbile to rename the kde-base/* ebuilds to kde-base/*-cvs? I like the names like that (and all the xfce cvs stuff is named xfce-{base,extra}/*-cvs , too) and like to have kde installed, but don't want cvs versions of it.

sn4ip3r · Post by **sn4ip3r** » Wed Sep 22, 2004 10:58 am

eGore911 wrote:Would it be possbile to rename the kde-base/* ebuilds to kde-base/*-cvs? I like the names like that (and all the xfce cvs stuff is named xfce-{base,extra}/*-cvs , too) and like to have kde installed, but don't want cvs versions of it.

kde ebuilds are special, they have their own cvs eclass which means that it can´t be easily renamed.

Fanatic · Post by **Fanatic** » Wed Sep 22, 2004 11:46 pm

sn4ip3r wrote: About the -uDpv slowness, I don't think there is much that can be done to improve it other than optimize portage or upgrade your hardware/kernel/whatever.

Well an upgrade to portage 2.0.51 solved the slowness problem, but you might want to update the fluidmanager.sh script:

Code: Select all

root@wanker trunk # scripts/fluidmanager.sh --pkgs-upgrade
scripts/fluidmanager.sh: line 1: genlop: command not found
 * Detected an updated CVS for net-p2p/valknut-cvs-20040916
 * PACKAGE: net-p2p/valknut-cvs-20040916 has been updated since "2004-09-23 00:00"
!!! Warning: emerge /path/to/ebuild is broken and considered dangerous.
!!! Don't use it. I'm serious, we're coming after you if you use it.

>>> Waiting 10 seconds before starting...
>>> (Control-C to abort)...
Continuing with emerge /path/to/ebuild in: 10 9 8 7 6 5 ...

scoobydu · Post by **scoobydu** » Sun Oct 03, 2004 5:10 pm

waimea-cvs on amd64 needs the 64bit patch applied, else it won't work.

Changed this;

useq genpatches && {
64-bit && epatch ${FILESDIR}/waimea-0.5.0-64bit-clean.patch
ereport 0 'redeeman does this still work? is it needed, or?'
}

for this;

use amd64 && epatch ${FILESDIR}/waimea-0.5.0-64bit-clean.patch

and everthing works fine.