[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Kevin F. Quinn wrote:

  The expectation here is that when a new version of gcc is
  stabilized, that users will upgrade to that in a reasonable amount
  of time, and use that (by selecting it with gcc-config) for
  compiling all new updates.  FYI, gcc-3.4.4-r1 was stabilized on
  2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th.

 I don't see how that information is conveyed to the user.

It's conveyed by the fact that when updating, you see a new compiler
version being installed.  If you have done a world update, you
already have the later compilers installed.


No, that's not true.  It's not conveyed at all.
It might install a new GCC, but it doesn't switch to it.
It doesn't tell the user to switch to it, either.


As has been explained before, as far as the gcc ebuilds are
concerned their job is finished when the new compiler version
is installed.  It is up to the user to decide to change their
system compiler.


You seem to have missed the issue.


 Yes, ok.  That's a bad alternative.  Thus it seems that there's no
 appropriate mechanism to handle new GCC versions in Portage, which
 again makes sense wrt. the complaints.

Portage and the ebuilds handle it fine.


Same.


All that needs to happen is for users to accept the advice to read
the gcc upgrading guide when they trip over problems that arise
from issues with gcc versions.


There's no advice, instead Portage crashes during a system update.


 Nothing?
 I find it unacceptable that the bug is marked INVALID when it clearly
 describes a relevant issue.

Don't take the bug marking as a personal attack


I don't, it's not my bug ;-).


it's a marking for devs to understand what was the impact of the bug.


It's marked INVALID, while the issue is clearly valid.


Focus on the advice given, which from what I can see was succinct
and correct.


It shouldn't even be _necessary_ to create bugs and receive advice
from a living, breathing human being just to perform a system update.


 As far as I can tell, the complaints are about Portage being unable to
 handle GCC upgrades gracefully for end users.

What exactly do you expect to happen?  GCC updates don't switch major
versions automatically, because in general it means changing ABI which
means rebuilding everything.


Ah, that's a good question.

I think the proper reaction from Portage would be (both):
a) Alert the user that the newest version of package XYZ cannot be
   merged because it needs a newer compiler than the currently
   selected one.
b) Skip package XYZ, but continue updating the rest of the system.

Package XYZ could also block the update, that would be OK.


Again, this is not a personal attack but information for devs
to understand whether different work is needed for the different bugs.


Noone has mentioned personal attacks, so drop that train of thought.

You misread my point.  I was trying to say that bugs describing problems
(with fx. Portage) in abstract will often get closed as a duplicate of a
bug where someone has experienced a particular incarnation of the
larger problem described.

That's a good way to make sure that relevant end user issues never
come into contact with the devs, which I'm sure is not what the
devs want.


  I suppose portage could be enhanced to have a
  is_gcc_version_supported() check, but I'm not sure how useful that
  would be.

 If that would enable ebuild maintainers to flag xine as requiring 3.4
 for compilation, then that would definitely solve the issue described
 in the bug.  I'd say that's _very useful_ to the end user.

The problem with having the xine ebuild check gcc version and aborting
if a certain version is found active,


I don't think anyone would implement it that way, since that's braindead ;-).
Instead of checking a particular version, checking for a minimum
version would be the default available functionality.


is that if the gcc version is modified in the future such that xine would
then build with it, that handling would have to come out again.


In the (hysterically abstract) situation where someone revisits an old
version of GCC and adds GCC-4 features, nothing would break.

Users would still be told to upgrade to a newer version, and all would
be well, despite the fact that the old GCC with the backported feature
could now theoretically be used.

(But it's just trolling anyway, you're really describing a non-issue, IMHO.)


Another way of looking at it, is that there are a lot of people out
there who are coping just fine with GCC upgrades as they are currently
managed.


Uh.  What's your point?
That you're one of those people who hates change just because it's
change, or do you have something more relevant to say that I'm not
catching?


See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs
are concerned, The problem described is not a bug so INVALID is the
correct resolution marking.


Not a bug does not translate to Not an issue.
You're practicing an extremely narrow view of what's a bug, and 

