Re: [gentoo-dev] About testing applications

2007-03-18 Thread Simon Stelling

Petteri Räty wrote:

Many applications save preferences in ~/.app/. When testing
applications please make sure you test with an empty directory to catch
cases when an upgrade works fine but a clean install doesn't. Thanks.


Even better: Fix them to use ~/.config/app instead, so they don't 
clutter up the home unnecessarily :)


--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo

2007-03-14 Thread Simon Stelling

Richard Brown wrote:

Respectfully, you're wrong. When you're writing a
policy document we do need to dissect every word.


I disagree with that. At least in my country, laws are written in a 
flexible enough way to give judges the ability to interprete the law to 
a certain extend, and it works just great. I don't see why we have to 
dissect every word, especially since it makes it so easy to not to see 
the wood for the trees. The goal of the CoC is fairly vague ('getting 
along well'), so why is there a need to specify the way ulta-explicit?


--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo

2007-03-13 Thread Simon Stelling

Thanks for the write-up :)

| Receiving one (or more) warnings. Usually, you wouldn't be banned for
| a single warning, but it might happen if we feel your infraction is
| severe enough. We consider banning to be pretty serious; we take each
| situation on a case-by-case basis and make sure we always have a
| consensus for whatever decision we reach.

Who is we in this? I assume it's devrel, but I think it should be
written out.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Some council topics for March meeting

2007-03-04 Thread Simon Stelling
Ciaran McCreesh wrote:
 It's
 wasting everyone's time and annoying a lot of people.

This sniplet was brought to you by the almighty Flaming Guide [1]:

| One thing is to frequently refer to us or our. Pretend like people
| are with you on this, so the uncertain ones will flock to your side!
|
| Code listing 1.6: Usage of plurality
| email: Stop wasting our time!

[1] http://dev.gentoo.org/~chriswhite/docs/flame.html

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] more up to date minimal install cd

2007-03-03 Thread Simon Stelling

Daniel Robbins wrote:

And it should be one (web) page.


http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1

--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Some council topics for March meeting

2007-03-03 Thread Simon Stelling

Daniel Robbins wrote:

1) Any material created by Gentoo developers, as part of an official
Gentoo Project, needs to have copyright assigned to the Gentoo
Foundation, whether or not it is currently included in the Portage
tree. This protects all of our collective contributions against
misuse, which is why it is policy.


Except that in many European countries you can't even re-assign your 
copyright. Oops.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Some council topics for March meeting

2007-03-03 Thread Simon Stelling

Ciaran McCreesh wrote:

I find it amusing that no-one complaining about this has actually asked
to see it.


I think ferringb did, just not very successfully.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Some council topics for March meeting

2007-03-03 Thread Simon Stelling

Ciaran McCreesh wrote:

I'd like it spelt out please.


Here we go:


So why not start by imposing deadlines upon more important projects
like Portage USE deps, [snip]


USE deps can't be used anyway in EAPI=0 because it would break current 
versions of portage. So we need EAPI=1, but you can't say putting 
together version 2 of a spec before version 1 was writte is sane. So we 
need the EAPI=0 spec. Makes it pretty easy to figure out why this spec 
is fairly important.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64
--
gentoo-dev@gentoo.org mailing list



Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)

2007-03-03 Thread Simon Stelling
Danny van Dyk wrote:
 2) There are countries who acutally adhere to the Berne Convention 
 (1886). This means even the deed of commiting sources with a Copyright 
 (C)  Gentoo Foundation is useless in most countries of the EU.
   ^
It's still Europe :P --'

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] multilib-strict

2007-02-24 Thread Simon Stelling

William Hubbs wrote:

Where do I find information on how to fix the package?


If you don't have a box using a multilib profile (I guess the user who 
filed the bug was using an AMD64 box), you won't be able to reproduce 
it. Just reassign the bug to [EMAIL PROTECTED], we'll fix it :)


Regards,

Simon
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-22 Thread Simon Stelling
Simon Stelling wrote:
[snip crap]

Actually, ignore me, there's a fundamental flaw in my thinking.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Hi all,

I recently worked on the app-emulation/emul-linux-x86-* packages and 
used almost identical code snipplets in them, so I realized I might as 
well put together an eclass and drop the duplication. The eclass would 
provide a common template for the following packages:


app-emulation/emul-linux-x86-baselibs
app-emulation/emul-linux-x86-compat
app-emulation/emul-linux-x86-gtklibs
app-emulation/emul-linux-x86-medialibs
app-emulation/emul-linux-x86-qtlibs
app-emulation/emul-linux-x86-sdl
app-emulation/emul-linux-x86-soundlibs
app-emulation/emul-linux-x86-xlibs

Thanks for any feedback,

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Simon Stelling [EMAIL PROTECTED]
# Purpose: Providing a template for the app-emulation/emul-linux-* packages 
#

ECLASS=emul-libs
EXPORT_FUNCTIONS src_unpack src_install

DESCRIPTION=Provides precompiled 32bit libraries
HOMEPAGE=http://amd64.gentoo.org/emul/content.xml;

RESTRICT=nostrip
S=${WORKDIR}

SLOT=0
IUSE=

DEPEND=

emul-libs_src_unpack() {
einfo Note: You can safely ignore the 'trailing garbage after EOF'
einfo   warnings below

unpack ${A}
cd ${S}

ALLOWED=${ALLOWED:-^${S}/etc/env.d}
find ${S} ! -type d ! -name '*.so*' | egrep -v ${ALLOWED} | xargs 
-d '
' rm -f || die 'failed to remove everything but *.so*'
}

emul-libs_src_install() {
for dir in etc/env.d etc/revdep-rebuild ; do
if [[ -d ${S}/${dir} ]] ; then
for f in ${S}/${dir}/* ; do
mv -f $f{,-emul}
done
fi
done

# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null

cp -a ${S}/* ${D}/ || die copying files failed!
}

Re: [gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Timothy Redaelli wrote:

# remove void directories
find ${S} -depth -type d | xargs rmdir 2/dev/null


Portage should remove blank dirs or am i wrong?


Yes, but only in the unmerge phase it seems, so you it installs them, 
then checks whether they are empty and removes them again, which is both 
stupid and confusing.



cp -a ${S}/* ${D}/ || die copying files failed!


For future *BSD compatibility (yes i want to use the linux bsd emulation
for flash, opera, etc) it's better to use rsync -a imho


I'll use cp -pPr.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Simon Stelling wrote:

I'll use cp -pPr.


Actually -dpPR, which is what -a is an alias for.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Fabian Groffen wrote:

I'll use cp -pPr.

Actually -dpPR, which is what -a is an alias for.


Yes, but -d is a GNU option, and BSD people are after the POSIX only
options, hence the -pPR.  :)


Missed that, Flameeyes just told me about it, so the -d will be dropped 
again ;)


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Mike Frysinger wrote:
every use of find | xargs in there should be fixed to use find -print0 | 
xargs -0


The second one, yes, that's fixed now. The first one, no, cause egrep 
wouldn't like it. The xargs -d'
' ensures that \n instead of a simple space is used as delimiter. If 
some package really installs files with a newline character in its name, 
well, then that package is just not worth including in emul-packages.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New emul-libs.eclass

2007-02-19 Thread Simon Stelling

Mike Frysinger wrote:

replace that with:
xargs -d $'\n'


aye, that looks way better.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Google Summer of Code 2007

2007-02-17 Thread Simon Stelling
Ciaran McCreesh wrote:
 * devmanual. Not converting it over to a new shiny XML thing or
 whatever, but just extending and reworking the parts that need it.

Last year's SoC FAQ said that the actual work would have to be coding,
not writing documentation.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] New preserve-libs feature

2007-02-17 Thread Simon Stelling
Marius Mauch wrote:
 So everyone who has valid objections to the _general idea_ of this
 implementation (preserving old libraries to avoid some runtime linker
 errors) speak up now. 

For how long are these libraries preserved? This might have a security
impact in cases like the recent openssl-case where you had to upgrade to
an incompatible ABI because the version using the old one was
vulnerable. Using preserve-libs it would leave the old lib around,
making it possible for programs to link against the wrong version and
ending up being vulnerable. I realize that the feature is meant to help
the transitional phase until all apps are built against the new ABI, but
how would you find these vulnerable apps currently? revdep-rebuild
wouldn't rebuild them since they are still functional.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] New network config for baselayout-ng

2007-02-08 Thread Simon Stelling
Ciaran McCreesh wrote:
 Which is all very well, but not sufficient reason to screw up a project
 that is developed and used by a lot of people.

As if we were all gonna die without bash arrays in our config files.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Another council topic for Feb

2007-02-03 Thread Simon Stelling

Mike Doty wrote:

We're going to talk about arch keywording policies.  IMO we should have
a standard policy if you own and use ${ARCH} then you may keyword your
packages for ${ARCH} with the exception of the sys-*/ categories.


keyword ~${ARCH} exclusively or also marking stable?

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New USE_EXPAND - CAMERAS

2007-01-21 Thread Simon Stelling

Hi,

This was discussed before, and noone was against it as it seems:

http://article.gmane.org/gmane.linux.gentoo.devel/44932/match=cameras+use+expand

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Some sync control

2007-01-11 Thread Simon Stelling

Piotr Jaroszyński wrote:

What do you think?


I think it would be much nicer to have a VCS with support for atomic 
commits.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Ideas for projects...

2007-01-11 Thread Simon Stelling

I like the idea. Something really useful I could think of is *drums*

the implementation of GLEP 42.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] deprecating /etc/make.profile

