
alinv wrote:Does anybody know how the 'Switch user' feature is supposed to work now? Some time ago, there was a $KDE_HOME/share/config/kdm/Xservers file, which now seems to be gone. Even if I put it back, kdm won't let me have more than one user logged in.

Thanks,mario.mario wrote:3Debentoo_Gao wrote:the QT-COPY version is 3 or 4 ?
Code: Select all
A KDE/kdelibs/dnssd/domainbrowser.cpp
A KDE/kdelibs/dnssd/remoteservice.cpp
A KDE/kdelibs/dnssd/README
A KDE/kdelibs/dnssd/sdevent.h
A KDE/kdelibs/dnssd/domainbrowser.h
A KDE/kdelibs/dnssd/remoteservice.h
A KDE/kdelibs/dnssd/INSTALL
A KDE/kdelibs/dnssd/configure.in.bot
A KDE/kdelibs/dnssd/Makefile.am
A KDE/kdelibs/dnssd/servicebase.cpp
A KDE/kdelibs/dnssd/settings.kcfgc
A KDE/kdelibs/COPYING.LIB
Fetching external item into 'KDE/kdelibs/admin'
* Failed in /usr/portage/distfiles/svn-src/kde/trunk during "svn --non-interactive update KDE/kdelibs"
!!! ERROR: kde-base/kdelibs-7 failed.
!!! Function subversion_handle_error, Line 137, Exitcode 0
!!! svn: PROPFIND request failed on '/home/kde/trunk/KDE/kde-common/admin'
!!! If you need support, post the topmost build error, NOT this status message.