[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Richard Fish wrote:

Having dozens (hundreds?  all?) ebuilds check for a minimum version


Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that version.  But yes,
a minimum version constraint could theoretically end up in a lot of
packages.


of gcc doesn't seem very effecient.


I can't see why it would not be efficient?


I don't think the issue is as simple as either having xine-lib put
out a warning about a particular gcc version, as that doesn't work
in the general case.


Obviously any solution implemented should work for all ebuilds, not
just xine-lib.


And putting the checks in portage doesn't seem to work very well
either.


I fail to see how a test in the ebuild for the active
GCC compiler version wouldn't work?


The system as it is now actually seems to work about right... the
vast majority of stable users upgrade to new versions of gcc as they
come out


Really?
How do you gather?
I'd think that most users hadn't even run into this problem (yet),
because many source code maintainers strive to be able to compile with
as old a version of GCC as possible..
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Jakub Moc wrote:

Sigh. Because it would break your system!

You really need to research better if you insist on beating a dead
horse over and over again. Kindly read the toolchain.eclass:


You're misreading me.

I was merely counter-arguing Kevin, who said that Portage provides
plenty of information to the end user about GCC switches being
necessary.

I was not trying to convince anyone to make Portage switch GCC
version automatically.  That would probably be rather insane.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Molle Bestefich wrote:

The current situation is very annoying for users that update often,
and also makes Portage mostly unusable for automatic server upgrades


After unmerging mono-tools so Portage could finally run a whole
update, it stopped halfway through because of this bug:
http://bugs.gentoo.org/show_bug.cgi?id=132122

I noticed that several users have commented with a relevant complaint:
GCC-4.x is required by the ebuild, but no information is ever conveyed
to the end user about this fact.  The ebuild does not have a
dependency on GCC-4.x.

Try reading the bug - users are basically being shoved off with an
arrogant silence and a stamp on their forehead saying INVALID.

Nothing personal against Jakub Moc who probably has a lot to do, but
the handling of relevant issues raised in the bugzilla is just
unacceptable.

What's the state of Portage and Gentoo in general?  Is there not
enough hands to do a proper job?  Or is it just that none of the devs
see what's wrong because bugs are wrongly being closed marked
INVALID such as the above when they're in fact not?
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] helping out - how?

2006-07-09 Thread Molle Bestefich

I'd like to take a stab at maintainership (or at least fixing) an
unmaintained ebuild.

What versioning system do you guys use (CVS?), and what's the URL for
checking out ebuilds?

(I was thinking that I'd conjure up a patch and submit it here so
someone with commit access can put it in.)
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Jakub Moc wrote:

 Try reading the bug - users are basically being shoved off with an
 arrogant silence and a stamp on their forehead saying INVALID.

 Nothing personal against Jakub Moc who probably has a lot to do, but
 the handling of relevant issues raised in the bugzilla is just
 unacceptable.

Dependency on a particular gcc version will solve exactly nothing.
Having that version installed doesn't mean you are really *using* it.
You won't be automagically switched to 3.4.x when upgrading from 3.3.x,
you won't be automatically switched to gcc 4.x when upgrading from 3.4.x


Yes ok.  So the user has to both merge the new version, and switch to it.

Either way, the end user is not getting told what should be done,
instead Portage just breaks, which is exactly what all the complaints
are about.


How about the you finally upgrade your outdated gcc, as asked over and
over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing
any bugs there. Hard to understand? Apparently, I guess...


I've never been told so, I have no clue what you are talking about.


Thanks for your rant.


What kind of reply do you expect to get from such crap?
Thanks for being an asshole?
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: helping out - how?

2006-07-09 Thread Molle Bestefich

Ioannis Aslanidis wrote:

You'd rather fill in a bug report and submit the patch in the bug.
Not in this list, definitely.


Oh, ok.  Never mind then, I fear I'd be spending way too much time
fighting with Jakub trying to get the ebuild in the tree.  I'll just
drop it.