2007-01-10 Thread Simon Stelling

Hi all,

As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of 
/etc/make.profile and the use of a PORTAGE_PROFILE variable instead. 
Reason for this change aside from consistency with all other portage 
settings is the annoyance of re-adjusting the /etc/make.profile link 
before and after testing a profile change in an overlay/development repo.


Before the change to portage is finally made, a few things will have to 
be done:


* Adjust handbook
* Adjust the eselect plugin
* (Anything I'm missing?)

If you don't like this idea, please speak up.

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

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Through the looking glass: Reflections on Gentoo

2007-01-08 Thread Simon Stelling

Hi,

Ivan Sakhalin wrote:
Now, our memories of the past are not always as thruthful as we 
would like

them to be, selective memory is what makes some large things small and some
small things large. So let us not idealize the past as if it had no 
problems,

but let us try to keep a perspective on how things have changed, evolved
maybe, into what they are now and what they may become.


Let us also not forget that a very vocal minority doesn't make a majority.


Many good people, having all attained the rank of full developer, have
retired, with a noticeable increase in the last trimester or so. Some have
retired to avoid all the political tomfoolery that kept them from enjoying
their work, some left as they found something else to fill that special 
place

in their heart. Some, sadly, did not feel they could contribute enough as
real life took its toll - may they find some time in the future. And a very
selected few, regrettably, were retired against their will.


Depends on your point of view. Some of these regrettable cases weren't 
that regrettable to me.



These removals even went outside the ranks of developers - the hostile
takeover of some IRC channels has caused unneeded tension between groups 
that

should cooperate. It is a sad day when the appearance of a gentoo developer
may be the first sign that your channel will now be censored and people
removed that have dissenting opinions.


I don't know what you're talking about here. Can you elaborate?


a few people. But when people are denied an appeal and devrel unilaterally
decides, ignoring policies and common sense, what is one supposed to think?


Same here.


Everything that is not official (for certain undefined values of official -
objectivity seems to be lost on many humans) is attacked, torn apart and


By the very vocal minority. Be reminded that the large majority of the 
devs doesn't give a damn, to be clear.



insulted. A great example of that is the Sunrise Overlay, which has become
quite a success, with a few of the community members becoming devs - at the
same time I see with sadness that at least one dev has retired because of
Sunrise. What madness there is when people leave such a great project 
because


One. It was his own choice, so I don't think that incident is too dramatic.


I ask you not to redo the errors of the past and remember the lessons
learned - there is so much that needs to be done, but no single person has
the strength to do them. Cooperate you must, my friends. Only when you 
leave

the infighting and bureaucracy behind can you aspire to true greatness.


You're not the first one to figure this out. It looks quite simple, and 
everybody will agree with your statement above, because it is not 
practical at all. As soon as you get into implementation of above 
wisdom, things get complicated. So, if you seriously want to help 
Gentoo, do it in a concrete manner.



   - Reduce the rules so that things can be done without a week of
discussion for every small idea


This is a very interesting idea. Do you genuinely think that less rules 
will result in less discussion? Quite the contrary, my friend. If there 
is no rule for an action, there will be a discussion whether said action 
was good or not.


We don't need more or less rules, we need better rules.


   - how can the environment be improved so that people can enjoy their
work and not care about silly problems?


Shut up the people that cause silly problems. We've done it before, it 
works.



So, with that being said, I hope that things change for the better.


I doubt so, to be honest.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Wrong dependencies to postgresql

2006-12-25 Thread Simon Stelling

Enrico Weigelt wrote:
since jakub (as always) closes all my bugs, I'll report the issue 
to this list before completely giving up and never ever waste a 
single second on reporting bugs ...


Please, never ever waste a single second on reporting bugs anymore. 
Your time is too worthy to be spent on such things. Thank you, and have 
a merry Christmas.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] CAMERAS as USE_EXPAND

2006-12-23 Thread Simon Stelling

Hi all,

I would like to add CAMERAS to the list of USE_EXPANDed variables. It is 
currently used by media-libs/libgphoto2, which can be built with/without 
support for the following photo cameras:


adc65 agfa-cl20 aox barbie canon casio clicksmart310 digigr8 digita 
dimera directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 kodak 
konica largan lg_gsm mars minolta mustek panasonic pccam300 pccam600 
polaroid ptp2 ricoh samsung sierra sipix smal sonix sonydscf1 sonydscf55 
soundvision spca50x sq905 stv0674 stv0680 sx330z template toshiba


...which is IMO enough to warrant USE_EXPAND.

For any objections, suggestions for a better name, etc. please also see 
bug 139884: http://bugs.gentoo.org/show_bug.cgi?id=139884


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] --config-root command-line option

2006-11-16 Thread Simon Stelling

Daniel Barkalow wrote:
Allow PORTAGE_CONFIGROOT to be set as a command-line option. It can be 
annoying to get environment variables to emerge, particularly when you 
need sudo and you only want the environment variable some of the time.


I think it would be better to solve the problem with sudo at its root:

/etc/sudoers has the following:

# Reset environment by default
Defaultsenv_reset

Commenting that out reverts this annoying behaviour and fixes all 
kinds of bugs.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Ignoring/overwriting IUSE from an eclass

2006-10-30 Thread Simon Stelling
Piotr Jaroszyński wrote:
 Just for fun(=I wouldn't use it in ebuild/eclass):

Sorry, but this mailing list is not really the best place for just for
fun bash foo. I suggest you take it somewhere else.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: license group file format

2006-10-26 Thread Simon Stelling
Marius Mauch wrote:
 Ok, as there is currently a lot of work going on for GLEP 23
 (licese based visibility filtering aka ACCEPT_LICENSE) the topic of
 license groups came up, in particular the way how they should be
 (technically) defined.
 
 The simplest way is a line based format
   groupname license1 ... licenseN
 however this doesn't allow for any addition of metadata (for example
 descriptions to explain the purpose of a group), these (if wanted) would
 have to be defined in another file. The alternative would be to use a
 more complex file format, for example so called ini-style

Uhm, what kind of metadata are we talking about here? Descriptions can
just be placed in comments above the group specification line, no?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: license group file format

2006-10-26 Thread Simon Stelling
Uhoh, forgive me for not reading the other replies before writing a
completely redundant one.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure

2006-10-25 Thread Simon Stelling

Mike Frysinger wrote:

(how do you measure the degree of a change ?)


By the number of inflammatory mails it causes within the timeframe of 
two weekdays. Quite obvious, isn't it? ;)


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Simon Stelling

Chris Gianelloni wrote:

Realize that the new council is trying to both become the leaders of
Gentoo that so many seem to want, yet also have to balance not
overstepping the bounds some people think we need.  We honestly do need
everyone's opinions on these things, so thank you for posing yours.


I don't mind the council touching the metastructure, as long as they do 
it right ;) If they don't, I will surely state so and ask for a 
referendum. If it turns out that like 60% of the devs don't share the 
council's opinion I'm sure they will re-think their decision.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: RFC: Gentoo Commitfests

2006-10-23 Thread Simon Stelling

Alec Warner wrote:
Haha, there are times when you need to realize that it's just joking 
around, versus an actual flamefest ;)


This makes Gentoo look very unprofessional. It even makes us look like 
we're having fun.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] implicit vs explicit dependencies

2006-10-23 Thread Simon Stelling

Alin Nastac wrote:

