-) Current stable does not build (bug #273616) -) Seems to have no serious issues. -) In tree long enough. Thanks. Reproducible: Always
How about, we wait for another month? Prelude 1.0.0 is now in the tree and solves a lot of the QA issues we've seen mount up.
Maintainer timeout. CCing arches. Please carefully test app-admin/prelude-manager-1.0.0
Changed summary. the exact version is 1.0.0-r1 (1.0.0 is dead on cvs)
I notice that there are available versions 1.0.0 of: dev-libs/libprelude dev-libs/libpreludedb How do you want to proceed?
They have to be included, of course.
Not run for me: ( What am I doing wrong? ) archtester ago # prelude-manager 09 Nov 21:21:03 (process:32157) INFO: Subscribing Normalize to active decoding plugins. 09 Nov 21:21:03 (process:32157) WARNING: prelude-client: error initializing prelude-client: profile 'prelude-manager' does not exist Profile 'prelude-manager' does not exist. In order to create it, please run: prelude-admin add "prelude-manager" --uid 0 --gid 0. archtester ago # prelude-admin add prelude-manager --uid 0 --gid 0 error creating directory /etc/prelude/profile//prelude-manager: No such file or directory. error creating directory /etc/prelude/profile//prelude-manager: No such file or directory. Could not find profile 'prelude-manager'.
This is the list I am planning for x86 after some issues have been resolved. =app-admin/prelude-lml-1.0.0 =app-admin/prelude-manager-1.0.0-r1 =dev-libs/libprelude-1.0.0-r1 =dev-libs/libpreludedb-1.0.0-r1
This seems to be a little stuck. Current prelude has serious problems, but the ~version is also not good. I think we should not stick with a non working version in our stable tree. We have two options: -) drop stable keywords of prelude (I would go for this!) -) stable newer version despite problems (at least it does build so it could be useful for some users) And of course there is -) fix ~arch version But it seems that everybody is overworked anyway. Comments?
(In reply to comment #8) > This seems to be a little stuck. Current prelude has serious problems, but the > ~version is also not good. I think we should not stick with a non working > version in our stable tree. We have two options: > > -) drop stable keywords of prelude (I would go for this!) > -) stable newer version despite problems (at least it does build so it could be > useful for some users) > > And of course there is > -) fix ~arch version > But it seems that everybody is overworked anyway. > > Comments? > Looking at the bugs that block this one, one seems to be specific for x86_64 (missing dep?), one has already some sort of patch attached to it and one has an USE flag that should not be in there (or calls the wrong configure option). Of course I haven't looked into it in detail, but these things seem fairly easy to fix. How about flagging them for bugday?
(In reply to comment #9) > Looking at the bugs that block this one, one seems to be specific for x86_64 > (missing dep?), one has already some sort of patch attached to it and one has > an USE flag that should not be in there (or calls the wrong configure option). > Of course I haven't looked into it in detail, but these things seem fairly easy > to fix. How about flagging them for bugday? > Fixed 2 bugs, but saw during fixing, that these packages have a lot more issues and are not up to quality. Just posted a new bug, have 2 more bugs in the pipe-line (one will be posted later, one has to go upstream (who doesn't seem to be that active)). Maybe dropping stable is not such bad idea after all.
Ok, there seems to be a too long way to go for us as an arch team. x86 dropped stable keywords on older prelude packges (non-building with many problems...) @netmon: Please consider us for stable on a later version when things are in good shape again. Thanks for flying x86.
amd64 will pass. Too many blockers. CC us when you fix your package
~alpha/~arm/~ia64/~sparc keywords dropped
ppc keywords dropped
Prelude was removed from tree