(Nothing personal, I just don't think it would work out, heh.)
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Richard Fish wrote:

The expectation here is that when a new version of gcc is stabilized,
that users will upgrade to that in a reasonable amount of time, and
use that (by selecting it with gcc-config) for compiling all new
updates.  FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
current stable is 3.4.6-r1 since May 29th.


I don't see how that information is conveyed to the user.  Portage
shouts about upgrading to a new profile from time to time, but it
never tells anyone to upgrade GCC.  Perhaps it should, if that's what
the devs expect people to do.


The devs can *not* be expected to verify that all software in portage
builds with all versions of gcc in portage.


Of course not.


The alternative here is that old versions of gcc disappear from
portage, but that causes a problem for those who need those versions
for some reason, such as compiling non-gentoo software.


Yes, ok.  That's a bad alternative.  Thus it seems that there's no
appropriate mechanism to handle new GCC versions in Portage, which
again makes sense wrt. the complaints.


 Nothing personal against Jakub Moc who probably has a lot to do, but
 the handling of relevant issues raised in the bugzilla is just
 unacceptable.

What, exactly, do you find unacceptable in
Your gcc version is outdated and unsupported?


Nothing?
I find it unacceptable that the bug is marked INVALID when it clearly
describes a relevant issue.

As far as I can tell, the complaints are about Portage being unable to
handle GCC upgrades gracefully for end users.

You could perhaps argue that the issue started out as why do I get
this error message and ended up being why doesn't Portage handle GCC
upgrades gracefully, which is of course a slightly different thing.
But it should be clear to anyone reading the bug what the real issue
is.  I'm even willing to bet that if I create a new bug describing the
Portage issue, with no mention of the specific xine ebuild, it will
get closed as a duplicate of this bug anyway.  I've got case studies
proving that this is what happens, heh.


I suppose portage could be enhanced to have a is_gcc_version_supported()
check, but I'm not sure how useful that would be.


If that would enable ebuild maintainers to flag xine as requiring 3.4
for compilation, then that would definitely solve the issue described
in the bug.  I'd say that's _very useful_ to the end user.

You could argue that only a couple of people has spent the time to
create a bugzilla login and lodge a complaint in the bug, but there's
probably more out there.  We can count the duplicates in a couple of
months and see ;-).  And as newer GCC features are used throughout,
the situation will probably happen more in the future.


 What's the state of Portage and Gentoo in general?  Is there not
 enough hands to do a proper job?  Or is it just that none of the devs
 see what's wrong because bugs are wrongly being closed marked
 INVALID such as the above when they're in fact not?

If you want to test compiling every version of every package in
portage with all 21 versions (16 if you assume all -rX versions are
compatible, or /only 9/ if you only consider stable x86 versions) of
gcc that are currently in portage, and submit patches when things
fail, go ahead.


That won't be necessary.  Things mostly works, and when they don't,
users file a bug like the aforementioned one, which should result in
that particular ebuild getting fixed, instead of the bug being marked
INVALID.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: helping out - how?

2006-07-09 Thread Molle Bestefich

 What versioning system do you guys use (CVS?),
 and what's the URL for checking out ebuilds?

bugs.gentoo.org is where this kind of work is done.


There's already an existing but unmaintained ebuild.
That's what I wanted to check out, so I could modify it and submit a diff -u.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-08 Thread Molle Bestefich

Richard Fish writes:

Unfortunately the Gentoo dev's have taken the rather unusual
step of _breaking the tree_ due to a security problem.


Thanks for the info.

I would really wish that there was some mechanism in place to make
sure that the tree was never broken.

The current situation is very annoying for users that update often,
and also makes Portage mostly unusable for automatic server upgrades
:-(.


1. Unmerge both mono-tools and gecko-sharp.


That did the trick.
I'll have to remerge it later when/if the tree gets fixed...
Thanks!

(I see now that it was just me that didn't understand how to use
--tree, which makes much of this conversation off-topic... Sorry about
that!)


[1] http://bugs.gentoo.org/show_bug.cgi?id=137665


I'm thinking that a Subversion pre-commit hook to secure integrity of
the Portage tree would be cool.  The changes listed in the bug above
would have to be committed atomically, or it wouldn't get through the
integrity check.  Perhaps there could be a staging area in the form of
a branch where the hypothetical integrity checker wouldn't run.  Ho
hum, wishful thinking.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-07 Thread Molle Bestefich

Pierre Guinoiseau writes:

pam-login is now included in shadow, you no longer need to emerge it.


Thanks, that's what I needed to know.
I had done an emerge -D world, and suddenly I couldn't turn on the
PC.  I later found out that /sbin/login had been removed.

Richard Fish writes:

USE=mono emerge -Devp evolution

No mozilla comes in.
So evolution does not depend on mozilla, at least not directly.


Ok.  Same picture here.  (Above command pulls in 402 other packages
though... caramba)


In fact, in the current portage tree, mozilla is going away, and
being replaced by seamonkey.  Very few (and hard masked) packages
like gecko-sdk still depend on mozilla.  So what you should
eventually end up with is no mozilla but seamonkey.


Thanks for the info!


Are you using an portage overlay?  If so, what is in it?


No.  No idea what that is.  Sounds interesting, though.


When was the last time you did an emerge --sync?


Yesterday.  It changed things a bit since last time (month ago?), but
it still wants to merge mozilla.  Only now it's mono-tools (or rather
gecko-sharp) that wants it, Evolution is out of the picture:

[nomerge  ] dev-util/mono-tools-1.1.11
[ebuild  N]  dev-dotnet/gecko-sharp-0.6
[nomerge  ]   www-client/mozilla-1.7.13


Also, the full output of emerge -Duvpt world


Attached.

Note that I got rid of the Xorg-6.9 blockers by merging virtual/xft-7.0.
Doesn't make any sense to me at all, explanations sought for :-).

These are the packages that would be merged, in reverse order:

Calculating world dependencies  . . 
!!! Packages for the following atoms are either all
!!! masked or don't exist:
media-tv/atitvout

... done!
[blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B ] www-client/mozilla (is blocking www-client/seamonkey-1.0.2)
[ebuild U ] kde-base/kwalletmanager-3.5.3 [3.5.2] USE=xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 2,910 kB 
[ebuild U ] sys-fs/device-mapper-1.02.07 [1.02.02] 902 kB 
[ebuild U ] kde-base/kdebase-meta-3.5.3 [3.5.2] 0 kB 
[ebuild U ]  kde-base/konsole-3.5.3-r1 [3.5.2-r1] USE=xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 6 kB 
[ebuild U ]  kde-base/ksysguard-3.5.3-r1 [3.5.2-r2] USE=xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% -lm_sensors -zeroconf 0 kB 
[ebuild U ]  kde-base/knetattach-3.5.3 [3.5.1] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kdeprint-3.5.3 [3.5.2] USE=cups kde xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]   kde-base/kghostview-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 7,129 kB 
[ebuild U ]  kde-base/ktip-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kate-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kscreensaver-3.5.3 [3.5.1] USE=opengl xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kmenuedit-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kpager-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/drkonqi-3.5.3-r1 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kappfinder-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]  kde-base/kxkb-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 5 kB 
[ebuild U ]  kde-base/klipper-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[nomerge  ] app-cdr/k3b-0.12.14  USE=alsa encode ffmpeg flac kde mp3 
sndfile* vorbis xinerama -arts* -css -debug -dvdr -hal -musepack -musicbrainz 
-vcd 
[ebuild U ]  app-cdr/cdrdao-1.2.1-r1 [1.2.1] USE=encode gnome -debug 
-pccts 0 kB 
[nomerge  ]   dev-cpp/gtkmm-2.8.1  USE=-debug 
[ebuild U ]dev-cpp/glibmm-2.8.4 [2.8.1] USE=doc* -debug 1,977 kB 
[ebuild U ] kde-base/konq-plugins-3.5.3 [3.5.2-r1] USE=xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 1,607 kB 
[ebuild U ]  kde-base/konqueror-3.5.3 [3.5.2] USE=java xinerama -arts 
-debug -kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ]   kde-base/kfind-3.5.3 [3.5.2] USE=xinerama -arts -debug 
-kdeenablefinal -kdehiddenvisibility% 0 kB 
[ebuild U ] dev-libs/openobex-1.2-r1 [1.0.1] USE=bluetooth% -debug% -irda% 
-syslog% -usb% 333 kB 
[nomerge  ] media-video/konverter-0.92_beta1  USE=xinerama -arts* -debug 
[ebuild U ]  media-libs/xine-lib-1.1.2_pre20060328-r9 
[1.1.2_pre20060328-r1] USE=X aac alsa asf directfb esd* fbcon ffmpeg flac 
gnome ipv6 mad opengl oss sdl theora vorbis win32codecs xinerama xv -a52 -aalib 
-arts* -debug -dts -dvd -dxr3 