Up till now, I relied on implicit dependencies (dependencies of my
dependencies).
Apparently now (see https://bugs.gentoo.org/show_bug.cgi?id=152534) we
should add every atom that an ebuild depends on to (R)DEPEND.
Which is the right way?


In the bug above we're talking DEPEND, for which this is true: gtk was 
installed with a binpkg and those don't pull in their DEPENDs because 
the package is already built. For RDEPEND you can savely rely on 
implicit dependencies, in most cases at least.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New Developer: Matti 'mabi' Bickel

2006-10-22 Thread Simon Stelling
Hello all,

It is my pleasure to announce the devification of Matti (mabi) Bickel to
the Gentoo community. Matti has been a Gentoo/PPC arch tester for about
a year and finally made the step to a full-fledged dev. As such he is
going to help the PPC team with keywording requests and bugfixes.

Living in Weimar and studying CS in Jena, he is going to join the German
conspiracy. He is also a member of the local CCC there. Non-computer
hobbies are reading (science, hitchhiker up and down, other novels,
but of course also computer-related) and adrenaline sports such as table
tennis.

Please give him a warm welcome!

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] amd64 and ia64 keywords

2006-10-21 Thread Simon Stelling
Ilya A. Volynets-Evenbakh wrote:
 | No worries, there are people who even wanted to merge amd64 with x86. 

 Yeah, that's almost as daft as suggesting a single keyword to cover
 both sparc v8 and sparc v9, or ip22 and ip27.
   
 Err... No, IP22 and IP27 are nearly identical as far as userland goes.
 (and if we did everything right, they would be completely identical)
 Now, if you said o32, n32, and n64

[x] You just made a fool of yourself.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: Recommended -march settings [was: Re: [gentoo-dev] CFLAGS paragraph submission for the GWN]

2006-10-14 Thread Simon Stelling

Wernfried Haas wrote:

What about creating an official document for both -march/mtune and
CFLAGS settings for different CPUs? If some other people like the idea
and no one else volunteers i can go poke the different arch teams,
toolchain folks and whoever else may be involved about it and compile
a list based on their input.


Check out these packages [1] before doing that, they will probably 
supply all you need.


[1] http://packages.gentoo.org/search/?sstring=cpuinfo

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Simon Stelling

Paul de Vrieze wrote:
I would go for the EAPI bump. Even then I think it would be smart to 
wait a short while for packages to use this as we ensure that the 
supporting portage version is stable.


Err, EAPI was designed to assure that a supporting version is actually 
used, no need to wait then.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Simon Stelling

Andrew Gaffney wrote:
Are you saying you like a bunch of php-only USE flags (I'm not picking 
on php...it was just the first that came to mind) being in the default 
USE in the profile?


Do you also like the nofoo flags? AFAIK, previous discussions said that 
the per-ebuild default USE would go in the USE stacking order above 
make.conf and below package.use, so that USE=-* wouldn't remove the 
default USE flags for the particular ebuild but the user could still 
disable it via package.use if they *really* wanted to.


Actually, USE=-* would still remove them because make.conf is above the 
defaults in the stacking order (if i understood correctly). Plus, don't 
forget that we will get package.use for the profiles with this patch, so 
it fixes all the problems in-ebuild defaults would solve too.


I agree that base/ would probably be the better place for this. It 
avoids another layer that seems just redundant.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] *plop*

2006-10-13 Thread Simon Stelling
Good luck with all the things you will be doing in future... You will be 
missed.

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] GLEP 14?

2006-10-11 Thread Simon Stelling

John J Lee wrote:
So, is there some work that needs to be done on portage before step 3 
happens -- i.e. is now the wrong time to be doing that work?  Or is it 
just lack of somebody to do it?


In short: No, yes, yes.

What really is needed is sets support in portage. See bug 144480 for that.

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

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

2006-10-10 Thread Simon Stelling

Roy Bamford wrote:
Dropping support for x86 i686 is a debate we need to have some time I 
suppose, its a question of when.


There is clearly only a few users, besides myself using systems that 
old, since there were very few forums posts about the original 2006.1 
x86 media not workign on P1 and AMD k6 based systems.


I'm sure I'm not the only one who is using a pentium mmx as a router, so 
you better think twice about it :P


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

2006-10-09 Thread Simon Stelling

Dominique Michel wrote:

When an user or a potential user read it and want to do a networkless install,
it will just use the Live CD install, and just get in trouble. It is even worse
when many Linux magazines will have this CD. And you cannot argue at it is just
to use catalyst or to burn a CD from a stage 3, when the doc say a bootable CD
that contains everything you need to get Gentoo Linux up and running.


That statement is still true. I have done 3 networkless installations 
for this release, without a problem. I used the installer. Using it you 
get your box up and running fast and convenient, so what exactly is the 
problem? It's not like you can't get Gentoo running without a network 
connection anymore.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Simon Stelling

Christian Heim wrote:

- Make every dev a member of at least 1 arch team


I think that would solve the understaffing of some of the arch teams (iirc 
amd64 and x86 are having enough devs / at's right now)


No. We don't need more people on our dev lists, because it won't change 
anything. What we need is more people who do actual testing. If you're 
forced to be in an arch team you're just a dev tag in a project page, 
not more. This is not going to help at all, in fact it will only hide 
the problems even more.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Simon Stelling

Thomas Cort wrote:

The number of opened bugs has always been higher than the number of
closed bugs in the bug stats listed in every 2006 GWN. How is this
'going forward'? It seems to me like we are falling behind.


Take a closer look at the statistics. The numbers seem drastic, but once 
you've seen the queries behind them you know how to interprete them and 
things don't look that bad anymore.



 - Make every dev a member of at least 1 arch team

Which doesn't mean he will ever keyword stuff stable, other than his
own, which he already can... Let's face it: most devs are mainly
interested in their stuff, getting their stuff keyworded, and many
wouldn't anyway have the time to efficiently work on an arch-team, as
members of such I mean, not just as I'm a member, so I keyword my
stuff, that's it... For that I agree with the current practice: if you
want that, ask the arch-team first. ;)


Every developer should have access to at least 1 Gentoo system. They
should also be able to determine if something is stable or not. It
would cut down on the number of keyword/stable bugs if developers did
a lot of their own keywording.


We had this model already, the x86 arch team did not always exist. We 
could revert to the old one, would be less bureaucratic. Would also take 
quite some load off the arch teams. Would also result in worse overall 
quality of the tree. *shrug*



 - Double the number of developers with aggressive recruiting

That's something that goes on since... forever! Gentoo's continuously
recruiting new people, more aggressive recruiting has already been
proposed many times, but it was always agreed to try to maintain a
relatively high standard of new recruits, and if you want quality,
finding loads of people who just happen to have the time and
dedication to become a Gentoo dev isn't that easy.


Even when someone is found it is hard for them to find mentors. We
need to improve this. I had found someone who wanted to join the sound
team and I was unable to locate a mentor for him (I wasn't a dev for 6
months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and
only one person offered. The person who offered fell through because
he didn't have enough free time.


 - No competing projects

Kills innovation... Who comes first has total monopoly of that branch of
things basically... I'd never agree to something like this, personally.


What happened to working together? Should we work together instead of
competing against each other?


Sometimes you want to achieve the same goal by totally different means. 
Sometimes there are good reasons for a complete new start. It does not 
even mean you don't communicate anymore. Brian Harring, although working 
on pkgcore which basically competes portage, communicates a lot with the 
portage team and vice versa, in a very productive manner. Nevertheless, 
you won't find anybody on the portage or pkgcore team saying that it 
would have been better to incorporate the ideas of pkgcore into portage. 
Sometimes it's simply better to start all over again.



--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN

2006-10-03 Thread Simon Stelling

Daniel Ostrow wrote:

It is inherently unreliable and outside of Gentoo's control.


Sorry, I really tried hard, but I just couldn't anymore... Must... say...

__ _   _   _ _  _
   / \  | |   | | | | | |  _ \  | __ )  / \  / ___|| |
  / _ \ | |   | | | | | | |_) | |  _ \ / _ \ \___ \|  _|
 / ___ \| |___| |___  | |_| |  _   | |_) / ___ \ ___) | |___
/_/   \_\_|_|  \___/|_| \_\ |/_/   \_\/|_|

_  _     _ _ ___  _   _     _ ___
   / \  |  _ \| | | __ )| | |   / _ \| \ | |/ ___| |_   _/ _ \
  / _ \ | |_) |  _|   |  _ \|  _| | |  | | | |  \| | |  _| || | | |
 / ___ \|  _ | |___  | |_) | |___| |__| |_| | |\  | |_| |   | || |_| |
