Curtis Napier wrote:
> Two names I see missing from this (otherwise very good) list are Chris
> Gianelloni (wolf31o2) and Donnie Berkholz (spyderous aka dberkholz). I
> think everyone knows exactly how much work these two put into Gentoo and
> how valuable that contribution is. The
Mike Frysinger wrote:
> can someone remind me why our arch USE flags are in an "opt-out" system
> rather
> than "opt-in" ? instead of adding things like:
> dmi
> icc
> mmx
> svga
> ...
>
> to every non-x86 profile, why dont we mask these things in base/use.mask and
> then un-mask them in defau
Enrico Weigelt wrote:
> Hi folks,
>
> maybe I've found a problem in the init.d stuff:
>
> It seems that /var/lib/init.d/started/* is blindly trusted,
> instead of actually checking if some service is running.
>
> For example, ntpd cannot be restarted via its init.d script
> if it died for some
Robin H. Johnson wrote:
> When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
> USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
> flags at all.
>
> Maybe a two-part solution is in order here then:
> 1. Change portage behavior regarding the
Robin H. Johnson wrote:
> If you have an ebuild with a non-standard pkg_nofetch, please ensure
> that you use $SRC_URI instead of $A!
>
> This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> download all of the source files for digesting or verification will hit
> pkg_nofetch
George Shapovalov wrote:
> The herd naming issue has surfaced in more detail again - there were already
> two comments that it is beneficial to keep -sci in herd names. I originally
> suggested that we drop it (and in general go with a "catchier" names), but
> now it looks like I am slowly turni
Luis Medinas wrote:
> There's a problem with this. A few packages i listed could be part of
> sci-crystallography too. If we start this new category we should had a
> few more related packages otherwise we will have this category empty.
> Another thing is who is really insterested in creating this
Ryan Hill wrote:
> Donnie Berkholz wrote:
>
>> My options are either missing important announcements or creating this
>> list. I would prefer the list.
>
> What important announcements are you expecting to find at the bottom 50-100
> posts of random relevance? The a
Thomas Cort wrote:
> On Fri, 30 Jun 2006 12:28:30 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> - I'm offering to stable any interested arch for 7.1. PPC, SPARC and
>> MIPS have already taken me up on this. I will be starting this very soon
>> (within 2
Wernfried Haas wrote:
> earlier today i updated my box (without reading the guide because i
> haven't gotten this mail yet), and apart from one problem because of
> not deleting some files as mentioned in the guide, all went fine.
> I also noticed (and someone correct me if i'm wrong here) the smar
Donnie Berkholz wrote:
> - If you stable your own arch, please also keyword xev and luit in
> addition to the various deps of virtual/x11, xorg-x11 and xorg-server.
One other thing I forgot to mention -- stable xproto 7.0.5, not 7.0.7.
stable: libX11 1.0.1 = xproto 7.0.5
~arch: libX11
Donnie Berkholz wrote:
> I encourage other architectures to stabilize modular X. AMD64, you will
> want to go with 7.0 because you also have binary drivers. All other
> archs will want to go with 7.1. The modular X package list [2] will help
> with this.
- I'm offering to stab
I've just spent the past few hours stabilizing modular X.Org 7.0 on x86.
This is a reminder of the migration guide [1] and a guide to other
arches on how to stabilize it. I have not stabilized most optional
packages, instead preferring to wait for any requests to see whether
demand exists for them.
Chris Gianelloni wrote:
> OK, guys, I was speaking with vapier earlier about the possibility of
> getting gcc 4.1.1 stable for the 2006.1 release. We've managed to build
> some release media with it, and are planning on doing more testing with
> it. What we really need is for more people to test
Stuart Herbert wrote:
> On 6/25/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> This topic has come up in the past, and I'd like to revive it once
>> again. The gentoo-dev list has gotten a lower and lower signal to noise
>> ratio over the past year or two, a
Chris Gianelloni wrote:
> - Create a new list ("gentoo-core-announce" ?)
> Reading: dev-only
> Posting: dev-only, reply-to set to gentoo-core
> This is the reference list of things (policy, decisions and discussions
> in progress) all developers must know about.
Agree with -(core|dev)-announce.
>
Lars Weiler wrote:
> Another upgrade for 2006.1 might be Xorg-7.1. ppc does not
> rely on any binary-driver which is affected by the
> ABI-change. This version of X has been tested by several
> developers and found to be stable. But we need to check
> Donnie's opinion about that move.
>
> A pro
Lars Weiler wrote:
> * Donnie Berkholz <[EMAIL PROTECTED]> [06/06/24 20:06 -0700]:
>> I propose that all need-to-know announcements and decisions be posted to
>> a separate, moderated (or restricted posting) gentoo-dev-announce list
>> to ensure that no developers lose t
Simon Stelling wrote:
> Right. So you agree with the intention, but not with the wording. This
> is exactly what I'm after. At least here in Europe, judges have to
> 'interprete' the law. They judge whether somebody is guilty or not based
> on the _intentions_ that are behind the law. If the law ha
Ned Ludd wrote:
> I would be in favor of a gentoo-dev-announce list if it allowed me
> to unsubscribe from this list.
Sure, if you want to just accept any decisions rather than participate
in making them. The -dev-announce list should be for finalized
decisions. It should be too late to dispute
Lance Albertson wrote:
> Outside if this being more centered around dev-only announcements, could
> the current -announce list suffice? I'd hate to need to subscribe to
> yet-another-announcement-list (or make our developers/users). Our
> -announce list certainly has the historical presence where t
This topic has come up in the past, and I'd like to revive it once
again. The gentoo-dev list has gotten a lower and lower signal to noise
ratio over the past year or two, and it's difficult to dig out the stuff
that's truly required reading.
I propose that all need-to-know announcements and decis
Luca Barbato wrote:
> Edward Catmur wrote:
> Critic 4
>> * Conflicts between contributors (social): Alice adds an ebuild; Bob
>> makes a (maybe "obvious") change; Alice thinks the change is incorrect,
>> and, feeling that the ebuild is her property, reverts the change. A
>> revert war erupts. Many
Alec Warner wrote:
> I believe that jakub finds this devrel decision a step out of bounds
> (not sure if anyone else detected the that in his statement) and saying
> that to the java folks is moreso a way of pointing out just how silly it
> is :) I mean if he was serious, he would have addressed t
Joshua Nichols wrote:
> Umm maybe it's just to early in the morning, but I don't see
> anything in the logs regarding using bugzilla for overlays not on
> overlays.gentoo.org. I only see references to sunrise specifically, not
> a blanket statement for all non-overlays.gentoo.org overlays
>
>
Mike Doty wrote:
> It is devrels place to attempt to stop the fighting. This is what I
> did. I clearly indicate that this is temporary and when the council is
> willing to clear this nonsense up, it will supersede anything I put
> forth yesterday.
I agree that it is devrel's place to help peopl
Mike Doty wrote:
> All-
>
> We've had a discussion about sunrise and have reached a compromise.
> Someone will summarize it later, I've attached the raw logs for now.
> Until the council makes a firm decision about non-gentoo hosted
> overlays, this will be the defining method of dealing with them
Mike Frysinger wrote:
> On Thursday 22 June 2006 00:54, Alec Warner wrote:
>> Specifically net-misc/vnc
>
> i'll fix this up if no one else does since it is a pretty friggin critical
> package for too many people (myself included), but i'd really really prefer
> someone else to do it
Not really
Stefan Schweizer wrote:
> Why you ask? Because a user does not care if packageX uses qt3 or qt4, he
> just wants to use it.
>
> But why do we have two useflags then?
> Because the user should be able to disable optional support for either qt3
> or qt4 or both for every package.
There's a signific
Kevin F. Quinn wrote:
>> The goal is to avoid a double-flag combo to do a single thing. "qt"
>> always and only affects the _best_ available qt interface for that
>> package. "qt#" affects only _older_ available qt interfaces for that
>> package.
>
> OK; so with this we're not providing a way to g
George Shapovalov wrote:
> середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали:
>> On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
>>> OK, so we can add qt3 to make.defaults.
>> -* says nothing to you? :)
> Now I am confused:
> My
Kevin F. Quinn wrote:
> On Tue, 20 Jun 2006 16:14:08 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>
>> Mike Owen wrote:
>>> From this user's perspective, simple is better. qt3 and qt4 as use
>>> flags are completely and utterly obvious as to w
Diego 'Flameeyes' Pettenò wrote:
> On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
>> OK, so we can add qt3 to make.defaults.
> Firulì Firulà (sounds of whistling in Italy at least)
>
> -* says nothing to you? :)
Sure it does, but -* has always been unsupporte
Diego 'Flameeyes' Pettenò wrote:
> I am talking about qt. Maybe I wasn't clear enough, I was thinking of KDE
> users, that are, casually, the main users of Qt-related stuff.
>
> In this particular issue, KDE (3) users are the main part, they need poppler
> and other stuff built for Qt 3. There a
Diego 'Flameeyes' Pettenò wrote:
> On Wednesday 21 June 2006 02:12, Donnie Berkholz wrote:
>> I disagree with this and agree with Caleb's earlier suggestion.
>> Presumably he has some clue what he's talking about when it comes to qt.
> I suppose he has, that
Diego 'Flameeyes' Pettenò wrote:
> On Wednesday 21 June 2006 00:52, Donnie Berkholz wrote:
>> Yes, you will need to introduce a qt4 flag as upstreams
>> port packages to qt5, if they choose to also retain a qt4 frontend.
> You're trying to compare gtk to qt direc
Mike Owen wrote:
> From this user's perspective, simple is better. qt3 and qt4 as use
> flags are completely and utterly obvious as to what they mean, and
> there is no confusion about them. Adding a plain qt flag in there
> brings back the gtk/gtk2 mess that we've presumably been trying to
> avoid
Kevin F. Quinn wrote:
> Problems with having 'qt' to mean latest and 'qt3' as specifically
> version 3 include:
>
> 1) Target package depends on build system (assuming 'qt' is interpreted
> as 'qt3' if only that is installed, rather than pulling in qt4 if not
> already present).
What? There will
Henrik Brix Andersen wrote:
> On Tue, Jun 20, 2006 at 03:11:38PM -0400, Caleb Tennis wrote:
>> I would personally like to stay with just the "qt" use flag. The use flag
>> will be for support of whichever version of Qt is supported (v3 or v4) for
>> the particular emerge.
>
> I would like a singl
Caleb Tennis wrote:
>> Currently we are at 4), should we change anything?
>
> My proposal:
>
> I would personally like to stay with just the "qt" use flag. The use flag
> will be for support of whichever version of Qt is supported (v3 or v4) for
> the particular emerge.
>
> In the cases where m
Josh Saddler wrote:
> With all the talk about forums and comments, that got me thinking: Heck, why
> not
> just have it posted to the forums? That way it and the comments can be viewed
> by
> the general public, but if you want to comment, you can just use your existing
> forum account. No additi
Donnie Berkholz wrote:
> Last year right after LWE August, Corey set up a 1-day Gentoo developer
> conference. Is anyone who's attending LWE going to pick up the ball, now
> that he's gone?
>
> Much of the information is supposedly on the devwiki [1], but it's
&g
Thomas Cort wrote:
> What is the proper quoting style for using epatch? In the tree there
> are about 3 different styles...
>
> epatch ${FILESDIR}/some-fix.patch # used by 7326 ebuilds
> epatch "${FILESDIR}"/some-fix.patch# used by 3092 ebuilds
> epatch "${FILESDIR}/some
Dan Meltzer wrote:
> According to the devmanual [1]
> "A herd is a collection of developers who maintain a collection of
> related packages"
>
> are you sure you are using the correct term?
>
> [1]
> http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
I guess it needs to g
Henrik Brix Andersen wrote:
> As I've said all along - I do not have any problems with Project
> Sunrise. I have a problem with it being an official project hosted on
> *.gentoo.org, as I fear most users will think "hey, it's official,
> it's hosted on *.gentoo.org - it can't be that bad". Judging
Last year right after LWE August, Corey set up a 1-day Gentoo developer
conference. Is anyone who's attending LWE going to pick up the ball, now
that he's gone?
Much of the information is supposedly on the devwiki [1], but it's
somewhat broken right now. The infra folks are working on fixing that
Henrik Brix Andersen wrote:
> On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
>> To take an example, there were made up quotes in my GWN interview,
>> however, nothing of great harm. I believe that time it was a case of
>> attempting to make it more fun, it is however a worryin
Henrik Brix Andersen wrote:
> While I do think this proposal is much better than the previous
> non-existing proposal, it still doesn't address the problem of having
> the sunrise overlay hosted on a non *.gentoo.org address to make it
> 100% clear to the public that it is unsupported.
It's no mor
Jakub Moc wrote:
> Donnie, pingy! ;) Just a friendly reminder to run the script again, so
> that we can do a last attempt on fixing the remaining stuff before
> resorting to more drastic solutions...
Yeah, it's on my list, but I've got family here all weekend so no time
to work on stuff.
Thanks,
Chris Gianelloni wrote:
> Since when was overlays.gentoo.org supposed to even be a service to our
> users? As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.
Our users are our biggest base of testers,
Chris Gianelloni wrote:
> Initially, yes. What happens once the user gets complete access to the
> repository, though? Are we going to be keeping people from adding
> packages without bugs?
Absolutely. This is for maintainer-wanted stuff, so it should be
documented in Bugzilla and assigned to ma
Chris Gianelloni wrote:
> Not policy (I don't think) but current accepted practice.
>
> Should this become a policy?
I'd say so, since this discussion regularly comes up again, and how we
do it is really an expression of the Gentoo philosophy and our
differences from a typical binary distribution
Chris Gianelloni wrote:
> The truth is that we don't ever want to become like the binary
> distributions. We don't want to have to have separate
> client/server/common/devel as it removes many of the advantages that
> Gentoo has. The default should *always* be to install the package as it
> was i
Chris Gianelloni wrote:
>> With an overlay: search sunrice.gentoo.org for the package (no, I don't
>> know category/name), sync that directory (no, I'm not syncing the whole
>> sunrice tree), check it over, note some mistakes, compile it if I feel
>> OK with it, it fails, I fix it - and what then?
Chris Gianelloni wrote:
> No, but the ebuilds are also checked by the team in question, that
> actually knows the packages, versus a couple of developers that will be
> overworked, dealing with packages that they are completely unfamiliar
> with and have no experience with. I just don't see the tw
Donnie Berkholz wrote:
> This aliases g77 to gfortran and gfortran to g77. They are entirely
> different compilers and do not accept all the same options. This is
> incredibly broken behavior, it masks issues in a number of packages and
> creates new issues in many others. Please fix
Jeremy Huddleston wrote:
> I finally had a few free cycles, so I fixed up the eselect-compiler
> ebuild to better handle the transition from gcc-config and updated
> toolchain.eclass to better work with multilib. I've had a bunch of help
> from the amd64 devs/testers/users this past week testing i
Ned Ludd wrote:
> On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
>> Ned Ludd wrote:
>>> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
>>> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
>>>
>>> Call it 'default'
Ned Ludd wrote:
> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
>
> Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specif
Jakub Moc wrote:
> Olivier Crete wrote:
>> Is there a recent list of non-ported packages ? Maybe we should do a
>> last effort to port everything for a week or two and then package.mask
>> the packages that no one cares enough about to port them.
>
> Hmmm, not a up2date one, AFAIK... There's a tra
Jakub Moc wrote:
>> =virtual/x11-7 is hiding breakage in ebuilds that are not ported for
> modular X.
I couldn't agree more, but I was forced to add this rather than allow
unported ebuilds to break.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Jeremy Huddleston wrote:
> I finally had a few free cycles, so I fixed up the eselect-compiler
> ebuild to better handle the transition from gcc-config and updated
> toolchain.eclass to better work with multilib. I've had a bunch of help
> from the amd64 devs/testers/users this past week testing i
Andrew Gaffney wrote:
> Rakotomandimby Mihamina wrote:
>> Hi,
>> I am trying to install qemu and kqemu, and I run into a problem:
>
> This is a question for the gentoo-user mailing list.
Didn't you notice, he cross-posted to there as well as personally
emailing me. Not something likely to make an
Christel Dahlskjaer wrote:
> The worry there was whether it would create controversy if they were
> hosted with other developer blogs, so we figured we'd host the actual
> blogs off-site (should irk less people, although presumably most will
> already have external blogs already) and just aggregate
Daniel Drake wrote:
> 1. We encourage our students to write about their projects on weblogs,
> and will set them up temporary weblogs at gentoo-soc.com if they do not
> have them already
Why a new domain? We've already got a blog setup at
http://planet.gentoo.org/developers/ and could just add
htt
Danny van Dyk wrote:
> Donnie: RFC: should ACML be modified to install both ABIs? (i.e. x86 and
> amd64). I'd say no, as no packages but glibc/gcc/binutils currently do
> that.
Portage should be fixed to allow things to be installed for ABI=x86 and
ABI=amd64. We shouldn't work around that in the
With great pleasure, I announce the testing release of new eselect
modules for BLAS, CBLAS and LAPACK implementations. You may say, "But we
already have 'eselect blas' and 'eselect lapack,' Donnie! What are you
thinking?" In reply, I would say, "The current eselect modules have many
limitations."
Mark Loeser wrote:
> At long last the devmanual is official. You can find it at
> http://devmanual.gentoo.org. I would like to thank plasmaroo for helping
> me with converting it to XML (since he did all of the XSL work to add in
> the features we needed to make it easy to write and expand upon).
Jeffrey Forman wrote:
> To all,
>
> Recently there have been reports of exceedingly long comments being
> posted on bugzilla bugs, such as kernel configs or long error messages.
>
> I had instituted a comment restriction in our test environment that will
> be shortly implemented, but with the rep
Mike Frysinger wrote:
> On Thursday 18 May 2006 06:41, Paul de Vrieze wrote:
>> The package sys-apps/paludis is in the wrong category. It is a package
>> manager on par with rpm, dpkg, etc. Those live in app-arch.
>
> app-arch is for things that manage archives
>
> paludis is much more than an ar
Harald van Dijk wrote:
> can't block themselves when only one may be
> installed at a time,
This is the one that really annoys me. New-style virtuals are supposed
to make things so easy, but you end up having a ton of crap added to
each provider to block all the others.
Thanks,
Donnie
signature
Harald van Dijk wrote:
> How does it help? New-style virtuals have several disadvantages, and the
> usual advantages of new-style virtuals don't apply here. If it actually
> provides real benefits, then no objections from me, but how is this
> easier to maintain than a "virtual/eject sys-block/uniej
Ned Ludd wrote:
> On Tue, 2006-05-23 at 12:38 +0200, Diego 'Flameeyes' Pettenò wrote:
>> So, right now virtual/eject is the old-style virtual that gets listed in
>> virtuals file in the profiles, defaulting to sys-apps/eject that is Linux
>> only.
>
> Please refrain from adding any new(bad) styl
Fernando J. Pereda wrote:
> I'd like people who use Git eclass to test it and see if any of the
> 'features' I introduced break things for them.
I just incorporated much of this into my version (minus some whitespace
changes) and pushed it up. Seems to work fine on my stuff, although the
additiona
Robin H. Johnson wrote:
> Simple case - consider a disconnected machine, that you use sneakernet
> to get files to - I've had a few in the past where the hardware was new
> enough that networking was broken or not supported yet, and I had to try
> a few patches and snapshots before actually getting
Greg KH wrote:
> Ok, we'll make it a new ebuild. "git-live-sources" perhaps? :)
If you just want the latest git rather than snapshots etc, you could do
a git-sources-.ebuild. That seems to have become the standard.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Robin H. Johnson wrote:
> On Fri, May 19, 2006 at 09:08:08AM -0700, Greg KH wrote:
>> On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
>>> Also, git-sources *should* use this eclass once it is in the tree since
>>> people using it will save _lots_ of bandwidth and disk space.
>>
Duncan Coutts wrote:
> In case anyone needs distracting from a current hot topic...
>
> Just like we have eclasses for cvs, tla etc, kosmikus has written one
> that does the same thing but for darcs.
s/kosmikus has/I have/, s/darcs/git/
> Darcs (dev-util/darcs) is one of the new breed of distrib
Matthijs van der Vleuten wrote:
> On 5/17/06, Christian Hartmann <[EMAIL PROTECTED]> wrote:
>> > With respect to the "hey support omg!" comments i say stick a big fat
>> > README about being an experimental profile or something like that and
>> > that's it. Usually bug reports require "emerge --inf
Kevin F. Quinn (Gentoo) wrote:
> # Xorg server is unaviodably suid with lazy bindings
> RESTRICT="stricter"
>
> to the xorg-server ebuild to stop it dying for people with
> FEATURES=stricter (the comment helps people who have enabled STRICTER
> to see why it's disabled, in case anything else crop
Kevin F. Quinn (Gentoo) wrote:
> The current solution (bail if -z,now is set in the compiler specs) is
> not one suggested by the hardened team, just need to make that clear,
> and it's not something we would encourage elsewhere. However until we
> can provide a solution for such a high-profile pac
Ned Ludd wrote:
> This was handled in the 6.8.x series and got dropped for unknown
> reasons when the modular X porting started happening.
> Unless your dead set on modular X I'd stick with the 6.8.x series.
We are using the solution that was suggested to us by members of the
hardened team. If yo
Simon Strandman wrote:
Hello
I installed modular X on my server running hardened. It was quite
annoying to have to switch back and forth betwen the vanilla gcc and the
hardened. I couldn't leave it on compiling over the night but had to
monitor it all the time. Is this really necessary? Why c
Ciaran McCreesh wrote:
> On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz
> <[EMAIL PROTECTED]> wrote:
> | so discussion with at least the portage team would be merited.
>
> Already happened, in amongst all the other GLEP 42 stuff.
Then I wonder why a member of the port
Stephen Bennett wrote:
> On Tue, 09 May 2006 18:27:45 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>
>> Then again, I'm missing context because people have this weird thing
>> about abstractly bringing up issues without discussing the actual
>> pro
Roy Marples wrote:
> On Wednesday 10 May 2006 01:17, Alec Warner wrote:
>> Please don't commit files to profiles/ unless it has been discussed
>> previously on this ML. I don't care if your file is insignificant or
>> 'won't affect anything else' or that it's 'completely necessary'. Please
>> dis
Alec Warner wrote:
> Please don't commit files to profiles/ unless it has been discussed
> previously
> on this ML. I don't care if your file is insignificant or 'won't affect
> anything else' or that it's 'completely necessary'. Please discuss it first.
>
> You don't have to ask for a vote o
Daniel Goller wrote:
> get we have lost one important thing out of sight, gentoo is a distro by
> users for users, and the users i think are left out of the loop on this
> whole situation
This may be true for you but not for all of us. Gentoo is a distro where
I can have what I want, and I can mak
Bart Braem wrote:
> Xorg 7: 5 months
Can't stabilize till portage 2.1 is stable. Doesn't matter how many open
bugs we've got, or how well it works.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Philippe Trottier wrote:
> We got some old school install done in a server around town, the libgpm
> was located in /usr/lib while /usr was only mounted later. This is a
> bug... Nothing should have a soft link to /usr/* from /bin or /lib*.
> Anyway it was an easy fix.
>
> Could people around che
Stuart Herbert wrote:
Hrm. Don't we get that benefit only if the overlays switch over to
using the same distributed VCS that the main tree moves to?
The short answer is yes.
The long answer is that it's much easier to interconvert histories
between most DVCS's than to convert back and forth
Alexandre Buisse wrote:
The opensolaris project has done a similar thing[1].
While we're posting useful links, here's another one from the cairo
project on switching from CVS to some distributed SCM:
http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
Thanks,
Donnie
--
gen
Alexandre Buisse wrote:
The opensolaris project has done a similar thing[1]. The three finalists
were bazaar[2], mercurial[3] and git[4], and the winner was eventually
mercurial. This is also the recommended choice from the EuroBSDcon
slides, so definitely something to consider.
Indeed, althoug
Jan Kundrát wrote:
Ryan Phillips wrote:
Stable and unstable keywords are a hack on top of a version control
system. We wouldn't have them if gentoo used an SCM that supports true
branches. There would be no need.
Umm, I'm not an ebuild dev, but how would users mix stable and unstable
package
Chris White wrote:
On Friday 28 April 2006 04:14 pm, Ryan Phillips wrote:
I disagree. By committing something to the current tree it has the
ability to effect a lot of people. What happens when we need to reverse a
commit? It isn't that easy with CVS.
cvs admin -or1.1
(delete revision 1.1)
Fernando J. Pereda wrote:
On Fri, Apr 28, 2006 at 02:56:26PM -0700, Ryan Phillips wrote:
I sorta like git in certain aspects. If git would work better than
CVS or anything other SCM I'm for it. Right now, _anything_ would be
better than CVS.
I don't really know if Git is suitable for our wor
Ryan Phillips wrote:
* In addition, git only allows checkins from the project parent.
A deal breaker in my opinion
Could you elaborate on what you mean by this? I don't understand.
Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list
Ryan Phillips wrote:
git - terrible with lots of tiny little files
Can you provide some evidence to support this?
I posted in more detail on SCMs elsewhere today.
Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list
A. Khattri wrote:
Does this sound right or is there a better (preferred?) way?
Try to fix --enable-conf-install to respect DESTDIR or whatever other
install method you're using, or look to see what flag it will take at
'make install' time to use a prefix.
Donnie
--
gentoo-dev@gentoo.org mai
Donnie Berkholz wrote:
cogito
Actually git on its own is pretty usable at this point. I use plain git
for managing my overlay.
Donnie
--
gentoo-dev@gentoo.org mailing list
901 - 1000 of 1428 matches
Mail list logo