[gentoo-dev] Portage: missing pieces

2006-07-06 Thread Molle Bestefich

I think a piece might be missing from Portage.

I'll depict my workflow as an example.

I'm preparing to upgrade:
# emerge --sync
# emerge -Dp world
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXi-1.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXrandr-1.1.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/randrproto-1.1.2)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-misc/makedepend-1.0.0)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking media-libs/mesa-6.5-r3)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libdrm-2.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86vidmodeproto-2.2.2)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-proto/glproto-1.4.7)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86driproto-2.0.3)
... etc, lots of blockers ...

Ok, let's try and find why it wants to downgrade to xorg-x11-6.9:
# equery d xorg-x11-6.9
[ Searching for packages depending on xorg-x11-6.9... ]

none found
#

Ok, no reason, apparently.  Maybe it's already merged then?
# emerge -C xorg-x11-6.9
--- Couldn't find 'xorg-x11-6.9' to unmerge.

Nope.  Now I'm getting uncertain.  Don't I have xorg-x11 at all?
# emerge -C xorg-x11

x11-base/xorg-x11
   selected: 7.0-r1
  protected: none
omitted: none


'Selected' packages are slated for removal.
'Protected' and 'omitted' packages will not be removed.



Waiting 5 seconds before starting...
(Control-C to abort)...
Unmerging in: 5 4 3


CTRL-C
Exiting on signal 2

Whoops.  Yep, it's there.

Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
no packages actually wants xorg-x11-6.9, but whenever I use
emerge -D world, Portage sees it as a blocker anyway.

Is there a piece missing in this puzzle, in particular the one that
will tell me why on earth Portage thinks version 6.9 is a blocker?

Or is the piece in place but I'm not looking hard enough?
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-06 Thread Molle Bestefich

Molle Bestefich wrote:

I think a piece might be missing from Portage.

I'll depict my workflow as an example.


Same thing with a package called 'seamonkey':

# emerge -Dpt world
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[blocks B ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B ] =sys-apps/shadow-4.0.14-r2 (is blocking
sys-apps/pam-login-4.0.14)
[blocks B ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r2)
... etc ...

# emerge --unmerge seamonkey
--- Couldn't find 'seamonkey' to unmerge.

No packages selected for removal by unmerge.


# equery d seamonkey
[ Searching for packages depending on seamonkey... ]

#

Nobody wants a seamonkey, and I haven't got one already, but Portage
wants to smuggle one in anyway if I tell it to upgrade world.

Where's the piece that can tell me why Portage wants to do so?

(Alternatively, what's the manual process to find out?)
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-06 Thread Molle Bestefich

Dont snip.  The relevant part comes *after* the blocks lines.


Aah.  I get it.  Thanks.
Sorry for the noise.


 www-client/seamonkey (is blocking www-client/mozilla-1.7.13)

Also, you are mis-interpreting the blocks lines.  The correct
reading of X (is blocking Y) is that you have (or should have)
X installed, and now portage wants to install Y instead.
Usually this is because Y supercedes the functionality that used
to be provided by X, and  in almost all cases, the right thing
to do is to unmerge X and merge Y.


Evolution depends on Mozilla and Mono depends on SeaMonkey.  Mono is
the newer (actively developed... sort of) component, also, from what
I've heard, SeaMonkey is based on a vastly newer version of Gecko.  So
I'm not sure how that fits with the above.

Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine.
Doesn't help any with the blocker status, though.

So I'm stuck here.
Is it impossible to have Mono and Evolution installed at the same time?

(Same story with OpenSSH and pam-login.  OpenSSH wants shadow, and
pam-login refuses to merge alongside shadow.  I want both pam-login
and OpenSSH, but seems like I'll have to choose, right?)
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: backups: remove Portage cruft?

2006-06-13 Thread Molle Bestefich

[snip - Mike, Robin, Joerg, Alec and Marius were kind enough to answer my 
questions...]


Thanks guys!

That should shave a couple of hours off each nightly backup.. :-))
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Sharing portage?