/_/   \_\_| \_\_| |/|_|_\___/|_| \_|\|   |_| \___/

 _   _ 
| | | / ___|
| | | \___ \
| |_| |___) |
 \___/|/

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: New Developer: Jim Ramsay (lack)

2006-09-27 Thread Simon Stelling

First time I'm happy we're having the developer lack ;)

Welcome Jim!

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New dev: dev-zero

2006-09-27 Thread Simon Stelling

Hi all,

It is with great pleasure that I announce the devification of Tiziano 
'dev-zero' Müller. He writes us:


I'm from Zurich, Switzerland. Born here and still living here  :-)
I'm studying physics at the University of Zurich and working
in a small company as IT responsabilitee and software engineer.

I also worked on a subproject of the LHC (Large Hadron Collider), called 
LHCb. I'm responsible for the database design and implementation 
(postgresql) for the sensor test database.


Besides that I'm working as a freelance software consultant for a couple 
of private customers.


If I'm not working, I'm playing the violin or watching movies.

With this addition, the Swiss conspiracy soon will be powerful enough to 
bribe everybody else with chocolate, so you better watch out.


Everybody please give Tiziano a warm welcome!

--
Kind Regards,

Simon Stelling
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New Developer: Tristan Heaven (nyhm)

2006-09-26 Thread Simon Stelling

Hello all,

I am proud to announce Tristan Heaven as the latest addition to the 
Gentoo developer community! Heaven knows why he wants to contribute to 
Gentoo: To help the games herd maintaining the games-*/ categories. 
Tristan is 19 and lives in a small town in England, near the Lake 
District. In his free time he is mostly busy playing^W_testing_ games, 
so we can all be assured that any stablization requests filed by him 
have gone through a careful inquiry.


Welcome Tristan!

--
Kind Regards,

Simon Stelling
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-22 Thread Simon Stelling
Alin Nastac wrote:
 Our civilized disputes are taken place in public because we are an open
 organization. If this looks bad in the eyes of some, so be it, but
 please keep your opinions out of this list.

Except that they're not always that civilized, which was his entire point.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Delay in approval of new developers

2006-09-22 Thread Simon Stelling
Peter wrote:
 We can disagree on that point. All distros are businesses. Users are
 customers. No users, no distro.

I haven't received a single paycheck in two years. What a shitty business.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC about another *DEPEND variable

2006-09-21 Thread Simon Stelling
Duncan Coutts wrote:
 So for it's something like:
 # for C:
 ABI=${SONAME}
 
 # for python
 ABI=${PY_PV}
 
 # for haskell:
 ABI=${GHC_PV}
 
 paludis has something going in this direction but I don't think it'd
 quite solve the python/ghc abi issue. It was aimed more at cases like
 mips with it's multiple abis.

It's all about multilib and has (except for the unfortunate name)
nothing to do with this issue.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Simon Stelling
Grant Goodyear wrote:
 If we
 (being Gentoo) say that we're going to do something, and then things
 fall through, it might make us look bad, after all.