getting this to work takes time, many re-tries and patienceDebentoo_Gao wrote:Thanks,mario.mario wrote:3Debentoo_Gao wrote:the QT-COPY version is 3 or 4 ?But I got an error when I emerge kdelibs-7
Code: Select all
A KDE/kdelibs/dnssd/domainbrowser.cpp A KDE/kdelibs/dnssd/remoteservice.cpp A KDE/kdelibs/dnssd/README A KDE/kdelibs/dnssd/sdevent.h A KDE/kdelibs/dnssd/domainbrowser.h A KDE/kdelibs/dnssd/remoteservice.h A KDE/kdelibs/dnssd/INSTALL A KDE/kdelibs/dnssd/configure.in.bot A KDE/kdelibs/dnssd/Makefile.am A KDE/kdelibs/dnssd/servicebase.cpp A KDE/kdelibs/dnssd/settings.kcfgc A KDE/kdelibs/COPYING.LIB Fetching external item into 'KDE/kdelibs/admin' * Failed in /usr/portage/distfiles/svn-src/kde/trunk during "svn --non-interactive update KDE/kdelibs" !!! ERROR: kde-base/kdelibs-7 failed. !!! Function subversion_handle_error, Line 137, Exitcode 0 !!! svn: PROPFIND request failed on '/home/kde/trunk/KDE/kde-common/admin' !!! If you need support, post the topmost build error, NOT this status message.
You shouldn't need to do that. Externals are disabled after at least a portion of the folder is created, so only 2 passes should suffice. If they don't, let me know, as there must be a bug in the code. I think the best solution would be to import keys, since the ebuilds are not supposed to be interactive to ask you to confirm certificates. I will look into key importation from the eclass.superstoned wrote: try again; try to go to the place it went wrong and do it by hand (all info is in the error: go to the /usr/portage/etc/trunk folder and type "svn --non-inblablabla" and see what happens. fix it, and try again


mario wrote:superstoned wrote:sorry 4 my poor english understanding. could u tell me the way 2 go on my emerge ?Debentoo_Gao wrote:You shouldn't need to do that. Externals are disabled after at least a portion of the folder is created, so only 2 passes should suffice. If they don't, let me know, as there must be a bug in the code. I think the best solution would be to import keys, since the ebuilds are not supposed to be interactive to ask you to confirm certificates. I will look into key importation from the eclass.mario wrote:3
getting this to work takes time, many re-tries and patience
try again; try to go to the place it went wrong and do it by hand (all info is in the error: go to the /usr/portage/etc/trunk folder and type "svn --non-inblablabla" and see what happens. fix it, and try again
Debentoo_Gao wrote:mario wrote:superstoned wrote:sorry 4 my poor english understanding. could u tell me the way 2 go on my emerge ?Debentoo_Gao wrote:You shouldn't need to do that. Externals are disabled after at least a portion of the folder is created, so only 2 passes should suffice. If they don't, let me know, as there must be a bug in the code. I think the best solution would be to import keys, since the ebuilds are not supposed to be interactive to ask you to confirm certificates. I will look into key importation from the eclass.mario wrote:3
getting this to work takes time, many re-tries and patience
try again; try to go to the place it went wrong and do it by hand (all info is in the error: go to the /usr/portage/etc/trunk folder and type "svn --non-inblablabla" and see what happens. fix it, and try again
this problem just wont go away.Making all in taskbar
make[3]: Entering directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker/taskbar'
/usr/kde/devel/bin/kconfig_compiler ./taskbar.kcfg ./taskbarsettings.kcfgc; ret=$?; \
if test "$ret" != 0; then rm -f taskbarsettings.h ; exit $ret ; fi
make[3]: *** No rule to make target `../libkicker/kickerSettings.h', needed by `libtaskbar_la.all_cpp.cpp'. Stop.
make[3]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker/taskbar'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase'
make: *** [all] Error 2
yagami wrote: the thing is that kcontrol/kicker needs ../kicker/libkicker compiled first to generate kickerSettings.h

why would one want monolithic ebuilds???mario wrote:If you want monolithic ebuilds, vote here:
https://developer.berlios.de/survey/sur ... rvey_id=97
its not that i think that monolithic ebuilds are better ... as long as we have -meta ebuilds , we are not missing on anything.If you want monolithic ebuilds, vote here:
Now, that I completed the transition?mario wrote:If you want monolithic ebuilds, vote here:
https://developer.berlios.de/survey/sur ... rvey_id=97
alinv wrote: My vote is no, but I wouldn't create an account on berlios.de for this. Wouldn't be a poll here a simpler way?
Fixed, gensync to updateyagami wrote: the thing is that kcontrol/kicker needs ../kicker/libkicker compiled first to generate kickerSettings.h

well, i'm running these ebuilds now, and i'm amazed how stable kde-svn is. and it's nice to see all these changesyagami wrote:its not that i think that monolithic ebuilds are better ... as long as we have -meta ebuilds , we are not missing on anything.If you want monolithic ebuilds, vote here:
the problem is that i dont think kde is ready for that ... everything is so tightly integrated , and arent supposed to be used seperatly , i think ( used = compiled)
this would be really nice , split ebuilds , if we could use all kde using branch 3.4 or 3.5 or whatever , and then that special app would be trunk or HEAD.
since i like to test and try kopete HEAD , i would love a kde svn branch 3.4 and kopete HEAD ( note that i dont want kde stable release.... really , having been on branch 3.4 since kde 3.4 was released .... to me branches are the best , always stable and the first to receive stable bug fixs )
so , is there any way we could use a svn branch ebuild ?!? and maybe combine branch with trunk ?? that would rock !
yagami wrote: so , is there any way we could use a svn branch ebuild ?!? and maybe combine branch with trunk ?? that would rock !

Debentoo_Gao wrote:mario wrote:Thanks, this morning I emerge it again,it works .so cool,mariosuperstoned wrote:sorry 4 my poor english understanding. could u tell me the way 2 go on my emerge ?Debentoo_Gao wrote:You shouldn't need to do that. Externals are disabled after at least a portion of the folder is created, so only 2 passes should suffice. If they don't, let me know, as there must be a bug in the code. I think the best solution would be to import keys, since the ebuilds are not supposed to be interactive to ask you to confirm certificates. I will look into key importation from the eclass.mario wrote:3
getting this to work takes time, many re-tries and patience
try again; try to go to the place it went wrong and do it by hand (all info is in the error: go to the /usr/portage/etc/trunk folder and type "svn --non-inblablabla" and see what happens. fix it, and try again

of coursemario wrote:Hello,
Is anybody here reading the Commit Digest?
i THINK i could figure out how to do it... let me think about it (have to work today, it's 5:38 in the morning, damn, not used to that - i usally get up at 9mario wrote:I wondered if I could ask you to create a list of changed packages when the digest comes out, if you read it. I would then bump all revisions and that would end up available to anyone to rsync. I am thinking of a way to automate that, but it won't happen very soon, so maybe the "once a week revision by looking at Commit Digest" will do fine for now.
Also, if anyone is following security announcement, we could do the same for those. I could even give you access to the repository so that you bump them (there's a utility called ebump, but simple copy/paste will also do).
Thanks,
Mario

Code: Select all
Making all in kicker
make[2]: Entering directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker'
Making all in taskbar
make[3]: Entering directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker/taskbar'
/usr/kde/devel/bin/kconfig_compiler ./taskbar.kcfg ./taskbarsettings.kcfgc; ret=$?; \
if test "$ret" != 0; then rm -f taskbarsettings.h ; exit $ret ; fi
make[3]: *** No rule to make target `../libkicker/kickerSettings.h', needed by `libtaskbar_la.all_cpp.cpp'. Stop.
make[3]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker/taskbar'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase/kicker'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/kcontrol-7/work/KDE/kdebase'
make: *** [all] Error 2
!!! ERROR: kde-base/kcontrol-7 failed.
!!! Function kde-meta_src_compile, Line 491, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.
See thisDebentoo_Gao wrote:I got this error just now
He's not kidding, it fixed the error heremario wrote:Fixed, gensync to updateyagami wrote: the thing is that kcontrol/kicker needs ../kicker/libkicker compiled first to generate kickerSettings.h