2006-06-13 Thread Molle Bestefich

Hi

Follow-up question to the backup thingy.

Is there an easy way to share Portage's database between multiple
virtual machines?

Optimally, I would emerge --sync and the results would land in a
filesystem that I'd share between VMs, so I don't have to do emerge
--sync in each and all of them.  The filesystem could perhaps be
readonly to the virtual machines, except for the one doing the --sync
of course.

(Currently, I run emerge --sync in all virtual machines.)

Thanks!
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] backups: remove Portage cruft?

2006-06-12 Thread Molle Bestefich

Hi

Portage takes up a lot of space and time when doing server backups.

How much of Portage needs to be backup up?
Any large parts of the tree that I can just dump?

Thanks!

CC appreciated :).
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Gentoo: State of the Union

2006-05-07 Thread Molle Bestefich

 If you want central control of what's happening in the repository,
 Subversion seems like the way to go.

Better to fix the design of the repository, so that it can't be
broken in the first place, than to try putting band-aids in place
to cover the gaps.


Wow, way out of scope.
Sure, a Portage that's inherently unbreakable would be nice.
And infinitely more difficult to carry out than what I was proposing.

Also, the two (QA inline in commit process vs. Perfect Portage) does
not preclude each other.  While one may be better long term you
can still do the other to improve quality short term.

(Not that you would need to - if you had a QA step in the commit
process to make sure that ebuild dependencies were never broken,
why would you want to create a whole new Portage?

I was trying to say that a QA tool in form of a SVN pre-commit hook
seems like a perfect fit.  The entire infrastructure to run an
external application to check a commit before carrying it out,
approve the commit, send appropriate error messages back to the SCM
client and display them to the user etc. is already in place (and
has been for years) in the Subversion server and any of the client
tools.

The amount of work involved between inventing a couple of rules that
committed ebuilds must obey to actually implementing an enforcement
of said rules is _very_ overcomeable with SVN.

I wasn't even proposing that Gentoo actually needs a QA tool inline
in the process, just saying that it can easily be done [with SVN] :-).


PS. I resent calling it a band-aid.  It'd be a QA tool built on the
very well-thought-out foundation for quality assurance of commits that
SVN pre-commit hooks happens to be.

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Gentoo: State of the Union

2006-05-04 Thread Molle Bestefich

 Having a live tree requires people to be perfect.  People are not
 perfect and requiring it is ridiculous.  I love having commits in my
 local tree within the hour, but having a stable and unstable branch
 makes a lot of sense.

Does it?  How does having a stable and unstable branch differ from
having stable and unstable keywords?


Agreed.  That doesn't make sense.

Subversion has what is known as pre-commit hooks.
Using those it's very easy to:
* prevent (most or some) committers from designating ebuilds as stable
* allow committers to designate ebuilds as stable under a certain path only
* strictly limit a commiters access to a part of the tree

Slightly harder, but could be done too:
* deny commits if it breaks ebuild dependencies

If you want central control of what's happening in the repository,
Subversion seems like the way to go.


SVN requires at least 2x the tree size for storage on the local machine,


This is a feature, not a bug.
It allows you to keep operations local, fx. do a diff without being
online with the repository.


checkouts take something akin to an order of magnitude longer than CVS.


In the past Subversion performance was sub-par.  I haven't
systematically tested performance, but I would expect it to be much
better now.

Performance is gradually improved, see fx. r18867, r18944 and r19420:
http://svn.collab.net/viewvc/svn?view=revrevision=18867
http://svn.collab.net/viewvc/svn?view=revrevision=18944
http://svn.collab.net/viewvc/svn?view=revrevision=19420

GIT might perform better, since Linus specifically emphasized
non-O(n^2) performance in the design.  But being a decentralized tool,
I'm not sure how well it fits the needs here.


The former is annoying, but liveable, but
the latter is a deal-breaker.


I don't think so.  You really rarely do a complete checkout.


- No changeset/merge tracking


Solutions exist, including svnmerge and svk.
Official solution actively worked on at the moment, check out the
svn dev list.

A benefit of Subversion that I personally like is that FSFS
repositories are extremely easy to rsync.

--
gentoo-dev@gentoo.org mailing list