Maybe it's just me being stupid, but what exactly do we have to loose?
(This is a serious question, I'd appreciate serious answers.)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] seeds, GLEPs, and projects

2006-09-21 Thread Simon Stelling
Ciaran McCreesh wrote:
 Huge amounts of time, effort and users. How much arch team time was
 spent fixing genkernel? How much time was spent fixing the OS X mess?
 How many users did we lose as a result of all the QA screwups?

Eh, I wanted answers, not more questions :P

 As much as I hate relying upon slashdot for anything reasonable at all,
 an awful lot of people in that thread were suggesting that more time be
 spent on QA and fixing existing bugs and much less on fancy new
 things...

These users are ignoring the fact that time is not the only and most
important factor. Motivation is far more important IMO, and it's pretty
hard to get the motivation together to test 60 packages instead of
tinkering around with a new idea. At least for me it often is.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Hello all,

I would like you to share your comments on the attached GLEP with me.

Thanks in advance!

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
GLEP: 52
Title: License Managment in Portage
Version: $Revision: $
Last-Modified: $Date: $
Author: Simon Stelling [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Sep-2006
Post-History: 20-Sep-2006

Abstract


GLEP 23 [1]_ was brought into existance 31 May 2003 to help users that
do not want to implicitly accept any license. Three and a half years later, it
is still not implemented. This GLEP aims at exactly the same target as GLEP
23, but with a different technical approach.

Credits
===

The ideas found in this GLEP originate from or are heavily influenced by 
Iván Pérez Domínguez's and other people's comments on bug 17367 [2]_.

Motivation
==

GLEP 23 has failed to get implemented. This GLEP proposes a quick and easy, yet
elegant way to enhance portage's license handling.

Specification
=

If a certain package requires to - implicitly or explicitly - accept licenses,
it obviously depends upon acceptance of said licenses. The set of licenses a
package depends on may vary, e.g. on the selected USE flags. Dependencies on
specific licenses should be treated no different than dependencies on other
packages, i.e. they should be defined using ``[R,]DEPEND`` syntax.

Every license which a package in the portage tree depends on gets a package in
the ``txt-licenses/`` category. Its ebuild must install the license text to 
``/usr/shared/licenses/``. The initial version shall be 1 if there is no version
specified.

There will also be a bunch of meta-packages: At least

* ``txt-licenses/osi-disapproved-licenses``, 
* ``txt-licenses/fsf-disapproved-licenses``, and 
* ``txt-licenses/gpl-incompatible-licenses``

should exist and be a dependency of
all licenses that possess the respective attribute.

Users can then assure that they do not implicitly agree with a license they
would not agree with explicitly by masking the license's package. If they only
want to accept packages that are e.g. approved by the FSF, they can simply mask
the ``txt-licenses/fsf-disapproved`` package.

Licenses that need to be explicitly accepted before installation of a package
(and only these) should be package.masked by default with a header like
the following:

::

# Simon Stelling [EMAIL PROTECTED] (20 Sep 2006)
# This license needs to be agreed on explicitly to be considered
# legally binding.
# By unmasking and installing the package you agree with its terms.
txt-licenses/wierd-license

As a lot of licenses have the same name as the packages that use it, the 
license's package name should contain a ``-license`` appendix.

The ``LICENSE`` variable currently used in ebuilds should be kept. However, it
should no longer use DEPEND syntax (e.g. || ( )) but a simple list of license
names. This is useful for package indexes like packages.gentoo.org and simple 
What license does this package use? queries.

Backwards Compatibility
===

For a reasonable amount of time, ``repoman`` should simply warn if there is not
at least one dependency to a license package. New ebuilds should make use of the
package-based system.

Once (almost) all ebuilds are ported to the new system, repoman should consider
the lack of a license dependency an error.

References
==

.. [1] GLEP 23
http://www.gentoo.org/proj/en/glep/glep-0023.html
.. [2] Gentoo Bug 17367
http://bugs.gentoo.org/show_bug.cgi?id=17367

Copyright
=

This document has been placed in the public domain.


Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Steev Klimaszewski wrote:
 I think it is over engineering of a non-issue.

Which non-issue in particular?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Krzysiek Pawlik wrote:
  # Simon Stelling [EMAIL PROTECTED] (20 Sep 2006)
  # This license needs to be agreed on explicitly to be considered
  # legally binding.
  # By unmasking and installing the package you agree with its terms.
  txt-licenses/wierd-license
 
 Why not make the ebuild ask for confirmation? Would work with versioned 
 licenses
 (for example: txt-licenses/wierd-license-2.1 and
 txt-licenses/wierd-license-2.999 - both would require ACK). Breaks portage in 
 a
 way it's interactive, but it's already happening in few ebuilds
 (eutils.eclass::check_license()).

Even assuming you have multiple versions of such a license, the user can
still unmask specific versions in case he really agrees with one version
but not another. If he unmasks just the package, then you can take that
as a he's fine with all of them. The reasoning for doing it this way
is that merges should really be non-interactive wherever possible. Sure,
there are a few exeptions, but they should be kept as rarely as
possible, and avoiding it IS possible in this case.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Sunrise trusted committers with bugzilla access

2006-09-14 Thread Simon Stelling
Stefan Schweizer wrote:
 To my fellow Gentoo developers,
 
 in the Sunrise project we have some users who are ambitious and cotribute
 more than a few ebuilds. Those regulars have the possibility to take the
 ebuild quiz and acquire the title Sunrise trusted committer. Those
 sunrise committers can use extended bugzilla permissions to edit keywords
 EBUILD and REQUEST for example in the maintainer-wanted@ and
 maintainer-needed@ bugzilla region where usually developers clean up litle
 or have no interest in spending time on.

I am not up to date, but I know that when the AT project was started, it
wasn't possible to give out access on specific keywords but just the
KEYWORD field as a whole. Not that it would make a difference, just
mentioning it here...

 All this is addressed and working with the current arch testers procedure.
 The plan is to just treat Sunrise trusted committers the same as arch or
 herd testers. The difference is that they operate on ebuilds of all
 flavours that interest themself in the sunrise overlay and not on a certain
 herd of packages. Neither do they focus on testing for a specific
 architecture. Just coding is their work, not testing - which explains the
 difference in the name.

Huh, I hope they will do testing :P

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

2006-09-12 Thread Simon Stelling
 Protected Locations
 ===
 
 Protected locations are determined by the ``CONFIG_PROTECT`` environment
 variable, which is defined in the profiles and which may be augmented or
 overridden by the current environment and user configuration files. This
 variable contains a space separated list of values which are matched against 
 the
 beginning of a full file path and name of files to be installed.

which are matched against the beginning of a full file path would mean
that e.g. CONFIG_PROTECT=/etc/foo would protect the following:

/etc/foobar/doh
/etc/foo
/etc/foobaz

.. or did I misunderstand something here? I don't know whether that is
the current behaviour of portage, but IMO it certainly shouldn't be. It
should rather be

/etc/foo (file)
or, if /etc/foo is a dir:
/etc/foo/*

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] colon separated variables in /etc/env.d/

2006-09-11 Thread Simon Stelling
Zac Medico wrote:
 What is the best way to propagate information about these two
 variable types?  For example, we can have a list of variable names
 stored in a new variable called COLON_SEPARATED that will reside
 in either the profiles or /etc/env.d/ itself.  Variable names not
 listed in COLON_SEPARATED can be assumed to be space separated.
 Does anyone have any ideas to share about how this information
 should be propagated?

Considering that some pretty critical variables (like PATH) are amongst
these I would prefer them to be in /etc/env.d. I wouldn't like it when
my box is totally screwed just because PORTDIR doesn't point at my
portage tree for the moment.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Simon Stelling
Alec Warner wrote:
 If you can't work
 it out, you talk to your project lead.  If THEY can't work it out, you
 talk to the ombudsman, and so forth.  Everyone knows the policy and yet
 no one follows it.  I don't want to see this thread continue; you know
 what you have to do.[1]
 
 [1] http://www.gentoo.org/proj/en/devrel/policy.xml

Don't even have to go that way. It's far simpler:

(quoting the devrel policy you linked to:)

Issues not necessarily related to personal conflict, such as
intentional or repeated policy breaches, malicious or abrasive behavior
to users or developers, or similar developer-specific behavioral
problems should be brought directly to Developer Relations via
[EMAIL PROTECTED] These should be dealt with on a case-by-case basis by
Developer Relations and may require disciplinary action.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Simon Stelling
Carsten Lohrke wrote:
 One question remains: Is it needed/correct that Portage doesn't take blockers 
 for architecture breakages into account? Such a line/prefix is easily changed 
 and when someone - whatever the bad reason is - uses cvs commit, a real tree 
 breakage is the cause.

The behaviour is correct. The depstring in question was
!app-text/hunspell-1.0, which means that you can't have hunspell-1.0
and kdelibs installed on a system at the same time. Reason for this
could e.g. be file collisions that got fixed in hunspell-1.0.

If the depstring was !app-text/hunspell-1.0 app-text/hunspell, (same
as =app-text/hunspell-1.0, just retarded)  repoman would complain loudly.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Simon Stelling
Jakub Moc wrote:
 carlo, you might want to revert it properly, instead of reverting only
 half of the previous commit you've been complaining about here.

Could you please take such stuff where it belongs next time? (To the
bug, that is.) There's really no need to point out such things on -dev,
because this is not a hey everybody, look, $dev did something stupid!
list. It doesn't matter whether $dev is genstef or carlo or anybody
else. The bitching ain't gonna stop if you just give back.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Moving ebuild-related where they belong

2006-09-07 Thread Simon Stelling
Zac Medico wrote:
 If we implement the repo-level profile, it can have a
 bashrc (much like profile.bashrc) that acts as a repo-level ebuild template
 (like install-helpers.eclass).  Actually, the repo-level profile already 
 exists
 in the form of files such as ${PORTDIR}/profiles/{package.mask,arch.list},
 though it doesn't yet have support for a bashrc (ebuild template).

Well, this is a nice idea, but not applicable to this problem. I had a
chat with Brian some days back, and the conclusion was that factoring
out the helper functions is basically an EAPI change. If we handle it
transparently, as in either using PORTAGE_AUTOLOAD_ECLASS or the
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
install-helpers.eclass, we're actually forced into using that one and
only version, which is quite limiting.

So, the correct way to do it is to define an EAPI=1 that does no longer
include these helper functions and make the eclasses/ebuilds that use it
inherit the eclass manually. However, this will need to run through -dev
and I'm afraid the ebuild devs wouldn't like it at all :-/

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Moving ebuild-related where they belong

2006-09-07 Thread Simon Stelling
Zac Medico wrote:
 Well, if the metadata generation step is viewed as being separate from the 
 rest,
 and the helpers aren't needed during that step, then it's possible to get the
 EAPI from the ebuild without the helpers being in the environment.  Once the
 EAPI is known, the package manager can use that to determine what else (if
 anthing) needs to be added to the environment.  Then you'd only need a way to
 tell the package manager which EAPI levels the functions in your
 install-helpers.eclass (or whatever) apply to.

That is a workaround, but it makes a pretty hard link between the
package manager and the functions, which is exactly what I am trying to
cut through with the patch. Sure, it'd be a workaround, but just keeping
them in the portage package until EAPI=1 is reached is one too...

 So, the correct way to do it is to define an EAPI=1 that does no longer
 include these helper functions and make the eclasses/ebuilds that use it
 inherit the eclass manually. However, this will need to run through -dev
 and I'm afraid the ebuild devs wouldn't like it at all :-/
 
 They won't like it because it's expected that EAPI will provide the necessary
 information.  Why should they have to inherit some special eclass if it's
 already implied by the EAPI that they've specified?

It wouldn't be implied anymore. The install-helpers.eclass would
actually be like every other eclass, like eutils fex.

Actually, the reason they won't like it for will more likely be that it
requires adding another eclass to the inherit line for ~15'000 ebuilds.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Moving ebuild-related where they belong

2006-09-07 Thread Simon Stelling
Brian Harring wrote:
 Make this change, and it means that all overlays that can function as 
 standalone, must bundle the eapi helpers themselves.

Not true. I don't have to add eutils.eclass to my overlay to use epatch.
Same goes for install-helpers.eclass. Standalone-repos will have that
problem, but there is none yet to my knowledge. Sure, the problem
persists for future repos, but it's not so much of a deal to copy an
eclass once.
Also, as it stands today, portage IS connected to gentoo-x86 through
exactly these helpers. Upon the needs of the portage tree the functions
in portage are changed, and this is simply not correct.

 This is ignoring the potential fun of an overlay that redefines an 
 eapi locked function.

eclasses in overlays that also exist in the tree are fun anyway. If
people are messing with eutils, we tell them that it is entirely their
responsibility if something breaks. Same goes for install-helpers.eclass.
That being said, this problem already exists today: A custom eclass
could simply define a function 'dosbin' and ebuild.sh would use that
one. While it's a possible cause for breakage, it's not an argument
against the move.

 A) requirement of trying to keep helper functionality exactly in sync 
 per tree,

If the helpers were a part of the EAPI those trees would have to verify
that the EAPI portage provides matches their needs. Whether you sync
against portage or the portage tree is not a big difference.

 B) fragmentation this implicitly enables
 isn't good.

I agree here.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Simon Stelling
Stefan Schweizer wrote:
 it
 is meant to be as non-concrete as possible to allow usage in as many cases
 as possible.

Which makes it pretty pointless. Really, this GLEP says almost nothing,
it's simply too vague to express any intend.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-portage-dev] Moving ebuild-related where they belong

2006-09-03 Thread Simon Stelling
Hi all,

I have thought a bit more about how to better organize the bash-side of
portage and came to the conclusion that modularization of ebuild.sh (as
proposed in the recent thread Refactoring ebuild.sh) can't be the only
and is not the best thing to do.

There is a fair amount of shell scripts and functions in the portage svn
repo that do not really belong there. For example all do*/new* scripts
in the bin/ directory. These are scripts that are not specific to
portage's implementation but the ebuilds that use it. That's why I think
we should move them more towards the ebuilds: Inside the tree.

This has the advantage that paludis/pkgcore don't have to keep their
helper scripts in sync with portages, that they get more visible to
ebuild devs (to some, especially the new ones, they seem like magic
commands that just come out of the middle of nowhere) and most
importantly, that they are where they belong. ;o)

Having them in the tree rather than portage would avoid bugs along the
lines of bug 121317 [1] and bug 136792 [2], or at least pull them off
portage's radar. As those functions are really the ebuild devs' area,
that's only a good thing, IMO.

As they reminded me very much of eclass functions, I converted them into
functions and put together an 'install-helpers.eclass'. Having them as
functions has the advantage of being able to create all of the new*
functions with zero redundancy and only few lines of code and being in
the same line as other helping utilities like the ones provided by
eutils and other eclasses. It has the disadvantage of not being able to
execute them with `find -exec' or `xargs'. However, that is not too much
of a problem in my eyes: I scanned the tree and out of the ~2400 ebuilds
that use find -exec/exec/xargs, none used it in combination with the
scripts I propose to convert to functions.

Having them in an eclass raises the problem of ebuilds having to inherit
said eclass, though. Even if it would be the correct way, I am not all
that keen on adding a 'inherit install-helpers' to ~15'000 ebuilds, so I
solved the problem this way:

--- ebuild.sh   2006-09-03 15:39:22 UTC
+++ ebuild.sh   2006-09-03 15:53:02 UTC
@@ -1350,6 +1350,9 @@
 # this can be left out of ebd variants, since they're unaffected.
 unset EBUILD_DEATH_HOOKS

+# let the profiles define eclasses to automatically load for every ebuild
+[[ -n ${PORTAGE_ECLASS_AUTOLOAD} ]]  inherit ${PORTAGE_ECLASS_AUTOLOAD}
+
 source ${EBUILD} || die error sourcing ebuild
 if ! hasq depend $EBUILD_PHASE; then
RESTRICT=${PORTAGE_RESTRICT}

Setting PORTAGE_ECLASS_AUTOLOAD enables every repository to define its
own set of standard functions.

Note that I don't really care how the functions/scripts get into the
tree, it only matters to me *that* they are in the tree, so I'm open to
other suggestions. Also, this is probably not the only heap of functions
to move out of portage into the tree, I just didn't want to do more
before I know what way to choose.

Suggestions, comments, alternative approaches, flames, all are welcome.

[1] http://bugs.gentoo.org/show_bug.cgi?id=121317
[2] http://bugs.gentoo.org/show_bug.cgi?id=136792

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Simon Stelling [EMAIL PROTECTED]
# Purpose: Install helpers to facilitate various actions performed in
# src_install
#

# Note: All of these were moved out of portage as they are only
# ebuild-specifc

ECLASS=install-helpers

#
# into*/*opts section
#

# These functions control where and how files/directories given to do* and
# new* functions are installed.

into() {
if [ $1 == / ]; then
export DESTTREE=
else
export DESTTREE=$1
if [ ! -d ${D}${DESTTREE} ]; then
install -d ${D}${DESTTREE}
fi
fi
}

insinto() {
if [ $1 == / ]; then
export INSDESTTREE=
else
export INSDESTTREE=$1
if [ ! -d ${D}${INSDESTTREE} ]; then
install -d ${D}${INSDESTTREE}
fi
fi
}

exeinto() {
if [ $1 == / ]; then
export EXEDESTTREE=
else
export EXEDESTTREE=$1
if [ ! -d ${D}${EXEDESTTREE} ]; then
install -d ${D}${EXEDESTTREE}
fi
fi
}

docinto() {
if [ $1 == / ]; then
export DOCDESTTREE=
else
export DOCDESTTREE=$1
if [ ! -d ${D}usr/share/doc/${PF}/${DOCDESTTREE} ]; then
install -d ${D}usr/share/doc/${PF}/${DOCDESTTREE}
fi
fi
}

insopts() {
export INSOPTIONS=$@

# `install` should never be called with '-s' ...
hasq -s ${INSOPTIONS}  die Never call insopts() with -s
}

diropts

Re: [gentoo-dev] Re: The Age of the Universe

2006-09-02 Thread Simon Stelling
Edgar Hucek wrote:
 Just a side hint. Try to enable all flags at the first cimpile time would
 reduce trys drasticaly ;)

