On Sonntag, 22. Februar 2009, Tomáš Chvátal wrote:
> Well that is the reason why i am first eapi2ing the kde eclass. I was
> really suprised when i saw kde3 ebuilds with eapi2 :(
I value users suffering from package manager issues higher and fix issues as I
see them, walking through the tree. Onl
On Sonntag, 22. Februar 2009, Petteri Räty wrote:
> Even if the eclasses are not EAPI 2 ready you can work
> around it in the ebuild by for example those empty functions.
This is fine with me, when you care for said packages and their eclasses and
know for sure such hacks have a very limited life
On Sonntag, 22. Februar 2009, Petteri Räty wrote:
> java-check-environment
Running it, I got the message everything would be fine, but after uninstalling
Sun's 1.4 JDK, Portage told me it'll be still needed. So after a bit package
masking and uninstalling
dev-java/sun-jdk:1.4
=dev-java/java-sdk
On Freitag, 20. Februar 2009, Petteri Räty wrote:
> Suggestions/objections?
If you mean by "mass migration" doing that more or less blindly, I do object.
When an ebuild directly or indirectly inherits an eclass, which is EAPI 2
enabled, like base.eclass, while another isn't, you have to expect
On Sonntag, 14. September 2008, Zac Medico wrote:
> Well, I'm open to alternative suggestions. Please see the previous
> email in which I've attempted to explain the reasoning for the given
> approach [1]. It seems to me that this approach is well suited for
> solving cases in which temporary simul
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
> ~ * The meaning of the !atom blocker syntax now implies that
> ~ temporary simultaneous installation of conflicting packages is
> ~ allowed [3].
>
> ~ * A new !!atom blocker syntax is now supported, for use in special
> ~ cas
On Samstag, 26. Juli 2008, Arfrever Frehtes Taifersar Arahesis wrote:
> > Um, this already is the policy. We've always fixed bug reports about
> > LDFLAGS being ignored.
>
> Mark Loeser (Halcy0n) (QA project leader) said on 2008-07-24 that this
> policy doesn't exist. I understand that bug reports
On Samstag, 26. Juli 2008, Donnie Berkholz wrote:
> Why are you asking us? He's the QA lead, you should be talking with the
> QA team about this.
Such issues are not up to a self chosen group, but are topic for this list.
Carsten
signature.asc
Description: This is a digitally signed message p
Since it is time to get Qt 4.4 into testing, here some information how to get
the dependencies in the ebuilds you maintain, right.
Beforehand: Relying on best_version() or the broken qt4_min_version() stuff
from qt4.eclass is not fine.
- Migrating existing ebuilds requires a dependency like
On Mittwoch, 16. April 2008, Tiziano Müller wrote:
> While the dump command can read clusters created by an older version it is
> still necessary to dump and reload your data on version bumps between major
> versions [...
Of course. I didn't question the dump and reload cycle. Just saying you have
> c) Upgrading between major versions of PostgreSQL requires the DB admin to
> bump the database using the old version, moving the database away and to
> reload the dump into a new database cluster using the new version of
> PostgreSQL. Having to take down the old server and purging the old version
> KDE 4.0.0 will be released on January, 11th 2008, and if things keep
> going like they do now we might be able to put all the stuff into
> ~arch on the release day.
> I'm going to mail about this again in -core soon.
Unless you mean hard masked, I do object. The code base has too many issues
an
On Samstag, 5. Januar 2008, Wulf C. Krueger wrote:
> > Anything other suggestions?
>
> Let the maintainer of said package decide on the keywording (and therefore
> how to handle slacker arches).
That's not a good idea. What Gentoo needs is users (and this includes
co-develoepers) having a reliabl
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.
It's not perfect, but
_pkg_setup() {
something_wrong && die
}
s
On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
> Nobody said that eclasses can't use new features.
Using new features in ebuilds or eclasses relates. EAPI A using ebuild with
EAPI B using eclass (but not defining any EAPI) is your hard nut. Shouldn't
happen, but will. And bugs in eclas
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> * Eclasses may not set EAPI.
>
> * Eclasses may not assume a particular EAPI.
I disagree here. It would be annoying and possibly even hindering in future
not being able to use higher EAPI features in eclasses. Point is the eclass
has to ch
On Mittwoch, 14. November 2007, Josh Saddler wrote:
> Robin H. Johnson wrote:
> > There isn't meant to be the big black area at the top like, the main
> > gentoo.org site.
>
> But shouldn't there be some sort of area at the top with links to the
> other parts of the site, as the other pages do (the
On Sonntag, 11. November 2007, Ciaran McCreesh wrote:
> I suspect that for existing eclasses, the safest way to proceed is to
> make a new eclass and move common code into a third eclass. So you'd
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
> and foo-eapi1.eclass doing
On Freitag, 9. November 2007, Petteri Räty wrote:
> What if I want to use EAPI=1 features in an eclass? So if we for example
> we have an ebuild using EAPI=2 and then it inherits and eclass that sets
> EAPI=1 for slot deps.
You check which EAPI the ebuild sets, then either continue or die. Handlin
> work fine with conditional wx usage? need-wxwidgets for that, I guess?
No, please. These need-foo()'s are crap, because too often people people do
need-foo
DEPEND="another-dep"
resetting the to be stored dependencies to just "another-dep"...
Also top level function calls in ebuilds are dead
On Sonntag, 29. Juli 2007, Carsten Lohrke wrote:
> Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
> > Why did you provocate this breakage?
>
> Which breakage? It didn't install a gzipped pci.ids here.
That is with USE=hal. Crap...
Carsten
signature.asc
Description: This i
Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
> Why did you provocate this breakage?
Which breakage? It didn't install a gzipped pci.ids here.
On the other hand, reading the utterly ridiculous bug 180554, I haven't read a
valid argument why it should at all. Bizarre.
Carsten
signature.asc
On Mittwoch, 25. Juli 2007, Vlastimil Babka wrote:
> A: PDEPEND="B"
> B: DEPEND="A"
>
> If this is what you call RDEPEND conceptually broken, then sorry for
> useles try to explain it :) Maybe package manager could be smart enough
> and relax the RDEPEND in such cases itself, maybe it's better to s
On Mittwoch, 25. Juli 2007, Brian Harring wrote:
> I suggest you in the future check out what actually was changed, and
> do some testing- both the original poster, and yourself are missing
> what is occuring here
Uh, thanks, I never was fond of reading the code of Portage, so I took Piotr's
poin
On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote:
> As a result of bug #180045 PDEPENDs can be now merged even before the
> package that pulls them. Zmedico says that's intended behaviour
Well, then what our Portage devs think the intended behaviour should be is a
bug. E.g. in the case the bug
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
> Carsten, no offense but I think you totally misunderstood the scope of
> what I was trying to convey
Yeah, sorry, should have had read your initial email carefully. Taking
anything before the last - as version information is indeed a Portage bu
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
> That's exactly what I'm saying. CPV (Category/Package/Version) requires
> =, >=, <, <= to begin it.
So you'd like to change every foo/bar occurrence (and that's the common case)
to >=foo/bar-0 !? Completely out of line, imho. I don't understand
While I always was for uniq package names, tree-wide, renaming doesn't solve
anything. Gentoo's binary packages are fundamentally broken. You can't have
two binary packages of the same ebuild differing e.g. in use flags,
architecture, toolchain, etc. pp. either.
Carsten
signature.asc
Descrip
Christian, Raúl - you guys rock!
Carsten
signature.asc
Description: This is a digitally signed message part.
On Dienstag, 15. Mai 2007, Mart Raudsepp wrote:
> Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
> I wonder how much packages KDE needs rebuilt with the expat bump
> (revdep-rebuild --library expat.so or something like that). Maybe
> including it in the GNOME bumps is a goo
On Dienstag, 15. Mai 2007, Ciaran McCreesh wrote:
> preserve_old_lib is a horrible hack that shouldn't be being used at all.
> Don't push it as an alternative for proper slotting.
In it's current state it's indeed a horrible hack. But slotting is in many
cases no solution either. When you have to
On Dienstag, 15. Mai 2007, Caleb Tennis wrote:
> I just read the bug, but I don't see any compelling reason against using
> the preserve_old stuff.
The big problem with it is that we do not store information about retained
libraries and let portage throw warnings. When people miss such a post
in
These packages are lingering around for a long time and no one of the KDE team
seems interested fixing them, so they're up for adoption for a while, before
they I'll remove them from the repository.
Bug 177782 is yours, if you're interested.
Carsten
signature.asc
Description: This is a digit
On Montag, 14. Mai 2007, Jakub Moc wrote:
> As the name unrar suggests, it doesn't *pack* stuff, in only unpacks it.
Why do you come with unrar-gpl then. I'd assume the same for it.
> So, thanks and leave the thing alone in the tree; and yeah, there are
> really people who work w/ .rar stuff stil
On Samstag, 12. Mai 2007, Harald van Dijk wrote:
> Do you need to accept the unmodified GPL-2 for software licensed under
> the GPL-2 plus exception? No? Then GPL-2 does not belong in LICENSE,
> unless in a || group.
Of course you accept the GPL plus the added exception. Just because an
exception
On Samstag, 12. Mai 2007, Harald van Dijk wrote:
> On Sat, May 12, 2007 at 02:27:20PM +0200, Carsten Lohrke wrote:
> > No. LICENSE="GPL-2 some-exception" suffices.
>
> No, that means something completely different. It means that you should
> install the software only if
Does it matter that the DUID-LLT isn't stored when starting from a Live-CD? I
don't see why there is the need for a use flag for this functionality, when
it doesn't imply a new dependency.
Carsten
signature.asc
Description: This is a digitally signed message part.
Err, every single _GPL_licensed_ software needs an OpenSSL exception of
course.
Carsten
signature.asc
Description: This is a digitally signed message part.
No. LICENSE="GPL-2 some-exception" suffices. That said, we suck at our
licensing information badly. E.g. every single ebuild linking against OpenSSL
has (or at least needs to have) a linking exeption. We don't flag this
anywhere. More important, what's with optional dependencies!? We don't
supp
Thanks for the xml excerpt Pettery, but I'm still in the dark about what you
speak at all.
Carsten
signature.asc
Description: This is a digitally signed message part.
Asking here and hoping everyone reads it may result in stable tree breakage.
Open a bug and cc all maintainers of packages which depend on it, to get a
definitive answer, please.
Carsten
signature.asc
Description: This is a digitally signed message part.
On Samstag, 17. März 2007, Petteri Räty wrote:
> It's already used by alsa-driver.
Then either me or the one doing so missed something on the discussion, why it
was requested in the first place. Something to clarify in our ebuild policy.
Carsten
pgpUkMku2iZHo.pgp
Description: PGP signature
> Well that's the problem. When I use say _pre instead of _dev it gives
> off the wrong impression to users judging package by it's name. Since
> it's not a pre-release. A user may go upstream looking for some sort of
> pre-release. Which they won't find.
We have stable, testing and masked ebuilds
On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
> IMHO I think it should be up to the package maintainer how close they
> want to follow upstream. With regard to development, progress, testing,
> qa, feedback. I think it's a very good thing, since it allows things to
> be caught before act
This is a valid argument for a single postfix with a lower order than alpha,
but not a reason to add everything what's out there. I don't see the need to
match upstream's versioning bit by bit. Honestly said I've never understood
why our order is alpha, beta, pre and not pre, alpha, beta, which
On Samstag, 17. März 2007, Jakub Moc wrote:
> Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
> portage; dunno how does that fit the netbeans upstream scheme, though.
The additional postfix is reserved exclusively for user local ebuilds, not for
the ones provided by us.
There's absolutely no reason to absorb every single version naming scheme on
earth. Gentoo's does work nicely and more than we have would only be
irritating to the user. Simply use _pre or whatever fits, but
extending our naming scheme is unneeded and pointless.
Carsten
pgpcLcObgCmuK.pgp
De
On Freitag, 23. Februar 2007, Chris Gianelloni wrote:
> Except some things really do not compile with it enabled. Now, if
> you're meaning you'd prefer patch every compilation failure using
> -ffast-math instead, then I'd say go for it. Patches are always a
> better solution than workarounds.
I
On Freitag, 23. Februar 2007, Ciaran McCreesh wrote:
> Because the solution doesn't generalise. Consider:
> || ( a? ( a ) b ) a? ( a2 )
I didn't imply it to be a solution to the || ( use? ) problem you started the
thread with.
> And because it makes things more rather than less complicated...
On Mittwoch, 21. Februar 2007, Timothy Redaelli wrote:
> What do you think about custom-cflags global USE?
I'd be pleased to see the flag removed. I think it's up to the maintainers, if
they accept bug reports due to custom cflags, even though upstream doesn't or
restrict them for other reasons.
On Donnerstag, 22. Februar 2007, Ciaran McCreesh wrote:
> Inside || ( ) blocks, the package manager first removes any use? ( )
> blocks that are *immediate* (that is to say, not inside ( ) themselves)
> children if the use flag is not enabled (or disabled for !use?). Then,
> if the || ( ) block is
If that, what you stated in your last three paragraphs - and I do agree with
it - will be the case, this proposed PMS will be dismissed and Paludis
remains with a more or less accurate description, of what isn't a Gentoo
package manager.
Carsten
pgpf4jh4lkHfG.pgp
Description: PGP signature
On Monday 30 October 2006 14:23, Ferris McCormick wrote:
> I might be mistaken, but I believe sparc responds pretty quickly to
> security bugs, either by taking the requested action or by explaining
> why the requested action is impossible (i.e., build problems).
Yes, the Sparc team is rather quic
On Thursday 26 October 2006 22:41, Jakub Moc wrote:
> +1 ... SPF is broken by design.
Right¹. Don't understand why it gets used either.
Carsten
[1] http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-spf-is-harmful.html
pgp9zuYplnFtJ.pgp
Description: PGP signature
First step should imho be, that you work with the Portage team on having
proper set support implemented. Current meta ebuilds do suck, really.
Carsten
pgpY3uwbpcikw.pgp
Description: PGP signature
What have we learnt now, Jakub? Keep it in the bug report. ;)
Carsten
pgpxG13G6keIP.pgp
Description: PGP signature
On Thursday 07 September 2006 13:48, Jakub Moc wrote:
> I wonder how exactly genstef broke mips, 'cos mind you, he just reverted
> to what the ebuild was doing before Bug 114161 was fixed by
> hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded,
> it wasn't affected by that bug b
On Thursday 07 September 2006 13:25, Diego 'Flameeyes' Pettenò wrote:
> I'll try to overlook the reverted changes in kdelibs for bug fixes, the
> improper ${ROOT} injected in my changes where it wasn't supposed to be, the
> broken opengl on kdelibs checks that appeared last month, unhelpful
> comme
On Thursday 07 September 2006 11:11, Stuart Herbert wrote:
> And I'm sure I'm not the only one who has a problem with your
> comment in that bug either. Bugzilla isn't there for flaming other
> devs.
I did not do an ad hominem attack, but have a problem with a single action and
listed my points.
On Thursday 07 September 2006 07:58, Stefan Schweizer wrote:
> I am part of the kde herd, thanks.
To my knowledge you have never asked to join the KDE team, nor did I see you
helping tracking down KDE bug reports ever. Just adding yourself doesn't
work.
Carsten
pgp7tjbj1KWLV.pgp
Descri
On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
> I am not adding stuff. I am fixing existing packages. And I am taking
> responsibility.
How wonderful this sort of "maintenance" is you can read here:
https://bugs.gentoo.org/show_bug.cgi?id=146626
Am I the only one who has a problem w
On Sunday 03 September 2006 00:42, Diego 'Flameeyes' Pettenò wrote:
> And waiting other 2, 3, 4, 5, 6 months won't change the thing. Why? Because
> we have _no_ accessibility team right now.
Well, the bug is assigned to williamh, who is not /completely/ inactive. I
wonder, if only 37 commits in
Either MTA or MUA brokeness. Another email I have to send a second time. :(
On Sunday 03 September 2006 00:42, Diego 'Flameeyes' Pettenò wrote:
> And waiting other 2, 3, 4, 5, 6 months won't change the thing. Why? Because
> we have _no_ accessibility team right now.
Well, the bug is assigned to
On Sunday 03 September 2006 11:20, Kevin F. Quinn wrote:
> triggered by bug #77751: hspell lists a non-gentoo.org address for
> the maintainer email, the herd as maintainer-needed, and no other
> addresses.
>
> Is this sort of thing now ok?
No.
Carsten
pgpLh7ZV4WbmG.pgp
Description: PGP signat
Seems my message got swallowed...
On Saturday 02 September 2006 15:36, Edgar Hucek wrote:
> Just a side hint. Try to enable all flags at the first cimpile time would
> reduce trys drasticaly ;)
There are lots of use flag combinations incompatible with each other within a
package as well as packa
On Friday 01 September 2006 20:26, Greg KH wrote:
> So we are just fine, one of the advantages of being a source-based
> distro :)
Um, rereading term three of the GPL, you're right of course. The question
remains how do we flag this. LICENSE="GPL-2 CDDL-Schily" in case of
cdrtools!? Yes, the lat
On Friday 01 September 2006 15:45, Luis Medinas wrote:
> I'm sure that situation will be fixed by the upstream (Jörg) since it
> violates GPL license. About the debian fork we will take a look at it
> and see where's going.
Read the Debian bug. Jörg Schilling is badmouthing Debian developers and t
The file listing the derecated overlays is fine. What about revdep-rebuild and
emerge regarding installed stuff and overlays?
Carsten
pgpMpDspMcPVc.pgp
Description: PGP signature
On Friday 01 September 2006 14:51, Lars Weiler wrote:
> We have a lot of other applications in the tree, which is
> not free.
The problem is not that it's not free*, but that linking GPL and CDDL code
violates the GPL. If the whole cdrtools code were CDDL, there were no
problem.
*The OSI consi
As discussed here¹, the author of cdrtools, Jörg Schilling, violates the GPL
in his application, by building GPL software with CDDL licensed makefiles as
well as linking mkisofs to libscg, which he relicensed to CDDL lately. Debian
seems to fork² cdrtools therefore.
Imho we have to remove the p
On Thursday 31 August 2006 16:58, Simon Stelling wrote:
> I think we agreed at least 3 times on that the logrotate use flag
> shouldn't exist at all because those files add <4kb to the package.
Right. Open a bug and cc involved maintainers. This is the way it works -
maybe slowly, but it does. We
On Thursday 24 August 2006 09:54, Donnie Berkholz wrote:
> The council doesn't actually do anything AFAICT, it just "approves" GLEP
> decisions that have already been made. So in effect we have no leadership.
Well, to quote the council project page:
"The elected Gentoo Council decides on global i
On Thursday 17 August 2006 21:42, James Potts wrote:
> hmmmdoesn't the GNU ClassPath implement enough of Java's runtimes
> to handle a command-line app like this
When it is at 100% 1.4 compatibility (and that does not mean nearly as bug
free, stable, fast, etc. as Sun's Java is), the latter w
On Sunday 06 August 2006 00:26, Mike Frysinger wrote:
> and i'm on the opposite side where implicit RDEPEND should be clean:
Why? I for one consider explicit dependencies much more clean. If Portage at
some point should distinct between dependencies defined in ebuilds and
eclasses, we'd need a d
As far as I'm aware the problem isn't the security team, but the reasons are:
1. slow/understaffed arch teams - and I suppose this is the biggest problem,
as we need all security-wise supported¹ architectures stable, before a GLSA
can be send out.
2. the amount of unmaintained stuff in the tree
On Thursday 03 August 2006 04:56, Brian Harring wrote:
> *cough*. bit hypocritical for you to lecture me about viewing
> your statements as 'flaming', and in the same breath label
> my own as 'flaming' ;)
>
> Why am I pointing this out? My initial points were that of "why the
> double standard",
First I'd like to state that I do offer my opinion. You don't have to like it,
but disqualifying it as flaming, while exactly doing this yourself,
disqualifies you. I'd appreciate, if you would try to have a controversial
discussion, without starting to loose your manners.
On Wednesday 02 Augu
On Wednesday 02 August 2006 05:50, Richard Fish wrote:
> Nothing that I have read about sunrise, either in GWN, their project
> pages, or the FAQ, has given me the impression that they are "urging
> all users to give it a try". There is certainly some advertising
> about it, as would be appropriat
On Thursday 01 January 1970 01:00, Alec Warner wrote:
> eclass changes? You can't even commit eclasses to it...
Eclass changes in the main tree, including all relevant ebuilds updated, but
breaking the ebuilds in the Surise overlay, having whining users or borked
systems in the worst case.
Ca
On Monday 31 July 2006 13:01, Christian Andreetta wrote:
> Seemant Kulleen wrote:
> > On Sun, 2006-07-30 at 23:50 -0400, Brett I. Holcomb wrote:
> >> My concern is beyond me. As I stated I know enough about what to
> >> expect IF I use sunrise. But many do not and with it becoming official
> >>
On Monday 31 July 2006 07:05, Seemant Kulleen wrote:
> OK, let's start with: what exactly is the problem?
Please reread my replies in the first sunrise thread. Points are: no security,
issues with eclass changes which will result in bug spam, the fact that
sunrise is a bunch of arbitrary package
On Monday 31 July 2006 04:52, Mike Frysinger wrote:
> On Sunday 30 July 2006 22:28, Dan Meltzer wrote:
> > 1) Users can submit patches/ideas to bugs.g.o at whatever frequency
> > they desire, contributing to gentoo casually.
>
> load up your browser and check out how many bugs are assigned
> to '[E
On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote:
> qt3 and qt4 is being used there already and it is obvious
It's "nice" to invent new use flags affecting Qt stuff without contacting
those who care for Qt.
>
> > 2) A package requires either Qt3 or Qt4 (both not both?...such as
> > x11-lib
On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote:
> How exactly does one go about maintaining our developers? ;)
It's devrel's cursed job. Ask them. :)
Carsten
pgpDHDEmEDUMI.pgp
Description: PGP signature
On Saturday 17 June 2006 14:39, Michael Cummings wrote:
> Kevin F. Quinn wrote:
>
> If RDEPEND is not set, it is defaulted to $DEPEND by portage.
>
> Alas, if only. If you inherit an eclass with deps this carry over won't
> happen. (And I have the bugs to prove it ;)
Well, has been the job of the
On Friday 09 June 2006 14:04, Stefan Schweizer wrote:
> Please, do not assume our users being stupid. They know that they are using
> an ebuild from the sunrise overlay with zero support. They deliberately
> typed
You have said stupid, not me. Some won't care enough, I'm quite sure about
that. We
On Friday 09 June 2006 13:44, Peter wrote:
> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in t
This may work for Apache or PHP, but an overlay with arbitrary "maintainer
wanted" ebuilds would need an extra bugzilla account. The problem is that
this won't really help, since (some) users will see "oh, an kde app crashed"
and file a bug at [EMAIL PROTECTED] Then /me looks at the tree, doesn'
On Friday 09 June 2006 02:53, Stefan Schweizer wrote:
> > It also doesn't answer the questions of security and maintenance. Are
> > genstef and jokey going to be responsible for the security of every
> > single package in the overlay?
>
> Yes, we will be acting upon all issues that we hear about.
In my eyes only the main tree is official. The overlays are development niches
(and as such perfectly fine), to speed up development without causing much
trouble in the main tree. The problem is that overlay.g.o is seemingly
official, because we host it. It should be made more clear that this is
On Friday 09 June 2006 12:12, Chris Bainbridge wrote:
> This larger group of users are the ones that would benefit
> from an overlay.
And this larger group of people is exactly the same one, that doesn't know to
help itself, if necessary and will suffer the most, when something goes
wrong. This
On Thursday 08 June 2006 02:42, Stefan Schweizer wrote:
> Initially jokey and myself will be working on this. The current focus is to
> migrate ebuilds from bugzilla into the overlay and to get contributors to
> commit their changes to the overlay instead of updating the bugzilla every
> time.
Can
On Tuesday 06 June 2006 11:25, Diego 'Flameeyes' Pettenò wrote:
> SDL based games requires mikmod quite often. I suppose Mike knows what he's
> saying.
It's a difference to know that, compared to share ones thoughts, which Mike
missed to do.
Carsten
pgp1iJ8Y6QlGG.pgp
Description: PGP signatur
On Tuesday 06 June 2006 04:11, Michael Sterrett -Mr. Bones.- wrote:
> Some games fail in pkg_setup if sdl-mixer isn't built
> with mikmod but I'm not sure if we've added the built_with_use check to
> all of the games that need it yet.
Time to fix this. And removing the flag would help, as bugs wou
On Tuesday 06 June 2006 06:07, Mike Frysinger wrote:
> mikmod is the only one i'd keep ... people generally want mikmod whether or
> not they know it ;)
I'd say 99,9% don't want mikmod. Arguments please, not vague assertions. :)
Carsten
pgpMnmHuAbjLA.pgp
Description: PGP signature
On Tuesday 06 June 2006 04:45, Andrew Muraco wrote:
> Sorry for the offtopic of this, but what would a user set as the
> useflags to have GTK-2 used by default, and GTK-1 for apps that only
> support it? (but not build GTK-2-capable apps with GTK-1)
Just the gtk use flag.
Carsten
pgp2dKgmdERfv
This list is for development discussions. Please file a request at
http://bugs.gentoo.org
Carsten
pgppRNCcOVLoi.pgp
Description: PGP signature
On Monday 05 June 2006 23:25, Chris Gianelloni wrote:
> Well, it doesn't affect stages, and GRP stuff is done w/ USE=bindist, so
> again, this is a non-issue.
Well, I didn't mean our binary releases, but being held liable for making
property of others available by default, without the permission
On Monday 05 June 2006 20:52, Chris Gianelloni wrote:
> > Have a look at
> > /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list
> > of current default use flags.
I think it's a bad idea to have win32codecs in make.defaults. There's quite a
number of codecs in the package an
On Monday 05 June 2006 20:08, Harald van Dijk wrote:
> No, the decision with the gtk/gtk2 USE flag mess was to have package
> maintainers decide for each ebuild whether to support only gtk1 or only
> gtk2, but not have support for both in a single ebuild.
I know about the decision of the Gnome team
1 - 100 of 233 matches
Mail list logo