If you had a look at the php ebuild (just because we took it as example
here), you'd see that it is a bit more complicated than just enabling
everything to have everything tested.

 So you say a developer cant't test all useflags? That is a strange
 message from you. How can a developer garantee that his package is correct.

He can't. That's what we're saying. Nobody said we can, nor do, nor want to.

 Realy funny, i only hear exuses but no real solution for the problem.

You have heard the real solution for the specific problems you pointed
out: File a bug. You have also heard why it is impossible to guarantee
that it simply works.

 The fact is, that long outstanding bugs are simple ignored. If a useflag
 would only apply to one package it could be ok, but not when the same
 useflag is in other packages and makes this one useflag for the normal user
 unusable.

man portage:

package.use
  Per-package USE flags.  Useful  for  tracking  local  USE
  flags  or  for  enabling  USE  flags for certain packages
  only.  Perhaps you develop GTK and thus you want documen-
  tation  for  it, but you don't want documentation for QT.
  Easy as pie my friend!

  Format:
  - comments begin with #
  - one DEPEND atom per line with space-delimited USE flags

  Example:
  # turn on docs for GTK 2.x
  =x11-libs/gtk+-2* doc
  # disable mysql support for QT
  x11-libs/qt -mysql

Know your tools, man.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: The Age of the Universe

2006-09-02 Thread Simon Stelling
Edgar Hucek wrote:
 I know my tools but not necessarly the normal user who wanna use gentoo
 and is ending frustrated.

If the users are too lazy to read the documentation, why should we care
about them?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Suggestion: Globalness of some USE flags

2006-08-31 Thread Simon Stelling
Steve Dibb wrote:
 And the descriptions seem to be pretty much the same in all of them from
 use.local.desc

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.

About the udev, there's one package that doesn't share the effect:

sys-apps/pcmciautils:udev - Install as an udev helper instead of a
hotplug helper

Which is different from the other 5 Enable udev rules file installation.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 39 compliance

2006-08-30 Thread Simon Stelling
Wernfried Haas wrote:
 As far i am concerned, i find seperate sections quite good as it's a
 clear solution as it's easy to see who is an official Gentoo monkey
 who did all the quiz stuff etc. May be subject to personal taste though. 

Well, yeah, it just makes we wonder what the fuck an ebuild quiz has to
do with a bash framework, as in this example? Really, the ebuild quiz is
cool for ebuild maintainers, so you at least know about some common
mistakes, but it does nothing beyond that.

Simply spoken: You can use them as indicator for _nothing_, i.e. it's
completely unimportant whether you did the quizzes or not. IMO, at least.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage Sets

2006-08-29 Thread Simon Stelling
Chris White wrote:
 y'all are killing me

So are you:

 --
 Chris White
 Gentoo Developer aka:
 ChrisWhite
 cpw
 ChrisWhite|Work
 WhiteChocolate
 VanillaWhite
 Whitey
 WhiteLight
 WhiteCheese
 WhiteSugar
 WhiteButter
 WhiteWall
 WhiteLemon
 WhiteApple
 WhiteBlanket
 WhiteEnergy
 WhiteWhite
 cab go shorten your sig ChrisWhite

head -n4 $(~/.sig)  ~/.sig

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Refactoring ebuild.sh

2006-08-27 Thread Simon Stelling
Brian Harring wrote:
 categorization is a bit whonky in a few spots-

I won't fight that. It was pretty hard to categorize functions that I've
never really noticed before ;)

 Debugging:
  register_die_hook()
 
 ebuild specific func, while debugging, it's not ebuild.sh debugging.
 
  diefunc()
  dump_trace()
 
 these are general utility, not debugging.

Where would you stick them? 'die' to 'ebuild helpers' and 'dump_trace'
to 'internals'?

 Action functions:
  dyn_setup()
  dyn_unpack()
  dyn_clean()
  dyn_compile()
  dyn_test()
  dyn_install()
  dyn_preinst()
  dyn_help()

  Abort handlers:
  abort_handler()
  abort_compile()
  abort_unpack()
  abort_test()
  abort_install()
  killparent()

 internal is a better label.

Well, that stuff under 'Abort handlers:' which I accidentally indented
was intended to go in an own file. However, seeing the list this way, it
might be better to stick them in the same one, which the label internal.
Could also put the 'Internal helpers' there as they are really short anyway.

 has is missing also...

Well, has* is already in isolated-functions.sh. I've thought about
killing that and moving the functions to the appropriate sections, but I
was not sure whether isolated-functions.sh was sourced from different
places too so that I simply put it off for the moment. If it's not
sourced otherwise, I'd certainly move the functions there too.

 If you're going to try breaking the beast up, suggest you go the step 
 further and break up what must be supplied from the ebuild.sh 
 implementation, and what is bound to the ebuild's environment.
 
 
 Internal eclass functions:
  newdepend()
  newrdepend()
  newpdepend()
  do_newdepend()
 
 These aren't eclass functions- usable without involving eclasses.
 inherit ought to be in internal eclass functions also (yes it's user 
 visible, but it's also ebuild.sh implementation specific).

Where to put them, then?

 I moved them into own files within a subdir in bin/, called modules, and
 source these files at the right time, so that nothing changes
 functionality wise. The global scope code I left untouched, except for a
 bunch of exports that set sane defaults for the do*/new* helpers.

 This cuts down ebuild.sh to 403 lines, which makes it far more readable,
 IMO.

 Except there are now magic vars hidden away in submodules.  If trying 
 to seperate it into seperate blocks, document 'em.

Uhm, how would that documentation part work? What exactly do you want
documented? (What do it and 'em refer to?)

About the magic vars.. I wasn't sure either whether putting the defaults
into the modules was a good idea. I thought it would be good because
they are not used anywhere else (didn't check), but I can just as well
stick them back into ebuild.sh.

 I also set all the functions that aren't meant to be overridden by saved
 env, profile bashrc, portage bashrc or ebuilds/eclasses readonly.
 
 Don't think much thought was put into this tbh- use* and has* (all but 
 useq and hasq basically) are bound to the ebuild environment.

This is actually true.

 Why?  Because they got mangled transitioning from 2.0.50 2.0.51, for 
 the ebuild to function properly it needs to use the original func from 
 the environment, not what the ebuild.sh implementation tries to force.
 
 Identified all of them that are affected by this?

Well, as it stands now, all variables except the sandbox related ones
are defined after env  bashrc are sourced and before the ebuild is
sourced. That means that the env can't override them, which means that
they are considered implementation specific in the current
implementation. I agree that consideration is nonsense, though ;)

So, to address the problem: What functions are bound to the ebuild
rather than ebuild.sh?

Beside {use,has}{,v} I don't know any.

 Further, all of these are still overridable by *bashrc and env.

How?

 Actually it doesn't fail sourcing.

Yeah, my bad. But you'd get a nice error message at least ;)

 Drop the readonly crap; it's not actually blocking anything, just 
 attempting to catch non real issues; in the process, it actually is a 
 step in the wrong direction.

I will drop it for now, but I would like to know the answers to above
questions nevertheless.

 Reordering is a bit arbitrary, but fine.  Attempted env changes, would 
 avoid those.

My primary goal is to cut down ebuild.sh to a managable size. I don't
see how that can be solved with a different env handling, tbh.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo-Status

2006-08-22 Thread Simon Stelling
Lance Albertson wrote:
 Frankly, the attitude of a lot devs lately towards infra
 have made many of us not want to communicate what we're doing. If we're

I can understand that, partly. But that won't help anyone. Assuming
you're not thinking *nobody* outside infra does respect you, try to
write the status report for those who you feel respected by. It will
even make those happy who didn't respect you and maybe even make them
respect you again because they see that a genuine effort is made to
solve a problem that buggers them.

 not getting respected by you, then why should we respect you back? At
 least for me personally, I don't hold any personal grudges against
 anyone unless you stop respecting the group and/or me. Personally, I
 think the larger problem in Gentoo itself is the attitudes of many
 developers. Communication aside, it means nothing if we can't deal with
 each other in a semi-professional manner. It seems like mini-flame
 explosions on irc/email have happened more frequently in the last few
 months. This is just going to make the group implode if nothing is done
 about it.

Respect is something that should be applied unconditionally, in my
opinion. The you don't so I won't attitude gets us nowhere.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo-Status

2006-08-22 Thread Simon Stelling
Lance Albertson wrote:
 I generally try to do that, but after the 10th time the person doesn't
 respect you and demands things from you, its kind of hard to keep that
 mentality.

Well, one out of 300. Simply do it for someone else then ;)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

2006-08-16 Thread Simon Stelling

Enrico Weigelt wrote:
I already suggested an bug-reporting tool, which automatically 
collects all the necessary data, several weeks ago. This tool is 
simply called by commandline and asks the users several questions.

Then it files an bug with some certain syntax and uploads necessary
information (emerge --info, pkg-db extracts, ...).


That somehow looks like the guided file-a-new-bug form we had some time ago. 
Personally, I'd rather have it in bugzilla, because a shell tool takes the user 
away from bugzilla, and after all you have to search for existing bugs anyway, 
so you already are on bugzilla.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: AT emerge info cruft attachments to [STABLE] bugs

2006-08-12 Thread Simon Stelling
Being an amd64 dev, I want to basically add a 'me too!' here. I think
it's not necessary to add the --info output when all worked well,
though, if instead the output of -pv $PN was given. Except when there
was a failure reported before, because then we need it to compare the two.

Regarding the inline vs. attachment issue, I'd vote for inline too.

Just my 0.05 CHF,

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] use.force as a complement to use.mask in profiles

2006-08-08 Thread Simon Stelling

Peter Gordon wrote:

Zac Medico wrote:

The difference with use.force is that it prevents flags, that are deemed
extremely important, from being accidentally disabled by the user.


If they were so extremely important then they would not be optional,
and hence not even be USE flags at all, no? Or am I missing something?


Yes. Some flags are extremely important to certain users (read: profiles) but 
not to others. In some cases the USE flag are so extremely important because 
they are more or less what makes the whole profile. Think of 'selinux' or 
'multilib'.


http://article.gmane.org/gmane.linux.gentoo.portage.devel/2316

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] client+server packages - build which one?

2006-08-08 Thread Simon Stelling

Enrico Weigelt wrote:
But it's very unclear. Ask around in the user list, who knows what 
minimal in this special case means (without extra reading the 
documentation). Such useflags should be obvious, but minimal isnt.


without extra reading the documentation? Documentation is there to be read!

That being said, server/client flags are nice, but not really applicable until 
we have per-package default USE flags, which is soon I hope.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Masking practics

2006-08-08 Thread Simon Stelling

Joshua Nichols wrote:

While it is columnar, the D is in a dark blue font. If you happen to be
using a dark background, there is extremely little contrast. Perhaps it
could be a different color that would stick out in both light and dark
backgrounds?


There is color-mapping support in portage 2.1, i guess it could be done with 
that.


Also something that has always bugged me... isn't the U supposed to be
for upgrade and the D for downgrade? In this case, it would make sense
to only show the D when downgrades will occur, and not both, wouldn't it?


I always interpreted it as 'update' instead of 'upgrade'.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Simon Stelling

You've already been told it's a non-issue, but here's why:

http://devmanual.gentoo.org/general-concepts/slotting/index.html

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:

Oh hell, this can't be serious !


It is.

It mixes up diffent things to one and just introduces new 
problems instead of solving anything. I could live with that, 
if it's for supporting different ABIs, but it obviously isn't.


What sort of problems? An example backing up your claims would be very nice.


gtk1 and gtk2 are completely different packages, they're not
compatible. So why should they be one package ? Just because
they share some ideas and the name ?!


Yes. Why not, after all?


For example, there are lots of packages requiring gtk1, other
gtk2. As long as dependencies don't cope the slot cleanly, 
slotting is utterly useless.


=x11-libs/gtk+-1.2*
x11-libs/gtk+-2

do a decent job.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] PDA herd call for assistance

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:

I'm going to take a deeper look at the synce stuff in a few days,
so I'll probably have to fix a lot of things there anyways.
You may add me to your maillist(s) and CC me to bugs at will.


http://bugs.gentoo.org/userprefs.cgi?tab=email has a 'Users to watch:' input 
field. Just add the PDA herd's email address there and you will receive all 
their bug mails, which has the advantage of not causing a lot of bugzi spam.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Masking practics

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:

big_snip /

My problem still seems unsolved (or did I miss something) ?

Lets say, if I've, installed foo-1.1, and it gets masked due
some bug(s), but 1.0 isn't, I want to get informed with an big
fat warning, *before* anything actually done, ie. 


[...]
# WARNING: installed package foo-1.1 has been masked and would
# be downgraded:
# masking comment ...
[...]

An fully-automatic downgrade should *never* downgrade anything. 
This is too dangerous, because essential features can get lost.

Again, my bugzilla example: assuming 2.22 will be unmasked some
day and I installed it w/ postgres support. Now there are some 
bugs found, but not fixed fast enough, so it gets masked. 
I run an update w/o knowing that it downgrades, and my whole

bugzilla hosting is suddenly broken.

Do you consider this as stability, seriously ?!


If your bugzilla hosting breaks with lower versions, then the ebuild contains a 
RDEPEND=postgres? ( =dev-db/postgresql-2.22 ). Now if =postgresql-2.22 gets 
masked, portage will bail out with an error because it can't find a valid 
dependency tree. This will cause the comment above the masking line in p.mask to 
be shown. You can then decide whether the breakage affects you or not and 
depending on that unmask it locally or remove your bugzilla installation.


If there is a bugzilla-ebuild which works with postgresql-2.22, it will be 
downgraded too, leaving you with a working bugzilla.


I can't quite see the massive problem.

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary

2006-08-07 Thread Simon Stelling

Wolfram Schlich wrote:

Any comments or thoughts about this?
Does the security team currently face serious problems that need to be
solved, be it inside or outside the security team?


As far as I know large chunks of time get lost when waiting for maintainers and 
arch teams to do their work. I don't see how the security team could do much 
about this; except maybe giving them a yearly budget to travel around the world 
and slap people who seem to ignore security bugs.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:

What sort of problems? An example backing up your claims would be very nice.
+ Additional complexity (slotting) is necessary, so additional 
  changes of bugs.


Oh please, this is so lame. That feature has been in existance for long enough 
to be proven useful and not faulty. The higher probability of problems is 
really not the best argument when discussing features that have been around for 
an incredible long time.


+ Package maintainers have to both take care of slots *and* 
  version number *ranges* 


taking care takes you one line. I already gave you both dependency strings. 
Now guess what: If they were two packages, it would take you one line too! OMG!



+ Different packages are treated as equal, produces confusion


Aside from that guy who opened bug 143063 [1] I have yet to see anybody who got 
confused by this behaviour.



So, why don't you consider libxml and libxml2 equal packages ?


Because that's the way upstream names them.


As said: you have to take care of version *ranges*.
Adds additional complexity. 



BTW: how do you enforce an minimum gtk1 version ?


You know that this wouldn't even make sense, as - you've pointed it out so many 
times - the API is incompatible.


So, I'm asking you one last time: Do you have any actual good reasons to not 
package things the way upstream does it?


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

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:

Yes, I'll file a bug on the whole gtk issue and all packages
using this ugly hacks.


You can save your time. Really. And vastly more important, save our 
bug-wrangler's time. You've already filed a bug. It was closed as INVALID, and 
except for you nobody in this thread agreed with you. It won't get anywhere, 
because you're the only one pushing for that change. I can assure you that every 
single bug for every package you file will get marked as DUPLICATION of the 
first bug, which was closed as INVALID.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Simon Stelling

Enrico Weigelt wrote:
If we changed the name of a package every time there was an API break, 
we would literally have thousands of packages in the tree that essentially 
do the same thing, just with different API's. 


Yes, but it would be much more cleaner. Everyone would see what
actually happens. Now its hidden from the user, but not changing 
the fact that they're different.


 __ ___ _ _ __   _   ___   ___
/_ /_ |  | (_) |   / /  | | | | _/_ | |__ \
__  _| || |__| |_| |__  ___   / /_ _| |_| | ___| |_ __| |) |
\ \/ / || |__| | | '_ \/ __| / / _` | __| |/ /_   _|__| |   / /
   | || |  | | | |_) \__ \/ / (_| | |_| |_|| |_ / /_
/_/\_\_||_|  |_|_|_.__/|___/_/ \__, |\__|_|\_\|_(_)|
__/ |
   |___/

Tell me, where is it actually hidden?

I tend to avoid such unstable packages. 


Nice for you. We don't care.


Thanks for the warning of neon, so I'll never even think of using it.


Nice for you. We don't care.


Of course. They're different packages.


They have the same name. Different versions. That's how it is upstream and how 
it should be.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)

2006-08-07 Thread Simon Stelling

Brian Harring wrote:
You're asking on the wrong ml.  Profile monkeying really should 
include a run through of -dev, *especially* something like that that's 
going to be a pita to turn off when folks start abusing it...


Make sure you explicitly state that one *must not* force a flag simply because a 
 build breaks with USE=-foo.


Other than that, I'm for it. It will make my job easier :)

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided

2006-08-06 Thread Simon Stelling

Paul Bredbury wrote:

But it is not an error. The answer is known to be False, through the
application of logic.


No. Let's get really sophisticated and do the 'application of logic' step.

There is a function built_with_use().
That function reports whether something was built with or without a specific USE 
flag.

The sentence above includes the fragment 'was built with or without'.
So it was built.
Uh, oh, but it wasn't built!!?!?
- Error

Really.

Go find a mathematician and discuss this matter with him. Tell him what you told 
me, and he will slap you with a large frying pan.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Proposal for advanced useflag-syntax

2006-08-04 Thread Simon Stelling

Enrico Weigelt wrote:

For example: mplayer
It has it's gui-less player and an gtk-based frontend in one package.
We should split this into two packages: mplayer and gmplayer.
The chances to get this done in the upstream *before* some major
distro like gentoo does the split by its own are quite low.


Not quite true. In reality, they're just the same. mplayer simply checks whether 
it was called as mplayer or gmplayer. So you not only have two programs in one 
package, but even in one binary. Changing this behaviour has nothing to do with 
packaging and is really upstream's responsibility, IMHO.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] per-package use.mask (bug 96368)

2006-08-04 Thread Simon Stelling

Zac Medico wrote:

Shall we go ahead with the package.use.mask implementation or not?


Yes, please!

--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for August

2006-08-03 Thread Simon Stelling

Jakub Moc wrote:

Broken bugzilla affects every ebuild dev, affects GDP, affects bug
wranglers, affects anyone else who's using it to track outstanding
project issues. How is this continuous borkage not a global issue that
council should discuss?


What is there to discuss? Do you expect them to say 'bugzilla shall be fix0rd!'? 
What would that change in reality? I, (and I guess so does solar) fail to see 
what the council could effectively do in regard to this matter. You should 
probably elaborate on that.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Re: Atom matching behavior

2006-08-02 Thread Simon Stelling
Brian Harring wrote:
 Response to this is that well don't have versions like that, 
 which while valid, is ignoring the point- cpvs are exact in their 
 version specification, there isn't anything implicit about them. 

This sounds to me like 'division through zero doesn't make sense, but
i've still got the right to do it'. Really, if anybody is ever going to
release 1.0 and 1.0.0 along each other, that person is completely on
crack. You can't do 2/0, either can you have 1.0 and 1.0.0 being
different versions. They should be the same.

That being said, which one is higher?

 Tag on a (.0)* implicitly, you open up potential issues like above.

Nonissue, really.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Resignation

2006-07-31 Thread Simon Stelling
Ciaran McCreesh wrote:
 Good intentions and trying to be helpful don't keep users or
 developers. Screwups lose users and developers.

It's really funny to hear such a statement from a person who made several great
developers leave the project.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Keep Sunrise... But not Here

2006-07-31 Thread Simon Stelling
Michael Crute wrote:
 Thoughts anyone?

That's all been done. That's why the last thread's title has the word 'resumed'
in it, after all :P

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

2006-07-30 Thread Simon Stelling
Enrico Weigelt wrote:
 The gentoo devs currently do much of the upstream's work.
 Fixing bugs or even adding new stuff which does not directly have to
 do w/ gentoo should be done exlusively by the upstream.

This is not really a problem. Fixing bugs is what I enjoy after all, this is the
interesting stuff. Spending hours on one broken build system is far more
interesting than writing 100 ebuilds.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list



  1   2   3   >